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.
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
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?
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.
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.
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.
But on the Vera hubs each command was given its own job number, you could see that happening in the Luup log.
So I assumed it processed them in a queue. It would also acknowledge ACK if the Z-Wave end point device had confirmed it had ran the command as well and if not did some retries.
