At this stage it’s literally impossible to ban me permanently. I have access to thousands of IPs, and an infinite number of email addresses. When someone tries to permanently ban me, I will respawn a few times in a completely obvious way just to prove them wrong and have them create some weird rules they think will stop me, but just really end up hurting other users.
Then a few days later I respawn in a less obvious way completely undetected.
So threatening me is useless, because I am 397.2% certain I can come back.
Now the question is are you foolish enough to try, and can your self confidence withstand learning how powerless you truly are.
well I was going to try to help you out as I done the migration and though it was a bit of work to rename devices I did not lose my automations or configurations but since you seem to only want to be banned so you can respawn does not sound like you really wanted help just wanted to blame others for your incompetency typical beta male so good luck on your little games
I excluded and re-included everything today, since the majority of my automations are motion based, and the way motion is reported in the new JS system is completely different, my only option is to redo all the automations. If you think that’s my incompetency then you really don’t understand how any of this works at all.
well considering that I am running dual ZwaveJS servers that have about 70 devices between the both of them that I migrated from the old zwave 1.4 the only one that I had to exclude and reinclude were the ones that I moved to the second Zwave Hub and I did not have to redo any of my automations including my motion based ones, but hey obviously its not your fault you could not figure out the path needed to do migrate over I am sure they whole thing was setup to for you to fail and whine about how they were out to get you, well at least since you get to start from scratch it gives you the opportunity to do some clean up and trimming of your setup
At this point yes, the recommendation is for you to start again.
You can complain, but that won’t change what was and was not done. So recommend you get it going.
I really don’t want to ban you. Just be nice to other people. You have a chip on your shoulder and you won’t get help if you keep this attitude.
The DEVS here often make decisions and hardcode things, and aren’t interested in anyone who disagrees with them
But sure you continue to believe they would never intentionally break someone’s system because they said so
I am nice to other people, I just have no tolerance for people operating out of their depth and making mistakes I have to clean up, and call it out when it happens. People with huge egos who think I should genuflect before their greatness, don’t always appreciate my direct honesty.
not sure what that article has to do with you breaking your Zwave setup but ok, I managed to not only migrate my Zwave network but also setup a dual system into one Home Assistant, I must have been pretty lucky that the DEVS missed my setup and did not break it LOL
Do you need help fixing your setup?
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 have to manually fix my automations, which is a pain in the ass, but I know how to do it.
Alright then, how about your focus your energy on fixing your automations then.
I kindly ask everyone else to avoid responding.
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
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.
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.
a lot of people have no success using the migration wizard. It may be user error or it may not be.
Here is a post outlining everything I did to switch to zwavejs before there was a migration wizard available:
What I never got was that people were saying migrating broke their network. I don’t see how that is even possible as petro explained above.
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.
Odd, my motion is faster and I have 130ish nodes. Unfortunately, no one can help you because you don’t provide information. Just complaints.