ESP Easy next stable... (release candidates)

Message

iron · #81 Post by **iron** » 14 Nov 2016, 13:13

Martinus wrote:R145_RC6 is available for download
http://www.letscontrolit.com/wiki/index ... candidates

Current status:

Bug #01 FIXED in R138 : Clock event at system boot issues
Bug #02 FIXED in R139 : Domoticz MQTT support was completely broken as of R109 (so it also affects R120!)
Bug #03 FIXED in R140 : I2C Scanner would not show PCF8574A at default address
Bug #04 FIXED in R141 : Pulsecounter value display style elements
Bug #05 FIXED in R141 : Some missing I2C scanner 'known devices'
Bug #06 FIXED in R145 : Task value name remains after clearing task
Bug #07 OPEN : Pulse counter total increases every second without pulse? - Unable to reproduce...
Bug #08 FIXED in R142 : Missing BMP180 in I2C scanner
Bug #09 FIXED in R142 : Missing MLX90614 in I2C scanner
Bug #10 FIXED in R412 : Intermittent issue getting NTP time during boot
Bug #11 FIXED in R145 : WDT crash using ADC/MQTT OpenHAB
Bug #12 OPEN : R142 resets configuration - (Upgrade from R143 to R145 went fine on all my units)
Bug #13 CLOSED : IP display errors - erroneous bug report...

Still can't see any cause for Bug #07 and still unable to reproduce...
Let's see if Bug #12 shows itself with R145

I can confirm upgrading to RC6 (from R142) did not reset configuration on the same device I had issue with when upgarding from 120 to 140

hvdwolf · #82 Post by **hvdwolf** » 14 Nov 2016, 13:46

Out of curiosity and to know what we are testing.
@martinus: How are the RCs built? As "bare bones" EspEasy repository only builds? or with all ESPEasyPluginPlayground plugins? or with a selected set of extra plugins?

Martinus · #83 Post by **Martinus** » 14 Nov 2016, 15:03

tozett wrote:whats/why the difference between r145_RC6 and the R145 on github?

No difference in terms of source code. The release candidates are delivered as binaries so everyone should be able and encouraged to try the latest stable-to-be version.

iron wrote:I can confirm upgrading to RC6 (from R142) did not reset configuration on the same device I had issue with when upgarding from 120 to 140

Thanks for reporting. I'll close the bug report for now.

hvdwolf wrote:Out of curiosity and to know what we are testing.@martinus: How are the RCs built anyway? As "bare bones" EspEasy repository only builds? or with all ESPEasyPluginPlayground plugins? or with a selected set of extra plugins?

The aim within this topic is to get new standard binary images out in the field to replace R120.
The binaries are build from the ESP Easy github repository without any change to the source or configuration settings and without any playground plugin.

When this stage is finished successfully, R120 will be replaced with Rxxx as the one and only stable edition, still suitable for all existing ESP modules.

beic · #84 Post by **beic** » 14 Nov 2016, 15:27

Hi Martinus,

Regarding the the i2c scanner:

1). under 0x3F address please add after PCF8574A the LCD 16x2 Display module like LCD!
2). under 0x40 address please add after SI7021 the HTU21D sensor too, it's working with the SI7021 plugin (tested)!

And a few other issues, notes, conclusion, etc...

1). Those Devices are on 3 separate pages, why? It would be better if all 12 device list were on only one page listed.
2). After removing any i2c sensors, devices from the i2c bus, all last values remain or it says for the (DHTxx, DHT12 and DS18b20 = nan), I think it would be better if the values goes to 0.00

Thank you!

ManS-H · #85 Post by **ManS-H** » 16 Nov 2016, 17:55

I see a strange thing with Build 120 and also at Build 145RC. When i fill the optional settings for IP etc. in Config i see that the time isn't correct. When i remove the settings the time is okay again. I did a reboot after the changes.

145-4.JPG

145-3.JPG

145-2.JPG

145-1b.JPG

145-1a.JPG

hvdwolf · #86 Post by **hvdwolf** » 16 Nov 2016, 18:17

Your last screen capture displays to use NTP but doesn't show an NTP server address (or pool).
Did you forget this or is this part of the problem?

I can imagine that when you use DHCP you simply get the time from your router.
However, if you specify a static ip you need to give an NTP server (or pool)

ManS-H · #87 Post by **ManS-H** » 16 Nov 2016, 18:37

However, if you specify a static ip you need to give an NTP server (or pool)

But this is from the Wiki:
NTP Hostname Can be left empty as it defaults to pool.ntp.org. Can be changed here if needed.

And the time from my Ziggo modem/router is: Current Time: Wed. Nov 16 19:35:37 2016

It's possible that i made a mistake, but that's the reason i ask it here

grhhm · #88 Post by **grhhm** » 16 Nov 2016, 19:37

Hello,

Seems, this is a bug report for release 140. If I am posting to wrong topic, please, point me to correct one.

The ESP module with release 140 runs MQTT publishing of HTU21, BMP180, and light sensors. It works fine (missing some reports, not a concern here).
After 2-3 hours of work it is impossible to dial into ESP module from browser. No response at all. No ping to ESP. MQTT publishing still works.

