I have got version 2.4.0.000 of OpenHAB, and what auto-update do you mean, updates of the app itself? That I have on auto-update, yes. The MQTT Hub app I currently have is version 2.1.1.
You may well find that v2.5 of openHAB fixes this issue for you, although obviously it’s not a released version for a while yet. 2.5 Milestone build 1 is in the developer branch but milestone 2 is going to be a significant update. Current snapshots are not too stable as so much is being changed. There are some known issues in the homie3 implementation in OH2.4. I am not suggesting you update by the way if it is working for you !
I asked about the auto update of MQTT-Hub as I just wondered if that had triggered your issue in OH - not because anything broke but because OH2.4 is very sensitive to timing updates from homie3 and the update might have manifested this.
Available in the store:
Version 2.1.2
- Homie Convention integer datatype fix
1 Like
@xAPPO Just tested: The Hub correctly broadcasts both the HA Discovery configuration and all device states when I publish the payload ‘online’ to topic: hass/status (as configured in both HA & the MQTT Hub app).
not sure how HA config should be, there is no hass/status does not live in homeassistent topic. i’ll share my config:
mqtt:
discovery: true
broker: broker IP
username: !secret mqtt_username
password: !secret mqtt_password
birth_message:
topic: ‘hass/status’
payload: ‘online’
will_message:
topic: ‘hass/status’
payload: ‘offline’
should I configure homeassistent topic somewhere?
Is the actual config indented? Indention is mandatory in yaml files.
yes the config is properly indented, config check does not report any errors.
@Leon_van_Efferen see HA MQTT Discovery. You’re missing the discovery_prefix.
mqtt:
discovery: true
discovery_prefix: homeassistant
broker: broker IP
port: broker PORT
birth_message:
topic: 'hass/status'
payload: 'online'
will_message:
topic: 'hass/status'
payload: 'offline'I wonder what is different between yours and mine (using 2.1.2) ?
The homeassistant topic is not resent if I send offline then online to hass/status.
Do you have QOS setup or retain in your configuration.yaml ?
@xAPPO Strange. Don’t see a difference in configuration. Version is fine and I don’t have a qos or retained config in my yaml.
Does broadcast or switch on/off HA Discovery in app settings publish any messages on the homeassistant topic?
Broadcast does … about a couple of minutes later… I will try switching on/off HA discovery.
I’m purging the MQTT-Explorer tree for homeassistant and homie before toggling hass/status - neither populate again…
How long should it take to send the homeassistant tree? I notice at startup it goes out fairly early before the status messages. Takes maybe 3 mins or so from restart app to fill.
I also now noticed (some 30 mins later) that the homeassistant topic has been populated sometime whilst I was eating. Maybe I’m not waiting long enough. I’ll see just when that arrives… I don’t have Broadcast System state or Commands on.
Can I find anything in the log that helps ?
Hmm … I’ve some other things not working now in HA … including onoff not populating set although dim is. Let me investigate some more and post back
I´ve set up a connection to Home Assistant without problems. Homey devices are discovered, but I´m facing some difficulties controlling lights that are simple on/off (without dim). I suspect it is related to the “on_command_type” topic. It seems to be configured to use “brightness” instead of default “last”. Thus only brightness command is sent instead of payload_on to turn the light on.
I haven´t had time for more thorough testing so forgive me if I´m wrong on some point. MQTT-explorer snapshot and Home Assistant link below for reference.
on_command_type
(string)(Optional)Defines when on the payload_on is sent. Using last (the default) will send any style (brightness, color, etc) topics first and then a payload_on to the command_topic . Using first will send the payload_on and then any style topics. Using brightness will only send brightness commands instead of the payload_on to turn the light on.
@Gustav_Tillback You’re probably correct. on_command_type is set to ‘brightness’, because another user reported non working devices due duplicate messages with the ‘last’ setting (2 messages are sent, dim & onoff).
What I’m going to try: for devices with device class ‘light’ the setting will become ‘last’, for other devices with dim capabilities (e.g. sockets) it will remain ‘brightness’. Hope this will work for both parties…
@xAPPO this will probably solve your issue with the onoff state to.
1 Like
Do you have MQTT integration enabled from HA as well? I did and the integration overrides the configuration.yaml.
My working config:
MQTT Hub settings default.
Hi Gustav - yes late last night I found that it was the on_command_topic too and if you manually edit it back to something like ‘last’ and publish it then it works.
So your fix sounds good Harrie.
Leon - can you just expand on that ? I have configuration.yaml setup correctly and I do have the MQTT integration + some manually entered MQTT devices - and mostly it works. It’s just last will I’m not convinced about yet. Are you saying in some way that it is being overridden from its inclusion in configuration.yaml ?
What I am currently thinking causes my issue is that I may have two MQTT clients setting hass/status rather than just the one. I’ll have to think how to best handle that in terms of maybe logic and ing the topic, to get MQTT-Hub to resend topics if needed.
I did also notice Harrie that when disabling devices it removed them from the homie/homey topic tree but created another named literally homie/deviceID (may have been device_ID, DeviceID or something) and inserted each device into this new tree . Following a restart it seems to have gone from the MQTT broker.
Whilst moving the devices it left one or two residual topics retained within each device in the original tree so the original homie/homey tree still contained all the device root topics. I think it leaves $format and $unit and in some cases $name.
Is that as expected ?
Update: Looks like those residual topics do get set to not retained but not deleted like the other ones. If I restart the connection from MQTT- Explorer to the broker they are gone.
@Gustav_Tillback Thanks!
The suggested change is pushed to the beta branch. You can try it if you want. It will be available in the store asap (beta channel).
You’re welcome! Keep up the good work.
Will try to test it later this evening when kid is asleep. .
install HA log viewer and reboot HA, it will tell you that MQTT settings from configuration.yaml are overridden by the MQTT integration. after deleting the MQTT integration all started working. Birth & Will messages are not enabled/configurable by MQTT integration (i’ve read somewhere, link)
Last Will is only send at ungracefull shutdown (link), so its expected not to see an will message when rebooting.
@HarriedeGroot a little different question, when using auto discovery the Homey devices are named <HomeyDeviceName - Aangezet> in HA. it seems they become their name from the name that’s in OnOff topic! see image. I would rather see that the device is name like in Homey is this case “keukenled” this “problem” only occurs with switch devices, other classes are name correctly.
