ESP Easy next stable... (release candidates)

Message

Martinus · #51 Post by **Martinus** » 26 Oct 2016, 19:08

cherowley wrote:
Martinus wrote:Current bugstatus:

Bug #01 FIXED in R138 : Clock event at system boot issues
quote]

I'm not sure if it's related to the above but I'm still getting the problem whereby sometimes the clock is NOT set after boot in version 140.

Can't detect a pattern - seems random.

Sometimes enabling/disabling the use ntp feature and saving a few times with get it working..

This is different from bug #01 where it would never work because of a design issue.

Sometimes the NTP server does not reply, but in my network this is a rare condition. I'll see if a simple retry mechanism can be implemented to avoid failure on a single missed packet... Listed as bug #10, intermittent failure getting NTP time.

Martinus · #52 Post by **Martinus** » 26 Oct 2016, 19:51

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 OPEN : Task value name remains after clearing task? - Unable to reproduce...
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 OPEN : Intermittent issue getting NTP time during boot - maybe fixed in R142, need feedback...

cherowley · #53 Post by **cherowley** » 27 Oct 2016, 09:42

Martinus wrote:
cherowley wrote:
Martinus wrote:Current bugstatus:

Bug #01 FIXED in R138 : Clock event at system boot issues
quote]

I'm not sure if it's related to the above but I'm still getting the problem whereby sometimes the clock is NOT set after boot in version 140.

Can't detect a pattern - seems random.

Sometimes enabling/disabling the use ntp feature and saving a few times with get it working..
This is different from bug #01 where it would never work because of a design issue.

Sometimes the NTP server does not reply, but in my network this is a rare condition. I'll see if a simple retry mechanism can be implemented to avoid failure on a single missed packet... Listed as bug #10, intermittent failure getting NTP time.

Brilliant, cheers buddy!

Shall I give r142 a whirl then to see if it is fixed?

BTW I need the time and stuff as I've written a thermostat plugin to control my central heating and hot water. The basic temperature logic and time slot stuff is done on chip as I feel it is not good to rely on wifi and domoticz etc to host that - wife wouldn't be happy returning to either a cold house, no hot water or a house heated like the tropics lol!

When developing it I spent virtually a whole day trying to work out why my chips suddenly went unstable - turned out to be memory as soon as I remove some of the other plugins and controllers it was fine again

Not sure why as ram free reported with still "plenty" and the bin was under 430k!

Thought about taking the realtime battery backed up clocks arduino code that's floating around the net and maybe converting to a plugin but I suppose that stuff would really need integrating at a lower level into the main ino etc?

papperone · #54 Post by **papperone** » 27 Oct 2016, 11:09

as mentioned elsewhere, the footer of web interface should be changed to reflect the new domain (replace www.esp8266.nu with www.letscontrolit.com)

hvdwolf · #55 Post by **hvdwolf** » 27 Oct 2016, 18:34

Martinus wrote:Current status:
Bug #10 OPEN : Intermittent issue getting NTP time during boot - maybe fixed in R142, need feedback...

I flashed github 142 on a spare nodemcu 0.9 and rebooted now at least 15 times. Everything is fine!
settings:

Code: Select all

Ntp ->check
NTP host name: -> nl.pool.ntp.org
Timezone Offset: (Minutes)	60
DST:	 -> check

I'm new on the forum so maybe that's the reason I can't find it.
What is the exact issue? I can't find the issue/bug, not on github or in this forum. Is there a section somewhere describing these bugs?
Is it viewtopic.php?f=6&t=2160&p=10195&hilit=NTP#p10195 ?
ot this one: viewtopic.php?f=6&t=2001&p=9271&hilit=ntp#p9271

frank · #56 Post by **frank** » 29 Oct 2016, 19:28

cherowley wrote:
Martinus wrote:
cherowley wrote:
This is different from bug #01 where it would never work because of a design issue.

Sometimes the NTP server does not reply, but in my network this is a rare condition. I'll see if a simple retry mechanism can be implemented to avoid failure on a single missed packet... Listed as bug #10, intermittent failure getting NTP time.
Brilliant, cheers buddy!

Shall I give r142 a whirl then to see if it is fixed?