Power cycle of the ESP renews the HTTP access to it for additional 2-3 hours.

Thank you.

hvdwolf · #89 Post by **hvdwolf** » 16 Nov 2016, 20:19

@mans-h : I did not even know it defaults to an existing ntp server, but what happens if you use nl.pool.ntp.org ?
I have that in all my ESPs.

Edit: You are right about the default. It is here.

ManS-H · #90 Post by **ManS-H** » 16 Nov 2016, 20:39

@mans-h : I did not even know it defaults to an existing ntp server, but what happens if you use nl.pool.ntp.org ?
I have that in all my ESPs.

Edit: You are right about the default. It is here.

I used your sugesstion: nl.pool.ntp.org and europe.pool.ntp.org

When i fill the optional settings for IP, time is gone.

20-35.JPG

Martinus · #91 Post by **Martinus** » 17 Nov 2016, 16:51

ManS-H wrote:
@mans-h : I did not even know it defaults to an existing ntp server, but what happens if you use nl.pool.ntp.org ?
I have that in all my ESPs.

Edit: You are right about the default. It is here.
I used your sugesstion: nl.pool.ntp.org and europe.pool.ntp.org

When i fill the optional settings for IP, time is gone.

20-35.JPG

Looks like DNS setting is incorrect or the provided IP does not 'relay' DNS requests.
At least, without a working DNS, ESP Easy will not be able to get the current time and will start at 0:01...

Martinus · #92 Post by **Martinus** » 17 Nov 2016, 17:00

grhhm wrote:Hello,

Seems, this is a bug report for release 140. If I am posting to wrong topic, please, point me to correct one.

The ESP module with release 140 runs MQTT publishing of HTU21, BMP180, and light sensors. It works fine (missing some reports, not a concern here).
After 2-3 hours of work it is impossible to dial into ESP module from browser. No response at all. No ping to ESP. MQTT publishing still works.

Power cycle of the ESP renews the HTTP access to it for additional 2-3 hours.

Thank you.

It looks like the network server processes somehow get disrupted. I'm not using MQTT, so a total lack of experience.
Could it be that the system gets corrupted or overloaded with incoming MQTT messages?

Before declaring this a bug, i would like to get more feedback from other MQTT users to see if their systems suffer from similar behavior. You should also report more information on which MQTT broker and MQTT application(s). Maybe we can see a pattern with enough feedback.

ManS-H · #93 Post by **ManS-H** » 17 Nov 2016, 17:02

Looks like DNS setting is incorrect or the provided IP does not 'relay' DNS requests.
At least, without a working DNS, ESP Easy will not be able to get the current time and will start at 0:01...

Thanks Martinus,
That's the solution. I changed ESP DNS: 192.168.0.1 in 8.8.8.8 and the time is correct again.

papperone · #94 Post by **papperone** » 17 Nov 2016, 17:11

Martinus wrote:
grhhm wrote:Hello,

Seems, this is a bug report for release 140. If I am posting to wrong topic, please, point me to correct one.

The ESP module with release 140 runs MQTT publishing of HTU21, BMP180, and light sensors. It works fine (missing some reports, not a concern here).
After 2-3 hours of work it is impossible to dial into ESP module from browser. No response at all. No ping to ESP. MQTT publishing still works.

Power cycle of the ESP renews the HTTP access to it for additional 2-3 hours.

Thank you.
It looks like the network server processes somehow get disrupted. I'm not using MQTT, so a total lack of experience.
Could it be that the system gets corrupted or overloaded with incoming MQTT messages?

Before declaring this a bug, i would like to get more feedback from other MQTT users to see if their systems suffer from similar behavior. You should also report more information on which MQTT broker and MQTT application(s). Maybe we can see a pattern with enough feedback.

I've got several Wemos D1 Mini running ESPEasy (from 120 to 145R6) all of them using MQTT broker (mosquitto on RaspberryPi 2).
I've at the moment NodeRed acting as a coordinator of MQTT messages (typically nodes sends out sensors/switch status to NodeRed via MQTT, and NodeRed issues MQTT commands to the nodes).
it's already more than 1 month I moved to ESPEasy (before I was using custom sketches) and all nodes are 24/7 working without any issues with MQTT...
If you need more details let me know!

Shardan · #95 Post by **Shardan** » 17 Nov 2016, 17:46

Hello,

i approve there might be a problem with the web server process.
Up to now i thought it was my breadboard testing here causing trouble.

It's a GP2Y10 dust sensor, an OLED display and some on/off-GPIO's driven by rules.
I have the same effect without MQTT, it's just a testing/calibrating for the GP2-sensor running standalone.
Occasionally the webserver disappears and i have to reboo to get access back.
This is intermittent here, atm it runs since 15 hours, sometimes it disappears after some hours.

Bug#06 is gone with R145, device list is clean now at my testing.

Regards
Shardan

Martinus · #96 Post by **Martinus** » 20 Nov 2016, 16:07

R146_RC7 is available for download
http://www.letscontrolit.com/wiki/index ... candidates

Current status:

