Beta - Ezlo Linux 2.0.32.2097.3 [production-146] for Ezlo Plus, Ezlo Secure controllers

[Max]

Hello all,

We’ve released a new beta update for Ezlo Linux firmware 2.0.32.2097.3
The highlights of this release are

• new device integrations and fixes
• improvements and bugfixes in Ezlogic
• improvements and fixes in the Plugin Framework
• logging improvements
• other fixes and improvements (SoftHub, system, connection)

The new Beta update for Ezlo Linux firmware 2.0.32.2097.3 for Ezlo Plus and Ezlo Secure controllers contains:

[Device integration]
Add support for the new Yale Lock product ID. Model ID: “NF-YRD612 PBDB”
Fibaro FGPB 101 - Button Function Not Working
Add full support for MCO Home A-89 9-in-1 sensor
MCO HOME Touch Panel Switch MH-S512 Have extra Switch
Neo Coolcam Light Switch 3 Buttons incorrect work
Incorrect range generated for the Thermostat Setpoints of MH-F500 thermostat
Incorrect range generated for the Thermostat Setpoints of MH-3928 thermostat

[Scenes][Actions] Action execution policy wait_result
[Scenes][Conditions] Evaluate the initial state of date range events isDateRange, isDate without time
[Scenes][AndOperator] AND operator doesn’t allow the creation of compareNumbers with expressions
[Scenes][Event flow] Add transactional handling for isSceneState, isGroupState, isCloudState, isItemState
[Scenes][Anonymous plugins] Unable to delete Lua scripts because of an “Anonymous plugin acquired!” error
[Scenes][Date Node] isDate: add range counterparts for weekly, monthly events
[Scenes][Date Node] Switch isDate with custom time to false after completing trigger block
[Scenes] behavior of “isItemStateChanged” doesn’t correspond to documentation
[Scenes][House Modes] houseModeChangedTo/From initial state and exceptions

[SoftHub] ha-bluetoothd is crashed and restarted continuously

[Plugin][Custom] Typo in error message displayed when installing a plugin with errors in interface.json
[Plugins][API Parity] - Command/scripts timeout and add API for changing the timeout

[cw-kid]

@Max

houseModeChangedTo/From initial state and exceptions

My controller is:

• Firmware: 2.0.32.2097.3
• Advanced Scenes: 1.54
• Web UI: 1.34.1
• Jira Ticket - EPPT-5097

How do you do just Home Mode currently equals ?

House mode = Home for example rather than “Changes”

I only want the Action that has an exception to run if House Mode is currently “Home”.

Thanks

EDIT: I’ve done some testing and it does seem to work OK when set as this:

Think its the wording “Changed To” that was confusing me somewhat.

So in my rule I have two actions.

Action 1. Turn off a light
Action 2. Send a TTS announcement (with exception “Home” mode).

When the controller is in “Home” mode both actions are run

When the controller is in “Night” mode only the first action is run, the second action to do ths TTS is not run.

This is correct and how I wanted it to be working.

[blacey]

There is another House Mode inconsistency in Meshbots. Specifically, Scenes created with “House mode” limitations using the iOS Vera App do not show those limitations in the EZLogic Meshbot editor. In fact, it isn’t clear how House Mode limits should be represented in the current EZLogic modality.

Below are screenshots for the iOS and EZLogic scene/meshbot editor to Close Blinds on an Ezlo Plus running 2.0.32.2097.3.

1. As you can see, the iOS Scene editor shows that the scene should only be run in Home, Away and Night house modes but those modes are not reflected in the EZLogic Meshbot editor for that scene.
2. Would it make sense to allow Exceptions on Triggers too to short-circuit the running of an entire scene under certain conditions? Perhaps the exception could be expressed for House Mode, a variable, an expression and/or a Lua Script result?

At a minimum, point 1 represents an EZLogic bug and point 2 is a question about the ultimate scope for “exceptions”.

[cw-kid]

This is the way I see it “Exception” is a Condition aka a “Constraint” in MSR.

