Tasmota: MQTT: Follow a convention like Homie

[davidgraeff]

I know about #244 from a while ago, but I wonder if the project is open to a PR to add support for a MQTT convention. In this case Homie.

This would allow auto discovery in openHAB and soon Home Assistant for devices flashed with this firmware.

Cheers,
David

[chaosmaster]

There is already Home Assistant autodiscovery.
See SetOption19

[ascillato]

@davidgraeff

Hi,

As Tasmota already supports autodiscovery for home assistant, please make a PR to add autodiscovery for openhab. Thanks :+1:

[ascillato2]

Closing this issue and waiting for the PR.

@davidgraeff

If you need help, please find us in the Tasmota Chat. Thanks

Support Information

See Wiki for more information.
See Chat for more user experience.

[SymanK83]

@davidgraeff Are you currently working on the pull request? I‘m interested in that functionality and would be willing to pitch in, if possible.

[davidgraeff]

@SymanK83 I can't unfortunately provide that PR myself, as I'm involved in Homie itself and openHAB which already takes some free time away.

[SymanK83]

Would you know, whether somebody is currently working on this? It makes a lot of sense to have this functionality in tasmota and/or homie-esp8266.
I'd be willing to try my best and implement it, but I'd rather not start from scratch if somebody started already ;-)

[davidgraeff]

homie-esp8266 has a PR for 3.0. For tasmota there seem to be nobody working on it right now.

[jochen314]

@davidgraeff Hi, I have the tasmota discovery in openhab running in my local branch. I am in the process of providing the PR for openhab.

[davidgraeff]

@jochen314 Sweet. There are many tasmota users in the OH community. But that doesn't change the fact that a united MQTT convention for all open source IoT projects is still a good idea :)

[jochen314]

I may not have been clear: My branch is using the homeassistant autodiscovery.

[davidgurr]

Does it actually make sense for Tasmota to directly support Homie?

As I understand it, the core Homie concept is that you have a Device with multiple Nodes, each of which has Properties. The classic example given in the Homie docs is a Device of "supercar" with Nodes for "wheels, engine, lights[]" each of which has their own properties.

But a Tasmota device is usually a single function device. In the example above, it's analogous to a Node - you'd have a Tasmota device for each.

It strikes me that Tasmota and Homie would fit much better together by creating a Home bridge for Tasmota. Essentially, an MQTT broker that Tasmota works through. The bridge then sends and receives Homie convention messages to the broker that the HA system is using.

This allows a single Device for all Tasmota Nodes for a whole home.

Comments?

[davidgraeff]

@davidgurr It doesn't matter how many nodes you expose for Homie. The point is auto-discovery for controllers like HomeAssistant, openHAB and so on.

[davidgurr]

Yep, but it seems like a lot of configuration overhead to have multiple Homie Devices (one for each Tasmota device, such as every light switch and power point in a home) rather than a single Homie Device for the whole home, that has one node for each Tasmota device.

[davidgraeff]

Tasmota can also follow the HomeAssistant MQTT convention and use 3 MQTT topics instead of 12 (but MUST include a json dependency on the other hand).

It's the task of the controller to unite all your small different IoT devices that expose one or two functions only. But your IoT device must be able to tell in a machine friendly way what its capabilities are.

[davidgraeff]

@ascillato2 I suggest to re-open this issue, because new users and developers will not find closed Issues and there seem to be interest in auto-discover tasmota :)

[ascillato]

Hi,

This issue was closed waiting for a PR. Please, make a PR. If you need assistant on that (PR, code, tasmota structure) just ask here or in the Tasmota support chat. We are willing to help. Thanks

[davidgraeff]

I have no time for a PR unfortunately. Tasmota is not exposing itself via MQTT only, so there is no immediate need to be discover-able via a standardized interface.