ESP Easy next stable... (release candidates)

[papperone]

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]

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]

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]

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

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]

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]

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]

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]

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]

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

[Ton_vN]

@Toffel969

Perhaps kicking an open door, but do you apply for coverage of your premises 1 single Wifi-AP, or multiple APs, or 1*AP+repeaters?

Have the own experience that for a setup with physically wide-spread ESP8266s, 1 single AP/router is hardly sufficient to cover the premises.
Only the 2 other configurations (= 1*router + multiple APs OR 1*AP/router + multiple Repeaters) assure communication-coverage of sufficient strength, although the latter setup has the handicap of reduced capacity.

[Ton_vN]

See it nowhere (specificly) mentioned for inclusion in the next stable release:
UV/IR/Light-sensor type SI1145 included in the next release, or implementation to be continued by the ino-file?

[mrwee]

@Toffel969

Perhaps kicking an open door, but do you apply for coverage of your premises 1 single Wifi-AP, or multiple APs, or 1*AP+repeaters?

Have the own experience that for a setup with physically wide-spread ESP8266s, 1 single AP/router is hardly sufficient to cover the premises.
Only the 2 other configurations (= 1*router + multiple APs OR 1*AP/router + multiple Repeaters) assure communication-coverage of sufficient strength, although the latter setup has the handicap of reduced capacity.

I have 3 AP's on a Cisco 2504 covering our house + most of the 1000m2 garden (Probably need 4 to have full coverage)

[Shardan]

Hello,

this may depend on your WiFi AP too.
I'm using a single Ubiquiti Unifi AC-Pro at home and three at my company - they cover quite a big range.
These are quite expensive, but using "small" or cheap AP's showed me decreased connectivity and speed.

Regards
Shardan

[toffel969]

@Toffel969

Perhaps kicking an open door, but do you apply for coverage of your premises 1 single Wifi-AP, or multiple APs, or 1*AP+repeaters?

Have the own experience that for a setup with physically wide-spread ESP8266s, 1 single AP/router is hardly sufficient to cover the premises.
Only the 2 other configurations (= 1*router + multiple APs OR 1*AP/router + multiple Repeaters) assure communication-coverage of sufficient strength, although the latter setup has the handicap of reduced capacity.

I tried with an additional AP, both in AP and repeater mode. Best was AP mode, I never got the repeating mode to be stable (ASUS RT12-N). Anyway my solution to shield the router in unwanted direction (aluminium plate) und reflect it in desired direction. together with alive checker from domoticz its very stable now

[jbaumann]

Is it possible to enable the additional GPIOs for ESP8285 builds automatically, or at least manually using a flag? Currently it seems hardcoded to me.

Cheers, Joachim