November Quickie – Stress – TDM and ESP-GO

Stat3

A few simples notes on probably my pet project and also some work that Antonio and I have been doing recently including a quick stress test for the Pi4, for those concerned about heat… remember I wrote about a combined heatsink/case?

With this:

sudo apt-get install stress
while true; do vcgencmd measure_clock arm; vcgencmd measure_temp; sleep 10; done& stress -c 4 -t 900s

The above came from:

https://core-electronics.com.au/tutorials/stress-testing-your-raspberry-pi.html

and on my Pi4 with the new fan/heatsink, while running that stress test for several minutes in an SSH session, the temperature never got above 62c which is fine. The stress testing stops when you close the SSH session. I undrstand that recent updates to the Pi help with temperature issues – what I don’t yet know is if such improvements come with an “apt upgrade” or if you have to do something else. I’m also eagerly awaiting the USB3 boot option promised for sometime this decade.

Meanwhile we’re both noticing, having moved lock stock and barrel to Tasmota for our ESP8266 devices, some “exceptions” and we’re still not 100% sure we have all the answers. I recently noticed that two of my Tasmota-driven lights flickered every now and then when on, not something I’ve noted before. I currently have a feeling this all started after Tasmota 6.5.0

To test this we installed the Tasmota Device Manager 0.2.0 on Windows (using an administrative command prompt – most annoying when there IS only me – administrator, chief cook and bottle-washer) – it has prerequisites of:

python -m pip install –upgrade pip
python -m pip install PyQt5 paho-mqtt PyQtWebEngine

and having then cloned or downloaded tdm (Tasmota Device Manager)

python3 tdm.py (in Linux)

pythonw.exe tdm.py (in Windows)

It seems (though it is by no means certain) that moving to Tasmota 7.0.0.4 and ensuring you do NOT have an extremely weak signal may elimiinate these exceptions.