BTW I need the time and stuff as I've written a thermostat plugin to control my central heating and hot water. The basic temperature logic and time slot stuff is done on chip as I feel it is not good to rely on wifi and domoticz etc to host that - wife wouldn't be happy returning to either a cold house, no hot water or a house heated like the tropics lol!

When developing it I spent virtually a whole day trying to work out why my chips suddenly went unstable - turned out to be memory as soon as I remove some of the other plugins and controllers it was fine again Not sure why as ram free reported with still "plenty" and the bin was under 430k!

Thought about taking the realtime battery backed up clocks arduino code that's floating around the net and maybe converting to a plugin but I suppose that stuff would really need integrating at a lower level into the main ino etc?

is it possible that you publish your plugin? I am looking for some thing like your plug in but i am a noob in programming

Martinus · #57 Post by **Martinus** » 30 Oct 2016, 11:17

R142 firmware images are available as weekly RC update:
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 OPEN : Task value name remains after clearing task? - Unable to reproduce...
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 OPEN : Intermittent issue getting NTP time during boot - maybe fixed in R142, need feedback...
Bug #11 FIXED in R142 : Help buttons stopped working after moving to http://www.letscontrolit.com[/color]

Shardan · #58 Post by **Shardan** » 30 Oct 2016, 11:33

Hello Martinus,

compiled and flashed R142 and rebooted about 20 times, no ntp problems showed.

tozett · #59 Post by **tozett** » 31 Oct 2016, 08:08

BUG 10# NTP issues:

first mentioned: posting.php?mode=quote&f=6&p=10460#pr10460

Martinus wrote:
cherowley wrote:
Martinus wrote:Current bugstatus:

Bug #01 FIXED in R138 : Clock event at system boot issues
quote]
Sometimes the NTP server does not reply, but in my network this is a rare condition. I'll see if a simple retry mechanism can be implemented to avoid failure on a single missed packet... Listed as bug #10, intermittent failure getting NTP time.

still open: viewtopic.php?f=6&t=2107&p=10504&hilit=Bug+%2310#p10563

Martinus wrote: Bug #10 OPEN : Intermittent issue getting NTP time during boot - maybe fixed in R142, need feedback...

it has something to do with the waiting-routine for ntp.

i mentioned this some time ago here: viewtopic.php?f=6&t=2001&hilit=ntp

maybe it helps to avoid the blocking delay?!

i am a coding beginner, you have to polish my code example,
but i guess you can build a state machine to avoid to blocking delay.

my working example, somehow a rude code, but working.

thex · #60 Post by **thex** » 04 Nov 2016, 00:12

For me with 142 openHAB MQTT is not working with ADC
WDT triggers

Server is mosquitto ona a raspberry working fine with other devices.
Connection to the broker also seems to be fine

Code: Select all

ADC  : Analog value: 0
MQTT : Topic: /esp4/3volt/Analog
MQTT : Payload: 0.00

 ets Jan  8 2013,rst cause:4, boot mode:(3,6)

wdt reset
load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
v09826c6d
~ld

iron · #61 Post by **iron** » 04 Nov 2016, 14:41

Upgrading over the air from 140 to 142 last night reset my "live/test" device to defaults.
That did not happen when upgrading the same device from 120 to 140.

beic · #62 Post by **beic** » 04 Nov 2016, 15:45

iron wrote:Upgrading over the air from 140 to 142 last night reset my "live/test" device to defaults.
That did not happen when upgrading the same device from 120 to 140.

Updated 5 or 6 ESP-01 devices in the past few days from (R140 to R142 - R141 to R142) and no issue on my side (note: compiled by myself form Github source)!

Regards

hvdwolf · #63 Post by **hvdwolf** » 06 Nov 2016, 14:02

So far the it works OK for me, however I work with self compiled versions from the github.
I had a couple of versions of the 142 and now the 143 (so slightly off topic).

However, in all versions (I have a couple nodemcus running on those several versions), the ip address is not correct.

It displays:

Code: Select all

0.abc.def.ghi

The first segment is always 0 and not 192 (or whatever range you are on)

EDIT:
With the new R143 github build it gets even weirder. Now my ip adress and gateway address are all wrong.
And it is really in the webserver display as my node list does give the correct ip addresses.[/i][/size]

EDIT: Sorry. False alarm. Somehow my own change on the time display caused this.

