ESP Easy next stable... (release candidates)

Message

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

ian_gregory · #131 Post by **ian_gregory** » 18 Dec 2016, 15:22

I think I've found a bug in the "serialsend" command if the bytes to be sent contain a null (i.e. 0x00).

I'm using an LC Technology 12v relay board which contains an ESP-01 which controls the relay by sending commands over serial to a "mother" board which decodes them with a PIC which then drives the relay coil.

I was able to turn the relay on and off using the "ser2net" feature - sending A0 01 01 A2 to the TCP socket turns the relay on, sending A0 01 00 A1 turns it off.

However, I wanted to use MQTT. I could only turn the relay ON using the serialsend command over MQTT. i.e.

This works:
echo -n -e 'mosquitto_pub -t esp-relay-01/cmd -m serialsend,\xA0\x01\x01\xA2'| sh

This doesn't:
echo -n -e 'mosquitto_pub -t esp-relay-01/cmd -m serialsend\xA0\x01\x00\xA1'| sh

Looking at the code for _P020_Ser2Net, it appears that the command being sent is held as a string. I think the 0x00 in the middle of the OFF command is being treated by espeasy as a null termination character, thus the whole command is not being output to the serial port.

I think the fix is to treat the command as a byte array rather than a string but don't know the code well enough to tackle it myself.

EDreamZ · #132 Post by **EDreamZ** » 24 Dec 2016, 19:36

Martinus wrote: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...

Hi all and merry christmas,

i want to share with you my experience, should be related to Bug #15...i have 10 devices in my network divided in ESP12, SONOFF and POW, all loaded with R120, networking is hosted from a cisco AP with a cisco ROUTER in cascade. Every device have its own setup and works very good with local tasks, when i try to "switch" a remote device with a SendTo command, sometime it works, sometime it doesn't.

i found that sometimes randomly, nodes disappear from the Node List of the main page, also if they are still online and reachable from the network via IP...i've also found a workaround for it...if i put a continuosly ping to every node from my pc...all nodes appear stable in all Node List of each device...

should be a Bug ? a network related problem ? Or am i wrong something in the configuration ?

Thanks in advance and sorry for my english...
Giuseppe

beic · #133 Post by **beic** » 24 Dec 2016, 20:24

These two I2C board are not working together, no matter what you will do!

PCF8574 I/O Expansion Board (chip PCF8574T)

and

I2C LCD 1602 Inerface board (chip PCF8574T)

Please advise!

Kind regards,
Viktor

Shardan · #134 Post by **Shardan** » 24 Dec 2016, 20:50

Related to Bug#15

I have this Bug again....
It comes up under the following conditions:

- ESPEasy has an admin password set
- Working on some configuration
- wait a while until it should ask password again

Webservice gone until restart.

FHEM home control (sending commands, receiving data) still works, serial monitoring still works, just web is gone.

If I remove the password everything works as expected.

Merry Christmas to all of you
Shardan.

jbaumann · #135 Post by **jbaumann** » 27 Dec 2016, 18:26

Hi,

I have a problem with reading a BME280-sensor via I2C. I'm using GPIO-1 and GPIO-3 (TX and RX) after having disabled serial, but I get no readings. The sensor itself works without problems on an Arduino with sensible values.

Interestingly, I get the information that a device is connected on address 0x77, which is the correct address.

I'm testing on 146, but I believe nothing has changed in this area between 146 and 147.

What can I do to narrow down the problem?

Cheers, Joachim

ananke · #136 Post by **ananke** » 29 Dec 2016, 06:38

jbaumann wrote:Hi,

I have a problem with reading a BME280-sensor via I2C. I'm using GPIO-1 and GPIO-3 (TX and RX) after having disabled serial, but I get no readings. The sensor itself works without problems on an Arduino with sensible values.

Interestingly, I get the information that a device is connected on address 0x77, which is the correct address.

I'm testing on 146, but I believe nothing has changed in this area between 146 and 147.

Check what it's detected as, in the tools->i2c scan. I'm guessing you're running into the same issue I had, and on the 0x77 address it's seen as another sensor type. After switching it to 0x76 on BME280, the sensor was detected by espeasy as BME280, and I got readings.

moelski · #137 Post by **moelski** » 29 Dec 2016, 08:19

Hi !

Just give the latest Github Version a try. I used Arduino 1.8.0 as IDE ...
It seems that there are some Problems with the MQTT Connection.
I get always this Messages in the logging:

Code: Select all

WD   : Uptime 8 ConnectFailures 30 FreeMem 23712
MQTT : Connection lost
MQTT : Connected to broker

followed by a new subscription to MQTT.

Has anyone else this Problem?

jbaumann · #138 Post by **jbaumann** » 29 Dec 2016, 23:49

I2C/BME280 Problems:

Ok, now I put the 147 onto the Sonoff device. On the plus side, I now can choose whether the address to use is 0x76 or 0x77, on the minus side, I no longer see the device when scanning. The device is still on address 0x77, the default when receiving the breakout board. Pullups are used as well. Do I really have to change the address?

Cheers, Joe

