-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Domoticz: Since v10.0.0 devices randomly get corrupted timezone (+104) and MQTT gets disabled #13700
Comments
I've got many devices running version 10 without any resetting of Timezone from my standard setting of 99. I'd be surprised if time difference would be a reason for MQTT getting disabled. It looks like the settings of your device is broken, not just the weird |
I tried a full reset offcourse before creating an issue. The "Reset 2" + the 2 above backlogs is how I configure the device after reset. Nothing else. After some time, boom, bootcount totally off, timezone wrong, MQTT disabled and spam in the console. MQTT disabled is how I get alerted, because Domoticz can't control it anymore. It happens on all of these 10 devices as long as they are on V10. No issues on 9.5.0. That's the weird thing. |
Can you erase the flash from a device and flash v.10. via serial? |
You should track this bootcount & possible reboots My ESP8266 devices were still on 9.5.0. (only ESP32 were on 10.0.0.x). |
Most of them are build behind wall switches or behind a closet. I'll flash a new basic R3 with 10.0.0 and see what it gives. |
The very high boot count was also corrupt above. After a restart it's back normal and it was 31 or so. The device was online for 5 days btw. |
And another one of my devices got this crazy corruption. Bootcount crazy, MQTT disabled, console message spam every second and other corrupted settings. I flashed 5 out of 10 devices back to 9.5.0 and they seem to be stable again (except some Exception 9 reboots once in a while, but they reboot and work fine, nothing gets corrupted). I installed 10.0.0.3 on a test sonoffMiniR2 and I'll check what it gives. |
Speculatively, I'm wondering if your issue is somehow related to using Domoticz, which AFAIK is not a very commonly used backend for Tasmota. |
My testdevice isn't configured with domoticz parameters. I'll see what it gives (also against the exception 9 error they all give once a day). |
Your posted config includes Domoticz: |
I know, but on my testdevice I installed this morning, I left that out |
Hi, any news on this? Have you tried to erase and flash again with Tasmotizer? |
Test device is still OK and MQTT still enabled, but just an hour ago, a Wemos D1 with 10.0.0 got MQTT disabled. Timezone 104, bootcount 55k +, ... |
how are you flashing these devices? are you using Tasmotizer? Can you try with latest version 10.0.0.3? ( http://ota.tasmota.com/tasmota/tasmota.bin.gz ) |
For the easy accessible ones (serial) (Wemos, NodeMCU, ...), I indeed always use the latest Tasmotizer. For the Sonoff's, I use the DIY tool. But both seem to be affected. Edit: my test device now runs on 10.0.0.3 instead of 10.0.0. Syslog set to 4 and being logged to my NAS. I hope it corrupts soon :-D |
Do you have new devices to test too? Looking at your BootCount there is maybe the flash chip defect. If new devices does work without a problem you have a hardware issue. Have you googled with the ` |
The bootcount is perfectly fine on all devices. It only gets corrupt / very high when it goes crazy. Like I said, the following things occur:
Restarting the module from console fixes it immediately. I've got Sonoff MiniR2's that are max. 3 months old, but also Wemos D1, NodeMCU and other Sonoff's that are older (1 year or older). They all seem to show this very weird crash / behavior. |
Just to confirm that none of the units I moved to 10.0.0.3 earlier this week have shown the problem. Still connected on MQTT and expected Timezone 99 |
This is super weird. Do you have any magnetic interference close to your devices like antennae or similar? |
I know... I have nothing special in my home. I do run however a ZigBee network of +- 30 devices, but my 2,4 WiFi is on channel 1 and ZigBee is on the highest band. Like I said, never had this behaviour before on previous firmwares. Nothing changed in my house at the time of upgrading to 10.0.0 I'll keep logging as much as I can. I have 4 devices on 9.5.0, 3 on 10.0.0 and 2 + 1 test device on 10.0.0.3 |
you said:
what messages do you have? can you paste here a log of several of those? Can you tried using and what is the |
The RSL and STATE message in the first message above. (04:13:27....) Do you want all 11 IDs? |
can you paste here a log of several of those? Can you tried using WEBLOG 4 to catch debug messages too? and what is the Flash Chip Id in the Information menu in Tasmota WebUI ? |
Syslog 4 is now active on 3 devices. Waiting for the error / crash to show up... |
Wemos d1 on 10.0.0 that went crazy today: ESP Chip Id6837606 (ESP8266EX) Sonoff Basic R3 on 10.0.0 that went crazy 2 days ago: ESP Chip Id11258249 (ESP8285) |
The 0x164020 is a XMC flash chip. In our experience it is a troublemaker and do fail more often than other flash chips very early. |
No, I don't think I've erased it before. But like I said, everything was "rock solid" before jumping to 10.0.0. |
Everything is back on 9.5.0 since 20 days here. Very rare some exceptions (and they happen at the same moment on 2 or more devices) but not a single crash / mqtt bug. Most devices with uptimes of 20 days. |
@Eddie-BS Thx for the info. I'm still investigating the issue. From the original OPs If you see it happen again pls report |
@arendst Thx for your effort so far, I will let this version run and hope te catch it next time with the webinterface still accessible to show you a status 0 |
Just for my information the issue occured "out of the blue", there were no configuration changes executed? |
indeed, the devices are just running, no changes made to them. they all send data over mqtt to domoticz. |
Too Bad my S5 was gone again this morning. It was rebooted and in 192.168.4.1 mode ...
going to restore the config on it now ... |
Fix possible heap corruption due to invalid PubSubClient memmove parameters (#13700)
I found at least one possible cause of observed heap corruption. The latest development branch contains an updated PubSubClient library. Pls try this on one of your devices and report back. |
tnx @arendst
|
You were just a few minutes too fast. Pls redo and look for a compile time of 15:06:38 visible at boottime and in the information webpage. |
like this one ;-)
|
S5 up for 48 hours, no exceptions, no hardware watchdog, no reboot, looks fine for now ... |
I've upgraded my "exceptiontional" devices too and see indeed no more unexplainable exceptions. What you will see is an increase in Tasmota will automaticcaly re-connect in that case. This PubSubClient issue will more likely pop-up with users using Domoticz as Domoticz sends all it's sensor updates to the MQTT broker in addition to Domoticz commands. Tasmota needs to receive this data and decide on it's index number if it needs to do something with the Domoticz command. |
Today I probably can't test any further, but I'll flash my devices with the latest dev (2022.01.1 ?) ASAP to try it out too. Very curious! Tnx Theo for looking into this! BTW: best wishes for everyone! |
Hi @arendst , in the mean time I updated 4 of my devices, each time after it had a corruption. my S5 is running for almost 4 days without exception or reboot. Only S1 shows a lot of MQTT reconnects (72) while the others are low (<5) I will let you know in a couple of days, looks promising. |
Is 2022.01.1 OK? |
Yes. |
I'll OTA update a device or three (coming from 9.5.0) with it and I'll report back. |
First 3 devices on 2022.01.1 up for 20h. No exceptions, no corruptions. I've updated 5 more devices this morning. Only 2 left on 9.5.0. |
OK. Thanks for the feedback. That's in line with my obervations of previous "exceptional" devices too. I think it's safe to close this issue now. |
HERO! @arendst , somewhere I can donate you some coffee's? |
See the link in README.md |
Hi to all.
My question. Is this Domoticz or Tasmota related? |
I think it's best to open a new issue as this doesn't seem related. All 10 devices still up and running on the 2022.01.1 release. Domoticz 2021.1 beta 13872. I don't use the MQTT AD (autodiscovery) however, I use dummy devices. |
PROBLEM DESCRIPTION
My devices (10 Sonoff Mini, MiniR2 and BasicR3) randomly get their MQTT disabled. The console spams
every second. Timezone99 was my setting, but upon checking, the time is off and timezone gives result +104 instead of 99. As you can see below in the requested information, time says 04:14 instead of 21:14 (UTC+1 in Belgium)...
The following commands work OK, but after some time, the problem acts up again...
REQUESTED INFORMATION
Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!
Backlog Template; Module; GPIO 255
:Backlog Rule1; Rule2; Rule3
:Status 0
:weblog
to 4 and then, when you experience your issue, provide the output of the Console log:TO REPRODUCE
Happens randomly after half a day, 2 days, ...
EXPECTED BEHAVIOUR
Keep MQTT enabled and keep correct timezone. (I guess time difference gets the MQTT disabled?)
SCREENSHOTS
/
ADDITIONAL CONTEXT
These 10 devices have been running rock solid on 9.5.0 and before. Never had this problem before and it started giving this problem right after updating to v10.0.0.
I already tried a complete "Reset 2" and configuring my device as new, but after some days it start's again (MQTT suddenly disabled, timezone off and console message spam every second).
(Please, remember to close the issue when the problem has been addressed)
The text was updated successfully, but these errors were encountered: