ESP Easy development status

[BertB]

In the meanwhile i also fixed building in Arduino IDE again and updated the wiki.

Use at least v2.0.0-dev7 and the changes i made here: https://www.letscontrolit.com/wiki/inde ... are_Upload

I have gone through the setup all over again and now I see the fault is maybe somewhere in my interaction with Github.
When I am at letscontrolit/ESPEasy, I see:

Github org.png (88.29 KiB) Viewed 51660 times

And after Fork:

Github Fork.png (69.88 KiB) Viewed 51660 times

I think the Forking is not actually been done.

[psy0rz]

the file structure looks like the naster branch, although github says mega-branch for some reason.

github should always fork all the branches i assume.

[BertB]

Okay ... so I went kamikaze and deleted my repository.
After that, I forked ESPEasy again and now things start to work.

[BertB]

@psyOrz
I thougt I understood how to work with github, but it seems I am still lost.
I managed to make my own fork of the letscontrolit repository and I was successful to compile it using github desktop and Atom.
Now I see there has been some changes, but when I click the Fork button they are not copied to my repository.
Is that normal?

[BertB]

How can I update my forked repository with the changes made in the letscontrolit/ESPEasy repository?

[psy0rz]

How can I update my forked repository with the changes made in the letscontrolit/ESPEasy repository?

I'm not sure how to do it with git desktop. (but its possible)

I usually use the commandline and do something like git pull or git pull origin mega.

There is probably some help on github.com on how to do it with git desktop. If you find out how we should update the wiki.

[BertB]

This works fine for me:

http://stackoverflow.com/questions/2098 ... 1#21131381

[Martinus]

After running R148 for months, i decided to just take a go with the latest github release and take it into production use. All unit's could be upgraded using OTA without a single glitch.
Did not have to dismount a single unit...

Yes of course, i had to reconfigure all unit's from scratch because the mega version uses a different config format, but it took less than 30 minutes to do so for all unit's.

Seem to run fine after two days:

V200_Upgrade.png (56.42 KiB) Viewed 50605 times

Although i'm no longer responsible for lead development, i would suggest to all developers/contributors to 'pause' new features for a while and focus on round-up of the current edition to replace the old R120. What do you think?

[grovkillen]

+1 for that. Just fix the issues relating none working features. We need all the things working at R120 to still work for 2.0.0.

[psy0rz]

I agree, we should focus on fixing bugs the coming month so we can move on and finally release a beta of v2.0.

Having all all the devs help with the awesome new features is like giving free candy to a kid. Its just too good not to take.

jkdesign, krikk, can you put the new features on hold for a while, so we dont get merge conflicts on long standing pull requests? ill try to focus on bugfixing the coming weeks. (had a few busy last weeks so i didnt have enough time to make good progress)

Martinus, let us know how stable it runs on all your gadgets

[Shardan]

Although i'm no longer responsible for lead development, i would suggest to all developers/contributors to 'pause' new features for a while and focus on round-up of the current edition to replace the old R120. What do you think?

+1 for that

On long term it will be necessary to come to a development scheme similiar to the way the linux kernel is developed.

A very raw layout might be:
1. Collecting - gathering new features for the next release.
2. Freezing, coding and testing. The list of new features is closed, coding and testing.
3. Beta, release candidate...
4. Release of a new version.

At the moment steps 1...3 are done same time.
Following my experience that will not work for unlimited time without issues.

Regards
Shardan

[psy0rz]

its more like we kept hanging too long at step 1. but im new here and it takes a few months to get "settled" in a new project an community, so to speak

now its time for step 2 indeed.

[themanfrommoon]

Did somebody fix the following reported bug?

https://www.letscontrolit.com/forum/vie ... f=6&t=3126

Thanks and best regards,
Chris

[LisaM]

Although i'm no longer responsible for lead development, i would suggest to all developers/contributors to 'pause' new features for a while and focus on round-up of the current edition to replace the old R120. What do you think?

And break the development in two: core/non-core with each having it's own focus / development cycle. Focus of core part should be stability and not new features, while the non-core part (sensors) can focus on new features relying on the core for stability...

[BertB]

+1 here too.
I am running the latest build (-dev10) on two devices and -dev8 on 8 others for a month now. Works like a charm.

[Martinus]

I think that the only right way is to split the project between stable and unstable. The stable versions will only get bugfixes (and maybe new features that have really been proven solid)
They could also be labeled Production and Experimental.

