You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug (config/log below)
I am running the HassIO MQTT broker add-on in addition to this Presence Monitor add-on under HassOS on my primary RPi. As an aside, I have three other nodes that only run the Monitor script (RPi Zero W).
I have noticed that the instance of the Monitor script run via this add-on does run it's own internally-triggered scans and provide those MQTT reports (as expected) but most of the time will not respond to requests sent via MQTT (e.g., monitor/scan/echo, monitor/scan/known device states, monitor/scan/arrive, monitor/scan/depart). The instances running on separate RPi's always respond to these MQTT requests as expected.
It got me wondering if there is a fundamental design issue when trying to run the MQTT broker and the Monitor process on the same node. I do not claim to understand linux architecture and especially not Docker, but I thought only one process can listen to a TCP port. If so, I could see the MQTT broker binding to port 1883 and not allowing the monitor script to also listen in on this port (either very often or at all). Is that a potential issue with this approach?
If not, could it be that the HassIO RPi is just too busy to allow a response? It's not as if the incoming MQTT requests are queued up and a response is eventually received, they are just ignored.
Experiencing the same thing, that it rarely responds to messages. Sometimes they come through and the answer is delivered, but rarely. Runnning same setup as @sbowater and the Pi zeros working fine.
Very strange. Addon does not open any ports. MQTT is used only in client mode. The MQTT server is not even installed. The conflict simply has nowhere to come from ...
I will study the problem later - now, sorry, because of quarantine, I have to spend a lot of extra time on my main job.
Version of the add-on
1.0.0
Describe the bug (config/log below)
I am running the HassIO MQTT broker add-on in addition to this Presence Monitor add-on under HassOS on my primary RPi. As an aside, I have three other nodes that only run the Monitor script (RPi Zero W).
I have noticed that the instance of the Monitor script run via this add-on does run it's own internally-triggered scans and provide those MQTT reports (as expected) but most of the time will not respond to requests sent via MQTT (e.g., monitor/scan/echo, monitor/scan/known device states, monitor/scan/arrive, monitor/scan/depart). The instances running on separate RPi's always respond to these MQTT requests as expected.
It got me wondering if there is a fundamental design issue when trying to run the MQTT broker and the Monitor process on the same node. I do not claim to understand linux architecture and especially not Docker, but I thought only one process can listen to a TCP port. If so, I could see the MQTT broker binding to port 1883 and not allowing the monitor script to also listen in on this port (either very often or at all). Is that a potential issue with this approach?
If not, could it be that the HassIO RPi is just too busy to allow a response? It's not as if the incoming MQTT requests are queued up and a response is eventually received, they are just ignored.
Configuration
Log:
The text was updated successfully, but these errors were encountered: