OSRAM LEDVANCE WIFI lamps lose connection after a while; reload fixes it

[neuronflow]

The problem

Environment

 {
  "home_assistant": {
    "installation_type": "Unsupported Third Party Container",
    "version": "2022.10.1",
    "dev": false,
    "hassio": false,
    "virtualenv": false,
    "python_version": "3.10.5",
    "docker": true,
    "arch": "armv7l",
    "timezone": "Europe/Berlin",
    "os_name": "Linux",
    "os_version": "5.10.103-v7l+",
    "run_as_root": false
  },
  "custom_components": {
    "hacs": {
      "version": "1.28.3",
      "requirements": [
        "aiogithubapi>=22.2.4"
      ]
    },
    "localtuya": {
      "version": "4.1.1",
      "requirements": []
    }
  },
  "integration_manifest": {
    "domain": "localtuya",
    "name": "LocalTuya integration",
    "version": "4.1.1",
    "documentation": "https://github.com/rospogrigio/localtuya/",
    "dependencies": [],
    "codeowners": [
      "@rospogrigio",
      "@postlund"
    ],
    "issue_tracker": "https://github.com/rospogrigio/localtuya/issues",
    "requirements": [],
    "config_flow": true,
    "iot_class": "local_push",
    "is_built_in": false
  },
  "data": {
......
    "devices": {
      "SECRET": {
        "friendly_name": "lr couch",
        "host": "192.168.178.22",
        "local_key": "SECRET",
        "protocol_version": "3.3",
        "entities": [
          {
            "friendly_name": "lr couch",
            "brightness": 22,
            "color_temp": 23,
            "brightness_lower": 10,
            "brightness_upper": 1000,
            "color_mode": 21,
            "color": 24,
            "color_temp_min_kelvin": 2700,
            "color_temp_max_kelvin": 6500,
            "color_temp_reverse": false,
            "scene": 25,
            "music_mode": false,
            "id": 20,
            "platform": "light"
          }
        ],
        "device_id": "SECRET",
        "dps_strings": [
          "20 (value: True)",
          "21 (value: white)",
          "22 (value: 1000)",
          "23 (value: 0)",
          "24 (value: 00d0003202c6)",
          "25 (value: 0328280000000000000001f4009f)",
          "26 (value: 0)",
          "101 (value: True)"
        ],
        "product_key": "SECRET"
      },

[cloudbr34k84]

Im having the same problem with my WiFi Online Control Monitor

[fldc]

This started happening too one of my bulbs a few home assistant updates ago, readding it seem to have fixed it for now.

[neuronflow]

issue persists :( do you require more information?

[jk7gr]

I am having the same issue as well

[rootd]

Same issue for me. Anyone has found a workaround?

[neuronflow]

is it possible to create an automation that reloads the plugin every n hours?

[rootd]

@neuronflow you might want to try switching the protocol version to 3.2. I just realized you used 3.3 like I did. I switched it to 3.2 just to see what happenes, and so far my Ledvance bulb is working great!

[neuronflow]

thanks, will try! Interestingly, for my devices just 3.1 and 3.3 are available? o_O

[rootd]

you need to update localtuya from your HACS tab. Protocol 3.2 was added in the newest version 5.0.0, see https://github.com/rospogrigio/localtuya/releases/tag/v5.0.0

[rootd]

btw others used a Ledvance LED with protocol 3.4: https://github.com/rospogrigio/localtuya/pull/1222#issuecomment-1375866798 3.4 didn't work for me, it depends on the model I guess

[rootd]

@neuronflow you might want to try switching the protocol version to 3.2. I just realized you used 3.3 like I did. I switched it to 3.2 just to see what happenes, and so far my Ledvance bulb is working great!

nevermind it still disconnects :(

[rootd]

So I checked with tinytuya. Its protocol 3.3. The bulb can still be used with tinytuya, even after it became unavailable in HASS.

I checked the logs, There's a permantent flood if the following messages while the bulb is working:

(MainThread) [custom_components.localtuya.pytuya] [bfb...rhz] Sending command 9 (device type: type_0a) (MainThread) [custom_components.localtuya.pytuya] [bfb...rhz] Sending payload: b'{"gwId":"bfb78a3161e332d6a4jrhz","devId":"bfb78a3161e332d6a4jrhz"}' (MainThread) [custom_components.localtuya.pytuya] [bfb...rhz] Command 9 waiting for sequence number -100 (MainThread) [custom_components.localtuya.pytuya] [bfb...rhz] Dispatching message CMD 9 TuyaMessage(seqno=0, cmd=9, retcode=0, payload=b'', crc=2958142211, crc_good=True) (MainThread) [custom_components.localtuya.pytuya] [bfb...rhz] Got heartbeat response (MainThread) [custom_components.localtuya.pytuya] [bfb...rhz] ACK received for command 9: ignoring it

And this is when the bulb becomes unavailable:

(MainThread) [custom_components.localtuya.pytuya] [bfb...rhz] Sending command 9 (device type: type_0a) (MainThread) [custom_components.localtuya.pytuya] [bfb...rhz] Sending payload: b'{"gwId":"bfb78a3161e332d6a4jrhz","devId":"bfb78a3161e332d6a4jrhz"}' (MainThread) [custom_components.localtuya.pytuya] [bfb...rhz] Command 9 waiting for sequence number -100 (MainThread) [custom_components.localtuya.pytuya] [bfb...rhz] Connection lost: [Errno 104] Connection reset by peer (MainThread) [custom_components.localtuya.pytuya] [bfb...rhz] Heartbeat failed due to timeout, disconnecting

tuyadebug output: INFO:localtuya:localtuya version 1.0.0 INFO:localtuya:Python 3.11.1 (main, Dec 7 2022, 00:00:00) [GCC 12.2.1 20221121 (Red Hat 12.2.1-4)] on linux INFO:localtuya:Using pytuya version '10.0.0' INFO:localtuya:Detecting list of available DPS of device bfb78a3161e332d6a4jrhz [192.168.178.41], protocol 3.3. DEBUG:localtuya.pytuya:[bfb...rhz] Sending command 10 (device type: type_0a) DEBUG:localtuya.pytuya:[bfb...rhz] Sending payload: b'{"gwId":"bfb78a3161e332d6a4jrhz","devId":"bfb78a3161e332d6a4jrhz","uid":"bfb78a3161e332d6a4jrhz","t":"1674180707"}' DEBUG:localtuya.pytuya:[bfb...rhz] Command 10 waiting for sequence number 1 DEBUG:localtuya.pytuya:[bfb...rhz] Dispatching message CMD 10 TuyaMessage(seqno=1, cmd=10, retcode=0, payload=b'Q0\x06B5\xfd<\xb5p\x84U/\x9d\xb7q\xe8\xe05=~\xea:\x0e\xe3\xe6\x8dH\x0e\xe4\x9eRv\x97\xb2\xadO4\x127\n\x04\x84\x0c\xcb\x93e\xfd\x15UL.\xf5\xe3~\xefw\x07\xd7=\xe6\xa5@\xe7M\x81\xc6\xc3-\xd0\xad\x07\xbd\xfb\x93\xa6\x17\xc6\x05\xbeB\xa1\xb6\x03T\x80\xa1L\xb02\xbe!8G#j\xda[\x9b\x95P\xdb\xa0\x1a\x07\xa9\x1c\xe3\xb5N\xf66\x13\x8f1!\x0f\xaf\x13\xffM!\xb5C\xda\x9e\x0c\xfa`', crc=4159497351, crc_good=True) DEBUG:localtuya.pytuya:[bfb...rhz] Deciphered data = '{"dps":{"20":true,"21":"white","22":1000,"23":165,"24":"003c035903e8","25":"000e0d0000000000000000c80000","26":0,"101":true}}' AVAILABLE DPS ARE [{'20': True, '21': 'white', '22': 1000, '23': 165, '24': '003c035903e8', '25': '000e0d0000000000000000c80000', '26': 0, '101': True}] INFO:localtuya:COMPLETE response from device bfb78a3161e332d6a4jrhz [192.168.178.41].

deviceInfo returned OK

TuyaDebug (Tuya DPs dump) [1.0.0]

Device bfb78a3161e332d6a4jrhz at 192.168.178.41 key XXXXXXXXXXX protocol 3.3 dev_type type_0a: DPS [20] VALUE [True] DPS [21] VALUE [white] DPS [22] VALUE [1000] DPS [23] VALUE [165] DPS [24] VALUE [003c035903e8] DPS [25] VALUE [000e0d0000000000000000c80000] DPS [26] VALUE [0] DPS [101] VALUE [True]

[SgtJalau]

I have the same issue with gosund smart plugs. One works, one loses connection after a few hours, then it stops working until I reload (by editing the device and just clicking okay twice).

EDIT: I got it fixed by downgrading. Check my solution out here: https://github.com/rospogrigio/localtuya/issues/1116#issuecomment-1427047385