costo · #139 Post by **costo** » 31 Dec 2016, 12:59

A small bug seems to exists in R147 (and earlier versions too).
In the Firefox browser I get an error message after I give a url command like this:

http ://192.168.178.111/control?cmd=GPIO,4,0 or http ://192.168.178.111/control?cmd=PWM,4,10

I get this message before the normal response while the command is still executed in the normal way:

There was an error parsing the JSON document. The document may not be well-formed.
expected ',' or '}' after property value in object at line 2 column 15

after the message the command is properly executed so it is just a warning.
Apparantly the FF-browser likes to see the comma punctuation mark right after the pinnumber and before the statevalue.
In the Chromium browser I do not see this errormessage.

B.t.w. I only use linux versions of the browsers, I did not test this on windows or Mac versions.

BertB · #140 Post by **BertB** » 31 Dec 2016, 13:45

jbaumann wrote:I2C/BME280 Problems:

Ok, now I put the 147 onto the Sonoff device. On the plus side, I now can choose whether the address to use is 0x76 or 0x77, on the minus side, I no longer see the device when scanning. The device is still on address 0x77, the default when receiving the breakout board. Pullups are used as well. Do I really have to change the address?

Cheers, Joe

I2C works okay for me on a WeMos D1 on Rx and Tx ports, but it is important to reboot after changing the ports.

papperone · #141 Post by **papperone** » 31 Dec 2016, 18:47

costo wrote:A small bug seems to exists in R147 (and earlier versions too).
In the Firefox browser I get an error message after I give a url command like this:

http ://192.168.178.111/control?cmd=GPIO,4,0 or http ://192.168.178.111/control?cmd=PWM,4,10

I get this message before the normal response while the command is still executed in the normal way:
There was an error parsing the JSON document. The document may not be well-formed.
expected ',' or '}' after property value in object at line 2 column 15
after the message the command is properly executed so it is just a warning.
Apparantly the FF-browser likes to see the comma punctuation mark right after the pinnumber and before the statevalue.
In the Chromium browser I do not see this errormessage.

B.t.w. I only use linux versions of the browsers, I did not test this on windows or Mac versions.

On Windows 7 (x64) using FF 50.1.0 I can confirm it works perfectly without that message, so maybe it's only linux version related...

jbaumann · #142 Post by **jbaumann** » 04 Jan 2017, 13:47

BertB wrote:
jbaumann wrote:I2C/BME280 Problems:

Ok, now I put the 147 onto the Sonoff device. On the plus side, I now can choose whether the address to use is 0x76 or 0x77, on the minus side, I no longer see the device when scanning. The device is still on address 0x77, the default when receiving the breakout board. Pullups are used as well. Do I really have to change the address?

Cheers, Joe
I2C works okay for me on a WeMos D1 on Rx and Tx ports, but it is important to reboot after changing the ports.

Perfect. That was the missing information. After rebooting using the correct I2C-pin-configuration and giving it a non-zero delay it works like a charm.

Thanks a lot

jongerenchaos · #143 Post by **jongerenchaos** » 05 Jan 2017, 20:57

There is a MQTT bug in this version. When you use domoticz incombination with ESPEASY it works ok for the maximum IDX +- 600. When you have a higher number (added in domoticz), the ESPEASY module does nothing with these commands from domoticz. With a previous version (like 82) it works well also with higher IDX domoticz numbers .

timsson · #144 Post by **timsson** » 08 Jan 2017, 10:53

.. [s] status gpio,2 - not working correct....[/s]

sorry my faulty - i don't set the status firstly:
gpio,2,1 and then
status gpio,2
it work's - sorry

paxi · #145 Post by **paxi** » 02 Feb 2017, 01:53

Martinus wrote:Bug #15 Feedback so far:

....

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

Excuse for complaining about bugs in my first post.

I really enjoy this software and appreciate your effort.

You can somehow add me to the list for #15:
I have 3 Sonoff's in use, only generic HTTP without a central server. One of them becomes unresposive after a random timespan - it seems to begin with the web interface (not responding or loading pages only partially), at this point its possible to issue a reboot command via http. If I miss that point the device becomes completely unresposive and needs a power cycle.
Interesting point is all devices are from the same batch, all run R120 and in the same environment - literally only meters apart. Thus I think it's save to conclude #15 is not environment-related.

I'm not 100% sure but the affected device might be the one I've tried OTA flashing to R147_RC8 which failed and flashed back to R120 via serial port. I did not try to factory-reset it yet but my suspicion goes to some residual data in the flash memory as the cause.

Also I think there's another bug:
I use the PWM command to dim the Sonoff's LED which work flawless until I create a rule on Clock#Time, then the dimmed LED flashes brighter for a brief moment exactly every minute. Somehow the PWM value or pin state seems to be re-written every minute if a time-dependent rule is set (but not triggered).
This is a minor annoyance for a LED but may become serious if a lamp or some other "heavy" load is controlled by PWM, it happens in R120 and also in R147_RC8. Haven't tested servo control but since servos also use PWM that may be affected as well.

Here are the rules, "State" is a dummy device to store LED brightness and relay state:

