I am doing some testing for a new install I have coming up.
I have been experimenting with a ZEN32 (scene controller) using a couple of the scene buttons to control a separate ZEN77 dimmer.
I wrote two meshbots, one case attached below.
I found the dimmer_up and the dimmer_down actions once started go to 100% or 0% respectively and the value entry doesn’t seem to do anything. I thought the value was meant to be the step size for each increment or decrement. Instead I had to do a delay then a dimmer_stop which is not as crisp as I would like.
What is the function/purpose of the value field in dimmer_up and dimmer_down, dimmer_stop capabilities? (red circle below) I am confused.
Misc other topics:
I would say the new way of configuring parameters in Ezlo is far superior to Vera, a nice improvement.
Lastly I saw some meshbot editing issues in Firefox on Ezlogic.mios.com site (value/option choices didn’t populate). It got fixed when I switched to MS Edge but fyi for someones todo list.
the commands “dimmer up” and “dimmer down” should not have a value parameter. They just start increasing/decreasing the value of dimmer until it is stopped again. You can see this behaviour on the mobile apps.
This was a point missed and we will remove those fields from meshbots.
The start increase/decrease command depends on the device itself if it supports or not.
OK by experiment that is what I thought was happening. I have a few PTZ cameras that are similar, once you start a pan, tilt, or zoom it doesn’t stop until you issue the corresponding stop command.
It would be better if you could specify a step size but if the target device doesn’t support that then its a moot point.
I was able to get the ZEN32 scene controller to control a ZEN77 dimmer via a handful of meshbots.
Its pretty basic stuff but thought might be helpful for others. I am trying to replicate a Control4 user experience (at a fraction of the cost) via ZWave devices and an Ezlo hub.
In this example I dedicate two of the scene buttons (on an ZEN32) to be the up and down buttons for a companion ZEN77 dimmer.
With more ZEN32s (or other scene controllers) and more meshbots you can expand this to many multi dimmer locations for the same circuit of lights. This is dimming nirvana where every switch location can fully control the fixture instead of simply one main site for dimming and the rest just on and off. There are others ways to do this with direct association but that doesn’t work for the ZEN32 hence this post.
Now my question to the admins. Is there a way to write the above five meshbots into one nested meshbot? In others words multiple triggers each with a separate action from the others? It would be tidy not to have to create five meshbots for the example above just for maintainability and code tidiness.
Wondering if there is a nesting technique in meshbots I am unaware of??
Yes just bought a new home where many of the neighbors have Control4 systems for lighting. Most of them hate the Control4 system because they feel they are locked/captive with their (expensive) dealers and they are forever charging them to come out to check or modify the system. So with the scheme above I think I can get a similar to Control4 experience and be able to manage the backend myself without monthly service calls. Would be nice to have a few more in-wall scene controller options but ZWave seems in a perilous place with WiFi seemingly running past it.
My only concerns is as I populate the ZWave network and the traffic gets so busy that ZWave lags cause the dim up and dim down not to work very well (overshoot set point due to network lag). I guess I’ll find out as the network gets populated. For now the basic use case is proven out.
please let us know if we can improve our automations or anything else in anyway.
You can write “nested” single meshbot…
or write each meshbot as a module and call all that from a single meshbot.
here is all the nesting capability under “Add Group” button. Also how you want to join them with logical operators…
Yes, I could readily compress the five meshbot triggers into one but each trigger needs a different action. So if there a way to create an OR nested series of trigger groups but then below in Action allow you to declare action 1 for trigger a, action 2 for trigger b and so on. As I say it doesn’t create anymore functionality than exists today. You can do it today with separate meshbots but it might be nice to group under one meshbot for reasons I mentioned earlier.
In my case here each pair of ZEN32 scene switches need 5 meshbots, now lets say I have five ZEN32s in the system, that is 10 pairs of switches, or 50 meshbots needed to replicate the functionality above. So the meshbots list can get messy quickly.
Exceptions seems a poor choice of wording, shouldn’t be a co-dependency/co-requirement? that the trigger must be true AND the exception must be true for the action to occur?
…“Exceptions are similar to triggers in that they act as a condition that must be fulfilled before an action is run.”… Exception to me would seem to be a condition in which the action wouldn’t run. Do this except if…
Beyond a nomenclature debate I have to wonder how the sequence of evaluation works with exceptions. In my example each trigger condition has a corresponding and identical exception. This is so that the one action is tied to one of the triggers and not the other triggers. But once the condition is met for the initial trigger does it have to be met again for the exception or is it the same event for both cases? By example if the trigger is button 1 is held and that is satisfied does the exception now need to see a new button held event or is it evaluating the prior identical condition that satisfied the earlier trigger? I see a window for race conditions here if the evaluation is different and time delayed.
When I implement the meshbots as five discrete meshbots the functionality works fine. When I combine them together using exceptions it does not work yet the logic is the same. There is either a bug in how exceptions work or there is some subtlety to the evaluation and time delays between the trigger and the exception. Something is not quite right here…
I still have issues with reliable execution of exception based meshbots. I have tried many things but the exception cases are erratic and mostly don’t work.
I am at a loss to proceed at this point. I was hopeful exceptions could collapse several single purpose meshbots into one for simplicity but there is something about the evaluation of the trigger condition and the exception that is different which is causing a problem.
A few findings/thoughts.
The trigger in the upper meshbot is rock solid. I put in some dummy code in the action section and it get triggered reliably every time when either switch is doubleClicked.
Because of #1 that means the erratic operation of the exception must be the reason the meshbot doesn’t work reliably.
I am suspicious that despite the trigger and the exception being identical they are evaluated differently in basis or maybe in time. I wonder if the trigger occurring state is not passed through to the exception. Instead all that memory is flushed and the evaluation start anew and now the inbound messages about switch closures is gone so the test now fails? I don’t know the inner state machine workings and message persistence so this is a guess on my part.
I was wondering if I could use LATCH to save the initial trigger state into a variable and then use that variable as a condition in the exception. That would seem to guarantee the reliable trigger condition be used for the exception instead of some time delayed and potentially impaired re-evaluation. There doesn’t seem to be a way to save the LATCH to a local variable.
Did more experiments today but no luck. Simplified to the most basic meshbot to hopefully pinpoint this better. I tried latching the switch state in hopes it would be preserved through to the exception evaluation. Then reset the latch at the end of the actions for next time around.
As stated before it is my belief the trigger works every time but the exception is flawed and is somehow getting impaired. I was hoping the LATCH might eliminate any issues of secondary evaluation of the trigger but alas it didn’t help.
I think there could be an issue when editing meshbots which corrupts them. I don’t know if that is the problem with my exclusions but I found a very simple meshbot worked 100%. Then I edited the actions to swap the order of them and save and after that the meshbot didn’t work properly anymore. When you can’t even rely on editing of a meshbot let alone the logic engine behind it, it makes this a difficult platform to rely on.
Top one worked fine, but just swapping the order of the actions corrupted the meshbot and it no longer worked properly:
I just tried this and didn’t seem to have the same issue (initially).
I created a new rule with two HTTP actions sending TTS announcements to my Google Home speaker.
The first action said “Message 1” and the second action after a few seconds delay said “Message 2”. My trigger was a virtual switch being turned ON.
I triggered the rule and it worked as expected, I heard the TTS “Message 1” first and then “Message 2”.
I then edited the rule and re-ordered the position of the actions i.e. I made the second action now the first action etc.
I then triggered the rule again and this time it said “Message 2” first and then “Message 1” on the Google speaker, so now my actions were in a different order.
So that seemed to work OK for me. I see you were using devices in your actions a switch and a dimmer. So I might have to try that next and replicate your rule above.
And then I had a problem after triggering the rule, after editing it and re-ordering the actions, the virtual switch 3 in the action was NOT turned ON but the dimmer was still set to 45% OK however.
So maybe there is a problem and bug here affecting the “Device” node as I did not see any problem when using the “HTTP” node in my first tests.
I then edited the rule again and swapped the action back around to how they were initially, so now virtual switch 3 toggle is the first action again. However triggering the rule its still broken and the virtual switch 3 is NOT turned ON. The dimmer is still set to 45% however.
So my rule does now seem corrupted and broken. I’ve reported this to a dev and made a new ticket.
Yes. I have been having many problems with the action side of meshbots. It all started when I started adding exceptions to the actions. I have created seven meshbots to cover all the use cases to have two ZEN77 dimmers plus a ZEN32 working in a three location multi site dimmer. Works great.
I learned of exceptions as a way to combine the seven meshbots into one with conditional execution on the actions. I did this to avoid the clutter of many meshbots for essentially one set of use cases.
Fortunately I have an interim solution, just not use exceptions, and use seven discrete meshbots but that is not a great answer long terms as I plan to have a few cloned instances of this switch arrangement so next thing you know 7 becomes, 14, 21, 28, 35… just to handle a few switch locations. Gets unwieldy quickly. Belwo is a short PDF of the seven meshbots and why they are there.
My guess is when you start editing with exceptions in the action side somehow the meshbot gets corrupted. Maybe some syntax error is missed or improperly changed. Not sure how rigorous this is checked. Once corrupted and the exception is removed the underlying problem still remains hence my issue with action swapping without any exceptions.
I’m not sure of any of this but the hit or miss nature or creating these meshbots is a huge time waster. I’m trying to build up and move forward but unexpected issues seem to pop up far too regularly and its 2 steps forward, two back, … When you doubt the platform and underlying system is seriously erodes your confidence in what you are doing.
I’m told there are Ezlo folks looking at this and perhaps it will be a simple fix in the end. If I can create the master meshbot with OR’d triggers and then exception based actions I can simplify my meshbot list so be more manageable (one more complicated meshbot instead of seven trivial ones)
I have been looking at Hubitat and they allow for conditional actions. So its not a new or exotic topic.
I prefer to stay with Ezlo but these ongoing gotchas are too common for a mature platform. I think they need more staff and more internal verification/validation efforts. I guess not too many people are ussing exceptions in actions so not a lot of people tripping over this presently.
