I have a few Tasmota devices and use the official Tasmota integration (Tasmota - Home Assistant).
I noticed that a Tasmota device was unavailable
I visited the device and the device looked alright looking at the console. Then I activated SetOption19 0 (one of the requirements) and the device suddenly came available in HA. This device was visible in HA but it appears it suddenly 'has lost" this setting. Why would that be the case? I remember this happened a few months ago.
Seems odd for a single device to change setting to SetOption19 1, especially as Tasmota versions >11 completely remove HASS discovery, effectively mandating SetOption19 0 and the Tasmota integration (which works better as it supports measurement units).
Could you have accidentally set SetOption19 1 instead of something else like SetOption30 1?
Certainly my own Tasmota devices haven’t changed, despite some changes to internal memory layout and settings data formats in the internal flash memory. My many devices are upgraded regularly* to avoid odd setting format issues - used to happen circa release 4 requiring a clean install occasionally.
*Simple command line to update ALL Tasmota devices (would also work from the HASS MQTT service MQTT: Publish under dev tools):
# Use mosquitto_sub or https://mqtt-explorer.com/ to view the results
mosquitto_pub -d -h BROKER_IPv4 --username 'uname' --pw "passw" -t 'cmnd/tasmotas/STATUS' -m '2'
# Update all
mosquitto_pub -d -h BROKER_IPv4 --username 'uname' --pw "passw" -t 'cmnd/tasmotas/upgrade' -m '1'
If this helps, 
this post!
Thanks for that. Tried the upgrade process given I’m running a really old release of Tasmota but got an error on the console
MQT: stat/tasmota_CFC67A/UPGRADE = {"Upgrade":"Failed File Not Found (404)"}
When I checked the OTA URL I realised this has changed. Do I need to manually change the OTA URL by going to the console of each Tasmota device or can I do this via MQTT as well?
Ah - there was a change to OTA release URIs some time ago, but it’s easy to change. From my notes (check the URL!):
# UPGRADE - two step (set OTA URL, then ask to download...)
mosquitto_pub -d -h BROKER_IPv4 --username 'uname' --pw "passw" -t 'cmnd/tasmotas/OTAURL' -m 'https://ota.tasmota.com/tasmota/release/tasmota.bin.gz'
mosquitto_pub -d -h BROKER_IPv4 --username 'uname' --pw "passw" -t 'cmnd/tasmotas/upgrade' -m '1'
If you have older versions, I’d read the docs, as there are intermediate firmware steps if you want to keep existing settings (personally, I’d wipe and use backlog commands on the console to configure the lot in one, but things have worked well for several upgrades once current).
# NB now use Tasmota integration so SetOption19 0
Backlog mqtthost BROKER_IPv4; mqttuser uname; mqttpassword passw; topic tasmota-9999; hostname tasmota-9999; FriendlyName Test-9999; FullTopic %prefix%/%topic%/;SetOption19 0; setoption53 1; SetOption30 0;
Moving away from HASS Discovery apparently saved a load of flash storage and memory with the complexity now in the Tasmota Binding on the server (and log-term graphing works with units as a bonus). This should mean less change in the device settings format.
More MQTT help if you need it can be found here:
Thanks. Very helpful… This allows me to save these instructions for more frequent updates.
btw, the SetOption19 was 1 for all the devices but given I communicate via MQTT I didn’t notice. I’m rebuilding my HA instance and hence found out.
Thanks again
I have about 10 Tasmota devices and TWO of them lose communication every time I reboot my HA system. I realized that Setoption19 was getting set to 1 occasionally, but it took me a while to figure out that it was the HA reboot (not rebooting the Tasmota) was triggering it. Now that I realize that, it’s very consistent. I can go for days with no problems, but when it’s time to reboot HA (i.e. for an upgrade) I can check Setoption19 just before the reboot (OFF), reboot HA, and then check Setoption19 again (it will be ON). Every time I reboot I have to access those devices and set it back to OFF.
The two problematic devices are different brands of smart plugs, and I have other devices of those same types that don’t demonstrate the problem. I can’t see anything different about the way those devices are configured!
My advice would be to reflash the troublesome devices from scratch - e.g. cable, erase, flash.
There have been some changes to memory layouts from old releases, but more likely, a part of the FLASH is getting tired and a reflash might fix any memory corruption.
If this helps, this post!