[psy0rz]

Martinus,

The common way to do this is with branches: As soon as we have a stable 2.0 release we should create a 2.0-branch. This will be the production branch in which we only commit the bugfixes, and create versions 2.0.1, 2.0.2 etc.

Development can then continue in the "development" branch, until we decide its time for a 2.1.0 release. (which at that point also will become a bugfix branch, and perhaps we can then make 2.0.x obsolete)

This will make porting bugfixes between the development and production versions much easier, because we can let git do most of the work.

Currently our development branch is "mega", but perhaps its better to switch this back to "master" at some point, since this is also more common.

Sounds good?

[Martinus]

Martinus,

The common way to do this is with branches: As soon as we have a stable 2.0 release we should create a 2.0-branch. This will be the production branch in which we only commit the bugfixes, and create versions 2.0.1, 2.0.2 etc.

Development can then continue in the "development" branch, until we decide its time for a 2.1.0 release. (which at that point also will become a bugfix branch, and perhaps we can then make 2.0.x obsolete)

This will make porting bugfixes between the development and production versions much easier, because we can let git do most of the work.

Currently our development branch is "mega", but perhaps its better to switch this back to "master" at some point, since this is also more common.

Sounds good?

Sounds good. I'm cleaning up the current issue list, moved some stuff from bug to enhancement and added the 2.1.0 milestone.
It's time to focus on bugs with the 2.0.0. milestone and get a beta version out...
(if we leave more room for enhancement in 2.0.0. we just never get there anyway...)

So we now have to decide on untagged issues if we can tackle those in 2.0.0. or the 2.1.0 milestone.

[psy0rz]

Yeah i saw you've been busy. Very nice.

So far, if i tagged it with 2.0.0 it meant i really wanted it to be fixed before that version can be released. These are probably only bugs that are fixable without adding a lot of new code.

Stuff that is not tagged with a mile stone is "to be decided"/"dont know"/"didnt read yet". We probably should scan all the issues to make sure we tagged everything that needs to be tagged for 2.0.0.

Maybe we should make a habbit of tagging ALL issues with a milestone? Perhaps we should create a special "other" milstone for stuff we dont know what to do with, or stuff that doesnt belong to a milestone. (like wiki documentation in some cases)

[grovkillen]

I wish we could have status of how many user there's out there but one indication is the number of stars on github. We have reached 500+ now over the weekend and if I remember correctly we have risen from 400 stars in just about a month. Great!

https://github.com/letscontrolit/ESPEasy/stargazers

[LisaM]

I wish we could have status of how many user there's out there but one indication is the number of stars on github. We have reached 500+ now over the weekend and if I remember correctly we have risen from 400 stars in just about a month. Great!

https://github.com/letscontrolit/ESPEasy/stargazers

I'm not surprised, i have looked long and hard to find anything simular to ESPEasy (8266 + wifi) and so far i haven't found it.It's like a HA Server for IOT devices and in that sense it's unique AND the first...

[grovkillen]

Yes, your point is probably a good reason of the popularity. Thanks!

[toffel969]

I wish we could have status of how many user there's out there but one indication is the number of stars on github. We have reached 500+ now over the weekend and if I remember correctly we have risen from 400 stars in just about a month. Great!

https://github.com/letscontrolit/ESPEasy/stargazers

I'm not surprised, i have looked long and hard to find anything simular to ESPEasy (8266 + wifi) and so far i haven't found it.It's like a HA Server for IOT devices and in that sense it's unique AND the first...

+1 to that. Before esp easy my homes automation plans always remained dreams. With esp easy it's a matter of few hours to build, implement and debug a node. Awesome!

[randytsuch]

I wish we could have status of how many user there's out there but one indication is the number of stars on github. We have reached 500+ now over the weekend and if I remember correctly we have risen from 400 stars in just about a month. Great!

https://github.com/letscontrolit/ESPEasy/stargazers

I'm not surprised, i have looked long and hard to find anything simular to ESPEasy (8266 + wifi) and so far i haven't found it.It's like a HA Server for IOT devices and in that sense it's unique AND the first...

+1 to that. Before esp easy my homes automation plans always remained dreams. With esp easy it's a matter of few hours to build, implement and debug a node. Awesome!

