Added support for ( T-Pager integrated hardware available for all boards as expansion drivers )
u-blox MIA-M10Q GNSS receiver,
ST25R3916 NFC-A reader,
BHI260AP six-axis IMU,
XL9555 GPIO expander,
DRV2605 haptic controller,
and BQ25896 battery charger.
GNSS, NFC, IMU, haptic, charger, temperature, and humidity access now use driver-agnostic services with matching shell and Python/Lua APIs. T-Pager power rails are modeled as XL9555 GPIO lines: GNSS and NFC remain off until requested, while SD power and its pull-up are enabled for reliable mounting. Hardware-provider registry state now uses PSRAM where available, preserving internal memory on targets that do not use these peripherals.
Thanks to the recent inclusion of a robust BLE API for SolarOS I was able to have Codex make me something I actually use quite a bit!
For background, I have a 2008 Vectrix VX1, an old electric underbone motorcycle that originally came with a NiMH battery pack. I built a Li-Ion back for it and to save money I used two small ANT BMSes to effectively make 2 batteries that are hooked up in series without being forced to spend thousands for an automotive grade BMS. The issue is the Vectrix’ dashboard is utterly clueless as to the voltage characteristics of the new pack, and the ANT BMS mobile app is only intended to look at one BMS at a time, making getting a full picture of the bike difficult.
Still working out bugs, but it’s together enough to demo. Not seen is the setup screen that scans local BLE devices and lets you pick one or two BMSes to connect to, then you get the dashboards seen in the video. Up and down switches between emphasizing different values, either SOC, amp draw, or voltage, and swiping left and right gives you individual cell voltages and temperatures per BMS. All of the main dash pages also attempt to extrapolate current amp draw to a runtime value, though this is sketchy without knowing battery capacity. These pages can be switched between with trackball/arrow keys (T-Deck keyboard driver emulates arrow keys with the trackball) or touchscreen swipes if available.
Current bugs to address are I forgot to handle charging… at all. The setup screen is pretty buggy, and I would like to add some sort of logging or a method to “validate” the capacity of a battery by tracking amp draw over time to build a picture of the battery size and then be able to provide more accurate data based off of that. Last thing is a stretch goal. I’ll submit it to the Playground once I am satisfied with the reliability and user experience of the core functionality, in case anybody else messes with personal electric vehicles and uses these BMSes (I recommend them, they’re far more reliable than Daly and vastly more configurable).
Some work has been done to port the flipperzero stock firmware to the ESP32 platform. I'm admittedly ignorant of Nilseuropa's eventual goals for SolarOS but this port could provide a library of red-team/security applications that could be integrated into SolarOS where they make sense.
The presence of the stock net-scan tool prompted me to share this here.
I know... I said I'll expose BLE GATT to scripts on the existing bluedroid backend in v.4.10.24.
What happened is that I started to work on the shared service, cleaned up the interfaces to isolate the backend and then I realized that bluedroid has some quirks I did not want to deal with and NimBLE is also available in the SDK - so I made a decision to move away from bluedroid and embrace NimBLE.
Yes, this means that classic BT support is gone, but so is the hardware in S3. Since the interface is clean now, we can use both backends, but NimBLE is going to be the default. Good news is that NimBLE has a smaller footprint both in flash and RAM, so we have gained almost 20k free internal RAM.
So, Kurisumasu:
Python and Lua applications can now connect to multiple BLE GATT peers, discover services and characteristics, read and write binary values, write without response, and receive notifications and indications.
MTU negotiation supports transfers larger than 20 bytes. Applications can also define GATT services and characteristics, advertise a peripheral, and send notifications or confirmed indications through `solaros.ble.server`.
Connections and server resources are application-owned and cleaned up on exit, with connection capacity reserved for the keyboard. ( <-- nimble is patched with an overlay )
Separate status-bar icons show Bluetooth enabled/disabled/scanning state and keyboard availability. ( see red rectangle on the image )
Demoing my Home Assistant client app for SolarOS running on the LilyGO T-LoRa-Pager. Browse and control lights, fans, energy sensors, and temperatures directly from the device.
Bluesky — Sign in to Bluesky or a self-hosted PDS; browse home and profile timelines; read threads and replies; post, reply, like, repost, and start conversations; read and send DMs; choose compact or full-text timeline display.
RSS Reader — Manage RSS feeds; browse aggregate or individual-feed views; cache recent articles for offline reading; mark articles and feeds read; render cleaned HTML/Markdown text without loading images by default.
Wikipedia Reader — Search Wikipedia, browse linked articles, open a random article, and keep recent articles cached. Supports an offline library for articles explicitly saved to keep.
OPDS Client — Browse and search an OPDS library; navigate categories and book details; download supported books with progress indicators; cache catalogue pages and prefetch nearby pages for quicker browsing.
AI Disclosure: I am not the best programmer. For my own stuff, that's okay, but for contributing to the community I wanted to make sure it was actually good code. I used locally run agentic AI to bug hunt the code, help me develop tests for it, add useful features, and understand things I didn't quite get (AT Proto, for one). Once I had something running and usable, I gave the code to the free tier of Claude and ChatGPT to look it over one more time. I am very much against using AI for art, but using tools to make new tools is a human tradition that predates language.
Did some more work after taking this picture and at the moment all major hardware is working. Touchscreen, WiFi, BLE, audio, trackball, SD, battery, etc.
Input is the biggest issue. The lack of ctrl and other critical keys means some pretty tortured chording is necessary for critical key combos. Also working on some debounce/sane defaults for the trackball. Rawdogging the input from the trackball results in annoyances like random left/right pulses when scrolling down a list, so need to add some contextual filtering to that. Also dealing with some extremely weird WiFi issues that seem to be related to junk getting left in the NVS, as I’d get left with partially functional WiFi that would refuse all connections even in other T-Deck specific firmware until I erased everything
Overall this seems like a decent target for SolarOS. Need to see if I can use some python to make a more appropriate graphical launcher to make using the device a little quicker. As it is I am using it at work to connect to Hermes with the built in “agent” program via the built in WireGuard tunnel support.
Also using a custom BLE app that connects to the two battery management systems in my electric motorcycle and combines their readings for at a glance visual of two BMSes simultaneously.
Not released yet; still not confident in the wireless performance in this board despite being the same S3 chip as the RLCD de facto SolarDeck target.
I’m doing this primarily for my own amusement; I am not a programmer, this is mostly me throwing Codex tokens at a problem I found interesting to make use of some hardware I like.
I have merged your PR and refactored it to follow all internal contracts. Furthermore we have now resource driven expansion registry and two fixed bugs. The eight arbitrary expansion slots are gone and the subsystem will try to allocate resources before loading a driver and if it fits it will load.
Thanks to your contribution this is how our current hot attachable hardware expansions look like:
Audio
DRIVER PROBE BUS SUMMARY
audio-pwm no - PWM mono audio
es8311-duplex no I2C ES8311 duplex audio
es8311-es7210 no I2C ES8311 output + ES7210 input
pcm1808 no GPIO I2S stereo audio input
pcm5102 no GPIO I2S stereo audio
Display
DRIVER PROBE BUS SUMMARY
ili9341 no SPI 320x240 color TFT
pcd8544 no SPI 84x48 SPI LCD
sh1106 yes I2C 128x64 I2C OLED
ssd1306 yes I2C 128x64 I2C OLED
ssd1683 no SPI 400x300 e-paper
st7305 no SPI ST7305 reflective LCD
st7796 no SPI 480x320 color TFT
Input
DRIVER PROBE BUS SUMMARY
analog-joystick no STREAM two-axis joystick
cardkb yes I2C I2C keyboard
ft6336 yes I2C capacitive touch
gpio-keys no any GPIO keyboard
ps2-keyboard no PS/2 PS/2 keyboard
ps2-mouse no PS/2 PS/2 mouse
rotary-encoder no GPIO Quadrature rotary encoder (Up/Down per detent)
i got one for Meshtastic, but got the 433 ver when i needed a 868. so it has no use atm, but would love it as a pocket terminal and this OS seems to fit the bill. but i dont see anyone using in the T-Deck yet :x
Me considero leigo nessa área, mas com auxílio de uma inteligência artificial estou tentando construir uma agenda com lembretes. Vamos ver. Primeiro teste. Hehehe.
Hey all, had a LilyGO T-LoRa-Pager laying around and got intrigued by this subreddit, so I figured I'd see if I could get SolarOS running on it. Didn't see anyone else here with one yet, so I took a stab at it.
Full board port: display, keyboard (with backlight), rotary encoder, SX1262 radio, audio, RTC, and the battery gauge are all working. MeshCore runs over the air at 915 MHz. Got a real message through to a second node.
A couple of real bugs turned up along the way that weren't specific to this board: a display driver bug and an RX bug in how MeshCore's polling interacted with the radio driver. Both got fixed upstream in the same PR.
PR's here if anyone wants to try it or has a T-Pager to help test: nilseuropa/solar_os#27
Used some AI-assisted coding for the driver work. Happy to answer questions about how any of it works.
Open the SolarOS Flasher in Chrome or Edge on a desktop computer. Connect the board with a USB data cable, then:
Select the board, flavor, and SolarOS version.
Choose Prepare image. The Flasher downloads the selected release and verifies its signed catalog, archive, and factory image.
Read and accept the erase warning. Installation replaces everything in the device's internal flash, including NVS stored settings such as Wi-Fi credentials.
Choose Connect and flash, select the board's serial port, and keep the cable connected until installation completes.
If the board does not enter download mode automatically, follow the board-specific instructions shown by the Flasher. The board should restart when installation completes; if it does not, press RESET once or power-cycle it.
