Open Motya-HA opened 1 year ago
Same here. I don't have any error message in the logs. It works well, then one random command fails and the device is not connected anymore to the network.
I have a Conbee II adapter.
A reboot of the RPi solves the issue until next failure.
Can it be an incompatibility between some new frames in the last update and the firmware of the adapter?
Correction. These are not just Hue devices. Recent check showed that pretty much all Zigbee devices with exception to inovelli dimmers
Just a comment based on my setup. I had problems with that firmware on the ZBDongle-E, I'm now on 7.1.1 and it is working much better.
@KoalaWerewolf Thanks for suggestion. I can't see 7.1.1 firmware in that site: https://github.com/xsp1989/zigbeeFirmware/tree/master/firmware/Zigbee3.0_Dongle-NoSigned/EZSP
I used this way of flashing: https://darkxst.github.io/silabs-firmware-builder/ and the firmware from here: https://cloud.time-vortex.net/s/Jy2x6tj2GNx2QZn (check this post and the thread above: https://github.com/Koenkk/zigbee-herdsman/issues/319#issuecomment-1634886994)
@KoalaWerewolf Thanks I'll try when I'll be back home (traveling now) Can I do it with Mac or Linux? I do not have any Windows machine at home
Thanks
Iâm sure you can, but I donât know if that webflasher works.
Same here. Almost all ZigBee devices are disonnecting. It's a mess. I'm on the Sonoff ZigBee 3.0 USB dongle with latest custom firmware.
Some more details - every time there is an update or home assistant restart, all Z2M devices become disconnected. Restart of Z2M add on fixing the issue. Any plans to address this bug?
I have this issue as well: my entities provided by Zigbee2MQTT (via Mosquitto broker) become "Unavailable" when I restart Home Assistant, until I also restart the Z2M add-on. I'm not sure how to debug this
Are they disconnected from Zigbee2MQTT/the ZigBee network or just "unavailable" in HA? The later would most likely be an issue with retained MQTT topics (or the lack thereof), the former would be more serious.
They became "unavailable" in HA. In order to make them "available" I need to restart Z2M add-on. sometimes several times. I've updated the topic subject
This debugging thread on the MQTT side of things may be helpful: https://github.com/home-assistant/core/issues/99936#issuecomment-1716028130
It seems Z2M may be dropping entity names sent to the config
topic, leading to a conflict when it falls back to the device class. There's a bugfix in the upcoming 2023.9.2 release that may help, but I'm unsure if a fix is also needed in Z2M
I think fix is needed in Z2M in a first place. All these issues have started after recent update for Z2M
Same problem. Devices and groups are unavailable after HA restart until I manualy restart Z2M. 3 Z2M networks: Sonoff (Z2M docker 1.33.1) Sonoff (Z2M docker 1.33.1-dev) zzh! (Z2M HA addon 1.33.0)
@rossowl do you still encounter that as I had to downgrade to 2023.8.4 HA due to UI slow/laggy so want to confirm if I'll have to deal with that now - every HA restart == Z2M restart?
I confirm I still have this issue: Z2M HA addon 1.33.1-1 Home Assistant 2023.10.4 Supervisor 2023.10.0 Operating System 11.0 Frontend 20231005.0
OK I didn't have that when running external mqtt/z2m now with fresh HA VM I've got mqtt broker from addons and it's an issue.
now it requires 2 or even 3 restarts of Z2M add-on for some devices to become responsive :-(
OK I didn't have that when running external mqtt/z2m now with fresh HA VM I've got mqtt broker from addons and it's an issue.
The mqtt add-on is very buggy at the moment
The mqtt add-on is very buggy at the moment
I do not have any issues with Z-Wave JS UI (uses MQTT as well)
Z-Wave JS UI does not use MQTT when integrated with HA.
"The Z-Wave JS UI add-on provides an additional control panel, allowing you to configure every aspect of your Z-Wave network. It provides a decoupled gateway which can communicate using Z-Wave JS WebSockets (used by the Home Assistant Z-Wave JS integration) and MQTT (even simultaneously)"
Yes, you can enable MQTT (disabled by default!). But the Z-Wave JS integration does not use it even if you do. So unless you have enabled the MQTT client in the Z-Wave JS UI settings and don't use the Z-Wave JS integration, your HA instance does not use MQTT to access your Z-Wave devices.
I did enable it
I can confirm that with external mqtt everything works. Intel NUC: Hass OS MQTT addon disabled
RPi4 with docker: eclipse-mosquitto 2x zigbee2mqtt
Installed Zigbee2MQTT in Linux box (stoped add-on in HA). Rebuild whole Zigbee network. Same issue. After restart of HA (Zigbee2MQTT run on Linux box interrupted) all my Zigbee devices becaem unavailable. Need 2, 3 reboot of linux box with Zigbee2Mqtt to make all devices responsive again
Same for me, restart of ha or the mqtt server are causing zigbee2mqtt completely offline. As I can see:
After a restart of the mqtt server, the entries in the homerassistant mqtt folder are not rebuild. So they don't have a retain flag and are not created --> device offline.
Fixing the problem of the homeassistant folder is simple: set a retain flag here
Also some values in the zigbee2mqtt folder are also not updated, because they get only updated on device response. A solution could be to update those values from time to time, or to handle reconnects from mqtt server better.
A reconnect in the mqtt library should create a callback that sends out all values again.
I think this should fix all problems we have.
PS: I saw an option for setting retain flag in the settings, but I want to see if there are connection errors, so setting the retain flag for all values could be a problem?
@merlink01
Fixing the problem of the homeassistant folder is simple: set a retain flag here
Can you please explain how?
I don't know what mqtt library is used here, in paho on python a publish function looks like this:
publish(topic, payload=None, qos=0, retain=False)
Topic is the path in the mqtt tree structure Payload is the json containing the information where homeassistant searches for the values qos is the adjustment how the messages are delivered the higher the more reliable, but causes more traffic retain: tell the mqtt server to send the last good value to new clients or in case of connection loss to the same client again
So I think in this case it could help.
Exact same issue here since a few months now! Devices and groups are unavailable after HA restart until I manualy restart Z2M.
I have made an automation which restarts Z2M addon 30 seconds after HA start, but this also doesn't work reliable all of the time.
Again, the devices not dropped of the network. In Z2M GUI, they are controllable and alive. Just HA is reporting them as unavailable. I think always the same devices has this issue. Now because I am knowing that, I just open the same room after HA restart, and when one specific group is not available, the issue occurred. Quickly restart Z2M and most of the time it's solved. Sometimes I need to restart it twice.
This is very good reproducable, how can we help to nail the issue down?
@Koenkk I am here to help debug if needed.
I've also also been seeing this (Z2M sees/controls devices, but HA UI does not) on and off for a while across various HA and Z2M versions. At this point I don't let Z2M start on boot. I always manually restart it well after HA and the MQTT broker have spun up.
That usually gets about half of my devices controllable from the HA UI. From there I can "fix" any device in the HA UI by either saving it's description in the Z2M UI (no changes needed, just click "Save Description") or by publishing the below:
zigbee2mqtt/bridge/request/device/options
with payload
{"id": [DeviceID], "options":{}}
For me this issue happens on every HA reboot, and most of the time if I stop/start Z@M while everything else is left running.
It's annoying enough that I'm considering writing a Z2M extension that publishes the above against every Online Z2M device at Z2M startup, which of course is completely stupid, overkill, and doesn't solve the root cause, but at least I know it would work...
I'm open to help repro / debug in any way I can, would love to see a real fix to this!
@diphen if you are writing such an extension, please let us know. We all know it's not an intended behaviour and should be fixed in Z2M/HA, but as a workaround it would be good enougth.
thx
Same problem, HA and ADD-ON up to date, have you made progress on this problem? thanks in advance
@xekil here was made some progress: https://github.com/Koenkk/zigbee2mqtt/pull/21500
I completely solved the problem with moving to EMQX broker (from Mosquito)
@Motya-HA thx for the hint. Is it just as easy as uninstall Mosquitto HA addon with EMQX HA addon? Is there also a good integration of the addon like on mosqouitto (HA users, ...)?
Stop Mosquito add-on. Download EMQX add on and follow instructions
https://github.com/hassio-addons/addon-emqx/blob/main/emqx/DOCS.md
Good luck
this is good instructions:
https://smarthomescene.com/guides/setting-up-emqx-mqtt-broker-in-home-assistant/
I can confirm EMQX is very feature-rich and capable, having it set up for testing in my secondary HA instance.
My only big gripes are that if you are using any kind of MQTT bridges (in my case the SUPLA electricity meter) it loses connection during HA/EMQX reboots and even though it's enabled, it never comes back up. I have to manually go in, log into EMQX UI, turn it OFF and ON, to make it work. No setting I've been able to find resolves this issue, including clean reboot on start. Not even the EMQX reboot fixes it. You have to do an OFF/ON for some reason from the UI. There is also no API from HA that I could find to automate the process, so it's a good old manual labor when the readings go down.
Second, 'with great power comes great responsibility' and all the features are incredibly overwhelming to start with, especially when devs decide to change menu names and layout every few weeks/months. I've spent some time finding options I used to use, since they were moved and drowned in the jungle of switches and nobs.
TL;DR, if it resolves the above-mentioned issue, I guess it's a no-brainer.
@xekilici des progrÚs ont été réalisés : #21500
Thanks, but will this be fixed quickly?
See the latest comments. The proposed fix doesn't work, so NO it won't be.
What reliable solution then? Change MQTT Broker? Make an MQTT MOSQUITTO VM without guarantee that it works? THANK YOU
Manage your expectations - people invest their own time to provide something to you for free, so getting frustrated and demanding over a small bug is not going to get you anywhere. If you seek guaranteed solutions, find a commercial home automation platform, pay for it and expect the provider to guarantee reliability and long term support. Sorry for stating the obvious, but it felt necessary.
Potential 'solutions':
1) Wait patiently for someone to provide you an 'out of the box' fix, which may take days to months.
3) Invest your own time into testing a solution/workaround for yourself, e.g. a different broker, automation rebooting the broker when things go unavailable
or anything else you find on the internet as a path worth following.
3) Lastly, if neither of the above seem appealing enough, continue to reboot HA/MQTT when things go offline, since it's not that much of a problem in the first place (been doing it for a few months now).
These are the pleasures of community driven, free project! Be a part of the community that makes things work together, or buy a product! ;)
I think we need to clarify things, I am not at all frustrated or demanding, far from it, and quite the contrary, I spend a lot of time helping others for free in several areas, and I am very grateful to everyone those who work to make home assistant the best home automation solution.
I am just surprised that this problem which seems major to me is not one of the priorities or rather that there is no official communication on this problem which does not seem to be an isolated case especially since the majority of the Home community Assistant is essentially equipped with Zigbee and uses the Zigbee2MQTT and MOSQUITO Add-ons.
I already have a workaround solution (restarting the add-on when starting home assistant with an automation) and it works, but it shouldn't work like this, I'm wondering, because I don't have a clear answer on this problem and whether a possible solution will be found or not, in which case, it is obvious that I will switch to another broker or another instance to try, etc... With Proxmox everything is easier :)
Sorry if my messages may have seemed frustrated and demanding, but that is not the case, I have been using open source software for several years and I know very well that you should not have the same requirements as for something of General public ;)
What reliable solution then? Change MQTT Broker? Make an MQTT MOSQUITTO VM without guarantee that it works? THANK YOU
I moved to EMQX (I am running HAOS) and I have "0" issues. It took literally 10-20 min (I have 2 Zigbee2MQTT add-ons running with 2 different NET coordinators). I do not know if they are changing interface, or anything else. It just works.
this is good instructions:
https://smarthomescene.com/guides/setting-up-emqx-mqtt-broker-in-home-assistant/
Thanks a lot for this link. Switched to EMQX now and restarted HA several times -> YESSS!! All Z2M devices where available! With mosquitto, after 1-2 restarts, several devices where not available.
Will see how it goes in a few weeks. Maybe (finally!) i can ditch my Z2M resatart automation.
Will see how it goes in a few weeks. Maybe (finally!) i can ditch my Z2M resatart automation.
LOL...I had restart automation as well. Made it disabled, deleted after 1 month
Glad it worked for you as well
I really want to test this EMQX add-on but I'm afraid of having duplicate entities or ones that change their name from MOSQUITO to EMQX.
How does it work for MQTT entities that have been renamed in Home Assistant?
For example, a sensor which is reassembled with MOSQUITO to Home Assistant named sensor.0x25422548654 and which I then rename in Home Assistant to sensor.door_garage, will it remain named sensor.door_garage with EMQX as broker or will it reassembled in sensor.0x25422548654?
THANKS
@xekil i Have 145x MQTT Z2M devices (~1300 entities) and not a single one has issues after migrating!
Just stop mosquitto, install/start EMQX, configure HA & Z2M User. Configure Z2M to use the new broker and user. Press "Reconfigure" on the MQTT integration and fill in the new mqtt://a0d7b954-emqx:1883 path. See here for more information: https://smarthomescene.com/guides/setting-up-emqx-mqtt-broker-in-home-assistant/
Good luck
What happened?
After recent update to laters version Z2M (1.33.0-1) all Hue Zigbee devices are droping from network and become unavailable. Requires Z2M restart to bring them back
What did you expect to happen?
HUE zigbee devices will not drop from network and be stable
How to reproduce it (minimal and precise)
No response
Zigbee2MQTT version
1.33.0-1
Adapter firmware version
6.10.3.0 build 297
Adapter
ITEAD_SONOFF_Zigbee_3.0_USB_Dongle_Plus_V2
Debug log
No response