Problem communicating with 2 gang switch

[owl770]

Hi,
I have a number of switches that I am able to communicate with - they include a 3 gang switch and dimmer switches. They work well.
I also have a 2 gang switch that I am having trouble communicating with. The "Smart Life" Android app controls all the switches OK.

The switch broadcasts UDP packets with the following data:
{"ip":"192.168.1.23","gwId":"0720009584f3eb84f920","active":2,"ability":0,"mode":0,"encrypt":true,"productKey":"kZbvCqK7zvFiCGl1","version":"3.1"}

tuya-cli --list-app returns:

Devices(s):
[ { name: 'C&E 2 Gang Switch',
    id: 'bf159f984c175cdccelh3p',
    key: '703a87d2b5c3eb33' },
  { name: 'C&E 3 Gang Switch',
    id: '02861367840d8ea29700',
    key: 'd81faac645a174ab' },
  { name: 'C&E Deck Downlights',
    id: '72016014bcddc2a363cf',
    key: '1b669c9ab7258abb' },
  { name: 'C&E Lounge Downlights',
    id: '72016014bcddc2a33505',
    key: '22726724a2948a77' },
  { name: 'C&E Wall Lights',
    id: '72016014bcddc2a3829e',
    key: 'f23a980a3836f837' } ]

Note that the ID of "C&E 2 Gang Switch" is 22 characters rather than 20. I have been able to ascertain that the 'real' ID is 0720009584f3eb84f920 (from the UDP broadcast packet).

tuya-cli get returns:

tuya-cli get --all --id 0720009584f3eb84f920 --key 703a87d2b5c3eb33
{ devId: '0720009584f3eb84f920', dps: { '1': false, '2': 0 } }

Note that dps 2 is a number rather than a bool.

I have hacked the "list-app" function to display all packets received and found the following...
Firmware is reported as:

{ result:
   [ { typeDesc: 'Wi-Fi Module',
       type: 0,
       currentVersion: '1.0.2',
       timeout: 60,
       upgradeStatus: 0,
       controlType: 0,
       lastUpgradeTime: 0 },
     { typeDesc: 'MCU Module',
       type: 9,
       currentVersion: '1.0.2',
       timeout: 60,
       upgradeStatus: 0,
       controlType: 0,
       lastUpgradeTime: 0 } ],
  t: 1571024307761,
  success: true,
  status: 'ok' }

Schema is reported as:

{ result:
   [ { code: 'countdown_2',
       dpId: 10,
       time: 1570778123867,
       type: 'value',
       value: '0' },
     { code: 'switch_1',
       dpId: 1,
       name: 'Path',
       time: 1571007033478,
       type: 'bool',
       value: 'false' },
     { code: 'switch_2',
       dpId: 2,
       name: 'Pitch',
       time: 1571024123423,
       type: 'bool',
       value: 'false' },
     { code: 'countdown_1',
       dpId: 9,
       time: 1570778123867,
       type: 'value',
       value: '0' } ],
  t: 1571024308235,
  success: true,
  status: 'ok' }

Note that there are 4 dps reported - two of them being "countdown" with a type of "value" and two being "switch" with a type of "bool".

Any suggestions on what further data I need to capture to get this problem investigated/fixed? Thanks.

[owl770]

Here is the debug output from tuya-cli get:

DEBUG=* tuya-cli get --id 0720009584f3eb84f920 --key 703a87d2b5c3eb33 --all --protocol-version 3.1
  TuyAPI Finding missing IP undefined or ID 0720009584f3eb84f920 +0ms
  TuyAPI Received UDP message. +392ms
  TuyAPI UDP data: +5ms
  TuyAPI { payload:
  TuyAPI    { ip: '192.168.1.24',
  TuyAPI      gwId: '02861367840d8ea29700',
  TuyAPI      active: 2,
  TuyAPI      ability: 0,
  TuyAPI      mode: 0,
  TuyAPI      encrypt: true,
  TuyAPI      productKey: 'a0peFph978Be8eLj',
  TuyAPI      version: '3.3' },
  TuyAPI   leftover: false,
  TuyAPI   commandByte: 19,
  TuyAPI   sequenceN: 0 } +0ms
  TuyAPI Received UDP message. +2s
  TuyAPI UDP data: +1ms
  TuyAPI { payload:
  TuyAPI    { ip: '192.168.1.28',
  TuyAPI      gwId: 'bf159f984c175cdccelh3p',
  TuyAPI      active: 2,
  TuyAPI      ablilty: 0,
  TuyAPI      encrypt: true,
  TuyAPI      productKey: 'keyuhq748jucq9fy',
  TuyAPI      version: '3.3' },
  TuyAPI   leftover: false,
  TuyAPI   commandByte: 19,
  TuyAPI   sequenceN: 0 } +0ms
  TuyAPI Received UDP message. +204ms
  TuyAPI UDP data: +1ms
  TuyAPI { payload:
  TuyAPI    { ip: '192.168.1.25',
  TuyAPI      gwId: '72016014bcddc2a3829e',
  TuyAPI      active: 2,
  TuyAPI      ability: 0,
  TuyAPI      mode: 0,
  TuyAPI      encrypt: true,
  TuyAPI      productKey: 'bSXSSFArVKtc4DyC',
  TuyAPI      version: '3.3' },
  TuyAPI   leftover: false,
  TuyAPI   commandByte: 19,
  TuyAPI   sequenceN: 0 } +0ms
  TuyAPI Received UDP message. +103ms
  TuyAPI UDP data: +1ms
  TuyAPI { payload:
  TuyAPI    { ip: '192.168.1.23',
  TuyAPI      gwId: '0720009584f3eb84f920',
  TuyAPI      active: 2,
  TuyAPI      ability: 0,
  TuyAPI      mode: 0,
  TuyAPI      encrypt: true,
  TuyAPI      productKey: 'kZbvCqK7zvFiCGl1',
  TuyAPI      version: '3.1' },
  TuyAPI   leftover: false,
  TuyAPI   commandByte: 0,
  TuyAPI   sequenceN: 0 } +0ms
  TuyAPI Connecting to 192.168.1.23... +4ms
  TuyAPI Socket connected. +7ms
  TuyAPI GET Payload: +1ms
  TuyAPI { gwId: '0720009584f3eb84f920', devId: '0720009584f3eb84f920' } +0ms
  TuyAPI Received data: 000055aa000000010000000a00000044000000007b226465764964223a223037323030303935383466336562383466393230222c22647073223a7b2231223a66616c73652c2232223a307d7d3422d0010000aa55 +13ms
  TuyAPI Parsed: +1ms
  TuyAPI { payload:
  TuyAPI    { devId: '0720009584f3eb84f920', dps: { '1': false, '2': 0 } },
  TuyAPI   leftover: false,
  TuyAPI   commandByte: 10,
  TuyAPI   sequenceN: 1 } +0ms
  TuyAPI GET Payload: +1ms
  TuyAPI { gwId: '0720009584f3eb84f920', devId: '0720009584f3eb84f920' } +0ms
  TuyAPI Received data: 000055aa000000020000000a00000044000000007b226465764964223a223037323030303935383466336562383466393230222c22647073223a7b2231223a66616c73652c2232223a307d7d905c52c40000aa55 +13ms
  TuyAPI Parsed: +0ms
  TuyAPI { payload:
  TuyAPI    { devId: '0720009584f3eb84f920', dps: { '1': false, '2': 0 } },
  TuyAPI   leftover: false,
  TuyAPI   commandByte: 10,
  TuyAPI   sequenceN: 2 } +1ms
  TuyAPI Disconnect +0ms
{ devId: '0720009584f3eb84f920', dps: { '1': false, '2': 0 } }
  TuyAPI Socket closed: 192.168.1.23 +2ms