Bug #01 FIXED in R138 : Clock event at system boot issues
Bug #02 FIXED in R139 : Domoticz MQTT support was completely broken as of R109 (so it also affects R120!)
Bug #03 FIXED in R140 : I2C Scanner would not show PCF8574A at default address
Bug #04 FIXED in R141 : Pulsecounter value display style elements
Bug #05 FIXED in R141 : Some missing I2C scanner 'known devices'
Bug #06 FIXED in R145 : Task value name remains after clearing task
Bug #07 OPEN : Pulse counter total increases every second without pulse? - Unable to reproduce...
Bug #08 FIXED in R142 : Missing BMP180 in I2C scanner
Bug #09 FIXED in R142 : Missing MLX90614 in I2C scanner
Bug #10 FIXED in R412 : Intermittent issue getting NTP time during boot
Bug #11 FIXED in R145 : WDT crash using ADC/MQTT OpenHAB
Bug #12 CLOSED : R142 resets configuration - (Upgrade from R143 to R145 went fine on all my units)
Bug #13 CLOSED : IP display errors - erroneous bug report...
Bug #14 FIXED in R146 : Ser2Net RXwait would only work as expected when used on tasknr 1

Anyone else who suffers from bug #07? Starting to look like an erroneous bug report to me...

Martinus · #97 Post by **Martinus** » 20 Nov 2016, 16:09

Shardan wrote:Hello,
Up to now i thought it was my breadboard testing here causing trouble.

You're running a breadboard setup? Better finalize your project first and see it the issue persists. Use a NodeMCU or Wemos board, use short soldered wires and then check again.

beic · #98 Post by **beic** » 20 Nov 2016, 17:01

Martinus wrote: Anyone else who suffers from bug #07? Starting to look like an erroneous bug report to me...

Did not get any faulty reading trough kWH meter so far...

And can you please look at my post please and answer me?!

viewtopic.php?f=6&t=2107&start=80#p10959

Shardan · #99 Post by **Shardan** » 20 Nov 2016, 17:04

Martinus wrote:
Shardan wrote:Hello,
Up to now i thought it was my breadboard testing here causing trouble.
You're running a breadboard setup? Better finalize your project first and see it the issue persists. Use a NodeMCU or Wemos board, use short soldered wires and then check again.

I'm waiting for the ordered PCB's and then i'll see.
ATM it's running on R145 and doesn't reproduce the error.

frank · #100 Post by **frank** » 21 Nov 2016, 11:01

i just updatet to version 146 it seems to work fine. The question i have is after rebooting the unit automaticly goes back to the update screen. Is it possible to make a go back to the main screen button in the update screen? Or make it go back to the main screen after reboot

beic · #101 Post by **beic** » 21 Nov 2016, 12:08

frank wrote:The question i have is after rebooting the unit automaticly goes back to the update screen. Is it possible to make a go back to the main screen button in the update screen? Or make it go back to the main screen after reboot

+1 thumbs for that!

cherowley · #102 Post by **cherowley** » 22 Nov 2016, 16:20

grhhm wrote:Hello,

Seems, this is a bug report for release 140. If I am posting to wrong topic, please, point me to correct one.

The ESP module with release 140 runs MQTT publishing of HTU21, BMP180, and light sensors. It works fine (missing some reports, not a concern here).
After 2-3 hours of work it is impossible to dial into ESP module from browser. No response at all. No ping to ESP. MQTT publishing still works.

Power cycle of the ESP renews the HTTP access to it for additional 2-3 hours.

Thank you.

I have this (not using mqtt though), sometimes after awhile they start responding again, sometimes not?!

papperone · #103 Post by **papperone** » 22 Nov 2016, 17:50

cherowley wrote:
grhhm wrote:Hello,

Seems, this is a bug report for release 140. If I am posting to wrong topic, please, point me to correct one.

The ESP module with release 140 runs MQTT publishing of HTU21, BMP180, and light sensors. It works fine (missing some reports, not a concern here).
After 2-3 hours of work it is impossible to dial into ESP module from browser. No response at all. No ping to ESP. MQTT publishing still works.

Power cycle of the ESP renews the HTTP access to it for additional 2-3 hours.

Thank you.
I have this (not using mqtt though), sometimes after awhile they start responding again, sometimes not?!

I experienced this just once and it happened after I had done some rewiring in my home network cabling; basically my modem was off for 2h while the wifi access point was alive but without any connection to the modem/router/dhcp; once all was back and connected with new cabling I realize all my ESPEasy units were working perfecting (all my system is based on MQTT protocol) but none was reachable via its web interface.
After reset all of them one by one everythign is back as it shoudl (this happened one week ago, and before that I was working with ESPEasy module in the last month without experiencing this phenomena).
I can only guess the web server of ESPEasy get somehow "broken" due to the outage of wifi network connection...

Haggycz · #104 Post by **Haggycz** » 22 Nov 2016, 20:20

papperone wrote:
cherowley wrote:
grhhm wrote:Hello,

Seems, this is a bug report for release 140. If I am posting to wrong topic, please, point me to correct one.

