ESP32-sveltekit POC

[ewowi]

Hi theelims,

I am playing with your ESP32 SvelteKit repo and I am impressed with the quality and features of it. I am considering using it to port my StarBase and StarLight projects to it, which are spin offs of WLED / WLED MoonModules.

I set up a fork for this called MoonBase to do a proof of concept (POC).

I have a number of questions / remarks / observations:

• Are you aware of more people working with it. I checked the current forks but except leokeba, I did not find a lot of activity. Is there a discord server or another platform where users can exchange information?
• What are the current plans? One of the first things I would like to setup is a files manager. As I use littleFS to store fixture definitions. Is that also on your list? I was thinking to setup a rest api to exchange the contents of the file system with the client. Is that the right approach? Do you have some hints how to do it? Of course I am more then happy to PR it back if you are interested.
• if I understand correctly loops run at 20ms. Which is a system I also use, except for effect loops which can run at 130 fps (or more in some cases), any hints how to setup high speed loops?
• I see cache has max-age=31536000. For development I want to see changes immediately. So I commented that statement for now, might be good to have that conditional.
• I was wondering why PsychicHttp is not a lib dep in Pio.ini but the code is copied in the repo. Is this done for a reason? (latest version is v1.2.1, included version is 1.0.1)
• It looks like it is not always working well in Safari (while it is running fine in Chrome). Eg refresh races occur. I need to investigate why exactly.
• There are a number of warnings during svelte compile (most is export let data / unused export property). Is that expected behavior?
• Passwords are not obfuscated (example /rest/wifiSettings)
• 🆕: impact of icons and png files on firmware size. Should be a few kb max. Will that be more when adding menu options each with its own icon?
• 🆕: does a device need internet connection to show the UI or is all (javascript) code included in the firmware. Maybe related to the cache max-age. I Will test this

I hope you can help me a bit. Maybe some of the points are just because I made a setup error or because I am just starting to play with your repo. I RTFM but maybe I need to read it again / better 🙂.

Thanks in advance,
Ewoud

[theelims]

Hi,

Great to see your interest in this project. It has seen some adoption and interest and I use it in various projects myself.
I'm on vacation right now.

I'll get back to your questions next week. I do like to develop it further and am looking for collaborators.

[ewowi]

Thanks @theelims. I will continue playing the coming days ;-). If the POC will be successful I have a lot to add. One chain of forks can be ESP32-sveltekit -> MoonBase -> MoonLight as I have StarBase -> StarLight now where StarBase is a general IOT solution. As ESP32-sveltekit is also that it might eventually just be ESP32-sveltekit -> MoonLight.

Things I have in StarBase now:

• File Manager
• Instance manager (multiple ESP's seeing each other and able to control / coordinate each other)
• Pin Manager
• Print / Log manager (redirect Serial output to the UI)
• Gyro / MPU6050
• E131 / DMX
• ESP Live Scripts: C-like scripting language compiled to assembler without the need to reboot or update firmware

StarLight

• FastLED integration
• Physical LED driver and Virtual Led driver
• 1D/2D/3D Led fixture system with preview (Using Three.js)
• 1D/2D/3D Effects and Projections
• 1D/2D/3D coordinate and mapping system
• Live Fixtures and Live Effects using ESP Live Scripts
• Art-net / DDP
• Audio Sync from WLED device (Native Audio support for Sound Reactive effects is planned)

Not to brag about it, but also for me to get the scope right ;-). So StarBase might partly move to ESP32 SvelteKit and MoonBase and StarLight might move into MoonLight (assuming all these Star/Moon/Base/Light names will stay the same)

[ewowi]

@leokeba , I also uploaded your fork but it needed i2s or i2c devices to boot up properly. I didn't look into detail in your fork but saw that you use sensors/ gps so probably thats the reason.
See my questions above, if you have some thoughts happy to hear them too ;-)

[theelims]

Not to brag about it, but also for me to get the scope right ;-). So StarBase might partly move to ESP32 SvelteKit and MoonBase and StarLight might move into MoonLight (assuming all these Star/Moon/Base/Light names will stay the same)

My intention is to have ESP32-sveltekit as an universal foundation for a wide variety of IoT projects. Not only LED based ones. I'm happy to accept PRs for more universal features like:

• file manager
• instance manager, to coordinate between devices
• scripting capabilities including web editor

I was experimenting with berry-lang, but couldn't get it to work properly.

[ewowi]

My intention is to have ESP32-sveltekit as an universal foundation for a wide variety of IoT projects. Not only LED based ones. I'm happy to accept PRs for more universal features like:

• file manager
• instance manager, to coordinate between devices
• scripting capabilities including web editor

I was experimenting with berry-lang, but couldn't get it to work properly.

Yeah, fully agree! I am happy to help here. Will try to set it up in my repo and show you the results later.
Currently re-reading your documentation and making new commits on the MoonBase repo based on this, so I guess I will slowly learn to add a Files module ;-)

[leokeba]

Hi everybody,

Happy to see more people interested in contributing to this project, I really think it is one of the most solid and well featured templates for embedded devices out there.

My first fork is a bit messy at the moment, I was mostly using it to create feature branches for different hardware or software integrations needed for my personal projects, maybe some of them could be upstreamed at some point but most of them will be too specific to belong here I think.

There are, however, a few features or ideas I have playing around with that I think could be of interest to others at some point in the future, if properly implemented :

• Building a "dynamic" library of basic UI components (sliders, text inputs, generic forms, buttons, etc.) and defining a json scheme enabling dynamically loading frontend UI elements from the backend. In many simple cases, this could obviate the need to write new svelte components for small and simple projects, allow faster iteration and present a simpler paradigm for projects that don't need very rich or complex interfaces.
• In the same spirit of decoupling / modularising the frontend and backend and possibly building on the previous point, I think it could be interesting to add a few different json endpoints, or maybe a generic one to build on, allowing to use other protocols or pipes to communicate between the UI and the devices. For example, I would like to be able to have a fleet of devices connected to a kind of master using a wired protocol like CAN BUS, with all the controls in the master UI, and possibly allowing the slave devices not to host any frontend data. I think this could be a really powerful paradigm coupled with the previous point.
• I also build a sort of POC allowing to define a hierarchically structured json endpoint where you can basically define the whole application state and get it all at once, or query any subsection of it. This works using a wildcard URL and parsing every "/" to build a subpath, returning only what's needed. It is a bit unorthodox to say the least, and also quite more memory and compute heavy than the standard way (we need to manipulate big JSON documents), but it's really powerful, flexible, and it composes well with the two previous ideas. Here's where I am using it : https://github.com/open-heliostat/open-heliostat/

I will keep working on some of those ideas for my projects anyway, for now everything is a bit messy and the naming is all over the place, but if people are interested I will try to clean all of this to the best of my ability and maybe submit a PR one of those days.

I see that @ewowi mentions the idea of an instance manager, which seems somehow similar to my second point, so I am curious about how this could be implemented ?

The file manager was also on my radar, and I think if we can ship a json editor with it to be able to modify / import / export config files it could be super useful. The embedded scripting language would also be a killer feature IMO, although probably more niche than others.

[theelims]

@ewowi Finally I am back home and can comment comprehensively.

• Are you aware of more people working with it. I checked the current forks but except leokeba, I did not find a lot of activity. Is there a discord server or another platform where users can exchange information?

As already mentioned, there are a number of projects using this. It has gained some traction over the last months. There is no discord server yet. I am active on discord and we can chat there, if you like.

• What are the current plans? One of the first things I would like to setup is a files manager. As I use littleFS to store fixture definitions. Is that also on your list? I was thinking to setup a rest api to exchange the contents of the file system with the client. Is that the right approach? Do you have some hints how to do it? Of course I am more then happy to PR it back if you are interested.

A file manager with scripting capabilities and built-in editor. I experimented with berry-lang (used by tasmato), albeit with no success so far. I would've set-up psychichttp to serve from a folder of the file system to serve the files. Then a service sending the content of that folder as json (path, names, extensions, dates, ...) and a third service for uploading a file with the path and other context in the search path.

• if I understand correctly loops run at 20ms. Which is a system I also use, except for effect loops which can run at 130 fps (or more in some cases), any hints how to setup high speed loops?

Well, the ESP32-Sveltekit loop runs in its own dedicated task. The http server lives in the ESP-IDF core probably with an own task, too. You can implement your business logic in any task you like. Arduino uses a 1 ms tick for the FreeRTOS scheduler.

• I see cache has max-age=31536000. For development I want to see changes immediately. So I commented that statement for now, might be good to have that conditional.

I had no issues with this so far. Development takes place from the vite development server in 99% of cases anyway. And when I tested on device I had no issues with an outdated cache.

• I was wondering why PsychicHttp is not a lib dep in Pio.ini but the code is copied in the repo. Is this done for a reason? (latest version is v1.2.1, included version is 1.0.1)

PsychicHttp requires some patches to work. I am actively monitoring the progress of PsychicHttps' development and had planned to port it over to their 2.0 plans. As this will see some API changes. Also there is currently a esp-arduino mess with pio. The whole situation doesn't seem stable enough to justify the effort. I would love to got to ESP-IDF v5.

• It looks like it is not always working well in Safari (while it is running fine in Chrome). Eg refresh races occur. I need to investigate why exactly.

I don't have Apple products so I can't test. If you can fix this please make an PR.

• There are a number of warnings during svelte compile (most is export let data / unused export property). Is that expected behavior?

I am not a professional software dev and I used this project to learn JS/TS. If you can fix this I happily accept an PR.

• Passwords are not obfuscated (example /rest/wifiSettings)

Yes, I am aware of this. I would love to have HTTPS enabled. But this is not yet solved satisfactorily in PsychicHttp. HTTPS requires tons of RAM and is currently limited to 2 connections only. It must be offloaded to PSRAM. Once PsyhicHTTP is there I plan to implement this.

• 🆕: impact of icons and png files on firmware size. Should be a few kb max. Will that be more when adding menu options each with its own icon?

As long as icons are SVG there is neglect-able impact on the binary size. Bitmaps on the other end should be avoided.

• 🆕: does a device need internet connection to show the UI or is all (javascript) code included in the firmware. Maybe related to the cache max-age. I Will test this

It is all self contained and served from the ESP. It was one requirement to not require internet to make it work. This requires caution on selecting JS packages. Heavy stuff like three.js forbid themselves.

[ewowi]

Thanks @theelims and @leokeba for your elaborate comments! I will respond to all of them the coming time!

Today I made a first setup for files using restful api:

MoonModules@da8d292

it's beginners work in progress though, but it looks already very professional ;-) :

[theelims]

Happy to see more people interested in contributing to this project, I really think it is one of the most solid and well featured templates for embedded devices out there.

• Building a "dynamic" library of basic UI components (sliders, text inputs, generic forms, buttons, etc.) and defining a json scheme enabling dynamically loading frontend UI elements from the backend. In many simple cases, this could obviate the need to write new svelte components for small and simple projects, allow faster iteration and present a simpler paradigm for projects that don't need very rich or complex interfaces.

Before creating ESP32-sveltekit I used a framework which had such a feature. I found it hard to use and very limiting. ESP32-sveltekit was born out of the frustration with such a framework. I concluded that Svelte and JS are easy enough to learn. Just look at the Lightstate example and copy the pattern.

• In the same spirit of decoupling / modularising the frontend and backend and possibly building on the previous point, I think it could be interesting to add a few different json endpoints, or maybe a generic one to build on, allowing to use other protocols or pipes to communicate between the UI and the devices. For example, I would like to be able to have a fleet of devices connected to a kind of master using a wired protocol like CAN BUS, with all the controls in the master UI, and possibly allowing the slave devices not to host any frontend data. I think this could be a really powerful paradigm coupled with the previous point.
• I also build a sort of POC allowing to define a hierarchically structured json endpoint where you can basically define the whole application state and get it all at once, or query any subsection of it. This works using a wildcard URL and parsing every "/" to build a subpath, returning only what's needed. It is a bit unorthodox to say the least, and also quite more memory and compute heavy than the standard way (we need to manipulate big JSON documents), but it's really powerful, flexible, and it composes well with the two previous ideas. Here's where I am using it : https://github.com/open-heliostat/open-heliostat/

On the one side I want ESP32-Sveltekit to be as much "with batteries included" as possible. On the other side I want it to be as sleek and easy to maintain as possible. The compiler flags in features.ini give it also some flexibility on what parts to include. However, one requirement I have is that is must run feature complete on a typical ESP dev board. So no special hardware dependencies in the core. Personally I have a number of services in a private repository which I commonly need in my projects but deem not worth to be included in the core. Like a heartbeat service.

[ewowi]

There are, however, a few features or ideas I have playing around with that I think could be of interest to others at some point in the future, if properly implemented

@leokeba , the ideas you post here are pretty much what I have done with StarBase and StarLight. As I wanted to make it possible to extend the app without writing any html code (as this is my weak point ;-). Only thing is I had to write it once for any button, any input field, any ...
So what I do is that the app builds up and maintains a json file with all the definitions. See model.json. As I initially intended to make a windows based UI (inspired what my synology NAS has). The result upon today is a half finished UI (this is StarBase, StarLight have even more windows):

The javascripts receive the model.json and build this completely. I get used to work with this UI as I see everything happening all the time, but this is the main bottle neck for users wanting to work with Star as it is overwhelming, and that was the reason I looked for alternatives and found ESP32-sveltekit.

I think you were looking for a similar mechanism (model driven ui). I think we can look what we can do in ESP32-sveltekit, but I also agree with @theelims that we need to be careful to not over engineer. Maybe have some more powerful general classes we can inherit from. But my pitfall is over-engineering so I try to be as practical as possible and at least work in the spirit of the design rules of the esp32-sveltekit ;-)

[ewowi]

I see that @ewowi mentions the idea of an instance manager, which seems somehow similar to my second point, so I am curious about how this could be implemented ?

See Instance Module for what I made in Star (this is the documentation which needs a lot of catching up by the way). You see on this page a table of instances, unfortunately only one shown here, but it will show all Star and WLED devices in your local network.

