Sonoff / Tasmota started regularly showing "Unavailable" on Home Assistant

bingobob · February 26, 2019, 11:01am

MQTT discovery. I can provide config details later on if helps . Most odd. Feels like I’m close - the on / off through the automations is lightning fast and I’m not seeing unavailable any moment. Just the switching thing via the HA ui

Ryanmaturi · February 26, 2019, 8:08pm

I have been having the same issue, I am on 6.4.1 on all my devices. This problem however is not occurring on all devices. Seems like they intermittently just drop off. Although it seems the phy layer connection remains connected. Wonder if 6.4.1 could be built on top of the espressif 2.
3 library

robg · February 26, 2019, 8:59pm

Overnight has show the 6.3.0 to solid without any unavailable reported, just need to work out how to downgrade other units to 6.3.0 OTP, tried to do it via the UI but rejected it for some reason. Just need to research that one…

Bingobob, not seeing that problem you described.
But I’m using the device as “Arilux LC01 Module” ie RGB light controller.
Maybe this might help you to narrow down the problem:
Can you via the device’s portal change the buttons(states) and does this reflect in HA device state, this works for me. Not an expert in this space, could be something in your devices config to not update the devices status via MQTT??

DavidFW1960 · February 26, 2019, 9:34pm

You will need to flash OTA twice… first time use the sonoff_minimal and the sendon time use sonoff.bin. Works fin OTA.

Reason is, the sonoff has to have 2 versions of firmware stored at one time and then one replaces the other one. The full firmware is too large so it won’t flash.

DavidFW1960 · February 26, 2019, 9:36pm

All recent versions of STasmota have precompiled binaries for core 2.3.0, 2.4.2 and 2.5.0 so you can use 6.4.1 with 2.3.0 core.

All the trouble for me started when they rolled out 6.4.0 and the default core was changed from 2.3.0 to 2.4.0…

Ryanmaturi · February 26, 2019, 9:59pm

So if I flash the 6.4.1 with 2.3 library. Potentially I could resolve this issue? Does anyone know if a case has been opened on git with Theo. I’ve had such good luck with tasmota now for years. This is my first problem.

DavidFW1960 · February 26, 2019, 10:03pm

Core 2.3.0 will work. The problem is I’m using some new features that are in the latest Dev builds and I have not been able to use either the precompiled binaries with 2.3.0 core or build my own… they both put the sonoff into a boot loop. So I’m using 2.5.0 core now and the disconnects are not too bad… I did have an automation fail yesterday because a switch was unavailable when triggered…

robg · February 27, 2019, 5:45am

Hi Bingobob,

After downgrading all my devices 6.3.0 they did act a bit peculiar and not reporting states correctly. Resolved by deleting the discovered files via the UI configuration/MQTT menu and reboot HA. As previously mentioned they don’t come back as discovered items under the MQTT discovered items

…but they are now stable.

Rob.

Ryanmaturi · February 27, 2019, 12:44pm

Was able to get one of my sonoff stable with no unavailable. Flashed 6.4.1 with 2.3 sdk. Then performed a reset 5 command on the console of the device. I should mention that on the console of the affected devices I was continuously getting dns connection retries. A thread on tasmota forms mentions the reset 5 command to alleviate this.
The particular device in question is manually setup in my switches.yaml. Not utilizing discovery

NK553 · February 27, 2019, 1:44pm

I was having all of these problems, I ended up switching to ESPHome. It’s much more stable and can be done OTA. It talks directly to HA, so no MQTT problems.

Highly recommend making the switch.

robg · February 28, 2019, 9:54am

Might be time time to switch to ESPHome.
Issues that bingobob reported started to appear as well ie HA reports the switch on but it’s actually not, so better the devil you know and switched back to 6.4.x.
Suspect it’s something with the MQTT discovery in HA not the firmware.
Getting around the problem by appdaemon in the background monitoring the expected state and updating the state when the device comes backonline.

DavidFW1960 · February 28, 2019, 10:05am

No it’s core 2.4.2 or 2.5.0… 2.3.0 is very stable. It’s nothing to do with discovery… that doesn’t even make sense.

robg · February 28, 2019, 7:34pm

Have two different HA environments running:
A: - Discovery turned off, with 6.4.1 sonoffs controlling lights and other things, and have not experienced any issues.

B: - Discovery turned on, all the issues above. Even with 6.3.0 which believe had 2.3.0 yeah sure stable, just not reporting the true state of switches.

Hence my reasoning.

bingobob · March 2, 2019, 1:55pm

Interesting, I’ve gone around the long way until things settle, please let me know when safe to go back in the water. I’ve removed MQTT entirely from my network and achieved simple stability. Might not be as cute as MQTT but working so far.

Flashed these sonoffs with 6.3.0.17(5f560ba-sonoff), disabled MQTT, apt removed my mqtt server.

Need to work on my Sonoff RF bridge (espurna) next though so might get MQTT back involved for that.

For now though, glad it’s working.

Example of one of the sonoffs below…

Program Version	6.3.0.17(5f560ba-sonoff)
Build Date & Time	2018-12-14T02:00:56
Core/SDK Version	2_3_0/1.5.3(aec24ac9)
Uptime	0T00:31:05
Flash write Count	3536 at 0xF5000
Boot Count	1117
Restart Reason	Software/System restart
Friendly Name 1	orange_light
 
