Redis-API-Referenz

State-Hashes

Zustand wird in Redis-Hashes abgelegt. Services aktualisieren Felder per HSET und publizieren Änderungsbenachrichtigungen auf gleichnamigen Channels.

vehicle

redis-cli -h 192.168.7.1 HGETALL vehicle

battery:0 / battery:1

redis-cli -h 192.168.7.1 HGETALL battery:0

engine-ecu

redis-cli -h 192.168.7.1 HGETALL engine-ecu

internet

gps

alarm

motion

Wird vom motion-service (BMX055-Eigner) geschrieben. Heading-Felder werden mit jedem Magnetometer-Sample (5 Hz) aktualisiert.

Pub/Sub-Channels, die motion-service veröffentlicht:

• motion:sensors – 10 Hz JSON-IMU-Stream {accel, gyro, mag}
• motion:heading – 5 Hz JSON HeadingReading mit roh + EMA-geglättetem Winkel, Genauigkeit, Tilt
• motion:interrupt – JSON {type, timestamp, engine} Bewegungs-Edges; type:"wake-hibernation" für das Post-Resume-Signal
• motion:ready – einmal beim Start ausgelöst
• motion:rpc – Request-Channel für synchrone Methoden (prepare-hibernation, get-calibration, clear-latch, soft-reset)

settings

Persistente Konfiguration, verwaltet vom settings-service. Alle Felder sind per lsc settings get/set les- und schreibbar. Wichtige Keys:

ota

sms

Vom modem-service geschriebener Kurzzustand für SMS. Die einzelnen Nachrichten liegen auf den Streams unter SMS-Streams.

version:mdb / version:dbc

Wird vom version-service aus /etc/os-release geschrieben. Enthält Felder wie version_id, build_id, id.

Command-Queues

Services nehmen Befehle über Redis-Listen entgegen. Senden per LPUSH, Services lesen per BRPOP.

Beispiel:

redis-cli -h 192.168.7.1 LPUSH scooter:state unlock
redis-cli -h 192.168.7.1 LPUSH scooter:alarm start:30

SMS senden

scooter:sms erwartet ein JSON-Objekt. id ist optional und kommt als request-id auf dem Stream sms:sent zurück, sodass sich Ergebnisse den eigenen Aufträgen zuordnen lassen.

redis-cli -h 192.168.7.1 LPUSH scooter:sms \
  '{"id":"mein-token","to":"+491701234567","text":"Hallo vom Roller"}'

Pub/Sub

Sobald ein Service ein Hash-Feld aktualisiert, veröffentlicht er den geänderten Feldnamen auf einem Channel mit demselben Namen wie der Hash. Abonnent*innen lesen danach gezielt nur dieses eine Feld neu.

# Auf Änderungen am Vehicle-State subscriben
redis-cli -h 192.168.7.1 SUBSCRIBE vehicle

# Auf Akku-Updates subscriben
redis-cli -h 192.168.7.1 SUBSCRIBE battery:0 battery:1

Als Message-Payload kommt der Feldname, der sich geändert hat (z.B. "state", "charge"). Empfänger*innen holen den neuen Wert mit HGET <hash> <field>.

Dieses Pattern ist in der redis-ipc-Bibliothek umgesetzt.

SMS-Streams

Einzelne Nachrichten passen nicht ins Hash-Muster, denn jede ist ein Ereignis und kein Zustand. Der modem-service hängt sie deshalb an zwei Streams an und kündigt jeden Eintrag als JSON auf einem gleichnamigen Channel an.

# Anzeigen, was noch gepuffert ist
redis-cli -h 192.168.7.1 XRANGE sms:received - +

# Oder JSON-Pushes live abonnieren
redis-cli -h 192.168.7.1 SUBSCRIBE sms:received sms:sent

Beide Streams sind auf 100 Einträge begrenzt. Der Datenspeicher überlebt keinen Neustart, das Limit begrenzt also den Speicherverbrauch und keine Historie: nach einem Neustart ist ohnehin alles weg. Das XADD ist der Zustellpunkt, eine Nachricht auf sms:received wird also nicht doppelt zugestellt.