Possible serious bug in Tasmota 13.10

Configuration
21

That’s definitely my goal but unless I can get the device out of AP mode and connected to my Wi-Fi network, it doesn’t appear to offer the ability to load new firmware.

After logging into the device while it’s in AP mode, you are presented with a list of detected Wi-Fi networks (it fails to connect to mine) and these three options:

  • Restore Configuration
  • Reset Configuration
  • Restart

‘Restore Configuration’ leads to a dialog box allowing you to select a file. However, I believe it means a configuration file and not a firmware file. In other words, it’s allowing me to re-configure the device but not re-flash it.

I know that once the device is connected to a Wi-Fi network it displays a more complete menu that includes the ability to change its firmware.

‘Reset Configuration’ probably just does a factory-reset like, I assume, what ‘Fast Power Cycle Device Recovery’ did. However, as I have already discovered, even when reset to its default configuration it fails to connect to my Wi-Fi network.

My goal now is to get the device to connect to some kind of AP so I can get to its full menu and re-flash it to 12.2 (then ponder about changing to ESPhome).

NOTE

My AP’s system log shows that the Tasmotized devices are periodically connecting then disconnecting 2-8 seconds later. Interestingly, that’s not the same logging message as when a device attempts to connect with the wrong password (that situation is logged as “failed to connect because it provided incorrect login information”).

22

Tried to setup a hotspot on a PC ?

1 Like
23

Or even your phone - when I moved in to my new house I brought all my devices with me from the old one and used a hotspot on my phone as the main network connection until my services were connected. The Tasmota devices had no problem connecting. Once connected use Fing to get the IP address and jobs a good un :slight_smile:

24

Thanks for that; it saved me a lot of time.

  • I used my Windows PC to create a Wi-Fi hotspot, put the Tasmotized device back into recovery mode and was able to make it connect to the PC’s hotspot where it remained connected. :+1:

  • Now I was able to access the device’s full menu and install the 12.2 version of Tasmota. :+1:

  • After it restarted, I made a few basic configuration changes (name, template, etc) and then came the critical moment, I changed its selected Wi-Fi network, and password, from the hotspot to my Wi-Fi network. After restarting it failed to remain connected to the network. The AP’s log shows the same pattern of connection/disconnection behavior as with 13.1. :-1:

So based on the fact the device was able to connect to the hotspot, using 13.1 and 12.2, but not to the AP with either version, I’m led to conclude that the culprit is my AP’s latest firmware. :man_facepalming:

“No joy in Mudville”

25

As an experiment, I reconfigured the AP so that only one SSID is used for both 2.4 and 5Ghz radios and set channel selection back to “Auto”. In other words, I reverted the AP to its default settings.

Unfortunately, it improved nothing; the Tasmotized devices still fail to establish a lasting connection (i.e. more than a few seconds).

Options now are to convert one device from Tasmota to ESPhome, and hope it can connect to the AP, or replace the AP with something more reliable (and configurable).

26

Since you have confirmed that the devices work with a hotspot, maybe it is time to bite the bullet and move away from your Internet provider’s devices. I had many issues in the past with Comcast routers / modems. Not so much anymore. Still have an occasional issue with the modem when the send an update, but usually very easy to fix.

1 Like
27

You could use an ESP8266 as a repeater (Tasmota devices don’t need a lot of bandwidth) and just connect them to that (or those if you need a spread).

https://github.com/martin-ger/esp_wifi_repeater

1 Like
28

It’s something I have considered for awhile but so many other projects have superseded it.

Interesting idea but unfortunately, at the moment, I don’t have the bandwidth to explore new projects. I’m already in the middle of home renovation work and this recent ISP-induced problem came at a very inconvenient time. I’ll revisit your suggestion, and Bill’s, as soon as I have more free time.

29

UPDATE

I re-configured all Tasmotized devices to use static IP addresses as opposed to DHCP. Now they connect and remain connected.

The process of accessing each device, in order to change its IP address configuration, was awkward. I had to put the device in recovery mode, make it connect to a temporary hotspot, re-configure it (using Backlog to speed up the process), and then switch its WiFi connection back to the local network.

The router’s DHCP server is disabled and a very old version of pi-hole is the DHCP server. Because of its age (circa 2018), I thought it might be the culprit. It was too old to upgrade because it was still running on Raspbian Stretch. So I had to create a completely fresh installation containing Raspberry Pi OS (bullseye) and the latest version of pi-hole.

