Oh, the irony is thick.
after the way he’s acted in this entire thread and he’s ignoring me for pointing it out! Talk about someone who can (try) to dish it out and can’t take it! that’s pretty thin-skinned. What a hoot! 
I really tried. I really honestly did… 
That was super helpful. Knowing that it won’t corrupt the stick / network gives me confidence to move forward as I can roll back. Understand the need to have the interview process complete in zwave-js.
Thanks for this link, very helpful and relevant as I’m on docker also.
A question, did you run into any contention issues with two containers accessing the same USB stick? Or is it that once you stop the zwave network on the old integration it releases the device?
glad to see that muting does absolutely nothing…
maybe I’ll take some time to go on a camping trip this weekend, I know a nice place near the water
Yes, once you stop the network it gets released so that there is no issue accessing the stick with zwavejs2mqtt. And the reverse is true as well - stop the zwavejs2mqtt container and the stick is released back to be accessible with the old zwave integration. Just simply restart the network and everything should be back to usual.
I too was hanging back on the migration mainly waiting for some device support to ‘catch up’ to 1.4. I attempted the migration late last year and ended up rolling back to my backup due to some unsatisfactory results. When I saw the recent update notice, it prompted me to try again. (While no one forced me down this path, I took the time to plan this out knowing I could likely revert to backups if need be. )
I read some blogs, watched some YouTube videos, read the migration ‘guide’ and the numerous comments in that thread. In the end, the migration was not exactly smooth, but more tedious than difficult.
There were the usual suspects like battery-operated devices that stretched the transition time, obvious matching and renaming entities, but the actual Z-wave transition went smoothly enough and I did not have to re-bind any devices to my Z-wave mesh. What did cause me grief were my automations.
Sensor attributes that were once supported no longer were - or at least not in the same way. Renamed sensors gave different outputs or behaved in unsuspected ways, all of which required device by device debugging for about 30% of my devices. And then there was my Z-Wave lock.
Past experiences have taught me to dread changing anything substantial with Z-wave locks but I was happy to see that it ‘just worked’. Kinda. It would lock and unlock but all of my various status code triggers were apparently gone. Again, some research found others with the same issue and that there were some wholesale changes as to how event notifications were getting surfaced. It was tedious and did require me to rework some of my automations, but it eventually worked like it did before after some debugging.
So for me, most of the issues I ran in to were possibly similar to the OP in the sense that I saw them as breaking changes for devices as opposed to general Z-wave stuff. Anyway, things are working now and, as well all know, if it ain’t broke don’t fix it! On to more exciting stuff…
Background - about 60 devices, AOEN Labs ZW090, did not go the ZwaveJS2MQTT route and use Node RED for all automations.
So I’m primed up and ready to do this. I have the zwavejs2mqtt container staged up. What I’m thinking is after stopping the zwave network in HA and getting all the interviews done in zwavejs - is to start up a new HA container and connecting into zwavejs - so I can see how the entities come through and work out the mappings / naming in zwave js and test / adapt the existing packages using new naming conventions, etc. Most of my config is through template packages running through sed to create the HA config. Once I have all working - I’ll do a production migration similar to what you described.
Any issues with this approach?
On the entity_ids - I’m leaning towards using whatever zwave_js provides vs trying to rename to the existing ids. Just seems simpler in the long run to remove mappings and that way it’ll be named the same in HA and zwavejs. Thoughts on this? I know I’ll have to update packages, Lovelace and figure out what history in recorder to bulk update to the new ids.
You should do whatever you feel works best for you and I don’t see any downsides necessarily.
I just found it easier for myself to rename the entity_id’s to the old ones instead of updating my entire config to accommodate the new entity_ids. I figured there would be less chance of missing something that way.
good luck! 
@marketingdue. Hope you found that water and it cleared your mind a little.
How @finity and @petro managed to help you in spite of your perpetual rudeness is beyond me.
REMEMBER this is a free application developed by people who give their time voluntarily. Instead of complaining why not use some of your undoubted expertise in developing scrIpts to assist with this migration for everyone to use?
Calm down when things do not go as you may expect, rationally work out a path to fix the problem and most importantly RESPECT those trying to help you.
Once I worked in out the kinks, I’ve had excellent results running zwavejs2mqtt. My containers has been running for 2 months without a restart. The one issue that occurred with a sensor report being missed appears to be fixed in the latest version. Solid for me!