Zwave outlet slower than rest

[user85]

Hello, I'm just getting started with zwave devices and home automation. I have a very basic scenario that is causing me grief.

I have a room with 1 zwave plus switch (Leviton), and 3 enbrighten outlets with lamps connected.

I'm planning to add a couple more outlets, and ultimately maybe more switches and outlets in other rooms.

However, I'm noticing some significant delays in turning on/off the outlets after the switch is toggled. One outlet in particular (Dining - north wall - left) pretty much always is a couple (or several) seconds delayed compared to the other two.

Here are example logs, notice the 2 second additional delay from the other outlets turning on until "Dining - north wall - left" finally turns on.

[dev:38]2022-02-03 10:39:44.084 am [info]Dining - north wall - left was turned on

[dev:38]2022-02-03 10:39:44.078 am [debug]parse:zw device: 0B, command: 2503, payload: FF , isMulticast: false

[dev:36]2022-02-03 10:39:42.919 am [info]Dining - east wall was turned on

[dev:36]2022-02-03 10:39:42.916 am [debug]parse:zw device: 09, command: 2503, payload: FF , isMulticast: false

[dev:37]2022-02-03 10:39:39.942 am [info]Dining - north wall - right was turned on

[dev:37]2022-02-03 10:39:39.939 am [debug]parse:zw device: 0A, command: 2503, payload: FF , isMulticast: false

[dev:36]2022-02-03 10:39:39.877 am [info]Dining - east wall was turned on

[dev:36]2022-02-03 10:39:39.860 am [debug]parse:zw device: 09, command: 2503, payload: FF , isMulticast: false

[app:68]2022-02-03 10:39:39.221 am [info]app: When Dining - switch turns on …

[app:68]2022-02-03 10:39:39.217 am [info]app: finished

[dev:38]2022-02-03 10:39:39.207 am [debug]on()

[dev:37]2022-02-03 10:39:39.189 am [debug]on()

[dev:36]2022-02-03 10:39:39.137 am [debug]on()

[app:68]2022-02-03 10:39:39.090 am [info]act: Turn on Dining - east wall, Dining - north wall - right, Dining - north wall - left

[app:68]2022-02-03 10:39:39.080 am [info]evt: Dining - switch switch on

[dev:39]2022-02-03 10:39:38.793 am [info]Dining - switch was turned on [physical]

Are these timestamps of when the command is issued, or when the outlet actually performs/completes the action? In other words, is this delay in the Hubitat, in the outlet, or in transit between the two?

[brad5]

First welcome to the community!

@user85

Are these timestamps of when the command is issued, or when the outlet actually performs/completes the action?

The timestamp is when HE issues the command.

I have a couple of these outlets and they are, as the expression goes, slow as molasses in january. In my use case it's not an issue so I have never tried troubleshooting it. I'm going to take a wild guess (ok, not so wild...) and say you may have a zwave mesh issue going on... Can you post a screen shot of the rule you're using and also of your zwave details page? Are your outlets in metal electrical boxes?

[user85]

I'm trying to attach png screenshots, but it's saying I cannot embed media in post??

The outlets are in metal boxes. The topology is pretty simple since I don't have many devices. Due to the location of the hub, I did need the repeater in order to comfortably reach the devices.

[user85]

making a couple posts so I can post pictures

[user85]

[neonturbo]

That Dining East Wall is at -9db which is practically a whisper. That repeater01 isn't getting that great of a signal either, and the other devices are routing through it.

I would move the hub, reposition the hub upright or upside down even, and maybe play with moving that repeater to see if it enhances the signal at all.

[user85]

What are reasonable RSSI values to shoot for?

What is the antenna radiation pattern on the hub?

[aaiyar]

@user85

What are reasonable RSSI values to shoot for?

I don't know. But I do know that 4 of my 5 repeaters have signals of >30 dB

They all function as repeaters, including the one at 8 dB.

[neonturbo]

@user85

What are reasonable RSSI

@aaiyar

my 5 repeaters have signals of >30 dB

I am not sure officially (per spec) either, but I see most of my best performing devices above 20.

[tony.fleisher]

The z-wave guide (INS12712) says signals > 17db should be good, but the PER (Error rate) and RC (Route changes) are more important.

Also note that repeaters do best with strong signals, so having one half-way (or closer) to the Hub will often do better than putting it next to a device with a low signal.

[neonturbo]

@tony.fleisher

The z-wave guide (INS12712) says signals > 17db should be good, but the PER (Error rate) and RC (Route changes) are more important.

Oooh, I have never seen that graphic before. Great reference, thanks!

[user85]

Well, I was able to move the hub much much closer to the room in question, remove the repeater, and it's a lot better now. The initial responsiveness for all smart outlets is great, and that one particular outlet (dining - north wall - left) is still "slower" than the rest, but just barely, like half a second.

The RSSI values for the devices don't make much sense to me though, a couple are nice and high , but one is -1, and another 0. All working pretty decently though. Does it take more time to update or something?

[bertabcd1234]

@user85

Are these timestamps of when the command is issued, or when the outlet actually performs/completes the action?

You've got a mix of both. The debug logs that show things like on() show when the command was issued from the Hubitat driver. Not all drivers log this, but it appears yours do. (EDITED to add: many apps also have logging options that will show when they send commands to devices, which can be more helpful for figuring out the source and timing.)

The debug logs that show something about parse for Z-Wave show when commands/reports are coming in from the device, which will normally be quickly followed by an info log that shows the event the driver parsed that information into (e.g., "switch is on").

Note also that info logs are on indefinitely by default; debug logs are enabled for 30 minutes after pairing and for 30 minutes if manually enabled before automatically disabling itself (this is convention; community drivers may vary).

[neonturbo]

@user85

Does it take more time to update or something?

Yes. I would leave it overnight and see what happens.

You could also try an individual repair (next to each device in the table) but not a Repair Zwave (the button at the top of the page).

[user85]

for my own knowledge, why not run a Repair Zwave? I like to click that button...

[672southmain]

(1) it causes a storm of packets on your mesh. At present, there is a bug in the SiLabs Z-Wave radio firmware on the 700 chip that can cause the chip to lock up in such a situation. A new version of the Z-Wave radio firmware has been recently released by SiLabs and is being tested, perhaps it will be released to us reasonably soon so we can update our hubs.

(2) doing a full mesh refresh really defeats the ongoing routing algorithm that explores better routes in the background.

[user85]

Thanks for all this great info, guys. It's been a tremendous help for a newbie.