I’m controlling various devices and services I’ve built myself using MQTT. I was wondering if it would be possible if those devices could be auto discovered and I found the Home Assistant discovery in OpenHab. Sadly this discovery does not support the percentage control I use for those devices.
Is there a better way to implement an auto discovery in OpenHab for my devices? Is there maybe an OpenHab standard for MQTT discovery planed?
Which standard though?
Homie
epshome
tasmota
home assistant
There’s plenty of varying standards and I can’t see Openhab wanting to use a specific one.
Does the homie standard support all channel types and features of the OpenHab MQTT plugin?
Homie standard supports what it supports. Purpose of binding is to match up Homie devices to openHAB, not the other way around.
Home Assistant MQTT discovery supports channels like brightness, for dimmers. What do you think is missing for your use?
Another way of looking at it is there is a standard so no need to make one.
The openHAB mqtt binding supports the homie standard of auto discovery.
Next step is to test it to see if its working on your system. Using the standard create the data to put into mqtt.
Then in paperui ask to discover a mqtt generic thing.
You have to ask as openhab dosent just poll mqtt broker constantly
I already did take a look at the light component, but this would create a color channel. I just need a dimmer channel.
Really? Identifying any color controls in the Home Assistant discovery scheme is optional.
Example -
Homie is not Home Assistant.
You can use the Homie Spec to make mqtt have auto discovery. I guess you are looking for example.
Here you go https://github.com/leifclaesson/LeifHomieLib/blob/master/examples/HomieLibExample/HomieLibExample.ino
This will send messages to mqtt so you can add a thing with some dummy channels and data that changes.
I got it working on platform io using VS code and its all working with dimmer channel
@rossko57 I tried adding a “brightness only light”, but OpenHab still adds a color channel. I also did take a look at the source code of the OpenHab addon and I found no dimmer item in the Home Assistant addon.
@denominator Thanks for the link. I already did take a look at the specification and did some tests. The Homie implementation looks very good and seems to work better with OpenHab. The only thing that is missing is the rollershutter type, but I guess I can just add a string channel and then link this to a rollershutter item in OpenHab.
But only if you keep the devices on homie/+ - if you move it off there, the binding will not find your devices as it’s hard coded in the binding…I did look at making a change as I think the homeassistant one might allow changing the base.
That is no problem. I can change all topics to homie/+ on my devices. So I also have a nice standard over all my devices.
@denominator I have my first problem with the Homie Discovery. I configured a boolean trigger topic (simply a boolean topic without $retained = false) for a smoke alert. The item does appear as a trigger channel in OpenHab, but my rule seems to be triggered 4 times for each message that is sent to the topic. Here is my rule:
rule "SmokeDetector01"
when
Channel "mqtt:homie300:4ce1d806:smokedetector01:smoke#alert" triggered "true"
then
logError("Test", "Triggered")
end
The log appears 4 times for each message I send. Any idea what I’m doing wrong?
Do you know for sure (checked logs) how many messages the MQTT broker is publishing?
Comment - that does not seem like a bad thing for a smoke alarm 
What shows in your events.log ?
While you were testing adding and removing things you may have it more then once in cache
Clean the openHAB cache
@hafniumzinc @rossko57 @denominator Thanks for the hints. It seems that a simple restart of OpenHab fixed the problem. I hope that solves the problem, or could it be that a reconnect to the mosquitto broker registers the topics multiple times?
I had the same issue as you. Multiple triggers showing up in openHAB from only one broker message.
I clear the cache every time I have something unexpected while programming things.
Interested as to why it’s not retained ? In transition false to true it will only ‘event’ once and presumably when cleared it will become false. A new MQTT client connecting would presumably want to know if it was still active… Not retaining state topics is unusual.
If the trigger action, rather than the sensor, is the thing that ‘clears’ the event then it can do that directly on MQTT
There are occasions when we’d like to treat some “binary” information as a bit more than binary.
Example, a smoke alarm state could be represented as “Okay” , “Alarm!”, and “Don’t know yet”. The sensor might not have communicated yet, and some faisafe scheme might want to avoid giving false “OK” signals if it doesn’t actually have positive data.
In the specific case of MQTT … retained data in that context is data supplied by the broker, “last I heard it was like this”, and could be regarded as false indication. I’ve no idea if that is what is going on, just pointing out there can be reasons.