How set up the "native Tasmota discovery"?

Setup, Configuration and Use Beginners
, ,
1

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
2

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).

3

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:

4

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.

5

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?

6

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.

1 Like
7

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.

8

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)
9

The Home Assistant discovery in Tasmota was dropped since Home Assistant has deprecated. Many new Tasmota functions in the old deprecated discovery simply is not supported or is faulty.
So the decision was made to phase out. The new method was coordinated with the maintainer of the HA Tasmota Part of HA. The new way is much more resource-friendly and future-proof.
Oh yes, Homie standard. Too much overhead for Tasmota. So we decided not to implement.
To me, i am the maintainer of the Platformio fork/setup and the modified Arduino frameworks.
In short SetOption19 1 is dead!

Greets Jason2866

P.S. For any questions do not hesitate and ask in Tasmota github discussions.

3 Likes
10

is there any hope that there comes a solution like a tasmota binding for openhab with tasmota autodisvovery or as a function at the mqtt binding,

im not able to do that but may be there is someone who is able to do that and is inspired on these sentence by reading thee post… would be great

11

There’s always hope if someone wants to put in the time, but there’s no guarantee that someone will do that. It generally relies upon a developer thinking that something would be useful for their own purposes and then sharing their work (as with all open-source software).

I think it’s more likely that someone will add Tasmota discovery to the MQTT binding, since the framework already exists. I imagine it would be much harder to create and maintain a dedicated Tasmota binding, but I could be wrong about that.

3 Likes
12

You know what, I just stick to Tasmota 11, done!
setoption19 1 is and remains alive :slight_smile:

13

i did it also these way … after the initiation and setup in openhab i go on the actual firmware via update…

14

Indeed and still working :smiley:
Please keep in mind that I only used this on a single device: Blitzwolf BW-SHP2 16A
Please check before using the links I put below.
Downgrade
Download firmware: Tasmota ESP8266 Binaries
Or directly

Firmware upgrade → OTA Url: http://ota.tasmota.com/tasmota/release-11.1.0/tasmota.bin.gz
Set option
Terminal → setoption19 1

Add via the inbox

Upgrade
Firmware upgrade → OTA Url: http://ota.tasmota.com/tasmota/release/tasmota.bin.gz
And still working, and back on 12

1 Like
15

I have working binding from Joerg from

Implemented features working fine in 3.4.2 too, but when I’d like add upgrade functionality, I’d like add version info as item. I found SW in thing/Information/Properties/StatusFWR.Version
Because is things autodetected, I can’t add custom Items. Is the way howto provide this values into widget or label?

16

Yes but then you only get a switch back and that is it.

.Just confirmed on version 13 discovery is still not working.

So still downgrading them to 11.

Link to the instructions and Tasmota11

17

I create workaround like this. Not practicaly, but works.

UID: mqtt:topic:1c1d57612a:87f87a0a40
label: tasmota-firmwares
thingTypeUID: mqtt:topic
configuration: {}
bridgeUID: mqtt:broker:1c1d57612a
channels:
  - id: sonoff-obyvak-down
    channelTypeUID: mqtt:string
    label: sonoff-obyvak-down
    description: null
    configuration:
      stateTopic: tasmota/discovery/840D8E679B23/config
      transformationPattern: JSONPATH:$.sw
  - id: sonoff-obyvak-up
    channelTypeUID: mqtt:string
    label: sonoff-obyvak-up
    description: null
    configuration:
      stateTopic: tasmota/discovery/840D8E685B96/config
      transformationPattern: JSONPATH:$.sw
18

Are there any plans for OH4 that it supports the Tasmota MQTT Autodiscovery?

19

I have same question. I’m not developer but maybe working implementation in HA will be helpfull to do this in OH.

20

Joerg’s work is still the only thing I’ve seen towards supporting Tasmota’s native auto discovery, and that seems abandoned at this point. I’m the maintainer now for the core MQTT binding, as well as Homie and Home Assistant discovery (and to a lesser extent, espmilighthub), but I don’t use Tasmota so don’t plan on implementing that myself. So… no, it doesn’t look like it’s coming anytime soon unless someone else steps up to finish Joerg’s work.