November Quickie – Stress – TDM and ESP-GO

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

1. 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. That looks GREAT. If I can get Eclipse back up on my PC (not used for a while) I should be able to use that to start up mdns? I hav room.

      1. Try it. It worked.

         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. Put that lot in – it turns out I dont have this either. I put both files in te user directory and

                  Looks like I don’t have “httpclient.h”

                  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. Peter,

                           I am sending a mail to pete@scargill.org, because it is hard to communicate throuh comments.

                           1. Thanks George…. appreciated. I just hope my broadband perks up this evening…

   2. I have a slight problem – I don’t have a “broadcastd.h”
      Do you have that to hand? Bearing in mind I’m using sdk 2.2

      1. I’m afraid not the broadcastd.h is the proper include file (it was for ThingSpeak upload. I am checking.

         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.

2. 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.

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. At this point in my own mind I’m blaming Tasmota as I don’t recall this problem previously (over a matter of years). I could be wrong of course.

               1. Its more of an Arduino core problem than Tasmota since all the wifi magic is happening inside the core.

                  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. Believe it or not we’re on it as much as resources permit

               2. The move to Tasmota 7.0.0.3 did not fix anything.

      2. I agree, sounds like too many people GUESSING and putting that forward as answers. I’ve used cheap FTDIs for YEARS without issue -for example.

         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.

      3. 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. I think you need more than 2 hours to claim absolute victory…

            1. absolutely, but in latest 2 days i had an exception reboot in less than 5 minutes after i restarted them manually… let’s wait…

            2. 6 hours and not a single flicker/restart…

               1. Antonio let me know your results tomorrow. The board I’ve put on monitoring seems to be failure (just by the act of monitoring) but not long enough test… couple of hours.

                  1. 20 hours, not a single reboot/flicker

                     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. 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.

         1. oh, yes, now i’ve understood what you were talking about, yes, you’re right, of course 🙂

5. 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.

6. Did I not recently read that recent updates to the Pi4 were going to deal with the heat issue?

Comments are closed.