Martinus · #64 Post by **Martinus** » 06 Nov 2016, 15:00

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 OPEN : Task value name remains after clearing task? - Unable to reproduce...
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 OPEN : Intermittent issue getting NTP time during boot - maybe fixed in R142, need feedback...
Bug #11 NEW : WDT crash using ADC/MQTT OpenHAB - Unable to reproduce...
Bug #12 NEW : R142 resets configuration - Needs testing, did not have this in my testlab...
Bug #13 NEW : IP display errors - Unable to reproduce...

hvdwolf · #65 Post by **hvdwolf** » 06 Nov 2016, 15:12

Martinus wrote:Current status:

Bug #13 NEW : IP display errors - Unable to reproduce...

I'm very sorry for the confusion. I was already debugging and our mails crossed.
As mentioned: It was my own fault. If I remove my code for displaying the time it works again. Beats me for now, but I will have a look.

Edit: Found. I changed the display of the uptime and my display string definition was too short, but everything runs and compiles fine. "In the old days" before 1996 (when I stopped with C) you would get an error if you tried to do this. I will also create a new pull request after the final release.

tozett · #66 Post by **tozett** » 07 Nov 2016, 08:48

Martinus wrote:Current status:

Bug #10 OPEN : Intermittent issue getting NTP time during boot - maybe fixed in R142, need feedback...

I gave some Feedback Here before. Didn't this help?

hvdwolf · #67 Post by **hvdwolf** » 07 Nov 2016, 10:07

tozett wrote:
Martinus wrote:Current status:

Bug #10 OPEN : Intermittent issue getting NTP time during boot - maybe fixed in R142, need feedback...

I gave some Feedback Here before. Didn't this help?

And so did I

Martinus · #68 Post by **Martinus** » 07 Nov 2016, 16:35

tozett wrote:
Martinus wrote:Current status:

Bug #10 OPEN : Intermittent issue getting NTP time during boot - maybe fixed in R142, need feedback...

I gave some Feedback Here before. Didn't this help?

I expected some feedback from "cherowly" because he mentioned the bug...

tozett · #69 Post by **tozett** » 08 Nov 2016, 08:22

Ahh, ok.
But May you want to change the ntp Code and eliminate the delay either way. ?

May cherowly (or me and some other) can Test afterwards hopefully this 'improvement'..?!

Martinus · #70 Post by **Martinus** » 12 Nov 2016, 15:50

tozett wrote:Ahh, ok.
But May you want to change the ntp Code and eliminate the delay either way. ?

May cherowly (or me and some other) can Test afterwards hopefully this 'improvement'..?!

ESP Easy comes full of delays as it was developed as a sensor that could not really care about small delays. In my network, the actual NTP get delay is really small:

Code: Select all

NTP  : NTP sync request:2
NTP  : NTP send to 185.27.174.7
NTP  : NTP replied: 14 mSec

Took only 14 milliseconds. And this happens once per hour. Changing the code to work async would require an additional persistent network socket, claiming network resources and valuable RAM from the already limited heap. The reason we wait for the answer is that we can simply open/close the socket within the function local scope. RAM is used from the stack and returned on exit. Besides all that, a very much used function like the webclient connection also waits for answers, delaying the main program loop for up to 200 mSec.

I'm afraid that if your application can't bear small delays, you may have to look after other solutions than ESP Easy. Or create a plugin that uses interrupts to handle time critical stuff. But beware that ISR handler routines can be tricky. Do not use IO blocking, flash access and store the routines in program RAM cache.

Martinus · #71 Post by **Martinus** » 12 Nov 2016, 16:32

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 OPEN : Task value name remains after clearing task? - Unable to reproduce...
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 OPEN : WDT crash using ADC/MQTT OpenHAB - Unable to reproduce...
Bug #12 OPEN : R142 resets configuration - Needs testing, did not have this in my testlab...
Bug #13 CLOSED : IP display errors - erroneous bug report...

I've seen a pull request that should solve #11 although i'm unable to see why it would crash in the first place.
The pull request addresses an unwanted situation so that will be included in the next RC anyway.

mgennip · #72 Post by **mgennip** » 12 Nov 2016, 20:09

Still a bug with the pulse counter....

%value%+3 works only for sending this value to Domoticz. +3 is not added to the value displayed on the Devices webpage.

Shardan · #73 Post by **Shardan** » 13 Nov 2016, 19:36

