Zwave: On vs Off vs Level

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.

According that other thread, it was broken in HA 0.67.0, but fixed in 0.67.1. (And that’s consistent with my experience)

What is the difference between local 7, 8 / 9,10 / 11, 12?

I think I understand 9 and 10 are just for dimming up and down without turning on or off, but 7/8 and 11/12? What is ALL (all my zwave dimmers?)

ALL is just tapping up to turn on and tapping down to turn off.

Dim Step - How much to dim the light per rate
Dim Rate - How long to wait between steps

Local means holding the button down to dim/brighten.
Command is via zwave.

1 Like

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:

http://www.ezzwave.com/advanced-operation/?_ga=2.140999666.1754055866.1524765844-760535922.1519246212

Hi @ha_steve & @psfales!

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. :slight_smile:

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 :wink:) 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.

2 Likes

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. :slight_smile:)

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.

I have two 12727’s, each with an add-on, and they both act this way. I also, for a short time, used one of the add-on’s with a newer 14292, and it acted the same way, too. Do you have polling set for your 14291, and if so, how often is it polled? Could that be why it updates? (My 12727’s update, eventually, when switched from the add-on only because I have polling set for them now.) If you don’t have polling, then maybe yours has newer firmware than mine or something. Hmm…

I have no polling setup on the 14291s I do have polling on my GE 12724 3-Way Dimmer Switch. The 14291 switches are zWave Plus so they shouldn’t need polling enabled.

Yep, the 14291 is also Z-Wave Plus and I don’t have polling set up for it either. Well, this is weird. I wonder if it’s a firmware version difference. Maybe yours has newer firmware??? Oh well.

¯\_(ツ)_/¯ bought it from Lowe’s that way.

Hey Steve,

Is there anywhere we could find a list of switches that did license that patent?

I think the patent has expired a few years ago, but i don’t know for sure (I bought all of my Z-wave switched in 2013, so long before Z-wave Plus even.

It’d suck to have to pay to buy all new switches. Maybe we can flash our devices somehow.

What problem are you trying to solve? If you have switches that you need to have ‘polled’ occasionally because they are too far away to get the broadcast message to the hub, you can set that up on an individual switch basis. Just put the polling_intensity: 1 in your zwave component config for the devices you want to have polled.

zwave:
  usb_path: /dev/ttyUSB0
  network_key: !secret zwave_network_key
  device_config:
    light.living_room_lights:
      refresh_value: true
      delay: 2
      polling_intensity: 1

I found this pretty annoying when I first started with HA. Now I honestly rarely ever notice. Do you actually use the app for all controls? Not that that’s a bad thing just curious. I find that most my lights are controlled with Alexa/google home, or just automations.