Closed Fettkeewl closed 4 years ago
Good idea. :+1: Please, help us and go to www.tasmota.com and click on IMPROVE THIS ARTICLE and add that info where you think is going to be easily found. Thanks.
Band steering is a new feature of some new routers. As soon as that feature was shipped, some networking magazines talked about this and that problem. Some devices are being sent to 5Ghz and they are not capable of that connection. Is not a problem of the ESP8266. It is just that config on the router. The router manual said to disable that feature if you have devices that are only 2.4GHz. AFAIK, it is recommended to have 2.4GHz and 5GHz as separated networks with different SSID as to avoid this type of issues.
I thought about this issue as first attempt to solve the problem but it did not work for me. I upgraded to 8.2 and the issue is not anymore there ... I do not know if this will help also you but I guess there is a "bad" combination between ESP8266 and Asus routers .
I have the same problem (asus rt-ac86u) with the 8.20 firmware, band steering is disabled, now trying the asus settings as recommended by Jagohu
In the Tasmota there is room for two SSID with passowrd. Try to use both with the same SSID and password... it helps and for me this combination with 8.20 works very well.
Sorry for post on Closed issue, but this may help others with keeping most settings as is
Been having the same issue for ages
Previously I had set Wireless Mode to Legacy to get it working
Used screenshot from @Jagohu (thank you) I believe changing the below fixed it for me (early testing stages - but looking good):
Also have set Wireless Mode back to Auto.
FYI: I actually just had a look at the User Manual for the above settings and kind of makes sense that these may play a role here
I will try the RTS and Beacon interval also, it took me 2 days to figure out what the problem was, I flashed the wifi unit 40 times and everytime after the flash the unit was accessible. So I thought it was related to the wifi unit. I use the wifi unit with a rs485 to ttl converter, the wifi unit can't be flashed with the converter attached to it, so every time I had to desolder the rs485 converter :) It would be nice if there was a warning that Tasmota doesn't work well with Asus routers that should have saved me alot of time...
Hi,
I'm using ASUS RT-AX88U and have the same issue... I tried everything mentioned here and still nothing... Someone was able to fix that "connecting loop"?
As I said in some previous posts, with my ASUS RT-86U everything has been solved with the followings:
I have now 4 SonOff connected to the router and they are stable and working since months without any problem of connection (my router is with standardd wifi settings with steering enabled .
Hi,
I am having the same issue with my Tasmota devices. They are flashed to 8.3.1.
I have disabled band steering on my router. Changing to seperate 2.4 and 5Ghz frequencies seemed to help (instead of being blocked after Tasmota reboot, it is stable for a couple of days now).
That said, eventually the Tasmota devices drop their Wi-Fi connection (usually after a day or two) and fail to reconnect. The only remedy is to reboot the router.
Following are my router details:
The Asus specific configuration changes recommended in this thread appear unavailable in my router's configuration page.
As others have indicated, the Tasmota devices are the ONLY devices on my network that experience this problem. All other devices do not have trouble connecting or reconnecting. I struggle to understand why many of the responses blame the router when other clients connected do not have the same problem.
Any help would be greatly appreciated.
At least you are confirming thatthe issue is not only ASUS related .... Do you have any wifi extender or mesh ? If yes try to temporarly switch off them and see what happens. In my case I needed to block MAC Address to WiFi extender.
Also try to define a fixed IP on your Tasmota and fill both SSID with the same user and password.
Unlikely this issue has not a final solution for who is affected.
Right now I have 4 Tasmota devices well working and stable but I do not know what did the diffenece and apparently I just flashed 8.1 to solve the issue. I am afraid to change anything that is working :)
@miazza99, thanks for the suggestions. I do not have a mesh WIFI network or extender.
I defined a fixed IP for my Tasmota devices and filled in the SSID for both Network ID's on the WIFI configuration page. Unfortunately it did not help with the devices dropping the connection. Same behavior as before, after about a day, they could not reconnect until the router rebooted.
Do I understand correctly that downgrading to 8.1 stopped your Tasmota devices from dropping/being kicked from the network?
Well, at the end, further to what I suggested before, what did the difference for me has been the following:
Hi all and excuse me in advance if my comment may seem foolish, but I can't fully understand all the matter written in this post. I'm having this behaviour when I issue the command AP 0: In tasmota 8.1.0 all ok, my sonoff switches betwwen routers flawessly. In tasmota 8.3.1 the switchover never occurs and the very first rows of console are:
00:00:00 CFG: Loaded from flash at F9, Count 38 00:00:00 Project tasmota Nordmende Version 8.3.1(tasmota)-2_7_1 00:00:00 WIF: Connecting to AP1 Haircare Channel 4 BSSId 20:B0:01:B2:A3:2F in mode 11N as Nordmende-1066... 00:00:09 WIF: Connect failed as AP cannot be reached
Reverting to 8.1.0 all returns ok; note that I wipe memory and load via Tasmotizer. What make me curiouse is that 'Haircare Channel 4' could be wrong: infact my Haircare router in fixed on channel 6. On the other way channel 4 is the channel of the other router. It is possible tasmota 8.3.1 looks for the wrong channel?
Not sure why this was closed because it's definitely still an issue. With stock firmware I didn't have any problems with my plugs / dimmers connecting to the Asus RT-AC86U. With Tasmota 8.3.1 and even 8.4.0 they generate:
Jul 5 16:25:03 wlceventd: WLCEVENTD wlceventd_proc_event(466): eth5: Deauth_ind 24:62:AB:2E:03:59, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
.. and will never connect. I have a Unifi Dream Machine and a NanoHD and these don't have the issue. It's specific to Asus.
I have Sonoff devices with the standard firmware on them and am having the same issue with my Asus mesh routers RT-AC88U & RT-AC68U.
Just found this issue register!, It should %100 be open. I have been messing around with my devices for a while now trying to find out what is happening. Any devices connected to my Mesh device die and go into boot loop. I can't remove my Mesh as the devices are not strong enough to connect to my primary and I have several other devices connected without issue.
Looking for people smarter than me to find a resolution and make several people on this forum happy people :)
Thanks, Following!
Phil
It IS a Asus problem. Using this firmware solves the problem. https://sourceforge.net/projects/asuswrt-merlin/files/RT-AX58U/Release/RT-AX58U_384.17_0.zip/download https://sourceforge.net/projects/asuswrt-merlin/files/
I'm already on the latest and greatest Merlin FW. I know it's an Asus issue, I'm simply stating that the stock firmware doesn't have the issue. There's something different about running Tasmota that causes this to happen.
Maybe, and it cant be solved. Sorry, it is NOT under control of Tasmota. Tasmota only uses Aduino ESP8266 which use the APIs from Espresiff nonos-sdk (closed source). If you want to use Tasmota avoid Asus.
I can work around it, I have a Unifi Dream Machine and a NanoHD. At this point I just use the Asus as an extra AP to extend reach to some tough areas outside. At some point I should just add another NanoHD and be done with it.
What I did is I split the 2.4 band into 3 separate SSID's so I can control who connects to what. 5G is still all on the same single name so phones can roam.
I don't know if I can be of any help on this but :
In the past I had issues like the ones mentioned in this ticket but since I updated to Tasmota 8.2 problems have disappeared. I tried to come back to 8.1 and all of them were still stable also after power cycling so I do not think it is an issue related to Tasmota FW. Also the Merlin FW is not responsible of this becasue I did not change anything in the settings.
The main trick I did has been a full flash wipe of all the Sonoff and reinstalled fresh FW with Tasmotizer.
If you like I can post my WiFi settings and plese feel free to ask anything you might need but at the end I do not think it is a router issue.
I've been experimenting a bit more with this. In my case the issue is specific to the Asus RT-AC86U. I have an older RT-AC68U and it doesn't have the problem (both on Merlin). It seems to only be a problem when SWITCHING either to or from the 86U and another AP. Once you're on the 86U it will usually stay connected. In some cases if I was trying to get a device to connect to the 86U, I would have to power cycle the AP it was previously connected to so it would "let go" of the old and join the 86U.
I'm already on the latest and greatest Merlin FW. I know it's an Asus issue, I'm simply stating that the stock firmware doesn't have the issue. There's something different about running Tasmota that causes this to happen.
My Asus RT-AC88u is on stock firmware and still I have this issue with several tasmota devices. The same devices have no problem connecting when running the original ewelink software. Also gwrichard reported the same problem on a Technicolor router, so it seems to be Tasmota related, not Asus or ESP hardware.
Again, no possibility to change the behaviour because it is NOT under control from Tasmota. https://github.com/arendst/Tasmota/issues/7770#issuecomment-654360964 ewelink software do not use Arduino Esp8266 nor nonos-sdk.
I've noticed over the years of owning Tuya / ESP devices they've pushed wi-fi firmware updates a few times. They probably patched this issue, but it's not fixed in the built-in driver that Tasmota is built with.
Tasmota uses latest actual Arduino Esp8266 (v.2.7.2) Tuya is NOT based on Arduino Esp8266. Fixing the issue is not possible since the necessary sources (nonos-sdk) are closed source from Espressif. And nonos-sdk is EoL.
I have the same issue since today with my Unifi access points running firmware 4.3.20.11298 and Tasmota 8.3.1 on some tuya devices, They all show up with their own Wifi SSID suddenly.
I have the same issue since today with my Unifi access points running firmware 4.3.20.11298 and Tasmota 8.3.1 on some tuya devices, They all show up with their own Wifi SSID suddenly.
One thing worth trying is split your 2.4 GHz network if you have more than one AP. I had multiple AP's advertising the same SSID for roaming and the crappy driver in the ESP doesn't handle that well. I believe Tuya etc. have patched this issue but using Tasmota means we don't have access to those fixes.
@Scope666 No using mixed 2.4 and 5 Ghz with the same SSID is no problem. I use this setup for Tasmota since v.5.x
@Scope666 No using mixed 2.4 and 5 Ghz with the same SSID is no problem. I use this setup for Tasmota since v.5.x
You're lucky then. I had problems where a Tasmota device would "latch on" to the wrong, weaker AP and I couldn't get it to connect to the stronger one until I power cycled the weaker AP. Giving the 2.4 GHz AP's unique SSID's helped this issue for me. This issue is very router dependent. I have the most problems with the Asus 86U, less but still some with 68U, and hardly any with Ubiquiti gear.
@Scope666
The ESP82xx only supports 2.4GHz. They cannot see any 5GHz AP. My experience is the same as @Jason2866. I have two "points" in my home which broadcast the same SSID for everything (2.4 & 5). On the 2.4GHz side, they do each auto-select different channels from each other which is necessary to avoid contention. It's all worked without issue since I first started using Tasmota back at 6.0.x. I would say the majority of Tasmota users are in this camp. Thus you have something happening on your network that is at the root of your issues. Some networking gear (e.g., Asus) is known to have issue with Tasmota and those are sometimes addressed through changing the AP network configuration... or avoiding those vendors.
I know this. I'm not trying to advertise 2.4 and 5 GHz with the same SSID, I've always kept them separate.
This issue mostly affects Asus users although I believe others in this thread have had the problem with non-Asus devices. My point is that this was patched in the official Tuya / Smart Life firmware as I NEVER had this problem until switching to Tasmota. I understand it can't be fixed because the driver code is "locked"
My main setup is a Unifi Dream Machine and a NanoHD. I use the Asus devices as extra APs for extra reach, as I have some devices that have a weak signal if I only use the Ubiquiti gear.
I am having A Unifi USG. TIll I rebooted the USG yesterday I had no problem. Then suddenly all the Tasmota (formerly Tuya, changed to tasmota with toya-convert) devices showed up with their own Wifi. When I access this Wifi, the Wifi configuration shows up. However, ehen I search for the SSID suddenly the device doesn`t even see my SSID anymore. It just sees the SSIDs from all other Tasmota deices. Following your suggestions I have quickly created an additional WLAN SSID with only 2,4 Ghz enabled. However this didn't show up either. The only thins that helped was completely resettig the device to factory defaults, then joining it again. It can the also rejoin my SSID that has 2,4 Ghz & 5 Ghz, like before. However prowering of the device and bringing it back on, results again in the device not joining the Wifi anymore.
I have 86U with mixed 2.4 and 5Ghz with the same SSID and SONOFF Tasmotized devices are now well behaving. I have had the same issue in the past and I really do not know what I have chnaged in the settings but now I have 4 devices always reliably well connected since months. Only thing I did, I banned their MAC from the wifi extender who has same SSID of ASUS 2.4 and 5Ghz.
I have 86U (not used as an extender) and I can confirm banning the MAC addresses from 5Ghz was the solution that worked for me as well.
On Sun, 19 Jul 2020 at 11:10, miazza99 notifications@github.com wrote:
I have 86U with mixed 1.4 and 5Ghz with the same SSID and SONOFF Tasmotized devices are now well behaving. I have had the same issue in the past and I really do not know what I have chnaged in the settings but now I have 4 devices always reliably well connected since months. Only thing I did, I banned their MAC from the wifi extender who has same SSID of ASUS 2.4 and 5Ghz.
— 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/7770#issuecomment-660685291, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAZJ6BPMO5KNAV4T35FAETR4MZIJANCNFSM4KZPF62A .
banning the MAC addresses from 5Ghz
That is just too strange. Wow!
I have 86U (not used as an extender) and I can confirm banning the MAC addresses from 5Ghz was the solution that worked for me as well. … On Sun, 19 Jul 2020 at 11:10, miazza99 @.***> wrote: I have 86U with mixed 2.4 and 5Ghz with the same SSID and SONOFF Tasmotized devices are now well behaving. I have had the same issue in the past and I really do not know what I have chnaged in the settings but now I have 4 devices always reliably well connected since months. Only thing I did, I banned their MAC from the wifi extender who has same SSID of ASUS 2.4 and 5Ghz.
Made some more progress today. Starting to think DHCP might be the issue. I upgraded my UDM today to the 6.0.4 release, and set my biggest problem outdoor switches to static IP, GW, Mask and DNS within Tasmota, and they are connecting now. I'm wondering if DNS requests coming from Tasmota and hitting my Adguard Home DNS server might be involved. Since I set them to static I pointed them at the gateway directly for DNS instead of the Adguard box.
Guys, I was having the same problem on 5 tasmota devices. I had to reboot my router (ASUS) to get them connected again, I tried all the suggestion mentioned: downgrade tasmota version, tuning asus parameters and nothing helped. I am manually assigning the IP addresses of those devices (this made no difference), but then I decided to disable DHCP option on each device, and assigned its specific address using:
IPAddress1 = set device IP address
restart 1
This fixed the problem for me!, I am even using beam-forming and advanced options under my 2.4Ghz without any problems.
regards
That's what I did in the post right before yours, except I went ahead and did the mask, gw and DNS just to be safe. They've been much more stable since I made the change. I have DHCP reservations in place that match what I've set statically.
Guys, I was having the same problem on 5 tasmota devices. I had to reboot my router (ASUS) to get them connected again, I tried all the suggestion mentioned: downgrade tasmota version, tuning asus parameters and nothing helped. I am manually assigning the IP addresses of those devices (this made no difference), but then I decided to disable DHCP option on each device, and assigned its specific address using:
IPAddress1 = set device IP address
restart 1
This fixed the problem for me!, I am even using beam-forming and advanced options under my 2.4Ghz without any problems.
regards
I have done the same on my Tasmota devices . I don't know it this is what made the trick but finally they are all stable.
So that's 3 of us that have confirmed the fix. DHCP is not working correctly with Asus, and possibly other routers. Setting everything statically in Tasmota seems to fix the issue.
I also have the same problem, one of my tasmota devices keeps dropping off the network. If I do a wireshark capture it is continuously sending DHCP Discover packets but ignoring the offer. This is on a Unifi AP.
I would recommend setting the IP, subnet mask, gateway and DNS addresses statically. Since I did this I haven't had any more problems. I have static reservations in the router matching what I'm setting statically so I never get conflicts.
I would recommend setting the IP, subnet mask, gateway and DNS addresses statically. Since I did this I haven't had any more problems. I have static reservations in the router matching what I'm setting statically so I never get conflicts.
Thanks will have a go at this, bit of a pain as the device is not in a very accessible location.
You do not need to access the device. Once the device is connected you can du it from the consol.
Adding some anecdotal information, hoping it helps someone. I got here by a Google search for the 'connect failed...' error message. I have been using a LinkNodeR4 and Tasmota 8.5.1. My WiFi router is a D-Link DIR-822 with both 2.4 & 5 GHz WiFi's enabled, and it is configured in Access Point mode, with a Linux hosted DHCP server. Initially, I was unable to see any traffic reaching the DHCP server (by monitoring the syslog messages from the DHCP server), so I knew the problem wasn't DHCP related. I used the serial terminal to set my WiFi SSIDs and passwords (took a bit of fiddling to realize that there's no echo, and the EOL is Ctl-M Ctl-J). While I was reading through this thread, 7 minutes and 23 seconds later tasmota reported that it had succeeded in making an AP connection, and that it had acquired an IP, which corresponded to the DHCP configuration file (I key all IPs to MACs in the DHCP server). My WiFi AP is about 50 cm from the ESP8266.
By the time I tried to connect a browser to the reported IP address, it seemed to have become unavailable again... :( This is my first foray into Tasmota-land, so I'm probably doing some things wrong. I will repeat the process and see how repeatable the problem is.
00:07:00 WIF: Connecting to AP2 XXXXXXX50 in mode 11N as tasmota_06E911-2321...
00:07:07 WIF: Connect failed with AP timeout
00:07:07 WIF: Connecting to AP1 YYYYYYYY24 in mode 11N as tasmota_06E911-2321...
00:07:14 WIF: Connect failed with AP timeout
00:07:15 WIF: Connecting to AP1 YYYYYYYY24 in mode 11N as tasmota_06E911-2321...
00:07:22 WIF: Connected
00:07:22 HTP: Web server active on tasmota_06E911-2321 with IP address 192.168.0.31
00:07:23 RSL: tele/tasmota_06E911/INFO1 = {"Module":"Sonoff Basic","Version":"8.5.1(tasmota)","FallbackTopic":"cmnd/DVES_06E911_fb/","GroupTopic":"cmnd/tasmotas/"}
00:07:23 RSL: tele/tasmota_06E911/INFO2 = {"WebServerMode":"Admin","Hostname":"tasmota_06E911-2321","IPAddress":"192.168.0.31"}
00:07:23 RSL: tele/tasmota_06E911/INFO3 = {"RestartReason":"Software/System restart"}
00:07:23 RSL: stat/tasmota_06E911/RESULT = {"POWER":"OFF"}
00:07:23 RSL: stat/tasmota_06E911/POWER = OFF
00:07:28 RSL: tele/tasmota_06E911/STATE = {"Time":"1970-01-01T00:07:28","Uptime":"0T00:07:40","UptimeSec":460,"Heap":28,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":0,"POWER":"OFF","Wifi":{"AP":1,"SSId":"YYYYYY24","BSSId":"A0:AB:1B:88:39:30","Channel":9,"RSSI":100,"Signal":-37,"LinkCount":1,"Downtime":"0T00:07:33"}}
21:03:23 APP: Serial logging disabled
I experienced the same issue with a mesh setup, Asus RT-AX88U with Merlin 384.19 as main node and 3 Lyra nodes with latest standard firmware. I run Tasmota on Sonoff Basic. The problem only occurs when Tasmota devices are trying to connect to the main AX88U node. All works well when they have a Lyra node nearby, they connect immediately. I have initially solved the problem by downgrading to Sonoff Tasmota 6.2.1. Went well for a while then experienced issues after few power outages. The error was mainly getting incorrect AP password (password was correct!) and after a while eventually some devices would randomly connect.
I am trying the fixed IP workaround, seems to be working for now, will report back when it does not. Thanks all for the suggestions.
I am trying hard to accept that this is not a Tasmota issue but I wonder how other wifi clients managed to solve the problem as I only have the issue with Tasmota devices.
I am trying hard to accept that this is not a Tasmota issue but I wonder how other wifi clients managed to solve the problem as I only have the issue with Tasmota devices.
For me it's not only tasmota. I have some other esp modules, and not all worked correctly. I'm using fixed IP since few mounts and all is working perfectly.
It could be several different problems at the same time. I replaced my Asus network with Unifi. The Tasmota devices stopped giving me problems, but my Shelly devices with Shelly firmware had the same problem of dropout without reconnecting. Fortunately, Shelly updated their firmware and fixed their problem. I much prefer working with recent Shelly firmware over Tasmota.
I am trying hard to accept that this is not a Tasmota issue but I wonder how other wifi clients managed to solve the problem as I only have the issue with Tasmota devices.
For me it's not only tasmota. I have some other esp modules, and not all worked correctly. I'm using fixed IP since few mounts and all is working perfectly.
This is what solved it for me too... with both Ubiquiti and Asus equipment.
Another suggestion that i can give is to filter the MAC on the 5GHz network. I know it's a nonsense because ESP8266 has only the 2.4 Gz but on ly ASUS Merlin RT86U this trick , together with the fixed IP, works.
PROBLEM DESCRIPTION
Sonoff devices with Tasmota firmware refuse to reconnect after power cycling them. As evident by serial output the devices just says "fails to connect to AP". The only remedy is to reboot router, then all my tasmota devices that are stuck in a loop will connect instantly.
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
:Rules output here:
STATUS 0 output here: 07:56:15 MQT: OfficeCeilingLamp/stat/STATUS = {"Status":{"Module":0,"FriendlyName":["SonoffT1-01"],"Topic":"OfficeCeilingLamp","ButtonTopic":"0","Power":1,"PowerOnState":3,"LedState":1,"LedMask":"FFFF","SaveData":1,"SaveState":0,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":0}} 07:56:15 MQT: OfficeCeilingLamp/stat/STATUS1 = {"StatusPRM":{"Baudrate":115200,"GroupTopic":"tasmotas","OtaUrl":"http://thehackbox.org/tasmota/release/tasmota.bin","RestartReason":"Software/System restart","Uptime":"7T00:51:52","StartupUTC":"2020-02-15T06:04:23","Sleep":50,"CfgHolder":4617,"BootCount":10,"SaveCount":169,"SaveAddress":"FB000"}} 07:56:15 MQT: OfficeCeilingLamp/stat/STATUS2 = {"StatusFWR":{"Version":"8.1.0(tasmota)","BuildDateTime":"2019-12-25T12:33:25","Boot":31,"Core":"2_61","SDK":"2.2.2-dev(38a443e)","Hardware":"ESP8285","CR":"364/699"}} 07:56:15 MQT: OfficeCeilingLamp/stat/STATUS3 = {"StatusLOG":{"SerialLog":2,"WebLog":2,"MqttLog":0,"SysLog":0,"LogHost":"","LogPort":514,"SSId":["",""],"TelePeriod":300,"Resolution":"558180C0","SetOption":["000A8008","2805C8000100060000005A00000000000000","00000200","00000000"]}}
07:56:15 MQT: OfficeCeilingLamp/stat/STATUS4 = {"StatusMEM":{"ProgramSize":566,"Free":436,"Heap":24,"ProgramFlashSize":1024,"FlashSize":1024,"FlashChipId":"144051","FlashMode":3,"Features":["00000809","8FDAE397","043683A0","22B617CD","01001BC0","00007881"],"Drivers":"1,2,3,4,5,6,7,8,9,10,12,16,18,19,20,21,22,24,26,29","Sensors":"1,2,3,4,5,6,7,8,9,10,14,15,17,18,20,22,26,34"}}
07:56:15 MQT: OfficeCeilingLamp/stat/STATUS5 = {"StatusNET":{"Hostname":"SonoffT1-01","IPAddress":"","Gateway":"","Subnetmask":"255.255.255.0","DNSServer":"","Mac":"","Webserver":2,"WifiConfig":4}}
07:56:15 MQT: OfficeCeilingLamp/stat/STATUS6 = {"StatusMQT":{"MqttHost":"","MqttPort":,"MqttClientMask":"DVES %06X","MqttClient":"DVES_BDA845","MqttUser":"","MqttCount":7,"MAX_PACKET_SIZE":1000,"KEEPALIVE":30}}
07:56:15 MQT: OfficeCeilingLamp/stat/STATUS7 = {"StatusTIM":{"UTC":"Sat Feb 22 06:56:15 2020","Local":"Sat Feb 22 07:56:15 2020","StartDST":"Sun Mar 29 02:00:00 2020","EndDST":"Sun Oct 25 03:00:00 2020","Timezone":"+01:00","Sunrise":"07:46","Sunset":"18:21"}}
07:56:15 MQT: OfficeCeilingLamp/stat/STATUS10 = {"StatusSNS":{"Time":"2020-02-22T07:56:15"}}
07:56:15 MQT: OfficeCeilingLamp/stat/STATUS11 = {"StatusSTS":{"Time":"2020-02-22T07:56:15","Uptime":"7T00:51:52","UptimeSec":607912,"Heap":23,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":7,"POWER":"ON","Wifi":{"AP":1,"SSId":"","BSSId":"","Channel":11,"RSSI":48,"Signal":-76,"LinkCount":6,"Downtime":"0T05:33:55"}}}
Console output here: