theelims / ESP32-sveltekit

A simple and extensible framework for ESP32 based IoT projects with a feature-rich, beautiful, and responsive front-end build with Sveltekit, Tailwind CSS and DaisyUI. This is a project template to get you started in no time with a fully integrated build chain.
https://theelims.github.io/ESP32-sveltekit/
Other
103 stars 18 forks source link

initial arduino-3 support #59

Open mhaberler opened 1 month ago

mhaberler commented 1 month ago

I like your project because it is a low-baggage starter to an esp32+webapp

I made it (mostly) work with arduino-3, in particular the pioarduino fork: https://github.com/pioarduino/platform-espressif32 (official esp32 Arduino at platformio is rotting away at arduino2 and currently no prospects for change, see https://github.com/espressif/arduino-esp32 and https://github.com/platformio/platform-espressif32/issues/1225)

you can see the changes here:

PsychicMqttClient: https://github.com/mhaberler/PsychicMqttClient/commits/main (needs love for ESP-IDF 4/Arduino2 backwards compatibility) ESP32-sveltekit https://github.com/mhaberler/ESP32-sveltekit-test/commit/af2a545c765287f80fb61fcffe3119f767174281

let me know if you are interested in adopting those

my eventual goal is to integrate the PicoMQTT broker (https://github.com/mlesniew/PicoMQTT) which starts to work with PsychicHttp and MQTT-wss (https://github.com/mlesniew/PsychicWebSocketProxy)

is that of interest? in that case I'd look into adding to the framework for configuration

best regards

Michael

theelims commented 1 month ago

I am wrapping my head around this problem since a while. I need to go to ESP-IDF 5 to finally implement my WS client library based on the ESP-IDF ws client. This is completely bugged in ESP-IDF4. Also I would love to use the C6 instead of the C3.

I am aware of the dead end between espressif and platformio. I do not expect anything in this regard. However, arduino-esp32 has also made some controversial design considerations which make it impossible to use esp-nimble: https://github.com/h2zero/NimBLE-Arduino/issues/685 and https://github.com/espressif/arduino-esp32/issues/9835 https://github.com/espressif/arduino-esp32/discussions/9836

So instead of using the pioarduino fork I would rather use the Tasmota fork: https://github.com/tasmota/platform-espressif32

Another option would be to use Arduino as a library. Long story short, I am very willing to accept pull requests for Arduino3.

In regards of PsychicMQTTClient I would just release a new version which is based on IDF5 and not bother with backwards compatibility. As long as the API does not change in a breaking way this will be transparent for the user. I think it is only used in conjunction with ESP32-sveltekit anyway.

The only reason to use PicoMQTT is the broker it offers. Even though I considered using this in one project I do see this outside the scope of ESP32-sveltekit.

I haven't checked your repositories yet, but would be very happy if we could join forces on this.

Kind regrads elims

mhaberler commented 1 month ago

good, I do not think Arduino2 backwards compat matters much anymore either

I'd have to switch to HTTPS for my plan to work - is a conditional build acceptable to you?

re Nimble: I'm using Nimble-Arduino master just fine with Arduino3 - what exactly is the issue?

I understand the authors of pioarduino and Nimble-Arduino are in close cooperation - maybe stop by at the pioarduino discord and report your problem

re PsychicHTTP - I see you included the repo - understandable since the author vanished; any substantial changes wrt upstream?

however he just resurfaced and I think a collective maintenance effort might happen

best regards

Michael

theelims commented 1 month ago

Regarding PsychicHTTP I had to make a few patches to get it to work. I opened also a few issues. I never made a PR as they didn't get pulled in and my patches are very "dirty" anyway. I don't know what upstream has changed. So far it seemed stable enough. I hope PsychicMQTT sees some more maintenance efforts, as it would be the natural successor of the abandoned ESPAsync-libs.

nimble is not activated as a module in ESP-IDF config for C6 and H2. If it is on the pioarduino fork I'm fine with that as well. Ah, I see it's the same person behind this and Tasmota. Should be fine than. Do you have a discord invite?

What do you mean with HTTPS and a conditional build? Can you elaborate? I am not sure if ESP32-sveltekit can use HTTPS, as it needs at least two concurrent connections to work properly. If it works I would love to have it as a configurable option, though.

mhaberler commented 1 month ago

pioarduino entry point - this has also the discord invite

re PsychictHTTP maintenance - once this picks up I'll see what can be folded back into upstream

HTTPS + conditional build:

our goal is a embedded MQTT broker supporting wss and PsychictHTTPs + PicoMQTT gets us there (the combo embedded device + PWA on phone/tablet must run without net connectivity)

I dont need the config UI per se to run on HTTPS as no value gained - I need to dig into PsychicHTTP code if a PsychitHTTPS instance also can support HTTP or if a second instance is needed and doable within the memory budget; so I'm not clear yet if a conditional build is actually needed

edit: a second PsychicHttpServer instance is needed, here's an example for a port 80->443 redirect - meaning a conditional buiild is not needed

the sensorbox link above has a PsychictHTTPs + PicoMQTT config which runs fine with two instances of MyhelloIOT with MQTT-WSS but goes down to 40kB heap - no measures to reduce memory pressure taken yet.

I've used esp-fs-webserver so far but rewriting that for PsychictHTTP looked to much effort, which brought me here - so I dont need the app capability per se as this is covered by the PWA which will be distributed independently

ps - btw esp-fs-webserver has a nice file system browser and ACE-based editor for the fileystem partition

mhaberler commented 1 month ago

I just tried this out - just add a PsychicHTTPS server to example,. and a PicoMQTT broker

worked on first try

heap drops from 187kB idle to 102kB with one MQTT-WSS session - looks doable!