The idea originated from WLED (MoonModules version especially) where each esp32 broadcasts udp packages with their info and other instances receives this info. Furthermore instances sends an udp message if something changes and other instances can be in sync mode and then will do the same (e.g. if brightness is changed in one, the brightness of the synced devices will also change).

I started in WLED MoonModules something we called SuperSync, where there is also synchronised time (ms accuracy) and synchronised randomness (so not really random ;-). By this more then one instance can run the same effect and each instance only drives leds for their part of the effect. Idea is that many instances, each with their own leds can show part of an effect. This in turn is inspired by drone shows where multiple drowns make up one big effect.

Basic (super)sync functionality is something I will for sure port over. Starting with udp based broadcasting so each instance can show the other instances

[ewowi]

The embedded scripting language would also be a killer feature IMO, although probably more niche than others.

It absolutely is. @hpwit made this and we currently run 12288 leds @ 80-120 frames per second on one ESP32!!! So it's a killer feature but the performance of it makes it a killer-killer-feature !!

It might be niche, but maybe less niche if you realise you can read from any pin and write to any pin so it's also ideal for prototyping or simple (and also complex) applications. E.g. the blinking led example can easily be made here. And if you want to play with pir sensors, or step motors or whatever sensor / actuator, you can just test it using Live Scripts.

[ewowi]

I am active on discord and we can chat there, if you like.

Let's do it, I am ewowi there. (but not a lot of time to talk in 2024 ;-) )

I would've set-up psychichttp to serve from a folder of the file system to serve the files.

Yeah, did the same in StarBAse

Then a service sending the content of that folder as json (path, names, extensions, dates, ...)

Done yesterday in MoonBase repo

and a third service for uploading a file with the path and other context in the search path.

To do

You can implement your business logic in any task you like.

Check

Development takes place from the vite development server in 99% of cases anyway.

learned to use that yesterday, which is great !

And when I tested on device I had no issues with an outdated cache.

Maybe one of my browser settings, I have that all the time when I cache pages and change the UI -> I see the old UI

PsychicHttp requires some patches to work

Did you consider to make a local fork of PsychicHttp (theelims/PsychicHTTP) and do your changes there, so you will keep the connection with the upstream PsychicHttp repo.

Also there is currently a esp-arduino mess with pio. The whole situation doesn't seem stable enough to justify the effort. I would love to got to ESP-IDF v5.

I don't have Apple products so I can't test. If you can fix this please make an PR.

Okay

There are a number of warnings during svelte compile (most is export let data / unused export property). Is that expected behavior? I am not a professional software dev and I used this project to learn JS/TS. If you can fix this I happily accept an PR.

I will look to it. Wow you are a good learner then, I am also no professional software dev, actually a lot of the people I work with aren't and still great products are made ;-)

Passwords are not obfuscated (example /rest/wifiSettings) HTTPS enabled.

I am thinking of making a (very) simple obfuscation algorithm, so not be depending on HTTPS. Main reason is that json files with passwords in it are shared during development and have a simple variation is already enough then.

As long as icons are SVG there is neglect-able impact on the binary size. Bitmaps on the other end should be avoided.

Perfect

It is all self contained and served from the ESP. It was one requirement to not require internet to make it work. This requires caution on selecting JS packages. Heavy stuff like three.js forbid themselves.

I use three.js (cached from the internet yeah ;-) ) for preview of leds, so I contradict myself but in this specific case I have no alternative (other then just not show the preview if not found in browser cache)

[theelims]

I started in WLED MoonModules something we called SuperSync, where there is also synchronised time (ms accuracy) and synchronised randomness (so not really random ;-). By this more then one instance can run the same effect and each instance only drives leds for their part of the effect. Idea is that many instances, each with their own leds can show part of an effect. This in turn is inspired by drone shows where multiple drowns make up one big effect.

Basic (super)sync functionality is something I will for sure port over. Starting with udp based broadcasting so each instance can show the other instances

This would be a feature I am highly interested in. One of my applications requires syncing devices in the low ms range. Also it would be interesting to sync various devices of different categories without one being the obvious master. Just a bunch of IoT devices coordinating between each other.

[ewowi]

without one being the obvious master

thats exactly what I did, I also didn't want one master. We can discuss how to add it, the basic code is in StarBase already

Update: code is in SysModInstances
Instances have a name if the name contains an _ it is part of a group so if you have

sticks_stick1
sticks_stick2
lab_esp1
lab_esp2
lab_esp3
cube_node1

then the 2 sticks are synchronised and the 3 lab instances also, cube_node1 is a group of 1 instance. Idea is that the system dynamically adapts, if lab_esp3 is removed, 1 and 2 continues, if lab_esp4 is added the group is increased