After switching to the Z-Wave JS Server I have found the UI state of the dimmer does not track the hardware like it did in Zwave 1.4 where I had this in configuration.yaml:
zwave:
usb_path: /dev/ttyACM0
network_key: !secret zwave_key
polling_interval: 30000
# device_config:
light.ge_12724_3way_dimmer_switch_level: # Added to keep HA in sync after manual override
refresh_value: true #refresh the brightness value if the dimmer do "soft off"
delay: 2 #Amount of seconds before the refresh is done after the actual action.
#Polls the device when each (polling_intensity) polling is performed by polling_interval
polling_intensity: 1
I think I need to enable refresh and change the rate. Just for fun I tried the Z-Wave JS to MQTT" add-on. There were additional node configurations available but not for polling or refresh. I ended up uninstalling it because it slowed down the response of my Zwave switches.
How can I set the refresh parameters in Z-Wave JS Server ?
If you don’t want to use zwavejs2mqtt to poll, you can create a time-based automation in HA that calls the zwave_js.refresh_value service call, using the light entity.
I ended up uninstalling it because it slowed down the response of my Zwave switches.
This is strange, running the zwavejs2mqtt addon, especially with the MQTT gateway disabled, is nearly identical to using the ZWave-JS addon. There aren’t any differences that should cause a performance problem.
This restores the UI response to the GE Dimmer without using another Add-On. I thought that running an automation every 2 seconds might be a strain on something.
Unix top command showing 1% CPU utilization. Hopefully, this doesn’t cause battery drain on my Z-Wave lock.
Edit:
To prevent a Zwave JS Server error message that showed up at startup I added, using a text editor, initial_state: false to the above automation and added this action, after a delay of 10 minutes (could be less), to my HA startup automation:
2 seconds is very excessive. Your configuration from zwave was every 30 seconds in comparison. Polling is generally bad, it should be avoided as much as possible. If you start to see problems, the first thing to revert would be this.
Just to chime in here, I also had this issue. I did not like the idea of either the polling solution, nor to have the device constantly refreshing, so I managed to get an automation working that basically runs a refresh on a device that has this problem of getting out of sync with the UI due to the dimming lag. Most of my ge / jasco dimmers and fan controls were suffering from this and it was a bit of a pain to add one automation for each affected device, but it works and seems to be more efficient than polling or constantly refreshing. Here is an example of the automation:
Did you actually observe a problem, and notice that your automation solves it? It doesn’t quite make sense to me. Your automation is triggering off of a state change, which means it would be run after the driver has already notified HA about the switch’s new state. The driver does an automatic refresh after 5 seconds. Are you using transitions longer than 5 seconds?
I’ve worked with ge switches a lot when I was on Smartthings and updated the device handlers for them. An odd quirk found is that if you set parameter 19 for “alternate exclusion” to yes or 1, it removes the delay and provides instant status updates. I think this is because you normally include/exclude the switches with a single tap, but alternate exclusion requires two times on and two times off for inclusion/exclusion. This then makes the device instantly know its an on/off and not an inclusion/exclusion when you tap the switch.
I don’t think parameter 19 shows up in the default parameters for these switches in zwavejs but you can set it manually. Also depends on how old the switch is if it had this parameter- they’ve had multiple versions of the switch and reliable status on the older ones could only be obtained with polling .
This in reference to status updates from physically operating the switch, not from zwave commands, right?
Is it supposed to work in this way?
Param 19 == 0 → Turn switch on, level is reported after dim level fully ramps
Param 19 == 1 → Turn switch on, level is reported immediately, before dim level fully ramps
I tried it on my 14294 dimmer switch, with firmware version 5.26. The config setting can be set, however I don’t notice any change in behavior with the status updates when toggling the switch. The level is reported after the switch has completed the dim level ramping, whether parameter 19 is set to 0 or 1. Maybe this version of the switch is too old.
Regardless, I like the idea of enabling this parameter to avoid accidental device exclusions, thanks! (although I’m hesitant to actually test it )
Yes changing the alternate exclusion to 1 is supposed to make status updates at the switch from manual control quicker.
It reports the on/off status instantly, not 100% sure on the dim level might take a moment because these switches have the annoying ramping that you can’t get rid of. I’ll check when I get home.
I’m afraid that is probably an older switch without the alternate exclusion parameter. Do your parameters match these Product Configuration Capabilities ? If so they are older and it probably won’t work.
This is nice to set if you upgrade. For me with little kids in the house and tinkering with zwave devices a lot I’ve had my share of “accidental exclusions” before setting it.
I did test with other parameters. For example, a GET for a nonsense parameter 50 does get a response, it just reports 0. Setting parameter 50 to 1 does not result in a report value of 1.
Unfortunately sometimes they set but don’t actually do anything. But I might be mixing up the model numbers, these are tough to keep track of and they have a lot of “in between” versions with a hybrid of old and new settings. Jascos documentation and version tracking is a mess. It doesn’t help they reused the model numbers for some too. But it’s definitely worth playing around with the settings to get what you want at the device/firmware level vs an automation if it’s possible.
I had to do this because I was not seeing the automatic refresh after 5 seconds on any of these dimmer devices. I’ve got something like 10-15 dimmers in the house and none of them would correctly reflect their state in the UI if I manually turned them off. I did migrate from SmartThings as @mwav3 suggested so perhaps my dimmers have their parameters set to prevent this 5 second refresh?
That is the first generation Zwave switch from jasco and it does not have many command classes or configuration settings to offer. It’s not zwave plus and doesn’t even offer a basic set report. Smartthings had an arrangement with jasco for these switches to use proprietary code for instant status on Smartthings. On other hubs though, the only way to get status is with poling, and with 10-15 in your case that’s less then ideal and will create a lot of zwave traffic.
Another option is to actually leave just those switches on Smartthings, so you get that instant status, and control them in Home Assistant using the Smartthings integration
I’m surprised you have so many still. These have a high failure rate due to a faulty capacitor. They usually fail to come back online after power is cut to them, either by an outage or flipping the breaker. The newer jasco/enbrighten line are much more reliable if you want to slowly upgrade them to zwave plus at some point. The newest ones also offer instant status on zwavejs, associations, and double/triple tap actions.
FYI - that was true of the switches (I’ve had several go bad after a power outage) the dimmers don’t suffer from the same issue, I assume because of the SSR instead of the on/off relay. unfortunately for me, I have a house full of them and it’s cost prohibitive to replace them all just to get instant notifications. So I poll most lights every minute and the ones I don’t care about 2-3 minutes. that seems to work okay for me.
That spaced out polling sounds good with a minute at a minimum. Some were doing it every few seconds and were really having problems. Now that you mention it the ones I had fail were switches vs dimmers. The relay would have the “click of death” when the capacitor failed. Glad the dimmers are still holding on for you.
)