[codetheweb]

Sorry, I'm not clear on what your question is. It appears to be working, other than the oddity with the ID not appearing in the list-app command correctly.

If you can capture the HTTPS requests that the app makes when retrieving the device list (e.g. with Charles) and email it to me, I can try and figure out why it's not parsing the ID correctly.

[owl770]

Thanks for the reply. I have searched the web for a guide on how to capture the HTTPS requests using Charles but am unable to find one. Sorry to be annoying but can you recommend a guide on how to do this? I have tried sniffing with wireshark but that was unsuccessful (apart from seeing the switch do a UDP broadcast every 3 seconds). Thanks in advance.

[owl770]

Just found something that may be interesting...in the Smart Life app, it reports the "virtual id" of the 2 gang switch as "bf159f984c175cdccelh3p", same as tuya-cli list-app.

The results of tuya-cli get using this ID returns:

DEBUG=* tuya-cli get --id bf159f984c175cdccelh3p --key 703a87d2b5c3eb33 --all
  TuyAPI Finding missing IP undefined or ID bf159f984c175cdccelh3p +0ms
  TuyAPI Received UDP message. +468ms
  TuyAPI UDP data: +5ms
  TuyAPI { payload:
  TuyAPI    { ip: '192.168.1.23',
  TuyAPI      gwId: '0720009584f3eb84f920',
  TuyAPI      active: 2,
  TuyAPI      ability: 0,
  TuyAPI      mode: 0,
  TuyAPI      encrypt: true,
  TuyAPI      productKey: 'kZbvCqK7zvFiCGl1',
  TuyAPI      version: '3.1' },
  TuyAPI   leftover: false,
  TuyAPI   commandByte: 0,
  TuyAPI   sequenceN: 0 } +0ms
  TuyAPI Received UDP message. +712ms
  TuyAPI UDP data: +1ms
  TuyAPI { payload:
  TuyAPI    { ip: '192.168.1.24',
  TuyAPI      gwId: '02861367840d8ea29700',
  TuyAPI      active: 2,
  TuyAPI      ability: 0,
  TuyAPI      mode: 0,
  TuyAPI      encrypt: true,
  TuyAPI      productKey: 'a0peFph978Be8eLj',
  TuyAPI      version: '3.3' },
  TuyAPI   leftover: false,
  TuyAPI   commandByte: 19,
  TuyAPI   sequenceN: 0 } +0ms
  TuyAPI Received UDP message. +1s
  TuyAPI UDP data: +1ms
  TuyAPI { payload:
  TuyAPI    { ip: '192.168.1.28',
  TuyAPI      gwId: 'bf159f984c175cdccelh3p',
  TuyAPI      active: 2,
  TuyAPI      ablilty: 0,
  TuyAPI      encrypt: true,
  TuyAPI      productKey: 'keyuhq748jucq9fy',
  TuyAPI      version: '3.3' },
  TuyAPI   leftover: false,
  TuyAPI   commandByte: 19,
  TuyAPI   sequenceN: 0 } +0ms
  TuyAPI Connecting to 192.168.1.28... +4ms
  TuyAPI Socket connected. +7ms
  TuyAPI GET Payload: +1ms
  TuyAPI { gwId: 'bf159f984c175cdccelh3p',
  TuyAPI   devId: 'bf159f984c175cdccelh3p' } +0ms
  TuyAPI Received data: 000055aa000000010000000a0000002c0000000148a3f8fcd1d0d65f117b469cf61c597c1bae999e038a906ef62c88686c058bdb7270832a0000aa55 +10ms
  TuyAPI Parsed: +0ms
  TuyAPI { payload: 'json obj data unvalid',
  TuyAPI   leftover: false,
  TuyAPI   commandByte: 10,
  TuyAPI   sequenceN: 1 } +1ms
  TuyAPI GET Payload: +1ms
  TuyAPI { gwId: 'bf159f984c175cdccelh3p',
  TuyAPI   devId: 'bf159f984c175cdccelh3p' } +0ms
  TuyAPI Received data: 000055aa000000020000000a0000002c0000000148a3f8fcd1d0d65f117b469cf61c597c1bae999e038a906ef62c88686c058bdb4dbbfdbf0000aa55 +11ms
  TuyAPI Parsed: +0ms
  TuyAPI { payload: 'json obj data unvalid',
  TuyAPI   leftover: false,
  TuyAPI   commandByte: 10,
  TuyAPI   sequenceN: 2 } +1ms
  TuyAPI Disconnect +0ms
