You can use exceptions on actions. so each action executes only if the exception is true
I’m trying to implement this right now. I have now configured the two actions as follows:
Unfortunately I cannot select a capability in the exception for the second action. The entries do appear. But when I select one of them it is immediately deleted. Am I doing something wrong or is this a bug?
A couple comments.
To avoid a race condition you might want to put say a 10-20 second delay to start the action sequence. Then change the state of the thermostat. Might not be needed due to interval triggering scheme but I sometimes do this to to keep things tidy.
As for two meshbots, that i why I recommend XOR function. It will fire only if the door and thermostat are different. When they are the same nothing happens. Then in the action just change state where new state equals inverse (or toggle) of old state. I had a several meshbots with two versions for the positive and negative case then I discovered XOR and it simplified things into one meshbot.
Looks like you well on you way to sorting this out.
It may be a bug. Let us take it asap. I filed the bug. Engineers are in GMT+2 so let us some time.
I just remembered that I had this exact problem with my pool project in 2022-06. I couldn’t create a second action/exception:
I can confirm I have the same problem as shown in that video above. On the second Action and its Exception when you select the Capability the Value drop down menu does then NOT appear.
Any news on that?
Lately I’ve had the problem more often that the Z-Wave chip seems to hang up and no device can be reached. Support has already reset the Z-Wave chip twice and has now recommended a Meshbot to restart daily as an interim solution. I suspect that this is due to the two new meshbots, which check at the same interval whether the two devices have an undesirable condition and then correct it. This probably caused me to create a kind of endless loop, which then paralyzed the Z-Wave network.
If I could put the two together, the problem would probably be solved.
What do the commands that are sent to devices actually look like? For example, if a device is already turned on and the “turn on” action is started. Is the command then sent unnecessarily even though the state has already been reached?
I’d also like to know more about this.
I think on the Vera platform if the device is already on and another on command is sent, the system doesnt then operate the device again.
I think, not 100% sure about this, so don’t quote me on it.
In fact I may try this while looking at the Vera system log.
UPDATE:
Not sure, but trying this on my Vera Plus with a Scene, it looks like in the logs it sends the ON command anyway again regardless that the switch was already ON.
08 11/13/23 14:39:25.010 Scene::RunScene running 305 Test - Z-WAVE Command <0x6c332520>
08 11/13/23 14:39:25.012 JobHandler_LuaUPnP::HandleActionRequest device: 367 service: urn:upnp-org:serviceId:SwitchPower1 action: SetTarget <0x6c332520>
08 11/13/23 14:39:25.012 JobHandler_LuaUPnP::HandleActionRequest argument newTargetValue=1 <0x6c332520>
06 11/13/23 14:39:25.012 Device_Variable::m_szValue_set device: 367 service: urn:upnp-org:serviceId:SwitchPower1 variable: Target was: 1 now: 1 #hooks: 0 upnp: 0 skip: 0 v:0x1582e28/NONE duplicate:1 <0x6c332520>
06 11/13/23 14:39:25.271 Device_Variable::m_szValue_set device: 367 service: urn:upnp-org:serviceId:SwitchPower1 variable: Status was: 1 now: 1 #hooks: 1 upnp: 0 skip: 0 v:0x1582e90/NONE duplicate:1 <0x7676c520>
04 11/13/23 14:39:25.272 <Job ID="2" Name="ON node 87" Device="367" Created="2023-11-13 14:39:25" Started="2023-11-13 14:39:25" Completed="2023-11-13 14:39:25" Duration="0.259126000" Runtime="0.258029000" Status="Successful" LastNote="SUCCESS! Transmit was OK" Node="87" NodeType="ZWaveNonDimmableLight" NodeDescription="Flood Lights Power"/> <0x7676c520>
Will look at an Ezlo hub next and its log.
The Ezlo logs are not so easy to read or understand as there are multiple log files and related information is stored in several of those log files.
You can SSH into the Ezlo hub login as root and run this command to tail the logs together. tail -F ha-*
I did this and then ran my Meshbot rule that turned on a Z-Wave switch that was already turned on. To me it looks like the Z-Wave script is run to turn on the light by setting its Switch Item to value true.
This part I think:
2023-11-13 15:24:31.581065 DEBUG: handleSetItemValue: Setting item value
2023-11-13 15:24:31.582716 DEBUG: sendExecutePluginScript: Execute script: HUB:zwave/scripts/set_item_value, with params: {
"item_id": "630611aa123e4312889cdfb2",
"source": {
"id": "65523754123e4315f4e0ce1c",
"type": "scene"
},
"value": true
}
This is other related stuff I saw in the logs:
==> ha-uid.log <==
2023-11-13 15:24:31.554140 DEBUG: RECV(NMA) <<< wss://nma-server7-cloud.ezlo.com:443/ <<< {
"id": "43c42a57-77d4-4846-a2da-4f2551f7d897",
"jsonrpc": "2.0",
"method": "hub.scenes.run",
"params": {
"sceneId": "65523754123e4315f4e0ce1c"
},
"sender": {
"conn_id": "4f864eee-ad43-4f77-878f-1dc0b7edeb30",
"type": "ui"
}
}
2023-11-13 15:24:31.554781 INFO : Received new command: hub.scenes.run
2023-11-13 15:24:31.577417 DEBUG: SEND(NMA) >>> wss://nma-server7-cloud.ezlo.com:443/ >>> {
"error": null,
"id": "43c42a57-77d4-4846-a2da-4f2551f7d897",
"method": "hub.scenes.run",
"result": {},
"sender": {
"conn_id": "4f864eee-ad43-4f77-878f-1dc0b7edeb30",
"type": "ui"
}
}
2023-11-13 15:24:31.579150 DEBUG: SEND(NMA) >>> wss://nma-server7-cloud.ezlo.com:443/ >>> {
"id": "ui_broadcast",
"msg_id": "65523faf123e43153fc68683",
"msg_subclass": "hub.scene.run.progress",
"result": {
"notifications": [],
"scene_id": "65523754123e4315f4e0ce1c",
"scene_name": "Test - Z-WAVE Command",
"status": "started",
"userNotification": false
}
}
"id": "ui_broadcast",
"msg_id": "65523faf123e43153fc68683",
"msg_subclass": "hub.scene.run.progress",
"result": {
"notifications": [],
"scene_id": "65523754123e4315f4e0ce1c",
"scene_name": "Test - Z-WAVE Command",
"status": "started",
"userNotification": false
}
}
2023-11-13 15:24:31.616479 DEBUG: SEND(NMA) >>> wss://nma-server7-cloud.ezlo.com:443/ >>> {
"id": "ui_broadcast",
"msg_id": "65523faf123e43153fc68684",
"msg_subclass": "hub.scene.run.progress",
"result": {
"notifications": [],
"scene_id": "65523754123e4315f4e0ce1c",
"scene_name": "Test - Z-WAVE Command",
"status": "finished",
"userNotification": true
}
}
"id": "ui_broadcast",
"msg_id": "65523faf123e43153fc68684",
"msg_subclass": "hub.scene.run.progress",
"result": {
"notifications": [],
"scene_id": "65523754123e4315f4e0ce1c",
"scene_name": "Test - Z-WAVE Command",
"status": "finished",
"userNotification": true
}
}
}
==> ha-scenes_manager.log <==
2023-11-13 15:24:31.556602 DEBUG: handleRequestFromBus, request :{"global":false,"sceneId":"65523754123e4315f4e0ce1c"}
2023-11-13 15:24:31.557752 INFO : runActions: start "then" action block of a scene with ID=65523754123e4315f4e0ce1c
2023-11-13 15:24:31.575618 DEBUG: CoreDRemoteInterface::setItemValue(){"_id":"630611aa123e4312889cdfb2","source":{"id":"65523754123e4315f4e0ce1c","type":"scene"},"value":true}
2023-11-13 15:24:31.576145 DEBUG: CoreDRemoteInterface::setItemValue() - single: "630611aa123e4312889cdfb2"
2023-11-13 15:24:31.578303 DEBUG: CoreDRemoteInterface::setItemValue(): {
"_id": "630611aa123e4312889cdfb2",
"source": {
"id": "65523754123e4315f4e0ce1c",
"type": "scene"
},
"value": true
==> ha-cored.log <==
2023-11-13 15:24:31.580818 DEBUG: handleSetItemValue: Setting item value: {
"_id": "630611aa123e4312889cdfb2",
"source": {
"id": "65523754123e4315f4e0ce1c",
"type": "scene"
},
"value": true
}
2023-11-13 15:24:31.581065 DEBUG: handleSetItemValue: Setting item value
2023-11-13 15:24:31.582716 DEBUG: sendExecutePluginScript: Execute script: HUB:zwave/scripts/set_item_value, with params: {
"item_id": "630611aa123e4312889cdfb2",
"source": {
"id": "65523754123e4315f4e0ce1c",
"type": "scene"
},
"value": true
}
Yes the zwave command is sent even if the device is in same state. I confirmed it from logs and zwave sniffs.
For the exceptions bug , it is done by our dev team and in QA process. So we expect to have it on live next week.
2 Likes
Does it make sense to send the command even if the status has already been reached (perhaps if the current status of the device was not correctly transmitted to the controller)? That would cause unnecessary traffic. Maybe you could make it configurable to determine whether it should still be sent in this case or not.
I know I do this with Conditions in my MSR rules.
Check if a light is on first ? If not then turn it on etc.
We dont have “global” Conditions (exceptions) yet in Meshbots but they are coming soon hopefully.
Yeah I think that would work. It should only set the Thermostat mode to OFF if its NOT already OFF.
Exceptions at the per Action level such as these, only obviously affect that one particular Action.
What we have currently missing in Meshbot rules are global Exceptions or conditions as I prefer to call them.
With those a global condition would affect all actions of the rule.
In MSR we have both global conditions and per individual action conditions.
So for example in a rule you may have 5 actions. And any global conditions set should affect all 5 of those actions BUT one of those actions you may also want it to adhere to a further additional condition for it to then be run.
I find I use global conditions most of the time and only need to specify an additional individual action level condition now and then and that is much less used.
The MSR dev added Action level conditions at a later date as per our user requests. He already had global conditions in place.
Ezlo on the other hand got it backwards and added Action level conditions first and then left us hanging and waiting for global conditions.
Which for me made Meshbot rules pretty useless.
The exception bug doesn’t seem to have been fixed yet. What is the status regarding this?
It has reached Quality Check stage. So we will wrap it up in next week or start of the following. there may be a delay due to holidays. thank you for your understanding
The Exception Bug seems to be fixed. I was able to summarize the scenario in a single meshbot.
Every 10 minutes it checks whether the window sensor is open and the heating is on or whether the window sensor is closed and the heating is off:
If this is the case, the heater will be turned on if it is not turned on and the window sensor is closed or the heater will be turned off if it is not turned off and the window sensor is open:
I tested both undesirable combinations of states twice and it seems to work. The condition is straightened every 10 minutes.
Is this the optimal solution, or could/should something be done differently/better? The Z-Wave network should not be subjected to any particular load, as only states are compared and only undesirable states are corrected. How is the load on the controller? Does excessive/frequent use of such control mechanisms place excessive strain on the CPU or RAM? What would e.g. B. if you checked every minute and then several of these meshbots were running? Do the processes then become more sluggish or can this lead to errors? Or can the controller handle it easily?
Does no one have any idea how much/often the controller can run meshbots (i.e. just triggers/comparisons without performing any actions) without causing problems? I would really be interested to know when it will go down.
For example, if I run a check like this every few seconds and then create 50 of them, is that a good idea, or should I approach things like this differently?
Hello @Odysee
As mentioned in the community forum, running two meshbots at the same time with multiple actions could crash the Z-Wave service. This suggests that there is a limit to how many operations an Ezlo controller can handle at once without encountering problems.
To mitigate this, delays were introduced between actions in a Meshbot, and new Execution Policies were implemented to define the sequence in which actions are executed. The policies include:
- Execute actions in parallel: All actions are started at the same time.
- Execute actions sequentially: Each action is executed once the previous action is finalized.
For your specific case, where you’re considering running checks every few seconds and creating 50 of them, it’s advisable to approach this with caution. Running too many checks in a short interval could potentially overload the controller, leading to instability or failure. Instead, consider the following:
- Space out the checks to run less frequently if possible.
- Use the Execution Policies to sequence actions and prevent overloading the controller.
- Consider the complexity and number of actions each Meshbot performs.
- Monitor the performance and responsiveness of your system as you add more Meshbots.
It’s also worth noting that we are continuously working on improving the performance and capabilities of our controllers, as indicated by the ongoing development and updates mentioned in the Beta - Ezlo Linux 2.0.32.2097.3 [production-146] for Ezlo Plus, Ezlo Secure controllers forum thread.
Ultimately, while there isn’t a one-size-fits-all answer to how much your controller can handle, it’s best to start with a conservative approach and gradually increase the number of Meshbots while keeping an eye on the system’s performance.
Many thanks for the answer.
If several meshbots are executed at the same time, each with one or more Z-Wave actions, the Z-Wave network can be overloaded. But in my opinion this is not an unlikely scenario. What would happen if several motion detector-turns-lamp-on meshbots were triggered at the same time? Then no execution policies would work. Will the command then be sent to all lamps at the same time? How many commands can the Z-Wave network actually handle at the same time? Or are the commands then processed one after the other in a kind of queue? Then there should be no overload here, but at most a delay.
And if we only look at the query. Shouldn’t it be easy for the controller to simply compare values or something similar without executing anything?
That’s why I had already created the feature request so that you can display the CPU/RAM load on the controller. Then you wouldn’t know until nothing was running that the controller was overwhelmed.