And finally, I’m sure someone, somewhere is thinking (I wonder what happened to Scargill’s ESP-GO? Well, it is alive and kicking. It does not need updates to Arduino SDKs as I did not use the Arduino SDK .I use the Espressif SDK- 2.2 as I still can’t get 100% reliable OTA out of RBOOT using SDK 3.0. So why not use ESP-GO? It does not do Alexa (you can get by that in Node-Red) and does not do pretty hostnames (working on that thanks to one of our readers) as I could not figure out how to do that with the Espressif SDK. My OTA needs 4MB devices as it has all sorts of failure protection built in, in the event of a bad OTA.

As Tasmota and others rush to add features, ESP-GO just works. It runs RGB serial LEDs – up to 300 of them , with soft fading and a host of effects you build up yourself. It also does 3 channel PWM, has a 60-LED clock program built in, handles various OLED and LCD displays, debounced buttons, a raft of sensors and much more. The current version has been controlling my house heating utterly reliably (a lot more reliable than the actual LG air-source heating system itself) since April 2019 (we went off to Spain for 6 months and left it running without support for holiday cottage guests to use) – it is now November 2019.

ESP-GO in use
ESP-GO in one of my two house thermostats – running the house 24-7 with Node-Red remote control

So, next time anyone wonders about ESP-GO – it’s doing just nicely thank you. The main ESP-GO blog entry points you to the source code, BINS (link in the blog entry) and FULL WORD manual (same place as the source) on BitBucket.

And here is my home-grown Node-Red-Dashboard thermostat that has allowed me remote heating control all this time – I put it together in an early blog but only in 2018 did I finish it off into a working piece of code (not properly documented before anyone asks) along with remote monitoring. I’m more than happy playing with Tasmota and others – marvellous stuff – which has some distinct advantages – but when I need some power and utter reliability without worrying about Arduino SDK issues – I often end up with Node-Red and ESP-GO (currently sitting around 700K with everything in). STAT4 in the photos was put into the bedroom as a belt and braces backup for STAT3 (in the study), as it happens it has not been needed as both run 24-7 reliably.

Currently, a Shelly ONE (tiny WIFI mains control unit) is controlling the actual Air Source heating control relay and a Sonoff TH-16 running Espurna runs the 2KW+ lower backup immersion heater in the hot water tank (in case of Air-Source system failure – not LG’s finest hour by any means).

Below is the Grafana monitor which runs constantly and is remotely accessible – just like the Node-Red-Dashboard-based stat.

Grafana heating dashboard on my UK RPi4
Facebooktwitterpinterestlinkedin

45 thoughts on “November Quickie – Stress – TDM and ESP-GO

  1. Re:- TASMOTA light flickering every now and then…

    I got impatient waiting for Itead to produce a face-plate for the T1 light switch suitable for Japan and built my own version (of what would now be the Sonoff Mini) using basically the Sonoff PSU, an ESP01 and a TRIAC, all on a small chunk of veroboard. Stuck it into the external light fitting with a high output LED bulb and we were off to the races! Twilight auto-on, manual override, web interface and Gewgull home.

    Then a couple of weeks later, we came home late and the light was flickering. Switched off and back on and it was fine. A couple of weeks later, the same thing. Oh dear! (or words to that effect). Pulled the ESP and sat it on the bench, but the fault was so intermittent that I couldn’t repeat it. It’s still on the bench.

    Months passed. Came home the other night and the light was flickering (With no ESP in circuit). Beggar it! (OWTTE). Intermittent LED bulb.

  2. You can use the « screen » command over SSH to detach from the session before closing it and reattach upon reconnection over a new session.

    1. yes, but as this command is run, it runs the monitoring reporting part in background, and the stress part in foreground… when you press ctrl-c, it kills the stress part, but the other continues to report it’s results, so or you kill the ssh session, or you look for its PID and kill that 🙂

      1. You don’t press “ctrl-c”: just login via ssh, launch “screen” without argument, then launch the stress as you like.

        You can then press “ctrl-a H” to log output to a “screenlog.0” file, and “ctrl-a d” to detach from the terminal session with the stress still running in background and foreground. Then close the ssh session.

        You can then reopen an ssh session, and re-attach to the live terminal session with “screen -r”, and get back where you left.

        You can use “screen -ls” to list the active terminal sessions.

  3. I’ve had intermittent problems with a couple of devices starting to reboot every minute or so. this would last for several hours and then stop.
    I have a mixture of Shelly, Sonoff, Teckin and ESP-01 devices and they have all had this problem at one time or another. It was always only one or two devices at a time that would start the reboot cycle and the issue would seem to move from device to device.
    I moved all my devices out over to their own WiFi AP and the problem went away (so far).

    1. Personally I’m half convinced I never had this until I started to standardise on Tasmota. I’m going to take one of the offending devices and put it on Espurna, the other on (another light) and put it on esp-go.

      1. you can do that only for general purpose device of which an espurna specific firmware exists, or you can modify gpio assignments, like your esp-go or espeasy… in both cases (esp-go and espeasy) you’ll loose alexa native integration… and espurna has no template/config page…

      2. I have a couple of Anoopsyche power monitoring plugs that were Tasmotized back in May to monitor washing machine/dryer consumption. I recently moved them and found that they had become very unreliable and were flickering lights on and off regularly. On investigation the unit was resetting at up to 30 times and hour – the Tasmota version was tried at 6.5, 6.7 and 7.0 with no effect, I suspected retained mqtt messages but again no joy and the RSSI was showing 75% + on all devices so connectivity seemed OK. However on relocating the devices to a stronger wi-fi location I have gone from up to 30 resets an hour to none in the last 24 hours on both devices. My suspicion is that some form of timeout/buffer overflow in Tasmota is causing the devices to reset which briefly flicks the power on and off. Maybe this is linked to your issue as the symptoms sound similar

        1. as in my other comment down here, same experience… i just picked one of those WT3020 router i had on a box, flashed it with openwrt, and created a new access point bridging wan and wifi interfaces… that’s it, issues are now gone, from 3 hours now not a single restart…

          https://openwrt.org/toh/nexx/wt3020

          Pete, you should have that yellow mango router, it’s like this one i’m using… but you can use just on other access point, many suggest to go to ubiquiti unifi, but i don’t want to spend more than 100€ on an access point…

          1. Just for reference I didn’t change the access point just moved the device to a stronger signal area. Odd thing is going by the RSSI reading the signal is not that bad in the original location? If I move it back I will have to look at installing the OpenWRT router or wait for them to fix issues with the SDK(if that is the root issue)

            1. they who? As said, tasmota guys told me a bunch of different solutions, which could be even good for most other cases, but not on mine… i had expections for bad memory writes, look here for 29:

              https://github.com/esp8266/Arduino/blob/master/doc/exception_causes.rst

              so, who ever could have thought of changing access point? I changed it 3 months ago, and then started the issues… i recently moved all of them to core 2.6.0pre, which seems as stable as 2.3.0 but without the recently discovered security issues of 2.3.0 (this is why no more 2.3.0 bin files on tasmota site), and noted all these disconnects…

              with same ssid and password as before, router put in the identical spot of previous one, and anyway i had good rssi on my problematic router, it’s just 5 meter max far from the devices…

              so, if the issues are in sdk, don’t even know where to report them…

        2. Could you possibly repeat that in an issue in Tasmota forums, feel free to say I am not discounting this idea as I don’t have a better one. Antonio it would seem changed access points – but is it because he changed access points or because the new access point is a stronger signal which would re-inforce your idea and STILL points back to Tasmota. I definitely do not have this issue with earlier Tasmotas, or ESP-GO. I should also point out that the errors are all inmy office several feet from the access point in here. In the house there are other access points with other names

    2. i need to do the same, as i never had such issues with my previous router/ap… on discord they said that this can be caused by tuya-convert not erasing full flash memory (so, WHY THE HELL suggest to use it?), other said that it was use of 4mb bin files on 1mb devices, other that it was the flashing tool (nodemcu-piflasher, again, SUGGESTED BY MANY OF THEM) instead of the stock esptool.py, others that it was the serial adapter (the red ftdi, which they say does not give enough power during flash) and to use only ch340g based adapters… how can this be addressed, with all this variables? And if i do a device via tuya-convert, just to avoid opening it, now i need to crack them and go via serial? unbelievable…

      1. I’ve used both OTA and serial and devices from different manufacturers. The only commonality is Tasmota.
        I moved the devices to their own AP because I have a lot of WiFi devices (phones, tablets, TVs, cameras etc) and I thought the crashes might have been due to WiFi problems. Since I moved them there hasn’t been any issues. The only other thing I did, at the same time, was change the telemetry reporting from 300 seconds to 60.

        1. Thanks for that – to add to the mix – Tasmota has just gone up to 7.0.0.3 – I’ll try moving devices over to another access point as I have a few on one. Other thoughts – keep ’em coming.

              1. Hmm, lots of ideas as to exactly where the problem lies, I can only say with confidense that thisid new for me – as is moving to the later Arduino core… we need to talk those workin on Tasmota development to spend some time on this issue?

                Bloody thing just flickered as I’m writing this.

        1. Peter, if I could offer a suggestion. One could set up a ‘control’ device of, say, a standard ESP8266 board powered from a decent PSU and a relay module thus ,apart from the PSU, replicating a Sonoff / Shelley device. An alternative to the relay could be some form of LED driver. This device, loaded with an appropriate Tasmota firmware, would eliminate any variance in Sonoff, Shelley etc. It can be ‘flashed’ easily by FTDI, OTA or USB as necessary.

      2. hi guys, remember those tasmotized sonoffs and other device of me and Pete of a few days ago which were throwing out repeated EXCEPTION 29? In my case it was not the serial adapter used (my red ftdi instead of the suggested ch340), nor it was tuya-convert i used on each of them, nor it was a bad flash, nor reset 5, nor nodemcu-pyflasher instead of esptool.py to reflash some of them…

        just added a new access point, on which i moved just the IOT devices (tasmota and espurna ones), and that’s it… no more reboots, more than 2 hours without a glitch, while before i had reboots at least every 20 minutes… so, why expressif sdk expection 29 is advertised as bad memory access, or something the likes, if just changing access point solved that?

                1. Just some extra information – I have tried a variety of other Tasmotized devices (sonoffs and d1 minis)- of various releases and access points in the original location and they do not have the reset problem – only the Anoopsyche plugs – whether the issue is power monitoring, ex tuya devices or device specific I cannot say but the sonoff s2x is showing RSSI of only 56% way below that of the Anoopsyche and still functions perfectly.

  4. Just some extra information – I have tried a variety of other Tasmotized devices (sonoffs and d1 minis)- of various releases and access points in the original location and they do not have the reset problem – only the Anoopsyche plugs – whether the issue is power monitoring, ex tuya devices or device specific I cannot say but the sonoff s2x is showing RSSI of only 56% way below that of the Anoopsyche and still functions perfectly.

  5. Peter,
    I noticed that you have mentioned the mdns problem more times. I used it in older native Espressif environment, an excerpt from my program:

    #include “broadcastd.h”
    .
    .
    .
    void ICACHE_FLASH_ATTR mdns_publish(void) {
    espconn_mdns_close();
    sysCfg.wifi_mode = wifi_get_opmode();

    if (sysCfg.wifi_mode == STATION_MODE || sysCfg.wifi_mode == STATIONAP_MODE) {
    struct ip_info ipConfig;
    wifi_get_ip_info(STATION_IF, &ipConfig); // IP INFO for station
    if ( espconn_mdns_get_hostname() != MQTT_DEVID) {
    INFO(“Start mDNS\r\n”);
    struct mdns_info *mdns_info = (struct mdns_info *)os_zalloc(sizeof(struct mdns_info));
    mdns_info->host_name = MQTT_DEVID;
    mdns_info->server_name = MQTT_DEVID;
    mdns_info->server_port = 80;
    mdns_info->ipAddr = ipConfig.ip.addr; //station ip
    espconn_mdns_init(mdns_info);
    }
    }
    }

        1. Hi I’m struggling with the dev environment at the moment to ensure I’m working on the latest source, not done this since May.. Are you saying the the code here…

          #include “broadcastd.h”
          .
          .
          .
          void ICACHE_FLASH_ATTR mdns_publish(void) {
          espconn_mdns_close();
          sysCfg.wifi_mode = wifi_get_opmode();

          if (sysCfg.wifi_mode == STATION_MODE || sysCfg.wifi_mode == STATIONAP_MODE) {
          struct ip_info ipConfig;
          wifi_get_ip_info(STATION_IF, &ipConfig); // IP INFO for station
          if ( espconn_mdns_get_hostname() != MQTT_DEVID) {
          INFO(“Start mDNS\r\n”);
          struct mdns_info *mdns_info = (struct mdns_info *)os_zalloc(sizeof(struct mdns_info));
          mdns_info->host_name = MQTT_DEVID;
          mdns_info->server_name = MQTT_DEVID;
          mdns_info->server_port = 80;
          mdns_info->ipAddr = ipConfig.ip.addr; //station ip
          espconn_mdns_init(mdns_info);
          }
          }
          }

          should work if I put it aftr the WIFI setup ?

          1. Mine worked (yes, after WIFI). But after the stable ESP8266 Arduino version was issued I abandoned the native development.

            I checked the Espressif version I had used and it seems to be v2.0.0., a bit ancient. Hope it works with the latest one.

              1. (If you see an empty include it should be “less than”esp8266.h”greater than”. It diseappears in the list on my screen.)
                The relevant include files in the program:
                #include “mem.h”
                #include “upgrade.h”
                #include
                #include “wifi.h”
                #include “httpd.h”
                #include “httpdespfs.h”
                #include “cgi.h”
                #include “cgiwifi.h”
                #include “auth.h”
                #include “espmissingincludes.h”
                #include “ets_sys.h”
                #include “osapi.h”
                #include “os_type.h”

                1. Hi

                  Sorry to be a pain – I don;t have those items in my sysCfg block – and you’ve commented out BROADCAST_PERIOD.. I don;t unserstand it that well, could I trouble you o give me a self-contained amended versio that assumes you want to use a host name. And where would you put the hostname – I could easily add that to my sysCfg setup.

        1. I wrote it for ages and couldn’t remeber, but I found it.

          the file to be included:
          #include “espmissingincludes.h”
          that contains the resolution file: espconn.h

          Please try it, I hope it works.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.