Exactly correct. The associations are stored on the device and then the hub has no role after they are set. The issue with ZwaveJS appears to be with commands related to settings the associations. So once they are set they will work regardless of the gateway on the hub.
2 Likes
I'm going to mark this as solution since this did the trick - Thanks! It kinda would be nice in the future to have all JS, but I think for time being I may just leave the hub in legacy mode. I've noticed a few other things like current states (not just for the Zen34 but other devices) don't seem to report reliably in JS mode ~ yet anyway. I imagine there may be some driver and/or UI enhancements needed to fully appreciate the migration. Like I don't know enough about the underlying technology to speak intelligently about this but does ZwaveJS even use groovy drivers or does it rely on json?
The goal with Z-Wave JS is to not require any changes to drivers (at least not ones that were using the standard Z-Wave classes the hub provides as opposed to parsing the hex manually, which is pretty rare). So, yes, still Groovy, though the "raw" data that comes in for parsing is now JSON (but, like the old hex string, normally not something you should deal with directly, and certainly not if you want compatibility with the old Z-Wave stack).
What problems have you noticed with the ZEN34, outside of the Association Set issue mentioned above (which would affect any driver trying to use this command)?
What kind of UI enhancements are you thinking? As for drivers, most "driver" issues so far have been something in the underlying Z-Wave class, but it does appear there are still a few to be worked out. Most were done before beta, and several more were caught during.
It uses the same drivers and that is where some of the issues are coming from. To be backwards compatible they had to rebuild all the parsing methods to accept the ZwaveJS data and parse it into the expected format. A lot of issues like this were caught in beta but I guess we did not test setting associations at all.
I wasn't trying to say I was having other operational problems with the Zen34 - just status display issues (and not necessarily your driver, actually I had switched back to built in - and now back to the one form Zooz) and I was saying that I was getting this on other devices... like plugs - where I may ask Alexa to turn on or off an it would work, but status wasn't refreshing in device page and changing from on-off-on in device page would do anything... I sometimes I might go to zwave status some would show pending even though they had a check box previously . Just stuff like that ~ minor inconsistencies. When I mentioned driver or UI enhancements I was just speculating maybe there was more to come before current states & variables were consistent with legacy zwave. Not that I was asking for anything specific.
What status? (Just trying to figure out what the actual problem is.)
I'll have to try do some before and after ~ maybe take some screen shots and then switch back to JS and compare - sorry I dont have specific examples to share
Sounds good! I was curious for two reasons. The first is that you'll get button events from taps (pushes), holds, and releases, and I suppose once in a while you'll have things like battery reports -- but there isn't much in the way of "status" for these things besides whatever events/attribute changes you might see from those. The other is that I was not aware (and am still not) of any problems with this device or any driver you might use with it, beyond, again, the Association Set problems from above that traces back to the new Z-Wave JS implementation.
Just switched back to JS - and so far everything looks good, same status and state variables as legacy. Even batteries devices that were a little erratic seem to be more consistent now.
So far the only thing I see off (someone mentioned this elsewhere too) zwave graph doesn’t register anything as a repeater.
