ESP Easy development status

[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 93283 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

[psy0rz]

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:
...snipsnip

Sounds very good! Offcourse, like you said, it will be a redesign from the ground up, and we will have to port/reimplement each and every module.
I also have a lot of experience with python, so i'm willing to help in the future once things start taking shaping. (and espeasy is stable and doesnt need lots of love and attention anymore )

In the mean while we'll keep maintaining espeasy offcourse.

[LisaM]

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

I also have it working on a ubuntu i5/16GB server, so a $6 raspberry pi zero should be possible to...
With a 1GHz cpu, 512MB memory and 40-pin GPIO the pi zero might be an interesting platform.
When booting from sd card, converting a part of the memory to an ramdrive and copy everything in there it might just shatter every SOC speed record when using a 1GHZ cpu. In-memory computing is hot these days...

[Shardan]

For about 95% of my sensors a pi zero is pure overkill.

As long as it still runs on an esp, fine.
If not.....

[LisaM]

For about 95% of my sensors a pi zero is pure overkill.

As long as it still runs on an esp, fine.
If not.....

There is no such thing as overkill...
Several of my sensors need to be AI Nodes forming a decentral neural network.

[Shardan]

Clearly everybody needs a 32GPIO monster to switch a ceiling light or read a temperature sensor.

YOU may need that. But what about those who don't? Don't throw all those users into the garbage who needs less and don't use a fat energy wasting ubuntu server at home.

And by the way if i ever need that i have a better way with much more possibilities then using espeasy. As i'm using fhem i coulld make a slave installation on another RPi for example connected to the main fhem RPi with all possibilities fhem offers.

Just this is overkill for swithicg a light or reading some sensors.

[BertB]

+1 for the first part.

[LisaM]

Clearly everybody needs a 32GPIO monster to switch a ceiling light or read a temperature sensor.

YOU may need that. But what about those who don't? Don't throw all those users into the garbage who needs less and don't use a fat energy wasting ubuntu server at home.

And by the way if i ever need that i have a better way with much more possibilities then using espeasy. As i'm using fhem i coulld make a slave installation on another RPi for example connected to the main fhem RPi with all possibilities fhem offers.

Just this is overkill for swithicg a light or reading some sensors.

Don't worry, scaling down is a lot easier then scaling up...
And... nobody is forcing you to use it.

Ps. i have domoticz and i stopped believing in star configurations like fhem or domoticz. A node based configuration with inter-node communication enables gradual degradation where a single node failure has very limited impact (in constrast to single point of failure like domoticz). It also means that the nodes need to have more functionality then a simple on or off. Reason why i'm phasing out z-wave, since it doesn't provide enough node based logic.
For example: node can only switch on the ceiling light IF it's dark AND somebody is detected in the room...

[BertB]

And... nobody is forcing you to use it.
[/quote]

Now this is not necessarily true, is it?
I mean, it is often so that development on older technologies grinds to a halt, when a new development gains in popularity.
I do not need the muscle power to swich a light or to tell me the temperature in the garden.
So yeah, this tendency worries me a bit. I have spend a lot of time and money creating stuff with ESPEasy and to be honest, I hate the thought that it will all be lost.

[LisaM]

Now this is not necessarily true, is it?
I mean, it is often so that development on older technologies grinds to a halt, when a new development gains in popularity.
I do not need the muscle power to swich a light or to tell me the temperature in the garden.
So yeah, this tendency worries me a bit. I have spend a lot of time and money creating stuff with ESPEasy and to be honest, I hate the thought that it will all be lost.

Don't worry, the Py version will run on the same hardware (well maybe not the 512KB version, since that's not supported by uPy).
The Py version will be portable, enabling a lot more platforms. You can make it as simple or complex as you want, the reason for the Py version is flexibility...
I'm developing it on a fast ubuntu server since the dev cycle is soooooo much faster then on a soc. I can develop, test and develop in just seconds on ubuntu, the server does a complete make build and run in just below 10 seconds, compared to hours on a soc (building firmware, loading it on a nodemcu, test it, find little debug info, etc). On ubuntu the image size of micropython with frozen modules is currently just 433KB, plenty of room left!
The dev hardware cycle is: ubuntu -> pyboard -> nodemcu -> Esp01 (with 1MB+)
I also have a few sonoff module's i don't want to lose, it's in my own interest to keep supporting smaller soc's...

[BertB]

I also have a few sonoff module's i don't want to lose, it's in my own interest to keep supporting smaller soc's...

That's always the best warranty ...

Okay, I am kind of convinced. But, what does it do with the speed of the ESP?
In the end, uPython is an interpreter language no? Like good old basic?

[Martinus]

Just wondering if the ESP8266 will have sufficient RAM to run both the microPython engine and a large project like ESPEasy?
I've just installed microPython and without any 'sketch' there's only 26k left (?)

[psy0rz]

lisam, is it possible to use 3rd party libraries like adafruit or IR in micropython? i know its possible with normal python to link against c-stuff, i was wondering how that works with micropython? can you just upload the .py file plus a object-file?

regarding size: i also dont like overkill for hardware, but on the other hand: stuff gets cheaper and more resources all the time. i think the esp32 is almost as cheap as the esp8266 already. we also have to develop with the future in mind: the next 2 or 3 years there will probably lots of new powerfull and cheap hardware to choose from. there's a big chance that most of them will support micropython.

regarding speed: python is indeed orders of magnitude slower than regular c. but in practice this is no problem: low level stuff like networking is still handle by very efficient C code in python. if we need high speed for some device: normally is possible with python to still use C for those parts.

also i think its possible to let espyeasy download a plugin from internet realtime. this way the user can only "install" the needed plugins via the same webinterfaces. and even update plugins via the webinterface.

edwin

[LisaM]

