Redis API Reference

State Hashes

State is stored in Redis hashes. Services update fields with HSET and publish change notifications on channels of the same name.

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

Written by motion-service (BMX055 owner). Heading fields refresh from each magnetometer sample (5 Hz).

Pub/sub channels published by motion-service:

• motion:sensors — 10 Hz JSON IMU stream {accel, gyro, mag}
• motion:heading — 5 Hz JSON HeadingReading with raw + EMA-smoothed angles, accuracy, tilt
• motion:interrupt — JSON {type, timestamp, engine} motion edges; type:"wake-hibernation" for the post-resume sentinel
• motion:ready — fired once on startup
• motion:rpc — request channel for synchronous methods (prepare-hibernation, get-calibration, clear-latch, soft-reset)

settings

Persistent configuration managed by settings-service. All fields are readable/writable via lsc settings get/set. Notable keys:

ota

sms

Latest-value convenience state for SMS, written by modem-service. Per-message history lives on the streams described under SMS streams.

version:mdb / version:dbc

Written by version-service from /etc/os-release. Contains fields like version_id, build_id, id.

Command Queues

Services accept commands via Redis lists. Send with LPUSH; services consume with BRPOP.

Example:

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

Sending an SMS

scooter:sms takes a JSON object. id is optional and comes back as request-id on the sms:sent stream, so a sender can match outcomes to its own requests.

redis-cli -h 192.168.7.1 LPUSH scooter:sms \
  '{"id":"my-token","to":"+491701234567","text":"hello from the scooter"}'

Pub/Sub

When a service updates a hash field, it publishes the changed field name to a channel with the same name as the hash. Consumers subscribe and re-read only the changed field.

# Subscribe to vehicle state changes
redis-cli -h 192.168.7.1 SUBSCRIBE vehicle

# Subscribe to battery updates
redis-cli -h 192.168.7.1 SUBSCRIBE battery:0 battery:1

The published message payload is the field name that changed (e.g. "state", "charge"). Recipients call HGET <hash> <field> to get the new value.

This pattern is implemented in the redis-ipc library.

SMS streams

Individual messages don't fit the hash pattern (each one is an event, not a state), so modem-service appends them to two streams and announces each entry as JSON on a channel of the same name.

# Replay what's still buffered
redis-cli -h 192.168.7.1 XRANGE sms:received - +

# Or subscribe for JSON pushes as they happen
redis-cli -h 192.168.7.1 SUBSCRIBE sms:received sms:sent

Both streams are capped at 100 entries. The datastore isn't persisted across reboots, so this bounds memory rather than retaining history: everything is gone after a restart either way. The XADD is the delivery commit, so a message that made it onto sms:received won't be delivered twice.