I have problems every once in a while with a rule not firing. I've tried this a couple times, once on an app to turn on a kitchen switch (made duplicate rule) and once on a garage door app (created a duplicate 'door'). Both devices are z-wave.
It seems to work, but it's hard to tell?
Anyone else try this? Opinions?
Have you confirmed by reviewing the logs that it is the rule not firing and not the hub failing to contact the device to command the action? I can't recall ever seeing a properly written rule fail to fire.
Maybe I should've reworded to say that the light didn't turn on as it should. From past experience, I do believe it's the light's switch not getting the message.
So, any opinion on doubling up on the rule? Helps in getting the message through?
I suppose as a band-aid but the real problem is the signal is not reliably getting through to the switch.
You might try something like:
[do whatever again]
This is a bad idea. Don't go down this path. Instead, figure out what the underlying problem is and fix it. Most likely there is a weak mesh, and bashing it with doubled commands is only going to make it worse!
@velvetfoot This applies to you. You have to solve the underlying issue, not bashing your mesh with duplicate commands.
I've got *loads of zwave switches and zigbee outlets. The hub is like 20 feet away. I don't think it's a bad idea if it works. The intermittent nature make it hard to see if it works.
With the z-wave contact sensor spamming issue a little while ago, it took a couple months for you guys to straighten that out. I was bitching and moaning the whole time. I wound up doing a hard reset, blah blah blah. I ain't going down that road again.
This is very intermittent. Doubling up on a couple simple rules may help. I'm wondering if it helped anyone else.
I'll be the dissenting voice (shocking, I know). I have a super strong zwave mesh - but I have a device or two that seem to just not get the command every once in a while. Rare, but it happens on occasion. And when it does happen it is quite annoying as it is a prominent device in a prominent location.
As it is very important that message gets there in this case, I send the command 3x with 5s in between.
Here's one of them. 55 neighbors, good RSSI, low PER... You tell me why sometimes the command doesn't "get there"/"take effect". Maybe the device is flaky? Maybe it is dying? Maybe the hub never sent the command? Don't know, I'll look at it someday, but for now I'll repeat the commands - 100% reliable since doing so... So...
@ JasonJoel Of course. While the preferred course would be to find the original problem and fix it, that's not always doable, given time and $$$ and the death glare from She Who Must Be Obeyed, who just wants the damn thing to work.
May I ask, how do you do that? I'd like to try that as well.
I do all my logic in Node-RED, so it wouldn't be applicable to RM.
But, if I were to do it in RM I would do like what was posted above... Command, delay X sec, command, etc.
I guess I'll check out RM.
Maybe instead of
[do whatever again]
If [whatever was supposed to happened] = false
[do whatever again]
I would be worried that do loop could create a storm of traffic. The delay or wait modulates the potential traffic.
I'm not proposing a do Loop, if that was directed at me. Although, I do something like this in a repeat sequence.
I have energy data that I send to virtual sensors across the hub mesh. For some reason the data sometimes does not update. After I send the data I then read back from the sensor to see if it updated and if not I wait 15 seconds and send it again. Its set for 5 repeats but it will usually do it first time, but every now then it will take two or three times before it updates..
This is not a lot of data that is being sent quickly it's hourly, daily, and monthly energy data.
I once asked the forum if the status of a device changes based on the device actually physically changing or if the status of a device is changed solely based on a command in HE changing the device. Another way to state this question is as follows:
What of the two scenarios below is correct, for a light that is off and its current HE status is "off"
Automation to turn light on is initiated -> HE Light Status is updated to "ON" -> HE sends zwave/zigbee command to turn light on -> Light turns on if it received the zwave/zigbee command or stays off it it didn't. Either way the HE status is now "ON"
Automation to turn light on is initiated -> HE sends zwave/zigbee command to turn light on -> Light receives command to turn on and turns on -> Light communicates back to the hub that it received the command and turned itself on -> HE updates light status to "ON"
The answer to my question was it depends on the driver, and either of the two are possible. Therefore, for this reason, I would not try this:
That works if the driver updates status based on the report and not the issued command.
Many drivers do the sendEvent in the hub as soon as the hub command is sent, not based on the report back from the device. In those cases checking status doesn't help, and will actually prevent the command from being re-sent when you want it to.
EDIT: I should have read @stephan_j post. He said basically the same thing. LOL
I'm actually going back and changing most of my drivers to only update status on the report. It makes dashboards, etc, update slower (as it has to wait for the device to report back), but mostly prevents any chance for status mismatch.