Just wondering if the ESP8266 will have sufficient RAM to run both the microPython engine and a large project like ESPEasy?
I've just installed microPython and without any 'sketch' there's only 26k left (?)

What you probably see is just the stack, uPyEasy modules are not stored in there but are 'Frozen' modules. Frozen means that the modules become part of the micropython firmware (that what i'm currently also doing with all the other standard micropython modules like picoweb to). It still gives you the ability to add additional modules/python programs, but eat up the stack (which is not what you want to do on a large scale in limited environments like the ESP8266).

[LisaM]

uPyEasy is overwhelming this thread, shall we continue here: viewtopic.php?f=14&t=3577&p=19287#p19287

[grovkillen]

Ok, I just want to mention that I'd prefer if we (with "we" I mean the developers) focused a bit on closing the issues found in the milestones of v2.0.0. I'd like us to squash "all" the bugs and release it to the crowd.

https://github.com/letscontrolit/ESPEasy/milestone/1

Do I hear a "YES we can!"?

[Shardan]

+1

[JR01]

Instead of micropython, has anyone looked at golang’s gobot, seems they are pushing multi-platform, even has stuff for esp8266.

https://gobot.io/documentation/platforms/esp8266/

[vader]

I do not understand all that doing. Before fixing all the known issues, the devs start working on implementing new CPUs like ESP32 and whatever we normal user don't need (yet)! We want a firmware that works without all that bugs! That doing remembers me at Micro$oft, that makes all of us to beta testers with unfinished and crappy products. So keep the focus on a bug-free firmware first!!!

[TD-er]

I do not understand all that doing. Before fixing all the known issues, the devs start working on implementing new CPUs like ESP32 and whatever we normal user don't need (yet)! We want a firmware that works without all that bugs! That doing remembers me at Micro$oft, that makes all of us to beta testers with unfinished and crappy products. So keep the focus on a bug-free firmware first!!!

The development of ESP32 is being done on the "mega" branch. So it is for the new stuff after this release.
At this moment there is a 2.0 branch which contains all that is going to be in the new upcoming release.

My personal preference would be to develop the ESP32 support into a separate branch and then merge into mega, but that is just one of the many flavors in software development and branching strategies.

Typical development is one master branch (which is called 'mega' here at the moment) for which new features are developed.
The feature-freezes are then split into a separate branch which only have bugfixes.

[grovkillen]

Spot on TD, we need a strategy for the branches and releases.

[Shardan]

+1

[papperone]

I do not understand all that doing. Before fixing all the known issues, the devs start working on implementing new CPUs like ESP32 and whatever we normal user don't need (yet)! We want a firmware that works without all that bugs! That doing remembers me at Micro$oft, that makes all of us to beta testers with unfinished and crappy products. So keep the focus on a bug-free firmware first!!!

The development of ESP32 is being done on the "mega" branch. So it is for the new stuff after this release.
At this moment there is a 2.0 branch which contains all that is going to be in the new upcoming release.

My personal preference would be to develop the ESP32 support into a separate branch and then merge into mega, but that is just one of the many flavors in software development and branching strategies.

Typical development is one master branch (which is called 'mega' here at the moment) for which new features are developed.
The feature-freezes are then split into a separate branch which only have bugfixes.

The more I study ESP32 architecture the more I think that a simple "porting" won't be using full chip capabilites...
Specially now that Espressiff provided RTOS functionality with possibility to run code on both cores in parallel, but this will require major modification to ESPEasy I guess

[LisaM]

The more I study ESP32 architecture the more I think that a simple "porting" won't be using full chip capabilites...
Specially now that Espressiff provided RTOS functionality with possibility to run code on both cores in parallel, but this will require major modification to ESPEasy I guess

Yep, the Espressiff ESP32 libs are completely different from the Espressiff ESP8266 libs. I looked at it and gave up the hope of ever uniting both ESP platforms. Even for micropython they are taking some time to develop micropython on a ESP32 with a complete team. They now have a multi threaded micropython and capable of using 4MB of psRAM (yes 4MB of free ram instead of 80KB...)

And even if you succeed, it's not async so not benefiting from the dual core. uPyEasy is async from the beginning, meaning the webserver can handle one request on one core and the other core can handle the IO. Arm soc's like the STM32 series are now also available in dual-core (cortex-r4). The $10 OrangePi is another competitor with loads of cores and IO available.

If i need this kind of power? For most apps not, but for some controls in my house (CO2, heating) it's even essential. I need a LOT more local node power to do AI, inter-node communication, wifi mesh networking, etc. None of that can be done with the current limited capabilities of ESPEasy.

For an ESP-01 all of this might not matter, but even the mighty ESP-01 doesn't live forever...

[Martinus]

I do not understand all that doing. Before fixing all the known issues, the devs start working on implementing new CPUs like ESP32 and whatever we normal user don't need (yet)! We want a firmware that works without all that bugs! That doing remembers me at Micro$oft, that makes all of us to beta testers with unfinished and crappy products. So keep the focus on a bug-free firmware first!!!

Hardly any code development has been done, nor is it planned for ESPEasy on ESP32 (unless some developer volunteers?)
Current changes to the mega dev branch are limited to some precompiler directives to select the ESP32 specific libraries and function calls. Mainly because they were named ESP8266xxx and now ESP32xxx or ESPxxx....

All all the actual hard work on ESP32 Arduino core is done by other developers (me-no-dev as lead developer).
Their aim is to get typical Arduino sketches to run on ESP32.

And ESPEasy actually runs on ESP32 as we speak.

Because of me-no-dev and his team...

(to avoid possible confusion, me-no-dev and co-developers are not members of the ESP Easy team, so we can't influence their work. In case one doubts the usefulness of their work on ESP32, better ask them directly)