ESP Easy next stable... (release candidates)

Moderators: grovkillen, Stuntteam, TD-er

Message
Author
JR01
Normal user
Posts: 252
Joined: 14 Feb 2016, 21:04
Location: South Africa
Contact:

Re: ESP Easy next stable... (release candidate 1)

#11 Post by JR01 » 14 Oct 2016, 18:32

And it looks like the Domoticz MQTT support has been seriously broken as of R109 where the new pubsub library was introduced. Maybe this also tells us that no one is using it (or they must still be at stable build 108). It was already broken in stable R120.
This bug needs further investigation...
I am using OpenHab MQTT, is that one okay ?

I am on v135, use it to connect to Mosquitto to NodeRed, and cannot do without it.....
-----------
IOTPLAY. Tinkerer, my projects are @ http://GitHub.com/IoTPlay, and blog https://iotplay.org. Using RPi, Node-Red, ESP8266 to prove Industry 4.0 concepts.

DonJuanito
Normal user
Posts: 7
Joined: 16 Mar 2016, 20:01

Re: ESP Easy next stable... (release candidate 1)

#12 Post by DonJuanito » 14 Oct 2016, 21:07

JR01 wrote:
I am using OpenHab MQTT, is that one okay ?
As far as you can control what information is encoded in the Publish messages outgoing from OpenHab, you'll be able to find a way to make it work (see this post: http://www.esp8266.nu/forum/viewtopic.p ... 1993#p9298).
With Domoticz, it is possible, or I haven't found how to do it, so it is unable to control "switch" functions. But fortunately, sending HTTP commands works.
The MQTT Publish incoming to Domoticz from Esp Easy devices are OK...
I'm quite sure these bugs will be corrected.

Shardan
Normal user
Posts: 1156
Joined: 03 Sep 2016, 23:27
Location: Bielefeld / Germany

Re: ESP Easy next stable... (release candidate 1)

#13 Post by Shardan » 15 Oct 2016, 15:06

Hello all,

the R139 Release Notes say "It also needs a patched pubsub library!"
Now where to get that patched lib?

If i may suggest: A github repository running parallel to the ESPEasy branch with the libs one needs for compiling the current release would be nice... makes life a bit easier. :)

Besides that, i agree with beic's post two days ago.
Cleaning up the wiki and getting it up to the current state (or at least close to the state) would be nice.
Some descriptions are very short, e. g. "GP2Y10" or "IR". Might create unnecessary "can't get it to work" questions here.
Some things are just missing or pretty outdated. (Barometric Pressure: BM085 is outdated - took me a while to find out BMP180 works as well...)
I'd write some parts, sadly i'm no native speaker and my english is a bit wooden.

Maybe a bit of cleaning up the code might be a nice idea either.
Development has run in an incredible speed (Must be said: Good job, guys!), so straightening up code from time to time usually is a good idea too.

ATM i'm testing R137_RC1 on some breadboard testing circuits. Up to now it behaves nicely. Again, good job!
Regards
Shardan

DonJuanito
Normal user
Posts: 7
Joined: 16 Mar 2016, 20:01

Re: ESP Easy next stable... (release candidate 1)

#14 Post by DonJuanito » 15 Oct 2016, 15:44

I just found that the "Flashdump" console command seems KO (No dumping, just the stats appear) on R137:

Code: Select all

>Flashdump
Sketch size        : 430848
Sketch free space  : 614400
Flash size         : 4194304
SPIFFS start sector: 256
SPIFFS end sector  : 1019
Offset: 0 : u9x	

Ok

Shardan
Normal user
Posts: 1156
Joined: 03 Sep 2016, 23:27
Location: Bielefeld / Germany

Re: ESP Easy next stable... (release candidate 1)

#15 Post by Shardan » 15 Oct 2016, 21:21

DonJuanito is right.

Flasdump gives statistics only on my testboards too.
Regards
Shardan

User avatar
beic
Normal user
Posts: 118
Joined: 18 Aug 2016, 18:19

Re: ESP Easy next stable... (release candidate 1)

#16 Post by beic » 16 Oct 2016, 01:34

