Smart Home smoke detector

[edgarhildering]

When I read the docs on tinytuya i don't see any docs or examples to connect data-producing devices like thermometers or smoke alarms. I am wondering

• do these devices send their data periodicly?
• is it possible to receive data from these devices?
  I am planning to put smoke alarms in my house and tuya products are a good candidate.
  (I am not a great pythoneer, but I managed to combine tinytuya, mqtt and the scheduler in one python script for comms with domoticz through mqtt)

--Edgar

[jasonacox]

Hi @edgarhildering -

Most battery powered Tuya devices do not stay online. They boot up, connect to the WiFi and send their data payloads to the Tuya Cloud, then they shut down to save power. The result means that it is very difficult to get a local connection to these devices to mine that data. If you do manage to ping them enough to catch it when it wakes ups, you may end up keeping it alive but draining the battery. All that to say, you are probably better off getting this data from the Tuya Cloud instead of directly from the device (which TinyTuya provides).

I am getting enough interest from the community to add Cloud functions to TinyTuya. It already uses Tuya Cloud for the Wizard so expanding those to accessible functions shouldn't be too hard. Look for an update soon (if my holiday time off goes well :).

Feel free to share any tips you have with your TinyTuya + mqtt + Domoticz stack! Others may be appreciate it as well.

[edgarhildering]

Thanks for yor reply Jason! Op vr 10 dec. 2021 06:28 schreef Jason Cox ***@***.***>:

…

Hi @edgarhildering <https://github.com/edgarhildering> - Most battery powered Tuya devices do not stay online. They boot up, connect to the WiFi and send their data payloads to the Tuya Cloud, then they shut down to save power. The result means that it is very difficult to get a local connection to these devices to mine that data. If you do manage to ping them enough to catch it when it wakes ups, you may end up keeping it alive but draining the battery. All that to say, you are probably better off getting this data from the Tuya Cloud instead of directly from the device (which TinyTuya provides). I am getting enough interest from the community to add Cloud functions to TinyTuya. It already uses Tuya Cloud for the Wizard so expanding those to accessible functions shouldn't be too hard. Look for an update soon (if my holiday time off goes well :). Feel free to share any tips you have with your TinyTuya + mqtt + Domoticz stack! Others may be appreciate it as well. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#87 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB53ECI2NRLJLDDQVXGEFLLUQGFXRANCNFSM5JWJZQJA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[edgarhildering]

Hi Jason, Hope you had a good Christmas overthere. We had some snow (Netherlands and Germany) but it is thawing away at the moment... You wrote: "I am getting enough interest from the community to add Cloud functions to TinyTuya". You may add me for more interest, Among my X-mas presents were: a Tuya Smart Camera and a Tuya Smoke detector. Of course I want to connect them to domoticz. Currently I am writing the 'story' of the connection domoticz <-> MQTT <-> ESP8266-DIY and domoticz <-> MQTT <-> Python <-> TinyTuya <-> Tuya-off-the-shelf. As you can expect "<-> ESP8266-DIY" is actually the same as "<-> Python <-> TinyTuya <-> Tuya-off-the-shelf". The story is not complete yet, still working on it. The wizard is able to 'inspect' the cloud. If I can be of assistance to help you with testing. kind regards, --Edgar

…

On Fri, Dec 10, 2021 at 7:28 PM Edgar Hildering ***@***.***> wrote: Thanks for yor reply Jason! Op vr 10 dec. 2021 06:28 schreef Jason Cox ***@***.***>: > Hi @edgarhildering <https://github.com/edgarhildering> - > > Most battery powered Tuya devices do not stay online. They boot up, > connect to the WiFi and send their data payloads to the Tuya Cloud, then > they shut down to save power. The result means that it is very difficult to > get a local connection to these devices to mine that data. If you do manage > to ping them enough to catch it when it wakes ups, you may end up keeping > it alive but draining the battery. All that to say, you are probably better > off getting this data from the Tuya Cloud instead of directly from the > device (which TinyTuya provides). > > I am getting enough interest from the community to add Cloud functions to > TinyTuya. It already uses Tuya Cloud for the Wizard so expanding those to > accessible functions shouldn't be too hard. Look for an update soon (if my > holiday time off goes well :). > > Feel free to share any tips you have with your TinyTuya + mqtt + Domoticz > stack! Others may be appreciate it as well. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#87 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AB53ECI2NRLJLDDQVXGEFLLUQGFXRANCNFSM5JWJZQJA> > . > Triage notifications on the go with GitHub Mobile for iOS > <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> > or Android > <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. > >

