Let me know if you hear anything please! Same issues here, again almost same setup
Oh, thank God, back up and running. So for me, the suggestion of removing the core.config_entries zwave entry was helpful but wasn’t all I had to do. Turns out, I had an integration with OpenZWave in my integrations list that I wasn’t using, must have tried it in the past and wasn’t using but had forgotten to delete it. So after I deleted it and rebooted the host, it ran to completion. So I guess I had to remove all references to any zwave before I was able to get it to run again. I have successfully switched over to the Z-Wave JS now, and it seems my devices are there. The names and entity ids aren’t the same, but I can live with that…just have to update everything in my automations and what not. What I can’t live with is non-functioning Home Assistant. Thanks for the suggestions. Everyone here is great, I can usually just read the forum and troubleshoot without posting. Cheers!
Hello there
I bouht a start kit about a year ago. It has a hub, and then some sensors. According to the labels the connectivity of this kit (hub) is wireless.
Later I bought some temperature sensors and found out it was not connected with the same hub, meaning it was a zigbee device and I bought another xiaomi hub (this one was for zigbee).
The temperature sensors (zigbee) and the xiaomi hub (zigbee), I was able to find them and connect them with a conbee stick, however the other hub and sensors I was not able to
Also, I have a air purifier which is wi fi, and that one I also can’t connect it. Every thing I find is talking about finding a token in the xiaomi app, but I was not very lucky with that 
I think xiaomi has a lot of nice and cheap smart devices but these limitations make me buy things like tuya that I then flash with tasmota, but it’s not really possible with these more complex devices
Unless you really want to redo all the automations I think it would ber much easier to just rename the new zwavejs entities to the same entity_id’s as the old integration had.
Then all of your automations and everything else will just work.
1 Like
Thanks for the advice. I am having an issue with a couple of my scene controllers now that don’t appear to be supported/ not producing zwave.scene_activated events that may be a deal breaker for me going forward on this integration anyway. We’ll see.
This version killed my HA on pi4 the same way, things stop working after update.
So, I ended up doing a fresh install but it failed too.
Wifi is broken. So I have to plug in to wired network.
Then I connect pi4 via HDMI and use a keyboard to login as root. then downgrade to 2021.1.5.
then I connect from browser try to restore my snapshot, but it seems only allow me to upload it, but it would not apply the backup… so I login again from console and apply the snapshot…
This is the most disastrous upgrade I ran into… oh well.
Oof, sorry to hear that. My RPi4 is running fine (after deleting a problem addon). Are you using SSD or microSD to boot? The stability has improved since going to SSD only.
It amazes me that anyone would try and run an essential service over wifi.
6 Likes
Smooth update here on a proxmox host. I always keep a stack of VM backups just in case. I’m just blown away by how snappy zwavejs. I was one weekend away from replacing all my dimmers with tuya devices rubbing esphome but alas, the zwave lives to see another day!
I am on microSD… sadly.
So, I am holding off to 2021.2 and stay at 2021.1.5 for now.
Not everyone has the lux of LAN cable run around the house, I am one of them. 8p
I appreciate that, I really do. But you said you are able to plug it into a wired network, and the system then works. Leave it there
3 Likes
I had a (possibly) similar experience, stopped wiorking as soon as boot completed.
Fixed by switching to ethernet instead of wifi
I think there is enough “me too” now for someone to post a github issue regarding this release and wifi on the raspberry pi.
Same problem for me. System stays up for about 4 days before requiring a full reboot.
I have isolated the memory growth to the homeassistant container in docker. I had the problem on 2021.1.5 and 2021.2.0. 2021.2.0 eats memory even faster. The memory growth is very consistent.
Roomba has fully transitioned to configuration via UI. YAML configuration is no longer supported.
Why? Alright, I get it that some (many) people prefer the UI way. That’s fine. But why remove functionality? I have my yaml(s) checked into a git repo, clean and easy, I can spin up an exact copy of my HA on any hardware just by checking out a repo with docker-compose and HA configs. I can track changes to configs, rollback bad ones. Now I cannot do that, bc UI configured json(s) are pretty obscure and require double work to change something in the UI and then go and checking in the config, merging conflict with the JSON. Why?
My post was referring to the changes in the Lutron Caseta integration and not the the zwave.js
This discussion has been gone over many times, and I agree with you. But please visit the appropriate thread and post there rather than rehashing it here.
I had something similar happen a few days ago, my thermostat disappeared. I made a github issue about it in the library ha uses. Looks like there an issue with Google’s SDM API and you have to restart your thermostat if it drops off, that fixed it for me. Instructions for restarting it are here.
I gave it a try and restarted the thermostat. At first, it didn’t seem to make any difference, but I restarted HA and everything appears to be working now. Thanks a lot. The simple solutions are the best.