Tuya/Smart Lights: Things discovered, but state "Waiting for IP address"

Setup, Configuration and Use Installation
1

@J-N-K Let’s continue here

I see log messages like

2023-06-11 11:22:36.249 [DEBUG] [.internal.local.handlers.TuyaDecoder] - udpListener: Received MessageWrapper{commandType=UDP_NEW, content='DiscoveryMessage{ip='192.168.1.247', deviceId='xxx', active=2, ability=0, mode=0, encrypt=true, productKey='keyyuwcn59gwsrr8', version='3.3', token= true, wf_cfg=true}'}

2023-06-11 11:22:37.886 [DEBUG] [.internal.local.handlers.TuyaDecoder] - udpListener: Received MessageWrapper{commandType=UDP_NEW, content='DiscoveryMessage{ip='192.168.1.103', deviceId='xxx', active=2, ability=0, mode=0, encrypt=true, productKey='keyyuwcn59gwsrr8', version='3.3', token= true, wf_cfg=true}'}

2023-06-11 11:22:41.193 [DEBUG] [.internal.local.handlers.TuyaDecoder] - udpListener: Received MessageWrapper{commandType=UDP_NEW, content='DiscoveryMessage{ip='192.168.1.247', deviceId='xxx', active=2, ability=0, mode=0, encrypt=true, productKey='keyyuwcn59gwsrr8', version='3.3', token= true, wf_cfg=true}'}
2

device config looks like this:

Bildschirmfoto 2023-06-11 um 11.30.17
Bildschirmfoto 2023-06-11 um 11.30.171518×1194 85.3 KB

@hmerk any idea?

3

@J-N-K It seems that there is a mismatch in the discovered device ids

  • ids I see in the “udpListener: Received MessageWrapper” messages don’t show up in the jsondb
  • things shown in the " Added new thing ‘tuya:tuyaDevice:eb21d2990f6a8611a9a10i’ to inbox." don’t show up in udpListener messages
4

Not really, just noticed this for one of my devices too. It‘s a power extension with 4 sockets branded as „Dewenwill“
My other outdoor socket adapter came online straight away.

Edit: I need to check if it will be the same at my oh3 installation when disabling and reenabling the bridge.

5

@markus7017

The device(s) with the produktKey keyy... does not show up in the discovery inbox? This is interesting. Do you have other Tuya devices that are paired with another account?

Are the device that don’t show udpListener messages on the same network? It’s a known issue that this does not work well with different networks. In some cases adding the IP manually works.

@hmerk

Do you see the message from the udpListener for the new device? It could be that a new firmware has a new protocol version that is not yet supported.

6

I will check later on and compare between both devices/openHAB versions.

7
8

Something seems to be completely wrong there. The productKey from the message should be the same as the productId in the thing configuration, but they seem to be different, also sjaun9de is too short for a productId.

There is a org.smarthomej.binding.tuya.Schema.json in the openHAB database directory. Do you see sjaun9de or keyyuwcn59gwsrr8 there? If you delete the thing and re-add it, is the configuration exactly the same? Can you show the YAML representation?

9

I upgraded one light to the latest fw (4.9)

  • the virtual device id shown in the App and discovered intormation in the thing is the same
  • the device local key in the thing is empty

No, see attached json

YAML:

UID: tuya:tuyaDevice:eb460179e3407f723dtaqb
label: "Upper Bath: Bathtub Light Left (tuya: Upper Bathtub L)"
thingTypeUID: tuya:tuyaDevice
configuration:
  pollingInterval: 0
  productId: sjaun9de
  deviceId: eb460179e3407f723dtaqb
  localKey: ""
channels:
  - id: scene_data
    channelTypeUID: tuya:string
    label: scene_data
    description: null
    configuration:
      dp: 6
  - id: colour_data
    channelTypeUID: tuya:color
    label: colour_data
    description: null
    configuration:
      dp: 5
      dp2: 1
  - id: bright_value
    channelTypeUID: tuya:dimmer
    label: bright_value
    description: null
    configuration:
      min: 10
      dp: 3
      max: 1000
      dp2: 1
  - id: do_not_disturb
    channelTypeUID: tuya:switch
    label: do_not_disturb
    description: null
    configuration:
      dp: 34
  - id: temp_value
    channelTypeUID: tuya:dimmer
    label: temp_value
    description: null
    configuration:
      dp: 4
      max: 1000
      min: 0
  - id: work_mode
    channelTypeUID: tuya:string
    label: work_mode
    description: null
    configuration:
      dp: 2
      range: white,colour,scene,music
  - id: music_data
    channelTypeUID: tuya:string
    label: music_data
    description: null
    configuration:
      dp: 8
  - id: countdown_1
    channelTypeUID: tuya:number
    label: countdown_1
    description: null
    configuration:
      dp: 7
      max: 86400
      min: 0