Also the I2C Scan seems to be broken!

Tested Firmware: R137 RC1 and RC139

It's not displaying or showing the attached device name what has found only the address appears!

Image

I'm using the same exact PCF8574 IO Extension Board shown on the ESPEasy WIKI page.

Image

Regards

Martinus

Re: ESP Easy next stable... (release candidate 1)

#17 Post by Martinus » 16 Oct 2016, 12:57

DonJuanito wrote:I just found that the "Flashdump" console command seems KO (No dumping, just the stats appear) on R137:

Code: Select all

>Flashdump
Sketch size        : 430848
Sketch free space  : 614400
Flash size         : 4194304
SPIFFS start sector: 256
SPIFFS end sector  : 1019
Offset: 0 : u9x	

Ok
The debug command expects start/end parameters to show some more info on sector contents. Without these, it only shows the sector at offset 0.
This is by design.
Try 'flashdump 0,10'

Martinus

Re: ESP Easy next stable... (release candidate 1)

#18 Post by Martinus » 16 Oct 2016, 13:01

beic wrote:Also the I2C Scan seems to be broken!

Tested Firmware: R137 RC1 and RC139

It's not displaying or showing the attached device name what has found only the address appears!

Image

I'm using the same exact PCF8574 IO Extension Board shown on the ESPEasy WIKI page.

Image

Regards
The I2C protocol does not specify device id or similar stuff to identify the chip at the other end. The scanner can only tell that some device is listening at a certain address. But i will add 0x38 as the default address for PCF8574A for convenience in the list of known devices.

But to be clear on this feature: the list of known devices is no proof that it is actually one of those devices...

Martinus

Re: ESP Easy next stable... (release candidates)

#19 Post by Martinus » 16 Oct 2016, 15:05

RC2 (R140) is available:

- R138 Bugfix #1: Clock event at system boot issues
- R139 Bugfix #2: Domoticz MQTT support was broken as of R109
- R140 Bugfix #3: I2C Scanner would not show PCF8574A at default address

papperone
Normal user
Posts: 497
Joined: 04 Oct 2016, 23:16

Re: ESP Easy next stable... (release candidates)

#20 Post by papperone » 16 Oct 2016, 15:31

Hi Martinus,
- R138 Bugfix #1: Clock event at system boot issues
Tested and confirm it's working perfectly now! But I think to be really complete and useful we shoudl have as well a %sysdate%; now I know at which time I got an event but on which day??? :o :o
I can implement it myself of course but I believe it's useful features to be added to this RC :)
- R140 Bugfix #3: I2C Scanner would not show PCF8574A at default address
According to this table --> http://www.esp8266.nu/index.php/PCF8574 there are many others address for PCF8574 and PCF8574A.
Unless we have proof those are unique to those devices I think we shoudl not hardcode the link of R140 (e.g. I use PCF8574A but as 0x3A and 0x3B in my setup)
My TINDIE Store where you can find all ESP8266 boards I manufacture --> https://www.tindie.com/stores/GiovanniCas/
My Wiki Project page with self-made PCB/devices --> https://www.letscontrolit.com/wiki/inde ... :Papperone

Shardan
Normal user
Posts: 1156
Joined: 03 Sep 2016, 23:27
Location: Bielefeld / Germany

Re: ESP Easy next stable... (release candidates)

#21 Post by Shardan » 16 Oct 2016, 16:03

Compiled including new libraries on Arduino IDE 1.6.11 --> OK

OTA Upgrade on two test boards --> OK

Checked Clock event --> OK

Can't say anything about the MQTT fix as i don't use MQTT at this time.

Regards
Shardan
Regards
Shardan

User avatar
beic
Normal user
Posts: 118
Joined: 18 Aug 2016, 18:19

Re: ESP Easy next stable... (release candidate 1)

#22 Post by beic » 16 Oct 2016, 16:29

Martinus wrote: The I2C protocol does not specify device id or similar stuff to identify the chip at the other end. The scanner can only tell that some device is listening at a certain address. But i will add 0x38 as the default address for PCF8574A for convenience in the list of known devices.