Unfortunately, after all of that, a Tasmotized device employing DHCP still failed to connect. I tested a device running Tasmota 12.2 and it could not acquire an IP address from the brand-new DHCP server. It failed to complete the handshake with the DHCP server; it doesn’t issue a DHCPREQUEST after the DHCP server sends a DHCPOFFER.

Here’s the handshake process; the client (Tasmota device) never responds with DHCPREQUEST. It goes back to sending DHCPDISCOVER (i.e. behaving as if it never heard the server’s DHCPOFFER).

CLIENT -> DHCPDISCOVER
SERVER -> DHCPOFFER
CLIENT -> DHCPREQUEST
SERVER -> DHCPACK
30

This looks indeed like a bug. Have you reported the behaviour to the Tasmota devs?

31

I haven’t reported it because the behavior exists exclusively on my local network consisting of my ISP’s router, with its DHCP server disabled, and Pi-Hole serving as local DNS and DHCP server.

The behavior does not exist with:

  1. An old Linksys e3000 router, flashed with FreshTomato firmware, serving as Wi-Fi Hotspot with DNS and DHCP services.
  2. When the DHCP server on the ISP’s router is enabled and Pi-Hole’s DHCP server is disabled.

Those results imply there may be a problem with Pi-Hole’s DHCP server. It was a very old version running on Raspbian Stretch. So I rebuilt it from scratch using RPI OS Bullseye and the latest version of Pi-Hole. To my disappointment, it fixed nothing and the Tasmotized devices still fail to acquire an IP address.

The curious thing is that all the other WiFi devices (phones, Sonos, a Wemo plug, some Ecobee Switch+ switches, an Echo , etc) have no problem connecting (not even with the ancient Pi-Hole). Only the Tasmotized devices can’t connect and one Lenovo tablet that occasionally connects for awhile and other times repeatedly connects/disconnects.

I am led to believe that something changed on the ISP’S router, namely a firmware upgrade. Nothing else in the network changed and the router’s firmware is out of my control. I have factory-reset it and reconfigured it several times, in the hope it would improve something but it hasn’t.

There’s one more test I intend to do. The router’s DHCP server is disabled and I will also disable Pi-Hole’s DHCP server. If a newly introduced device acquires an IP address via DHCP, it implies the router’s DHCP server is always functional and cannot actually be disabled.

32

Do you have underscores in your Tasmota device names?

If so try replacing them with dashes.

This is from the ESPHome FAQ but applies to Tasmota as well:

According to RFC1912, underscore characters (_ ) in hostnames are not valid. In reality some local DNS/DHCP setups will be ok with underscores and some will not. If connecting via a static IP address, there will probably be no issues. In some cases, initial setup using an underscore works, but later the connection might fail when Home Assistant restarts or if you change router hardware. Recommendation: use hyphen (- ) instead of underscore if you can.

1 Like
33

Thanks, that’s a good tip; but none use underscores. FWIW, I may be mistaken but I think Tasmota automatically converts a supplied underscore into a hyphen.

This problem occurred recently, after years of trouble-free operation by the Tasmotized devices.

Five of them are in permanent service monitoring energy consumption of the fridge, dishwasher, and furnace (fan) and the remaining two control devices (light and a fountain). Those five were upgraded to 13.1 and worked well for several days before the network connection problem started when the router was rebooted.

I hastily jumped to the conclusion that there was a problem with 13.1. However, I also have about a dozen other identical Tasmotized devices (put into service only for holiday lighting) running 12.2 and, when tested now, they also fail to connect (they all worked last Christmas). It’s literally a case of “they worked before, but suddenly not today”.

The abrupt change from working to not working is why I am now led to believe that something must have changed on the ISP’s router that, for some reason, negatively affects only the Tasmotized devices (and my tablet to some extent). It’s a head scratcher.

EDIT

I wrote this on my tablet and just when I was about to post it, the tablet repeatedly disconnected/reconnected from/to WiFi. Now that I am writing this addendum, it’s remaining connected. So weird.

34

It might be worth to give esphome a try on one of your tasmota devices. Technically it could be they behave the same - this would indicate the bug/error is in the upstream code like arduino/esp-idf which is used by both projects. :toolbox:

In esphome you can also choose a particular framework/platformio versions which might come in handy if the tasmota behauviour is reproducible with esphome :hammer_and_wrench:

35

