search

arendst / Tasmota

Alternative firmware for ESP8266 and ESP32 based devices with easy configuration using webUI, OTA updates, automation using timers or rules, expandability and entirely local control over MQTT, HTTP, Serial or KNX. Full documentation at
https://tasmota.github.io/docs
GNU General Public License v3.0
21.97k stars 4.77k forks source link

Alexa issue #10430

Closed wchulze closed 3 years ago

wchulze commented 3 years ago

PROBLEM DESCRIPTION

I have been using the Tasmota version 6.3.0 for about 20 Sonoff Basic's for several years and have not had any worries with the Belkin Wemo emulation. I control the sockets with Amazon Echo. Now I've added two Tuya dimmers to my IoT park. The setup - including the heartbeat - went without a hitch. With the Tasmota version 6.3.0, however, the HUE emulation does not work properly in conjunction with Alexa, ok. So I installed the current version (9.2.0) of Tasmata. The Tuya dimmers work fine. To my astonishment, there are now problems with network transmission. Alexa often reports "the device does not respond ...". In order to rule out that the problem comes from the dimmers, I installed version 9.2 on a Sonof Basic - with the result that the same problem now occurs there.

If the Sonoff website is called up in the browser (Chrome), there are sometimes waiting times of 6 seconds until the interface appears, which is very long. The "Sleep" setting is set to 40ms. Other values for Sleep do not change the behavior.

Tasmota shows an RSSI value of 54% at -68 dBm in the "information page", which is sufficient. MQTT is deactivated.

I have now experimented with different Tasmota versions: if the HUE emulation works in the version, there are problems with the WLAN access. That may be a coincidence. However, if an error occurs, the Belkin Wemo emulation has the same problem. For programming I use "Tasmota-PyFlasher-1.0" and delete the flash memory completely.

I have now varied the distance between the Sonoff and my router. From an RSSI of < 55% problems occur in version 9.2. Version 6.3 plays up to RSSI 25% without problems. The distance between the router and the Sonoff can be considerably greater with version 6.3.0, more than twice.

What can I do to solve the problem? I'm compiling the project with Visual Studio Code V1.50.1. Unfortunately, I have no more ideas at the moment. Thanks for a hint.

REQUESTED INFORMATION

Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!

- [ ] If using rules, provide the output of this command: `Backlog Rule1; Rule2; Rule3`:
```lua
  Rules output here:


- [ ] Set `weblog` to 4 and then, when you experience your issue, provide the output of the Console log:
```lua
  Console output here:
na, 

### TO REPRODUCE
_Steps to reproduce the behavior:_

Update from Tasmota Version 6.3.0 to Tasmota Version 9.2.0

### EXPECTED BEHAVIOUR
_A clear and concise description of what you expected to happen._

See problem description above

### SCREENSHOTS
_If applicable, add screenshots to help explain your problem._

na

### ADDITIONAL CONTEXT
_Add any other context about the problem here._

**(Please, remember to close the issue when the problem has been addressed)**
ascillato commented 3 years ago

Please, could you be so kind on completing the troubleshooting template in order to have more information so as to properly help you?

Without status 0 output, log outputs, etc, etc, there is no information to help you.

Remember to read the Contributing Guideline and Policy. Thanks.

Support Information

See Docs for more information. See Chat for more user experience. See Community for forum. See Code of Conduct

wchulze commented 3 years ago

Sorry, I forget to fill the template. Hopefully you have enough information now. Regards Wolfgang

ascillato commented 3 years ago

Please, set weblog to 4 and then copy the output of the console when you see your problem.

Jason2866 commented 3 years ago

Since you upgraded from Tasmota 6.x using a older Arduino ESP8266 core it is always a good idea to initiate wifi recalibration. This is done by reset 3 NO settings are lost. After device is back online it is neccessary to switch off / on the power supply. Only with off / on the new calibration settings are used.

wchulze commented 3 years ago

Hallo Jason2866 The upgrade is done by erase the flash with Tasmota-PyFlasher-1.0. I think no calibration is necessary. I have setup the dive manually after "upgrade"

Adrian, this is the console output after failed connection from Alexa.