The ESP module with release 140 runs MQTT publishing of HTU21, BMP180, and light sensors. It works fine (missing some reports, not a concern here).
After 2-3 hours of work it is impossible to dial into ESP module from browser. No response at all. No ping to ESP. MQTT publishing still works.

Power cycle of the ESP renews the HTTP access to it for additional 2-3 hours.

Thank you.
I have this (not using mqtt though), sometimes after awhile they start responding again, sometimes not?!
I experienced this just once and it happened after I had done some rewiring in my home network cabling; basically my modem was off for 2h while the wifi access point was alive but without any connection to the modem/router/dhcp; once all was back and connected with new cabling I realize all my ESPEasy units were working perfecting (all my system is based on MQTT protocol) but none was reachable via its web interface.
After reset all of them one by one everythign is back as it shoudl (this happened one week ago, and before that I was working with ESPEasy module in the last month without experiencing this phenomena).
I can only guess the web server of ESPEasy get somehow "broken" due to the outage of wifi network connection...

Hello,
i have exactly the same issue as cherowley, im using separate wifi for domoticz, which can access intranet - where is the Windows Domoticz server(updated to latest)+Wemos D1 mini boards publishing via http domoticz, i have 3pcs of R120(i started on this)+2pcs R140, and im experience the web-access issue; when web-access issue is ongoing & try to ping the problem device, i receive this:
#ping 192.168.1.253 (R120 Wemos esp8266)

Pinging 192.168.1.253 with 32 bytes of data:
Reply from 192.168.1.27: Destination host unreachable.
Reply from 192.168.1.27: Destination host unreachable.
Reply from 192.168.1.27: Destination host unreachable.

Ping statistics for 192.168.1.253:
Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),

.... this was happening to me like every several hours-, so i went to router, setup static ip assignement based on Wemoses MAC addresses, and well... now it can stay at least for several days without any problem. After while, it happen again, but it "repair" itself somehow mostly in next 2-3hours ... but when im near PC and i find out this issue re-occure again, i go to router, and have to change password to just random one...wait till all espeasy boards became APs, and then i change the password back again and voa-la ... working again for several days without issue...i mostly realize the issue is ongoing when the lights goes "light-on" little bit later... so... something wrong is happening, but boards are really slowly responsing - like ping 99999ms sometimes...

looking forward this successful project!

thank you guys...

Martinus · #105 Post by **Martinus** » 26 Nov 2016, 14:59

Current status:

Bug #01 FIXED in R138 : Clock event at system boot issues
Bug #02 FIXED in R139 : Domoticz MQTT support was completely broken as of R109 (so it also affects R120!)
Bug #03 FIXED in R140 : I2C Scanner would not show PCF8574A at default address
Bug #04 FIXED in R141 : Pulsecounter value display style elements
Bug #05 FIXED in R141 : Some missing I2C scanner 'known devices'
Bug #06 FIXED in R145 : Task value name remains after clearing task
Bug #07 OPEN : Pulse counter total increases every second without pulse? - Unable to reproduce...
Bug #08 FIXED in R142 : Missing BMP180 in I2C scanner
Bug #09 FIXED in R142 : Missing MLX90614 in I2C scanner
Bug #10 FIXED in R412 : Intermittent issue getting NTP time during boot
Bug #11 FIXED in R145 : WDT crash using ADC/MQTT OpenHAB
Bug #12 CLOSED : R142 resets configuration - (Upgrade from R143 to R145 went fine on all my units)
Bug #13 CLOSED : IP display errors - erroneous bug report...
Bug #14 FIXED in R146 : Ser2Net RXwait would only work as expected when used on tasknr 1
Bug #15 OPEN: ESP server processes (Web, ICMP) become unresponsive in certain environments under certain conditions? - Unable to reproduce...

We were almost looking at a new stable until reports were received that lead to bug report #15. This is a very nasty one, as i can't reproduce it in my own environment (using >20 rock-solid modules). But if ESP Easy somehow intermittently looses the web-server process, it becomes a useless device. And it will make no sense for any further development on unreliable firmware.

Up until now, we only have limited reports on this presumed bug. We likely have several hundreds (?) of users and only 5 individuals have reported on this.
To get a better picture, we would also need positive reports, so i would like everyone to report their findings on reliability of the webgui and ICMP ping on their units.

Please provide information like this:
- Stable webgui/ICMP ping:
- ESP Hardware:
- Firmware used:
- Stock binary image or custom:
- Controller type/version:
- DHCP/fixed IP:
- Node list active?:
- Do these unreliable units also drop from the node list?:
- Connected devices:
- Wifi router/AP:
- Issues after router reboot?:

My own report as a sample:
- Stable webgui/ICMP ping: Yes
- ESP Hardware: NodeMCU V1, Wemos D1 mini
- Firmware used: R146
- Stock binary image or custom: Stock binaries on all modules
- Controller type/version: Domoticz V3.5864
- DHCP/fixed IP: All fixed IP
- Node list active?: Yes
- Do these unreliable units also drop from the node list?: N/A
- Connected devices: DS18B20, LDR, LCD, OLED, SI7021, RFLink
- Wifi router/AP: Linksys E3000 with DD-WRT firmware
- Issues after router reboot?: No

Limited feedback so far:

Reported as issue:
- grhhm, 16-11, using MQTT
- Shardan, 17-11, not using MQTT (breadboard setup?)
- Cherowly, 22-11, not using MQTT
- Haggycz, 22-11, not using MQTT

Reported as NON issue:
- papperone, 17-11, using MQTT

Statistics: 4 to 1 (80% reported as bug)

BertB · #106 Post by **BertB** » 26 Nov 2016, 16:13

Please provide information like this:
- Stable webgui/ICMP ping: Yes, but I do not ping (I know Domoticz can do this)
- ESP Hardware: NodeMCU, Wemos D1, ESP12E
- Firmware used:146
- Stock binary image or custom: I compile binaries from downloaded repositories.
- Controller type/version: Domoticz V3.5877 and V3.5983
- DHCP/fixed IP:Fixed
- Node list active?:Yes
- Do these unreliable units also drop from the node list?:No unreliable units
- Connected devices:RFLINK, 18B20,OLED SSD1306, BH1750, BMP 085, Nextion, DHT22, PCF8574, Relays, Switches
- Wifi router/AP: Sitecom X8 AC1750 and Netgear WN3100 RP range extender
- Issues after router reboot?: No

Only with the ESPEay (WeMos/RFLINK) I have the issue that after software update or router reboot, Domoticz cannot connect. I have to disable the RFLINK hardware in Domoticz and enable it again. In the Domoticz log, it looks like this:

----
2016-11-26 15:44:33.342 RFLink: trying to connect to 192.168.0.75:23
2016-11-26 15:44:39.143 Hardware Monitor: Fetching data (System sensors)
----
2016-11-26 15:45:09.198 Hardware Monitor: Fetching data (System sensors)
2016-11-26 15:45:17.347 RFLink: TCP/IP Worker stopped...
2016-11-26 15:45:21.631 (PVOutput) General/Percentage (SolarEff)
2016-11-26 15:45:22.821 RFLink: trying to connect to 192.168.0.75:23
2016-11-26 15:45:22.903 (PVOutput) General/kWh (SolarMain)
2016-11-26 15:45:23.821 RFLink: connected to: 192.168.0.75:23
----

papperone · #107 Post by **papperone** » 26 Nov 2016, 16:49

- Stable webgui/ICMP ping: YES / no packet loss
- ESP Hardware: Wemos D1 Mini (around 20 of them)
- Firmware used: 140/146
- Stock binary image or custom: Custom compiled (I use "MQTT Import" plugin)
- Controller type/version: OpenHAB MQTT - Raspberry running Mosquitto/NodeRed latest versions
- DHCP/fixed IP: DHCP (fixed at the routed using Mac Addr lockup)
- Node list active?: YES
- Do these unreliable units also drop from the node list?: not able to reproduce
- Connected devices: physical push buttons, relays, DS18B20, DHT22, LEDs
- Wifi router/AP: Sitecom X4N300
- Issues after router reboot?: NO

As explained beofre the only time I had this phenomena was during a voluntary outage of my home network due to rewiring...
I tried to reproduce it disconnecting the VDSL Modem, as well to disconnect the Access Poitn but I was unale to...

hvdwolf · #108 Post by **hvdwolf** » 27 Nov 2016, 09:39

- Stable webgui/ICMP ping: YES / no packet loss
- ESP Hardware: 2x Nodemcu 1.0, 2X Nodemcu 0.9
- Firmware used: 146
- Stock binary image or custom: Custom compiled with Pimatic REST-API _C022.ino and my own WebServer.ino patch for uptime display (like: Uptime: 2 days 21 hours 18 minutes)
- Controller type/version: Pimatic REST-Api to Pimatic 0.9 on RPi3 B
- DHCP/fixed IP: All STATIC on nodemcu outside DHCP range router
- Node list active?: YES
- Do these unreliable units also drop from the node list?: not able to reproduce
- Connected devices: relays, DS18B20, PIR motion sensors (1 dedicated relay nodemcu, others multi-functional with sometimes cables up to 5-6 meter)
- Wifi router/AP: Cisco epc3928 (Ziggo); one Linksys E4200 in bridge mode -> 3 nodemcus connected to cisco, 1 to linksys
- Issues after router reboot?: NO
- NTP: All using NTP (nl.pool.ntp.org) with DST and time offset, no issues observed

Note: before I had 143, 142 and 140. For my used purposes no issues observed either.

grhhm · #109 Post by **grhhm** » 27 Nov 2016, 11:05

Martinus wrote:Bug #15 OPEN: ESP server processes (Web, ICMP) become unresponsive in certain environments under certain conditions? - Unable to reproduce...

Reported as issue:
- grhhm, 16-11, using MQTT
- Shardan, 17-11, not using MQTT (breadboard setup?)
- Cherowly, 22-11, not using MQTT
- Haggycz, 22-11, not using MQTT

Reported as NON issue:
- papperone, 17-11, using MQTT

Statistics: 4 to 1 (80% reported as bug)

Martinus, I've encountered non-responsive HTTP server in ESP Easy about a month before reporting. Then I was using HTTP RESP API reporting to Thingspeak. I thought maybe HTTP stack is too heave for ESP so I switched to lightweight MQTT communication.
Bottom line, the protocol of transmission does not affect the ESP8266 internal server in positive or negative way. Maybe this will help to pin the bug.
Thank you.

ToniA · #110 Post by **ToniA** » 27 Nov 2016, 12:31

Seems that my brother has the same unresponsiveness problem. He's running Wemos D1 mini with ESPEasy R140. After a while it just becomes unresponsive, does not answer to ping. But it for example continues to report measurements to Emoncms, and there's nothing strange on the terminal. He brough the device to my place, and here it worked just fine. The difference is that he's running on a Huawei B315 4G router, whereas I have an old Linksys WRT54GL on DD-WRT firmware. Oh yes, he's not running MQTT, but reporting to Emoncms.

Martinus · #111 Post by **Martinus** » 27 Nov 2016, 14:43

The reports on ThingSpeak and EmonCMS got me triggered on issues that could be caused by the large (15000 mS) delay used for these services.
I was able to reproduce severe network disruption using a 10 second sensor delay with a 15 second message delay and UDP traffic enabled.
In this particular scenario the ESP Easy uses 'background' processing during the delay and UDP messages were not processed causing network buffer issues.

R147 is fixed for this particular scenario, handling UDP traffic also in background. It should also fix the scenario's where large delays are used in the rule engine.
This may not be the root cause for the reported issues, but it clearly shows that the server processes can fail when the ESP Easy gets to busy doing a lot of stuff without attending to background tasks.

Since we have a non-preemptive multitasking environment, these situations can also occur in other places in the framework or plugins. A higher than usual system load could indicate situations that may need attention.

R147 also adds "system load" to the sysinfo plugin so you could report this to Domoticz or other controller. Or use %sysload% in your LCD template if you have an LCD or OLED connected to your ESP.

ToniA · #112 Post by **ToniA** » 27 Nov 2016, 20:14

I just visited my brother this evening... We put in the R147_RC8, and no change in stability. Not even if we put it in 'Standalone' mode, i.e. not talking to any controller. I'm still wondering if there's something wrong with his router, as the same Wemos device was working just fine in my network, even when connected to EmonCMS. I haven't had a single problem myself, and I've tried a really large bunch of Wemos D1 minis (~80 pieces so far).

hamster · #113 Post by **hamster** » 27 Nov 2016, 20:30

I've just been trying to update to r147 from 146 using OTA , but fails at 80% every time. anyone else with the same issue?

this is happening on 5 different ESP's when I flash OTA from 146 to 147
at 80% fails

on boot the logs show the following

308 : INIT : Booting Build nr:146
1195 : WIFI : Connecting... 1
5204 : WIFI : Connected!
5205 : INIT : I2C
5205 : INIT : SPI not enabled
5208 : INIT : Boot OK
5208 : INIT : Reboot from deepsleep

????

hvdwolf · #114 Post by **hvdwolf** » 27 Nov 2016, 21:04

No. I just updated 2 of my Esps via OTA (after a trial update via OTA on a spare Esp).
Sorry I can't help you but at least it is not reproducable.

BertB · #115 Post by **BertB** » 27 Nov 2016, 22:05

Seems that WeMos with 147 and ONLY ser2net and RFLINK becomes irresponsive. I picked 147 from the Github, while it stated updated 21 hour ago.

pwassink · #116 Post by **pwassink** » 28 Nov 2016, 09:29

Not sure where to post this, but its happening on a release-candidate, so this might be the place.

Up from version 1.44 rc i had several times that with very stable weather the temperature will differ about 2 centigrade a couple
of times right after each other up/down like a saw tooth with 5 minutes sample time in Domoticz.
The sensor is a single Ds18b20, placed outside the house, not direct in the wind and covered up from above so no dew directly.
last weekend i made the 1.47 updated versions and upgraded that nodemcu with Esp12, bot this night around 02:00 it happened again.

anyone seen those same weard hicks ?

cherowley · #117 Post by **cherowley** » 29 Nov 2016, 13:57

Hi Martinus,

I've had these problems for a while, dating back to 120 I think but not 100%...

Happens with http and mqtt.

Forgot to say, even though when it happens I can't ping and can't access the web page, issuing http commands to the esp still works (no confirmation response though).

- Stable webgui/ICMP ping: No/ Yes (but fluctuates widely)
- ESP Hardware: sonoff, wemos d1-mini, nodemcu
- Firmware used: 120-140
- Stock binary image or custom: custom
- Controller type/version: domoticz http & mqtt
- DHCP/fixed IP: both
- Node list active?: yes
- Do these unreliable units also drop from the node list?: yes
- Connected devices: relay, oled
- Wifi router/AP: router
- Issues after router reboot?: not tested

beic · #118 Post by **beic** » 29 Nov 2016, 18:27

Didn't found any issues yet, using more ESP units at the same time...

- Stable webgui/ICMP ping: YES / No packet loss
- ESP Hardware: ESP-01 and ESP-01S Barebone (black version = 1Mb)
- Firmware used: 146
- Stock binary image or custom: Custom compiled from GitHub (only iternal VCC customisation)
- Controller type/version: Domoticz HTTP / v3.5923
- DHCP/fixed IP: DHCP (fixed at the routed using MAC Address lockup)
- Node list active?: Yes
- Do these unreliable units also drop from the node list?: Not able to reproduce
- Connected devices: OLED, LCD16x2, BME280, BH1750, SI7021
- Wifi router/AP: TP-Link TP-WA500G, TP-Link TP-WA500G and IPCop Router
- Issues after router reboot?: Not tested

Regards

Shardan · #119 Post by **Shardan** » 29 Nov 2016, 18:42

Even my "unstable by definition" breadboard testing is running now without any issues for more then 50 hours.

- Stable webgui/ICMP ping: Yes / No packet loss
- ESP Hardware: NodeMCU V2.0 / ESP12E
- Firmware used: 147
- Stock binary image or custom: Custom compiled, no changes
- Controller type/version: Standalone
- DHCP/fixed IP: DHCP (fixed by DHCP server MAC -> IP)
- Node list active?: Yes
- Do these unreliable units also drop from the node list?: Not able to reproduce
- Connected devices: OLED, GP2Y10, GPIOs controling signaling LEDs and fan
- Wifi router/AP: Ubiquity UAP-AC-LR
- Issues after router reboot?: Not tested

Regards
Shardan

sla · #120 Post by **sla** » 29 Nov 2016, 19:08

Hello all,

need help guys. i'm using rules to push value to dummy device f.e.:

On System#Boot do
timerSet,1,5
endon
On Rules#Timer=1 do
TaskValueSet 1,1,-4.99
timerSet,1,5
endon

if i try positive value everything works ok, but with negative i get some recalculation on esp and i get -3. Log result:

580179 : EVENT: Rules#Timer=1
580183 : ACT : TaskValueSet 1,1,-4.99
580187 : ACT : timerSet,1,5
595102 : EVENT: test#Dummy=-3.00
595107 : EVENT: test#=0.00
595111 : EVENT: test#=0.00
595115 : EVENT: test#=0.00

probably there are some points with syntax or some other know how isues, please replay if you know the answer. Thanks.
same on 120 137 147 builds

Martinus · #121 Post by **Martinus** » 01 Dec 2016, 16:00

sla wrote:Hello all,

need help guys. i'm using rules to push value to dummy device f.e.:

On System#Boot do
timerSet,1,5
endon
On Rules#Timer=1 do
TaskValueSet 1,1,-4.99
timerSet,1,5
endon

if i try positive value everything works ok, but with negative i get some recalculation on esp and i get -3. Log result:

580179 : EVENT: Rules#Timer=1
580183 : ACT : TaskValueSet 1,1,-4.99
580187 : ACT : timerSet,1,5
595102 : EVENT: test#Dummy=-3.00
595107 : EVENT: test#=0.00
595111 : EVENT: test#=0.00
595115 : EVENT: test#=0.00

probably there are some points with syntax or some other know how isues, please replay if you know the answer. Thanks.
same on 120 137 147 builds

This is a confirmed bug. It looks like calculation goes wrong when there's actually nothing to calculate in case of negative values.

A workaround is to substract the negative value from zero. So this one gives the right result:

TaskValueSet 1,1,0-4.99

Martinus · #122 Post by **Martinus** » 01 Dec 2016, 16:10

Current status:

Bug #01 FIXED in R138 : Clock event at system boot issues
Bug #02 FIXED in R139 : Domoticz MQTT support was completely broken as of R109 (so it also affects R120!)
Bug #03 FIXED in R140 : I2C Scanner would not show PCF8574A at default address
Bug #04 FIXED in R141 : Pulsecounter value display style elements
Bug #05 FIXED in R141 : Some missing I2C scanner 'known devices'
Bug #06 FIXED in R145 : Task value name remains after clearing task
Bug #07 OPEN : Pulse counter total increases every second without pulse? - Unable to reproduce...
Bug #08 FIXED in R142 : Missing BMP180 in I2C scanner
Bug #09 FIXED in R142 : Missing MLX90614 in I2C scanner
Bug #10 FIXED in R412 : Intermittent issue getting NTP time during boot
Bug #11 FIXED in R145 : WDT crash using ADC/MQTT OpenHAB
Bug #12 CLOSED : R142 resets configuration - (Upgrade from R143 to R145 went fine on all my units)
Bug #13 CLOSED : IP display errors - erroneous bug report...
Bug #14 FIXED in R146 : Ser2Net RXwait would only work as expected when used on tasknr 1
Bug #15 OPEN: ESP server processes (Web, ICMP) become unresponsive in certain environments under certain conditions?
Bug #16 OPEN: using single negative values in formulas produce wrong values

Bug #15 Feedback so far:

Reported as issue:
- grhhm, 16-11, MQTT
- Shardan, 17-11, no MQTT (breadboard setup?)
- Cherowly, 22-11, no MQTT
- Haggycz, 22-11, HTTP-Domoticz
- Tonia's brother, 27-11, EmonCMS, Huawei B315 4G

