Homey Community Forum

MQTT Hub/Gateway

Hi all,

I have a Problem I didn’t understand. I would like to control my blinds via MQTT in Homey. The Blinds are connected to FHEM.
So I create a Device via the MQTT-Hub. I fill out the topic and States correctly. Now I can change the state from my Blind from 100-1 percent. If I go down with the slider to zero percent it won’t work.
If I sniff with the mqtt-explorer I can see that, when I slide to 0 the state goes away. The complete line is away. If I slide then to 1 percent the line with status : positiin=1 comes back.

Any Idea what I am doing wrong? Or what I can do to fix that problem?

Hi i am trying to sync a dimmer to a virtual devices using The app groups. But the group device cant be shown in mqtt hub devices list. I tried to check all devices and that doesnt do it either. I heard People get groups devices in mqtt hub, so why doesnt it work for me?

Hi everyone,

First of all thank you for the amazing work you have done for this app @HarriedeGroot and @scanno.
Sadly though, I am running into 2 issuse I am unable to resolve myself.

EPS8266 (LSC Wall Plug) flashed running tasmota reporting state via MQTT.

Homey version: 3.2.0-rc.3
MQTT Hub Version: 2.2.5
State Topic: homie/deviceid/Stekker_1/stat/POWER
Set Topic: homie/deviceid/Stekker_1/cmnd/POWER
Homey MQTT Device Name: christmas-bedroom