Code: Select all

//ceiling lamp with sonoff

on switchon do
    TaskValueSet 2,2,1 //State#Relay=1
    gpio 12,1                  //Relay on
    pwm 13,1024          //LED off (pin low = LED on) 
endon

on switchoff do
    TaskValueSet 2,2,0          //State#Relay=0
    gpio 12,0                           //Relay off
    pwm 13,[State#Bright] //LED on
endon

on Button#Switch do //not really needed, pushbutton is hidden in lamp
    if [Button#Switch]=1
        TaskValueSet 1,1,0 //set switch to 0, avoids double press if event was triggered remotely
        event switchon
    else
        event switchoff
    endif
endon

on System#Boot do
    if[Clock#Time]>7:59
        TaskValueSet 2,1,500 //LED medium brightness
    endif
    if[Clock#Time]>19:59
        TaskValueSet 2,1,990 //LED dim 
    endif
    event switchon
endon

on Clock#Time=All,20:00 do //dim LED at night
    TaskValueSet 2,1,990
    If [State#Relay]=0
        PWM 13,990,5000
    Endif
endon

on Clock#Time=All,8:00 do //medium LED at day
    TaskValueSet 2,1,500
    If [State#Relay]=0
        PWM 13,500,5000
    Endif
endon

paxi · #146 Post by **paxi** » 02 Feb 2017, 23:33

Update to the post above:

Re #15 I've tried factory reset (tx/rx shorted on boot), full erase by flashing 1MB of 0xFF and soldering a 10uF cap close to the ESP - to no avail, this unit still hangs sometimes while the other 2 Sonoff's run solid.

Re the PWM-flickering issue I found that it's not related to clock#time, without such rules and even NTP disabled it still flashes every minute - there seems to be a "heartbeat" somwhere deep in the code.

beic · #147 Post by **beic** » 03 Feb 2017, 07:57

paxi wrote:Update to the post above:
this unit still hangs sometimes while the other 2 Sonoff's run solid.

Did you consider maybe that one device is hardware damaged as new from factory?

Kind regards,
Viktor

paxi · #148 Post by **paxi** » 03 Feb 2017, 10:51

Yes I did. Now that you mention it I remember having a hard time setting up this specific unit with the original firmware.
Btw. when it becomes unresponsive on the WiFi interface it still reacts to the pushbutton.

Too late to claim a refund, I'll give up on this one...

matzej · #149 Post by **matzej** » 08 Feb 2017, 22:04

Hi Guys,

great work you did on the esp, just discovered the project a week ago!
Have the following setup @home, mostly knx, homebridge with knx support.
now i want the esp for S0 pulsecount and some temperature stuff.
For that i have setup mqtt broker and Domoticz for visualisation.

I started with R120, because auf the Bug #2 you mentioned (i think i hit that with my setup) i updated to R148.
But some part of the is bug still there, i think.

I have checked with 3 boards, the values of the Pulsecounter are always empty:

Code: Select all

Log
935760 : UDP : Send Sysinfo message
938150 : DHT : Temperature: 21.50
938150 : DHT : Humidity: 46.20
938151 : {"idx":9,"nvalue":0,"svalue":"21.5;46.2;0"}
939129 : HTTP : Delay 66 ms
939195 : {"idx":3}
942828 : UDP : a0:20:a6:12:4c:da,192.168.2.241,1
954733 : UDP : a0:20:a6:12:1e:bc,192.168.2.243,3
965761 : WD : Uptime 16 ConnectFailures 0 FreeMem 26512
965761 : UDP : Send Sysinfo message

idx3 is the Pulsecounter, idx9 a DHT22. the dht22 is working, pulsecounter not, on another board i have several dallas DS18b20, al sending the right stuff to mqtt. Just wanna add that the esp webpage shows count, total and time values.

2nd: syslog is not working! setup syslog server ip on esp, on my syslog server nothing arrives (according to wireshark).

If you need any furhter logs, information, dont hesitate to contact me.

regards Matze

toffel969 · #150 Post by **toffel969** » 10 Feb 2017, 18:38

EDreamZ wrote:
Martinus wrote: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...
Hi all and merry christmas,

i want to share with you my experience, should be related to Bug #15...i have 10 devices in my network divided in ESP12, SONOFF and POW, all loaded with R120, networking is hosted from a cisco AP with a cisco ROUTER in cascade. Every device have its own setup and works very good with local tasks, when i try to "switch" a remote device with a SendTo command, sometime it works, sometime it doesn't.

i found that sometimes randomly, nodes disappear from the Node List of the main page, also if they are still online and reachable from the network via IP...i've also found a workaround for it...if i put a continuosly ping to every node from my pc...all nodes appear stable in all Node List of each device...

should be a Bug ? a network related problem ? Or am i wrong something in the configuration ?

Thanks in advance and sorry for my english...
Giuseppe

I can confirm same behaviour, both sonoff and nodemcus. Also used the same fix (continous ping every 5min). The weaker the WiFi Signal, the worse this behaviour (without ping) becomes.
However, it becomes even much worse if there are two units with same unit no, completely eratic

Who is online