Replies: 20 comments 3 replies
-
|
Please provide the debug log file. Also Screenshot of the HA MQTT device. Also you should check using another MQTT client if the topics get sent. I usually use http://mqtt-explorer.com/ |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Debug log Development-Branch: fix-timezone-config-parser (Commit: d9cb0e1d66af170c1175dd7fdc2531fb2ee71260+): |
Beta Was this translation helpful? Give feedback.
-
|
After the reboot the 15.0.3 is back online... |
Beta Was this translation helpful? Give feedback.
-
|
Homeassistant uses the topic Please update to 15.1.0 and check the logs there. Please note that it is not suggested to restart HA and the MQTT broker every night. This means you will lose messages during that time! |
Beta Was this translation helpful? Give feedback.
-
|
I tried by manual publishing the connected payload to the AHwatermeter/connection topic. But is does not bring it back online. |
Beta Was this translation helpful? Give feedback.
-
|
v15.1.0 says: (Only send Homeassistant Discovery the first time we connect, ...) |
Beta Was this translation helpful? Give feedback.
-
No, HA only needs to receive the discovery topics once, so it can set the device representation up. |
Beta Was this translation helpful? Give feedback.
-
|
this is wrong. you must always publish the there is no difference between "discovery" topics and normal topics for HA. Every valid sensor under |
Beta Was this translation helpful? Give feedback.
-
You can test the HA behaviour by sending "connection lost" resp. "connected" to "AHwatermeter/connection" using another MQTT client. |
Beta Was this translation helpful? Give feedback.
-
But when the HA restarts.. it needs those again.. the AI-on-the-Edge device does not "know" if HA had restarted or just lost the connection... |
Beta Was this translation helpful? Give feedback.
-
Then your HA is setup quite odly! |
Beta Was this translation helpful? Give feedback.
-
|
It looks like HA keeps the devices but they will not re-appear online after they are offline for some minutes unless you re-send the auto-discovery sequence... |
Beta Was this translation helpful? Give feedback.
-
What do you mean "not re-appear"? After a MQTT timeout (which is set to 2.5 of the Round interval), the MQTT broker will send the Last Will Topic which is "connection lost". HA will then mark all entries of that device as "not available". After the device completes a round, it publish the "connection" topic with "connected" and HA will show the entries as "available" again. Sending the Discovery topics is completely independent of this! And as a side note, there are many users with HA, if there would be such a bug, you for sure would not be the only one complaining! |
Beta Was this translation helpful? Give feedback.
-
|
Ok... let's give it a week... i am back to v15.0.3 now... |
Beta Was this translation helpful? Give feedback.
-
|
the same problem has now hit me. My watermeter and gasmeter have been running smoothly for 2 days now. 2 hours ago I restarted the server where MQTT is also running. A restart of the two meters helped |
Beta Was this translation helpful? Give feedback.
-
|
Like stated before, the Discovery topics are only required once to set the device up in HA. Those config topics no longer are required afterwards! I just validated this myself. My device then looks like this in HA: Then I disabled HA Discovery in my device and restarted it. Then I restarted HA. For a moment all sensors will be shown as unknown, but as soon as the device sends its first data, it changes back to the latest values. Then, I restarted HA and Mosquitto together. It is right that it would be useful to send the Discovery and Static topis at every connecting, how ever we decided on purpose to not do this as it could overload the device in case it is on a task with high RAM usage. |
Beta Was this translation helpful? Give feedback.
-
|
the problem still exists in my case. ONLY a ESP reboot fix this issue.
rest_command:
gasmeter_reboot:
url: http://192.168.155.52/reboot
watermeter_reboot:
url: http://192.168.155.51/reboot
alias: System - Watermeter / Gasmeter reboot
trigger:
- platform: time
at: "03:00:00"
action:
- service: rest_command.gasmeter_reboot
- service: rest_command.watermeter_reboot
mode: single |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for this workaround. Been having trouble for a while now. |
Beta Was this translation helpful? Give feedback.
-
|
Thats really odd. |
Beta Was this translation helpful? Give feedback.
-
|
I've seen this problem occur occasionally as well, I think mainly after updating HA to a new version - which I did yesterday evening, so today I didn't receive any values from the watermeter until I noticed it being NA in the afternoon and rebooted it. MQTT devices from Z2M don't seem to have this problem. |
Beta Was this translation helpful? Give feedback.
-
|
Not sure what happens on your systems, but for me, I can either restart (ESP32-CAM, HA or the MQTT broker). I even have You could check with a different MQTT client to see what happens. |
Beta Was this translation helpful? Give feedback.
-
Just after the latest Z2M update, as soon as I had updated to 1.36.1, the water meter immediately was marked unavailable again in HA - then I noticed that it might be due to a combined stack of both Z2M and Mosquitto. I was only pulling a new image of Z2M so I thought only this container will be restarted afterwards but it seems that the Mosquitto one was also restarted which could explain the water meter's NA status. Unfortunately I didn't wait to see if the problem resolved itself after the next run but will do so after the next update. |
Beta Was this translation helpful? Give feedback.
-
The Problem
Since i upgraded to Development-Branch: fix-timezone-config-parser (Commit: d9cb0e1+) my devices do reconnect and report to Home-Assistant but it does not show. After the HA-server and MQTT have restarted (they do it every night in my case). Before i used version v15.0.3 (Commit: f42e9c7+) and with that version it works fine.
It looks like there is a slight difference in the MQTT reconnect procedure...
Version
Development-Branch: fix-timezone-config-parser (Commit: d9cb0e1+)
Logfile
Will be supplied if neccesaryExpected Behavior
No response
Screenshots
No response
Additional Context
No response
Beta Was this translation helpful? Give feedback.
All reactions