In MSR its much better overall I think, as you have your rules Trigger(s) then under that a separate section in the middle for any Conditions “Constraints”.

Then your Actions at the bottom. Actions can also have additional conditions / exceptions applied to them via a “group”.

In Mesbot’s there is no Conditions / Constraints section in between Triggers and Actions.

They say any “Conditions” you may have should also be added in to the Triggers section. However in some situations with multiple triggers acting as “conditions”, I have seen strange and unexpected stuff happen when doing that in the past.

The rule I was looking at earlier today in relation to this Meshbot Action “Exception” thing, was the rule that turns off some of my garden lights.

The rule in MSR -

Trigger -

There is only one Trigger - A trigger to me is the main thing that starts the rule processing. In this case its a time schedule.

Condition / Constraint

This is a condition that checks if the light in question is already turned ON ? If its OFF already then no point continuing and running the rules Action to turn it off as its already off. So this is a Condition “Check”.

Actions -

Action 1 - Turns OFF the light
Action 2 - Send a Notification to Telegram
Action 3 - Sends a TTS announcement to my GH speaker

Actions 1 and 2 I want to happen every time this rule is run.

However Action 3 that does the TTS I only want to happen if the controller is in “Home” mode.

In MSR its called a “Group” when you want to add an additional Condition / Check at the per Action level.

In Mesbhot’s in the Actions section, they called it an “Exception”.

The same rule now in Meshbot’s

Trigger(s) -

I now have two “Triggers” here. One is my actual trigger the “main trigger” I want which is the time schedule.
The second trigger is what was in the “Constraints” section in MSR. Its the Condition that the light must be ON already etc.

Actions -

I haven’t bothered with the Telegram notification action as Ezlo don’t support it other than using RAW HTTP requests.

Action 1 - Turns off the light
Action 2 - Sends the TTS announcement to the GH Speaker - But I added an “exception” that the controller must be in “Home” mode.

[cw-kid]

@blacey

Would it make sense to allow Exceptions on Triggers too to short-circuit the running of an entire scene under certain conditions? Perhaps the exception could be expressed for House Mode, a variable, an expression and/or a Lua Script result?

Yeah they only currently have “exceptions” at the Action Level not the Trigger Level.

I really wish they had just done what Reactor, MSR and PLEG had done.

Trigger(s)

Conditions

Actions

We had to ask Patrick to add the ability for additional per Action “Conditions” so he added “Groups”.

Trigger(s)

Constraints (Conditions) - Main conditions for the whole rule

Actions

Action 1 - runs every time
Action 2 with “Group” - additional condition(s) that must be matched for this particular action to run.

[blacey]

@cw-kid

Yeah they only currently have “exceptions” at the Action Level not the Trigger Level.

I really wish they had just done what Reactor, MSR and PLEG had done.

I agree - I am a firm believer that it is good to learn from prior art when and where it makes sense and does not encroach on IP. Perhaps the team will take a look at this discussion and revisit/rethink the EZLogic exception/constraint use-cases accordingly to encompass a broader set of needs and gain meshbot/scene definition “simplicity” and execution “performance”.

[cw-kid]

Its like this here for my lounge lamps ON schedule.

What is the actual main trigger in this lot ?

One is what I would call a trigger the rest are conditions for the rules actions to be run etc.

MSR rule -

Trigger - Single Time based trigger. I can clearly see what trigger starts this rule processing etc.

Constraints / Conditions - These all have to be met for the rules actions to be run.

And the actions obviously turn on the lights.

[blacey]

I agree that MSR has a much cleaner constraint/exception implementation. I still think the Ezlo team needs to rethink this area and improve it as you have demonstrated with your comparative analysis.

That said, as a work-around to improve clarity (i.e. reduce confusion) in your meshbot trigger section, you could change the device exceptions to NOT TRUE so when you read the triggers, the main trigger is followed by a series of NOT exceptions Food for thought.

[cw-kid]

Thats a good idea or maybe even put the others in to a group below the main date / time trigger.

[melih]

So what can we do to “improve” usability?
What is it that you can’t do in Ezlo easier?
would love your feedback so that we can continually improve the product.

