ESP Easy next stable... (release candidates)
Moderators: grovkillen, Stuntteam, TD-er
ESP Easy next stable... (release candidates)
ESP Easy development on github is currently at build R137 and we have reached the compile size limitations for the classic ESP modules with 512kb flash chips.
A good time to deliver the next and maybe 'final' stable in its present form. This requires some feedback on the latest build.
For your convenience, we provided standard binary images for R137, to be considered as 'release candidates' for the next stable.
http://www.letscontrolit.com/wiki/index ... candidates
Highlights for the next stable:
=========================
Added formula option for pow calculations like 2^3 in (contributed by pm-cz)
Added NodeMCU/Wemos pin numbers (contributed by nonflammable)
Added pressure altitude adjustment to pressure sensors (contributed by adrianmihalko/pm-cz)
Added build and unit name to the node list
Added total to the pulse counter as single value (not persistent counter!) (contributed by fvdpol)
Added authentication to http controller (contributed by marcfon)
Added SPI support in hardware tab (contributed by moelski)
Added NodeMCU/Wemos pin numbering to GPIO list (contributed by moelski)
Added rule events to SerialServer and SerialSend command
Added support for DS1825 (contributed by maxx333)
Added support for multiple BH1750 sensors (contributed by guslinux & pm-cz)
Added JSON support on FHEM controller plugin (contributed by ddtlabs)
Added support for smaller OLED displays (contributed by ToniA)
Added generic UDP controller, C010
Added IR TX plugin from the playground as P035, (contributed by cherowley)
Added support for the DHT12 sensor, successor of the famous DHT11. (contributed by pm-cz)
Added option for MQTT retain flag
Fixes
=====
Moved ISR handlers for Pulse, RFID and HCSR04 plugins to iram cache for better stability
Fixed the situation where using the old style MQTT gpio/pwm commands left event-Par3 uninitialized.
Corrected minor issue on plugin_027
Adjustable serial RX Receive timeout in Ser2Net plugin. To collect entire message and send it as one TCP packet.
Check on unit number < UNIT_MAX before adding self to the nodelist. This would corrupt the nodelist data structure for units > 31
Fixed another potential buffer overflow when logging ser2net data. And changed the fix from R119. Extended Ser2Net logging.
Wiki pages have been updated for the latest plugins (Dummy, DHT12 and IRTX), but the Wiki is still very limited. There's certainly room for improvement. Contributions are welcomed here, but we need to settle things on access rights and naming conventions and such before we can open up the Wiki for contributors.
(we had the Wiki open for public in the very beginning and we were spammed and hacked before we blinked our eyes...)
A good time to deliver the next and maybe 'final' stable in its present form. This requires some feedback on the latest build.
For your convenience, we provided standard binary images for R137, to be considered as 'release candidates' for the next stable.
http://www.letscontrolit.com/wiki/index ... candidates
Highlights for the next stable:
=========================
Added formula option for pow calculations like 2^3 in (contributed by pm-cz)
Added NodeMCU/Wemos pin numbers (contributed by nonflammable)
Added pressure altitude adjustment to pressure sensors (contributed by adrianmihalko/pm-cz)
Added build and unit name to the node list
Added total to the pulse counter as single value (not persistent counter!) (contributed by fvdpol)
Added authentication to http controller (contributed by marcfon)
Added SPI support in hardware tab (contributed by moelski)
Added NodeMCU/Wemos pin numbering to GPIO list (contributed by moelski)
Added rule events to SerialServer and SerialSend command
Added support for DS1825 (contributed by maxx333)
Added support for multiple BH1750 sensors (contributed by guslinux & pm-cz)
Added JSON support on FHEM controller plugin (contributed by ddtlabs)
Added support for smaller OLED displays (contributed by ToniA)
Added generic UDP controller, C010
Added IR TX plugin from the playground as P035, (contributed by cherowley)
Added support for the DHT12 sensor, successor of the famous DHT11. (contributed by pm-cz)
Added option for MQTT retain flag
Fixes
=====
Moved ISR handlers for Pulse, RFID and HCSR04 plugins to iram cache for better stability
Fixed the situation where using the old style MQTT gpio/pwm commands left event-Par3 uninitialized.
Corrected minor issue on plugin_027
Adjustable serial RX Receive timeout in Ser2Net plugin. To collect entire message and send it as one TCP packet.
Check on unit number < UNIT_MAX before adding self to the nodelist. This would corrupt the nodelist data structure for units > 31
Fixed another potential buffer overflow when logging ser2net data. And changed the fix from R119. Extended Ser2Net logging.
Wiki pages have been updated for the latest plugins (Dummy, DHT12 and IRTX), but the Wiki is still very limited. There's certainly room for improvement. Contributions are welcomed here, but we need to settle things on access rights and naming conventions and such before we can open up the Wiki for contributors.
(we had the Wiki open for public in the very beginning and we were spammed and hacked before we blinked our eyes...)
Re: ESP Easy next stable... (release candidate 1)
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 in conjunction with FHEM controller environment. Apart from that, I did not read about any problems with the last ESPEasy versions in our FHEM forum.Martinus wrote:This requires some feedback on the latest build.
Regards,
dev0 (ddtlabs/_C009.ino)
Re: ESP Easy next stable... (release candidate 1)
Hi !
As written before ... No problems at all with Release 137.This requires some feedback on the latest build.
regards
Dominik
Dominik
Re: ESP Easy next stable... (release candidate 1)
Binary built from the latest GitHub source, uploaded via OTA and everything seems to working fine!Martinus wrote:
This requires some feedback on the latest build.
Re: ESP Easy next stable... (release candidate 1)
HI, So what is the new style MQTT GPIO/PWM commands?
Re: ESP Easy next stable... (release candidate 1)
I've upgraded my ESP's to build 137, will report back when I find issues.
remark: it took me no more than about 10 minutes to download, unzip, and load into all of my ESP's!
Such a vast improvement to the old Nodo days... Great job, guys!
remark: it took me no more than about 10 minutes to download, unzip, and load into all of my ESP's!
Such a vast improvement to the old Nodo days... Great job, guys!
Re: ESP Easy next stable... (release candidate 1)
I think after the RC release maybe it's time to pause with the further firmware development and to rework, update the whole WIKI page.
It's really hard to find anything on it, regarding "Events, Rules, Basic Examples, Connection Diagrams, Schemes, Pinouts, etc...", little useful stuff's!
Anything with "Good explanation",...
Just my opinion as a beginner...
It's really hard to find anything on it, regarding "Events, Rules, Basic Examples, Connection Diagrams, Schemes, Pinouts, etc...", little useful stuff's!
Anything with "Good explanation",...
Just my opinion as a beginner...
Re: ESP Easy next stable... (release candidate 1)
Seems to work perfectly, as usual.
Great job and yes, time to wrap up and do some work, I think too.
Great job and yes, time to wrap up and do some work, I think too.
-
- New user
- Posts: 7
- Joined: 16 Mar 2016, 20:01
Re: ESP Easy next stable... (release candidate 1)
Everything I tested seems OK in R137, apart from the "Output - (Domoticz Helper)" which seems unstable as sending some MQTT commands to a task reboots the device (SonOFF).
For now, I use HTTP commands to control the ESP Easy devices (from Domoticz V34834 on a Raspberry 2).
This reboots the device (Idx:2 is a Switch device on the ESP8266/SonOFF):
This works and doesn't crash it:
But the commands sent by Domoticz for a light switch are ignored:
As I haven't found the time to try to debug this behavior, I reverted to sending HTTP commands from Domoticz to my Esp Easy devices...
Thanks for your dedication and keep up the good work...
For now, I use HTTP commands to control the ESP Easy devices (from Domoticz V34834 on a Raspberry 2).
This reboots the device (Idx:2 is a Switch device on the ESP8266/SonOFF):
Code: Select all
mosquitto_pub -d -t /domoticz/out -m '{"idx":2,"command":"switchlight","switchcmd":"Off"}';
Code: Select all
mosquitto_pub -d -t /domoticz/out -m '{ "idx" : 2, "nvalue" : 1, "switchType" : "" }';
Code: Select all
domoticz/out {
"Battery" : 255,
"RSSI" : 12,
"dtype" : "Light/Switch",
"id" : "00014051",
"idx" : 2,
"name" : "CAVE Lampe établi",
"nvalue" : 1,
"stype" : "Switch",
"svalue1" : "0",
"switchType" : "On/Off",
"unit" : 1
}
Thanks for your dedication and keep up the good work...
Re: ESP Easy next stable... (release candidate 1)
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.
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...
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...
Re: ESP Easy next stable... (release candidate 1)
I am using OpenHab MQTT, is that one okay ?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 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.
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.
-
- New user
- Posts: 7
- Joined: 16 Mar 2016, 20:01
Re: ESP Easy next stable... (release candidate 1)
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).JR01 wrote:I am using OpenHab MQTT, is that one okay ?
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.
Re: ESP Easy next stable... (release candidate 1)
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!
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
Shardan
-
- New user
- Posts: 7
- Joined: 16 Mar 2016, 20:01
Re: ESP Easy next stable... (release candidate 1)
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
Re: ESP Easy next stable... (release candidate 1)
DonJuanito is right.
Flasdump gives statistics only on my testboards too.
Flasdump gives statistics only on my testboards too.
Regards
Shardan
Shardan
Re: ESP Easy next stable... (release candidate 1)
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!
I'm using the same exact PCF8574 IO Extension Board shown on the ESPEasy WIKI page.
Regards
Tested Firmware: R137 RC1 and RC139
It's not displaying or showing the attached device name what has found only the address appears!
I'm using the same exact PCF8574 IO Extension Board shown on the ESPEasy WIKI page.
Regards
Re: ESP Easy next stable... (release candidate 1)
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.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
This is by design.
Try 'flashdump 0,10'
Re: ESP Easy next stable... (release candidate 1)
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.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!
I'm using the same exact PCF8574 IO Extension Board shown on the ESPEasy WIKI page.
Regards
But to be clear on this feature: the list of known devices is no proof that it is actually one of those devices...
Re: ESP Easy next stable... (release candidates)
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
- 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
Re: ESP Easy next stable... (release candidates)
Hi Martinus,
I can implement it myself of course but I believe it's useful features to be added to this RC
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)
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???- R138 Bugfix #1: Clock event at system boot issues
I can implement it myself of course but I believe it's useful features to be added to this RC
According to this table --> http://www.esp8266.nu/index.php/PCF8574 there are many others address for PCF8574 and PCF8574A.- R140 Bugfix #3: I2C Scanner would not show PCF8574A at default address
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
My Wiki Project page with self-made PCB/devices --> https://www.letscontrolit.com/wiki/inde ... :Papperone
Re: ESP Easy next stable... (release candidates)
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
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
Shardan
Re: ESP Easy next stable... (release candidate 1)
Hi Martinus,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...
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
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
Thank you!
Regards
Re: ESP Easy next stable... (release candidate 1)
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.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
Are you sure that you have used the current ArduinoJson library (enclosed in R137/R140) for compiling the images?
Re: ESP Easy next stable... (release candidate 1)
You're right. The images were build using a different system that still had the older json lib.dev0 wrote: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.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
Are you sure that you have used the current ArduinoJson library (enclosed in R137/R140) for compiling the images?
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...)
Re: ESP Easy next stable... (release candidate 1)
I've tested the ESPEasy_R140_4096.bin image and it works like a charme. Thank you very much for your quick support!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...)
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.
-
- Normal user
- Posts: 51
- Joined: 15 Sep 2016, 00:20
Re: ESP Easy next stable... (release candidates)
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.
Re: ESP Easy next stable... (release candidates)
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
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
My Wiki Project page with self-made PCB/devices --> https://www.letscontrolit.com/wiki/inde ... :Papperone
Re: ESP Easy next stable... (release candidates)
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!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
Regards
btw...I would do it all, if they let me, it's annoying for me too!
Re: ESP Easy next stable... (release candidates)
The Domoticz MQTT messages are too large, the PubSubClient hardcodes 128 as the maximum message size: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.
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.
Re: ESP Easy next stable... (release candidates)
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
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
Dominik
Re: ESP Easy next stable... (release candidates)
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.
Please fix it!
Kind regards
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.
Please fix it!
Kind regards
Re: ESP Easy next stable... (release candidates)
Fixed pulsecounter value display style elements
Fixed some missing I2C scanner 'known devices'
current list of bugs to fix is empty.
Fixed some missing I2C scanner 'known devices'
current list of bugs to fix is empty.
Re: ESP Easy next stable... (release candidates)
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 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
Re: ESP Easy next stable... (release candidates)
Thanks, but I don't see any changes on GitHub?!Martinus wrote:Fixed pulsecounter value display style elements
Fixed some missing I2C scanner 'known devices'
Re: ESP Easy next stable... (release candidates)
Hi Martiuns,
did you see a chance to make some small improvements here?
http://www.esp8266.nu/forum/viewtopic.php?f=6&t=2172
did you see a chance to make some small improvements here?
http://www.esp8266.nu/forum/viewtopic.php?f=6&t=2172
regards
Dominik
Dominik
Re: ESP Easy next stable... (release candidates)
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.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
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.
Re: ESP Easy next stable... (release candidates)
If you're using the filesystemcheck(), it seems impossible that you are running the release candidate image...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
Re: ESP Easy next stable... (release candidates)
Code: Select all
If you're using the filesystemcheck(), it seems impossible that you are running the release candidate image
Anyway ... Would be a simple fix for people who compile the code (like me)
regards
Dominik
Dominik
Re: ESP Easy next stable... (release candidates)
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
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:
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
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'
Re: ESP Easy next stable... (release candidates)
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)?!
Please fix it SAP, thank you as always!
Regards
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)?!
Please fix it SAP, thank you as always!
Regards
Re: ESP Easy next stable... (release candidates)
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
Here is maybe a bug what I have found...
in R141 after the first pulse the total value increment every secound without pulse
Re: ESP Easy next stable... (release candidates)
Current bugstatus:
Does anyone else experience the same erratic behavior?
Is this intermittent or does it only occur in some specific situations?
- 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?
Does anyone else experience the same erratic behavior?
Is this intermittent or does it only occur in some specific situations?
Re: ESP Easy next stable... (release candidates)
Bug #06 NEW : Task value name remains after clearing task?Martinus wrote:Current bugstatus:I verified bugs #06 and #07 but i'm unable to reproduce those (using R140-RC3)
- Bug #06 NEW : Task value name remains after clearing task?
Bug #07 NEW : Pulse counter total increases every second without pulse?
Does anyone else experience the same erratic behavior?
Is this intermittent or does it only occur in some specific situations?
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
Re: ESP Easy next stable... (release candidates)
Bug #05 FIXED in R141 : Some missing I2C scanner 'known devices'Martinus wrote:Current bugstatus:
- 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:
PCF8574/P/T, MCP23008, MCP23017 = 0x20, 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27
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
Re: ESP Easy next stable... (release candidates)
MLX90614 on adres 0x5a is not shown in rc 141 scanner
Re: ESP Easy next stable... (release candidates)
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:
in line 2495 of webserver.ino file (R141)
Thomas
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)");
Thomas
Re: ESP Easy next stable... (release candidates)
I will add the missing BMP180.beic wrote:Bug #05 FIXED in R141 : Some missing I2C scanner 'known devices'Martinus wrote:Current bugstatus:
- 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:
PCF8574/P/T, MCP23008, MCP23017 = 0x20, 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27
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
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
Re: ESP Easy next stable... (release candidates)
Thanks for reporting. Will be fixed in R142frank wrote:MLX90614 on adres 0x5a is not shown in rc 141 scanner
Re: ESP Easy next stable... (release candidates)
[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..
Re: ESP Easy next stable... (release candidates)
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.Martinus wrote: Regarding the PCF8574, these are just additional package type markings.
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
Who is online
Users browsing this forum: Bing [Bot] and 134 guests