[jasonacox]

Hi @edgarhildering - We had a great Christmas as well! I love the snow... that and a nice warm fire. :)

I have good news. I have just released v1.3.0 that adds Cloud functions to TinyTuya to make it easier to pull data from the TuyaCloud and manage devices via the Cloud APIs. Here is an example script:

import tinytuya

# Turn on Debug Mode (optional)
# tinytuya.set_debug(True)

# Connect to Tuya Cloud
# c = tinytuya.Cloud() # This uses the tinytuya.json file created by the wizard or
c = tinytuya.Cloud(
        apiRegion="us", 
        apiKey="xxxxxxxxxxxxxxxxxxxx", 
        apiSecret="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", 
        apiDeviceID="xxxxxxxxxxxxxxxxxxID")

# Display list of devices
devices = c.getdevices()
print("Device List: %r" % devices)

# Select a Device ID to Test
id = "xxxxxxxxxxxxxxxxxxID"

# Display Properties of Device
result = c.getproperties(id)
print("Properties of device:\n", result)

# Display Functions of Device
result = c.getfunctions(id)
print("Functions of device:\n", result)

# Display DPS IDs of Device
result = c.getdps(id)
print("DPS IDs of device:\n", result)

# Display Status of Device
result = c.getstatus(id)
print("Status of device:\n", result)

# Send Command - This example assumes a basic switch
commands = {
	'commands': [{
		'code': 'switch_1',
		'value': True
	}, {
		'code': 'countdown_1',
		'value': 0
	}]
}
print("Sending command...")
result = c.sendcommand(id,commands)
print("Results:\n", result)

[edgarhildering]

Hi Jason, I think I found a little flaw in your code. I got this error just before my daemon was forced to restart. Feb 16 12:31:17 ge-domoticz python3.7[13872]: Traceback (most recent call last): Feb 16 12:31:17 ge-domoticz python3.7[13872]: File "/home/pi/domoticz/scripts/python/test11-mqtt.py", line 247, in <module> Feb 16 12:31:17 ge-domoticz python3.7[13872]: st=d.set_timer(switches[idx]['dutyTime']) Feb 16 12:31:17 ge-domoticz python3.7[13872]: File "/home/pi/.local/lib/python3.7/site-packages/tinytuya/__init__.py", line 1014, in set_timer Feb 16 12:31:17 ge-domoticz python3.7[13872]: devices = status['dps'] Feb 16 12:31:17 ge-domoticz python3.7[13872]: KeyError: 'dps' Feb 16 12:31:17 ge-domoticz systemd[1]: tuyaPython.service: Main process exited, code=exited, status=1/FAILURE Feb 16 12:31:17 ge-domoticz systemd[1]: tuyaPython.service: Failed with result 'exit-code'. Feb 16 12:31:22 ge-domoticz systemd[1]: tuyaPython.service: Service RestartSec=5s expired, scheduling restart. Feb 16 12:31:22 ge-domoticz systemd[1]: tuyaPython.service: Scheduled restart job, restart counter is at 4. Feb 16 12:31:22 ge-domoticz systemd[1]: Stopped python-process to handle timed resyncs to domoticz. Feb 16 12:31:22 ge-domoticz systemd[1]: Started python-process to handle timed resyncs to domoticz. When I looked at line 1014 i saw that you try to get a status to find the dps for the timer. And my conclusion is that the status() did return an error (905? Offline?) instead of the expected status report that contains the key dps. For now I solved the problem by calling the set_timer with parameter 9, skipping the lines around 1014... Do what you want with it! kind regards, --Edgar

…