+2. Although I'm not as fast, takes me more than a few hours lol
But seriously I've been able to do so much with not much money because of ESP Easy, where I would have spend hundreds of dollars for commercial solutions.

[Martinus]

Has anyone noticed that today it's been a full year after we published R120 stable.

Although this could ask for a small celebration, it also indicates that we have not been able to release the next stable within a reasonable time frame...

[LisaM]

Has anyone noticed that today it's been a full year after we published R120 stable.

Although this could ask for a small celebration, it also indicates that we have not been able to release the next stable within a reasonable time frame...

I'm not worried about R120, rather then a new release for V1 i would want to have a release of V2 (mega)...
I've dev11 running in 7 places in my home, some running on Sonoff (basic, pow) and some on home made ESP boards. I also am readying V2 for two ElectroDragons.

I propose to promote the mega branch to master and release the next dev as ESPEasy R200 stable.

[LisaM]

With the ongoing development of ESP8266 MicroPython it's now in reach to rewrite ESPEasy in python. The ESP8266 hardware(with standard 8MB of flash memory on an ESP-01 module in Ali as latest record) is capable of supporting it although the minimum of 4MB should be required.
Performance test should be applied to verify if the performance is acceptable.

With using MicroPython, it would no longer be required to flash the ESP8266 other then to install MicroPython itself.ESPEasy python code should be in mainly two (fat) files: boot.py and main.py since micropython is using a fat filesystem after it becomes active. ESPEasy updates whould then mean to copy over some files and flash the firmware again. OTA, Serial and other update methods (with size limits) would no longer be required.
The rules section could become entirely python, giving a lot of additional options...

All pins except number 16 can be configured to trigger a hard interrupt if their input changes. You can set code (a callback function) to be executed on the trigger.

This will make ESPEasy a LOT easier, no need to run the loop() several times per second as we are currently doing...
Uart, i2c, spi, DHT and NeoPixels are all standard present in micropython.

[Shardan]

Be carefull with those ESP-01 with 8Mbyte shown at AliExpress.
It has shown that many of our chinese friends can't (or acidentally forgot to) differ between MBit and MByte
Every "8MByte" modul i tested showed up to be a 8MBit one....... in other words as a standard 1Mbyte type.

Give it a try.

[LisaM]

Be carefull with those ESP-01 with 8Mbyte shown at AliExpress.
It has shown that many of our chinese friends can't (or acidentally forgot to) differ between MBit and MByte
Every "8MByte" modul i tested showed up to be a 8MBit one....... in other words as a standard 1Mbyte type.

Give it a try.

Thx for the warning.
I don't need one at this point, the esp's with 4MB are good enough for me. If i need a lot of memory then i'll buy a wemos with 16MB.
Other option is to buy a pyboard for $15, it has a shitload of io-ports (30!), sd card and other ports and a LOT of flash/ram memory...
With micropython, ESPEasy is no longer bound to the ESP8266.

[Martinus]

All pins except number 16 can be configured to trigger a hard interrupt if their input changes. You can set code (a callback function) to be executed on the trigger.

This will make ESPEasy a LOT easier, no need to run the loop() several times per second as we are currently doing...

This is already in use for ESP Easy as well. Just look at the pulse counter plugin where interrupts are hooked up to callback functions. The main loop handles everything that is not interrupt based. But it remains a single threaded process so using something like RTOS would be better for this kind of projects.

But even when everything was irq based, beware that the ESP module can't access flash during irq handler and therefore all irq routines need to be stored in it's 32k instruction cache (IRAM). This is one of the major issues on the ESP8266 as well as it's limited 80k RAM that keeps us from building really powerful projects. Having 16MB flash is nice but this still doesn't mean that you can create huge projects for the ESP8266. Bottlenecks are RAM and IRAM and these can't be extended...

I think the LUA project has also struggled a lot with RAM issues... And so will likely any large interpreted environment suffer from the same RAM/IRAM limitations. Remember that the ESP8266 was actually never build with this in mind. Just a serial-wifi bridge...

[toffel969]

Maybe the micropython route is a good way to get esp easy to run on esp32

[LisaM]

Maybe the micropython route is a good way to get esp easy to run on esp32

And on a IO monster like this: https://www.aliexpress.com/item/STM32-S ... 71346.html

Code: Select all