json obj data unvalid
  TuyAPI Socket closed: 192.168.1.28 +2ms

I still can't control dps 2 (the second switch in the 2 gang switch) because tuya-cli thinks that it is a number rather than a bool.
tuya-cli is reporting dps 1 as a bool and dps 2 as a number (0) whereas the schema seems to be dps 1 bool (switch 1), dps 2 bool (switch 2), dps 9 number (countdown for switch 1) and dps 10 number (countdown for switch 2).

[owl770]

Just noticed that the device broadcasts its gwID via UDP as "0720009584f3eb84f920" and tuya-cli list-app reports the ID as "bf159f984c175cdccelh3p". Is it possible that this device wants the gwID and ID to be different when it is connected to?

[kueblc]

@owl770 it's very difficult to read your logs like this, please use triple backtick (```) to enclose a multiline block in the future.

Looks like this is related to #246.

Also looks like one of those devices where there are two MCUs, one for wifi (the gateway ie gwId) and one for the main function (subId or devId). I don't have access to a device like this so it's difficult to develop and test for.

[codetheweb]

It's fairly simple to set up Charles (as long as you're on iOS), here's their official tutorial on setting up SSL sniffing.

For the control issue, I added a feature recently that allows you to pass a raw value directly to the device without any additional parsing logic being performed on the value: #254.

I agree with @kueblc; but to test and see if specifying different a gwId and devId works you'll have to use TuyAPI directly (the CLI tool doesn't currently support it).

Do you happen to have a link to a page with more details about this device you bought?

[owl770]

@kueblc thanks for the tip on triple backticks - was wondering how to fix that.
@codetheweb I have just sent you an email that contains (I hope) a valid Charles session when communicating with the switch via the Smart Life app on my Samsung phone. Let me know if it is what you need or if you need anything else. Thanks all for your help.

[codetheweb]

Just took a quick look at the capture you sent me @owl770 and unfortunately I don't think there's much we can do. Running a text search for 0720009584f3eb84f920 yields no results in any of the packets; so the ID that's actually required to control the device is never sent and thus cannot be sniffed.

For posterity, this is the device that's exhibiting the weird behavior.

Let me know if you have any other ideas to fix this or other issues and I can reopen this; otherwise I'm closing it for now. Sorry we can't help more.

[owl770]

Thanks for looking at the capture @codetheweb. Do you think that it is controlling the switch using the ID of "bf159f984c175cdccelh3p" instead, as that is in there (and that is the ID as reported by the Smart Life app)?

[codetheweb]

My guess would be that the app tries to control it locally, but then fails-over to controlling them via the cloud API. (Although I can't say for sure without seeing a Wireshark capture of app activity.)

[owl770]

Hi @codetheweb. I have sent you a wireshark capture with the internet disconnected (local traffic only). The switches turn on and off OK (almost immediately the button is pressed in the app). Thanks again for looking at this.

[codetheweb]

Maybe I'm just not seeing it, but I only saw the broadcast packets from the device in that capture.

[owl770]

It seems that this may be a different WiFi module. Wireshark resolves the mac address with the prefix "Hangzhou". The switches I have that work OK are resolved as "Espressi".
Until something changes, I would suggest not buying switches with Hangzhou WiFi modules.