Are you running HassOS ?
Yes, on Intel NUC
Ok, then it will be difficult to make the changeover without the initial hand holding you did when you migrated to zwave-js.
basically, there are cache files that store what has currently been found for all your nodes. That’s a file that’s stored in HassOS. Unfortunately, you don’t have access to it on HassOS. When you make the switch to ZwaveJS2MQTT you can give it the cache file and it’ll just run with it. However, because you don’t have access to it, you’ll have to let it create the cache file. Meaning you’ll have to let it do it’s thing until it finds all the info for each node.
Whatever you do, don’t delete the integration. That’ has all your names (if you renamed). If you didn’t rename, go ahead and just start over because that’s really the only important thing when changing between the 2.
Should I switch? I’d prefer not using MQTT, if we’re going to get tooling with this add-on eventually, I’ll just be patient.
Thanks as always petro.
That’s up to you. You won’t be using MQTT. I suggest you take a look at the community guide section, there’s a zwave overview that describes how each zwave method works. ZwaveJS2MQTT can be ran 2 ways, with or without MQTT.
Which is a brillliant post by the way ! Very informative :
You’ll want to enable the sensors:
They are disabled by default.
I was able to enable those. I did switch to the other addon.
However, I’m not getting any events from the locks at all, it appears. Their state isn’t properly represented in Lovelace or otherwise. They work when sent a lock or unlock command.
I tried excluding and repairing, now I can’t get the thing to work at all. The interview completes, but details are omitted and I cannot use the lock anymore. I’ve made myself worse off trying to solve it. Though I’m using secure pairing, it’s registering as a No for secured.
Factory reset and repaired, and got all the entities back, but it’s still not reporting the status back or anything at all. All my locks are not working on the zwavejs2mqtt without mqtt. I’m gonna restore my snapshot and patchup the node that’s been excluded/included and be patient with the UI missing.
I think we are still waiting on the HA side to update the integration. I can see those entities for my lock as well. But they are listed as “This entity is not currently available” when clicked on.
I could actually enable those entities on zwavejs2mqtt (sans mqtt), but state reporting from the lock was not working. I reverted back to vanilla zwavejs addon. They’re still slow to report and missing attributes and data, but they’re working.
ZwaveJS2MQTT is ahead of the integration. As @b1g_bake said, you’re waiting on the integration to move forward on the next release.
Curiosity I have just noticed. When I restored my snapshot, the zwavejs2mqtt addon stayed in place. Although the other zwavejs addon came back and was enabled, there was a conflict with the radio. I did not notice until this morning, that zwavejs2mqtt is still running my mesh. I’ve never seen a full snapshot leave bits in place. I must’ve missed some happenings.
Which locks are you using ?
I’m using the older (non ZW+) Schlage BE469 and I can see the states change (locked/unlocked by keypad) in ZWaveJS, but the alarmType is not populated / changed in HA.
This worked OK with the old (1.4) depreciated ZWave solution. (not a complaint as I understand that we’re in the early stages of ZWaveJS, just mentioning it as a reference)
Driver Version: 6.4.0
Server Version: 1.0.0-beta.7
I am using a Kwikset 910.
The BE469 uses the NotificationCC v2+ so it’s likely your firmware is much newer than the one Kwikset slapped on this old 910
@firstof9 I’ve experienced a great deal of trouble with these 910s. I agree with you.
@mrMagoo I also had them working in the 1.4 zwave solution. But there were attributes I could query that don’t exist in zwavejs currently. I suspect they’ll come along as the integration/addon matures.
What you are experiencing is the same I experienced over on Hubitat when they went from 1.4 to 1.6. All my Kwikset 888 zwave locks stopped being reliable. I moved to Yale yrd-110 locks and gave up on the kwikset as my home’s security outweighed waiting for the devs to get something fixed (was about 8mos when I threw in the towel). Just an FYI and hope your experience will be better here on HA.
Edit: I also thought you could change the hardware and make those secure Zigbee locks. Just another option.
I did that back when I was using HE. I went back to zwave when I came here.
Has anyone upgraded to ZWaveJS2MQTT 1.4.0?
Running core with docker and the ZWJS2MQTT container (using WS and not MQTT obviously…). Upgraded and lost a few entities in the ZWJS control panel (ones that are a pain to get info restored) and also could not get anything to talk to Home Assistant anymore, even after 30 minutes and some Home Assistant restarts. I downgraded to 1.2.3 (I think I was on 1.2.xx before) and rolled back my config folder and it seems to be coming back and talking now.
EDIT: Looks like an open issue now
EDIT 2: Basically 1.4.0 only works with the in the process of being released Home Assistant beta and forward.
I started migrating to zwavejs yesterday but found the delay to be obscenely long (~ 10 seconds) and wasn’t sure if it was maybe something with my existing zwave network, so I started up a test env with a second (clean) zwave stick and an extra zwave dimmer I wasn’t using. Originally couldn’t get the entities to appear but then read the messages right above mine and switched to v1.3.0 of zwavejs2mqtt and that solved the initial issue. It also seems that with just the simple 2 node network, the response is pretty much instantaneous, so I was thinking of rebuilding my network from scratch to see if it fixes the issues.
One thing I found at least for this dimmer is that the home assistant ui toggle button updates the state incorrectly for about 1-2 seconds. Is this a known issue? In the video below you can see that I toggle the light on, but the ui switches back off for a second or two and then corrects itself. The physical switch doesn’t exhibit any weird behavior, it turns on and ramps up the brightness over the desired ~1 second transition time.