While searching for a solution to this problem (device never sends a DHCPREQUEST after server sends a DHCPOFFER), I had discovered that it was reported for previous versions of Tasmota. I recall at least one reply explaining that ‘upstream arduino code’ is responsible for DHCP negotiation and problems are usually due to network misconfiguration.

In other words, the reply gave me the impression that the arduino code was considered to be blameless, otherwise far more users would be seeing the same issue.

Perhaps what was not considered is that there may be a very unique set of circumstances that, when they occur, reveal a deficiency in the arduino code (and it’s been there for a long time). Or it’s just network misconfiguration. :man_shrugging:t3:

Anyway, your suggestion is worth trying. I have a good candidate: an outlet that can be easily opened in the event I screw something up and need to flash it serially.

1 Like
36

As an experiment, I disabled Pi-Hole’s DHCP server (in addition to the router’s already disabled DHCP server) then plugged in a Tasmotized device.

The router’s log shows the same kind of messages as before:

2023-09-25 11:20:07	INF	WIFI	A WiFi device < [C4:XX:XX:XX:XX:0B]> has successfully connected to SSID (XXXXX)[RADIO2G4]
2023-09-25 11:20:20	INF	WIFI	A WiFi device < [C4:XX:XX:XX:XX:0B]> was disconnected on SSID (XXXXX)[RADIO2G4]

The router doesn’t show the same level of detail as Pi-Hole so it doesn’t display the individual steps in a DHCP handshake. It’s hard to tell for sure if those two messages mean DHCPDISCOVER and DHCPOFFER. Anyway, the upshot is that with both DHCP servers disabled, the device fails to get an IP address; when one disables the router’s DHCP server, it’s really disabled.

I then enabled the router’s DHCP server back on but left Pi-Hole’s disabled and, just like in previous tests, the Tasmotized device promptly acquired an IP address. So the problem occurs exclusively when the router’s DHCP server is disabled and the Pi-Hole’s DHCP server is enabled (regardless if it was an ancient version of Pi-Hole or the most recent). Yet this problem occurred abruptly (one day to the next) so it’s hard to exclude the router from being the culprit … jut not sure how yet.

37

It appears that I have found a cure for the problem here:

Users reported that switching the Tasmotized device’s WiFi from 802.11n to 802.11g helped to ensure a stable connection.

  1. I re-enabled the router’s DHCP server. I have it’s IP allocation range set above the range used by Pi-Hole’s DHCP server (i.e. no overlap).
  2. I plugged in two Tasmotized devices that are configured with 12.2.
  3. They immediately acquired IP addresses from the router.
  4. I logged into both and executed wifi 3 to make them use 802.11g.
  5. I disabled the router’s DHCP server.
  6. On startup, both devices acquired IP addresses from the Pi-Hole’s DHCP server.
  7. I was able to log in to both devices, by their hostname, and confirm they were accessible.

I’ll leave them connected for several hours and then check the log for any anomalies. If all seems well, I’ll re-configure all other devices.

2 Likes
38

I converted several Tasmotized devices to use 802.11g and they have all acquired IP addresses from Pi-Hole’s DHCP server and remained connected.

I have no idea how switching the devices from one networking standard, 802.11n, to an older networking standard, 802.11g, influences their ability to successfully negotiate an IP address from a DHCP server. It seems to me the two things operate at different levels of the OSI model yet the modification has brought back stability to my network. :man_shrugging:

1 Like
39

Another chapter to this saga.

I replaced the ISP’s wireless router with a used Asus RT-AC86U flashed with the latest firmware. The latest version of Pi-Hole continues to serve DNS and DHCP.

Tasmotized devices continue to fail to connect in the same way as with the ISP’s equipment.

Only by using the same fix (configuring the Tasmotized device with wifi 3 to prevent it from connecting via 802.11n) allows the device to connect and acquire an IP address.

If Pi-Hole is removed from the equation, and the router acts as DNS and DHCP server, Tasmotized devices experience no problem connecting and getting an address.

Next step is to make Pi-Hole serve DNS only and the router to serve DHCP. Obviously all of these tests are highly disruptive to an otherwise functional home network so scheduling this work is tricky.

FWIW, I have scoured the internet for solutions and discovered that the problem isn’t unique to Tasmotized devices, has been reported for other “IOT” and non-IOT devices, isn’t widespread, has occurred seemingly “suddenly and inexplicably”, and there’s no explanation that I found for the root cause of the issue (i.e. employing wifi 3 fixes the symptom but not the cause).

40

I use Asus devices in my mesh and don’t have an issue with tasmota losing connection. What is wifi 3?