(what is the technical difference between a “trigger” and a “Condition”? They both are a “State” of a device, its merely a “subjective” decision which one you appoint as a “trigger”…?)

[cw-kid]

It’s a way of thinking about your rules thing and a visual UI thing. As we are so use to using PLEG and Reactor etc.

I have edited my new rule and added a Group instead like this:

However saying that I have in the past, seen odd behaviour sometimes, when adding items in to Triggers and expecting them to just work as a “Conditional check”. Sometimes that item might also actually trigger the rules actions to be run when I wasn’t expecting it to do that.

Its been sometime since I have even tried creating Meshbot rules with extra Triggers that I want to act as a “Condition”, so can’t fully remember now.

I will have to create some more rules and test somethings again.

That new rule btw just ran and turned on my lamps as its 40 minutes before Sunset now.

[melih]

@cw-kid

It’s a way of thinking about your rules thing and a visual UI thing

exactly my point…its a subjective preference thing vs capability…(including what is considered to be a Trigger vs Condition… (they are interchangable)…)

So from the UI point of view…any recommendations as to how we might make it better?

[blacey]

@Melih, did you see my 2 points here? Beta - Ezlo Linux 2.0.32.2097.3 [production-146] for Ezlo Plus, Ezlo Secure controllers - #3 by blacey

[cw-kid]

Actually I remember about this particular rule for my Lounge Lamps ON Schedule, last time I tried it in Meshbot’s, there was a bug that if after the schedule had run and the lights had been turned on, if you then later manually turned the lights off, they would be automatically turned back on again instantly by the system.

This no longer seems to be happening now, so something must of been fixed. Now when I manually later turn the lights off they stay off.

[Max]

@blacey

Would it make sense to allow Exceptions on Triggers too to short-circuit the running of an entire scene under certain conditions? Perhaps the exception could be expressed for House Mode, a variable, an expression and/or a Lua Script result?

We are planning to introduce the “cancel meshbot” capability. It should cover the use case you described.

[cw-kid]

@melih

So from the UI point of view…any recommendations as to how we might make it better?

I don’t really understand why we might want “exceptions” at the Trigger level as @blacey said.

For Actions yes I can understand that. As in the example I gave above for the TTS announcement action I wanted an “exception” so that particular action only ran if the controller was in Home mode aka I hadn’t already gone to bed and the controller would then be in Night mode.

As for Triggers I’m trying to think of a scenario when I might want an “exception” on a trigger. The trigger is the “exception”.

I guess there could be some uses for an “exception” on a trigger? but can’t think of one at the moment.

As for the UI layout, I said it from day one and haven’t really changed my stance. Add a Conditions section between Triggers and Actions.

[melih]

Yes, and our guys have taken that in as an input into our devs…thank you. @Max is the owner driving it internally.

my question was more around “Trigger vs Condition” concepts.

[melih]

@cw-kid

Add a Conditions section between Triggers and Actions.

What is a condition if not a Trigger? (its exactly the same thing, isn’t it)? Technically speaking they are about “Data” about a “State” of a device…

[cw-kid]

Technically yes they are the same.

However my OCD could possibly cope with this, if I add a Trigger group.

It definitely could not cope with looking at this however.

And Reactor and PLEG with their separate “Conditions” section in the UI really helped my OCD lol.

[blacey]

@cw-kid

I don’t really understand why we might want “exceptions” at the Trigger level as @blacey said.

My suggestion is global vs. local exceptions/conditions for a scene/meshbot. I’m not suggesting one UI implementation vs. another to achieve such. While it is manageable to place trigger exceptions in a self-made group under triggers labelled “Conditions”, I feel that is the result of a non-intuitive UI design that bleeds the underlying technical implementation up to the user (further exemplified by @Melih’s “data” vs “state” comment). If you really want your average typical user (i.e. not @cw-kid) to easily grasp and use conditions/exceptions to limit scene execution, then the condition/exception UI design needs to be much more intuitive than what is there now. Just my 2 cents.