Hi,
I’ve recently bought some ITEAD Sonoff devices to test them and after analyzing and testing the available custom firmwares I went for ESPurna (the other option was Tasmota). I’m happy with this decision but I realized I’m missing something: the DISCOVERY. I was able to integrate devices into openHAB using MQTT but it is really painful to configure all the topics for all the items. ESPurna is able to publish the device configuration to MQTT so all we need here is a binding listening for this configuration topic based on which openHAB things could be created FOR ALL devices running ESPurna firmware on the local network. What do you think?
Good idea!! There is something like this for the new MQTT 2.4 binding but for the Homie standard.
Please @David_Graeff on how to implement this for ESPurna.
The idea is to create a binding with generic thing types like generic switch, sensor, etc., and when a new configuration is published by the devices running ESPurna firmware the binding could discover a device in openHAB and add channels dynamically (e.g. switch for switch type device or number channel for a sensor measuring voltage). This way all devices running the firmware on the local network would appear in openHAB too with dynamic channels matching the capabilities of the device. These channels could be linked to the items as usual - no more MQTT topic mistyping.
The mqtt 2.4 binding is doing exactly this for two other mqtt conventions. But it would help a lot to convince the firmware developers to adopt the Homie mqtt convention instead, in my opinion. You could at least try at their bug trackers.
If you really want to add this support, have a look at the mqtt generic bundle in the eclipse Smarthome repository (openHAB is based on eclipse Smarthome).
Cheers David
Yes! This is the same I was thinking about… ESPurna supports HomeAssistant convention so this should be OK. I’ll test this in the next few days.
Thanks
@David_Graeff
Hi,
I tested the binding with ESPurna/HASS integration but it doesn’t seem to work on M7. In HomeAssistant the device is discovered and I’m able to control it. In openHAB the device is also discovered but it never comes ONLINE. Any suggestion where to look?
Thanks
Not the full HomeAssistant convention is implemented. It would help if you could find out which MQTT components are used by ESPurna.
BTW why did you choose to implement this integration embedded into MQTT binding. IMHO the MQTT is the transport protocol and these integrations (homie, ha) are something on the top of this protocol. It would be also strange to have all the things in the same binding that use HTTP protocol for communication…
Hm, I think you misunderstand. They are conventions not “integrations” and their only purpose is to allow auto discovering.
The same goes for a http binding (there is a new http 2.0 binding by Brian in the making btw, see https://github.com/openhab/openhab2-addons/pull/4342). To allow auto discovery of a Restful service, a specification like Swagger/OpenAPI can be realized and that would also be done within the http binding.
I’m testing with a simple Sonoff S20. Adding it as general MQTT thing works… In connection with the discovery: the configuration is published under topic homeassistant/switch/SonoffS20_0/config and the json payload is
{
"name":"SonoffS20",
"platform":"mqtt",
"state_topic":"homeassistant/switch/SonoffS20/relay/0",
"command_topic":"homeassistant/switch/SonoffS20/relay/0/set",
"payload_on":"1",
"payload_off":"0",
"availability_topic":"homeassistant/switch/SonoffS20/status",
"payload_available":"1",
"payload_not_available":"0"
}
For some reason this discovery doesn’t seem to work for me. This is the related documentation for ESPurna.
Does this mean that there should be a binding on the top of mqtt.generic extending e.g. HomeAssistantThingHandler to support ESPurna devies?
No that means, feel free to complete the implementation of the HomeAssistant specification so that ESPurna devices work as well 
Although I thought that the HomeAssistant MQTT Switch component works. Haven’t tested it with real live devices though.
If ESPurna is not fully complying to the specification, they should fix it instead though.