Tasmota MQTT connection over SSL broken after Update to 2024.10.2

zeus86 commented 1 month ago

The problem

After updating to core-2024.10.2 the reporting of values from all my tasmota devices (around a dozen) stopped working, the only metric not shows as unknown is the IP-address. Everything worked before the upgrade, and no configuration changes have been made. I use RSA-keys with nginx, as ecdsa-Keys with letsencrypt are known to be problematic with some mqtt-devices.

What version of Home Assistant Core has the issue?

core-2024.10.2

What was the last working version of Home Assistant Core?

core-2024.10.1

What type of installation are you running?

Home Assistant OS

Integration causing the issue

tasmota, maybe mosquitto

Link to integration documentation on our website

https://www.home-assistant.io/integrations/tasmota

Anything in the logs that might be useful for us?

nothing helpful in the mosquitto-log:

2024-10-16 10:36:22: New connection from <IP>:58587 on port 8883.
2024-10-16 10:36:44: Client <unknown> has exceeded timeout, disconnecting.
2024-10-16 10:36:53: Client <unknown> disconnected: Protocol error.

(the <unknown> is literal, I only truncated the IP).

--

Connection-Failures in the Tasmota-Log:

10:41:58.618 MQT: Attempting connection...
10:41:58.683 MQT: TLS connection error: 1
10:41:58.684 MQT: Connect failed to <myFQDN>:8883, rc -2. Retry in 90 sec

Additional information

Tested with recent Versions of tasmota: 14.2 and 14.3.

Without SSL (on port 1883) everything works fine, but as said: before the Upgrade everything worked, so I think this is a Homeassistant-Issue, not a Tasmota one.