AP1 SSId (RSSI)	mars (66%)
Hostname	sonoff2-2889.local
IP Address	192.168.2.21
Gateway	192.168.2.1
Subnet Mask	255.255.255.0
DNS Server	1.1.1.1
MAC Address	
 
MQTT	Disabled
 
Emulation	None
mDNS Discovery	Enabled
mDNS Advertise	Web Server
 
ESP Chip Id	
Flash Chip Id	0x14405E
Flash Size	1024kB
Program Flash Size	1024kB
Program Size	503kB
Free Program Space	500kB
Free Memory	14kB

Here’s the HA config to make it work… interesting mix of POWER and POWER1 here, guess it’s the S20’s vs the basics.

switch:
  platform: command_line
  switches:
    fish_tank_filter:
      command_on:      "/usr/bin/curl -X POST http://192.168.2.20/cm?cmnd=Power%20On"
      command_off:     "/usr/bin/curl -X POST http://192.168.2.20/cm?cmnd=Power%20Off"
      command_state:   "/usr/bin/curl -X GET http://192.168.2.20/cm?cmnd=Power"
      value_template:  '{{value_json.POWER == "ON" }}'
      friendly_name:   "Fish tank filter"
    orange_light:
      command_on:      "/usr/bin/curl -X POST http://192.168.2.21/cm?cmnd=Power%20On"
      command_off:     "/usr/bin/curl -X POST http://192.168.2.21/cm?cmnd=Power%20Off"
      command_state:   "/usr/bin/curl -X GET http://192.168.2.21/cm?cmnd=Power"
      value_template:  '{{value_json.POWER == "ON" }}'
      friendly_name:   "Orange light"
    fish_tank_lights:
      command_on:      "/usr/bin/curl -X POST http://192.168.2.22/cm?cmnd=Power%20On"
      command_off:     "/usr/bin/curl -X POST http://192.168.2.22/cm?cmnd=Power%20Off"
      command_state:   "/usr/bin/curl -X GET http://192.168.2.22/cm?cmnd=Power"
      value_template:  '{{value_json.POWER1 == "ON" }}'
      friendly_name:   "Fish tank lights"
    outside_passage_light:
      command_on:      "/usr/bin/curl -X POST http://192.168.2.25/cm?cmnd=Power%20On"
      command_off:     "/usr/bin/curl -X POST http://192.168.2.25/cm?cmnd=Power%20Off"
      command_state:   "/usr/bin/curl -X GET http://192.168.2.25/cm?cmnd=Power"
      value_template:  '{{value_json.POWER == "ON" }}'
      friendly_name:   "Passage light"
    outside_backdoor_lights:
      command_on:      "/usr/bin/curl -X POST http://192.168.2.28/cm?cmnd=Power%20On"
      command_off:     "/usr/bin/curl -X POST http://192.168.2.28/cm?cmnd=Power%20Off"
      command_state:   "/usr/bin/curl -X GET http://192.168.2.28/cm?cmnd=Power"
      value_template:  '{{value_json.POWER == "ON" }}'
      friendly_name:   "Back door lights"
    outside_front_light:
      command_on:      "/usr/bin/curl -X POST http://192.168.2.27/cm?cmnd=Power%20On"
      command_off:     "/usr/bin/curl -X POST http://192.168.2.27/cm?cmnd=Power%20Off"
      command_state:   "/usr/bin/curl -X GET http://192.168.2.27/cm?cmnd=Power"
      value_template:  '{{value_json.POWER == "ON" }}'
      friendly_name:   "Outside front light"

DavidFW1960 · March 12, 2019, 12:25am

OK everyone… the boot loops in core 2.3.0 are fixed. They found the bug. Just flashed 6.4.1.21 with core 2.3.0. I build my own firmware but the latest dev binaries will also have this fix as well…

Just for reference, 6.4.1.21 from yesterday with core 2.5.0 is here for 2 of my switches:

Horrible.

I actually did a router log with wifi disconnects the other day and 100% correlation with HA dropouts as well. It also showed that the closer the switch was to the access point the less dropouts there were. 3 switches right next to the AP had none.

Anyway, as you can see it was pretty unstable. I expect the state display tomorrow won’t have any dropouts…

robg · March 12, 2019, 3:33am

Hi David,

Well done, seen some of the work you had going on Github.
Keep us posted, I’ll sit on the fence with this one for now.
Do you know if anyone has or will release a generic binary of 6.4.1.21 with core 2.3.0?

Rob.

DavidFW1960 · March 12, 2019, 3:40am

That is available (as are all dev builds) on the dev site for Tasmota… just click the link a couple of inches down from the top…
http://thehackbox.org/tasmota/

By way of an update, zero dropouts since 4 hours!

robg · March 12, 2019, 4:00am

Thanks David,

Even with fixing a bug in the core version stays the same @ 2.3.0?

Rob.

DavidFW1960 · March 12, 2019, 4:03am

Yes… It was a compilation bug they fixed. The core itself is unchanged. It actually only happens if SetOption19 is ON… ie it only happened if you used MQTT discovery…
I’m already enjoying the stability LOL!!

robg · March 12, 2019, 6:34am

Nice when things just work! Thanks.