But to be clear on this feature: the list of known devices is no proof that it is actually one of those devices...
Hi Martinus,

1).
Yes, I know that, but you can do it like on other multiple address detection, just for the reference to see what have been detected and attached to the i2c bus.

Like you did it before for the SI7021 Temp/Hum Sensor, INA219, PCA9685 and BME280/BMP280/MS5607/MS5611

Image

2).
It's is just a surface/beauty/aesthetic issue, but a little bit annoying for me, the multiple i2c device detection separation, there is comma and slash separated (need to decide only for one separation type
(simple comma would be Ok like BME280, BMP280, MS5607, MS5611, shown on the image above).

Also I would remove all definition text (free up some space) from i2c scanner like those "Lux Sensor", "Temp/Hum Sensor", etc..., because other sensors like INA219, PCA9685, BME280, BMP280, MS5607, MS5611 does not have them too.

3).
But as papperone mentioned for the PCF8574 series http://esp8266.nu/forum/viewtopic.php?f ... =10#p10113 for the addressing, I think for these i2c IO Expanders all addresses need to be hardcoded.

PCF8574 and PCF8574P = 0x20, 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27
PCF8574A and PCF857AT = 0x38, 0x39, 0x3A, 0x3B, 0x3C, 0x3D, 0x3E, 0x3F

But, also you can add these like:
PCF8574/P, MCP23008, MCP23017 = 0x20, 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27
PCF8574A/AT = 0x38, 0x39, 0x3A, 0x3B, 0x3C, 0x3D, 0x3E, 0x3F

Example for MCP23008 and MCP23017 (FOR REFERENCE)

http://www.ladyada.net/wiki/tutorials/l ... caddr.html

Image

Thank you! ;)

Regards

User avatar
dev0
Normal user
Posts: 18
Joined: 08 Sep 2016, 14:13

Re: ESP Easy next stable... (release candidate 1)

#23 Post by dev0 » 17 Oct 2016, 09:13

dev0 wrote:Just compiled the source from R137_RC1 with the enclosed libraries, ESP8266 Community libraries 2.30 and Arduino IDE 1.6.9 (Mac): everything went fine for different sensors
Version R137_R1 / R140_RC2 works fine if I compile the source code. But there seems to be a problem with enclosed images (ESPEasy_R140_4096.bin tested). All sensor data will be transmitted as 1 (TRUE). This typically occoure if the ArduinoJson Library ist too old. Used controller is FHEM-HTTP.

Are you sure that you have used the current ArduinoJson library (enclosed in R137/R140) for compiling the images?

Martinus

Re: ESP Easy next stable... (release candidate 1)

#24 Post by Martinus » 17 Oct 2016, 11:43

dev0 wrote:
dev0 wrote:Just compiled the source from R137_RC1 with the enclosed libraries, ESP8266 Community libraries 2.30 and Arduino IDE 1.6.9 (Mac): everything went fine for different sensors
Version R137_R1 / R140_RC2 works fine if I compile the source code. But there seems to be a problem with enclosed images (ESPEasy_R140_4096.bin tested). All sensor data will be transmitted as 1 (TRUE). This typically occoure if the ArduinoJson Library ist too old. Used controller is FHEM-HTTP.

Are you sure that you have used the current ArduinoJson library (enclosed in R137/R140) for compiling the images?
You're right. The images were build using a different system that still had the older json lib. :oops:
I updated the lib and images and uploaded a new zip as R140_RC3. Could you double check these builds? (i don't have an easy way to verify json posts...)

User avatar
dev0
Normal user
Posts: 18
Joined: 08 Sep 2016, 14:13

Re: ESP Easy next stable... (release candidate 1)

#25 Post by dev0 » 17 Oct 2016, 13:28

Martinus wrote:I updated the lib and images and uploaded a new zip as R140_RC3. Could you double check these builds? (i don't have an easy way to verify json posts...)
I've tested the ESPEasy_R140_4096.bin image and it works like a charme. Thank you very much for your quick support!

EDIT: A FHEM user noticed that the enclosed ArduinoJson library version in R140_RC3 differs from verison on github (5.6.4 vs 5.6.7). Take this just as a note, version 5.6.4 is new enough to fix the described problem. I just wanted to let you know.

adrianmihalko
Normal user
Posts: 51
Joined: 15 Sep 2016, 00:20

Re: ESP Easy next stable... (release candidates)

#26 Post by adrianmihalko » 17 Oct 2016, 21:42

Wiki recommendation: you should add a more visible URL to this forum on front page of the Wiki (esp8266.nu), at this moment it's well hidden on the center of the page. :)

papperone
Normal user
Posts: 497
Joined: 04 Oct 2016, 23:16

Re: ESP Easy next stable... (release candidates)

#27 Post by papperone » 19 Oct 2016, 12:51

back to the "hardcoding" of addresses to device:

I am testing ADS1115 which is a supported device and it works, but in the i2c scanner is seen as below:

ADS1115 0x48 --> PCF8591 ADC
ADS1115 0x49 --> TLS2561 Lux Sensor
ADS1115 0x4A --> <empty>
ADS1115 0x4B --> <not recognized>

I still don't understand why on 0x4B the module is not recognized (not ESPEasy issue but looks like somethign with hardware or connections) but on all those 4 addresses ADS1115 shoudl be listed as part of next RC
My TINDIE Store where you can find all ESP8266 boards I manufacture --> https://www.tindie.com/stores/GiovanniCas/
My Wiki Project page with self-made PCB/devices --> https://www.letscontrolit.com/wiki/inde ... :Papperone

User avatar
beic
Normal user
Posts: 118
Joined: 18 Aug 2016, 18:19

Re: ESP Easy next stable... (release candidates)

#28 Post by beic » 19 Oct 2016, 20:30

papperone wrote:back to the "hardcoding" of addresses to device:

I am testing ADS1115 which is a supported device and it works, but in the i2c scanner is seen as below:

ADS1115 0x48 --> PCF8591 ADC
ADS1115 0x49 --> TLS2561 Lux Sensor
ADS1115 0x4A --> <empty>
ADS1115 0x4B --> <not recognized>

I still don't understand why on 0x4B the module is not recognized (not ESPEasy issue but looks like somethign with hardware or connections) but on all those 4 addresses ADS1115 shoudl be listed as part of next RC
All those i2c addresses by the i2c scanner are hardcoded into the ESPEasy source, so, it will not detect it until they decide to put them in!

Regards

btw...I would do it all, if they let me, it's annoying for me too!

ToniA
Normal user
Posts: 68
Joined: 26 Aug 2016, 20:37

Re: ESP Easy next stable... (release candidates)

#29 Post by ToniA » 20 Oct 2016, 19:45

Martinus wrote:I've just run a few tests on Domoticz MQTT in my testlab (i don't use MQTT in production...)
And it looks like the Domoticz MQTT support has been seriously broken as of R109 where the new pubsub library was introduced.
The Domoticz MQTT messages are too large, the PubSubClient hardcodes 128 as the maximum message size:

https://github.com/knolleary/pubsubclie ... ient.h#L26

I changed it to 256 on my own build, and it starts working, but it's still close to the Domoticz message size, so it might not work for all message types, or long device names.

Even though this is a conditional #define in the PubSubClient's header file, one of the shortcomings of the Arduino IDE is that there's no way to define global defines. I.e. adding a #define for this in ESPEasy.ino doesn't change anything.

User avatar
moelski
Normal user
Posts: 126
Joined: 31 Aug 2016, 06:33
Location: Germany - NRW
Contact:

Re: ESP Easy next stable... (release candidates)

#30 Post by moelski » 20 Oct 2016, 20:15

Hi Martinus,

there is another topic that can confuse new ESPEasy user with new ESP boards:
http://www.esp8266.nu/forum/viewtopic.php?f=6&t=2172
regards
Dominik

User avatar
beic
Normal user
Posts: 118
Joined: 18 Aug 2016, 18:19

Re: ESP Easy next stable... (release candidates)

#31 Post by beic » 20 Oct 2016, 21:50

Hey Martinus,

I found a little misc. bug in the Pulse Counter GUI interface plugin, there is no GREEN background shape for the displayed values!

Used R140 firmware.

Image

Please fix it! ;)

Kind regards

Martinus

Re: ESP Easy next stable... (release candidates)

#32 Post by Martinus » 21 Oct 2016, 17:32

Fixed pulsecounter value display style elements
Fixed some missing I2C scanner 'known devices'

current list of bugs to fix is empty.

morle
Normal user
Posts: 17
Joined: 30 Jan 2016, 08:50
Location: Germany

Re: ESP Easy next stable... (release candidates)

#33 Post by morle » 21 Oct 2016, 19:09

Hi Martinus,
It looks like the rules are not saved when doing settings save.
Would be good to have the rules also in the settings save.
Regards
Hubert

User avatar
beic
Normal user
Posts: 118
Joined: 18 Aug 2016, 18:19

Re: ESP Easy next stable... (release candidates)

#34 Post by beic » 21 Oct 2016, 23:32

Martinus wrote:Fixed pulsecounter value display style elements
Fixed some missing I2C scanner 'known devices'
Thanks, but I don't see any changes on GitHub?! :?

User avatar
moelski
Normal user
Posts: 126
Joined: 31 Aug 2016, 06:33
Location: Germany - NRW
Contact:

Re: ESP Easy next stable... (release candidates)

#35 Post by moelski » 22 Oct 2016, 07:51

Hi Martiuns,

did you see a chance to make some small improvements here?
http://www.esp8266.nu/forum/viewtopic.php?f=6&t=2172
regards
Dominik

Martinus

Re: ESP Easy next stable... (release candidates)

#36 Post by Martinus » 22 Oct 2016, 10:46

morle wrote:Hi Martinus,
It looks like the rules are not saved when doing settings save.
Would be good to have the rules also in the settings save.
Regards
Hubert
It was once designed to be able to publish ESP Easy settings to other users by distributing the settings files. For that reason, the security data is not included.
The rules data block comes after the security data block in flash memory so expanding the range would also include security settings.

But you can easily copy/paste your rules to notepad and save them or load them to other units. I personally keep a folder on my PC with settings and rules for each unit number.

Martinus

Re: ESP Easy next stable... (release candidates)

#37 Post by Martinus » 22 Oct 2016, 10:50

moelski wrote:Hi Martiuns,

did you see a chance to make some small improvements here?
http://www.esp8266.nu/forum/viewtopic.php?f=6&t=2172
If you're using the filesystemcheck(), it seems impossible that you are running the release candidate image... ;)

User avatar
moelski
Normal user
Posts: 126
Joined: 31 Aug 2016, 06:33
Location: Germany - NRW
Contact:

Re: ESP Easy next stable... (release candidates)

#38 Post by moelski » 22 Oct 2016, 11:15

Code: Select all

If you're using the filesystemcheck(), it seems impossible that you are running the release candidate image
:mrgreen: Ok you got me :mrgreen:

Anyway ... Would be a simple fix for people who compile the code (like me) ;)
regards
Dominik

Martinus

Re: ESP Easy next stable... (release candidates)

#39 Post by Martinus » 22 Oct 2016, 12:20

I'm planning to have a weekly update on RC editions until we stop discovering bugs for some weeks. (As we discovered lately that R120 is also partly broken, it's time to deliver a more stable firmware this time). And this should still be the stable edition that runs as a simple firmware image without modification on all existing ESP modules.

So my work will be prioritized on fixing bugs for quite some time.

My definition of a bug: Something that does not work as it was designed by the developer :oops:

And this could be different from "Something that does not work as expected by it's user" ;)

I will maintain a temporary buglist during this development stage within this topic:
  • 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'
All fixes will be published directly on github, but the RC images will be only be made available on a weekly schedule unless we have introduced new serious issues while trying to fix things...

User avatar
beic
Normal user
Posts: 118
Joined: 18 Aug 2016, 18:19

Re: ESP Easy next stable... (release candidates)

