-
Notifications
You must be signed in to change notification settings - Fork 0
shadow.md
Dashboard implements device shadow mechanism, semantically identical to to the Azure device twin and Amazon IoT device shadow. Google IoT Core state/config objects provide similar functionality, but implemented quite differently.
Device shadow is a JSON object that is associated with a device. It lives on a cloud, keeps device state, and always available regardless whether the associated device is online or offline. Shadow object has four top-level keys:
-
desired
- this is the state you want your device to have. -
reported
- this is the state your device actually has. -
delta
- automatically generated by the cloud every timedesired
orreported
changes.delta
is the difference betweendesired
andreported
only for keys that are present indesired
. -
tags
- arbitrary settings invisible to the device but visible to the cloud user.
The structure of the desired
and reported
subobjects is arbitrary -
create whatever structure you wish. However, the dash
library that connects
your device to the dashboard, reserves some keys:
-
reported.ota
- object that keeps firmware information and last OTA status -
reported.stats
- object that keeps device RAM statistics
The device shadow is displayed in the device list, and it is available for edit in the device panel (when clicked on the device name):
Devices can update their shadow using C API or JavaScript API, see shadow library for reference.
In order to create new keys, send a shadow update with that new key and its
value. In order to delete a key, send a shadow update where that key is set
to null
.
The best practive for using shadow on the device side is this:
- Catch the
MGOS_SHADOW_CONNECTED
event that indicates that the device is connected to its shadow, and report device current state to thereported
key. - Catch
MGOS_SHADOW_UPDATE_DELTA
event, and apply all keys in thedelta
to the device. If the state is changed, report and update to thereported
key.
Example: see example-shadow-js app for the JavaScript example, and https://github.com/cesanta/mongoose-os-smart-light for C example. Both implement the canonical best practice mentioned above.
ADS1X1X I2C ADS7843/XPT2046 SPI APDS9960 I2C ATCA BH1730 sensor BME280/BMP280 BQ27421 Barometers Bosch BM222 CCS811 I2C DHT DS3231 I2C Dallas RMT ESP32 touch sensor HTU21D(F) I2C ILI9341 SPI IMU INA219 I2C INA226 I2C INA3221 I2C Inventek ISM43xxx WiFi MAX7219 I2C MAX72xx LED matrix MCP23XXX I2C MCP9808 I2C MQ135 gas sensor Neopixel Onewire RMT PCF857X I2C SHT31 I2C SSD1306 OLED STMPE610 SPI Si7005 sensor Si7021 I2C TI TMP006 temp sensor VEML6075 I2C VFS (LittleFS) VFS (RAM) VFS (SPI NOR Flash) VFS (SPIFFS) VFS (Winbond W25XXX) VFS (another device) VFS (encryption) VFS bh1750 I2C
RPC core RPC loopback RPC over BLE GATT RPC over MQTT RPC over UART RPC over UDP Service - ATCA Service - Config Service - Cron Service - FS Service - GATT client Service - GPIO Service - I2C Service - OTA Service - WiFi