How set up the "native Tasmota discovery"?

Hi everyone!

So, I’m doing a new OH3 installation (openhabian image) because everything got way messy and glitchy with the one that was upgraded from OH2. Trying to stay close to “intended use” this time. The preferred way to set up tasmota devices appears to have changed at least 2 times since I last did it and it’s hard to find up to date information. I’m probably looking for what is in some places described as the “new / tasmota / native autodiscovery” method (which should be the successor to the “deprecated MQTT / homeassistant autodiscovery”)?

What is the preferred (mainly UI) way to do it now? Can someone correct / fill in some blanks? Looking for the future-proof approach. I guess…:

  • install mosquitto (is it considered deprecated now? still available via ssh/openhab-config; discussions on whether it should still be used seemed to be going nowhere? Or was that just about the UI addon that I can’t find anymore?)
  • add mqtt server binding to things
  • install JINJA transformation (why is this not done automatically?)
  • Update all tasmota devices to newest version (i did that part)
  • setoption19 should be 0? (set to 1 and back to 0 to trigger detection?) That means, NOT the hassio detection should be used but tasmotas own new thing?
  • I have to set topic, client, full topic to the new defaults that are apparently listed NOWHERE? And which setting will later be the name of the device in openhab? Is it the “client”? I think client needs to have a value distinct from the other variables, so it is usually prefixed with the user name which is “DVES” by default for some reason? Also somewhere I read I should use the MqttUser to name devices, but somewhere else I read that’s bad and I should use the same for all Tasmota devices at least?
  • The homeassistant autodiscovery still seems to work and I accidentally triggered it, so now I probably have to discard all “mqtt:homeassistant_” devices?

So, the tasmoadmin (is a great help, works fine as raspie docker) commands I have to run should look something like this…( assuming I already set a unique hostname on all devices, to whatever I want the device to be named later):

setoption3 0; #turn off mqtt
setoption19 1; #turn on deprecated autodiscovery?
SetOption10 1; #clear old topic on topic change
DeviceName %hostname%; #no idea where this is used
FriendlyName %hostname%; #no idea where that is used
SetOption55 0; # disable mDNS? Helps with arp problems? No idea.
SetOption55 1; # enable mDNS? Helps with arp problems? No idea.
MqttClient DVES_%hostname%; #might reboot?
Topic %hostname%; #results in reboot?
FullTopic %prefix%/%topic%; # probably another reboot T_T
MqttHost 0; #turn on autodiscovery of mqtt host, is this reliable?
# MqttHost openhabian; # or should I set it to openhab hostname? manual says 'do NOT use .local'
# MqttHost 192.168.1.111; # IP is probably most reliable - until it changes -_-
MqttPort 1883; # should be default but why not make sure
MqttPassword 0; #not using password for now
setoption3 1; #turn on mqtt, hope it doesn't reboot
setoption19 0; #turn on 'native' autodiscovery?
# Change color scheme to mark finished devices: 
WebColor {"WebColor":["#eaeaea","#252525","#282531","#eaeaea","#282531","#d7ccff","#1d1b26","#ff5661","#008000","#faffff","#694fa8","#4d3e7f","#b73d5d","#822c43","#1f917c","#156353","#faffff","#716b7f","#eaeaea"]};

And then, the devices should - in theory - be auto-discoverable again, this time the “native” way… somehow? All of this is likely wrong, so what’s the right way to do it? Is there some WIP stuff I should prepare for / install workaround until it’s implemented?

( Testing this is problematic with my setup, because I have that popular bug that results in devices disappearing after they reboot until you do random stuff like hit an asus router with a shovel, turn electricity for the whole house off and on again a couple of times and pray to your favourite animist deity for 21600 seconds. So any advice that helps me keep the amount of times I have to go through that ordeal to a minimum is highly appreciated! )

1 Like

Can you point out some of these resources. I did a couple of searches and I’m not finding anything about a Tasmota autodiscovery that isn’t Home Assistant autodiscovery. I’m running the latest snapshots and I’m not seeing Tasmoata as a choice for autodiscovery.

As far as I’m aware, Home Assistant mode remains the only way to autodiscover Tasmota devices in OH.

The way autodiscovery works in OH is that there are certain standards in the ways that MQTT topics are layed out and the way messages are sent. The MQTT Binding, when told to scan for Home Assistant or Homie or any of the other supported standards will look for topics that conform to those standards. So when you scan for devices, you have to tell OH what standard you are scanning for. That’s why the list of options when you click to add an MQTT Thing is so long. So I would expect to see a Tasmota entry in the list and there isn’t one.

Seems like that might be better addressed first as you cannot always be there every time you reboot (e.g. power loss).

The information is sort of a mess and all over the place and most of the discussions go nowhere. It used to be ‘setoption19 1’ for discovery, but now it’s ‘setoption19 0’ for the new one and ‘setoption19 1’ is the old one or (soon?) turned off. Not sure what they’re planning to do about backwards compatibility, possibly nothing.

Tasmota/CHANGELOG.md at development · arendst/Tasmota · GitHub
Prepare to remove dedicated Home Assistant discovery in favour of Tasmota Discovery and hatasmota