schema.json (13.5 KB)

10

So there seems to be something wrong with discovery. Can you disable the cloud thing, delete all things, set org.smarthomej.binding.tuya to TRACE and send the responses of the requests to

/v1.0/users/token.uid/devices
/v1.0/iot-03/devices/factory-infos (one is sufficient)

by private mail or to github@klug.nrw?

11

I sent you a PM

12

@J-N-K Any progress here ?
My power strip still shos waiting for ip but is working very well with the openHAB 3 version of your binding.

13

I had this issue initially (with 4.0.2) but my OH server was on a different server so mDNS (I assume) wasn’t working. Added a couple of other devices after migrating to a local device and IP address is still not populated. All devices work, locally or when they are on different networks, after manually adding the IP address. Does seem to be just discovery that is an issue.

14

2023-10-16 19:01:55.880 [WARN ] [.internal.local.handlers.TuyaDecoder] - bfffb630943a69cd33h3k7/192.168.1.24:6668: Checksum failed for message: calculated E2AF4A6484963BE2570478B21BC8CBC95D66DEE467BF487FBE2DDD022D0C1C12, found 22861CE9FF8718AFFD8DA853E06F8BB5B6E154BE4B9BB5C8954533E992B830C8

2023-10-16 19:02:05.881 [WARN ] [.internal.local.handlers.TuyaDecoder] - bfffb630943a69cd33h3k7/192.168.1.24:6668: Checksum failed for message: calculated 1DB6D1F0A88E79037EDB224982F1CD35E36C76DC6CC298A1D881A2A97AD02858, found 22861CE9FF8718AFFD8DA853E06F8BB5B6E154BE4B9BB5C8954533E96B921747

2023-10-16 19:02:15.881 [WARN ] [.internal.local.handlers.TuyaDecoder] - bfffb630943a69cd33h3k7/192.168.1.24:6668: Checksum failed for message: calculated 109877C93CD0711281B3A0A19CE0E4F170051710589EB372014DEF2FEE94294C, found 22861CE9FF8718AFFD8DA853E06F8BB5B6E154BE4B9BB5C8954533E9C8043F0B

2023-10-16 19:02:25.882 [WARN ] [.internal.local.handlers.TuyaDecoder] - bfffb630943a69cd33h3k7/192.168.1.24:6668: Checksum failed for message: calculated D58283E9C4C7173E0D9165ED37797D4BCA4D931274D470495772FC928673E033, found 22861CE9FF8718AFFD8DA853E06F8BB5B6E154BE4B9BB5C8954533E9F7CF419E

2023-10-16 19:02:35.882 [WARN ] [.internal.local.handlers.TuyaDecoder] - bfffb630943a69cd33h3k7/192.168.1.24:6668: Checksum failed for message: calculated 3D055609326148A5C5545986AA1CECD0A56F1496CB0D02697C8C8E56F69B4A9C, found 22861CE9FF8718AFFD8DA853E06F8BB5B6E154BE4B9BB5C8954533E9545969D2

2023-10-16 19:02:45.883 [WARN ] [.internal.local.handlers.TuyaDecoder] - bfffb630943a69cd33h3k7/192.168.1.24:6668: Checksum failed for message: calculated E80183FF0374DF0FE5870C51D9242C0816A857D464199BC0B9E3DBF153ADF6EF, found 22861CE9FF8718AFFD8DA853E06F8BB5B6E154BE4B9BB5C8954533E98859BCB4

2023-10-16 19:02:55.883 [WARN ] [.internal.local.handlers.TuyaDecoder] - bfffb630943a69cd33h3k7/192.168.1.24:6668: Checksum failed for message: calculated C8A0041EFB9C5C9A3821101E21881B275FF9EF27092E271FD185C7FDF30EBDB9, found 22861CE9FF8718AFFD8DA853E06F8BB5B6E154BE4B9BB5C8954533E92BCF94F8

Same pb here:(

15

Wrong protocol? Can you show the discovery message for that device?

16

Has there been any progress on this? I have the same problem with a tuya smart plug.

17

No. Without information it‘s impossible to debug.

18

I will be happy to provide information if I can. But at the moment I cannot get an access token from the Tuya API Explorer. If you can tell me how to do that I will do my best to provide any information you ask for. To start with, I am running openHAB 4.1.2 on a Raspberry Pi4, installed by Openhabian.