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.