How to restart zigbee2MQTT after a Home Assistant Restart

Ok the disable auto zigbee2MQTT reboot after a Home Assistant restart failed

Now all my battery powered zigbee devices are:

“This entity is no longer being provided by the mqtt integration. If the entity is no longer in use, delete it in settings.”

They are fine in zigbee2MQTT and respond to commands - Home Assistant just loses them

Logger: homeassistant.helpers.service
Source: helpers/service.py:275
First occurred: 12:00:00 (1 occurrences)
Last logged: 12:00:00

Referenced entities cover.blind_ensuite are missing or not currently available

A restart of zigbee2MQTT restores them all in Home Assistant

Tried un-installing z2m and re-install it?

No

Would that involve re-pairing every device and fixing in Home Assistant ?

If I do - I’ll have to think about building a production version of Home Assistant and create another using a spare Home Assistant green theoretically I could share the zigbee2MQTT / mqtt between them maybe

No, it shouldn’t, z2m is a docker, but it’s database is stored in the shared folder and shouldn’t be deleted (but just made a full backup before you do, just in case) :wink:

1 Like

If you ever reenable that automation, make sure to change the time.

HA purges the database at 4:12 every day. Your reboot is cutting it extremely close to that time.

2 Likes

Thanks. Good to know.

Before I do that I’ll move lighting back to Hue.

I need the lighting to be reliable or risk the wrath of my better half.

It will reduce the loading on Home Assistant zigbee2MQTT and get rid of the pesky disagreeable lights

Regarding the issue with devices showing as unavailable. I had this same issue with several of my zigbee plugs after I updated to z2m version 1.36.1. In my case though it was about every two minutes these devices would show as unavailable. I ended up reverting back to version 1.36.0 and the issue went away. Per the z2m github page it does appear others are having similar issues. If you can try rolling back to a previous version to see if the problem goes away.

I wouldn’t say there is a recommendation but rather personal preference maybe. I use Proxmox with HA running in a VM with z2m and other addons running in LXC’s. I chose this method because I didn’t want everything running in HA in case HA ever had to be taken offline or crashed. If you want to go this route and use Proxmox there are some helper scripts that make it easy to do

Proxmox VE Helper-Scripts | Scripts for Streamlining Your Homelab with Proxmox VE (tteck.github.io)

1 Like

Before Home Assistant I was running MQTT, zigbee2MQTT and Nod Red in containers, keeping the updates up to date and managing them required a higher level of maintenance than was optimal. Especially when my days of command line passed 30-40 years ago :slight_smile:

I am open to all options.

For the moment, everything has been stable since Sunday, normally this hits every 7 - 10 days, I am journaling the issue now so can keep a precise record.

I have disabled 25 integrations, which while a bit of pain is not hitting critical systems but a some point would like the functionality back but not important when lighting, switches, plugs, sockets etc stop working.

This weekend I will migrate Hue lighting back off Home Assistant zigbee2MQTT back to a newly wiped Hue Hub.

Then hand over most of the autonomous lighting (90% of the house is driven by motion/presence sensors) the remaining will be through the official Hue integration.

That will reduce the zigged devices down from 148 to 100 leaving more room to add the remaining Router type devices. That will reduce the loading on zigbee2MQTT and Home Assistant.

Then stand back and see if the problem is still occurring, the stay take a couple of weeks.

But at least the lighting will remain functional if it continuing.

Actually the issue is helping out a little - I have been bouncing back and forth between the monolith solution - ie everything sits in Home Assistant or I use Home Assistant as a support for Node Red operating as Command and Control with autonomous subsystems, ie Tado runs heating and hot water, Hue lighting, Eufy Cameras, with Home Assistant running the Govee/Nanoleaf/Shelly lighting.

I will need to look at automous sub units to support Alarm system.

As part of this if I am still experiencing issues with zigbee2MQTT /Hass integration I will do a rebuild of zigbee2MQTT and MQTT as recommended by @aceindy

If still having issues will look to running Matt and zigbee2MQTT in another VM and follow @billyjoebob999 helpful suggestion.

Also need to raise a ticket on GitHub for the zigbee2MQTT losing every device - but need to collect more data first to see if I can make the issue repeatable on demand.

Also, need to raise a ticket with Home Assistant team onHass losing every zigged device following a restart.

Lots of steps here - thanks to all those who have helped.

ditch the hub, why do you need it?

I have seen posts that state the hue/ikea lights bulbs use a protocol that disrupts other zigbee devices on the same controller.

Also, if zigbee goes down my better half is not amused when lights don’t work :slight_smile:

I had hoped I could run it all in Home Assistant but I have also been told that I have too many devices on zigbee2MQTT so this a surgical prune of 48 devices and makes them autonomous to boot with an override still available in Home Assistant

?? 48 ??

i think the amount of repeaters is more important :grin:

For sure the controller is the bottleneck, not Z2M

I am taking a new (to me) and making it smart as I get closer to retirement.

So I know I am stressing the boundaries :slight_smile:

48 of the 148 devices on zigbee2MQTT are Hue light bulbs/ motion sensors.

Currently 85/62 Router/Endpoint

By moving over the 48 Hue devices it will be

52/47 until I start adding mainly Router devices

If I remove the Hue bulbs I can keep it all under 150 zigbee2MQTT devices on coordinator/z2m

I have brought zwave up online for heat/fire/smoke/door locks sockets along with some motion/door/window sensors

I’ll eventually end up with 30+ double wall sockets, the four wet areas have 10 leak sensors.

30+ Door window sensors

20+ plug in sockets

15 outdoor sensors, shed doors, gates etc, motion

7 presence sensors

5 air quality sensors

10 switches

8 ikea relays

5 temp/humidity sensors - I get most of the temp and humidity from tado.

4 bed occupancy sensors

15 Blind controllers

If I run the lights on an semi autonomous service the same as I do for heating/hot water then I can build in a higher level of resilience

Most coordinators have a limit of 50 routing devices max. Some can go beyond that limit, but most of the “common” ones can barely handle that (usually crapping out between 25-30 routers attached).

If you need more than 50 router devices, you’ll need to think about splitting your mesh as the ZStack firmware has a pretty hard limit of 50 routing devices, 100 normal routes and 200 source routes. You’re going to have a hard time getting around that. Moving the Hue bulbs back to their hub is essentially doing that very same thing.

Useful info thanks.

Moving lights onto Hue hub(s) seems to be a useful way forward.

Flirting with the idea of running up a zha as well, break the house up, downstairs and upstairs + outside.

1 Like

Or you can do a second instance of Z2M. That’s actually the route I would go as using both ZHA and Z2M at the same time can lead to things like a device having different quirks between the two platforms and such. Plus, imho, Z2M adds devices and quirks (drivers) a lot faster than ZHA does. But, that’s just my opinion.

2 Likes

^^This. It’s super easy to spin up another instance of Z2MQTT Edge. Just remember to change the topic name.

2 Likes

As an update

zigbee2MQTT ‘lost’ all of its devices again at 22:17 Saturday night, 5 days after it did it before.

So have enabled most of the 25 integrations I disabled as they do not appear to have any impact on this.

Not a problem - keeping a journal and log grabs so I can try to identify the issue.

I am migrating the Hue bulbs and motion sensors off zigbee2MQTT back to a Hue hub, 1 to stabilise core services, 2 reduce loading in zigbee2MQTT, 3 reduce the Hue/ikea bulb disruptive effect on zigbee.

It will get solved, I just need to do it slowly so I can track the issue down.

Some of these are known to generate excessive traffic.

I have turned on zigbee2MQTT debug logging to see if I can capture the issue occurring.

1 Like