On Fri, Dec 31, 2021 at 10:24 AM Jason Cox ***@***.***> wrote: Hi @edgarhildering <https://github.com/edgarhildering> - We had a great Christmas as well! I love the snow... that and a nice warm fire. :) I have good news. I have just released v1.3.0 that adds Cloud functions to TinyTuya to make it easier to pull data from the TuyaCloud and manage their devices via the Cloud APIs. Here is an example script: import tinytuya # Turn on Debug Mode (optional)# tinytuya.set_debug(True) # Connect to Tuya Cloud# c = tinytuya.Cloud() # This uses the tinytuya.json file created by the wizard orc = tinytuya.Cloud( apiRegion="us", apiKey="xxxxxxxxxxxxxxxxxxxx", apiSecret="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", apiDeviceID="xxxxxxxxxxxxxxxxxxID") # Display list of devicesdevices = c.getdevices()print("Device List: %r" % devices) # Select a Device ID to Testid = "xxxxxxxxxxxxxxxxxxID" # Display Properties of Deviceresult = c.getproperties(id)print("Properties of device:\n", result) # Display Functions of Deviceresult = c.getfunctions(id)print("Functions of device:\n", result) # Display DPS IDs of Deviceresult = c.getdps(id)print("DPS IDs of device:\n", result) # Display Status of Deviceresult = c.getstatus(id)print("Status of device:\n", result) # Send Command - This example assumes a basic switchcommands = { 'commands': [{ 'code': 'switch_1', 'value': True }, { 'code': 'countdown_1', 'value': 0 }] }print("Sending command...")result = c.sendcommand(id,commands)print("Results:\n", result) — Reply to this email directly, view it on GitHub <#87 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB53ECKLYVAM76TILREVNKTUTVZFXANCNFSM5JWJZQJA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[jasonacox]

Thanks for this @edgarhildering. Your workaround is actually the best way to use set_timer() since the DPS for timing setting can vary with devices. Without specifying the DPS for the timer, it will try to find the last DPS value in the status response (as you pointed out) and will use that. If the device throws an error, that will cause it to fail as you note.

Bug Fix - I agree with you that throwing a python error when unable to find the DPS value is not what we want. I have added some minor error checking to help with this case. I'll check in the code tonight and it will show up in the v1.3.2 release.

[gabrielklein]

Some more information

1. I bought a tuya's zigbee gateway and a few smoke detector, door opener detector and CO detectors.
   Important: The name starts with "CO{something)", "Smoke{sth}" and "Detect{sth}".
   It's how I separate "object types".

Temperature and infrared sensors are on it's way :P

2. I generate "snapshot.json"

cd /home/gabriel/tuya
rm -rf snapshot.json
cd tinytuya
python3.11 -m tinytuya wizard
python3.11 -m tinytuya scan

Don't forget to regenerate it when you add a device.

3. I send information from tuya to mqtt
   (tip if you are on linux: mosquitto_sub -t "#" -h 10.1.2.3 -v | grep tuya )
4. I have 2 python scripts, one for objects that respond to commands, and another one for my zigbee gateway. I prefer zigbee honestly.
5. My "zigbee" realtime code - you will need to adapt some parts :)
   My device is called : NetGateway

import tinytuya
import tinytuya.tinytuya.core

import json
import time
import datetime as dt
from paho.mqtt import client as mqtt_client
from tinytuya.tinytuya.core import Device as Device
from tinytuya.tinytuya import HEART_BEAT as HEART_BEAT

# Only one instance at a time
# tendo-0.3.0/src/tendo
from tendo import singleton
me = singleton.SingleInstance()  # will sys.exit(-1) if other instance is running

# ------------------------------------------------
# Config
# ------------------------------------------------
snapshotpath = '/home/gabriel/tuya/snapshot.json'
broker = '127.0.0.1'
port = 1883
basetopic = "tuya"
client_id = 'TinyTuyaMqttRT'

