You might try something like:
[do whatever]
Delay 0:00:01
[do whatever again]Is that RM or what?
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.
2 Likes
yeah, ok
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...
2 Likes
@ 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.
3 Likes
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.
1 Like
I guess I'll check out RM.
Maybe instead of
[do whatever]
Delay 0:00:01
[do whatever again]
[do whatever]
If [whatever was supposed to happened] = false
delay
[do whatever again]
end if
1 Like
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.
1 Like
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
1 Like
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.
I was thinking of the scenario I listed above and you're probably right for the state of a switch it's probably not helpful.
1 Like
Ah! I went back and re-read your post and I get what you were saying. Sorry about that.
Most of the bases have been covered here, so I will just add my personal approach for Z-Wave:
- Use compatible devices. Of the 2 Z-Wave devices that misbehave in my network, 1 is explicitly not compatible with C7 and the other is not yet on the compatible list.
- A small amount of troubleshooting may help to validate a quick-and-dirty band-aid. The 2 devices that I mentioned took a long time to update switch state. Repeatedly sending the same command would just be ignored if it thought it was already in the commanded state. It made more sense for me to send a refresh command a bit before or after a change.
As someone who uses Hubitat to control my HVAC, I am very concerned about the occasional missed message. I have a routine that runs periodically, like every 10-15 minutes, and re-commands the devices to the desired states. This is effective for me, at least with the devices and drivers I am using. It avoids something being in the wrong state for very long. I suppose this strategy could fail if the drivers assume the commands they issue are received and they don't re-send commands when they think the state is not changing.
