The devs here make decisions based on how they think things should work, and don’t listen to anyone who has a valid point they disagree with.
For example if you run your own DNS server like PiHole to protect your privacy, Home Assistant flagrantly tries to get around your DNS blocking with hardcoded IPs for Cloudflare. They don’t want to deal with users complaining about DNS issues, which is a legitimate concern. Firefox solved the problem by using a Canary Domain for users who want to run their own DNS servers. The devs here refuse to acknowledge that anyone else has a valid opinion other than themselves, and refuse to even discuss using a canary domain.
So I know for a fact the devs here are arrogant and have no problem breaking or trying to circumvent your network, if they don’t deem your concerns as being important.
I’d still like an understanding, if we have it, of the causes of having to rebuild the zwave network when doing the migration. I want to make sure that if it does not go well I can revert back by restoring HA backup and Zwave stick back up
Specifically:
Does zwave-js reconfigure the stick or reconfigure the devices? If so, why? And will restoring stick backup fix the issue?
It seems that locks may be a problem? Other types of devices that has known issues?
Should the migration wizard be used or am I better off dealing with the entity remapping later?
No it does not. It just trys to interview each node when you start up. If you don’t wake the device it’s trying to interview, it waits until you do. This for some reason is what everyone ignores and assumes that Zwave JS is terrible. When this is what would happen on any z stack, because the sticks do not store everything and things need to be queried.
Devices need to be reinterviewed when placed on a new system because the new system wants to know all the functionality. Some of the information associated with nodes is not stored on z-sticks, most is. Battery devices usually have the least information and they actively do not wake up unless a person forces them to wake up. Also, manufacturers dont’ follow rules. Many of them have odd configurations that do odd things. The only way for any new zwave software to know these things is by interviewing the node.
If you don’t remove the node and you just attempt to interview it, switching back to an old setup will have no impact. If you remove the node from the stick and add it back (as a new node), the old zwave setup will have to interview that “new” node.
Because they have security and people put in the wrong code. Because they are battery devices and need to be woken up. Sometimes these lock devices have a short 10 second wake window and that’s not enough. So you have to keep the device awake for a long time, people don’t do this. Again, they assume it’s zwave js’s fault when it’s them not keeping the device alive. 99% of the issues you see in this forum in relation to migration are due to not keeping battery devices alive during a reinterview. For some reason, when you first interview a device, they stay awake longer without user intervention. This is why deleting the node and re-adding it has a high success rate with people who don’t understand what’s going on.
Battery devices.
Choice is yours. I did it without a migration wizard. It’s just time consuming because you have to rename a ton of nodes. The wizard will help mitigate that.
My automations were triggered by ‘State’ changes, this no longer works. It now uses ‘Device’ attribute changes. Since the majority of my automations were motion based state changes, this change broke most of my automations.
The developers didn’t care about maintaining legacy functionality so ‘State’ based automations stopped working. I really don’t understand why this is such a hard concept for people to grasp.
Z-Wave JS is terrible because the response time is much much slower. My motion sensors, and Z Wave stick are exactly the same, yet all of my motion triggered automations are much much slower. If you don’t use motion based triggers you may not notice your performance has gotten worse, but if you do used motion based sensors, you now notice how much farther you have to walk into the room, before the trigger fires and the light turns on.
Just wanted to chime in to tweak the noise to signal ratio. Several versions ago, I followed the guide that @petro created when I saw that Open Zwave was being deprecated. Took about an hour, but my 50+ devices are now working just fine. No speed issues to speak of. I have several automations that depend on motion to trigger. Aeotec stick on a Raspberry Pi 4.
I recently added a couple secure devices and that process went smoothly as well.
In addition, I got some new functionality (at least I think it’s new) - I have some switches that let me double or triple tap on/off and I’m able to trigger automations from that via Zwave-JS events.
I have no idea at all with what you are referring to with that statement.
I never use the UI editor to create any automations…ever…and so I don’t have access to any device based automations so all of my automations are “state based” and none of them have stopped working.
There was no change. state based automations still work just fine.
Unless there was some breaking change in the latest HA? But I seriously doubt it.
I saw literally zero difference between the old zwave and zwavejs. It’s neither better nor worse.
All of my motion devices are the exact same devices. My Z Wave stick is the exact same stick. The only thing that changed was updating to JS Z Wave. Before my motion based automations would trigger 4-6 feet into the room. Now I get to the middle of the room and have to wait before the light turns on.
The only thing that changed was updating to JS Z Wave, nothing else in the equation changed.
Unless you think I became a meta-human and turned into the Flash, and am now somehow walking into the room much faster than before.
The JS update completely changed how and where data from my motion detectors are brought into the system. I’m glad your system didn’t break, but acting like I’m imagining this, or that it didn’t completely break my automations, shows you really don’t understand things as well as you think you do.
Ok, still, that doesn’t give any information on what the problem could be. Zwave is a mesh network of devices. All devices behave differently. Things have been updated too. The original OpenZwave 1.4 (which is what you came from) is an old package dating back to 2016. As you can imagine, a lot has changed in 6 years.
It’s just a way of reporting. You can actually change the reporting type on most devices. From basic to notification. But that depends on the device. Basic reporting will give you a binary sensor.
That’s a device trigger. You can change it to a entity_id based trigger.
Remember when I said to be nice? Calling people smart asses is not the way to handle this. Just ask your questions. Why do you act this way? No one here is “out to get you”. Just act like a reasonable adult. Is that so much to ask?
I have the same amount of Z Wave devices before and after the update. No one moved in and is walking around triggering extra motion detectors. I went into each sensor and adjusted the refresh time to 1s shorter than the default 3s