1. STM32F405RG microcontroller
2. 168 MHz Cortex M4 CPU with hardware floating point
3. 1024KiB flash ROM and 192KiB RAM
4. Micro USB connector for power and serial communication
5. Micro SD card slot, supporting standard and high capacity SD cards
6. 3-axis accelerometer (MMA7660)
7. Real time clock with optional battery backup
8. 24 GPIO on left and right edges and 5 GPIO on bottom row, plus LED and switch GPIO available on bottom row
9. 3x 12-bit analog to digital converters, available on 16 pins, 4 with analog ground shielding
10. 2x 12-bit digital to analog (DAC) converters, available on pins X5 and X6
11. 4 LEDs (red, green, yellow and blue)
12. 1 reset and 1 user switch
13. On-board 3.3V LDO voltage regulator, capable of supplying up to 250mA, input voltage range 3.6V to 16V
14. DFU bootloader in ROM for easy upgrading of firmware

In my machineroom i have a need for a sensor array, dozens of sensors attached to one controller, this would make that possible...

[LisaM]

Outside temperatures are cooling over here, sitting allday outside in the sun is no longer possible. Time to get active again, bought an STM32.
The first python port will only be a espeasy skeleton, not doing much other then serving out webpages...

[toffel969]

Have you seen this one ? https://pycom.io/product/lopy/
Could it be an option?

[LisaM]

Have you seen this one ? https://pycom.io/product/lopy/
Could it be an option?

ESPyEasy will run on any soc that supports micropython, including the esp8266/esp32/stm32F405. Primary soc test platform is the nodemcu v3, offcourse since its python most of the development is done on a text editor (np++ in my case) and development testing done on a python browser version.
For performance reasons a frozen version might be needed, although the viper emitter might also be enough.

[vader]

Is the hype about the project already over? The only thing I can see running up are the issues.... And the intervals of new versions become longer and longer....

[toffel969]

Well then do something about it. I guess most devs have a real life to tend to/enjoy .... I spare the time I can to help on forum/wiki, as my coding sucks. I dont nearly put as much time into this project as many devs and I still find your statement a bit inappreciative.

[vader]

Don't misunderstand, I respect the hard work on it. I'm also not a professional programmer, but I dig in the source code to find bugs if something not expected happens. I posted some issues in the forum (I have no GitHub account) and mailed to the devs, but no response yet.

[grovkillen]

Don't misunderstand, I respect the hard work on it. I'm also not a professional programmer, but I dig in the source code to find bugs if something not expected happens. I posted some issues in the forum (I have no GitHub account) and mailed to the devs, but no response yet.

I understand your concern but I don't think it is abandoned at all. Many devs have vacations from their daily jobs and after getting back from that they have a lot of catching up to do. It's like this every September. I wouldn't start to worry until late October

[vader]

Ok, thanks for clearing this. I thought the main time for vacation is July to August. I forgot already what vacation is.....

[LisaM]

Is the hype about the project already over? The only thing I can see running up are the issues.... And the intervals of new versions become longer and longer....

I'm still working on ESPyEasy, the main core and plugins release will be a frozen module baked in the micropython firmware. It will also have a directory where you can dynamically add a plugin, so that baking a new firmware for new or changed plugins will be unnecessary. You drop the plugin python code on the share and it will pop up at the devices tab.
This is not going fast, since lately i'm completely buried under work by my employer...

[frank]

This is not going fast, since lately i'm completely buried under work by my employer...

I hope that your employer pays you a lot of money for this

[LisaM]

This is not going fast, since lately i'm completely buried under work by my employer...

I hope that your employer pays you a lot of money for this

A lot! And a headline in progress.

[psy0rz]

Yes, I was doing "vacation" stuff, like playing around with ESPEasy and creating a doorlock plugin (_P151_CISA.ino in the playground)

Currently i'm using ESPEasy nodes with domoticz to control access to my house and office doors, and i'm also building an alarm system with it.

Since i've started managing ESPEasy, I didn't actually get around to use it myself the way i wanted it.

Also sometime one need time to breath, like: http://theoatmeal.com/comics/creativity .

I'm back now, i'll be trying to do at least SOMETHING everyday to keep the project moving.

Current goal is releasing a stable 2.0.0 version, so only bugfixes will be merged.

Stuff that needs to be fixed for 2.0.0: https://github.com/letscontrolit/ESPEasy/milestone/1

I'm working through the notification backlog on github so it might take a couple of more days before i responded to all issues and pull requests.

[psy0rz]

