Did you try restarting the mqtt client and Hub apps in this order?
I do it every night - but it seems like those restarts causes this behavior - because during day a manage (by turning off and on each device) to make it report every device…
(forgot to mention - I’m talking about homie convention reporting, didn’t checked that for HA as I do not use that)
one more thing - after 4.2 update - restart of HUB causes my Homey-Pro to stop responding for several minutes (it never happened before 4.2)
I did some testing - definitely HUB is causing restarts of whole Homie.
- if I perform restart of client and then hub app - restart of hub causes restart of whole device
- sometimes it causes boot loop (after restart I have few secs till it starts and reboots device - if I disable App, device boot’s up correctly)
- I’m talking about clean HUB install, no additional config changed done.
Is there a way to turn on debug logs, so I can see what’s causing it?
@Zimo Probably you’ve got some devices spamming your network with frequent device state updates. Try spotting them with mqtt explorer and disable them or change the device settings. E.g. I personally had an Aeotec energy meter causing some trouble, changing the device update frequency fixed it for me.
The startup process (broadcast) is known to be a heavy process, especially when you’ve got many devices connected. The state of every capability of every device needs to be published.
Debug logs can be found in the apps settings ‘log’ tab.
Looks like I found the issue. I had message loop via flows which caused flood of messages. Unfortunately didn’t knew that that might cause restart of whole device (looks like there is some non-managed stack in Athom build).
Anyway - thanks very much for your help. This MQTT hub is something which is moving whole homey one dimension up (without it homey will not be worth the price)…
Hi Magnus_P,
Sorry for warming this up. I’m trying exactly the same for you, using Mosquitto on a separate RaspberryPi. However messages do not seem to get flagged as Retained, so I cannot see anything in NodeRed. Any idea? 
Johannes
@Johannes1702 - As mentioned I restart the app (MQTT hub) every night to refress the Status by disable/enable the app, I do not have any better solution…
I think the beta version now posts messages as retained
Hi All,
I’m running MQTT Hub and MQTT client on a Homey Pro and MQTT Broker on a Raspberry Pi4 to serve a Node Red Dashboard.
Recently I have experienced some strange behavior.
Every day between 16:30 and 17:00 my whole network starts becoming non-responsive and eventually I get a message “De MQTT broker is ONBESCHIKBAAR” in Homey notifications.
In max 1 minute (sometimes even within seconds) it restores itself again and I get the message “De MQTT broker is weer BESCHIKBAAR”
Funny enough two of my switched lights always turn on after this event.
Somehow the state is set to ‘true’ by this event (I concluded from looking in MQTT Explorer)
All the other lights remain off as they should be.
Any suggestions on what may cause these two light to be switched on?
You probably have retained messages:
Thanks.
I watched the video, but… aren’t ALL topics in the Homey MQTT Hub / Broker setup retained?
If I look in MQTT explorer I see the yellow ‘Retained’ message box at every topic.
So having retained messages everywhere should actualy avoid this issue and not cause it as far as I understand. 
Command topics …/set should not be sent retained.
Yes, that seems indeed logical (since the device that will turn on or off will send an update message on its status which message should be retained again, right?).
But how can you tell whether these ‘set’ messages are being retained (or not)?
In MQTT explorer I see the set = “false” entry appear if I use the set command for the first time on the topic for the lamp that turns on after a disconnect.
What I find remarkable is that the entry really appears if I use the set command for the first time and that it doesn’t have a $ in front of it.
Would that indicate that it is not a topic and therefore also cannot be retained?
If you quit MQTT Explorer and restart it - if there is a payload value showing in the topic then it is retained.
The ‘retained’ icon shows in Explorer if the current value was read from ‘retained’ (at connection). If a value is later updated ‘retained’ then does not display (even if the payload has been sent with a retained flag)
hey guys, still facing some irregularities quite often. (Using v2.2.5)
Slowly building a node-red dashboard and switches don’t always correspond to the status of the lights.
Can i place a request to the developer to allow changing some homie-convention parameters within the MQTT Hub app?
For example the QoS / Retain settings.
(pretty please )
I’m not talking about a default setting for everyone but just a little bit more customizable options to the homie-convention settings.
I’m using a separate MQTT server so for example resources on the broker side are not an issue to me.
I see the Fibaro Button in the list of devices in the MQTT Hub,
but the device is neither broadcasted nor the events are not published to the queue…
How should I understand such behaviour?
@Marian what capabilities are listed in the developer portal for this device? The hub provides the ability to expose & control device capabilities over mqtt.
Hmm, None 
That’s bad…
The push button should by my opinion have the capability to send the information if it was pressed. In the Homey Flow definition can be controlled how many times the push button was pressed or held…
I don’t understand why the number of presses cannot be sent as capability… for example as integer value responding to the number of presses (and for holding f.e. -1)…
Button devices are a difficult integration via MQTT - no standards and lots of implementations. Deciding whether pressed states should be retained is one example.
You can create last pressed (from a multiple button controller) but then there’s long press and hold and the subsequent release. I do agree some feedback from a button press via MQTT is useful but only as an event, not a state.
HA does not offer button support or discovery via MQTT.
