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

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.

Sharing SolarOS, an ESP32 operating environment with a shell, apps, Python/Lua scripting, and two ways to use MeshCore:

• Local LoRa radio: Run a non-forwarding MeshCore node with encrypted DMs, delivery acknowledgements, public hashtag channels, and private shared-key groups.
• BLE companion: Connect to an existing MeshCore device for messaging through SolarOS’s Contacts, Chat, and Inbox.

There’s also virtual serial over MeshCore between two SolarOS devices: access a remote shell or bridge a UART through standard MeshCore repeaters, without modifying the repeaters. This requires the local-radio mode and trusted endpoints on both sides. It’s a slow link suited to short commands.

SolarOS itself doesn’t act as a MeshCore repeater or room server (yet).

Visit our community for regular updates: r/SolarOS

https://www.elecrow.com/wiki/CrowPanel_ESP32_E-paper_5.79-inch_HMI_Display.html

Added `ltop`, a resumable live task monitor for display and port terminals. It shows:

• interval-based CPU load for each core,
• aggregate CPU load,
• internal and external memory utilization, and a
• width-aware task table with current CPU use, state, priority, and
• peak stack consumption.

Run ble without arguments to open the BLE Inspector TUI. Its Devices, Services, Chars, and Settings tabs support scanning, connecting, service and characteristic inspection, characteristic reads and hexadecimal writes, and BLE keyboard settings. Press Tab to move between tabs. The inspector owns its GATT connection and disconnects it when the TUI closes. Existing ble status, ble scan, and ble gatt ... commands remain available for scripts and plain text use. On a BLE-disabled boot, the Settings tab remains available so BLE can be enabled for the next boot.

• Added offline PicoTTS speech with runtime-loaded voice directories, an asynchronous native/Python/Lua service, and the say command for text or streaming plain-text files with progress, cancellation, pitch, and speed controls.
• agent --tts can speak final model answers while keeping tool activity and intermediate messages silent.
• PicoTTS voice assets are included in the repository for copying to device storage but remain outside the firmware image, so you can decide which one to host on the internal flash disk or on SD:
  • German: de-DE
  • English (US): en-US
  • English (GB): en-GB
  • Spanish: es-ES
  • French: fr-FR
  • Italian: it-IT
• Python and Lua apps can now discover native and installed Playground apps, hand off to another app, and open supported files or URLs. Their storage APIs add metadata, existence checks, bounded directory enumeration, and recursive directory creation.
• MicroPython integers now support the signed 64-bit range.

*ftpcan be started without arguments as a disconnected file manager and opens connection setup with F2/n; ( its Copy, Move, Mkdir, and Delete function keys and letter mnemonics now match 'files'. )
* Added a two-pane sftp file manager with the same browsing, recursive copy/move/delete, mkdir, viewing, progress, and cursor-retention behavior over the existing SSH transport and SFTP subsystem.
* SFTP supports known hosts, host aliases, password or key authentication, an F2 connection form, and the compatible direct-connect command-line form, including user@host:path.

See https://solar-os.eu/docs/manual/apps.html#sftp

Added a full-screen, overlay-free Palm Graffiti keyboard job with alphanumeric templates, Palm editing gestures, and automatic letter/number selection from the stroke's starting region. It accepts absolute touch devices attached at runtime without taking the foreground application's pointer stream.

Added the MGC3130/Skywriter expansion driver with 3D position, absolute hover-pointer, and gesture input.

Gesture-capable devices now use a common source class and can bind advertised gestures and directions to shell commands or scripts through the gesture-listener job. input emit supports modifier chords such as ALT+RIGHT, releases synthetic modifiers correctly, and gesture binding completion now suggests live sources and their supported gestures. Idle listeners release their worker stack while preserving bindings.

gesture-listener

Gesture-to-command listener. Rules are configured independently with gesture bind, while this job owns observation and dispatch:

gesture bind source=gesture0 gesture=flick direction=east -- input emit ALT+RIGHT
gesture bind source=gesture0 gesture=flick direction=west -- input emit ALT+LEFT
job start gesture-listener
job status gesture-listener
job stop gesture-listener

Stopping the job preserves the rules, prevents new gesture actions, and drops queued actions. A command already executing finishes normally. Use gesture bindings to inspect rules and counters, gesture unbind <id> to remove one, or gesture unbind all to clear the table and reset the next ID to 1. Rules and job state are volatile; recreate them in the startup script when persistence is needed. The command worker is created on demand and releases its internal stack when its queue is idle.

load: 4G routed to WiFi AP with 3 clients + paper shell

4 hours up, yet still at 3.9V / 100% ( battery is 15 years old )

( my current meter just died of boredom )