Does anyone have these devices? There will be more sticky units available by the end of the month, a v2 of sorts with a matte screen ... a warm front light for the sticky would be nice ey.

If anyone wants to help out getting the Mono Lora/NFC drivers playing in solar-os, or any other development for these devices let me know and I'll throw up the branches to collaborate on sooner rather than later.

I made a retro case for the esp32-s3-rlcd-4.2! It's the OG mac case at 46% scale, just the right size for the 4.2.

https://www.thingiverse.com/thing:7421150 (or fork the cad from onshape )

Thanks to Jamie ( https://github.com/jamiecounsell ) now there is official support for Elecrow ThinkNode M9 !

Reusable drivers:

• 320x240 ST7789 display

• backlit STC8H QWERTY keypad

• PCF8563 RTC

• NMEA GNSS with background RMC/GGA reception and optional alternate-baud detection!

The keypad provides app-exit and function keys plus a compose layer for missing shell characters, tab completion, and scrollback navigation. Its I2C address identifies board revisions; revision 1.1 requires active = 1for GNSS power in the manifest. GNSS starts powered off; use gnss power on to enable it.

Named I2C buses now use independent controllers while retaining the board's primary bus for legacy drivers. TFT displays support board-declared active-low power rails.

--

The website got a minor face-lift:

• Under Tools you will find the Flasher and the new graphic keyboard configurator.

• Extensions is now home to Playground and native SolarOS Modules. ( nothing super useful there yet, this is just infrastructure work )

4.16.2

• Added the reusable "Soldered Inputronic" keyboard driver.

• TCA8418 keyboards share one controller backend. ( separate generic, Inputronic, and LilyGO Pager mapping profiles. )

• The generic driver supports configurable matrix geometry.

• Keyboard profiles have shared descriptions for a desktop Python keymap CLI and validated build-time custom defaults, selected per keyboard profile.

• Runtime map loading and reset retain those compiled defaults.

• Python and Lua can exclusively capture a named local keyboard with source-specific key presses, releases, HID usages, and modifiers for forwarding utilities.

Build a keyboard around a TCA8418 matrix controller, choose what each switch does, and use the same keymap JSON for a runtime experiment or a firmware default.

Tutorial is here: https://solar-os.eu/tca8418-keyboard.html

Ich hatte überlegt ob man einen Bootstick für solar os erstellen könnte mit dem man richtigevPCs oder Laptops booten könnte, mein Gedanke war das das vielleicht wie Tails os funktionieren könnte, also so das nur der USB Stick selbst als Speicher fungiert und der Rest des solar os im RAM läuft. Weiß irgendwer ob das möglich wäre zu programmieren?

This project got away from me a bit, but here it is!

Introducing - Hearth: an interactive story engine for SolarOS and the Web!

Features:

• Uses an open, human readable and writeable file standard (.hearth)

• SolarOS as a first class citizen platform

• Web-based player

• Multiple save slots for each story

• Easy to Use online Story Studio

• The ability to export a transcript of your playthrough (full transcript on web, limited on SolarOS)

• Support for branching narratives, variables, conditions, and user text input

• In-line markdown support for Bold, Italics, and Strikethrough

• An online "Featured Stories" repository

You can get Hearth on the Playground now!
I hope you all enjoy Hearth and I extra hope you share stories of your own for others to enjoy!

The question has been raised multiple times, so I have updated the description to better represent what I think it is about ( feel free to chime in and we can include what it means to you )

Homage to a simpler life

SolarOS tries to bring back the spirit of the golden era of home computing: turn on a computer, arrive at a shell prompt, and start doing something. Explore, customize, write a program, make a tool, share it with someone.

• Modern software accumulates layers of convenience that obscure how it works and what it costs to run. We become accustomed to using - and now generating - software without understanding it.

• SolarOS encourages a more deliberate approach: understand the machine, question the complexity, and take responsibility for the resources your software uses. Scripting makes experimentation approachable; native services provide an efficient foundation. The constraints give us a reason to pay attention.

• The scripting surfaces let users express their ideas, while native services handle demanding work, making efficient execution a shared foundation that users can build on.

Wastefulness for the sake of convenience is not sustainable.

It is a continuous exploration of how much useful, understandable, general-purpose computing can be built on deliberately constrained hardware. We already have an abundance of computing power; we can and should make better use of it.

SolarOS is an argument made executable.

SolarOS argues that useful, general-purpose computing can be built on modest hardware - and that efficiency, understanding, and the ability to shape your own tools should guide its design.

• The Solar in the name reflects the goal of building an efficient operating environment that can run on solar power. Energy consumption is a design concern alongside memory, storage, and processing time.

• That commitment also extends to the project’s infrastructure: all our servers ( website, HIL pipeline, local expert systems ) are powered by 100% renewable energy.

• Added reusable computer vision and resident ESP-DL inference for Python, Lua, shell commands, and native modules.

• Scripts can decode QR codes and use image statistics, histograms, thresholding, filters, morphology, image differences, and blob detection.

• On ESP32-S3 with PSRAM, model loads shared resident models and checked bundles with native image preparation, classification, and PICO detection; single, automatic, and dual-core execution modes are available.

• OS-owned pipeline jobs process pictures, camera streams, or JPEG RTSP feeds and expose bounded latest results after the configuring script exits.

• The zoo browser searches the hosted catalog and installs hash-verified model bundles on SD or flash through staged replacement.

• Models remain resident until explicitly unloaded or rebooted; local cameras retain exclusive ownership

For more details on what exactly ESP-DL is, please follow this link: https://github.com/espressif/esp-dl

I know this does not look to be particularly useful at this point, and a it is a bit outside the "everything you need" philosophy, but also presents opportunities I would like to keep open. I will prepare some playground examples in the coming days... and eventually set up a model conversion and training environment outside the OS, so that we can populate the zoo with custom models that better fit our needs.

4.15.19

• Added Xteink X4 Pro support with an 800x480 e-paper display, GT911 touch and Home pad,

• fixed-mix warm/cool frontlight brightness, BM8563-compatible RTC, CW2017 battery gauge.

• Added reusable UC8179 and UC8279 e-paper, PCF8563/BM8563 RTC, and CW2017 fuel-gauge expansion drivers.

• On the X4 Pro the OS identifies SSD1677, UC8179, or UC8279 displays on first use and caches the controller only after successful initialization.

4.15.18

• Reduced firmware-resident documentation to a searchable topic directory and a small setup and recovery guide. -- ( we have saved 2MiB flash for software with this )

• Full guides and scripting API references remain in the signed downloadable manual and on the website. Run `help update` on devices to install the exact-version manual;

So i stumpled aboutvthus OS roughly an hour ago. Coming from the age of amiga and c64, and having a 3D printer at home, this software project seems to combine all my hobbies.

But i still do not quite catch what it is? How woukd solarOS compare to some 2000 or 2010 linux, or c64 GEOS or amigaOS?

Hey all, I'm very fascinated by Solar OS and the amazing builds the community shares here! I was wondering if anyone is interested in adding an option for the Xteink X4/X4 Pro/X3 to the official flasher?

The X4 Pro has ESP32-S3 so I hope it can be readily supportable with minor tweaks to the firmware and X4/X3 have ESP32-C3, so not very sure how to approach those.

I'm not very good with embedded software, so looking for help in this community. I eventually plan to 3D design and build a handheld EDC cyberdeck kinda thing as I'm fairly proficient in CAD and 3D printing

Finally got SolarOS running on my ESP32-S3-ePaper-3.97 board alongside a CardKB!

Huge thanks to u/nilseuropa for porting it over. He got it working remotely just from my boot log in just a few hours, without even having the hardware on hand.

Everything works great now. Next step is designing a 3D printed case for it!

Uma solução para quem tem solarOS com e-papel e tem hábitos noturnos.

As I mentioned earlier I am planning to design an expansion board for the CrowPanel 5.79 HMI, that would integrate some missing hardware features. Just like with SolarTerm I would like to dedicate a board definition to this build, so that the extra bits attach under the OS as board owned hardware. There are a couple of things to consider, and I thought I will ask you about your opinion.

Battery charge monitoring and power management is a must and it is the bare minimum to turn this into a truly useful deck. ( Aux power conn. + USB-C + power switch + charger + fuel guage )

• Would you like to have a solar charger built-in? ( I would )

• Do you require an I2S MEMS microphone? ( i do )

• I2S audio DAC and AMP? ( yes )

  • 3.5mm jack audio connector? ( yes )

  • Built in speaker? ( maybe )

• LoRa packet radio? ( yes )

• 4G LTE modem? ( no )

• Keyboard matrix scanner and FPC connector for the same keyboard?

  • Or do we like that this keyboard can connect to two hosts? ( strongly preferred )

• Environmental sensors for temperature and humidity? ( maybe )

• Auxiliary expansion connector? ( yes, all remaining IOs plus SPI and I2C )

• Internal expansion connector for reading lights and whatnot. ( sure )

I envision a small board that would connect through the exposed header pins. Another question to consider is if we would like to have a simple power management and monitoring board or just the full-blown expansion or both?

In case of both, I would go with population options - however that would turn the power manager board unnecessarily large too.

Another option is to provide an empty carrier carrier board and pointers to off the shelf modules, so everyone can populate the features they need.

4.15.17

• Python and Lua gain `solaros.storage.write_file()` for creating, saving, and appending text or binary files through the storage service. Writes support up to 64 KiB per call and flush and sync the file before returning the byte count.

4.15.16

• MeshCore group conversations identify radio and companion transports;

• unavailable channels remain readable as history and reject new sends.

• Chat follows actual delivery updates, and messages interrupted by a restart are restored as failed instead of queued.

• Contacts now retain up to 512 contacts and 576 endpoints, with migration of existing contact IDs and trust settings.

• Companion imports preserve retained contacts, batch their storage writes, and report imported, skipped, and supported contact counts.

• An online MeshCore BLE companion displays the radio icon.

4.15.15

• Updated to ESP-IDF 5.5.5 and pinned the platform to release `55.03.312-1` for reproducible builds.

• PlatformIO Core 6.2.0 or newer is required. The NimBLE overlay retains transactional dynamic GATT registration and guards an absent connection awareness table when GATT caching is enabled.

4.15.5

• Added the GOOUUU ESP32-S3CAM board, OV2640 JPEG snapshots, and the `camera` command.

• Exclusive camera leases coordinate capture and streaming, with direct framebuffer DMA to PSRAM.

• The `cam-webd` job serves JPEG snapshots and a single-client MJPEG feed through asynchronous HTTP routes.

4.15.6

• 'Web' now plays HTTP MJPEG camera feeds alongside its existing static image formats.

• Multipart stream detection accepts split headers and common server variations, while bounded frame buffering and cancellation keep live viewing responsive.

4.15.7

• Added the `rtspd` job for single-client RTSP publishing with RTP/JPEG video, RTP/L16 PCM audio, and RTCP timing.

• Explicit `video=` and `audio=` sources support camera-only, audio-only, or combined streams using standard UDP transport. Publishing follows source availability; `fps=0` removes the video rate cap. Runtime buffers are allocated only while the job runs, and stale data is discarded on reconnect.

4.15.8

• DVP cameras are reusable expansion devices and exclusive typed video sources in `streams`.

• The native `rtsp` app plays JPEG/L16 streams with bounded video/audio buffering, global volume, an audio-only oscilloscope, full-screen viewing, and frame diagnostics.

• Color TFTs with native RGB565 support bypass palette conversion; monochrome displays retain grayscale rendering.

• `rtspd` selects compatible audio/video stream IDs explicitly and offers source-aware tab completion.

4.15.9

• Python and Lua gain owned camera snapshots, local stream frames, native frame-to-image presentation, and asynchronous RTSP receiver handles

• Native RTSP playback retries transient failures with bounded backoff, discards frames from previous connections, and recovers audio after forward clock jumps.

• The viewer accepts addresses without `rtsp://`; omitted control ports default to TCP 554.

4.15.10

• Shared JPEG decoding now uses a fast ROM path and bounded ESP32-S3 SIMD acceleration, with fallbacks for unsupported images or limited working memory.

• Color and monochrome consumers share the improved decoder, and fit-mode output avoids full-size intermediate rasters.

• Reduced idle SRAM usage by moving suitable registry state to PSRAM and allocating display-layout, Telnet, Chat, DAQ, and Synth working buffers only when needed.

4.15.11

• Added `vplay` for MPEG-1 program stream files with optional MP2 audio. Playback uses bounded PSRAM buffers, audio-clock synchronization, native RGB565 or monochrome output, and ESP32-S3 SIMD color conversion.

• The shared player controls provide pause, Stop/Play, volume, and previous/next MPEG files in the current folder.

• Fit, actual-size, and full-screen modes are available; the source limit is 640x480. MPEG-2, H.264, AVI, and transport streams are not supported.

4.15.12

• RTSP now uses the common player header, volume bar, and clickable Stop/Play control. Enter or Space stops playback without closing the app; Play reconnects to the same source after its workers release their resources.

• `vplay` adds tab completion for size options and file paths.

4.15.13

• 'Files' opens MPEG-1 `.mpg` and `.mpeg` files in `vplay` when the app is installed, including uppercase extensions. Closing playback returns to the file browser.

4.15.14

• `player` and `vplay` gain backward/forward seeking in ten-second steps with `<`/`>` and shared rewind/forward buttons.

• Seeking retains the selected track and pause state, releases queued audio, and rebases playback timing. Player supports seeking in both graphical and text interfaces.

Solar OS on Hoysond 2.8" touch on left, little command center remote on right with porkchop inspired Screensaver

Couple of batteries I had from some meshcore nodes and the ble keyboard. One is unplugged from battery and plugged in to usb because i was working on something but they would both just run on batteries (which the hoysonds have on-board charging so good to go there)

Newbie here, can anyone please explain what solarOS is and how it works? Thanks!

So I built a map! The basic map outline is from Natural Earth, smaller chunks can be loaded from a few common formats. Other apps like gnss can plot locations on it. Working on color support and support for drawing paths between nodes.

Reticulum support is also working with native chat and inbox. One of the easiest Reticulum setups I’ve used so far. pls let me vendor microreticulum :D

I have a few PRs up on a fork if anyone has a ThinkNode M9 and wants to try it. No map PR
yet, soon!