Closed Sonusss closed 5 years ago
this is a new one. Can you help me recreate it?
Yes for all... I also changed for another board and same result Board model is Wemos D1 mini V3.0.0 with 4MB flash I cannot change to another type as I have only this model
I'm not sure what the actual problem is how to reproduce the problem. When in AP mode the IP is fixed to 192.168.4.1. Did you upload the firmware yourself? Did you configure it to use your own wifi network?
@Sonusss so you are in zwo WLAN simultaneously? 🧐 What are the Network Settings of your workstation? Especially the subnet mask ?
Yes I flashed the firmware myself. Wifi settings were made with telnet. My home Wifi is using 192.168.1.0/24 subnet My computer was connected with copper to my router with 192.168.1.25/24 and to ems-esp AP with the Wifi interface. As you can see from netmask there is no way to pass through the router as ems-esp is in 192.168.4.0/24 subnet
So if I understand correctly, you wiped the ESP (like pio run -t erase), flashed it, it boots into AP mode. You join the wifi ssid ems-esp and use telnet to set the wifi_ssid and wifi_password. reboot. Then you telnet to the new IP assigned by your router's DHCP, it logs you out and the device goes back into AP mode?
Yes I done it like that, however the simultaneous Wifi and AP modes didn't appears directly, I don' know exactly when but connecting a new device to my Wifi I discovered that thers was an ems-esp AP available. I then connected to it and telnet, was working but I still could ping ems-esp on my Wifi (192.168.1.79), tried to telnet > connection refused I closed the telnet terminal on ems-esp AP keeping this Wifi (192.168.4.x) active and could then telnet to 192.168.1.79. As I wrote both ethernet interfaces on my computer have /24 netmask. I'm trying now to reproduce the situation having USB serial connected to in order to trace maybe some important messages from the Wemos but it is running as expected for 12 hours now but without EMS bus connection, will continue testing and let you know
Something else... I remember that when this simultaneous Wifi and AP modes was active the Wemos LED was on steady while actually it's blinking. (I don't know LED status codes)
I am seeing the same behavior here, but not only on the EMS-ESP device, also on other ESP8266 devices I am using. Though I cannot connect to the devices, even when they appear as an AP. The ems-esp is the only one I have build based on the Arduino SDK, the others are using the (native) 8266NON-OS sdk. Not all of them are WEMOS D1 boards, but all of them are based on the ESP12 boards. Might be an 8266 bug?
Op vr 19 jul. 2019 om 09:19 schreef Sonusss notifications@github.com:
Something else... I remember that when this simultaneous Wifi and AP modes was active the Wemos LED was on steady while actually it's blinking. (I don't know LED status codes)
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/proddy/EMS-ESP/issues/152?email_source=notifications&email_token=AIQ7TGBJ6MO5MWFG5BTCKPLQAFTILA5CNFSM4IETX3QKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2KZ5EA#issuecomment-513121936, or mute the thread https://github.com/notifications/unsubscribe-auth/AIQ7TGDBC7ZGIFKF7TAXBMDQAFTILANCNFSM4IETX3QA .
Well, I'm glad not being the only one... But it looks strange as this is not reported on a larger scale like as soon the AP mode is enable ems-esp enable serial and then EMS bus is disconnected which is quite remarquable. @proddy: I found this ... The ESP8266 is also able to operate both in station and soft access point mode at the same time. https://42bots.com/tutorials/esp8266-wifi-tutorial-arduino-ide/
I looked into the code and can't immediately see how this is happening. I'd love to be able to recreate the scenario at home so I can debug, but still not sure how to reproduce?
The kit was on my desk for hours with serial terminal, telnet bot no EMS bus.... I placed it back on the bus in the garage, will see.... It might be related to the way you manage EMS serial com. One question, if ems-esp receives unknown telegram from EMS bus won't this creates problems with your code. I have two devices on the bus: Buderus GB172/Nefit Trendline/Junkers Cerapur (ProductID:123 Version:06.08) TC100/Nefit Easy (ProductID:202 Version:02.19)
First clue ems-esp reboots quite frequently when connected on EMS bus. Longest uptime I can get is about 15 mins Crash dump: No data captured Last reset reason: Software Watchdog Last reset info: Fatal exception:4 flag:3 (SOFT_WDT)
Complete system output: [APP] EMS-ESP version: 1.8.0 [APP] MyESP version: 1.1.16 [APP] Build timestamp: 2019-06-15 15:47:29 [APP] Boot time: start [APP] Uptime: 0 days 0 hours 12 minutes 29 seconds [APP] System Load: 1% [WIFI] WiFi Hostname: ems-esp [WIFI] WiFi IP: 192.168.1.79 [WIFI] WiFi signal strength: 100% [WIFI] WiFi MAC: DC:4F:22:65:FE:DB [EEPROM] EEPROM size: 4096 [EEPROM] EEPROM Sector pool size is 4, and in use are: 1019 1018 1017 1016 [SYSTEM] Board: PLATFORMIO_D1_MINI [SYSTEM] CPU frequency: 80 MHz [SYSTEM] SDK version: 2.2.1(cfd48f3) [SYSTEM] CPU chip ID: 0x65FEDB [SYSTEM] Core version: 2_5_2 [SYSTEM] Boot version: 31 [SYSTEM] Boot mode: 1 [SYSTEM] Last reset reason: Software Watchdog [SYSTEM] Last reset info: Fatal exception:4 flag:3 (SOFT_WDT) epc1:0x40002eee epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000 depc:0x00000000 [SYSTEM] Restart count: 0 [SYSTEM] rtcmem status:1 blocks:3 addr:0x60001280 [SYSTEM] rtcmem 00: 1163087989 [SYSTEM] rtcmem 01: 0 [SYSTEM] rtcmem 02: 0 [FLASH] Flash chip ID: 0x1640EF [FLASH] Flash speed: 40000000 Hz [FLASH] Flash mode: DIO [FLASH] Flash size (CHIP): 4194304 [FLASH] Flash size (SDK): 4194304 [FLASH] Flash Reserved: 4096 [MEM] Firmware size: 441296 [MEM] Max OTA size: 2699264 [MEM] OTA Reserved: 16384 [MEM] Free Heap: 27248 bytes initially | 12096 bytes used (44%) | 15152 bytes free (55%)
Stay tuned - a revamped "tx_mode 2" pull request is in the queue.. Found a bunch of reasons for WTD timeout and other issues...
ESP8266 System stats:
[APP] EMS-ESP version: 1.8.1b18 [APP] MyESP version: 1.1.22 [APP] Build timestamp: 2019-07-19 13:00:59 [APP] Uptime: 0 days 2 hours 26 minutes 3 seconds [APP] System Load: 1% ... And the Rx busy test also works:
Publishing hot water and heating states via MQTT
** We missed the bus - Rx non-idle!
Please commit the code I'm impatient to test !
You can fetch the brkdetect branch from https://github.com/susisstrolch/EMS-ESP.git
Sent by mobile device
Am 19.07.2019 um 15:50 schrieb Sonusss notifications@github.com:
Please commit the code I'm impatient to test !
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
Compilation fails for me, can you upload .bin ?
It's already merged into 1.8.1 beta 21. You can grab the beta bins from https://github.com/proddy/EMS-ESP/releases/tag/1.8.1-beta
Hi I checked with 1.8.1b21 (your bin) and same situation... Both Client and AP mode simultaneously after some reboot
[SYSTEM] Last reset reason: Exception [SYSTEM] Last reset info: Fatal exception:0 flag:2 (EXCEPTION) epc1:0x206f7420 epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000 depc:0x00000000
ok, coming back to the the wifi issue. Are you saying when you have ssid_hostname
and ssid_password
set the EMS-ESP is connected to your wifi network and has been assigned an IP address from your router AND you still see it as an Access Point called ems-esp
?
I'm unable to reproduce this and need a set of concrete steps.
Unfortunately I don't have a setup procedure. Using ems-esp normally it goes in this mode after several reboots for Fatal Exception as reported. Having wrote code myself long time ago, I may imagine some flags or variables that are not properly resettled on reboot after a crash as this is hot reboot... I suggest to wait for the next posted beta release and I will test again.
ah, ok. I know where to look now. The logic in the code is that after 10 restarts due to crashes it goes into 'unstable' mode and forces the EMS-ESP into Access Point mode. I think the problem is there. Perhaps its also the wrong logic and we should just ignore it. I'll take it out anyway in b23
May I suggest to add in the code a crash counter instead that would be readable with "system" command
its there, called # restarts under system
Does it consider also reboot commands or just crashes ? I downgraded in the meantime to 1.8.0 because I want my outside temperature during these very hot days and it looks like "restart count" is not working. I got: [SYSTEM] Restart count: 0 [APP] Uptime: 0 days 0 hours 17 minutes 41 seconds
While it was started days ago. This demonstrate also that my ems-esp keeps on rebooting quite frequently for Fatal Exception
With 1.8.1 and specifically tx_mode of 2 you'll see a lot of restarts and we're aware and working on fixing that. tx_mode of 0 is the same logic we had in 1.8.0 and should be safe to leave EMS-ESP running for months without any restarts.
I agree the restart count code is flaky and its tricky to distinguish between a genuine crash, a manually reboot or an OTA/USB firmware upload. I'm working on improving that too in between a million other things.
Point is, it should never crash and reboot! That's the goal anyway but these little microcontrollers are fiddly little buggers. Thanks for helping in testing and providing feedback - very appreciated.
I agree with your comments. But your wonderful work and efforts is much more appreciated than my little contribution, never hesitate to request my help for testing :-)
I'm running 1.8.0 for some days now in the course to have outside temp value. It keeps on rebooting almost every 20 minutes for the same reason: SYSTEM] Last reset info: Fatal exception:4 flag:3 (SOFT_WDT) epc1:0x40002eee epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000 depc:0x00000000 But not going to simultaneous WiFi client and AP mode anymore... Showing that it looks that the logic of rebooting 10 times and forcing AP is not working either Cheer.
I removed the logic to automatically go into panic mode and switch to AP after too many reboots. What happens is that if the system has been stable for more than 1min it will set the status flag to Stable (which you can see under system
).
Anyway, it shouldn't restart in the first place! Can you confirm tx_mode is 0 and that you don't have the telnet constantly open.
Is your Gateway powered via EMS-Bus of via an external Power supply?
Von meinem iPad gesendet
Am 01.08.2019 um 23:10 schrieb Paul notifications@github.com:
I removed the logic to automatically go into panic mode and switch to AP after too many reboots. What happens is that if the system has been stable for more than 1min it will set the status flag to Stable (which you can see under system).
Anyway, it shouldn't restart in the first place! Can you confirm tx_mode is 0 and that you don't have the telnet constantly open.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
Hi, I just loaded latest release 1.8.1 and have still my outside temp. Will test and keep you posted
my board is externally powered as I didn't changed the resistors yet. Telnet is not permanently open tx_mode is 0
Seems not switching to AP mode anymore but constantly reboots about every 2 minutes... Restart count not accurate and reset to 0 sometimes without power cycle. System out: [APP] EMS-ESP version: 1.8.1 [APP] MyESP version: 1.1.24 [APP] Build timestamp: 2019-07-29 13:38:03 [APP] Boot time: start [APP] Uptime: 0 days 0 hours 0 minutes 43 seconds [APP] System Load: 0% [WIFI] WiFi Hostname: ems-esp [WIFI] WiFi IP: 192.168.1.79 [WIFI] WiFi signal strength: 66% [WIFI] WiFi MAC: DC:4F:22:65:FE:DB [MQTT] is connected (with heartbeat disabled) [SYSTEM] Board: PLATFORMIO_D1_MINI [SYSTEM] CPU frequency: 80 MHz [SYSTEM] SDK version: 2.2.1(cfd48f3) [SYSTEM] CPU chip ID: 0x65FEDB [SYSTEM] Core version: 2_5_2 [SYSTEM] Boot version: 31 [SYSTEM] Boot mode: 1 [SYSTEM] Last reset reason: Exception [SYSTEM] Last reset info: Fatal exception:3 flag:2 (EXCEPTION) epc1:0x4024a7f5 epc2:0x00000000 epc3:0x00000000 excvaddr:0x40026981 depc:0x00000000 [SYSTEM] Restart count: 1 [SYSTEM] rtcmem status: blocks:2 addr:0x60001280 [SYSTEM] rtcmem 00: 1163087990 [SYSTEM] rtcmem 01: 65537 [FLASH] Flash chip ID: 0x1640EF [FLASH] Flash speed: 40000000 Hz [FLASH] Flash mode: DIO [FLASH] Flash size (CHIP): 4194304 [FLASH] Flash size (SDK): 4194304 [FLASH] Flash Reserved: 4096 [MEM] Firmware size: 461024 [MEM] Max OTA size: 2678784 [MEM] OTA Reserved: 16384 [MEM] Free Heap: 28984 bytes initially | 7632 bytes used (26%) | 21352 bytes free (73%)
@proddy If you also upload the corresponding .elf there‘s at least a little chance to find out where the exception occures...
Sent by mobile device
Am 02.08.2019 um 13:25 schrieb Sonusss notifications@github.com:
Seems not switching to AP mode anymore but constantly reboots about every 2 minutes... Restart count not accurate and reset to 0 sometimes without power cycle. System out: [APP] EMS-ESP version: 1.8.1 [APP] MyESP version: 1.1.24 [APP] Build timestamp: 2019-07-29 13:38:03 [APP] Boot time: start [APP] Uptime: 0 days 0 hours 0 minutes 43 seconds [APP] System Load: 0% [WIFI] WiFi Hostname: ems-esp [WIFI] WiFi IP: 192.168.1.79 [WIFI] WiFi signal strength: 66% [WIFI] WiFi MAC: DC:4F:22:65:FE:DB [MQTT] is connected (with heartbeat disabled) [SYSTEM] Board: PLATFORMIO_D1_MINI [SYSTEM] CPU frequency: 80 MHz [SYSTEM] SDK version: 2.2.1(cfd48f3) [SYSTEM] CPU chip ID: 0x65FEDB [SYSTEM] Core version: 2_5_2 [SYSTEM] Boot version: 31 [SYSTEM] Boot mode: 1 [SYSTEM] Last reset reason: Exception [SYSTEM] Last reset info: Fatal exception:3 flag:2 (EXCEPTION) epc1:0x4024a7f5 epc2:0x00000000 epc3:0x00000000 excvaddr:0x40026981 depc:0x00000000 [SYSTEM] Restart count: 1 [SYSTEM] rtcmem status: blocks:2 addr:0x60001280 [SYSTEM] rtcmem 00: 1163087990 [SYSTEM] rtcmem 01: 65537 [FLASH] Flash chip ID: 0x1640EF [FLASH] Flash speed: 40000000 Hz [FLASH] Flash mode: DIO [FLASH] Flash size (CHIP): 4194304 [FLASH] Flash size (SDK): 4194304 [FLASH] Flash Reserved: 4096 [MEM] Firmware size: 461024 [MEM] Max OTA size: 2678784 [MEM] OTA Reserved: 16384 [MEM] Free Heap: 28984 bytes initially | 7632 bytes used (26%) | 21352 bytes free (73%)
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
@susisstrolch crash and stack decryption is not something for novices and using the data is pointless with the source code. I assume anyone who's brave enough to compile the dev branch and upload the firmware can run the python file to decode the stack trace.
@Sonusss do you want to try building from source?
Hey,
Just wanted to let you know that I've been running the ems-esp roughly for four months, and it is working correctly.
This week also the ems-esp network showed up, even thhough it's still sending data to HASS.
@dutchrazor thanks, thats good extra info. Did you compile the firmware yourself? And also did the ems-esp appear after a reboot?
can you guys test with 1.9? I think the wifi/AP issue is resolved. At least I can't reproduce it.
Hi, I know that it was already reported but I'm sure that the board is having both Wifi client and acces point simultaneously activated. (Wemos 1 mini running 1.8.0) I can telnet on my internal subnet (192.168.1.79 in this case) and connect to ems-esp access point. Cannot telent simultaneously as it seems that it accept only one connection at a time but both are active.
First interface: telnet 192.168.1.79 Trying 192.168.1.79... Connected to 192.168.1.79. Escape character is '^]'. [TELNET] Telnet connection closed System Logging set to None [TELNET] Telnet connection established
Second interface: telnet 192.168.4.1 Trying 192.168.4.1... Connected to 192.168.4.1. Escape character is '^]'. [TELNET] exiting telnet session [TELNET] Telnet connection closed System Logging set to None [TELNET] Telnet connection established
This looks weird but it's true. What looks strange to me is this sequence: Connected to 192.168.4.1. Escape character is '^]'. [TELNET] exiting telnet session [TELNET] Telnet connection closed System Logging set to None [TELNET] Telnet connection established
As soon as AP mode is enabled serial is set to ON which makes the interface to EMS unusable....