14:26:02 UDP: Packet (119)
14:26:15 WIF: Prüfe Verbindung...
14:26:35 WIF: Prüfe Verbindung...
14:26:55 WIF: Prüfe Verbindung...
14:27:15 WIF: Prüfe Verbindung...
14:27:35 WIF: Prüfe Verbindung...
14:27:55 WIF: Prüfe Verbindung...
14:27:57 UDP: Packet (119)
14:28:07 UDP: Packet (119)
14:28:15 WIF: Prüfe Verbindung...
14:28:23 UDP: Packet (119)
14:28:23 UDP: Packet (119)
14:28:24 UPP: Hue 3 Antwortpakete gesendet zu 192.168.178.57:50000
14:28:24 HTP: Hue-Setup
14:28:25 HTP: Hue-API (/723620/lights) from 192.168.178.57
14:28:25 HTP: Hue Result ({"119759361":{"state":{"on":false,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"sonoff1","modelid":"Generic","manufacturername":"Tasmota","uniqueid":"5c:cf:7f:72:36:20:00:11-1"},"119759362":{"state":{"on":false,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"sonoff1t1","modelid":"Generic","manufacturername":"Tasmota","uniqueid":"5c:cf:7f:72:36:20:00:11-2"}})
14:28:25 HTP: Hue-API (/723620/lights/119759361) from 192.168.178.57
14:28:25 /lights path=/lights/119759361
14:28:25 HTP: Hue Result ({"state":{"on":false,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"sonoff1","modelid":"Generic","manufacturername":"Tasmota","uniqueid":"5c:cf:7f:72:36:20:00:11-1"})
14:28:25 HTP: Hue-API (/723620/lights/119759362) from 192.168.178.57
14:28:25 /lights path=/lights/119759362
14:28:25 HTP: Hue Result ({"state":{"on":false,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"sonoff1t1","modelid":"Generic","manufacturername":"Tasmota","uniqueid":"5c:cf:7f:72:36:20:00:11-2"})
14:28:25 HTP: Hue-API (/723620/lights) from 192.168.178.57
14:28:25 HTP: Hue Result ({"119759361":{"state":{"on":false,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"sonoff1","modelid":"Generic","manufacturername":"Tasmota","uniqueid":"5c:cf:7f:72:36:20:00:11-1"},"119759362":{"state":{"on":false,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"sonoff1t1","modelid":"Generic","manufacturername":"Tasmota","uniqueid":"5c:cf:7f:72:36:20:00:11-2"}})
14:28:29 UDP: Packet (119)
14:28:30 HTP: Konsole
14:28:35 WIF: Prüfe Verbindung...
14:28:55 WIF: Prüfe Verbindung...

"State info"

14:47:20 HTP: Konsole
14:47:25 CMD: state
14:47:25 SRC: WebConsole from 192.168.178.85
14:47:25 CMD: Gruppe 0, Index 1, Befehl "STATE", Daten ""
14:47:25 RSL: RESULT = {"Time":"2021-01-07T14:47:25","Uptime":"0T16:06:35","UptimeSec":57995,"Heap":26,"SleepMode":"Dynamic","Sleep":40,"LoadAvg":24,"MqttCount":0,"POWER1":"OFF","POWER2":"OFF","Wifi":{"AP":1,"SSId":"wolfgangtespe","BSSId":"9C:C7:A6:30:9E:65","Channel":1,"RSSI":40,"Signal":-80,"LinkCount":1,"Downtime":"0T00:00:04"}}
14:47:35 WIF: Prüfe Verbindung...
14:47:55 WIF: Prüfe Verbindung...
14:48:02 UDP: Packet (119)
14:48:07 UDP: Packet (119)
14:48:15 WIF: Prüfe Verbindung...

Wolfgang

Jason2866 commented 3 years ago

Take care that NO Alexa app or program is running. If this is the case the packets are send to the wrong address. See example (first Alexa app, second real Echo device!):

15:44:11.750 UPP: Hue 3 response packets sent to 192.168.2.162:50000
15:44:11.961 HTP: Hue setup
15:45:57.348 UPP: Hue 3 response packets sent to 192.168.2.140:50000
15:45:57.799 HTP: Hue setup

If you have devices in Alexa which are not working or have a mark "Gerät reagiert nicht" Delete all this devices. The prevent a successful discovery!

Just tried again with latest development version. Tasmota Hue Light device. Discover works and dimming too.

16:11:23.802 SRC: Hue
16:11:23.808 MQT: stat/sonoff-D43BE2/RESULT = {"POWER":"OFF"}
16:11:23.811 MQT: stat/sonoff-D43BE2/POWER = OFF
16:11:24.852 CFG: Saved to flash at F8, Count 20, Bytes 4096
16:11:25.178 SRC: Hue
16:11:25.184 MQT: stat/sonoff-D43BE2/RESULT = {"POWER":"ON"}
16:11:25.188 MQT: stat/sonoff-D43BE2/POWER = ON
16:11:25.812 CFG: Saved to flash at F7, Count 21, Bytes 4096
16:11:32.231 SRC: Hue
16:11:32.237 MQT: stat/sonoff-D43BE2/RESULT = {"POWER":"ON"}
16:11:32.241 MQT: stat/sonoff-D43BE2/POWER = ON
16:11:32.247 MQT: stat/sonoff-D43BE2/RESULT = {"POWER":"ON","Dimmer":100}
16:11:32.814 CFG: Saved to flash at F6, Count 22, Bytes 4096
wchulze commented 3 years ago

Hello Jason2866 Yesterday I have set up the sonoff and in addition, I deleted it in Alexa in the Internet browser and reconnected it. Otherwise the HUE emulation could not work.

Normally, 99, ..% , everything works fine. The problem occurs only sporadically, especially with low signal levels on the Sonnoff. That with not running an Alexa app would mean that all smartphones must have to be switched off, wow.

Why should Amazon send a nonsensical command to one of my echoes when the level at the Sonnoff is low?

Here is a working recording just some minutes ago:

16:26:06 WIF: Prüfe Verbindung...
16:26:12 HTP: Hue-API (/723620/lights/119759361/state) from 192.168.178.57
16:26:12 HTP: Hue POST-Argumente ({"on":true})
16:26:12 SRC: Hue
16:26:12 RSL: RESULT = {"POWER1":"ON"}
16:26:12 RSL: POWER1 = ON
16:26:12 HTP: Hue Result ([{"success":{"/lights/119759361/state/on":true}}])
16:26:12 HTP: Hue-API (/723620/lights/119759361) from 192.168.178.57
16:26:12 /lights path=/lights/119759361
16:26:12 HTP: Hue Result ({"state":{"on":true,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"sonoff1","modelid":"Generic","manufacturername":"Tasmota","uniqueid":"5c:cf:7f:72:36:20:00:11-1"})
16:26:26 WIF: Prüfe Verbindung...

Wolfgang

wchulze commented 3 years ago

I've just looked at the console output of the Sonoff. All the output there come from the Sonoff itself and not an Echo.

The Sonoff has been addressed by my echo. I find the reaction in the console.

Why does the Sonoff send to 192.168.178.57 the echo in my kitchen near the router 14:28:24 UPP: Hue 3 Antwortpakete gesendet zu 192.168.178.57:50000

carries out a setup 4:28:24 HTP: Hue-Setup

and gets from the echo 14:28:25 HTP: Hue-API (/723620/lights) from 192.168.178.57

and then send 14:28:25 HTP: Hue Result ({"119759361":{"state":{"on":false,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"sonoff1","modelid":"Generic","manufacturername":"Tasmota","uniqueid":"5c:cf:7f:72:36:20:00:11-1"},"119759362":{"state":{"on":false,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"sonoff1t1","modelid":"Generic","manufacturername":"Tasmota","uniqueid":"5c:cf:7f:72:36:20:00:11-2"}})

I don't see any communication between the Alexa app and the Echo, as well.

If it goes well it looks like this: 22:58:01 HTP: Hue-API (/723620/lights/119759361/state) from 192.168.178.57 22:58:01 HTP: Hue POST-Argumente ({"on":true}) 22:58:01 SRC: Hue 22:58:01 RSL: RESULT = {"POWER1":"ON"} 22:58:01 RSL: POWER1 = ON 22:58:01 HTP: Hue Result ([{"success":{"/lights/119759361/state/on":true}}]) 22:58:01 HTP: Hue-API (/723620/lights/119759361) from 192.168.178.57 22:58:01 /lights path=/lights/119759361 22:58:01 HTP: Hue Result ({"state":{"on":true,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"sonoff1","modelid":"Generic","manufacturername":"Tasmota","uniqueid":"5c:cf:7f:72:36:20:00:11-1"})

  1. Somehow there seems to be something wrong with the communication between Tasmota and the Echo.

2: There are no problems of this kind with Tasmota version 6.3.0.

3: I have not yet dig into the Belkin Wemo emulation with V9.2.0 except that if it comes to an error. Alexa acknowledges with "The device does not answer ...".

Wolfgang

Jason2866 commented 3 years ago

I can not reproduce the issue you have. Device with low rssi do work for me too (Webfrontend, Alexa and mqtt).

wchulze commented 3 years ago

As with the HUE emulation, the error only occurs rarely and sporadically. I think that the wrong behavior is probably not an emulation problem but rather to find in the communication between Tasmota and an Amazon echo.

I have now deactivated all Alexa apps on my smartphones and tablets for testing purposes. Unfortunately the problem remains, no change.

On the test device (Sonoff Basic) I activated the Belkin WeMo emulation, then deleted it from Amazon and reactivated it. I will investigate the behavior.

Wolfgang

wchulze commented 3 years ago

That you cannot reproduce the issue may be due to the nature of the sporadic occurrence. The error quickly appeared in my arrangement.

Here is the log from the console.

21:10:11 UDP: Packet (119) 21:10:11 UDP: Packet (119) 21:10:13 WMO: WeMo Type 2, Antwort gesendet to 192.168.178.57:50000 21:10:15 HTP: WeMo-Setup from 192.168.178.57 21:10:16 HTP: Konsole 21:10:17 HTP: WeMo basic event from 192.168.178.57 21:10:18 UDP: Packet (119) 21:10:25 WIF: Prüfe Verbindung... 21:10:38 UDP: Packet (119) 21:10:38 UDP: Packet (119) 21:10:39 UDP: Packet (119) 21:10:45 WIF: Prüfe Verbindung...

I added the "Status".

21:11:04 CMD: state 21:11:04 SRC: WebConsole from 192.168.178.85 21:11:04 CMD: Gruppe 0, Index 1, Befehl "STATE", Daten "" 21:11:04 RSL: RESULT = {"Time":"2021-01-07T21:11:04","Uptime":"0T01:22:23","UptimeSec":4943,"Heap":25,"SleepMode":"Dynamic","Sleep":40,"LoadAvg":24,"MqttCount":0,"POWER":"OFF","Wifi":{"AP":1,"SSId":"wolfgangtespe","BSSId":"9C:C7:A6:30:9E:65","Channel":1,"RSSI":40,"Signal":-80,"LinkCount":1,"Downtime":"0T00:00:04"}} 21:11:05 WIF: Prüfe Verbindung...

This console printout shows a good transmission afterwards.

21:15:45 WIF: Prüfe Verbindung... 21:16:05 WIF: Prüfe Verbindung... 21:16:09 HTP: WeMo basic event from 192.168.178.57 21:16:09 SRC: Wemo 21:16:09 RSL: RESULT = {"POWER":"ON"} 21:16:09 RSL: POWER = ON 21:16:09 HTP: WeMo basic event from 192.168.178.57 21:16:13 HTP: Konsole

Jason2866 commented 3 years ago

You can try setoption41 60

wchulze commented 3 years ago

Thanks. Good idea with the ARP. Already had the assumption that my Fritzbox ... falls asleep. Unfortunately, the ARP doesn't help either.

19:15:14 UDP: Packet (119) 19:15:28 WIF: Sending Gratuitous ARP 19:15:30 WIF: Prüfe Verbindung... 19:15:38 UDP: Packet (119) 19:15:38 UDP: Packet (119) 19:15:38 UDP: Packet (119) 19:15:40 UPP: Hue 3 Antwortpakete gesendet zu 192.168.178.57:50000 19:15:40 HTP: Hue-Setup 19:15:40 HTP: Hue-API (/723620/lights) from 192.168.178.57 19:15:40 HTP: Hue Result ({"119759361":{"state":{"on":false,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"sonoff1","modelid":"Generic","manufacturername":"Tasmota","uniqueid":"5c:cf:7f:72:36:20:00:11-1"},"119759362":{"state":{"on":false,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"sonoff1t1","modelid":"Generic","manufacturername":"Tasmota","uniqueid":"5c:cf:7f:72:36:20:00:11-2"}}) 19:15:40 HTP: Hue-API (/723620/lights/119759361) from 192.168.178.57 19:15:40 /lights path=/lights/119759361 19:15:40 HTP: Hue Result ({"state":{"on":false,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"sonoff1","modelid":"Generic","manufacturername":"Tasmota","uniqueid":"5c:cf:7f:72:36:20:00:11-1"}) 19:15:40 HTP: Hue-API (/723620/lights/119759362) from 192.168.178.57 19:15:40 /lights path=/lights/119759362 19:15:40 HTP: Hue Result ({"state":{"on":false,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"sonoff1t1","modelid":"Generic","manufacturername":"Tasmota","uniqueid":"5c:cf:7f:72:36:20:00:11-2"}) 19:15:41 HTP: Hue-API (/723620/lights) from 192.168.178.57 19:15:41 HTP: Hue Result ({"119759361":{"state":{"on":false,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"sonoff1","modelid":"Generic","manufacturername":"Tasmota","uniqueid":"5c:cf:7f:72:36:20:00:11-1"},"119759362":{"state":{"on":false,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"sonoff1t1","modelid":"Generic","manufacturername":"Tasmota","uniqueid":"5c:cf:7f:72:36:20:00:11-2"}}) 19:15:42 UDP: Packet (119) 19:15:42 UDP: Packet (119) 19:15:42 UDP: Packet (119)

I rummaged through the source code. The message "Hue 3 Antwortpakete gesendet zu ..." seems to be issued when a UDP message has timed out. The time for this is calculated by: uint32_t response_delay = UDP_MSEARCH_SEND_DELAY + ((millis () & 0x7) * 100); and is possibly quite tight with1500 ms.

Is it worth increasing this time?

Wolfgang

wchulze commented 3 years ago

Increasing the waiting time was unsuccessful. The behavior is basically the same as before, except that the error message from Alexa is announced later.

Wolfgang

s-hadinger commented 3 years ago

@wchulze I removed completely the time in #10514 although I don't think it's the issue here. Please try with the new version.

wchulze commented 3 years ago

Thanks. I don't think it will solve the problem. It is still worth a try. Where can I find the version?

Wolfgang

ascillato2 commented 3 years ago

http://ota.tasmota.com/tasmota/tasmota.bin.gz

wchulze commented 3 years ago

Thanks. I installed version 9.2.0.3. The result is even worse. Dropouts now occur with an RSSI of 70% and a field strength of -64dBm.

In order to exclude the router (FritzBox) I tried yesterday with a Ciso, same problem.

15:07:30.878 UDP: Packet (119) 15:07:30.887 UPP: Hue 3 response packets sent to 192.168.178.29:50000 15:07:30.918 UDP: Packet (119) 15:07:30.920 UDP: Packet (119) 15:07:39.628 WIF: Checking connection... 15:07:42.600 HTP: Hue API (/723620/lights/119759361/state) from 192.168.178.57 15:07:42.602 HTP: Hue POST args ({"on":false}) 15:07:42.609 SRC: Hue 15:07:42.613 RSL: RESULT = {"POWER1":"OFF"} 15:07:42.616 RSL: POWER1 = OFF 15:07:42.618 HTP: Hue Result ([{"success":{"/lights/119759361/state/on":false}}]) 15:07:42.720 HTP: Hue API (/723620/lights/119759361) from 192.168.178.57 15:07:42.723 /lights path=/lights/119759361 15:07:42.732 HTP: Hue Result ({"state":{"on":false,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"son... 15:07:51.578 UDP: Packet (119) 15:07:54.392 HTP: Console 15:08:00.110 WIF: Checking connection... 15:08:13.791 CMD: state 15:08:13.794 SRC: WebConsole from 192.168.178.85 15:08:13.798 CMD: Group 0, Index 1, Command "STATE", Data "" 15:08:13.804 RSL: RESULT = {"Time":"2021-01-11T15:08:13","Uptime":"0T00:02:04","UptimeSec":124,"Heap":26,"SleepMode":"Dynamic","Sleep":40,"LoadAvg":24,"MqttCount":0,"POWER1":"OFF","POWER2":"OFF","Wifi":{"AP":1,"SSId":"wolfgangtespe","BSSId":"9C:C7:A6:30:9E:65","Channel":1,"RSSI":70,"Signal":-64,"LinkCount":1,"Downtime":"0T00:00:04"}}

Wolfgang

ascillato commented 3 years ago

In order to rule out a scrambled settings in the wifi parameters of the SDK, please do a reset 3 to recalibrate the wifi radio settings and then do a reset 6 to reset internal Tasmota settings to default. After that, please, re configure your device manually and test again. Thanks.

wchulze commented 3 years ago

Thanks, I had made a fresh instalation with Tasmota-PyFlasher-1.0. Then the state from 9.2.0.0 restored. Will do command reset 3 and 6 and then make the setting by hand.

Wolfgang

wchulze commented 3 years ago

Here is the result after a few minutes. With low RSSI and moderate level. But it should work anyway.

16:45:03.219 UDP: Packet (119) 16:45:03.228 UPP: Hue 3 response packets sent to 192.168.178.57:50000 16:45:03.622 HTP: Hue setup 16:45:03.722 HTP: Hue API (/723620/lights) from 192.168.178.57 16:45:03.739 HTP: Hue Result ({"119759361":{"state":{"on":true,"alert":"none","effect":"none","reachable":true},"type":"Extended color light"... 16:45:03.823 HTP: Hue API (/723620/lights/119759361) from 192.168.178.57 16:45:03.826 /lights path=/lights/119759361 16:45:03.836 HTP: Hue Result ({"state":{"on":true,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"Sono... 16:45:03.923 HTP: Hue API (/723620/lights/119759362) from 192.168.178.57 16:45:03.927 /lights path=/lights/119759362 16:45:03.936 HTP: Hue Result ({"state":{"on":false,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"Son... 16:45:04.022 HTP: Hue API (/723620/lights) from 192.168.178.57 16:45:04.039 HTP: Hue Result ({"119759361":{"state":{"on":true,"alert":"none","effect":"none","reachable":true},"type":"Extended color light"... 16:45:05.973 UDP: Packet (119) 16:45:08.078 WIF: Checking connection... 16:45:18.049 UDP: Packet (119) 16:45:24.108 UDP: Packet (119) 16:45:28.676 UDP: Packet (119) 16:45:30.409 HTP: Console 16:45:42.741 UDP: Packet (119) 16:45:43.637 UDP: Packet (119) 16:45:43.639 UDP: Packet (119) 16:45:43.642 UDP: Packet (119) 16:45:44.193 CMD: state 16:45:44.195 SRC: WebConsole from 192.168.178.85 16:45:44.199 CMD: Group 0, Index 1, Command "STATE", Data "" 16:45:44.204 RSL: RESULT = {"Time":"2021-01-11T16:45:44","Uptime":"0T00:18:17","UptimeSec":1097,"Heap":27,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":0,"POWER1":"ON","POWER2":"OFF","Wifi":{"AP":1,"SSId":"wolfgangtespe","BSSId":"9C:C7:A6:30:9E:65","Channel":1,"RSSI":38,"Signal":-81,"LinkCount":1,"Downtime":"0T00:00:03"}}

Wolfgang

ascillato commented 3 years ago

"RSSI":38 is very low. With that poor wifi coverage, you should expect low response and/or commands to be missed.

The Wifi signal coverage can not be solved by software. You need to expand your wifi coverage with extra wifi routers.

wchulze commented 3 years ago

That is known. I chose the bad place just to get the problem faster. In the problem descrition on the top I wrote

I have now varied the distance between the Sonoff and my router. From an RSSI of < 55% problems occur in version 9.2. Version 6.3 plays up to RSSI 25% without problems. The distance between the router and the Sonoff can be considerably greater with version 6.3.0, more than twice.

Wolfgang

s-hadinger commented 3 years ago

Your logs show normal Hue discovery I'm afraid the issue comes from something else

wchulze commented 3 years ago

To find out where the problem might come from, I installed a different firmware for test purposes. Two screen shots of the result are shown below.

image

#############################################################################################

image

There are 2 Sonoff baisc. They are next to each other in the same place with different firmware. Same SDK and core version. I am confused.

Wolfgang

Jason2866 commented 3 years ago

Different hardware (not a single device is exactly the same) different places (yes a few cm does care!). The values are similar. Nothing what surprises. Wlan is HF

wchulze commented 3 years ago

Rss 34% is similar to 78%, mhm. I am very aware of he high frequency properties (I developed HF modules @Philips). If there are only slight reflectionsin a distance of Lamda , a few cm does not matter. That is the case.

In addition, tried that with the same hardware. the result can be compared. A few dB of filed strenght (3..4, mybe 6 ) difference is normal. The signal changes in this order of magnitude. That doesn't explain the behavior.

Here, just for the sake of completeness:

_Tasmota version 6.3.0 Build Date & Time 03/02/2019 11:16:17 AM Core / SDK version 2_30 / 1.5.3 (aec24ac9)

without any dropouts over the livespan with a poor RSSI.

20:39:54 CMD: weblog 4 20:39:54 RSL: RESULT = {"WebLog":4} 20:39:54 CFG: in Flash gespeichert am FB, zählen 1723, Bytes 3584 20:39:59 HTP: WeMo basic event 20:39:59 SRC: Wemo 20:39:59 RSL: RESULT = {"POWER":"OFF"} 20:39:59 RSL: POWER = OFF 20:39:59 HTP: WeMo basic event 20:40:00 WIF: Prüfe Verbindung... 20:40:00 WIF: verbunden 20:40:11 HTP: WeMo basic event 20:40:11 SRC: Wemo 20:40:11 RSL: RESULT = {"POWER":"OFF"} 20:40:11 RSL: POWER = OFF 20:40:11 HTP: WeMo basic event 20:40:18 CMD: state 20:40:18 SRC: WebConsole from 192.168.178.85 20:40:18 RSL: empfangenes topic /state, Datengröße 0, Daten 20:40:18 RSL: Gruppe 0, Index 1, Befehl STATE, Daten 20:40:18 RSL: RESULT = {"Time":"2021-01-11T20:40:18","Uptime":"2T05:19:29","Vcc":3.226,"POWER":"OFF","Wifi":{"AP":1,"SSId":"wolfgangtespe","BSSId":"9C:C7:A6:30:9E:65","Channel":1,"RSSI":28}} 20:40:20 WIF: Prüfe Verbindung...

Wolfgang

ascillato commented 3 years ago

Arduino core version 2.3.0 is known to report a higher RSSI but it is wrong. The more approximate value to the reality is from the latest core.

Also, core 2.3.0 is very old and has serious security bugs. You should stop using it right now (If anyone goes close to your home and broadcast a wifi network with their phone, using the same SSID as yours but without password, any software based on core 2.3.0 will connect to it and will provide full access to your device - OTA updates etc.)

Also core 2.3.0 is deprecated and no longer supported anymore. It uses a lot of energy compared to latest core and have other stability issues.

With a RSSI below 50%, the wifi connection is not super reliable. You need 60% or more for a good connection.

ascillato commented 3 years ago

I have done a huge amount of tests with several brands of routers and several devices types of ESP8266, when we were testing which SDK version of the Arduino core was more stable.

That is why, a connection below 35% is not reliable at all. You need a better wifi coverage. Take into account to have at least 60% RSSI or add Access Points to increase your wifi coverage. If you can't, you can change the device with low RSSI, to one of the wemos mini that have external antenna and will increase about 20% the measured RSSI.

wchulze commented 3 years ago

Thanks for the safety instructions. How does a new core protect against this behavior?

I believe that your test was very successful. How I could build a mesh is clear to me.

Normally I don't run Tasmota under such difficult conditions. I explaid why I did it. The levels are usually> -60 dBm (RSSI> 70% ). But, as I have already described above, sporadic dropouts occur with V9.0.0 at these levels. Quite seldom, but remarkable because in my living room, kitchen, ... the lighst sometimes does not go on / off. My wife looks funny then.

It could also be possible that the channel load plays a role. Switching to other channels didn't help.

My FriztBox can record the channel utilization. Seems like worries occur at values over 20%. Difficult to reproduce. That shouldn't play a role with the small amount of data transmitted by Tasmota, but who knows?

image

ascillato commented 3 years ago

How does a new core protect against this behavior?

The actual Arduino core don't have that bug. That simple attack doesn't work now. That is why, update to latest is highly recommended.

It could also be possible that the channel load plays a role. Switching to other channels didn't help.

Obviously, you have to measure the channel utilization from your wifi and the interference from your neighbours, and choose the one that is free or less used.

Quite seldom, but remarkable because in my living room, kitchen, ... the lighst sometimes does not go on / off. My wife looks funny then.

That is just with Alexa right? With MQTT you don't have that issue right? And you have access to the webinterface of your device when it didn't respond to Alexa? If not, your issue is the ARP Table of your Fritzbox.

Core 2.3.0 didn't have the sleep function so, it didn't use the DTIM feature of the wifi protocol. Some Wifi Routers don't have a good implementation of ARP Table with DTIM and the sleep functions of devices. Some routers need a specific extra config for properly managing this (like MULTICAST-HELPER=FULL in Mikrotik routers). Some others just have this correctly set by default. Others don't have anything and need that you set in Tasmota the Gratuitous ARP using its corresponding SetOption.

wchulze commented 3 years ago

Thanks for the detailed answer. I don't know exactly whether the problem is to be attributed to Alexa. With Alexa, I expect rather symtomatic and not sporadic errors.

I don't use MQTT. I use Alexa and HTTP commands via RCoid.

When I access Tasmota via the web interface, the problem is typically no longer available ( sporadic dropouts )

In order to identify an ARP table problem I tried 2 routers: FritzBox and Cisco. Gratuitous ARP with setoption41 60 was also unsuccessful.

Wolfgang

ascillato commented 3 years ago

When your device is not reachable, please, do a ping to its known IP and try again. If after the ping, you can reach your device again, it is indeed a misconfiguration of your router's ARP table that forgets the match IP to MAC Address. May be an incompatible ARP lease time vs DHCP lease time.

wchulze commented 3 years ago

I know, thanks. The device is reachable.

Ping wird ausgeführt für 192.168.178.21 mit 32 Bytes Daten: Antwort von 192.168.178.21: Bytes=32 Zeit=26ms TTL=255 Antwort von 192.168.178.21: Bytes=32 Zeit=41ms TTL=255 Antwort von 192.168.178.21: Bytes=32 Zeit=56ms TTL=255 Antwort von 192.168.178.21: Bytes=32 Zeit=64ms TTL=255

Ping-Statistik für 192.168.178.21: Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust), Ca. Zeitangaben in Millisek.: Minimum = 26ms, Maximum = 64ms, Mittelwert = 46ms

When I access Tasmota via the web interface, the problem is typically no longer available ( sporadic dropouts )

Jason2866 commented 3 years ago

Your Ping times are high. Normal values are <10 ms. Something is fishy in your Network

ascillato commented 3 years ago

Yes, ping times are much higher than normal. I also have ping times of <10ms for wifi devices (Tasmotas). My Network consists of 2 AP, 1 router and 82 devices where 73 are wifi and 64 are Tasmotized devices. So, seems that you have an issue with your Router's configuration.

I can reproduce this issue only if I don't use Multicast-helper=full in my mikrotik router (and latest mikrotik firmware). Without this configuration I also have problems with other devices too.

So, seems that your issue is not Tasmota related but more the configuration of your router and how that configuration interacts with the Arduino core. Yes, you didn't see this issue with the older Arduino core, but also the old wifi implementation of the wifi core wasn't complete and never uses the sleep function and DTIM. This made that some devices got overheated and start failing, besides the excess of energy used on them.

To solve your wifi issue, you need to change your wifi properties in your router as it have been long discussed in old issues.

wchulze commented 3 years ago

Since I didn't find anything in my router that could apply to problems. A consultation with AVM did not provide any new information.

Therefore, for test purpose, I placed 2 Sonoffs near the router.

192.168.178.20 contains Tasomta and 192.168.178.80 ESPurna. Both firmware versions contain the same core. Information I have posted 2 days ago.

Then I pinged the Sonoffs several times. That should avoid start-up problems. Final result see below.

Tasmota C:\Windows\system32>ping 192.168.178.20

Ping wird ausgeführt für 192.168.178.20 mit 32 Bytes Daten: Antwort von 192.168.178.20: Bytes=32 Zeit=62ms TTL=128 Antwort von 192.168.178.20: Bytes=32 Zeit=79ms TTL=128 Antwort von 192.168.178.20: Bytes=32 Zeit=99ms TTL=128 Antwort von 192.168.178.20: Bytes=32 Zeit=24ms TTL=128

Ping-Statistik für 192.168.178.20: Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust), Ca. Zeitangaben in Millisek.: Minimum = 24ms, Maximum = 99ms, Mittelwert = 66ms

#################################################################

ESPurna C:\Windows\system32>ping 192.168.178.80

Ping wird ausgeführt für 192.168.178.80 mit 32 Bytes Daten: Antwort von 192.168.178.80: Bytes=32 Zeit=2ms TTL=255 Antwort von 192.168.178.80: Bytes=32 Zeit=2ms TTL=255 Antwort von 192.168.178.80: Bytes=32 Zeit=1ms TTL=255 Antwort von 192.168.178.80: Bytes=32 Zeit=2ms TTL=255

Ping-Statistik für 192.168.178.80: Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust), Ca. Zeitangaben in Millisek.: Minimum = 1ms, Maximum = 2ms, Mittelwert = 1ms

mhm, Wolfgang

arendst commented 3 years ago

FWIW:

PS C:\WINDOWS\system32> ping pow3 -n 10

Pinging pow3 [192.168.2.194] with 32 bytes of data:
Reply from 192.168.2.194: bytes=32 time=295ms TTL=255
Reply from 192.168.2.194: bytes=32 time=175ms TTL=255
Reply from 192.168.2.194: bytes=32 time=86ms TTL=255
Reply from 192.168.2.194: bytes=32 time=309ms TTL=255
Reply from 192.168.2.194: bytes=32 time=2ms TTL=255
Reply from 192.168.2.194: bytes=32 time=2ms TTL=255
Reply from 192.168.2.194: bytes=32 time=2ms TTL=255
Reply from 192.168.2.194: bytes=32 time=1ms TTL=255
Reply from 192.168.2.194: bytes=32 time=2ms TTL=255
Reply from 192.168.2.194: bytes=32 time=2ms TTL=255

Ping statistics for 192.168.2.194:
    Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 1ms, Maximum = 309ms, Average = 87ms
s-hadinger commented 3 years ago

Interesting. I'm seeing the same behavior.

First 3 or 4 packets are very slow then single digit ms. 

PING 192.168.2.201 (192.168.2.201): 56 data bytes
64 bytes from 192.168.2.201: icmp_seq=0 ttl=254 time=250.548 ms
64 bytes from 192.168.2.201: icmp_seq=1 ttl=254 time=168.080 ms
Request timeout for icmp_seq 2
64 bytes from 192.168.2.201: icmp_seq=3 ttl=254 time=4.866 ms
64 bytes from 192.168.2.201: icmp_seq=4 ttl=254 time=3.101 ms
64 bytes from 192.168.2.201: icmp_seq=5 ttl=254 time=2.551 ms
64 bytes from 192.168.2.201: icmp_seq=6 ttl=254 time=3.537 ms
64 bytes from 192.168.2.201: icmp_seq=7 ttl=254 time=3.844 ms

And it goes high again if I wait ~5 seconds until the next ping command

ascillato commented 3 years ago

First 3 or 4 packets are very slow then single digit ms.

That is just because of the energy saving feature of sleep. If you have sleep 50, Tasmota uses very little energy and it is very responsive. If you use sleep 0, Tasmota will give you small ping time also in the firsts attempts, but it uses a lot more energy.

The dynamic sleep feature is in Tasmota only.

arendst commented 3 years ago

Agree with @ascillato. Tasmota lowest sleep mode is still WIFI_MODEM_SLEEP. Espurna's default sleep mode is WIFI_NONE_SLEEP (source: Espurna general.h)

#ifndef WIFI_SLEEP_MODE
#define WIFI_SLEEP_MODE             WIFI_NONE_SLEEP        // WIFI_NONE_SLEEP, WIFI_LIGHT_SLEEP or WIFI_MODEM_SLEEP
#endif

For a test I changed tasmota's WIFI_MODEM_SLEEP to WIFI_NONE_SLEEP too and receive this:

PS C:\WINDOWS\system32> ping wemos4 -n 10

Pinging wemos4 [192.168.2.226] with 32 bytes of data:
Reply from 192.168.2.226: bytes=32 time=2ms TTL=255
Reply from 192.168.2.226: bytes=32 time=2ms TTL=255
Reply from 192.168.2.226: bytes=32 time=2ms TTL=255
Reply from 192.168.2.226: bytes=32 time=12ms TTL=255
Reply from 192.168.2.226: bytes=32 time=4ms TTL=255
Reply from 192.168.2.226: bytes=32 time=2ms TTL=255
Reply from 192.168.2.226: bytes=32 time=2ms TTL=255
Reply from 192.168.2.226: bytes=32 time=2ms TTL=255
Reply from 192.168.2.226: bytes=32 time=2ms TTL=255
Reply from 192.168.2.226: bytes=32 time=3ms TTL=255

Ping statistics for 192.168.2.226:
    Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 2ms, Maximum = 12ms, Average = 3ms

So concluding, the initial Tasmota connection will be slow to enable wifi modem startup. This is true for sleep 0. With sleep >0 it will be set to WIFI_LIGHT_SLEEP.

arendst commented 3 years ago

Try latest development with commands sleep 0 and so60 0. This will set the wifi modem sleep to NONE and should respond to your pings immediatly (like espurna does).

s-hadinger commented 3 years ago

I confirm setting Sleep 0 removes the hickup.

Do you have any clue why with Sleep 50 the wifi stabilizes to low latency after 2-5 seconds?

wchulze commented 3 years ago

I installed the version. After sleep 0 no more access possible, so60 was 0. I had to flash the previous version 9.2.0.3 again -> Tasmota-PyFlasher-1.0 with clear.

Sleep 0 doesn't work there either, strange.

Wolfgang

s-hadinger commented 3 years ago

Device not responding with Sleep 0 is often a sign that the power supply is not strong enough.

wchulze commented 3 years ago

Which one, the Sonoff-Basic???

Wolfgang

funnyfrish commented 3 years ago

disable mqtt and try it again with alexa.

Wolfgang Schulze notifications@github.com schrieb am Mi., 13. Jan. 2021, 21:37:

Which one, the Sonoff-Basic???

Wolfgang

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/arendst/Tasmota/issues/10430#issuecomment-759724580, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAXWP625SBGAZT5HPVIYC73SZYAAZANCNFSM4VXVHTGQ .

ascillato commented 3 years ago

Do you have any clue why with Sleep 50 the wifi stabilizes to low latency after 2-5 seconds?

Yes, that is because of the dynamic sleep. You can use dynamic (default) or static sleep. In the dynamic sleep, Tasmota can reduce the sleep time if the cpu usage got incremented, and after that, it can go to 50ms again. So, if you start using Tasmota (pinging or performing any task) Tasmota can reduce its sleep time to increase performance, and after it returns to idle state, will go back to the set sleep time. (@andrethomas great idea)

ascillato commented 3 years ago

Which one, the Sonoff-Basic???

Sonoff basics are known to have a very weak power supply. But if sleep 0 makes your device unusable, it has a big issue. How did you flash your device? Did you set flashing as DOUT? Can you try Tasmotizer?

ascillato commented 3 years ago

@funnyfrish

disable mqtt and try it again with alexa.

From the data shared on the first comment, mqtt is already disabled.