You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- Moonlight is a fork of Upstream sveltekit repo (theelims/ESP32-sveltekit):
2
+
- /interface except moonbase folders (frontend)
3
+
- /lib folder (backend)
4
+
- Changes in upstream code has been commented with // 🌙 (moonbase) or // 💫 (moonlight)
5
+
- Core benefits of upstream sveltekit: state and services with subscriptions and up and running svelte (reactive framework)
6
+
- Improvements to the sveltekit stuff can be added, but always submitting a pull request to upstream needs to be considered. In theory all the // 🌙 are possible PR’s but for different reasons they not always end up in upstream
7
+
- MoonLight UI is now pretty much inspired by the UI used in upstream. Future goals is to develop more
8
+
- Repo is split in
9
+
- moonbase (everything not lights related, see for instance env:esp32-d0-moonbase in esp32-d0.ini, compiles only moonbase, not moonlight. Can be the basis for any IOT project)
10
+
- Moonlight: everything lights related
11
+
- MoonBase / MoonLight
12
+
- /src contains everything moonbase and moonlight specific
13
+
- See /src/MoonBase: some files contains MoonLight specifics, e.g. Nodes.h/.cpp. This is work in progress, eventually things like Nodes should be generic also for non light applications.
14
+
- pal.h and pal_espidf.cpp as a first attempt to come to an esp-idf only repository (not using arduino). This is very much work in progress.
15
+
- Modules and nodes are the core concepts of MoonBase/MoonLight. Modules are fully generated frontend(UI)/backend(server) modules (no specific sveltekit code per module, see /interface/src/lib/components/moonbase and /interface/src/routes/moonbase for Module specific code)
16
+
- Monitor module is now also lights specific, in the future should be a generic moonbase feature.
17
+
- Lightscontrol is now also lights specific, in the future should be a generic module, maybe renamed to something more generic. Lightscontrol is the interface / API to the outside world. e.g. DMX, IR, Home assistant etc, all have the variables / rest api / web sockets / … of lights control as their interface point
18
+
- MoonLight core concepts are physical and virtual layer. The physical layer has a double buffered / two array called channelsE/D: channels for effects and channels for drivers. Main.cpp manages the double buffering / producer/consumer synchronization of the two arrays in a way 2 core MCU’s like the ESP32 series uses one core for the producer (effects) and 1 core for the consumer (drivers)
19
+
- The channel array(s) are a generalization of FastLED’s CRGB leds. In FastLED’s, each entry is one CRGB object. In Moonlight each entry is one light with a nrOfChannels. So RGB lights have 3 nrOfChannels, RGBW 4, but other lights like moving heads are also supported (can be up to 24/32/… lights)
20
+
- The effects module contains effect nodes and modifier nodes, the Driver module contains layout and driver nodes.
21
+
- Eventually the effects and drivers module will be replaced / augmented by a graphical interface showing nodes, connected to other nodes in different lanes (e.g. physical lane and multiple virtual layer lanes)
22
+
- MoonLight currently supports audio reactivity by using https://github.com/netmindz/WLED-sync, depending on a WLED-MM device transmitting audio over the network. Implementing FastLED audio is work in progress, WLED-MM audio is currently moved to a separate library and in the future will also be added as an audio node. These 2 options allow for Audio processing indepenent of another device running WLED.
23
+
- MoonLight documentation is maintained in the same repo and is deployed here: https://moonmodules.org/MoonLight/
24
+
- See architecture : https://moonmodules.org/MoonLight/develop/architecture/ for more details on system tasks, producer/consumer double bufering etc.
25
+
- /src/MoonLight/Nodes contain subfolders for all currently supported Effects, Modifiers, Driver and layout nodes. Each node is a class with constructor and destructor to manage all their memory usage (after deleting a node in the effects or drivers module, they should be completely reverse their resource claims). Nodes have controls, each node can define their own unique controls and is shown and managed in the UI.
26
+
- MoonLight supports different LED drivers , the FastLED channels api drivers and also physical led driver which is based on I2SClocklessDriver repo for non P4 and on parlio.h/cpp for P4. They can be used as alternatives.
27
+
- All pins are manager by the IO module by board presets. Board presets is the only place where pins are defined. Nodes can use the pin definitions (and can report back to the IO module). Currently the IO module supports also I2C, in the future I2S, SPi, … will also be supported.
28
+
- Live scripts (https://github.com/hpwit/ESPLiveScript.git) is supported, now MoonLight specific but should be moonbase functionality eventually. It allows for live coding of nodes. Currently effect and layout nodes are implemented but not tested for a while (due to some crashes and planned further development of that repo).
29
+
- General
30
+
- MoonLight should run on all ESP32 devices. Mainly used and tested now on ESP32-D0 (standard dev MCU’s), ESP32-S3 and ESP32-P4. Running MoonLight on ESP32-D0 is a challenge as heap is pretty much used up, and Flash size is limited. We currently use a 3MB flash partition so 4MB boards cannot do OTA at the moment. In the future we plan to implement a minimal OTA partition (as investigated at Tasmota/ESPHome …), so also small flash size boards (4MB) can do OTA.
31
+
- Optimize on the critical process: running effects / modifiers (producers) and displaying them on leds (direct via pins on the board using led drivers or via Art-Net over the network). So code for the critical process should compile to minimal assembler code and checks on code should be minimal. (Example use int instead of unsigned int as no need to control if it is negative if the developer should ensure it is possible, or do not check if a const char * is null as it’s the developer responsibility to make sure this is the case). In short: the code should not be resilient to developer mistakes, the developer must solve the mistakes.
32
+
- Non critical processes can run in reasonable time, in general 20ms response time for UI is more than enough.
33
+
- See also GIMINI.md in /misc/parking for info about upstream sveltekit
Copy file name to clipboardExpand all lines: platformio.ini
+14-3Lines changed: 14 additions & 3 deletions
Original file line number
Diff line number
Diff line change
@@ -57,7 +57,7 @@ build_flags =
57
57
-D BUILD_TARGET=\"$PIOENV\"
58
58
-D APP_NAME=\"MoonLight\"; 🌙 Must only contain characters from [a-zA-Z0-9-_] as this is converted into a filename
59
59
-D APP_VERSION=\"0.8.1\"; semver compatible version string
60
-
-D APP_DATE=\"20260224\"; 🌙
60
+
-D APP_DATE=\"20260301\"; 🌙
61
61
62
62
-D PLATFORM_VERSION=\"pioarduino-55.03.37\"; 🌙 make sure it matches with above plaftform
63
63
@@ -204,9 +204,20 @@ build_flags =
204
204
-D DRIVERS_STACK_SIZE=6144 ; psramFound() ? 4 * 1024 : 3 * 1024, 4096 is sufficient for now. Update: due to FastLED audio I had to increase to 6144 (might want to move audio to a separate task)
205
205
206
206
; -D FASTLED_TESTING ; causes duplicate definition of initSpiHardware(); - workaround: removed implementation in spi_hw_manager_esp32.cpp.hpp
; https://github.com/FastLED/FastLED#7e133f8f39480cac7ca5876fc78c980f874b527d ; 20260225 10:03 AM bass/mid/high looks nervous / all or nothing, doens't align with audio sweep (https://www.youtube.com/watch?v=PAsMlDptjx8)
; https://github.com/FastLED/FastLED#4cef007214bdf70039576ccf60c9384981c06a0d ; 20260224 4:13 isqrt32 ... working ✅
218
+
; https://github.com/FastLED/FastLED#595150340cb0034b50328bee8eaaaceaeb570dc7 ; 20260224 2:48 AM add filtering to audio detectors working
219
+
; https://github.com/FastLED/FastLED#d03ffd69c68f1a00f883243f78b2a0e9bfb66298 ; master 2026023 6:15AM (fix no preamble for the UCS led chipset) websocket working!
220
+
210
221
https://github.com/ewowi/WLED-sync#25f280b5e8e47e49a95282d0b78a5ce5301af4fe ; sourceIP + fftUdp.clear() if arduino >=3 (20251104)
211
222
212
223
; 💫 currently only enabled on s3 as esp32dev runs over 100%
0 commit comments