SetOption19 Tasmota discovery protocol used in Home Assistant Tasmota integration
0 = enable Tasmota discovery (default)
1 = use deprecated MQTT discovery (only with #define USE_HOME_ASSISTANT, does not exist in release binaries)

Tasmota devices configured for native discovery (SetOption19 0)

USE_HOME_ASSISTANT has been removed from standard binaries in favor of TASMOTA_DISCOVERY
You are strongly advised to move to the HATASMOTA plug-in as the old way is in way of absolescence

If you absolutely want to use the old and deprecated way you’ll have to compile yourself.

Also there’s some stuff here already that might or might not be related:

OK, so anything that Tasmota does on their end isn’t necessarily going to be supported on our end automatically. Just because Tasmota has decided to implement their own brand new discovery protocol rather than using an existing one like Homie doesn’t mean anyone has made the necessary changes to OH to support it.

As you can see in that first thread from our forum, a github issue was opened and it remains open, meaning this has not been implemented and merged. There isn’t even a PR yet.

The second link is on a thread where someone wrote a dedicated Tasmota add-on but for OH 2.5 (so it won’t work in 3.x) which was never published to the marketplace nor submitted to the OH project proper to become an official add-on. I see no effort made to update this add-on for OH 3.

So, it appears that you either have to compile Tasmota yourself to renable Home Assistant support or you can’t use automatic discover on Tasmota any more and have to manually create the Generic MQTT Things.

It’s annoying that they decided to go invent a brand new standard rather than using one of the existing ones. But not invented here pervades even open source projects too. I’m sure OH has does the same more than once.

Yes, that is why I’m asking what the OH way to deal with this is. People on both the OH end and the Tasmota end seem to be working on this in different places, more than the ones listed, but most of them either behind the scenes or they gave up. Anyone seen any recent activity? Would be nice to have some pointers on where this might be going / what we should do in the meantime. So people can at least try to stay close to the default solution and avoid making something that turns into a huge mess again after some OH update.

So, does that mean mqtt:homeassistant is as of yet the best supported method for including Tasmota devices? Last time I still used config and scripts, but all of that broke around the time OH moved unto a more GUI heavy path… where it will probably continue?

I don’t know about others, but my way of dealing with it is to not use autodiscovery at all. I just manually define the bridge and things. Obviously that can be a pain if you have a lot of Tasmota devices, but once you’ve done it, you generally won’t need to do it again.

The closest to a default solution would be manually defining the bridge/things and ignoring autodiscovery. I say “closest” because manual definitions don’t rely on things beyond our control (e.g., Tasmota dropping HA autodiscovery).

How did it break? I haven’t changed anything in the mqtt.things file I moved over from OH2 to OH3, and it works just fine. There was never a requirement to move to the GUI, and as far as I’m aware there are no plans to remove text configuration from OH3.

As I said and @rpwong also said, your two options are too recompile Tasmota to reenable HA discovery, or manually set up OH using Generic MQTT Things. There is not support in OH right now for Tasmota discovery and it doesn’t appear that anyone is actively working on adding it.

@rpwong also agreed the text config comment. They are as well supported in OH 3 as they were in OH 2. Just because UI options have been added doesn’t mean the text configs where removed.

Info I was missing:

  • Variables don’t work directly in Tasmota commands but there are various easy to find bash scripts to set the name, topic, etc around.
  • One problem with the home assistant discovery is the available space on the IoT device. Some other stuff needs to be deactivated and then still - for OTA flashing - most devices might need to be flashed to the intermediate light version first. Dropping 10-11k worth of stuff should be enough.
  • Example unser_config_override.h for compiling Tasmota with homeassistant support:
/// activate discovery
#define USE_HOME_ASSISTANT                              // Enable Home Assistant Discovery Support (+12k code, +6 bytes mem)
#define HOME_ASSISTANT_DISCOVERY_PREFIX "homeassistant" // Home Assistant discovery prefix
#define HOME_ASSISTANT_LWT_TOPIC "homeassistant/status" // home Assistant Birth and Last Will Topic (default = homeassistant/status)
#define HOME_ASSISTANT_LWT_SUBSCRIBE true               // Subscribe to Home Assistant Birth and Last Will Topic (default = true)

// gratuitously drop random stuff to reduce firmware size. 
#undef USE_EMULATION_HUE     // Enable Hue Bridge emulation for Alexa (+14k code, +2k mem common)
#undef USE_EMULATION_WEMO    // Enable Belkin WeMo emulation for Alexa (+6k code, +2k mem common)
#undef USE_TASMOTA_DISCOVERY // Enable Tasmota Discovery support (+2k code)
#undef USE_DOMOTICZ          // Enable Domoticz (+6k code, +0.3k mem)
#undef USE_TIMERS            // Add support for up to 16 timers (+2k2 code)
#undef USE_TIMERS_WEB        // Add timer webpage support (+4k5 code)
#undef USE_SUNRISE           // Add support for Sunrise and sunset tools (+16k)
#undef SUNRISE_DAWN_ANGLE    // Select desired Dawn Angle from (DAWN_NORMAL, DAWN_CIVIL, DAWN_NAUTIC, DAWN_ASTRONOMIC)
#undef USE_SHUTTER           // Add Shutter support for up to 4 shutter with different motortypes (+11k code)
#undef USE_IR_REMOTE         // Send IR remote commands using library IRremoteESP8266 (+4k3 code, 0k3 mem, 48 iram)
  • Some items can’t work without the new discovery method due to limitations of… HA / mqtt serialization or something, but most will work.
  • Once discovered/added, the devices will keep on working even after they are flashed to a stock version of the firmware that does not have HA discovery support (not tested extensively. Might need to make the additional changes to topic etc that are performed when setoption19 is first set to manually)