Can someone help me understand the relationship between on/off and brightness level for zwave lights?
If I want it to come on at full brightness, do I need to make sure to set the level to 255? Strangely, if
set it to some other level, it comes on at some intermediate value different from what I set. For example,
if I ask for a level of “200” what I actually get is a level of “154”
Most puzzlingly, if the light is on, and I tell it to light.turn_off, it appears (visibly) to go off, but according the
UI it goes to some “half-on” level like “85” with state=on. So, even though it appears to be off, I have to send it another light.turn_off to actually get the UI to reflect that the light state=off
I dont’ have much experience with zwave. Is that the expected behavior? If not, any suggestions on how to debug it? If it matters, my new zwave light is a GE toggle dimmer, model 12729
This is because, due to a patent that GE didn’t pay to license, those switches do not send out “status” updates - they have to be polled. So when you send a command, HA then has to come back and poll the switch to get it’s current state. The default dim/ramp rate for the GE switches is a little slow and so when HA polls, it hasn’t quite reached the commanded target.
So, what you do is in your zwave: composnent in your configuration.yaml file is you set the refresh_value: true then delay: to how ling HA should wait before asking the switch for its current state. Here’s an excerpt from mine:
zwave:
usb_path: /dev/ttyUSB0
# add refresh delays for the GE dimmers
device_config:
light.living_room_lights:
refresh_value: true
delay: 2
I also changed the ramp rate through the Z-wave config panel so it’s faster. If you have left them at their out-of-the-box values, then you might want to make that 3s as I believe their default settings have them doing single-steps at 10ms intervals (so going from 0 to 255 - off to full brightness - would take 2.55s).
Can you expand a little more on that last paragraph? By the changing the ramp rate through the “Z-wave config panel” are you referring to ozwcp, or something in the HA GUI? If it’s the latter, I could not figure out how to do it. If the default value is 10, what do you recommend changing it to?
In the HA GUI, Go to Configuration->Z-Wave, then under Nodes, select one of your GE Dimmers. Then scroll down to where it says Node Configuration Options. There you should see something like: .
You can see the Dim Step and Dim Rate options there. Dim Rate is how many 10’s of milliseconds to wait between steps, and Dim Step is how many levels it “jumps” at each step.
For example, if the Dim Step is 1 and the Dim Rate is 1, that means every 10 ms, it will change the level by 1 to go from where it is to where you commanded it. So, 10ms * 255 steps = 2.55s to go the full range.
If you set the Dim Step to 5 and leave the Dim Rate at 1, that means ever 10ms, it will change the level by 5, so it will take 51 steps at 10ms each to go from 0 to 255, or 0.51 seconds (so 5x faster).
You can set these differently for “local control” - that is, someone physically touching the switch - or “command” which is when a z-wave command sets the level.
Thanks for the detailed response, but for some reason, that’s not working for me. After I select the node, it activates the drop-down menu for “Entitiies of this node” (which only has one entry) and “Node Values” (which also has only one entry in the list), and under “Node Information” the “Show” button gives a bunch of statistics about the dimmer. But “Node Group Associations” and “Config Options” are greyed-out and don’t appear to do anything.
Hmm, I don’t know if this is significant, but in ozwcp, I can select “Current Values” (to adjust the brightness of the dimmer) or “Information” (which shows things like version numbers and power levels), but if I select “Configuration”, nothing is shown (that area of the screen is blank)
Don’t know… weird that it doesn’t show up for you in Home Assistant’s z-wave configuration tool. I have three of the GE dimmer switch and I’m able to adjust them as shown above.
Well, this is weird! I had a need to re-build my HA system recently (I was upgrading from a Raspberry Pi 3B to a a 3B-plus and a copy of the old SD card would not boot). So, even though I reinstalled everything from scratch, I thought was just installing the same version of HA, the same version of python, the same version of open-zwave, etc. But when I was done, the zwave config panel was working! I have no idea why, but I was able to change the step rate in the GE dimmers! Thanks for your help!
Update (about 8 hours later)… After further reflection, I think there may be a difference between the version of open-zwave that I used in the old system (a downloaded tarball of openzwave-1.4.164) and the version I used in the new system (a git clone of the current release code which calls itself version 1.5). I have not verified for sure that this is the reason for the improved behavior, but I think it’s a plausible hypothesis.
I believe 11 & 12 are for All On and All Off commands. I don’t know much about it, but I suspect those are special Z-Wave commands??? Anyway, for GE/Jasco devices, you can check out:
First, ha_steve, thanks for the explanation of how the zwave’s refresh_value & delay parameters work! Until I ran across this I couldn’t figure out what was going on in my setup and I ended up turning polling on for everything. Now I’ve been able to turn that back off, and for my one dimmer that turns on & off slowly, I can get HA to update correctly/promptly.
After reading this (and other related topics) I decided to spend some time digging into the details (browsing code, etc.) It turned out to be a bit more complex than I expected, but now that I understand it, it makes perfect sense. I wrote up what I found (a bit long winded, but it is a bit complex ) here:
Lastly, when calculating the times from the config params (as I explain in the linked topic), the total number of steps is 99, not 255. So the default values of step=1 and rate=3 translates to 2.97 sec ((99/1)*3*10msec.)
FWIW, I found yet another less than optimal behavior of my GE/Jasco switches. If you use an add-on switch (to make a 3-way, 4-way, etc. configuration), when changing the state of the switch via the switch itself, it will update HA immediately. (Not sure the exact mechanism, but all I know is, HA will see the change immediately.) But, when changing the state of the switch via the add-on switch, HA doesn’t get informed, so if polling is off, it will never update (at least not until the actual switch is changed or HA tries to change it.) So, bottom line, I had to turn polling back on for any switch that uses an add-on switch.
@pnbruckner - not sure why you are seeing that, but I can shed some light on the behavior:
Because of a patent that some company other than GE/Jasco held, they could not implement “instant update” - that is, if you manually flipped the switch, in order for the switch to initiate a status update to the hub (Home Assistant in this case) they would have had to pay a fee to do it.
As a workaround, when the switch is manually flipped, the switch sends out a network “broadcast message” - when most z-wave hubs see that, they turn around a poll the switch for a status update. Since all of this is really fast, it looks like the switch is instantly updating.
However, a broadcast message is NOT routable by the z-wave mesh network. So in other words, if the switch in question cannot be “heard” by the z-wave controller directly, and messages usually get routed through another z-wave device closer to the hub, then the broadcast message will not be forwarded by the closer switch and the hub will not get the broadcast message and therefore will no poll the switch for a status update.
Dunno if this helps you in any way, but I do have a couple of switches that are in a guest-house detached from my main house and they do not instant-update for this reason, so they have to be polled.
That… explains alot of stuf I did not understand. Thank you for teaching me something important today! This makes me even happier that i split my zwave network in 3 small pieces…
@ha_steve, thanks, I didn’t know those details about broadcast messages not being routable. I’ll have to keep that in mind.
But, for what it’s worth, that’s not the issue here. I probably didn’t explain myself very well. GE/Jasco makes Z-Wave switches, and they also make Add-on switches that work in conjunction with the Z-Wave switches to enable 3-way, 4-way, etc. switch configurations. The Add-on switches are “dumb.” They do not have Z-Wave radios. They just have a simple wire that goes back to the Z-Wave switch. Think of them as extensions to the physical toggle or rocker. They just tell the Z-Wave switch to turn the load on or off. Therefore, the Z-Wave switch should be able to do the same thing no matter whether its own physical toggle/rocker is pushed or the Add-on switch’s is. But, sadly, they don’t.
Oh, and also, it’s the same thing with their newer Z-Wave Plus switch, which should not be limited by that patent issue, and I’m pretty sure isn’t. But, still, it doesn’t broadcast or otherwise update the controller (& HA) if the load is changed via an Add-on switch like it does when its own switch is pushed. This makes absolutely no sense to me (and I’ve been an embedded software developer for 40 years. )
I posted my original comment on this topic of the GE/Jasco Add-on switches to try to warn others that might be thinking of using them. It’s not the end of the world (since polling can resolve the problem), but it is something to consider or at least be aware of.
I have an addon switch connected to a GE/Jasco switch for my stair lights. One at the top of the stairs (the main switch with the radio, addon at the bottom) when I toggle either the addon or the main switch, it updates fine in HA. What model switch are you working with?
I’m using a GE 14291 In-Wall Smart Switch for the stairs.