Simple Rule app response flakiness redux

Hi all,

Well it's been a while and this situation is still not working as well as I might like. I've changed nothing in the system config in all this time.

To refresh on what's going on:

We have a water circulator on a Leviton outlet. There are two different button panels and a timer that can operate this. Then there are two lights (one on a Leviton outlet, the other on a Jasco dimmer). These are slaved to the circulator by an app that tuns them on when the circulator on and off/off.

The circulator turns on most of the time. The lights are more flaky. An example is today:

Timer went off at 6:56AM
Circulator turned on
App fired
Jasco light turned on, but Event list claimed that it did not.
Leviton light turned on and said that it had

Turned off via one wall switch
App triggered
Circulator turned off
Neither light turned off, nor claimed that they had

Turned on again via other switch
Circulator came on
app triggered
Jasco light got on event, stayed on
Leviton light records no event, stayed on

Turned off via second switch
Everybody worked as expected

Nothing else int eh entire network flakes at all these days. Just this.

Looking for ideas on what to try to get this to be more reliable.

I've reached out to Hubitat several times, but no response.

Thanks for any thoughts/ideas.

Cheers.

You probably have Z-Wave mesh problems, and some Leviton devices are known to have pretty poor Z-Wave behavior. Think about it this way, if it works sometimes but not others, it's not the app, it has to be the device. What's between the hub and device: the Z-Wave mesh.

1 Like

Thanks for the reply.

The hub is reasonably centrally-located within the mesh and connectivity has been good in the past. I haven't checked the stats lately, but nothing has changed.

The circulator, which is the farthest away item, is on a Leviton and it works more reliably. I have an espresso machine on a Leviton that is 100% reliable from switch and app.

Also, I was wrong about the smart outlet. it is Minoston and not Leviton (the dimmer is still jasco).

Also, the Minoston switch also connects to another app (a timer) at holiday times and is 100% solid.

It seems only this app that links the behavior of these devices (the two lights) to the behavior of the Circulator that is flaky. All time-based apps work very reliably including, as I mentioned, one that controls the same switch that is flaking out with this particular app.

Given all this, it seems a stretch that the devices (both of them) are the issue and this one particular app (different from the other apps) is working as expected. If this particular app were, for example, reporting that it is sending signals and not sending them reliably, that would have the same behavior as well.

Finally, if I just go to the devices and turn them on/off from the Dashboard, that works every single time with no fail. so the devices seem pretty solid.

Cheers.

Hi all,

Coming back to this yet again to see if there might be any new suggestions. The situation is pretty much the same in terms of flakiness and failure rate.

Summarizing the situation:

We have a water circulator on a Leviton switch. This is controlled by switches and a Simple Automation Rule timer. Because this is in a little side room of the garage, we have two lights as indicators of whether this is on.

The way this is supposed to work:

When the circulator turns on it triggers a Simple Automation Rule to turn on the lights, and vice versa. And it works like 90% of the time maybe a bit more or less at times.

Usually the circulator (the furthest item from the Hub) turns on even when the lights fail when I go out to check. The lights just don't activate. Most of these times the rule trips and says it turned them on. They just don't.

When controlled directly from the Hub, the lights are 100% reliable. I've run a number of experiments and these are rock solid,. So it really doesn't seem like mesh issues. They simply work.

Somehow the loop: push button -> turn on circulator -> inform Hub -> trigger app -> tell lights to turn on -> turn on lights

fails to work properly a fair percentage in the last steps. It's as if the app says it command the lights and just doesn't.

I.m still on 2.3.0.124 as past upgrades made it worse, and I think I may not be able to go back this far if I did upgrade.

I've contacted Hubitat support several times, but they never respond, so that's out.

Any additional thoughts are welcome. "Grin and bear it" is all I've got now :slightly_smiling_face:

Cheers.

Might try putting a small delay (50-100ms) between the commands, may be briefly overwhelming the mesh.

1 Like

Thanks for the suggestion. I think I'd have to go to Rule Machine for this as I don't believe that Simple Rules supports delays. I had done something similar previously with a multiple-try rule incorporating delays between tries, but that didn't help. Worth trying again.

The rule on;y has one command: Turn on/off lights to follow the other switch. I could put a delay right at the start to separate it in time from the initial turn on of the circulator, let that settle. Then I could separate the turning on of the two lights with a delay (not sure how the Hub sequences multiple events that have the same trigger under Simple Rules).

Those are really the only places I can add delays to separate events.

Cheers.

OK, at long last back to respond to this. Thanks to @thebearmay for the suggestion. Short version is that this seems to be working.

Adding more detail of the process in case it may be helpful down the road. It does seem that Hubitat does not serialize commands and it will try to send things "all at once" if the users requests that, with no handshake in between.

I did not see a way to out a sub-second delay in the Rule machine, so I used a few seconds. After receiving the "the circulator has turned on/off" I added a small delay. Then the first light, small delay and the second.

I noticed that the first light would routinely take 20-30 seconds or so to actually turn on (more on that later). I put in an event delay with a timeout. Sometimes it did time out, but the second light turned on and the first one eventually did, so I realized that the wait was not needed. It seemed to work, albeit with a longer-then-expected delay sometimes.

Cheers.

Getting back to the delay, this was surprising to me as there is a repeater about 18' away in the same room. Sometimes HE routed through this, sometimes more circuitous routes. I honestly don't know what logic Hubitat uses to plan routes. it will periodically take a strong connection and reroute to make it weaker in terms of data rate.

Wish there were a way to guide this a bit.

So, I got a Ring Alarm kit. This came with a repeater. The Ring base seems to have a more robust Z-Wave system than Hubitat and the repeater was not needed on that network. So I added this in the same living room area.

About 15' from repeater_1 to repeater_2 and 13 from repeater_2 to light. This is based on where the plugs are and a triangle, so not ideal.

But, with this, light #1 turns on/off quickly/repeatably. Not sure why this should be and why this added repeater helps that much even though the routing doesn't go through that repeater. More mystery.

In any event, this seems to work. The delay between commands seems to have been the key. The delays are just a system mystery.

Cheers.