Is the hype about the project already over? The only thing I can see running up are the issues.... And the intervals of new versions become longer and longer....

I'm still working on ESPyEasy, the main core and plugins release will be a frozen module baked in the micropython firmware. It will also have a directory where you can dynamically add a plugin, so that baking a new firmware for new or changed plugins will be unnecessary. You drop the plugin python code on the share and it will pop up at the devices tab.
This is not going fast, since lately i'm completely buried under work by my employer...

LisaM is your code on github somewhere? I also think micropython is the way to go in the future. It solves a lot of issues and its very platform independent.

[LisaM]

LisaM is your code on github somewhere? I also think micropython is the way to go in the future. It solves a lot of issues and its very platform independent.

Not yet, i'm still busy with the main core outline and collecting and assembling all standard components.
Basic principle is to do as little programming as possible:
- Allow for standard modules (plugins) with an easy override, meaning that if you put (drag 'n drop in a plugin directory in the pybflash share) the same module customized in a directory it will use that module (plugin) instead of the frozen one. This enables to use a standard (frozen) core (firmware) together with customised plugins, lowering the need for baking firmwares.
- Use picoweb for webserver. Using picoweb means no longer fixed html but customizable webpages, where the standard templates are in the frozen module with an override possibility in a pybflash directory similar to that of plugins. It will support i18n, javascript, css, images and many more.
- Lan/Wlan transparency , either can be chosen depending on the hardware available (IF there's a choice, when the hardware isn't there the choice is greyed out). I have an PyBoard connected to a W5100 using Lan, while the NodeMCU is using WLan without any changes to the code.
- The ESPEasy core will be COMPLETELY rewritten, micropython already has a lot of standard modules that can be reused, but most IDEAS in the ESPEasy are used as foundation in either searching for an existing solution or as a base for writing a new module!
- Rules are written in Python in separate files called scripts in a pybflash directory, exception protected, and no longer in the ESPEasy language. There's no limit other than that what the hardware can handle, like memory constraints.

Please let me know if you have more requests to include in the core!

The performance of ESPyEasy is a little less then that of EspEasy on equal hardware (NodeMCU) but since it can also run on faster platforms like ESP32 and PyBoard which have faster SOC's the difference is no big deal anymore. The PyBoard has an enormous amount of GPIO's and other features, which makes this platform superior to that of the ESP8266. The range of platforms where ESPyEasy can run on is limited only by micropython, complex setup's will problably run on pyboard, wipy or ESP32 or equals and more simple ones on ESP8266.

My $20 (AliExpress) ESPyEasy development environment:

IMG_3014.JPG (1.65 MiB) Viewed 62859 times

Development has become very easy, just drag 'n drop the new code in the pybflash share and run it from putty...

[frank]

this looks great LisaM. And a lot of IO. What kind of network shield are you using?

[LisaM]

this looks great LisaM. And a lot of IO. What kind of network shield are you using?

A W5100, but it isn't working properly with the micropython wiznet5k driver so i ordered a W5500.
The used PyBoard: https://www.aliexpress.com/item/STM32F4 ... 29035.html

[LisaM]

There are some brutal monster SOC boards out there, all supporting micropython. Here is an ADC comparison:
'ADC_loop' with 20 thousand readings, mean speed in ksample/s :
* Pyboard v1.1 (12 bits ADC) with MicroPython v1.8.6 : 34.9;
* Pyboard Lite v1.0 (12 bits) with MicroPython v1.8.6 : 20.1;
* WiPy 1.0 (12 bits) with MicroPython v1.8.2-103 : 62.5;
* ESP8266 (10 bits) with MicroPython v1.8.6-7 : 5.44 (80 MHz) / 7.34 (160 MHz);
* BBC Micro:bit (10 bits) with MicroPython v1.7.9 : 6.51;
* LoPy (12* bits) with MicroPython 0.9.6.b1 : 21.2.
* WiPy2 (12* bits) with MicroPython 0.9.6.b1 : 21.3.
* Teensy 3.2 (16 bits) with MicroPython v1.8.6 : 59.6;
* Teensy 3.5 (16 bits) with MicroPython v1.8.6 : 62.3;
* Teensy 3.6 (16 bits) with MicroPython v1.8.6 : 107.

A Teensy is at least 10 times faster then a ESP8266...

[frank]

that are some great boards but expensive compared to esp 8266 boards