mirror device 'Smoke_Detector': case study

case study: Smoke detector 'mirror' device

[12/2023] Since v. 2.2.4 the use of core_OPENAPI makes this study obsolete: see an updated version here)

_My 'Smoke detector' (WiFi, BATT) is a WiFi device connected only in case of events: so the 'smoke detector' cannot be caught by tuyAPI (see notes).

tuyaDAEMON can nevertheless exchange information via TRIGGER, i.e. using a 'mirror' device._

Smoke Alarm capabilities

From the smartlife interface (using the menu 'add automation: device changes: smoke alarm') I found the following state changes of the 'smoke alarm' device (unknown data points):

• alarm: BOOL, ON/OFF (RO)
• smoke level: string, [0.0..10.0] ppm (RO)
• battery level1: ENUM (GOOD|MEDIUM|LOW) (RO)
• battery level2: int 0..100 % (RO)
• Alarm silence: BOOL, ON/OFF (RW)

From the smartlife interface (using menu 'add automation: tape to run: device actions: smoke alarm') I found the following actions for the 'smoke alarm' device (unknown data points):

• Alarm silence: BOOL, ON/OFF (RW)

'mirror' device capabilities

To reduce complexity I chose to implement in the 'mirror' device only an optimized subset of 'smoke alarm' capabilities: my interest is only on dynamic options and security issues: alarm ON/OFF, the battery status.

• For the 'battery status' I choose for now the simplest way: the 'LOW' level.

status update device => node_red events (see triggerMAP node in core_TRIGGER flow):

   - alarm:ON                         trigger 30030 
   - alarm:OFF                        trigger 30100
            (two triggers are required for a BOOL status)
   - battery level:LOW                trigger 30170
   - battery level:OK                 trigger 30240
            (The automation does a battery status polling every 24H, 3 automation)
   - silence: ON                      trigger 30310
   - silence: OFF                     trigger 30380

commands node-red => device to change status:

  - SET silence:ON                   trigger 50050
  - SET silence:OFF                  trigger 50120

The total count is 9 automation on smartlife, all called 'smokeXXXXY' for simplicity.

description in global.alldevices.fake

  {
         "name": "smoke detector",
         "id": "12345678987654321",
         "power": "BAT",
         "dps": [
            {
               "dp": 30030,
               "name": "alarm",
               "capability": "PUSH",
               "type": "string",
               "comment_01": "Values: 'ON'|'OFF'"
            },
            {
               "dp": 30170,
               "name": "battery",
               "capability": "PUSH",
               "type": "string",
               "comment_01": "Values: 'OK'|'LOW'"
            },
            {
               "dp": 30310,
               "name": "silence",
               "capability": "WO",
               "type": "string",
               "comment_01": "Values:  'ON'|'OFF'"
            }
         ]
      },

9 automation required in smartlife:

• smoke30030: if "smoke"alarm:on, "tuya_bridge"countdown:30030

• smoke30100: if "smoke"alarm:off, "tuya_bridge"countdown:30100

• smoke30170: if "smoke"battery:low + timer: 3:00H every day, "tuya_bridge"countdown:30170

• smoke30240A: if "smoke"battery:medium + timer: 3:00H every day, "tuya_bridge"countdown:30240

• smoke30240B: if "smoke"battery:good + timer: 3:00H every day, "tuya_bridge"countdown:30240

• smoke30310: if "smoke"silence:on, "tuya_bridge"countdown:30310

• smoke30380: if "smoke"silence:off, "tuya_bridge"countdown:30380

• smoke50050: if "tuya_bridge"countdown:50050, "tuya_bridge"countdown:0 + 'smoke'silence:on

• smoke50120: if "tuya_bridge"countdown:50120, "tuya_bridge"countdown:0 + 'smoke'silence:off

implementation

This flow in tuyaDAEMON.mirror_devices implements the smoke detector 'mirror' device :

• PUSH: The 'smoke detector' switch node selects the incoming TUYATRG30030..TUATRG30310 TRIGGERs, then each 'do logging' subflow converts it into the usual device/property/value format for the 'mirror' device. Lastly tuyaDAEMON processes this message in the standard way (dB and 'global.tuyastatus' update).

• SET/GET/SCHEMA/MULTIPLE: first tuyaDAEMON updates the dB, then extracts all the messages for the 'fake' devices. The 'pick and execute' function node for the 'smoke mirror' device is just a selector. It must detect only the SET requests for the 'smoke mirror' device (GET/SCHEMA/MULTIPLE are not required). Then the selected 'REDTRG' subflow builds the 'payload' for the corresponding REDTRG50050...REDTRG50120 TRIGGER and sent it directly to the 'Tuya_bridge' device.