Crashes nightly on T1 UK 3ch #3965
Comments
|
Please, provide also the status 0 |
|
also you have a powerretain to 1. This causes issues also. see https://www.youtube.com/watch?v=31IyfM1gygo&t=2s |
Seems to be a problem with your wifi core version but as there is no status 0 I can't know. If your esplib version is 2.4.0 or 2.4.1 that bug will occur. Or also can be because of the mqtt library chosen. Please, share the output of your status 0 command console |
ascillato2
added
awaiting feedback
|
Here's status 0. Thanks for the help |
|
I watched the video about powerretain. It's not a ghost switch event. The device is locked up: no wifi access, buttons don't work, relays are all on but the leds behind the buttons are off. |
|
Using your status 0: with decode-status.py: You can try to change the MQTT_PUBSUBCLIENT library to TASMOTA_MQTT in user_config.h file and recompile. Try to use lwIP 1.4 This alternative library is non blocking when you have a glitch or disconnection from your MQTT Broker. Also try to disable mDNS Discovery and MQTT Host Discovery in user_config.h file |
|
Come to think of it i used to compile with 1.4 and saw somewhere to switch to 2. It may have gotten worse since then. I'll try that. |
|
yes, depends on which libraries you use, sometimes lwIP 2 is better or worse |
|
Ok, all flashed up. Cross your fingers that it's not stuck tomorrow morning! |
|
If it is still not working you can try to use the fixed IP instead of |
|
Crashed again last night :( |
|
Also, last night the last line of logs is not MQTT, just one of the periodic Checking connection... / Connected messages. And it should have sent another pair or two of those before the next tele message. Wifi signal was 98 in the last tele sent. |
|
And I just realized it crashed again after I reset it this morning, uptime of just over 5 mins this time. |
|
The ESP8285 is not a problem. I just think you have a faulty hardware. |
|
Hi, Before discarding the hardware, let's try one last thing. Erase all flash using esptool.py |
|
I disabled my automations that automatically turn on the light based on a motion sensor outside (it's an exterior light) and it didn't crash last night. |
|
Hi, Can you give more details about that? Which Automation? from a Home Automation software or a rule? If it is an automation software, which one and which command is sending to your sonoff? |
|
No crash again last night. It's from Home Assistant. It's a kind of complicated rule that basically says If anyone got home (phone wifi tracking), or there's motion outside, and the sun is down and the lights are not already on, turn on the front door lights. Then 3 mins later turns them off. I did notice that one of the phone's wifi connections was flapping which was causing it to trigger often. command_topic: "cmnd/sonoff-front-lights/power2" |
|
Have you tried to fire that command manually to see if that hungs your device? |
|
Oh yeah. It goes off all the time and is fine. It would just lock up randomly at night. I'm thinking maybe an issue with the number of times commands are sent? |
|
The number of commands shouldn't be an issue. I have tested that and Tasmota works fine. No problem. If you send like 100 messages per second, a lot of messages will be ignored but will work. |
|
Do you have anything else attached to your Sonoff? Or it is just standard ? |
|
This one has an AMS312 PIR sensor on GPIO2 in Switch4n mode with an external pull down resistor. |
|
The source voltage for the PIR is being taken from the sonoff or you have another power source for that? I'm asking because the sonoff power source are very tight and taken power from them make some little power failures that gave some random issues. |
|
No separate power. VCC in the tele messages is always 3.500 or 3.499 though. |
|
Ok, perfect. So, that is not an issue there. |
|
So, to avoid any platformio issue, let's try this (I know it is a pain): Erase all flash using esptool.py |
|
Oh i probably should have mentioned I flash with arduino the first time. After that I always use OTA. |
|
ah, ok, So as to discard any issue with incorrect information left in the flash, please, try this (I know it is a pain): Erase all flash using esptool.py |
|
Hi Have you managed to solve your issue? |
|
I haven't had a chance to reflash, but removing the phone that flaps
between home and away from the triggers have stopped the crashing. This
points to a problem with mqtt commands. I tried sending off/on commands
rapidly but could not get it to crash though. You can close this for now
unless that gives you any ideas.
…On Sun, Oct 7, 2018, 4:31 PM Adrian Scillato ***@***.***> wrote:
Hi
Have you managed to solve your issue?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#3965 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAKE3EmHXIxb8sN34sUB2V6jBuoqInkZks5uimSkgaJpZM4XGFlQ>
.
|
|
I think that is better that you close the issue, so, if you start having the issue again you can reopen it. If we close it, you need to ask us for reopen. FYI: We are now testing the new MQTT Library called ArduinoMQTT and it is very promising. Also the new core that will be released from Arduino (hope to be soon), should have a lot of issues solved including the sleep feature. One thing I didn't ask you is that when you were compiling with Arduino, which lwIP did you choose? lwip 1.4, lwip 2 (low mem) or lwip 2 (high bandwidth) ? the more stables are using core 2.3.0 OR the core 2.4.2 but with the lwip 1.4 and using the TasmotaMQTT or ArduinoMQTT libraries. |
|
I was using iwip 2 high bandwith, but switched to iwip 1.4 and tasmota mqtt
at the suggestion of this thread. It didn't seem to make a difference.
…On Sun, Oct 7, 2018, 6:05 PM Adrian Scillato ***@***.***> wrote:
I think that is better that you close the issue, so, if you start having
the issue again you can reopen it. If we close it, you need to ask us for
reopen.
FYI: We are now testing the new MQTT Library called ArduinoMQTT and it is
very promising. Also the new core that will be released from Arduino (hope
to be soon), should have a lot of issues solved including the sleep feature.
One thing I didn't ask you is that when you were compiling with Arduino,
which lwIP did you choose? lwip 1.4, lwip 2 (low mem) or lwip 2 (high
bandwidth) ?
the more stable is using core 2.3.0 or the 2.4.2 with the lwip 1.4 and
using the TasmotaMQTT or ArduinoMQTT libraries.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#3965 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAKE3P12Vho2ftPcNXr93rZk_LLeqCJpks5uinq7gaJpZM4XGFlQ>
.
|
Almost every night my T1 UK 3ch will lock up and turn all the lights on. It will remain unresponsive until power is removed and restored. This seems to be happening more frequently now. Previously it was only once a month or so. It's possible there are external factors which have increased the frequency but I would like some help identifying what it might be.
This issue has persisted across version upgrades including effecting 5.1 (I'm running 6.2.1 now). It also persisted across me doing a config reset by incrementing the number.
I setup external syslog to try and capture what is happening. With level set to "More Debug" this is the last contents of the logs before it locks up. The last line is always MQTT so far.
It is set up with an AMS312 PIR sensor on GPIO2 in Switch4n mode with an external pull down resistor.
SwitchTopic is 1
SwitchMode4 is 1
The rest are defaults.
I run an MQTT server in Hass.io which controls the actions of the PIR sensor.
My user_config_override.h follows with passwords and ssids removed:
The text was updated successfully, but these errors were encountered: