When RM executes the Action portion of the rule, does it go back and verify that the action was done successfully? For example, when it sends a command to turn on a switch, does it go back and make sure the switch is ON? I am thinking that it currently doesn't do that. Can enhancement be made so that it does go back and verify that action did happened? If not, some sort of retry might make the system a lot more robust.
Here is why I am asking for it. I have this rule as a test.
So I modified the rule to run a test. The trigger now is a button on the aeotec minimote.
(normally the trigger is midnight).
When I pushed the button, all of the lights turned OFF except for the Landscape Lights. This one remained ON. I then pushed the button for the second time and now the Landscape Lights turned OFF.
This tell me there is a problem with RM... Please have someone take a look at why this is the case. So almost 1 out of 3 tests it would not turn off landscape lights.
Update: Reran the test again and now everything turned off correctly. About 30% of the time, the landscape light remain ON until i push the button again.
I would suspect that if it works once then RM is working correctly.
The issue is more likely a mesh problem.
The light that doesnāt always respond correctly, is that at the limit of your zigbee or z-wave mesh?
I am not saying that this is the reason for the failure..
Just a possibility.
Turn one light on/off on its own is different to turning off 8-10. There would be significantly more network traffic and if a repeater gets āoverloadedā then it may miss one message.
We don't live in a perfect world so don't expect perfect timing that everything to turn on correctly. There are lots of timing involve so it's always good to have some redundancy.
My opinion is that this is a very bad idea. What a person needs to do is to diagnose what is causing the failure, not put a diaper on it. Once in a while an event is going to get lost -- such is life. If this is happening more frequently, then diagnosis is called for. Most common problem is a poorly put together mesh, or flaky devices in the mesh.
When you say poorly put together mesh what do you mean by that? In my case where my lights didnāt turn off the other night you mentioned the same thing, however my dimmer and motion sensor for at least one of the lights in question is literally 3 feet from my hub. I highly doubt thereās a mesh issue there. As much as Iām loving my Hubitat hub, this is one issue I did not have when I was using my ST hub. All my rules and motion sensors were reliable outside of a cloud issue.
I know Iād be pretty upset if my water leak sensor didnāt turn off because an event āgot lostā and allowed water to flood my house causing thousands of dollars in damage to my home. And the response is āsuch is lifeā. To me thatās not a good enough response. And I mean no disrespect by my comments, but it makes me not trust the platform.
Oddly when I execute this test trigger, it's 100% reliable. RM must be too good and fast for the zwave stick because when it seems to fail at pretty high rate when trying to do more than one light. Redoing my rule to control only one light at a time for now.
So in a scenario where you want every light in your house to turn off when mode goes to away... youād have to have a single rule for away for every light? Doesnāt seem right to me. Something is wrong.
most light has their own shutoff when no motion already so I don't really turn off lights when switching to away mode. I just recently noticed this particular rule behaving this way so just a short term fix for now for me anyway. I am slowly rebuilding my mesh and removing old devices.
All I'm saying is that these technologies, Zigbee and Z-Wave, are not 100% reliable -- and this has nothing to do with Hubitat. Not all of these devices are 100% reliable, and the mesh network technology itself is not 100% reliable. Zigbee is prone to RF interference. The Z-Wave band has its own issues. This is what I meant by "such is life".
To get higher levels of reliability than Zigbee and Z-Wave one would need to invest in higher quality technologies. Lutron radios used in their systems have a higher level of reliability due to a number of factors, including the use of licensed spectrum and radio network architecture. But, Lutron systems are much more expensive than Zigbee and Z-Wave. You get what you pay for. For most home automation applications, Zigbee and Z-Wave are adequate, and perform fairly well, but not perfectly. It is unreasonable to expect perfect performance from these technologies.
What I'm describing is not a factor of the Hubitat platform.
If you are having issues with a light turning on that's close to the hub, that definitely bears some investigation as to what's going on. Not knowing any of your details, I'm not in a position to tell you what to do about it. I'd test the heck out of it, try to determine and isolate the conditions under which it fails.
I think what Iām getting at is for me the only thing that has changed in my environment is the hub. I was using the same sensors in ST as I am in Hubitat. Yet my experience on Hubitat is less reliable then when I was on ST. I want to stay with Hubitat because of the local processing, Iād just like to find out why Hubitat is less reliable and work with someone to fix it.
Keep in mind my environment is extremely small currently. I am remodeling my house and adding devices as I go. I have less then 5 motion sensors and about 20 summers / switches.
