-
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
When the WeMo emulation feature is enabled, the web ui is almost frozen. #5505
Comments
Sometimes i got EXCEPTION info as below: FYI.
|
Have you tried Core 2.4.2 too? http://thehackbox.org/tasmota/release/020402/sonoff.bin |
Yes, i've try 2.4.2, event 2.5.0 have the same symptom. if i uncheck the WeMo emulation then it will go back to normal. |
Strange, loaded 6.5.0.1 with Arduino stage and SDK 2.2.1 and enabled Belkin on a wemos mini configured as Sonoff Basic. It is up and running since 5 hours. Not a single reconnect and device is responsive as always. Gonna try precompiled release 6.5.0 (core 2.4.2). Will report... |
Please try flashing device with esptool.py. Before flashing erase whole flash with erase_flash |
yes, i usually use this tool as mentioned on above template. i don't know if it has any wrong, please correct me. thanks.
|
Device still fails? |
Sorry. Yes, it's still the same issue. |
I have no idea left. I cant reproduce this error. |
Reconnection (wifi) issues appear if power supply is bad. |
@wongnam Can you ping the device and upload the results? |
@Jason2866 i tried 20190309-170231-8a43cfb-sonoff.bin that it boot loops with Fatal exception.
|
Do you have a working version with this device? |
Been testing for #5506 too and noticed that with wemo emulation enabled on a ailight it indeed has a lot of MQTT retries and almost no web gui response. I haven't seen exceptions yet but I will investigate. |
@wongnam do you have a domoticz idx configured or are they all set to 0? |
@arendst Do you have tried different cores? I have tried 2.4.2 and stage core / sdk 2.2.1 and no issues |
I update more info. : the issue will happen when both MQTT are enable and connected with Emulation is turned on. |
Cannot reproduce today :-( |
6.5.0.2 20190325 * Change UDP initial message handling from string to char using static memory and add debug info (#5505)
@wongnam I still cannot reproduce but your problem may be due to too much UDP traffic. Before the change I made today, for every received UDP message it was copied to a dynamic string before checking if it was a valid M-SEARCH packet. This could lead to your exceptions as string management can not cope with releasing memory. The latest change only uses a string once a valid M-SEARCH packet has been recognised. It also adds some more debugging info (level 4) so pls give it a try and report back if you see many of these:
|
Alexa is still working :-) |
@Jason2866 could you try if the below changes in xplg_wemohue.ino lines 242-264 still work pls?
|
@arendst Yes, is working fine. Tested with echo dot 2g |
@arendst I saw many of this. yet to try your code(above).
|
I have not that many...
|
I have the exact same problem as OT. In fact, before disabling Wemo Emulation i thought i have multiple broken boards (i'm using dev-boards). Does wemo emulation put substantial stress on the chip? Tested with a self compiled sonoff basic 6.5.0 on 2.3. |
It's not so much that wemo emulation puts substantial stress on the chip as it is your UPnP environment. Both wemo and hue emulation use UDP for initial action and UDP traffic can be huge. Remember the Google Chromecast bug where it swamped your intranet with UDP messages bringing havoc to your UPnP devices. Possible UDP message sources are Sonos, TP-Link routers and Chromecast. Just enable emulation and log level 4 to see how much UDP packets come along. All packets need to be checked for a M-SEARCH type which might contain the wemo/hue request needed to control your emulation enabled device. |
Here's the log lvl4 for a basic with the changes to xplg_wemohue.ino above if that's any help. My router is configured to not use UPnP and the only devices i can think of that might pollute are a firetv stick and a hue bridge. I can replicate this on actual sonoffs and dev-boards. 09:40:21 MQT: Attempting connection... |
Try replacing the complete function PollUdp with this:
|
Looks like exactly the same to me :/
For some reason github just won't accept anything i put into code |
Did you use three backquotes like
|
@arendst it seam better now . the Sonoff response very fast. update: below result is after i replaced void PollUdp(void) and remove lines 242-264.
|
@wongnam from your log I see you do not have excessive UDP traffic; it looks almost like mine where most Packet (199) are coming from my routers. @narfel I do not see those MQTT reconnects but I wonder what version you are using as the log states 6.5.0(basic) where the latest dev release is 6.5.0.2... |
@arendst Yes, i saw many of Packet (199) but I don't understand what this is. issue or normal? update my result, it's perfect @arendst . Thank you.
|
@arendst Yes, my initial idea was to just upload via vscode to intialize the board and then use a hackbox binary. However when the wemo troubles began i didn't switch to dev. Here is a log of 6.5.0.2/2.4.2 with above replaced PollUdp function. I can't really see anything different in behaviour or even something that would raise concerns in the log. Any further idea how to troubleshoot? Comparing my log against @wongnams there seems to be no UDP messages for me but a lot of MQT reconnects. Is this even the same issue? I don't want to pollute the thread, yet the erroneous behavior is exactly like in the original post.
|
@narfel My log is no MQT re-connection. the MQTT command is sending from my SmartHome system to check the PowerOnState of the Relay only, please ignore it.
|
I confirm the issue is fixed. Thank you very much. |
BUG DESCRIPTION
When the WeMo emulation feature is enabled, the web ui is almost frozen, the console shows that the network connection has been interrupted continuously.
status 0
:05:16:59 CMD: weblog 4
05:16:59 MQT: stat/sonoff/RESULT = {"WebLog":4}
05:16:59 CFG: Saved to flash at F6, Count 22, Bytes 3584
05:17:16 UPP: Multicast disabled
05:17:16 MQT: Attempting connection...
05:17:16 MQT: Connected
05:17:16 MQT: tele/sonoff/LWT = Online (retained)
05:17:16 MQT: cmnd/sonoff/POWER =
05:17:16 MQT: Subscribe to cmnd/sonoff/#
05:17:16 MQT: Subscribe to cmnd/sonoffs/#
05:17:16 MQT: Subscribe to cmnd/DVES_797107_fb/#
05:17:17 UPP: Multicast (re)joined
05:17:47 WIF: Checking connection...
05:17:47 WIF: Connected
05:17:47 UPP: Multicast disabled
05:17:47 MQT: Attempting connection...
05:17:47 MQT: Connected
05:17:47 MQT: tele/sonoff/LWT = Online (retained)
05:17:47 MQT: cmnd/sonoff/POWER =
05:17:47 MQT: Subscribe to cmnd/sonoff/#
05:17:47 MQT: Subscribe to cmnd/sonoffs/#
05:17:47 MQT: Subscribe to cmnd/DVES_797107_fb/#
05:17:48 UPP: Multicast (re)joined
05:18:07 UPP: Multicast disabled
05:18:07 MQT: Attempting connection...
05:18:07 MQT: Connected
05:18:07 MQT: tele/sonoff/LWT = Online (retained)
05:18:07 MQT: cmnd/sonoff/POWER =
05:18:07 MQT: Subscribe to cmnd/sonoff/#
05:18:07 MQT: Subscribe to cmnd/sonoffs/#
05:18:07 MQT: Subscribe to cmnd/DVES_797107_fb/#
05:18:08 UPP: Multicast (re)joined
05:18:22 WIF: Checking connection...
05:18:22 WIF: Connected
05:18:38 UPP: Multicast disabled
05:18:38 MQT: Attempting connection...
05:18:38 MQT: Connected
05:18:38 MQT: tele/sonoff/LWT = Online (retained)
05:18:38 MQT: cmnd/sonoff/POWER =
05:18:38 MQT: Subscribe to cmnd/sonoff/#
05:18:38 MQT: Subscribe to cmnd/sonoffs/#
05:18:38 MQT: Subscribe to cmnd/DVES_797107_fb/#
05:18:39 UPP: Multicast (re)joined
TO REPRODUCE
(Please, remember to close the issue when the problem has been addressed)
The text was updated successfully, but these errors were encountered: