Let's Control It

Hello,

I feel I need to clear some things from the development side of things. We are fairly close on releasing a new stable version.

• Current development is called "mega".

• We released a candidate for v2.0.0 in last December, this RC was abandoned some weeks ago.

• When we release next stable we will release this as v2.1.0 to not make it mistakenly taken for the same version as the now abandoned v2.0.0 (which was never officially stable).

And just to make it more clear, users need to understand that until an official stable release is launched the nightly builds might break stuff for you so never upgrade a live unit until you have tested it on a test unit. With that being said, we are in great need of dedicated testers.

Some random clearifications:

• Tag name (currently we use mega and next stable will be tagged v2.1) of current development, thus the nightly release name "mega-YYYYMMDD".

• Git version (for example mega-YYYYMMDD) name which consist of tag name and date. This is essentially the zip file with all the bin files and a copy of the source at the time of release.

• Build (currently 20101) is an integer number which we use inside the code to make sure that updates that are not compatible with older builds are taken care of with a simple if statement in the code.

• Core (currently we use 2_4_0) is the core code which we use, ESP Easy is not 100% self maintained code, we use a core library with code plus many specific libraries which will take care of communication, hardware, etc. etc.

• Bin file name (for example ESP_Easy_mega-20180415_normal_ESP8266_4096.bin and ESP_Easy_mega-20180415_test_ESP8266PUYA_VCC.bin) is actually a combination of many of the above names/tags. First we have ESP_Easy, then we put the current Git Version, after that is what plugin set that is used (normal, test, dev), after that is the specific hardware (currently ESP8266 and ESP8285), for special units we add a tag directly after the hardware (like PUYA for the cheap memory chip used in later ESP-01s units), then it's chip size (1024, 4096), after all those we add VCC if internal VCC monitoring is enabled.

So all these numbers, tags and names are needed even though it might at first seem unnecessary to have them. We really need them to keep track of everything.

sounds like a plan!

Where's the love for the ESP32 , though ?

It's totally there but we just recently got a developer doing ESP32 stuff so it's really early and nightly releases are not there yet.

sounds even more like a plan!

Btw, i have a few esp32's lying around, doing some stability monitoring on them. If I can help the development in any way, with these non-critical units... be glad to.
Sorry for the thread hi-jacking

grovkillen wrote: ↑16 Apr 2018, 09:15 Hello,

I feel I need to clear some things from the development side of things. We are fairly close on releasing a new stable version.

• Current development is called "mega".

• We released a candidate for v2.0.0 in last December, this RC was abandoned some weeks ago.

• When we release next stable we will release this as v2.1.0 to not make it mistakenly taken for the same version as the now abandoned v2.0.0 (which was never officially stable).

And just to make it more clear, users need to understand that until an official stable release is launched the nightly builds might break stuff for you so never upgrade a live unit until you have tested it on a test unit. With that being said, we are in great need of dedicated testers.

Some random clearifications:

• Tag name (currently we use mega and next stable will be tagged v2.1) of current development, thus the nightly release name "mega-YYYYMMDD".

• Git version (for example mega-YYYYMMDD) name which consist of tag name and date. This is essentially the zip file with all the bin files and a copy of the source at the time of release.

• Build (currently 20101) is an integer number which we use inside the code to make sure that updates that are not compatible with older builds are taken care of with a simple if statement in the code.

• Core (currently we use 2_4_0) is the core code which we use, ESP Easy is not 100% self maintained code, we use a core library with code plus many specific libraries which will take care of communication, hardware, etc. etc.

• Bin file name (for example ESP_Easy_mega-20180415_normal_ESP8266_4096.bin and ESP_Easy_mega-20180415_test_ESP8266PUYA_VCC.bin) is actually a combination of many of the above names/tags. First we have ESP_Easy, then we put the current Git Version, after that is what plugin set that is used (normal, test, dev), after that is the specific hardware (currently ESP8266 and ESP8285), for special units we add a tag directly after the hardware (like PUYA for the cheap memory chip used in later ESP-01s units), then it's chip size (1024, 4096), after all those we add VCC if internal VCC monitoring is enabled.

So all these numbers, tags and names are needed even though it might at first seem unnecessary to have them. We really need them to keep track of everything.

Heya grovkollen,

Question, are there problems with the nightly builds? I see the last nightly build has as date: Release mega-20180524

No only more going on in the background. We're still developing but need to test it by our self until we got it down.

grovkillen wrote: ↑01 Jun 2018, 16:13 No only more going on in the background. We're still developing but need to test it by our self until we got it down.

Oké, clear answer. Thanks.

To give some more information on my side.
Apart from being very busy with other stuff that takes time from this project (sleep, work, family, issues with the house), I've been trying to get my dev environment back to work again.
I simply can't get it to flash the ESP32 anymore and I really want to test a few things on that before I continue.
There has been an update on PlatformIO (or Windows or something else) that caused these issues.
It has occupied the last few evenings completely to get it to work again, but still no luck.

One of the reasons I really want the ESP32 to work again with the latest updates is because it will support debugging from VScode and I really want some kind of debugger.
Not having a debugger is just taking way too much time and frustration.

at this point in time, which would be the most stable release for the ESP32 ?
I'm still running ESPEasy32_R20100 from March30th, 2018.

Tommmii wrote: ↑28 Jul 2018, 11:28 at this point in time, which would be the most stable release for the ESP32 ?
I'm still running ESPEasy32_R20100 from March30th, 2018.

ESP32 builds still have issues regarding I2C.
If you use more than one I2C device (more can be connected, only not used), it will halt all I2C communications.
And not much other plugins are added to the ESP32 build.
So the ESP32 build should still be considered "experimental", I am afraid.

I have no need for I2C (for now )
I just had a look at a recent nightly build, and it looks as if the "Switch input - Switch" and the "Analog input - internal" are both not included?
Does that seem right, or am I having a blonde moment ?

Not sure about the analog input.

and the Switch input ?

Tommmii wrote: ↑29 Jul 2018, 17:18 and the Switch input ?

The switch input is present.
Currently the ESP32 builds have:

• OLED Framed
• INA219
• BMx280
• Dummy Device
• MQTT Import
• Pulse counter
• System Info
• Switch input.

Is there a way to see in github which plugins are supported ?
Or can this only be seen after flashing the build into a device ?

Tommmii wrote: ↑07 Aug 2018, 09:56 Is there a way to see in github which plugins are supported ?
Or can this only be seen after flashing the build into a device ?

What is used where is defined in here: https://github.com/letscontrolit/ESPEas ... gin_sets.h

Perfect, cheers for this!

What is the difference between these builds:

custom_ESP8266_4M1M.bin
test_core_260_sdk222_alpha_ESP8266_4M1M.bin (test plugins + new SDK?)
test_ESP8266_4M_VCC.bin (includes test plugins)

JohnW wrote: ↑19 Oct 2019, 20:34 What is the difference between there builds:

custom_ESP8266_4M1M.bin
test_core_260_sdk222_alpha_ESP8266_4M1M.bin (test plugins + new SDK?)
test_ESP8266_4M_VCC.bin (includes test plugins)

See the README.txt also included in the ZIP you can download: https://github.com/letscontrolit/ESPEasy/tree/mega/dist

TD-er wrote: ↑19 Oct 2019, 21:55

JohnW wrote: ↑19 Oct 2019, 20:34 What is the difference between there builds:

custom_ESP8266_4M1M.bin
test_core_260_sdk222_alpha_ESP8266_4M1M.bin (test plugins + new SDK?)
test_ESP8266_4M_VCC.bin (includes test plugins)

See the README.txt also included in the ZIP you can download: https://github.com/letscontrolit/ESPEasy/tree/mega/dist

Unfortunately, I can't find info about "custom":

- normal_IR => "Normal" + IR receiver/transmitter plugins and library
- hard_xxxxx => Special builds for some off-the-shelf hardware.
- minimal_ESP82xx_1M_OTA => Minimum number of plugins and a limited set of controllers included to be able to perform a 2-step OTA on 1 MB flash nodes.
- normal_core_241 => "Normal" using core 2.4.1, since 2.4.2 has issues with PWM
- xxx_core_260_sdk2_alpha -> core 2.6.0 alpha version (under development) using SDK 2.2.1
- xxx_core_260_sdk222_alpha -> core 2.6.0 alpha version (under development) using SDK 2.2.2
- xxx_core_260_sdk3_alpha -> core 2.6.0 alpha version (under development) using SDK 3.0.0-dev (under development too)

The custom one is using the Python script pre_extra_script.py

As you can see in that script, it is using a pre-defined set of plugins and controllers.
It is also used for people building their own using the (experimental) Vagrant build.