Closed susisstrolch closed 5 years ago
Do you have some reading on how I can upload via OTA ?
@susisstrolch if I understand you correctly, using the 1.7 dev firmware, with the EMS connected, when opening a telnet session the ESP crashes and reboots? Does this happen when logging is activated only? Does it happen when you type a specific telnet command? How did you build the firmware? Any steps I can reproduce here? I've seen problems with the ANSI colors casusing printf() crashing but that was with an ESP32 and you'll only see this if you type 'info'
@proddy This happens ALWAYS - using your prebuild release 1.6 or using homebrewed 1.7xxxx versions.
As soon as I connect to EMS-Bus AND try to send ANY telnet command
<some command>[Return]
the system reboots. Even a plain [Return]
in telnet leads to a reboot.
As long as I don't send anything via telnet I don't see any reaction - not even a "Error! Unable to read the EMS bus"... MQTT also doesn't show anything but the start info...
For homebrew I've tried
Libs are the defaults from pio update...
Here's my platformio:
[platformio]
; add here your board, e.g. nodemcuv2, d1_mini, d1_mini_pro
env_default = d1_mini
[common]
flash_mode = dout
;cpu_clock = 160000000L
cpu_clock = 80000000L
build_flags = -g -w
; for debug use these...
build_flags = -g -Wall -Wextra -Werror -Wno-missing-field-initializers -Wno-unused-parameter -Wno-unused-variable -DCRASH
;wifi_settings =
; hard code if you prefer. Recommendation is to set from within the app when in Serial or AP mode
wifi_settings = '-DWIFI_SSID="whoCares"' '-DWIFI_PASSWORD="changeit"'
lib_deps =
CRC32
CircularBuffer
JustWifi
AsyncMqttClient
ArduinoJson
OneWire
EEPROM_rotate
[env:d1_mini]
board = d1_mini
platform = espressif8266
framework = arduino
lib_deps = ${common.lib_deps}
build_flags = ${common.build_flags} ${common.wifi_settings}
board_build.f_cpu = ${common.cpu_clock}
board_build.flash_mode = ${common.flash_mode}
upload_speed = 921600
monitor_speed = 115200
upload_port = /dev/ttyUSB0
; for OTA comment out these sections
upload_protocol = espota
upload_port = 192.168.254.139
;upload_port = <add here your ip of the device>
[env:esp12f]
board = esp12e
platform = espressif8266
framework = arduino
lib_deps = ${common.lib_deps}
build_flags = ${common.build_flags} ${common.wifi_settings}
board_build.flash_mode = ${common.flash_mode}
board_build.f_cpu = ${common.cpu_clock}
upload_speed = 921600
upload_port = /dev/esp8266
monitor_speed = 115200
; for OTA comment out these sections
upload_protocol = espota
upload_port = 192.168.254.82
Unfortunately I'm on business trip - and the latest SW I've uploaded was "prebuild 1.6" which obviously doesn't work with Arduino OTA - at least it doesn't listen to port 8266. So I can't do any further tests until weekend...
@moustic999 If you've installed the Arduino IDE you may want to use 'arduinoOTA', which is usually in folder 'hardware/tools/avr/bin/' below your Arduino base folder. Alternative: espota.py
@susisstrolch your build configuration looks fine. What OS and Telnet s/w are you using? Ironically theres a command called 'crash dump' which displays the stack-dump that caused the crash and the line number and function where it happened. But that'll be of no help to you.
@moustic999 to OTA change two lines in your platformio.ini. It uses the ArduinoOTA library on standard port 8266. You can check yourself using any free ios/android/win/osx MDNS sniffer and you'll see it. Best not to have an OTA discussion on this thread as its focused on susisstrolch's IT challenges
@proddy I‘ve tried Termius - Telnet for iOS Telnet on armlinux Telnet on Debian / Linux Mint Always the same Resultat. OS: Linux Mint, ArmLinux, iOS (iPhone and iPad)
Hmm, enhancement request: Trigger ‚crash dump‘ when Telnet Session is activated. Add a ,clean dump‘ command...
I did a quick test using telnet on Ubuntu 19.04 and didn't get any crashes, but noticed spaces were sent to the session window which is strange. I'll look into that piece of the code tonight. I'll also try Termius. So the reproducible test case, for example, could be
?
@proddy I also see sometimes a strange sessionwindow. It looks like the message text after the * is overwritten by spaces.
I guess testing with 1.6, EMS Connection and a Linux based Telnet is sufficient. You only have to press Return to trigger the problem.
Tonight I‘ll have a look with WireShark and also try with netcat.
@proddy did a quick test with netcat (which for sure doesnt send any overhead). Same result - reboot.
I found the problem and working on a fix.
Great! Can you also implement an "set crashdump off/on", with default "on" and conditionally call crashDump from telnetConnected? Or shall I create a pull request?
can you try the latest dev 1.7. I couldn't reproduce the crashes with Telnet under Ubuntu 19.10 but did using 'Get Console' and 'Termius' apps on an iPad.
the crash code is only included in the dev builds when compiled with the -DCRASH build option and then its always on capturing stack dumps after crashes. You want to display the crash data after a reboot only if there is data?
Can't test now - still on business trip. Unfortunately the 1.6 from github release seems to miss the OTA. So we've to wait until WE...
crashDump: simplest would be:
void MyESP::_telnetConnected() {
myDebug_P(PSTR("[TELNET] Telnet connection established"));
_consoleShowHelp(); // Show the initial message
#ifdef CRASH
crashDump();
#endif
if (_telnet_callback) {
(_telnet_callback)(TELNET_EVENT_CONNECT); // call callback
}
}```
BTW Termius's Telnet behaves strangely and newlines are not echo'd. I haven't seen this with any other telnet client and there are no settings you can configure within Termius to change its behaviour. This is why lines are sometimes overwritten.
Yes, it's a bit clumpsy with non-Unix systems...
If the client only sends a '\r' it won't auto add the '\n'...
and OTA has been in the code since version 1.1. I just built and uploaded 1.6 and tested it.
strange... I can't OTA with the 1.6 (firmware_d1_mini.bin)...
Argh... problem was on my side... Firewall enabled and VPN doesn't work very well with OTA from Visual Studio. I had to run espota.py manually - so stay tuned..
Ha... telnet works!
ok, now I also get the Error! Unable to read the EMS bus. Retrying in 20 seconds...
when connected to the bus...
I' shure that rx/tx aren't exchanged... have to check on WE
great, progress!
there's still something pretty wired. Now I only use netcat to ensure a clean protocol. When "serial=off" I mostly get 'unknown command". Pressing [Return] pretty fast and pasting in the desired command mostly helps. It still doesn't detect the boiler or anything else on EMSbus...
I tested with netcat from my Ubuntu box and telnet works (as in it responds to commands and doesn't hang) but I'm not ruling out that it's 100% yet. The code is quirky in places.
As for the EMS bus, look at what theinfo
command tells you. On mine it shows
EMS Bus stats:
Bus is connected
Rx: Poll=23 ms, # Rx telegrams read=240, # CRC errors=54
Tx: available, Tx delay is off, # Tx telegrams sent=0
I still see a ``` EMS Bus stats: No connection can be made to the EMS bus
Interesting - when setting 'serial on' it seems there's something coming in - at least I have to clean the telnet buffer with lot's of [return] until I can enter a command.
But - log v doesn't show anything...
What I still don't understand:
Silly question but you know Rx & Tx are switched, so D7 and D8 in my design? Just checking...
On Thu, 9 May 2019 at 23:34, susisstrolch notifications@github.com wrote:
What I still don't understand:
- my hardware is working fine with EMSLink software
- BBQs hardware is the same as mine
- the EMS-ESP bootup distorts the EMS-Bus (as expected), so Tx and Rx are ok
- your Rx IRQ is nearly identical to mine (beneath different macros) But it doesn't get any data with EMS-ESP...
— You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/proddy/EMS-ESP/issues/108#issuecomment-491077049, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJMO6DVGIGCN3G7OUKEB33PUSKEZANCNFSM4HLUHCHQ .
:man_facepalming: Only looked at the schema drawing - which shows Rx and Tx w/o pin numbers and D7/D8 as not connected!
That explains a lot! Will try to check this evening...
That would explain it then. It was mentioned in the README and now also the wiki (https://github.com/proddy/EMS-ESP/wiki/Assembly-and-Configuration). The reason I did this is to not have the bus interfere with the ESPs boot procedure. Also I think 99% of the people purchased BBQKees's board. My design was copied from yours and I used some of the ideas in esp-link in my code too - so kudos. You are even mentioned in the acknowledgments ;)
oh and it's also here too https://github.com/proddy/EMS-ESP/wiki/Troubleshooting#ems-bus-shows-as-disconnected
:-)
you know - a picture tells more than 1000 words... and the (wrong) schematic was burned into my brain... I read about D7/D8 but didn't realize it... :man_facepalming:
yes, the picture is wrong I need to update it to show D7/D8.
Did a quicktest by commenting the system_uart_swap();
in emsuart.h
Strolchi:/bay/Development/esp8266/EMS-ESP-Boiler$ telnet 192.168.254.139
Trying 192.168.254.139...
Connected to 192.168.254.139.
Escape character is '^]'.
EMS Tx delay is disabled
[WIFI] Connecting to SSID: whoCares
[WIFI] SSID whoCares
[WIFI] CH 4
[WIFI] RSSI -66
[WIFI] IP 192.168.254.139
[WIFI] MAC 5C:CF:7F:F1:BB:89
[WIFI] GW 192.168.254.1
[WIFI] MASK 255.255.255.0
[WIFI] DNS 192.168.254.1
[WIFI] HOST ems-esp
[OTA] listening to ems-esp.local:3232
Disabling serial port
[UART] Opened Rx/Tx connection
Starting auto discover of EMS devices...
Started scan on EMS bus for known devices
[MQTT] Connecting to MQTT...
[MQTT] Connected
[MQTT] Subscribing to home/ems-esp/restart (PID 2)
[MQTT] Subscribing to home/ems-esp/start (PID 3)
[MQTT] Subscribing to home/ems-esp/thermostat_cmd_temp (PID 5)
[MQTT] Subscribing to home/ems-esp/thermostat_cmd_mode (PID 6)
[MQTT] Subscribing to home/ems-esp/wwactivated (PID 7)
[MQTT] Subscribing to home/ems-esp/boiler_cmd_wwtemp (PID 8)
[MQTT] Subscribing to home/ems-esp/boiler_cmd_comfort (PID 9)
[MQTT] Subscribing to home/ems-esp/shower_timer (PID 10)
[MQTT] Subscribing to home/ems-esp/shower_alert (PID 11)
[MQTT] Subscribing to home/ems-esp/shower_coldshot (PID 12)
[MQTT] Subscribing to home/ems-esp/thermostat_cmd_hc (PID 13)
[MQTT] Subscribing to home/ems-esp/thermostat_daytemp (PID 14)
[MQTT] Subscribing to home/ems-esp/thermostat_nighttemp (PID 15)
[MQTT] Subscribing to home/ems-esp/thermostat_holidayttemp (PID 16)
[TELNET] Telnet connection established
* Connected to: EMS-ESP version 1.7.0b16
* Hostname: ems-esp (192.168.254.139)
* WiFi SSID: whoCares (signal 60%)
* MQTT is connected
*
* Commands:
* ?=help, CTRL-D/quit=exit telnet session
* set, system, reboot
* crash <dump | clear | test [n]>
* info show data captured on the EMS bus
* log <n | b | t | r | v> set logging mode to none, basic, thermostat only, raw or verbose
* publish publish all values to MQTT
* refresh fetch values from the EMS devices
* devices list all supported and detected EMS devices and types IDs
* queue show current Tx queue
* autodetect [deep] detect EMS devices and attempt to automatically set boiler and thermostat types
* shower <timer | alert> toggle either timer or alert on/off
* send XX ... send raw telegram data as hex to EMS bus
* thermostat read <type ID> send read request to the thermostat
* thermostat temp <degrees> set current thermostat temperature
* thermostat mode <mode> set mode (0=low/night, 1=manual/day, 2=auto)
* thermostat scan <type ID> probe thermostat on all type id responses
* boiler read <type ID> send read request to boiler
* boiler wwtemp <degrees> set boiler warm water temperature
* boiler tapwater <on | off> set boiler warm tap water on/off
* boiler flowtemp <degrees> set boiler flow temperature
* boiler comfort <hot | eco | intelligent> set boiler warm water comfort setting
System Logging set to None
refresh
Fetching data from EMS devices...
info
EMS-ESP system stats:
System logging set to None
LED is on, Listen mode is off
Thermostat is disabled, Boiler is disabled, Shower Timer is disabled, Shower Alert is disabled
EMS Bus stats:
Bus is connected
Rx: Poll=5 ms, # Rx telegrams read=0, # CRC errors=7
Tx: available, Tx delay is off, # Tx telegrams sent=0
Boiler stats:
Boiler: <not enabled>
Central heating: off
Warm Water activated: ?
Warm Water circulation pump available: ?
Warm Water selected temperature: ? C
Warm Water desired temperature: ? C
Warm Water current temperature: ? C
Warm Water current tap water flow: ? l/min
Warm Water # starts: ? times
Warm Water 3-way valve: off
Selected flow temperature: 45 C
Current flow temperature: 39.2 C
Return temperature: ? C
Gas: off
Boiler pump: on
Fan: off
Ignition: off
Circulation pump: off
Burner selected max power: 100 %
Burner current power: 0 %
Flame current: 45.8 uA
System pressure: ? bar
System service code: 0C (0)
Heating temperature setting on the boiler: ? C
Boiler circuit pump modulation max power: ? %
Boiler circuit pump modulation min power: ? %
Outside temperature: 11.8 C
Boiler temperature: 39.6 C
Pump modulation: 100 %
Burner # starts: 138251 times
Total burner operating time: 361 days 2 hours 45 minutes
Total heat operating time: 360 days 0 hours 54 minutes
Total UBA working time: 2699 days 19 hours 3 minutes
Works so far!
For those who can not update to the last version due to own modifications. => remove espressiif8266 which are not 2.04, means delete all version EXCEPT 2.04 and prevent upgrade after! You find it under PlatformIO Home/ platforms (delete all but 2.04)
Or use the latest version if you can.
@lobocobra here's just the other way around... upgrading to 2.2.1 and removing older ones fixed my reboot problem...
I would also recommend upgrading to the latest PlatformIO version 4 (sudo pio upgrade --dev
or platformio upgrade --dev
). It works so much better and you can use my optimized platformio.ini file. Also delete all the .pio* directories as with version 4 it will only create one.
It starts rebooting again. Got a stack dump... Maybe showing the last restart reason when opening the telnet session could help a bit finding the real issue...
stack:
0x3fff42c8: ?? at /home/strolch/.platformio/packages/framework-arduinoespressif8266/libraries/ESP8266mDNS/src/ESP8266mDNS.cpp:9
0x4022cb5a: operator new(unsigned int) at /workdir/arena/gcc/xtensa-lx106-elf/libstdc++-v3-nox/libsupc++/../../../../../dl/gcc-xtensa/libstdc++-v3/libsupc++/new_op.cc:52
0x40210f20: malloc at /home/strolch/.platformio/packages/framework-arduinoespressif8266/cores/esp8266/umm_malloc/umm_malloc.cpp:1677
0x3fff42c8: ?? at /home/strolch/.platformio/packages/framework-arduinoespressif8266/libraries/ESP8266mDNS/src/ESP8266mDNS.cpp:9
0x4022cb5a: operator new(unsigned int) at /workdir/arena/gcc/xtensa-lx106-elf/libstdc++-v3-nox/libsupc++/../../../../../dl/gcc-xtensa/libstdc++-v3/libsupc++/new_op.cc:52
0x3fff42c8: ?? at /home/strolch/.platformio/packages/framework-arduinoespressif8266/libraries/ESP8266mDNS/src/ESP8266mDNS.cpp:9
0x4021ece8: esp8266::MDNSImplementation::MDNSResponder::_sendHostProbe() at /home/strolch/.platformio/packages/framework-arduinoespressif8266/libraries/ESP8266mDNS/src/LEAmDNS_Control.cpp:1197
0x401064ff: esp8266::polledTimeout::timeoutTemplate<false, esp8266::polledTimeout::YieldPolicy::DoNothing, esp8266::polledTimeout::TimePolicy::TimeUnit<esp8266::polledTimeout::TimePolicy::TimeSourceMillis, 1000ull> >::expiredOneShot() const at /home/strolch/.platformio/packages/framework-arduinoespressif8266/cores/esp8266/PolledTimeout.h:216
\-> inlined by: esp8266::polledTimeout::timeoutTemplate<false, esp8266::polledTimeout::YieldPolicy::DoNothing, esp8266::polledTimeout::TimePolicy::TimeUnit<esp8266::polledTimeout::TimePolicy::TimeSourceMillis, 1000ull> >::expiredOneShot() const at /home/strolch/.platformio/packages/framework-arduinoespressif8266/cores/esp8266/PolledTimeout.h:241
0x402508eb: wifi_station_get_connect_status at ??:?
0x3fff42c8: ?? at /home/strolch/.platformio/packages/framework-arduinoespressif8266/libraries/ESP8266mDNS/src/ESP8266mDNS.cpp:9
0x4021f618: esp8266::MDNSImplementation::MDNSResponder::_updateProbeStatus() at /home/strolch/.platformio/packages/framework-arduinoespressif8266/libraries/ESP8266mDNS/src/LEAmDNS_Control.cpp:1053
0x40216ef8: ESP8266WiFiSTAClass::status() at /home/strolch/.platformio/packages/framework-arduinoespressif8266/libraries/ESP8266WiFi/src/ESP8266WiFiSTA.cpp:613
0x3fff1dcc: ?? at /bay/Development/esp8266/EMS-ESP-Boiler/src/ems-esp.cpp:138
0x402508eb: wifi_station_get_connect_status at ??:?
0x3fff42c8: ?? at /home/strolch/.platformio/packages/framework-arduinoespressif8266/libraries/ESP8266mDNS/src/ESP8266mDNS.cpp:9
0x3fff4120: ?? at /home/strolch/.platformio/packages/framework-arduinoespressif8266/libraries/ESP8266WiFi/src/ESP8266WiFi.cpp:98
0x40220257: esp8266::MDNSImplementation::MDNSResponder::_process(bool) at /home/strolch/.platformio/packages/framework-arduinoespressif8266/libraries/ESP8266mDNS/src/LEAmDNS_Control.cpp:82
0x3fff1dcc: ?? at /bay/Development/esp8266/EMS-ESP-Boiler/src/ems-esp.cpp:138
0x3fff41ec: ?? at /home/strolch/.platformio/packages/framework-arduinoespressif8266/libraries/ArduinoOTA/ArduinoOTA.cpp:379
0x4021e7fe: esp8266::MDNSImplementation::MDNSResponder::update() at /home/strolch/.platformio/packages/framework-arduinoespressif8266/libraries/ESP8266mDNS/src/LEAmDNS.cpp:1124
0x3fff37b8: ?? at /bay/Development/esp8266/EMS-ESP-Boiler/lib/MyESP/MyESP.cpp:1572
0x3fff1dcc: ?? at /bay/Development/esp8266/EMS-ESP-Boiler/src/ems-esp.cpp:138
0x3fff37b8: ?? at /bay/Development/esp8266/EMS-ESP-Boiler/lib/MyESP/MyESP.cpp:1572
0x4021d61a: ArduinoOTAClass::handle() at /home/strolch/.platformio/packages/framework-arduinoespressif8266/libraries/ArduinoOTA/ArduinoOTA.cpp:372
0x3fff1dcc: ?? at /bay/Development/esp8266/EMS-ESP-Boiler/src/ems-esp.cpp:138
0x3fff37b8: ?? at /bay/Development/esp8266/EMS-ESP-Boiler/lib/MyESP/MyESP.cpp:1572
0x4020c990: MyESP::loop() at /bay/Development/esp8266/EMS-ESP-Boiler/lib/MyESP/MyESP.cpp:1567
0x3fff1dcc: ?? at /bay/Development/esp8266/EMS-ESP-Boiler/src/ems-esp.cpp:138
0x40205cd4: loop at /bay/Development/esp8266/EMS-ESP-Boiler/src/ems-esp.cpp:1742
0x4020e998: loop_wrapper() at /home/strolch/.platformio/packages/framework-arduinoespressif8266/cores/esp8266/core_esp8266_main.cpp:125
0x3ffe9714: ?? at /home/strolch/.platformio/packages/framework-arduinoespressif8266/cores/esp8266/core_esp8266_main.cpp:55
0x401006e9: cont_wrapper at /home/strolch/.platformio/packages/framework-arduinoespressif8266/cores/esp8266/cont.S:81
do you get this all the time? What I could do is provide a firmware.bin to try. Quickly looking at the stack it looks like the OTA code
and you do you get this all the time, or after an ORA upload or during telnet? It will help me pinpoint the root cause.
I got the coredump only once. But ongoing reboots. Also when MQTT is disabled.
oh, thats bad. Can you wipe the esp (pio run -t erase) and rebuild the firmware. It'll start in AP mode and with Serial set. do a system
to capture the ESP details and then change the password. I need to re-produce here to fix the issue
Stupidity... had two EMS-bridges connected to the bus - my old EMS-Link and the EMS-ESP. Seems that was a bit too much current... So I only have to add EMS_Boiler.burnWorkMin and heatWorkMin to MQTT data to completely replace the old one...
for the files...
ESP8266 System stats:
[APP] EMS-ESP version: 1.8.0b8
[APP] MyESP version: 1.1.12
[APP] Build timestamp: 2019-05-28 17:41:11
[APP] Uptime: 0 days, 0 hours, 0 minutes, 52 seconds
[APP] System Load: 0%
[WIFI] WiFi Hostname: ems-esp
[WIFI] WiFi IP: 192.168.254.100
[WIFI] WiFi signal strength: 80%
[WIFI] WiFi MAC: 18:FE:34:F3:BF:0F
[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: 0xF3BF0F
[SYSTEM] Core version: 2_5_2
[SYSTEM] Boot version: 31
[SYSTEM] Boot mode: 1
[FLASH] Flash chip ID: 0x1640C8
[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: 442064
[MEM] Max OTA size: 2699264
[MEM] OTA Reserved: 16384
[MEM] Free Heap: 12984
Bug description Hardware:
As long as the system isn't connected to the EMS-Bus telnet works as expected. Setting the "serial" to "off" leads to the expected check message each 20s. Setting WIFO, requesting system info etc. works as far EMS is not concerned:
As soon as the system is connected to the EMS-Bus the telnet connection behaves different. On connect I only see this output:
The system does NOT show the
Error! Unable to read the EMS bus. Retrying in 20 seconds...
when I leave it running w/o telnet input.Additional info (EMS-Bus connected, EMS-Bus or USB-powered):
Summary: When connected to EMS-Bus I can't see any information from EMS-Bus. What makes it worse is the reboot after 3-5s when sending any command via telnet. Even after compiling with
I don't see any bit of log in the telnet console.
I sniffed the EMS-Bus with a second EMS-Link. Here I saw the (expected) collisions/framing errors during bootup of EMS-ESP. What I didn't see where the queries from the autodetection...
As a side node, the hardware was tested and worked with my EMS-Link software w/o problems.