Redis Interface Documentation¶

Connection Details¶

The scooter runs the datastore on the MDB accessible at:

• Host: 192.168.7.1
• Port: 6379

Local connection command:

redis-cli -h 192.168.7.1 -p 6379

Redis or Valkey - Librescoot Only¶

Librescoot 1.2 replaced Redis with Valkey 9 (wrynose's meta-oe ships it; the tuned config was ported over directly). It speaks the same protocol on the same port and redis-cli remains as a compat symlink, so everything documented here applies unchanged, as do the --redis-* flags across the services.

What did change is the systemd unit name: service units now order against valkey.service, not redis.service. Anything that hardcodes the old unit name will not find it on 1.2 or later.

Stock ScooterOS and Librescoot 1.1 and earlier still run Redis.

Key Structure¶

The Redis database uses hash sets for system state storage. All fields default to empty strings ("") when data is unavailable unless otherwise noted.

For potential values, also see the Bluetooth reference.

Vehicle State (vehicle)¶

hgetall vehicle

Engine ECU (engine-ecu)¶

hgetall engine-ecu

Battery Management (battery:0 and battery:1)¶

hgetall battery:0
hgetall battery:1

Note: When battery is not present ("present": "false"), all fields will show default values as shown in examples.

Auxiliary Battery (aux-battery)¶

hgetall aux-battery

Connectivity Battery Box (cb-battery)¶

hgetall cb-battery

Scooter (scooter)¶

Ambient temperature measured by the onboard thermistor, relayed from the nRF52 by bluetooth-service. Also published on the scooter channel.

hgetall scooter

System Information (system)¶

hgetall system

Power Management (power-manager)¶

hgetall power-manager

Power Manager Busy Services (power-manager:busy-services)¶

hgetall power-manager:busy-services

Stores systemd inhibitors preventing suspend. Cleared and repopulated on updates.

Published to power-manager:busy-services channel with value "updated" when changed.

Power Multiplexing (power-mux)¶

hgetall power-mux

Internet Connectivity (internet)¶

hgetall internet

Dashboard Interface (dashboard)¶

hgetall dashboard

See Dashboard.

Bluetooth Interface (ble)¶

hgetall ble

Bluetooth Commands¶

The Bluetooth service accepts commands via the scooter:bluetooth Redis list. Commands are sent as strings:

# Send a command to the Bluetooth service
redis-cli -h 192.168.7.1 LPUSH scooter:bluetooth "command-name"

Available commands:

• advertising-start-with-whitelisting - Start BLE advertising with whitelist filtering (only paired devices can connect)
• advertising-restart-no-whitelisting - Restart advertising without whitelist restrictions (any device can connect)
• advertising-stop - Stop BLE advertising completely
• delete-bond - Remove a single paired/bonded device
• delete-all-bonds - Remove all paired/bonded devices from the system
• remove - Remove the currently connected device
• ltc-enable / ltc-disable - Enable/disable the LTC4020 aux charger
• ltc-force-enable / ltc-force-disable - Force the LTC4020 aux charger on/off (bypass safety gating)
• ltc-status - Query the LTC4020 aux charger state
• data-stream-sync - Re-push the current data-stream state to the nRF52
• firmware-update - Trigger an nRF52 firmware update from /usr/share/nrf-fw/

Bluetooth Event Subscriptions¶

The Bluetooth service subscribes to several Redis channels and automatically updates the nRF52 module when values change:

Vehicle State Updates:

• vehicle:state - Vehicle operating state changes
• vehicle:seatbox:lock - Seatbox lock status changes
• vehicle:handlebar:lock-sensor - Handlebar lock status changes

Battery Status Updates:

• battery:0:state - Main battery 0 state changes
• battery:0:present - Main battery 0 presence detection
• battery:0:charge - Main battery 0 charge level
• battery:1:state - Main battery 1 state changes
• battery:1:present - Main battery 1 presence detection
• battery:1:charge - Main battery 1 charge level

Power Management Updates:

• power-manager:state - Power state changes trigger automatic data stream management

Bluetooth-Triggered Redis Requests¶

The Bluetooth service can write requests to Redis when receiving commands via BLE:

Scooter Control:

• scooter:state → unlock / lock / lock-hibernate
• scooter:seatbox → open
• scooter:blinker → right / left / both / off

Power Management:

• scooter:power → hibernate / hibernate-manual

Keycard Authentication (keycard)¶

hgetall keycard

Note: This hash expires after 10 seconds. Authentication is published on the keycard channel (the field name authentication is sent as the message payload), not on a separate keycard:authentication channel.

Keycard management commands go through the scooter:keycard list:

redis-cli -h 192.168.7.1 LPUSH scooter:keycard learn:start

Available commands: list, count, add:<uid>, remove:<uid>, set-master:<uid> (NONE to disable), learn:start, learn:stop, learn:master:start, learn:master:stop, reset

Command results land in the keycard hash field command-result. During teach-in flows, per-tap progress events (card-learned:<uid>, master-learned:<uid>, mode-entered:master, ...) are published on the keycard:events channel. See keycard-service documentation.

Navigation (navigation)¶

hgetall navigation

Destination for the dashboard's navigation mode. Written by bluetooth-service (BLE nav commands) and lsc nav; consumed by scootui-qt.

Clearing navigation sets all fields to empty strings rather than deleting them, so hash watchers get notified.

GPS Data (gps)¶

hgetall gps

Published by modem-service from gpsd data.

The hash is updated silently; a pub/sub notification on timestamp is published only when GPS recovers after an outage. For a continuous stream, subscribe to the gps:tpv channel, which carries the full snapshot (same fields, JSON) for every fix.

GPS has no commands; modem-service manages it automatically (see scooter:modem below). The legacy gps:raw and gps:filtered hashes no longer exist.

Over-the-Air Updates (ota)¶

hgetall ota

Settings (settings)¶

hgetall settings

Librescoot Additional Settings¶

Librescoot adds persistent settings managed by the settings-service:

The full settings schema (types, defaults, ranges, labels) is served as a JSON document in the settings:schema key by settings-service:

redis-cli -h 192.168.7.1 GET settings:schema

See settings-service documentation for details on persistent settings.

Settings Overlay Commands (settings:overlay) - Librescoot Only¶

Apply or clear a named settings overlay. Overlays override live settings values in memory without ever writing them to /data/settings.toml; clearing restores the user's base values.

# Enable Service mode
redis-cli -h 192.168.7.1 LPUSH settings:overlay apply:service

# Disable Service mode
redis-cli -h 192.168.7.1 LPUSH settings:overlay clear:service

Available commands: apply:service, clear:service

Service mode overrides (applied in memory only, not persisted):

Service mode persists across reboots until cleared. The base values in /data/settings.toml are never modified.

Status field: settings hash field dashboard.service-mode-active = "true"/"false" (read-only; written by settings-service).

New setting scooter.handlebar-unlocked (bool, transient - only set via overlay): vehicle-service releases the handlebar latch and suppresses auto re-lock while "true".

CLI: lsc service-mode on|off|status (alias: lsc servicemode)

Alarm System (alarm) - Librescoot Only¶

hgetall alarm

Possible status values:

• disabled - Alarm system is disabled
• disarmed - Alarm enabled but not armed (vehicle not in stand-by)
• armed - Alarm is armed and monitoring for motion
• level-1-triggered - Level 1 alarm (notification only)
• level-2-triggered - Level 2 alarm (horn + hazards)

See alarm-service documentation for details.

Motion / IMU (motion) - Librescoot Only¶

hgetall motion

motion-service owns the BMX055 9-axis IMU and publishes its state here. The legacy bmx hash and scooter:bmx command list are gone.

Pub/sub channels:

• motion:sensors (10 Hz) - JSON sensor reading: timestamp, accel, gyro, optional mag, each axis as {x, y, z, magnitude, unit}
• motion:heading (5 Hz) - JSON heading payload (heading_deg, accuracy_deg, tilt_deg, ...)
• motion:interrupt - JSON motion event: {"type": "edge"|"wake-hibernation", "timestamp": ..., "engine": "any-motion"|"slow-motion"}
• motion:ready - fired once at startup after the first profile-apply; payload is a unix-ms timestamp

RPC channel motion:rpc (redis-ipc CallServer): methods prepare-hibernation, get-calibration, clear-latch, soft-reset.

soft-reset resets accel + gyro and then reprograms the current profile. It does not leave the chip at register defaults, since that would mean no motion detection on an armed scooter.

The motion hash still carries a sensitivity field. motion-service seeds it to "none" at startup and rewrites it whenever a sensitivity:<level> command arrives on scooter:motion. It is advisory: the profile controller reprograms threshold and duration on the next alarm or power-manager transition regardless of it.

Chip configuration is reactive: motion-service derives the profile from the alarm and power-manager hashes, consumers never write registers. The bmx:interrupt channel survives only as a relay: bluetooth-service publishes wake-suspend / wake-hibernation there when the nRF52 reports an accelerometer wake event.

See motion-service documentation for profiles, payload schemas, and the hibernation handshake.

Dashboard Backlight (dashboard) - Librescoot Enhancement¶

Librescoot adds these fields to the dashboard hash:

dbc-backlight-service on the DBC owns all three. It reads the OPT3001 through IIO itself, publishes the reading to brightness, maps it through a lux-to-brightness curve, and writes the level it applied to backlight. Each write is followed by a PUBLISH dashboard <field>.

backlight is an index into the interpolated step range the pwm-backlight device tree node exposes, not a raw duty cycle. max_brightness is 10240.

backlight-enabled is a hard override rather than a mode: false writes 0 and holds, true releases back to whatever the ambient level calls for. vehicle-service asserts it on entering parked and ready-to-drive, scootui-qt clears it for the hop-on lock overlay and the OTA and maintenance screens, and lsc backlight on|off drives it by hand. The mode itself lives in settings, as dashboard.backlight-mode (auto, low, medium, high).

scootui-qt reads brightness for its automatic light/dark theme when dashboard.theme is auto, which is why the field keeps updating even while the backlight is overridden off or pinned to a fixed level.

Modem Management (modem) - Librescoot Only¶

hgetall modem

SMS (sms hash, sms:received / sms:sent streams) - Librescoot Only¶

Per-message SMS data lives on two Redis streams, each with a dedicated pub/sub channel of the same name; the sms hash only carries latest-value convenience state. Redis is not persistent on librescoot, so the streams are a live window (capped at 100 entries), not an archive.

sms hash¶

hgetall sms

The last-received-* fields are refreshed silently; the per-message notification is the dedicated sms:received channel below.

sms:received stream + channel¶

One stream entry per inbound message, fields from, text, timestamp (RFC 3339). Each entry is also PUBLISHed on the sms:received channel as JSON including its stream id:

SUBSCRIBE sms:received        # {"id":"1752...-0","from":"+4930...","text":"Hello","timestamp":"..."}
XREAD STREAMS sms:received 0  # catch-up from the beginning of the window

A message is only deleted from modem storage after its XADD succeeds, so a Redis outage doesn't lose mail (the modem store buffers it and modem-service retries). Messages that arrived while the service was offline are drained on startup.

sms:sent stream + channel¶

One stream entry per terminal send outcome, fields request-id (the caller's id token from the scooter:sms payload, empty if none), to, text, outcome (sent/error), error (empty on success), timestamp. Each entry is also PUBLISHed on the sms:sent channel as JSON including its stream id.

Internet Connectivity (internet) - Librescoot Enhancement¶

Librescoot adds modem health tracking:

Modem health states:

• normal - Modem operating normally
• recovering - Attempting recovery
• recovery-failed-waiting-reboot - Recovery failed, waiting for reboot
• permanent-failure-needs-replacement - Hardware failure

Connectivity classification (connectivity):

modem-service folds modem state, SIM state, registration, the enable flag and health into a single debounced verdict. Consumers (e.g. the dashboard internet icon) use it to decide whether being offline is worth surfacing:

• connected - modem connected, data path up
• disconnected - enabled with a SIM present, but searching/registering/no signal (provisioned, currently down)
• disabled - modem intentionally powered off by command
• no-sim - SIM missing or inactive
• denied - registration denied/failed, e.g. a carrier-deactivated SIM (debounced ~60s)
• failed - modem broken/absent (health terminal)

Hysteresis: connected->disconnected waits 3 min (ride out tunnels), denied waits 60 s before committing; disabled/no-sim/failed commit immediately.

OTA Updates (ota) - Librescoot Enhancement¶

Librescoot adds per-component update tracking:

Update status values: idle, downloading, preparing, installing, pending-reboot, error

status and update-type are the non-namespaced pair from the stock convention, describing the vehicle rather than one board. Both components feed them and the least advanced one wins, so the pair only clears once neither board is busy. The MDB's update-service is the sole writer. They carry nothing the namespaced fields lack; read status:{component} instead. See services/librescoot-update.md for the full mapping. download-bytes and download-total are preserved across such an abort so the partial's progress stays visible; the next attempt resumes from it.

A heartbeat that has stopped advancing while status is downloading, preparing or installing means the reporter is gone rather than merely quiet. pending-reboot is excluded: a DBC install ends there and the heartbeat legitimately stops until the next power cycle. An absent heartbeat is not a stale one either, since older images never wrote the field. See services/librescoot-update.md for the full caveats and for what vehicle-service actually does, which is not an age test. they say what a switch to that channel would fetch, and the update status fields are never touched by a preview. preview-status is checking, ready, unavailable (that channel carries nothing for this board's variant_id) or error (bad channel, or the release index could not be reached inside 20 seconds). preview-channel is echoed on every write so a reader can tell the answer it asked for from a stale one. All four are cleared at service start. Each component answers only for itself; a reader wanting the cost of a scooter-wide switch asks both and sums the sizes. The size is always the full artifact, because a channel switch has no delta base to patch against and so forces a full update regardless of updates.{component}.method.

See update-service documentation for details.

BLE OTA Transfer Status (ota:ble) - Librescoot Only¶

Written by bluetooth-service's OTA receiver while a phone pushes a firmware bundle over BLE (see BLE OTA Firmware Transfer):

Session fields (all but state/updated-at) are only present while a session is active.

Version Information - Librescoot Only¶

MDB Version (version:mdb)¶

hgetall version:mdb

Contains all fields from /etc/os-release with lowercase keys (e.g., version_id, build_id), plus the board serial:

DBC Version (version:dbc)¶

hgetall version:dbc

Contains all fields from /etc/os-release with lowercase keys, plus serial_number_real and serial_number as above.

version-service populates these hashes on startup, as a oneshot unit per board (version-service-mdb.service passing -hash version:mdb, version-service-dbc.service passing -hash version:dbc; the MDB unit also orders itself after valkey.service, the DBC unit restarts on failure). The binary itself has no board-specific logic: the hash name is the only difference. It reads the serial from /sys/bus/nvmem/devices/imx-ocotp0/nvmem (offsets 4 and 8 for CFG0 and CFG1), falling back to /sys/fsl_otp/HW_OCOTP_CFG* where that exists. A missing serial source is logged and skipped; the OS release fields are still published.

These are the authoritative board serials. Read them here.

Physical Inputs (buttons, input-events)¶

vehicle-service exposes the handlebar controls on two pub/sub channels. Neither is a state store: read vehicle for the current level of brake:left, brake:right, blinker:switch and friends.

buttons channel - raw edges¶

One message per input edge, payload <source>:<edge> or <source>:<position>:<edge>:

SUBSCRIBE buttons
horn:on
horn:off
seatbox:on
seatbox:off
brake:left:on
brake:left:off
brake:right:on
brake:right:off
blinker:left:on
blinker:left:off
blinker:right:on
blinker:right:off

The payload always reflects the triggering input's own edge, independently of any combined state. Releasing one side of a hazard pair emits blinker:right:off even though the combined blinker:switch moves to left rather than off. Consumers that want the combined switch position read vehicle[blinker:switch].

Nothing on this channel carries a timestamp or duration. For press duration semantics use input-events; for the current level of an input read the vehicle hash (brake:left, brake:right, blinker:switch). horn:button and seatbox:button are not written in this release.

There is no buttons hash. Between Librescoot 1.x (2025-12) and this release a buttons hash existed with fields horn:on / horn:off / seatbox:on / seatbox:off set to the literal "1" and never cleared; it had no readers and was removed. Over the same period vehicle[horn:button] and vehicle[seatbox:button] were not written and read back empty. Both are fixed: the level fields are in the vehicle hash again, and each edge is published on buttons exactly once.

input-events channel - synthesized gestures¶

vehicle-service runs a gesture detector over the same inputs and publishes higher-level events, payload <source>:<gesture>:

SUBSCRIBE input-events
horn:press
horn:release
horn:tap
brake:left:long-tap
brake:right:hold
seatbox:double-tap

press and release fire on every edge. long-tap and hold fire while the input is still down, so a 4-second press emits press, long-tap, hold, release in that order and no tap. A long-tap or hold clears the pending tap, so a long press between two taps does not glue them into a double-tap.

Unlike buttons, each gesture is emitted exactly once, which makes this the channel to use for anything that counts or reacts to discrete user actions.

Event Streams¶

Fault Events (events:faults)¶

Stream of system fault events using XADD:

XREAD STREAMS events:faults 0

Each entry contains:

• group - Component group (e.g., "cb-battery", "modem")
• code - Fault code
• description - Human-readable fault description

Command Channels¶

The scooter accepts control commands via Redis list-based channels using LPUSH. Commands are queued and processed by the vehicle service.

Scooter State Control (scooter:state)¶

Controls the lock/unlock state of the scooter.

# Lock the scooter
redis-cli -h 192.168.7.1 LPUSH scooter:state lock

# Unlock the scooter
redis-cli -h 192.168.7.1 LPUSH scooter:state unlock

# Lock and request hibernation
redis-cli -h 192.168.7.1 LPUSH scooter:state lock-hibernate

Available commands: lock, unlock, lock-hibernate, force-lock

Seatbox Control (scooter:seatbox)¶

Controls the seatbox lock mechanism.

# Open the seatbox
redis-cli -h 192.168.7.1 LPUSH scooter:seatbox open

Available commands: open

Horn Control (scooter:horn)¶

Controls the horn/buzzer.

# Turn horn on
redis-cli -h 192.168.7.1 LPUSH scooter:horn on

# Turn horn off
redis-cli -h 192.168.7.1 LPUSH scooter:horn off

Available commands: on, off

Blinker Control (scooter:blinker)¶

Controls the turn signals/blinkers.

# Left blinker
redis-cli -h 192.168.7.1 LPUSH scooter:blinker left

# Right blinker
redis-cli -h 192.168.7.1 LPUSH scooter:blinker right

# Hazard mode (both blinkers)
redis-cli -h 192.168.7.1 LPUSH scooter:blinker both

# Turn off blinkers
redis-cli -h 192.168.7.1 LPUSH scooter:blinker off

Available commands: left, right, both, off

Alarm Control (scooter:alarm) - Librescoot Only¶

Controls the motion-based alarm system.

# Enable alarm system (persists settings.alarm.enabled=true)
redis-cli -h 192.168.7.1 LPUSH scooter:alarm enable

# Disable alarm system (persists settings.alarm.enabled=false)
redis-cli -h 192.168.7.1 LPUSH scooter:alarm disable

# Runtime arm/disarm (does not change settings.alarm.enabled)
redis-cli -h 192.168.7.1 LPUSH scooter:alarm arm
redis-cli -h 192.168.7.1 LPUSH scooter:alarm disarm

# Manual alarm trigger (30 seconds)
redis-cli -h 192.168.7.1 LPUSH scooter:alarm start:30

# Stop alarm immediately
redis-cli -h 192.168.7.1 LPUSH scooter:alarm stop

Available commands: enable, disable, arm, disarm, start:<seconds>, stop

Motion Sensor Control - Librescoot Only¶

The scooter:motion command queue still exists (the older scooter:bmx queue is gone). motion-service BRPOPs it and accepts sensitivity:<level>, pin:<pin>, interrupt:<enable|disable>, reset, polling:<hz> and streaming:<enable|disable>.

These are dev conveniences, not configuration: chip configuration is reactive, and the profile controller reprograms the registers on the next alarm or power-manager transition, so a manual sensitivity, pin or interrupt looks like it worked and then reverts. reset duplicates the soft-reset RPC.

There are also RPC methods on motion:rpc. See Motion / IMU (motion).

Power Control (scooter:power) - Librescoot Enhanced¶

Librescoot adds more power control commands:

# Request running state (highest priority)
redis-cli -h 192.168.7.1 LPUSH scooter:power run

# Request suspend
redis-cli -h 192.168.7.1 LPUSH scooter:power suspend

# Request hibernation
redis-cli -h 192.168.7.1 LPUSH scooter:power hibernate

# Manual hibernation (user-initiated)
redis-cli -h 192.168.7.1 LPUSH scooter:power hibernate-manual

# Timer-based hibernation
redis-cli -h 192.168.7.1 LPUSH scooter:power hibernate-timer

# Hibernate for a specific duration; nRF52 wakes the iMX6 after N seconds
redis-cli -h 192.168.7.1 LPUSH scooter:power "hibernate-for:300"

# Cancel a pending hibernate-for and disarm the wake timer
redis-cli -h 192.168.7.1 LPUSH scooter:power hibernate-cancel

# Reboot system
redis-cli -h 192.168.7.1 LPUSH scooter:power reboot

Available commands: run, suspend, hibernate, hibernate-manual, hibernate-timer, hibernate-for:<seconds>, hibernate-cancel, reboot

Modem Control (scooter:modem) - Librescoot Only¶

Controls modem power state.

# Enable modem
redis-cli -h 192.168.7.1 LPUSH scooter:modem enable

# Disable modem
redis-cli -h 192.168.7.1 LPUSH scooter:modem disable

Available commands: enable, disable

There are no GPS commands; modem-service manages GPS automatically based on connectivity state. The modem.gps setting toggles GPS overall.

SMS Send (scooter:sms) - Librescoot Only¶

Sends an SMS through the modem. Unlike the other command queues (plain-string commands), the payload is JSON, because a send needs both a recipient and a body. The optional id token is echoed back as request-id on the sms:sent stream so concurrent senders can correlate outcomes:

redis-cli -h 192.168.7.1 LPUSH scooter:sms '{"to":"+4915112345678","text":"Hello from the scooter"}'
redis-cli -h 192.168.7.1 LPUSH scooter:sms '{"id":"trip-42","to":"+4915112345678","text":"Hello"}'

The terminal outcome lands on the sms:sent stream/channel; send progress is also reflected in the sms hash (state goes sending, then idle or error).

Update Control (scooter:update, scooter:update:mdb, scooter:update:dbc) - Librescoot Only¶

Controls the OTA update system. Per-component lists target one updater instance.

# Force immediate update check on one component
redis-cli -h 192.168.7.1 LPUSH scooter:update:mdb check-now

# Install from a local file (optional checksum)
redis-cli -h 192.168.7.1 LPUSH scooter:update:dbc "update-from-file:/data/ota/image.mender#sha256=<hex>"

# Install from a URL
redis-cli -h 192.168.7.1 LPUSH scooter:update:mdb "update-from-url:https://example.com/update.mender"

# Ask what a switch to another channel would download (changes nothing)
redis-cli -h 192.168.7.1 LPUSH scooter:update:mdb preview-channel:stable
redis-cli -h 192.168.7.1 HMGET ota preview-status:mdb preview-version:mdb preview-size:mdb

Per-component commands (scooter:update:mdb / scooter:update:dbc): check-now, update-from-file:<path>[#sha256=<hex>], update-from-url:<url>[#sha256=<hex>]

preview-channel:<channel> reports the latest release on <channel> for this component's variant_id and the size of its .mender artifact, into the ota hash's preview-* fields. It sets nothing and downloads nothing; the dashboard uses it to price a channel switch before asking the rider to confirm.

The shared scooter:update list is consumed by vehicle-service, not the updaters: update-service pushes lifecycle commands (start, complete, start-dbc, complete-dbc) there to drive the vehicle's updating state.

See update-service documentation.

Settings Overlay Control (settings:overlay) - Librescoot Only¶

Apply or clear a named settings overlay. See Settings Overlay Commands above for full details.

# Enable Service mode
redis-cli -h 192.168.7.1 LPUSH settings:overlay apply:service

# Disable Service mode
redis-cli -h 192.168.7.1 LPUSH settings:overlay clear:service

Available commands: apply:service, clear:service

CPU Governor Control (scooter:governor) - Librescoot Only¶

Consumed by pm-service; switches the CPU frequency governor. vehicle-service and update-service push ondemand here (when leaving stand-by, and at download start, respectively).

redis-cli -h 192.168.7.1 LPUSH scooter:governor performance

Available commands: ondemand, powersave, performance

Command Channel Notes¶

• Commands use the LPUSH operation to queue requests
• Services subscribe to these channels using BRPOP and process commands sequentially
• State changes resulting from commands are published to the corresponding hash fields and pub/sub channels
• Command results can be monitored by subscribing to the relevant state hashes (e.g., vehicle hash for lock/unlock state)
• Librescoot adds several new command channels for alarm, motion, modem, keycard, governor, and update control