# ------------------------------------------------
# Main process
# ------------------------------------------------
def main():

    client = connectMqtt()
    f = open(snapshotpath)
    data = json.load(f)
    f.close()
    
    print('------------------------------------------------')
    print('Start processing')
    print('The hour is {}'.format(dt.datetime.today()))    
    print('------------------------------------------------')

    # Map data by device name and UUID  
    dataName = {item["name"]: item for item in data['devices']}
    dataUUID = {item.get("uuid"): item for item in data['devices']}
    dataGW = dataName["NetGateway"]
    
    print('Connect to NetGateway')
    gw = Device( dataGW["id"], address=dataGW["ip"], local_key=dataGW["key"], persist=True, version=3.4 )

    while True:      
      try:

        data = gw.receive()
        data = data.get("data")
        
        if data :

          cid = data.get("cid")
          data["name"] = dataUUID.get(cid).get("name")

          print( "Received data: ", data )
          
          dps = data.get("dps")
          if data["name"][0:2] == 'CO':
            if "2" in dps:
              level = dps.get("2")
              level = int(level) / 100
              print("just before sent", level)
              client.publish(basetopic + "/" + data["name"] + "/level", level)
          elif data["name"][0:5] == 'Smoke':
            if "1" in dps:
              status = dps.get("1")
              # We get "alarm" or "normal"
              client.publish(basetopic + "/" + data["name"] + "/alarm", status)
            if "2" in dps:
              level = dps.get("2")
              level = int(level) / 100
              client.publish(basetopic + "/" + data["name"] + "/level", level)
            if "101" in dps:
              alarm = dps.get("101")
              client.publish(basetopic + "/" + data["name"] + "/alarmtest", alarm)
          elif data["name"][0:6] == 'Detect':
            if "1" in dps:
              status = dps.get("1")
              client.publish(basetopic + "/" + data["name"] + "/open", status)

      except Exception as e:
            print('Problem with devices (realtime)!')
            print(e)
       
# ------------------------------------------------
# Connect to mqtt
# ------------------------------------------------

def connectMqtt():
    client = mqtt_client.Client(client_id)
    #client.username_pw_set(username, password)
    client.connect(broker, port)
    return client

# ------------------------------------------------
# Run main
# ------------------------------------------------
main()

[uzlonewolf]

Unexpected payload =

b'd55bb35f75c6\x13\xd3~]_\x9b\xa8\xa6\xab\x81\x0b\x91\x87Il\x01<\n\x18\x1d;\x94w\x0c\x95\x85\xd5\xb9U`\x87LAwrx\xecK1;\x89<\xc7\x98l$og\x12\x9f\xe0| \x93\xa6\x8c\xd4\xa2R,\x16\xf6\xff\xf3\xf9\x8d(\xca\x8a\xdd\\\xfbB\x0b\x83\xfc\xf5MB\xcb\xbdW\xbf\x19\xc4\xfcC\x19=c%\xcd\xe4\xd6\xe7\xcd{\xfeX\xe1W\xa2\xc8Q\x86\x15\xe5OSs\x84\x02Sz\xafh\xa9\x08~j\x1bQG\x16W%Z\xf9BSg\xb0\xc6\x1d\x00P\x18\xea\xe5\xec\x1btq\xf7\xa0#\xeb\xc2t\x84C\xcd\x12\x0c\x1c\xa1\xe2GJ\xd3\xc4\xa2\x17M\xe2n\x05\x99\xc4|'

Yeah, this decrypts to:

b'\x00\x00\x00\x00{"ip":"192.168.188.79","gwId":"bfedad1a64d3bb2674cerk","active":2,"ablilty":0,"encrypt":true,"productKey":"keyyj3fy8x98arty","version":"3.5","token":true}

@edgarhildering Upgrade your TinyTuya and it should just work.

[edgarhildering]

ok, i did an upgrade to 1.12.9; but had still the scanner 1.7.2. After upgrading the scanner tot 1.12.9 there is better output (with version 3.5 payload) but still some sort of an error:
ZigBee Gateway Product ID = keyyj3fy8x98arty [Valid Broadcast]: Address = 192.168.188.79 Device ID = bfedad1a64d3bb2674cerk (len:22) Local Key = -------- Version = 3.5 Type = default, MAC = 18:69:d8:47:09:66 Access rejected by 192.168.188.79 (check key): Invalid JSON Response from Device: devid not found
No clue why the access is rejected. It is understandable that there is no IP address for the subdevice since it is behind the gateway.

I've attached a debugfile from the scan -d; since all my keys are in there (!) I prefer to encrypt it. I think you can find the product id from my zigbee gateway...