While TLS-Error 1 indicates, that this is a fingerprint-issue (https://tasmota.github.io/docs/TLS/#tls-troubleshooting), i don't think this is actually true, because it worked before, and the cert did not change during the upgrade.
All Tasmota-Devices in question are ESP32-based, not ESP8266-based.

home-assistant[bot] commented 1 month ago

Hey there @emontnemery, mind taking a look at this issue as it has been labeled with an integration (tasmota) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of `tasmota` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Renames the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign tasmota` Removes the current integration label and assignees on the issue, add the integration domain after the command. - `@home-assistant add-label needs-more-information` Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue. - `@home-assistant remove-label needs-more-information` Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

tasmota documentation tasmota source _{^{(message by IssueLinks)}}

letsgetbusy commented 1 month ago

+1 Same problem after updating to core-2024.10.2. With core-2024.10.1 all work fine.

letsgetbusy commented 1 month ago

Update Affected all tasmota before 14.1.0. Updated to 14.2.0 or 14.3.0 not have this problem.

Please try by your side

zeus86 commented 1 month ago

Update Affected all tasmota before 14.1.0. Updated to 14.2.0 or 14.3.0 not have this problem.

Please try by your side

I cannot confirm this. All my devices already have been on 14.2.0 and after spotting this problem, I upgraded to 14.3.0, but the problem persists for me.

pathwayx99 commented 1 month ago

I had the same problem. All tasmota devices unavailable in HA, with their web UIs perfectly accessible. And sure enough, tracking my Watchtower logs, it seemed like the update of HA was the issue.

But a bit more careful digging proved it was not: I couldn't get through to the tasmota devices using my MQTT tools. So then I started looking at Mosquitto (my MQTT server). Again, the Watchtower logs showed an update. I rolled back to previous versions. Nothing.

In the end, I reset the fingerprint on the tasmota devices through their console using the command that allows them to auto-learn it:

MqttFingerprint 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

...and it worked. Not sure why this became necessary, but...might help someone else, so I'm posting it.

zeus86 commented 1 month ago

[...] In the end, I reset the fingerprint on the tasmota devices through their console using the command that allows them to auto-learn it:

MqttFingerprint 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

...and it worked. Not sure why this became necessary, but...might help someone else, so I'm posting it.

Good catch!
I can confirm this works, but in the end this makes it just even stranger, because the root-cause triggering the problem is still the homeassistant-update, so I'm really curious what the underlying problem here is...

pathwayx99 commented 1 month ago

[...] In the end, I reset the fingerprint on the tasmota devices through their console using the command that allows them to auto-learn it: MqttFingerprint 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ...and it worked. Not sure why this became necessary, but...might help someone else, so I'm posting it.

Good catch! I can confirm this works, but in the end this makes it just even stranger, because the root-cause triggering the problem is still the homeassistant-update, so I'm really curious what the underlying problem here is...

Thing is, I'm not convinced it's the home assistant update that caused this. I'm gravitating more towards the mosquitto update being the culprit. Are you also by any chance using mosquitto? And if so, did you perform an update (or maybe Watchtower did it for you)?

In my case, I re-examined the logs and the timing when HA lost connectivity matches perfectly with the mosquitto update. The HA update was several hours BEFORE that.

zeus86 commented 1 month ago

Thing is, I'm not convinced it's the home assistant update that caused this. I'm gravitating more towards the mosquitto update being the culprit. Are you also by any chance using mosquitto? And if so, did you perform an update (or maybe Watchtower did it for you)?

In my case, I re-examined the logs and the timing when HA lost connectivity matches perfectly with the mosquitto update. The HA update was several hours BEFORE that.

hmhm, possible, yes. I am using mosquitto, but if it got updated, is has been updated automatically (as configured) and did not an explicit backup then, and the logs are already rotated I suppose. however, in my case, i explicitly updated homeassistant-os (while sitting in front of it), and right after that update the devices were no longer reachable via mqtt, so even tough it MIGHT be a mosquitto related problem, for the average user it is not, when the problem occurs, while updating HA-OS. In the json-files of the backups i at least cannot see an explicit mpsquitto update. Currently it is on 6.4.1.

pathwayx99 commented 1 month ago

Thing is, I'm not convinced it's the home assistant update that caused this. I'm gravitating more towards the mosquitto update being the culprit. Are you also by any chance using mosquitto? And if so, did you perform an update (or maybe Watchtower did it for you)? In my case, I re-examined the logs and the timing when HA lost connectivity matches perfectly with the mosquitto update. The HA update was several hours BEFORE that.

hmhm, possible, yes. I am using mosquitto, but if it got updated, is has been updated automatically (as configured) and did not an explicit backup then, and the logs are already rotated I suppose. however, in my case, i explicitly updated homeassistant-os (while sitting in front of it), and right after that update the devices were no longer reachable via mqtt, so even tough it MIGHT be a mosquitto related problem, for the average user it is not, when the problem occurs, while updating HA-OS. In the json-files of the backups i at least cannot see an explicit mpsquitto update. Currently it is on 6.4.1.

Maybe it's a combination of both, then? My timing fits with the mosquitto update, yours fits with the HA update. What's common in our cases is that both pieces of software were updated before the problem manifested itself.

Unfortunately, I wouldn't know how to follow up that hypothesis, I'm afraid.

joshuaaaaa commented 1 month ago

I had the same problem. All tasmota devices unavailable in HA, with their web UIs perfectly accessible. And sure enough, tracking my Watchtower logs, it seemed like the update of HA was the issue.

But a bit more careful digging proved it was not: I couldn't get through to the tasmota devices using my MQTT tools. So then I started looking at Mosquitto (my MQTT server). Again, the Watchtower logs showed an update. I rolled back to previous versions. Nothing.

In the end, I reset the fingerprint on the tasmota devices through their console using the command that allows them to auto-learn it:

MqttFingerprint 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

...and it worked. Not sure why this became necessary, but...might help someone else, so I'm posting it.

work for mee too...

crhass commented 4 days ago

I am seeing this issue and I am not using tls. Tasmota devices keep disconnecting from the broker, WiFi stays connected.

Same log messages of device disconnected due to time out and then connected again

Using latest home assistant 2024.11.3 on rpi4 and Tasmota v11.0, V12 and v14.3

Not sure when this started

EDIT: Downgrade to 2024.11.2 has resolved this for me, when I upgrade it comes back.

home-assistant / core