“onoff”: {
“stateTopic”: “homie/deviceid/Stekker_1/stat/POWER”,
“setTopic”: “homie/deviceid/Stekker_1/cmnd/POWER”

Issue 1:
Tasmota is expecting ON/OFF values for the Set topic and uses those same values for the state topic.
When changing the ‘On/Off values’ setting of the MQTT device to ‘on/off’ I run into a timeout.
The actual setting does seem to have been changes as turning the device on/off works.


Couldn’t find anything about this in the debug log…

Issue 2:
The state topic isn’t processed properly resulting in a out of sync state (Homey reports a ‘Off’ state while the device is turned on and the other way around)

When setting homie/deviceid/Stekker_1/cmnd/POWER to ON/OFF manually (or via the homey device in case it is in sync) the device responds as expected, the state topic is also updated but the change isn’t processed by the mqtt hub app.

The topic is monitored properly it seems as the log reports:

20191212-21:47:01 message: Stekker_1/stat/POWER with value: ON
[turned on using manual mqtt message here]
20191212-21:45:51 message: Stekker_1/stat/POWER with value: OFF
20191212-21:45:50 message: christmas-bedroom/onoff with value: false
20191212-21:45:50 Homie set value [christmas-bedroom.onoff]: false

However it does not result in a ‘Homie set value [christmas-bedroom.onoff]: true’

Looking forward to your reply :slight_smile:

Edit: typo

@HarriedeGroot Thanks for all the great work. I have setup everything as described (Synology + Homey) and it seems to work :slight_smile: The only thing which happens is that Home Assistant loses connection with all devices after a while. This then requires a new broadcast for the devices to appear and work again. Is there a way to not lose connection? I also have my NAS on a autoschedule to turn off during nighttime and restart in the morning. Not sure if that is a problem too. I understand that this has to do with the settings of the birth & last will messages? I couldn’t find a simple explanation / guideline of how I should/can set these up to avoid the necessity of manual broadcasts. Thanks!

I had the same problem, located the problem to Homey itself, solved by making a flow, restarting MQTT client, broker and hub, after waking up server for the day, and a scheduled restart of Homey at 05:00! Now working flawless, Good luck!

Hi all!
Trying to use MQTT Hub to integrate in Node-RED using the Homie-Convention Node.

The problem I encounter, also expressed from the developer is this Node-Red Homie Convention Node relies on the mqtt broker as a persistent database i.e the MQTT messages should be set as retained. Link to Node-RED forum topic

I use the Homey MQTT Broker app, and It may be there the problem is since I read the MQTT Hub send retained messages, anyone who can guide me?

According to the homie convention:

The nature of the Homie convention makes it safe about duplicate messages, so the recommended QoS for reliability is QoS 1 . All messages MUST be sent as retained , UNLESS stated otherwise

I interpret that if the device can’t do it the broker needs to handle it. Storing and saving QoS=0 Messages with retained flag is within the MQTT spec 3.3(?). The broker even should keep those messages. My question is if the Homey MQTT Broker capable of doing that?

I use the Homey MQTT app but with an external broker and the messages are correctly sent and stored retained. The MQTT app is the component that requests this and the broker ‘should’ just do it. I would be very surprised if the internal Homey MQTT didn’t implement this.

Are you using say ‘MQTT Explorer’ as a client. If you log onto your Homey internal MQTT broker and can see the topics/payloads published by the MQTT app then they are retained.

Note that command messages ( the ones ending in a …/set topic) should NOT be sent retained.

You can’t configure an MQTT broker to retain messages by default, they must be originated as ‘retain’


I have moved over to an external MQTT Broker on my Synonymy NAS - Mosquitto Broker. Now everything workes fine :call_me_hand: Have no clue why the internal Homey Broker app did’t worked…

@HarriedeGroot Can you please read this Node-RED forum topic about the Homie Convention implementation in MQTT Hub. I have an discussion with the developer of the node-red-contrib-homie-convention node stating a wrong implementation. I have very difficult to answer him about what is correct or not.

It’s implemented exactly as described by the Node-RED developer (and according the Homie convention).
Did you try restarting both the client & hub apps? Looks like you’ve a (outgoing) connection problem. The current device state should be updated.

Always it is simpler solutions than you first expect… Restart of the MQTT Client and MQTT Hub helped out, now everything is up and running

1 Like

Is that ‘up and running’ with the ‘internal’ or an ‘external’ broker… or both ?
I would hope people could expect a trouble free time with the internal one too.

I needed to use an external Broker to have it stable, it worked with the internal but not fully since the list of devices with theirs properties in the Node-Red convention node wasn’t retained between deploys in Node-Red. I haven’t fault traced why because I don’ t have the knowledge.

Worrying - I have a second Homey with mqtt app and broker installed that I really dont use for that purpose. If I get a moment over New Year I’ll test this out because if it doesn’t retain it’s no use.

First of all, great work on the app!
I finally have everything connected correctly with an external MQTT broker.
On this server i’m experimenting with Node-Red (learning curve!)

I was wondering; the MQTT Hub sends it’s message woth QOS: 0 and no retain.
Is there an option to modify this?

Often when i flip a switch in homey, the switch flips back; i think this is because mqtt hub sends the status and reads some older status at the same time, causing the switch to revert to the read status immediatly.

Therefore i’d like the option in the hub to change the QoS and Retain settings, if possible.

Are you sure - on mine the topics are definitely retained (only the command /set topics should NOT be sent retained).

You aren’t sending those /set messages retained are you which might cause Homey to revert state to the last sent command every time …

… … as in your thinking here.

Really the only thing that might cause a Homey device that you change the state of within Homey to revert back is a new /set command (or some internal flow action in Homey), or it couldn’t actually change the state of the device.

yes, sorry, i was not awake enough :frowning:

I see the sensor-alarms-status etc on QOS:0 and no retain.

shouldn’t switches have a retain as well?
Or is it better to have everything on a QoS:1?
(would be great to experiment with if this comes available in a future update)

(ps. sorry if i sound a bit stupid, just recently started discovering MQTT :slight_smile: )

All state information should be retained - just don’t send /set commands retained
You mean onoff ?? It is…

QOS 0 or 1 is fine with homie - it was designed for either



If i toggle a light from within the homey app and monitor the MQTT channel, i see the light is switched but no retain is set, everything is QOS:0

What sometimes happens is when i toggle a light off from within the Homey app it toggles off and on again.
i have to toggle the light a couple of times before it takes.

It does not happen all the time, just occasionally.
Now, i AM working on a node-red dashboard but i have no ‘active’ functionality in there, i want to understand everything/a lot first before jumping in the deep. (and the WAF is very important here; i must not break stuff)

btw, what is that interface you’re working in from the screenshot?

It is MQTT Explorer - you should use it it’s great

QOS and retained are not connected - the messages from MQTT hub will always be QOS 0 - that is fine. Messages are always sent retained.

So sent QOS 0 and retained.

Higher QOS e.g. 1 or 2 requires retained I think as it needs to support clients that connect after the message was sent. QOS 0 is much less taxing on the broker (as it doesn’t need to know which clients received which messages). QOS 2 is particularly taxing on both the broker and the client.

There is good info here in the MQTT Essentials documents