device22 query triggers setting of dpid

[szupi-ipuzs]

Hi, I recently got Nedis camera (WIFICO11CWT), and I was not able to make it broadcast any dpids by itself. tinytuya was simply saying "no response". All I could see were reponses to the setting changes I made from Tuya app.

After experimenting and analysing the logs, I've realized this is a "device22" case. So I've build this simple script and got it to respond with most of the dpids!

import tinytuya

#tinytuya.set_debug(True)

dpids = [101, 103, 104, 106, 108, 109, 110, 111, 115, 117, 134, 139, 140, 141, 150, 151, 168, 169, 253, 254, 255]

for dpid in dpids:
    d = tinytuya.Device('REDACTED', 'REDACTED',
      'REDACTED',
      'device22')

    d.set_version(3.3)

    print(" > Send Request for dpid " + str(dpid) + " < ")
    d.add_dps_to_request(dpid)
    payload = d.generate_payload(tinytuya.DP_QUERY)
    d.send(payload)

    data = d.receive()
    while data:
        print('Received Payload: %r' % data)
        data = d.receive()

Unfortunately it seems that simply quering the dpids like above triggers setting them (to some default). And in the case of dpid 111, it even triggers formating of sdcard. Am I doing something wrong here? I thought DP_QUERY was not supposed to change anything... Or is it a specific function of device22?

Here's the logs with set_debug(True): nedis.log

[uzlonewolf]

Are you sure it's a device22? That setting overrides DP_QUERY and changes it to CONTROL_NEW, among other things. CONTROL_NEW is the "set" command for most devices, and setting them via TinyTuya is going to elicit a "changed" response just like setting them via the app.

[szupi-ipuzs]

Yes, i'm pretty sure, at least tinytuya seems to think so. Here's the log from scanning with "devices" option, just for this device (id bf82d07207ebdee95dk0te). nedis2.log

[uzlonewolf]

Hmm, I don't think it is a device22 as DP_QUERY would not cause a "set" if that were the case. Perhaps @jasonacox can check those logs and let us know what he thinks, he's a bit more familar with those devices than I am. The detection function is kinda crude and just makes some assumptions anytime it gets an "unvalid" response. What happens if you use DP_QUERY_NEW instead?

[jasonacox]

Hi @szupi-ipuzs !

@uzlonewolf is right, this is an odd behavior even for device22. The query should NOT cause changes to the device. I have seen this in the past with some cheap smartplug models that toggled power when you queried state (not great if you are using it to monitor something like a refrigerator!) - in a few of those cases (can't find the issue links at the moment), there was a firmware upgrade that addressed some of the instability.

Apart from what @uzlonewolf suggested, you might try running a monitor loop to see if the device emits data points over time:

https://github.com/jasonacox/tinytuya/blob/5d2f5488744e3121dc9d2c24bb17a255ea35f682/examples/monitor.py#L10-L66

I looked at the logs and didn't see the unvalid response that would trigger tinytuya to fall back to device22 mode. What do you get with scan?

[szupi-ipuzs]

@jasonacox

I looked at the logs and didn't see the unvalid response that would trigger tinytuya to fall back to device22 mode. What do you get with scan?

I have attached nedis2.log in on of the previous posts. There definitely is an "unvalid" response there.

There's no new firmware for this device, at least Tuya app does not find any. I might try with Nedis app though.

I will try to use your script to see if device emits something over time.