Sorry if this is basic, but I’m learning and trying to be smarter and more efficient with my automation.
I’m talking about triggers like light levels, temperature or even a variable. Do they only trigger - like a temp trigger- once at the crossing point? Is there a hold time that keeps from firing over and over?
I am specifically looking at light sensors. For example : If in the afternoon the light drops to the trigger point and turns the lights on. The light level goes over the threshold. Then at night it’s bedtime and I turn the lights off. The light level will then be back below the trigger level. Will the meshbot then fire again and turn the lights back on? Or will the meshbot set to fire “if light <= 50” continue to trigger as long as light is below trigger level.
Also I’m wondering about variables. If I set a variable to “true” and the meshbot that’s looking for a “true” fires. Then the variable gets subsequently set to “false” and at some point back to “true”. Will the meshbot fire every time the variable toggles from “false” to “true”.
I’m not referring to using the “true/false” events option. Just a simple it’s “true” meshbot or a “false” meshbot
The meshbots get triggered when the nodes in the trigger section are changed in any way. So once a meshbot is triggered, it does not keep triggering.
But in your case, if you decide to turn the lights on based on a light measurement form a light sensor, then whenever that sensor data is changed (that means a broadcast coming from a zwave/zigbee device coming) then meshbot gets triggered based on your comparison. So it is up to the device if it can differentiate daylight or artificial light. In my opinion they can’t. So yes if the environment goes dark again, the light sensor sends its measurement saying it is dark and the meshbots gets triggered.
So you need to test your logic in your mind first to achieve what you want.
I can suggest adding additional conditions so that logic decides like this:
“If light level is below %50 AND if I didn’t manually set the mode to Bedtime” then turn lights on.
And the second part about variables: the same logic applies there as well. Whenever the variable is changed, then meshbot gets triggered. and in the comparison, you compare the variable to “True” then meshbot runs.
We planned to add options like , “Run this meshbot only once in xx timeframe” but not added this feature yet.
Hi @BillC The meshbots get triggered when the nodes in the trigger section are changed in any way. So once a meshbot is triggered, it does not keep triggering.
I think this is an important point to be underscored. An electrical engineer would call this edge triggered vs level triggered. The condition is triggered on the leading edge of a state change on one of the inputs evaluated, once and only once per state change. It also means it will not be retriggered if the inputs remain stable and do not change even if that remains a triggered state.
Hysteresis is a concept where something triggers at one level in one direction (declining) and at a different level in the other direction (rising). Sometimes called a window comparator. It is helpful to avoid spurious triggering around a single value if when the sensor value hovers around a single point trigger value and pops above and below such that it might cause frequent spurious triggering. By adding hysteresis you avoid some of that false tripping.
Instead of hardcoding the meshbot to a <=50, code to <= a variable (tripPoint). Start the variable at say 50. When it triggers the first time your now change the variable (tripPoint) to say 65 so that the level has to rise up above 65 before it “untrips”. When it eventually does rise about 65 then the threshold is set back to 50 for the reverse direction. This creates a guard band (or hysteresis window) of 15 (65-50) that might mask false tripping.
Anyway its just a thought. You have to experiment what amount of guard band you need.
Gotcha. Had to think back to my electronics knowledge from too long ago for that concept in another context.
Would it also work to just do an “and” with checking if the first device turned on is already on? I had it that way and at one point it seemed like it would trigger and stop itself. Which didn’t make sense but I took it out anyway. I wasn’t sure how the meshbot was working internally.