#40 Post by beic » 22 Oct 2016, 17:15

Hi Martinus,

Here is maybe one more bug what I have found...

It seems that after removing the Pulse Counter device from the Device list it can't remove the Name value (the Name value stays after device deletion)?!

Image

Please fix it SAP, thank you as always! ;)

Regards

johannes
Normal user
Posts: 1
Joined: 22 Oct 2016, 21:35

Re: ESP Easy next stable... (release candidates)

#41 Post by johannes » 22 Oct 2016, 21:44

Hi Martinus,

Here is maybe a bug what I have found...
in R141 after the first pulse the total value increment every secound without pulse

Martinus

Re: ESP Easy next stable... (release candidates)

#42 Post by Martinus » 23 Oct 2016, 11:23

Current bugstatus:
  • 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 NEW : Task value name remains after clearing task?
    Bug #07 NEW : Pulse counter total increases every second without pulse?
I verified bugs #06 and #07 but i'm unable to reproduce those (using R140-RC3)
Does anyone else experience the same erratic behavior?
Is this intermittent or does it only occur in some specific situations?

User avatar
beic
Normal user
Posts: 118
Joined: 18 Aug 2016, 18:19

Re: ESP Easy next stable... (release candidates)

#43 Post by beic » 23 Oct 2016, 15:27

Martinus wrote:Current bugstatus:
  • Bug #06 NEW : Task value name remains after clearing task?
    Bug #07 NEW : Pulse counter total increases every second without pulse?
I verified bugs #06 and #07 but i'm unable to reproduce those (using R140-RC3)

Does anyone else experience the same erratic behavior?
Is this intermittent or does it only occur in some specific situations?
Bug #06 NEW : Task value name remains after clearing task?

It's happening only occasionally, maybe I have some caching issue, so far happened to me before 1-2 months and yesterday, now it's gone! Strange!?!?

Bug #07 NEW : Pulse counter total increases every second without pulse?

I'm running my 2 channel Waterflow sensors on the ESP-01 through Pulse counter plugin (R141 compiled from GitHub source manually), running stable over 3 hours now and without any 1s increment on Total value (seems good, no issues there).

Regards

User avatar
beic
Normal user
Posts: 118
Joined: 18 Aug 2016, 18:19

Re: ESP Easy next stable... (release candidates)

#44 Post by beic » 23 Oct 2016, 16:16

Martinus wrote:Current bugstatus:
  • Bug #05 FIXED in R141 : Some missing I2C scanner 'known devices'
Bug #05 FIXED in R141 : Some missing I2C scanner 'known devices'

Please don't forget to add to the 'known devices' list the BMP180 too, between BMP085 and BME280.

And olso you need to correct the PCF IO Extender IC too like I mentioned before:

Image

PCF8574/P/T, MCP23008, MCP23017 = 0x20, 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27

Image

PCF8574A/AT = 0x38, 0x39, 0x3A, 0x3B, 0x3C, 0x3D, 0x3E, 0x3F

I'm just telling you this Martinus, because I'm currently using all those mentioned modules and sensors and I want to help in anyway I can!

Thank you!

Regard

frank
Normal user
Posts: 85
Joined: 15 Oct 2016, 20:17
Location: Nederland

Re: ESP Easy next stable... (release candidates)

#45 Post by frank » 24 Oct 2016, 17:07

MLX90614 on adres 0x5a is not shown in rc 141 scanner

tparvais
Normal user
Posts: 79
Joined: 28 Oct 2015, 23:13

Re: ESP Easy next stable... (release candidates)

#46 Post by tparvais » 24 Oct 2016, 18:38

Hello

A small bug (or maybe missing feature?):

in Wifi setup wizard (connected to ESP_0), the Wifi power indication is not displayed. Not obvious to select the correct AP. At Home, I've several AP wit same SSID.

I propose to add the three lines:

Code: Select all

reply += F("(");
reply +=WiFi.RSSI(i);
reply += F(" dB)");
in line 2495 of webserver.ino file (R141)

Thomas

Martinus

Re: ESP Easy next stable... (release candidates)

#47 Post by Martinus » 26 Oct 2016, 16:58

beic wrote:
Martinus wrote:Current bugstatus:
  • Bug #05 FIXED in R141 : Some missing I2C scanner 'known devices'
Bug #05 FIXED in R141 : Some missing I2C scanner 'known devices'

Please don't forget to add to the 'known devices' list the BMP180 too, between BMP085 and BME280.

And olso you need to correct the PCF IO Extender IC too like I mentioned before:

Image

PCF8574/P/T, MCP23008, MCP23017 = 0x20, 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27

Image

PCF8574A/AT = 0x38, 0x39, 0x3A, 0x3B, 0x3C, 0x3D, 0x3E, 0x3F

I'm just telling you this Martinus, because I'm currently using all those mentioned modules and sensors and I want to help in anyway I can!

Thank you!

Regard
I will add the missing BMP180.

Regarding the PCF8574, these are just additional package type markings. In that case, you could have missed:
PCF8475AP
PCF8475TS
PCF8475ATS
And maybe the Texas Instruments device markings (according to datasheet):
PF574
PCF8574
PCF8574N
I don't think that we should add all these variants. The only interesting part is the 'A' because it uses a different I2C address

Martinus

Re: ESP Easy next stable... (release candidates)

#48 Post by Martinus » 26 Oct 2016, 16:59

frank wrote:MLX90614 on adres 0x5a is not shown in rc 141 scanner
Thanks for reporting. Will be fixed in R142

cherowley
Normal user
Posts: 125
Joined: 14 Jan 2016, 09:39

Re: ESP Easy next stable... (release candidates)

#49 Post by cherowley » 26 Oct 2016, 17:15

[quote="Martinus"]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..

User avatar
beic
Normal user
Posts: 118
Joined: 18 Aug 2016, 18:19

Re: ESP Easy next stable... (release candidates)

#50 Post by beic » 26 Oct 2016, 17:55

Martinus wrote: Regarding the PCF8574, these are just additional package type markings.
Yes, but if someone or like me using more of them in the external enclosure it wont be able to figure out where is what device, that was my point.

If you add that markings, then I will know that the DIP package type (PCF8574/P/T) is in the white external enclosure and the SMD package type (PCF8574A/AT) is in the black internal enclosure (or whatever, indoor, outdoor).

You know what I meant, but it's just my opinion!

Thank you! ;)

Regards

Martinus

Re: ESP Easy next stable... (release candidates)

#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

Re: ESP Easy next stable... (release candidates)

#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
Normal user
Posts: 125
Joined: 14 Jan 2016, 09:39

Re: ESP Easy next stable... (release candidates)

#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
Normal user
Posts: 497
Joined: 04 Oct 2016, 23:16

Re: ESP Easy next stable... (release candidates)

#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)
My TINDIE Store where you can find all ESP8266 boards I manufacture --> https://www.tindie.com/stores/GiovanniCas/
My Wiki Project page with self-made PCB/devices --> https://www.letscontrolit.com/wiki/inde ... :Papperone

hvdwolf
Normal user
Posts: 51
Joined: 09 Jun 2016, 12:37

Re: ESP Easy next stable... (release candidates)

#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
Normal user
Posts: 85
Joined: 15 Oct 2016, 20:17
Location: Nederland

Re: ESP Easy next stable... (release candidates)

#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

Re: ESP Easy next stable... (release candidates)

#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
Normal user
Posts: 1156
Joined: 03 Sep 2016, 23:27
Location: Bielefeld / Germany

Re: ESP Easy next stable... (release candidates)

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

Hello Martinus,

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

tozett
Normal user
Posts: 734
Joined: 22 Dec 2015, 15:46
Location: Germany

Re: ESP Easy next stable... (release candidates)

#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.
Attachments
ntp-delay.png
ntp-delay.png (196.72 KiB) Viewed 9311 times

thex
Normal user
Posts: 1
Joined: 04 Nov 2016, 00:09

Re: ESP Easy next stable... (release candidates)

#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

Post Reply

Who is online

Users browsing this forum: No registered users and 15 guests