OK, thanx, I did the subscription, but didn’t know about the device behaviour (delayed response).
There is a possibility to get via MQTT Hub the zone a device belongs to?
Change the setting in MQTT Hub to from Homei 3.0.1 to Custom and you can send the zone as well.
Hmm, ok, it is also a solution.
But the zone of the device doesn’t change, why to send it by every MQTT message in the topic?
Would it be possible to get the zone by broadcasting the device info via homeassistant?
…for example to send additional mqtt message with $zone value?
(format as $type, $name, $properties)?
@Marian That’s exactly where the custom protocol is for. It even includes the option to add the zone to the topic as stated above. This also adds the possibility to listen to all device changes in a zone by using topic wildcards.
By default the Hub follows the Homie Convention.
Hallo Harriede,
sure, I understand the extension in custom protocol.
What is not nice, that it changes the format of the topic in compare to Homie Convention 
For me it would be enough to get the “device zone” info once, not in every message.
May be think once more about the possibility to send the $zone property during the discovery… 
Hello,
I visited openHab forum and I found out how to install 2.5 M4,
And now Mqtt homie connection works better and more stable.
When I disconnect the broker, I just have to broadcast via Mqtt hub and it works again 
I will wait few weeks and do some tests now, before make my dashboard.
Many thanks from France 
1 Like
I have been running combination broker+hub+client direct on Homey for couple of hours.
By not very intensive MQTT communication sunk the free memory from 17% to 4% and is further sinking… (info about free mem on homey received via MQTT topic homey/system/info)
There is a way to find out which Homey application consumes the memory?
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.
Situation:
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
Settings:
{
“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.
Log:
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 
Edit: typo
@HarriedeGroot Thanks for all the great work. I have setup everything as described (Synology + Homey) and it seems to work 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’
Kevin
I have moved over to an external MQTT Broker on my Synonymy NAS - Mosquitto Broker. Now everything workes fine 
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