About Bug #6:

I have a similiar behavior with the name:
When removing a device the name remains in the device list.
I moved a GP2Y dust sensor from task 3 to task 1, setting the device field of task 3 to empty.
This was the result:

: Task name remains.jpg (89.32 KiB) Viewed 26310 times

I edited task 3 again, setting it to GP2y again, stored it and set it back to empty, stored again.
Now the Name field shows "DSP1" from the Display in Task2.

R144, compiled on Arduino IDE 1.6.11 with the given libraries.

Greetings,
Shard

Martinus · #74 Post by **Martinus** » 13 Nov 2016, 21:12

mgennip wrote:Still a bug with the pulse counter....

%value%+3 works only for sending this value to Domoticz. +3 is not added to the value displayed on the Devices webpage.

It's not a bug. The counter device presents the realtime internal ISR counters and this makes debugging counter status easier. But i'm aware that this also lead to confusion. Maybe we have to show both internal and reported values here.

Martinus · #75 Post by **Martinus** » 13 Nov 2016, 21:13

Shardan wrote:About Bug #6:

I have a similiar behavior with the name:
When removing a device the name remains in the device list.
I moved a GP2Y dust sensor from task 3 to task 1, setting the device field of task 3 to empty.
This was the result:

Task name remains.jpg

I edited task 3 again, setting it to GP2y again, stored it and set it back to empty, stored again.
Now the Name field shows "DSP1" from the Display in Task2.

R144, compiled on Arduino IDE 1.6.11 with the given libraries.

Greetings,
Shard

I had another look at the source and i think I've spotted the bug. Will try to fix it in R145

beic · #76 Post by **beic** » 13 Nov 2016, 23:36

Shardan wrote:About Bug #6:

I have a similiar behavior with the name:
When removing a device the name remains in the device list.
I moved a GP2Y dust sensor from task 3 to task 1, setting the device field of task 3 to empty.
This was the result:

Task name remains.jpg

I edited task 3 again, setting it to GP2y again, stored it and set it back to empty, stored again.
Now the Name field shows "DSP1" from the Display in Task2.

R144, compiled on Arduino IDE 1.6.11 with the given libraries.

Greetings,
Shard

Yes, same issue mentioned already to Martinus, it is the Bug #06...that he can't reproduce, I had it with two Pulse counter...

xbmcnut · #77 Post by **xbmcnut** » 14 Nov 2016, 01:22

Any chance you could update the dead link on page 1 to the correct location? Should be http://www.letscontrolit.com/wiki/index ... candidates not http://www.esp8266.nu/index.php/Main_Pa ... candidates which goes nowhere.

tozett · #78 Post by **tozett** » 14 Nov 2016, 10:08

just a remark to you (older) post, i did not see early enough..., sorry.:

Martinus wrote:
Code: Select all
NTP  : NTP sync request:2
NTP  : NTP send to 185.27.174.7
NTP  : NTP replied: 14 mSec
Took only 14 milliseconds. And this happens once per hour.

big thanks for reply. i can live with current implementation. no problem.
but as it was marked as a potential bug, i could have been the delay.

which is 1000ms delay time, waiting for receiving a ntp-packet. (you reduced this from 1500 to 1000, i recognized now)
and this is every ntp-interval and also (at start of espeasy) for the very first ntp-request.
https://github.com/ESP8266nu/ESPEasy/bl ... .ino#L1803

Code: Select all

uint32_t beginWait = millis();
while (millis() - beginWait < 1000) {
int size = udp.parsePacket();

thanks again for considering my post and reply.
keep on this good work on the great espeasy ! i love it!

Martinus · #79 Post by **Martinus** » 14 Nov 2016, 10:22

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

tozett · #80 Post by **tozett** » 14 Nov 2016, 10:27

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

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.

: Config; 145-4.JPG (56.96 KiB) Viewed 26704 times

: Main; 145-3.JPG (65.28 KiB) Viewed 26704 times

: Config; 145-2.JPG (57.07 KiB) Viewed 26704 times

: Main; 145-1b.JPG (68.3 KiB) Viewed 26704 times

: Tools - Advanced; 145-1a.JPG (60.03 KiB) Viewed 26704 times

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 (24.23 KiB) Viewed 26675 times

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

Who is online