regards --Edgar

[uzlonewolf]

I got it @edgarhildering, thanks! I went ahead and removed the download link from your post. Now that TinyTuya has been updated it looks like the scan went fine.

As for the gateway, I've never had good luck getting gateways to respond to poll requests. They do work fine when you poll sub-devices however. You should be good to go after adding your Zigbee sub-devices into something like examples/zigbee_gateway.py

[edgarhildering]

many thanks for the quick response. I had a quick look at the example. I'll try to get sub-devices working standalone first. If I succeed to get it going, I will integrate it in my daemon that handles the requests from Domoticz...

--Edgar

[edgarhildering]

Dear Jason & co,
After your email about the zigbee gateway, I got to work. I have now managed to address the sub-devices from my python daemon even though the code is a bit quirky for my liking. (the daemon sniffs domoticz's MQTT messages and translates them into switching commands using tinytuya)
Of course I also experimented with your sample program. These are my findings:

• With your program I sometimes had error messages as a result.
• when starting the program I get no data back from the zigbee gateway (receive-call) if there is no activity on one of the sub-devices.
• if one of the devices is activated (turn on/turn off), even by an external source (my daemon), the gateway suddenly starts sending data.

After a bit of experimenting, this became clear to me: the gateway 'stores' the activity of a device. Setting up the connection with the Zigbee Gateway acts as a sort of subscribe. Issueing a receive() triggers the gateway to start sending any outstanding changes in the status of the devices, in chronological order. The mechanism seems to be very similar to MQTT.

I've added a simple program based on your example, together with some output. To understand it you need to know what is happening.

• I have only 1 subdevice in the gateway (a switch called Stekker 2)
• The device is controlled through Domoticz -> daemon:
  • when Domoticz turns the switch off, the daemon will send an 'turn-off' to the switch
  • when Domoticz turns the switch on, the daemon will
    (1) turn the switch on
    (2) set a countdown timer for 325 seconds
    (3) check with Domoticz just before the timer expires what the state of the switch is:
    if 'on' then start at step (1)
    if 'off' perform turn-off

Why the countdown timer? This way if ever there get some comms lost, processes stop or whatever, the switch will then turn itself off after 325 secs. (very helpfull if it controls a heater!)
Step (3) does not leave any messages in the output I have supplied. But you can see the effect through the execution of step (1)

Interesting to see is the time difference between the stamp and the t-value in the data. Also the counter will flag a 'change status' at round minute values. I have a sleeptime of 14 and connection time out of 1. This means that the max delay in knowing what is happening is 15 secs

Furthermore I sometimes see a response with 'type': 'query'. No idea what is happening there and why.

Maybe you both already know this all. But it was quite a discovery for me.

Kind regards, --Edgar

import tinytuya
import time

# Zigbee Gateway support uses a parent/child model where a parent gateway device is
#  connected and then one or more children are added.

# configure the parent device
#   address=None will cause it to search the network for the device
gw = tinytuya.Device( 'bfe----------------erk', address=None, local_key='lpP----------[z#', persist=True, version=3.5, connection_timeout=1 )
print( 'GW IP found:', gw.address )

print(" > Begin Monitor Loop <")
pingtime = time.time()

while(True):
    if( pingtime <= time.time() ):
        print('--- new heartbeat genewrated---')
        payload = gw.generate_payload(tinytuya.HEART_BEAT)
        pingtime = time.time() + 300

    # receive from the gateway object to get updates for all sub-devices
    gw.send(payload)
    while True:
	    print('recv: ', end='')
	    data = gw.receive()
	    print( 'data @ {0} = {1}'.format(time.time(),data ))
	    if data is None:
	      break
    time.sleep(14)

OUTPUT:

pi@ge-domoticz:~/domoticz/scripts/python $ python3 zigtest5.py 
GW IP found: 192.168.188.107
> Begin Monitor Loop <
--- new heartbeat genewrated---
recv: data @ 1691499496.2879784 = None
recv: data @ 1691499511.3126395 = None
recv: data @ 1691499525.3432677 = {'protocol': 4, 't': 1691499513, 'data': {'dps': {'1': True}, 'cid': '842e14fffe5ac82e'}, 'dps': {'1': True}}
recv: data @ 1691499525.3473618 = {'protocol': 4, 't': 1691499513, 'data': {'dps': {'9': 325}, 'cid': '842e14fffe5ac82e'}, 'dps': {'9': 325}}
recv: data @ 1691499526.3516054 = None
recv: data @ 1691499540.3795502 = {'protocol': 4, 't': 1691499539, 'data': {'dps': {'9': 300}, 'cid': '842e14fffe5ac82e'}, 'dps': {'9': 300}}
recv: data @ 1691499541.3830314 = None
recv: data @ 1691499556.4140015 = None
recv: data @ 1691499571.4449806 = None
recv: data @ 1691499586.4786665 = None
recv: data @ 1691499600.503468 = {'protocol': 4, 't': 1691499599, 'data': {'dps': {'9': 240}, 'cid': '842e14fffe5ac82e'}, 'dps': {'9': 240}}
recv: data @ 1691499601.5090675 = None
recv: data @ 1691499616.5325482 = None
recv: data @ 1691499631.5616746 = None
recv: data @ 1691499646.592754 = None
recv: data @ 1691499660.6189618 = {'protocol': 4, 't': 1691499660, 'data': {'dps': {'9': 180}, 'cid': '842e14fffe5ac82e'}, 'dps': {'9': 180}}
recv: data @ 1691499661.6217453 = None
recv: data @ 1691499676.6525142 = None
recv: data @ 1691499691.6809301 = None
recv: data @ 1691499706.7117126 = None
recv: data @ 1691499720.995524 = {'protocol': 4, 't': 1691499720, 'data': {'dps': {'9': 120}, 'cid': '842e14fffe5ac82e'}, 'dps': {'9': 120}}
recv: data @ 1691499721.9968758 = None
recv: data @ 1691499737.0276637 = None
recv: data @ 1691499752.0584166 = None
recv: data @ 1691499767.089243 = None
recv: data @ 1691499781.5960846 = {'protocol': 4, 't': 1691499781, 'data': {'dps': {'9': 60}, 'cid': '842e14fffe5ac82e'}, 'dps': {'9': 60}}
recv: data @ 1691499782.5974793 = None
--- new heartbeat genewrated---
recv: data @ 1691499797.620785 = None
recv: data @ 1691499812.642668 = None
recv: data @ 1691499826.6688302 = {'protocol': 4, 't': 1691499814, 'data': {'dps': {'1': True}, 'cid': '842e14fffe5ac82e', 'type': 'query'}, 'dps': {'1': True}}
recv: data @ 1691499826.673255 = {'protocol': 4, 't': 1691499814, 'data': {'dps': {'9': 0}, 'cid': '842e14fffe5ac82e'}, 'dps': {'9': 0}}
recv: data @ 1691499826.677462 = {'protocol': 4, 't': 1691499814, 'data': {'dps': {'9': 325}, 'cid': '842e14fffe5ac82e'}, 'dps': {'9': 325}}
recv: data @ 1691499826.6819427 = {'protocol': 4, 't': 1691499814, 'data': {'dps': {'9': 325}, 'cid': '842e14fffe5ac82e', 'type': 'query'}, 'dps': {'9': 325}}
recv: data @ 1691499827.6870298 = None
recv: data @ 1691499841.7151582 = {'protocol': 4, 't': 1691499838, 'data': {'dps': {'9': 300}, 'cid': '842e14fffe5ac82e'}, 'dps': {'9': 300}}
recv: data @ 1691499842.718423 = None
recv: data @ 1691499857.7489295 = None
recv: data @ 1691499872.7735593 = None
recv: data @ 1691499886.8040233 = {'protocol': 4, 't': 1691499874, 'data': {'dps': {'1': False, '9': 0}, 'cid': '842e14fffe5ac82e'}, 'dps': {'1': False, '9': 0}}
recv: data @ 1691499887.8088496 = None
^CTraceback (most recent call last):
  File "zigtest5.py", line 37, in <module>
    time.sleep(14)
KeyboardInterrupt
pi@ge-domoticz:~/domoticz/scripts/python $