Reported as NON issue:
- Martinus, 26-11, HTTP-Domoticz, Linksys E3000 with DD-WRT, -69dB (outside unit)
- papperone, 26-11, MQTT-OpenHAB
- BertB, 26-11, HTTP-Domoticz
- hvdwolf, 27-11, HTTP-Pimatic
- beic, 29-11, HTTP-Domoticz, TP-Link TP-WA500G
- Tonia, 27-11, EmonCMS, Linksys WRT54GL on DD-WRT
- Shardan, 29-11, Standalone, Ubiquity UAP-AC-LR

Statistics: 5 to 7 (42% reported as bug)
Still only 12 reports. Does this mean that we only have 12 ESP Easy users?

As Tonia reported, it could also somehow depend on the Wifi environment like type of router or maybe traffic, distance, etc...
(should we all move to DD-WRT

?)
I think it's interesting to also report the RSSI value in future posts.

I've just installed an additional Access Point (Dlink DIR 505) in my home and moved two ESP Easy unit's to that AP.
See what happens during the next couple of days...

JR01 · #123 Post by **JR01** » 01 Dec 2016, 19:37

Guilty as charged ! Will send detailed report, upgraded to 147 last night, have 2 x esp12F's, 3 x sonoffs, using mqtt (openhab) back to RPi, running Mosquitto, Node-Red. Will report back.
--- update -----
- Stable webgui/ICMP ping: 4 out of 1 is okay. One has missing pings, RSSI is -86 dB.
- ESP Hardware: 2 x ESP12F's, 3 x Sonoffs, flashed with 1MB & 64k spiffs.
- Firmware used: 147
- Stock binary image or custom: Compiled from GitHub (only changed wifi, and mqtt server ip)
- Controller type/version: Node-RED. v0.15.1
- DHCP/fixed IP:fixed IP's
- Node list active?: No.
- Do these unreliable units also drop from the node list?: Not able to reproduce
- Connected devices: DHT22, tipping bucket rain gauge, DS18b20 - 1-wire, relays.
- Wifi router/AP: D-Link ~ DSL-2750U
- Issues after router reboot?: Yes, the Sonoff's - after OTA flashing did not reboot, had to remove them, and flash with USB again.

Drum · #124 Post by **Drum** » 03 Dec 2016, 10:04

Martinus wrote: (should we all move to DD-WRT ?)
I think it's interesting to also report the RSSI value in future posts.

I've just installed an additional Access Point (Dlink DIR 505) in my home and moved two ESP Easy unit's to that AP.
See what happens during the next couple of days...

I just setup a new gl-mt300 with open-wrt in our new house and it is certainly far more responsive, or the ESPs were far more responsive. Unfortunately I am really too busy getting ready for the movers at the old house to do a lot of testing on it yet. With the 4 other APs I have it was frequently difficult to get a module to respond quick enough to turn off deepsleep to make changes in the time permitted after restarting. Of course this is a really small network with no internet, 4 to 6 devices total. 2 esps.

At best I am using R145 currently.

JR01 · #125 Post by **JR01** » 03 Dec 2016, 19:32

On what hardware does one run DD-WRT ?

ToniA · #126 Post by **ToniA** » 04 Dec 2016, 15:08

JR01 wrote:On what hardware does one run DD-WRT ?

http://www.dd-wrt.com/wiki/index.php/Supported_Devices

moelski · #127 Post by **moelski** » 06 Dec 2016, 20:16

Hi Martinus,

Bug #07 OPEN : Pulse counter total increases every second without pulse? - Unable to reproduce...

maybe this is the bug I´m having, too:
viewtopic.php?f=6&t=2377

BertB · #128 Post by **BertB** » 06 Dec 2016, 22:51

Off topic, no doubt, but what is the benefit of DD-WRT?

Shardan · #129 Post by **Shardan** » 07 Dec 2016, 12:00

Hello martinus,

there might be a bug in the ADS1115 sketch.
Even if my programming knowledge is near zero i did some testing.

See posts in viewtopic.php?f=5&t=2361

Regards
Shardan

ToniA · #130 Post by **ToniA** » 11 Dec 2016, 20:42

Speaking of stability, I now have a case where my customer has the first Wemos modules installed. He has a Huawei B593 4G router which is set to reboot twice a day (at 07:20 in the morning, and 16:20 in the afternoon) with a timer socket plug. The 4 Wemos's he has installed so far all disappear from the network at 04:20, and come back at 07:24 (after the router reboot). The ESPEasy main page says the uptime grows all the time, so the Wemos's are not down. ESPEasy is connected to Domoticz via MQTT, the Raspberry running Domoticz has a fixed IP address in the routers DHCP settings.

I wonder if there's something strange about the DHCP lease or something...

Lets see if this workaround in the ESPEasy rules is any good (at least a quick smoketest on a much smaller timer value rebooted it nicely):

Code: Select all

on System#Boot do
  timerSet,1,28800 // 6 hours
endon

on Rules#Timer=1 do
  reboot
endon

Who is online