Tasmota Integration: Unavailable Devices After Reboot

Configuration
1

I recently switched from native MQTT integrated Tasmota outlets, to the new Tasmota integration thinking it would help my issues.

All four of my mains powered Tasmota 9.3.1 outlets are SUPER sensitive/fickle to any hiccup in my HASS setup, forcing me to manually invoke a reboot of the devices through their web ui. If my Home Assistant docker container updates overnight (on 2021.3.0), router patching that drops my wifi/network, etc…then all the devices go into an “Unavailable” state in HASS until restarting the outlets.

image
image1437×887 66.7 KB

image

Post-reboot console:

00:00:03.254 HTP: Web server active on tasmota-headboardlights with IP address 10.10.100.178
00:38:51.482 MQT: Attempting connection...
00:38:51.497 MQT: Connected
00:38:51.500 MQT: tele/tasmota_headboardlights/LWT = Online (retained)
00:38:51.502 MQT: cmnd/tasmota_headboardlights/POWER = 
00:38:51.509 MQT: tele/tasmota_headboardlights/INFO1 = {"Module":"Aoycocr X5P","Version":"9.3.1(tasmota)","FallbackTopic":"cmnd/DVES_F27C15_fb/","GroupTopic":"cmnd/tasmotas/"}
00:38:51.518 MQT: tele/tasmota_headboardlights/INFO2 = {"WebServerMode":"Admin","Hostname":"tasmota-headboardlights","IPAddress":"10.10.100.178"}
00:38:51.531 MQT: tele/tasmota_headboardlights/INFO3 = {"RestartReason":"Software/System restart"}
00:38:51.539 MQT: stat/tasmota_headboardlights/RESULT = {"POWER":"OFF"}
00:38:51.547 MQT: stat/tasmota_headboardlights/POWER = OFF
00:38:53.670 QPC: Reset
00:38:55.627 MQT: tele/tasmota_headboardlights/STATE = {"Time":"2021-03-05T00:38:55","Uptime":"0T00:00:09","UptimeSec":9,"Heap":28,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":25,"MqttCount":1,"POWER":"OFF","Wifi":{"AP":1,"SSId":"Grand Central","BSSId":"E0:63:DA:74:14:BE","Channel":6,"RSSI":80,"Signal":-60,"LinkCount":1,"Downtime":"0T00:00:04"}}
00:39:01.943 MQT: tele/tasmota_headboardlights/STATE = {"Time":"2021-03-05T00:39:01","Uptime":"0T00:00:15","UptimeSec":15,"Heap":27,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"POWER":"OFF","Wifi":{"AP":1,"SSId":"Grand Central","BSSId":"E0:63:DA:74:14:BE","Channel":6,"RSSI":80,"Signal":-60,"LinkCount":1,"Downtime":"0T00:00:04"}}
00:39:01.966 MQT: stat/tasmota_headboardlights/RESULT = {"Time":"2021-03-05T00:39:01","Uptime":"0T00:00:15","UptimeSec":15,"Heap":27,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"POWER":"OFF","Wifi":{"AP":1,"SSId":"Grand Central","BSSId":"E0:63:DA:74:14:BE","Channel":6,"RSSI":80,"Signal":-60,"LinkCount":1,"Downtime":"0T00:00:04"}}
00:40:04.241 MQT: tele/tasmota_headboardlights/STATE = {"Time":"2021-03-05T00:40:04","Uptime":"0T00:01:18","UptimeSec":78,"Heap":27,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"POWER":"ON","Wifi":{"AP":1,"SSId":"Grand Central","BSSId":"E0:63:DA:74:14:BE","Channel":6,"RSSI":74,"Signal":-63,"LinkCount":1,"Downtime":"0T00:00:04"}}
00:40:04.264 MQT: stat/tasmota_headboardlights/RESULT = {"POWER":"ON"}
00:40:04.269 MQT: stat/tasmota_headboardlights/POWER = ON
00:43:55.720 MQT: tele/tasmota_headboardlights/STATE = {"Time":"2021-03-05T00:43:55","Uptime":"0T00:05:09","UptimeSec":309,"Heap":27,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"POWER":"ON","Wifi":{"AP":1,"SSId":"Grand Central","BSSId":"E0:63:DA:74:14:BE","Channel":6,"RSSI":78,"Signal":-61,"LinkCount":1,"Downtime":"0T00:00:04"}}
00:48:45.623 APP: Serial logging disabled
00:48:55.660 MQT: tele/tasmota_headboardlights/STATE = {"Time":"2021-03-05T00:48:55","Uptime":"0T00:10:09","UptimeSec":609,"Heap":27,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"POWER":"ON","Wifi":{"AP":1,"SSId":"Grand Central","BSSId":"E0:63:DA:74:14:BE","Channel":6,"RSSI":78,"Signal":-61,"LinkCount":1,"Downtime":"0T00:00:04"}}

To set the outlets up, all four devices were switched back to SetOption19 0 from SetOption 1for them to show up in HASS’ Tasmota integration. Is that setting not persistent? The MQTT container is configured as shown in the screenshot. I have also setup a HASS startup automation to restore the device states:

image
image514×1033 27.1 KB

  - id: Sync Tasmota states
    alias: Sync Tasmota states
    initial_state: true
    trigger:
      platform: homeassistant
      event: start
    action:
    # sync state for devices with default fulltopics
    - service: mqtt.publish
      data:
        topic: cmnd/tasmotas/state
        payload: ''
    # sync state for pre8.2 autodiscovery devices
    - service: mqtt.publish
      data:
        topic: tasmotas/cmnd/state
        payload: ''

What am I missing here that I have to manually reboot my outlets for them to become unorphaned? From all accounts I read, I’m an outlier and Tasmota “just works” for people. I’ve yet to have a 7 day period without having to finesse my devices back to an available state.

2

Same issue here :frowning:

3

yes I have same issue … The commands with MQTT, HTTP and webconsole all work but the device is “unavailable” in HA. So it POWER ON of the Tasmota Lamp triggered with a Sonoff T1 MQTT via HA proxy does not work.
I had this issue before, so I have set up a PING sensor and it works (is on for 6 days).
The NTP is also OK. The timing it reports is with 1 hour offset but the NTPserver on the Tasmota was OK. I set the NTP now to a local NTP server.

I will in the mean time switch back to MQTT settings in de configuration.yaml.

Oh the tasmota is 9.3.1 and HA core-2021.3.4.

Mario

4

Check the topic as if you previously used MQTT discovery and then turned it off you need to manually reset the topic.
Having said that I still see ZERO benefit to the Tasmota Integration. It’s just an added integration to MQTT and the Broker and adds nothing not already present there anyway so I am baffled why anyone would switch a working system to add Tasmota with no benefit or reason.

5

OK david, I will try to reset the MQTT topic.

I agree with you vision but it was IMHO worth trying. Somebody has put effort in it, so (s)he was convinced of the benefit. I must agree that it “easy” to integration Tasmotised devices but there should be a RCA why they become unavailable.

I will post back my findings …

Mario
PS: thanks for the fast response!

6

But there IS no benefit only a vague promise of some future benefit.

7

In my case was the reason wrong MQTT server configuration. Seems it is not set automatically to save retained messages. It is working for me once I’ve enabled following in mosquitto.conf:

autosave_interval 1800
autosave_on_changes true
persistence true
persistence_file mosquitto.db
persistence_location /mosquitto/config

Without this, everytime I did reboot (whole raspberry) the restart of all tasmotas was necessary to get it recognized by HA again.

2 Likes
8

My understanding is that the Tasmota project has deprecated support for Home Assistant’s MQTT Discovery in favor of its own method. Although both currently work, eventually it will eliminate MQTT Discovery (to free up code-space for other purposes). Tasmota will have the freedom to enhance its own standard as it sees fit.

9

I use RabbitMQ as MQTT broker and the same problem is here. I really like the integration with its device configuration (you can’t do that in YAML) but every time I restart HA, I have to restart Tasmota devices.

I’m thinking about adding MQTT discovery to the Tasmota with rule to announce its sensors every boot. I have tried it and it works quite well but there are some problems with discovery as well – HA doesn’t always like removing and re-adding devices this way and discovery stops working until HA restart. Haven’t tried with latest HA version yet. Still it feels ugly hack for me when Tasmota integration should do exactly the same.

10

This fits my definition of a compelling reason

11

I need to test more but looks like if I send 0 to cmnd/tasmotas/setoption19 after HA startup, everything works. It is still not 100% reliable but it can be from some old firmware versions in my setup which crash integration itself like this 8.5.1 does:

2021-04-10 23:16:41 DEBUG (MainThread) [homeassistant.components.mqtt.discovery] Process discovery payload {} 
2021-04-10 23:16:41 ERROR (MainThread) [homeassistant.util.logging] Exception in discovery_message_received when handling msg on 'tasmota/discovery/5CCF7F950000/config': '{"ip":"10.10.10.156","dn":"LED lamp","fn":["LED lamp",null,null,null,null,null,null,null],"hn":"DVES_950000-4235","mac":"5CCF7F950000","md":"Sonoff Basic","ofln":"Offline","onln":"Online","state":["OFF","ON","TOGGLE","HOLD"],"sw":"8.5.1","t":"DVES_950000","ft":"%prefix%/%topic%/","tp":["cmnd","stat","tele"],"rl":[1,0,0,0,0,0,0,0],"swc":[-1,-1,-1,-1,-1,-1,-1,-1],"btn":[0,0,0,0],"so":{"11":0,"13":0,"17":0,"20":0,"30":0,"68":0,"73":0,"80":0},"lk":1,"lt_st":0,"ver":1}' 
Traceback (most recent call last): 
  File "/usr/local/lib/python3.8/site-packages/hatasmota/discovery.py", line 188, in discovery_message_received 
    payload = TasmotaDiscoveryMsg(json.loads(payload)) 
  File "/usr/local/lib/python3.8/site-packages/hatasmota/discovery.py", line 147, in __init__ 
    config = TASMOTA_DISCOVERY_SCHEMA(config) 
  File "/usr/local/lib/python3.8/site-packages/voluptuous/schema_builder.py", line 272, in __call__ 
    return self._compiled([], data) 
  File "/usr/local/lib/python3.8/site-packages/voluptuous/schema_builder.py", line 594, in validate_dict 
    return base_validate(path, iteritems(data), out) 
  File "/usr/local/lib/python3.8/site-packages/voluptuous/schema_builder.py", line 432, in validate_mapping 
    raise er.MultipleInvalid(errors) 
voluptuous.error.MultipleInvalid: required key not provided @ data['so']['82] 
 
2021-04-10 23:16:41 DEBUG (MainThread) [homeassistant.components.mqtt.discovery] Process discovery payload {}

Edit: This reminds me another WTH: firmware version is only visible under device but this is not accessible for user as a sensor value or attribute. Only way to know what firmware is running, is to check every device one by one. Even device list doesn’t show this important field. This is why I add all Tasmota devices to YAML, just to have a overview card of all running versions.

12

So I do a status 2 on startup which causes all the firmware information to be written to a sensor which will then display if I tap on the entity. I can share that info.

13

Yeah, but you have to tap every sensor to check it. Assume you have tens of sensors sensors and this takes some time and you can still miss some devices…

I have such script right now:

script:
  notify_tasmota_versions:
    description: Send list of different Tasmota versions to telegram
    sequence:
      - service: notify.telegram_cougar
        data_template:
          title: Tasmota versions running
          message: >
            {% set ns = namespace(versions=[], names=[], verlist=[]) %}
            {% for sensor in states.sensor -%}
            {% if sensor.name | regex_match('.* Firmware$') -%}
            {% set ns.versions = ns.versions + [sensor.state | regex_replace('\(.*\)')] -%}
            {% set ns.names = ns.names + [sensor.attributes.friendly_name | regex_replace(' *Firmware$')] -%}
            {% endif -%}
            {% endfor -%}
            {% if ns.versions | length -%}
            {% for version in ns.versions | unique -%}
            {% set ns.verlist = [] -%}
            {% for name in ns.names -%}
            {% if ns.versions[loop.index - 1] == version -%}
            {% set ns.verlist = ns.verlist + [name] -%}
            {% endif -%}
            {% endfor -%}
            {{ '✅' if version == states('sensor.tasmota_firmware_version_available') else '⚠️' }} {{ version }}: {{ ns.verlist | join(', ')}}  
            {% endfor -%}
            {% endif -%}

This sends me a list of all versions I’m using with list of devices (not very well formatted but this is Telegram message limitation). I can trigger this script after every Tasmota release for instance (there will be no up-to-date devices at that time any more of course) or just check manually.

But for that I still have to manually configure sensor for every device like this:

sensor:
  - platform: mqtt
    name: "Tasmota Sauna Sensor Firmware"
    icon: mdi:chip
    state_topic: "stat/tasmota_010203/STATUS2"
    value_template: 'v{{ value_json.StatusFWR.Version | replace("(tasmota)", "") | replace("(release-tasmota)", "") }}'
14

Hi all,

I am a newbie to HASS. I face the same issue with all my Tasmota devices.

I have to add a script to broadcast an MQTT message using a group topic to restart all the Tasmota devices (e.g. publish cmnd/tasmotas/restart 1) every time HASS reboot/restart.

If anyone has a better idea, please kindly let me know.

15

Why do you have to do this? What isn’t working

What same issue? This is meaningless with no context

16

Hi David:

Thank you for your prompt reply.

The issue is: somehow all my Tasmota devices lost connection to HASS (but they can still communicate with the MQTT server) after I reboot the server that houses the HASS. My not-so-smart solution is to restart all the Tasmota devices, which reestablishes connection with HASS. This only take seconds; so, not a big issue.

I am running a separate Eclipse Mosquitto server (hosted inside my Asus Router) because I was using it to communicate to all my smart switches before I migrated to HASS. I am wondering whether it is the MQTT server settings that are causing the disconnection (e.g. QoS / retained flag). I have no network, engineering or computer science background and therefore, this is a wild guess. Please bear with this newbie. :yum:

17

It is not clear what you mean by that… how do you see this disconnection? It sounds like you just need to send a status message to the group topic but you are not really supplying any useful information… Obviously HA is still communicating with the broker and the broker is communicating with HA - otherwise sending the reset command wouldn’t work!

Maybe try these scripts instead of resetting

  startupalltasmota:
    alias: Tasmota Restore State at Startup
    sequence:
    - data:
        payload: ''
        topic: cmnd/tasmotas/state
      service: mqtt.publish
  firmwarealltasmota:
    alias: Tasmota Firmware Versions & Status
    sequence:
    - data:
        payload: '2'
        topic: cmnd/tasmotas/status
      service: mqtt.publish
    - data:
        payload: '11'
        topic: cmnd/tasmotas/status
      service: mqtt.publish

The first script restores the state - this will probably fix your issues.
The second one is probably not needed but I use it to feed a sensor with the current firmware version and also to get a bunch of status information I used to get when I was using discovery that also feeds sensors.

By resetting the device, you are just making it send those same messages to HA. Resetting them doesn’t do anything else magical for connectivity…

18

Thank you David! I live in Canada with EDT time zone. It is late now; so, I will try your script tomorrow.

Please allow me to document the exact behaviours I’d seen in order for you to understand (and it may help others in the future):

  1. After I reboot the HASS server, most, but not all, of the Tasmota related icons on the HASS dashboard are greyed out. Tapping the greyed out icons do not execute any actions. This happens sporadically.

  2. By restarting these devices either through a HASS script, one of the Tasmota devices’ console, or the MQTT broker’s terminal, the greyed out icons become active again.

  3. I used another Android (non-HA) app to switch on one of the greyed out Tasmota devices. Its associated HASS icon was still greyed out after the device was on.

Point #2, as you have indicated, seems to suggest that the MQTT broker does connect to HASS; otherwise, the greyed out icons would not be re-activated after restarting.

Point #3, however, seems to suggest otherwise. By switching it on using another app, the device should broadcast MQTT topic + payload like this (copied from the Tasmota’s console):

  • 21:14:36.312 MQT: cmnd/tasmota/device/power = toggle

  • 21:14:36.347 MQT: stat/tasmota/device/RESULT = {“POWER”:“ON”}

  • 21:14:36.350 MQT: stat/tasmota/device/POWER = ON (retained)

If HASS is subscribed to the device topic and connected to the MQTT broker, it should activate its dashboard icon if I extrapolating your comment correctly. But it didn’t… as least it didn’t thus far.

While I have a solution (plus your potential one), this issue is not critical. I simply find it interesting because problem solving is both in my nature and a career requirement. But David, thank you very much for spending your precious time helping me.

I will continue to pursue the root cause of the issue, however. If I find out anything interesting, I will post them here.

19

It doesn’t though does it? It needs the status command or to wait for the tele period to expire when it will automatically publish status messages so those scripts request that info if you have an automation to send the command when HA starts…

1 Like
20

Oh… IC… Only the “stat” or “tele” topics can do it. Wow… I would never guess… Thanks again. I really learn a lot today.

In other words, if I setup a cron job to reboot the server at night (to keep it afresh once in a while) and let all the Tasmota devices’ tele topic to run their course (it’s about every 5 minutes), I don’t even need to run the manual script. Am I correct?

That explains why some icons are activated after reboot. They must have the tele topic coincidentally published right after the reboot.

I can have a sweet dream tonight. LOL… :grimacing: