Connection reset by peer: LSC WiFi Bulb, Hombli WiFi/BLE Gateway

MarkPaxton commented 6 months ago

Hello, I'm looking for a bit of help getting up and running with my local devices.

I am trying to connect and get status for the LSC Bulb device which has worked fine with the cloud integration / smart life app. I'm also trying to work out how to communicate with my Hombli radiator valves via the Bluetooth gateway.

Whatever I try, I just get 'connection reset by peer'. I did get the local keys via the wizard but otherwise I'm pretty stuck at the moment. Any help would be great!

This was my last attempt based on the earlier thread about the LCS bulbs.

d = tinytuya.BulbDevice(item['id'], item['ip'],  item['key'])
d.bulb_type = 'A'

 d = devices.get(id)
    d.set_version(3.3)
    d.set_socketPersistent(True)
    print(" > Send Request for Status < ")
    payload = d.generate_payload(tinytuya.DP_QUERY)
    d.send(payload)

    print(" > Begin Monitor Loop <")
    while(True):
        # See if any data is available
        data = d.receive()
        print('Received Payload: %r' % data)

        # Send keyalive heartbeat
        print(" > Send Heartbeat Ping < ")
        payload = d.generate_payload(tinytuya.HEART_BEAT)
        d.send(payload)


DEBUG:status() entry (dev_type is default)
DEBUG:final payload_dict for '03010850600194d4bd7e' ('v3.3'/'default'): {1: {'command': {'gwId': '', 'devId': '', 'uid': '', 't': ''}}, 7: {'command': {'devId': '', 'uid': '', 't': ''}}, 8: {'command': {'gwId': '', 'devId': ''}}, 9: {'command': {'gwId': '', 'devId': ''}}, 10: {'command': {'gwId': '', 'devId': '', 'uid': '', 't': ''}}, 13: {'command': {'devId': '', 'uid': '', 't': ''}}, 16: {'command': {'devId': '', 'uid': '', 't': ''}}, 18: {'command': {'dpId': [18, 19, 20]}}, 64: {'command': {'reqType': '', 'data': {}}}}
DEBUG:building command 10 payload=b'{"gwId":"03010850600194d4bd7e","devId":"03010850600194d4bd7e","uid":"03010850600194d4bd7e","t":"1702420607"}'
DEBUG:sending payload
DEBUG:payload encrypted=b'000055aa000000010000000a000000782bb4032dc138f0aa955f1f86afc1feb269b13a4d7913ba0f00c4abe15570175c5c27a1bb858c97af70bf23677e26f0fb0ed9ad59c29bb6f3fa648848e3eceffe046b437b2e8de34f59a7c4b5ceb81ab7f9cb12c56a5dbeeb66bea6285de662af4dfdac39b91faeb7f769d00531177f00dbf5a4990000aa55'
DEBUG:Network connection error in _send_receive() - retry 1/5
Traceback (most recent call last):
  File "/home/mark/.local/lib/python3.10/site-packages/tinytuya/core.py", line 1193, in _send_receive
    rmsg = self._receive()
  File "/home/mark/.local/lib/python3.10/site-packages/tinytuya/core.py", line 1081, in _receive
    data = self._recv_all( min_len )
  File "/home/mark/.local/lib/python3.10/site-packages/tinytuya/core.py", line 1055, in _recv_all
    newdata = self.socket.recv(length)
ConnectionResetError: [Errno 104] Connection reset by peer
DEBUG:sending payload
DEBUG:payload encrypted=b'000055aa000000020000000a000000782bb4032dc138f0aa955f1f86afc1feb269b13a4d7913ba0f00c4abe15570175c5c27a1bb858c97af70bf23677e26f0fb0ed9ad59c29bb6f3fa648848e3eceffe046b437b2e8de34f59a7c4b5ceb81ab7f9cb12c56a5dbeeb66bea6285de662af4dfdac39b91faeb7f769d00531177f003593a7800000aa55'
DEBUG:Network connection error in _send_receive() - retry 2/5
Traceback (most recent call last):
  File "/home/mark/.local/lib/python3.10/site-packages/tinytuya/core.py", line 1193, in _send_receive
    rmsg = self._receive()
  File "/home/mark/.local/lib/python3.10/site-packages/tinytuya/core.py", line 1081, in _receive
    data = self._recv_all( min_len )
  File "/home/mark/.local/lib/python3.10/site-packages/tinytuya/core.py", line 1055, in _recv_all
    newdata = self.socket.recv(length)
ConnectionResetError: [Errno 104] Connection reset by peer
DEBUG:sending payload
DEBUG:payload encrypted=b'000055aa000000030000000a000000782

uzlonewolf commented 6 months ago

It sounds like the version is wrong. What does tinytuya scan report it as?

MarkPaxton commented 6 months ago

Scan fails to detect anything :( I also tried 3.0 up to 3.5 though not all the combinations of different commands (set twice, dp 1 on etc) with all versions.

uzlonewolf commented 6 months ago

Hmm, that's odd. It's sounding like a network issue. Is there a firewall between your computer and the device? Are they on the same WiFi network?

MarkPaxton commented 6 months ago

Thanks for getting back to me, it's a fairly clean install of mint linux, I've been running Home Assistant in a docker container on the same machine with 'host' networking option, that has no problems finding (non-tuya) devices on the network other than and local tuya stuff.

I also tried on my macbook, which also did not work :(

Smart life on my phone can discover/control the light and BLE gateway fine and I can trigger changes via the Tuya developer portal as well, so I know it's online, and getting updates that way. I've I've got 2 IP/BLE gateways and 1 bulb, none of them can be discovered :(

I also tried the BLE direct integration in Home Assistan, that basically crashed my machine. It also seemed like it could have been the same disconnect issues but more badly managed. Fixing that is later on the roadmap!

uzlonewolf commented 6 months ago

The fact that none of the 3 devices work makes me think it is a networking issue. Can you ping their IP addresses? Is HA shut down? (HA has been known to steal the socket needed for scanning, and a lot of devices only support 1 local connection at a time.)

MarkPaxton commented 6 months ago

I disabled the tuya integrations on HA and killed smartlife on my phone just to make sure, but I can shut down the HA container completely and see what happens later. I'd already assumed the stack on the devices doesn't implement ping responses!

MarkPaxton commented 6 months ago

I tried with my HA instance shut down, but that made no difference.

I also tried with versions 3.0 up to 3.5 and got a different error message for 3.4 and 3.5:

DEBUG:status() entry (dev_type is default)
DEBUG:final payload_dict for '03010850600194d4bd7e' ('v3.5'/'default'): {1: {'command': {'gwId': '', 'devId': '', 'uid': '', 't': ''}}, 7: {'command': {'protocol': 5, 't': 'int', 'data': {}}, 'command_override': 13}, 8: {'command': {'gwId': '', 'devId': ''}}, 9: {'command': {'gwId': '', 'devId': ''}}, 10: {'command': {}, 'command_override': 16}, 13: {'command': {'protocol': 5, 't': 'int', 'data': {}}}, 16: {'command': {}}, 18: {'command': {'dpId': [18, 19, 20]}}, 64: {'command': {'reqType': '', 'data': {}}}}
DEBUG:building command 10 payload=b'{}'
DEBUG:sending payload quick
DEBUG:final payload: b'0123456789abcdef'
DEBUG:payload encrypted=b'00006699000000000001000000030000002c3031323334353637383961622df3d86e47d70d6c3925e0e7f081b093a85a5a5f73612ebde44f5d57c104d0c700009966'
DEBUG:received null payload (None), fetch new one - 1 retries remaining
DEBUG:received null payload (None) but out of recv retries, giving up
DEBUG:session key negotiation failed on step 1
DEBUG:ERROR Check device key or version - 914 - payload: null
DEBUG:status() received data={'Error': 'Check device key or version', 'Err': '914', 'Payload': None}
DEBUG:bulb type set to B
 > Send Request for Status < 
DEBUG:building command 10 payload=b'{}'
DEBUG:sending payload quick
DEBUG:final payload: b'0123456789abcdef'
DEBUG:payload encrypted=b'00006699000000000002000000030000002c3031323334353637383961622df3d86e47d70d6c3925e0e7f081b093f88faf4f3ea373ee9d31f54bcc96b94b00009966'
DEBUG:received null payload (None), fetch new one - 1 retries remaining
DEBUG:received null payload (None) but out of recv retries, giving up
DEBUG:session key negotiation failed on step 1
DEBUG:ERROR Check device key or version - 914 - payload: null

Any thoughts? I could also ping the device with no problems.

uzlonewolf commented 6 months ago

It still feels network-related to me. I'd shut down HA completely, make sure the SmartLife app is closed, reboot the device(s), and run python -m tinytuya scan as soon as they boot.

I attempted to pick up one of these bulbs off ebay so I could have a look myself. Shipping from Netherlands to the U.S. was advertised as $7.50, but we'll see if it actually ships as I don't believe it can be that cheap.

jasonacox commented 6 months ago

@MarkPaxton Do you have any other Tuya devices on your network? If not, it may be worth getting a basic low-cost Tuya smart plug just to help troubleshoot the basic connectivity. In my experience, gateways are more challenging and if you have other networking issues going on it may be hard to find.

MarkPaxton commented 6 months ago

Yeah, I have an LSC bulb I’m trying to crack first.

MarkPaxton commented 6 months ago

The log print was actually from the bulb.

jasonacox commented 6 months ago

I know @uzlonewolf asked, but you should get a ping response from these devices (I have over 30 Tuya devices and they all ping). If ICMP packets are not getting to these devices, you may have network issues that will need to be addressed first. Make sure they are all on the same network with the computer you are using to control them.

It would also be good to see if you get a response using:

python -m tinytuya scan
# or
python -m tinytuya scan -f

(where -f uses a Jedi force push to get access to the devices) ✋ 😂

MarkPaxton commented 6 months ago

I was able to get a ping from it, I’ll try force powers tomorrow… the only thing I didn’t do was a power cycle after shutting down HA and killing smart life.

MarkPaxton commented 6 months ago

Ok I had a free moment to try force scan…

Scanning... / (Devs:3)                              Bluetooth Bridge 1   Product ID = ?  [Force-Scanned]:
    Address = 192.168.2.193   Device ID = bf94bb0153aa35eed0pzsf (len:22)  Local Key = *******  Version = 3.4  Type = default, MAC = fc:67:1f:6d:5b:11
    Status: {'38': 'on'}
Scanning... - (Devs:3)                              Scanning... \ (Devs:2)                              Bluetooth Bridge 2   Product ID = ?  [Force-Scanned]:
    Address = 192.168.2.202   Device ID = bf61a75057cec67600h73n (len:22)  Local Key = *******  Version = 3.4  Type = default, MAC = fc:67:1f:6d:43:3c
    Status: {'38': 'on'}
Scanning... | (Devs:2)                              Scan completed in 40.3226 seconds                 
Unknown v3.3 Device   Product ID = ?  [Failed to Force-Scan, FORCED STOP]:
    Address = 192.168.2.173   Device ID =  (len:0)  Local Key =   Version = 3.3  Type = default, MAC = 

Scan Complete!  Found 3 devices.
Broadcasted: 0
Force-Scanned: 3  - Matched GWID: 0 Matched Key: 2 Unmatched: 1
Versions: 3.3: 1, 3.4: 2
Unknown Devices: 1

MarkPaxton commented 6 months ago

Ok so strangely I've found another Tuya device on my network "TY_WR" which I have no idea about... after I entered the correct IP address for the bulb, I was able to get a full status report :)

  Starting Scan for network 192.168.2.0/24
Bluetooth Bridge 1   Product ID = ?  [Force-Scanned]:
    Address = 192.168.2.193   Device ID = bf94bb0153aa35eed0pzsf (len:22)  Local Key = ****  Version = 3.4  Type = default, MAC = fc:67:1f:6d:5b:11
    Status: {'38': 'on'}
Bluetooth Bridge 2   Product ID = ?  [Force-Scanned]:
    Address = 192.168.2.202   Device ID = bf61a75057cec67600h73n (len:22)  Local Key = ****  Version = 3.4  Type = default, MAC = fc:67:1f:6d:43:3c
    Status: {'38': 'on'}
Bedroom light   Product ID = ?  [Force-Scanned]:
    Address = 192.168.2.189   Device ID = 03010850600194d4bd7e (len:20)  Local Key = ****  Version = 3.3  Type = default, MAC = 60:01:94:d4:bd:7e
    Status: {'1': False, '2': 255, '3': 255, '101': True}
Scan completed in 38.6663 seconds
Unknown v3.3 Device   Product ID = ?  [Failed to Force-Scan, FORCED STOP]:
    Address = 192.168.2.173   Device ID =  (len:0)  Local Key =   Version = 3.3  Type = default, MAC =

I'm wondering if the normal scan got confused as I was running some docker containers to the machine sits on 4 subnets. But either way, we have progress :)

MarkPaxton commented 6 months ago

Great news also, I was also able to get the status from the TRV by setting the parent correctly :) I don't know what magic the force push uses, but seems it has brought them to life!

trv = Contrib.ThermostatDevice('bffa0dijvjaqqmqx', cid='de0e48ad74667c93', parent=gw1)
trv.set_version(3.4)
print(trv.status())

{'dps': {'8': True, '10': True, '27': 0, '40': False, '101': True, '102': 245, '103': 240, '105': 0, '106': False, '108': True, '130': True}, 'cid': 'de0e48ad74667c93', 'device': ThermostatDevice( 'bffa0dijvjaqqmqx', address=None, local_key='', dev_type='default', connection_timeout=5, version=3.4, persist=True, cid='de0e48ad74667c93', parent='bf94bb0153aa35eed0pzsf', children={} ), 'changed': ['temp_correction', 'upper_temp', 'raw_upper_temp', 'cooling_setpoint_c', 'weather_forcast'], 'changed_sensors': []}

MarkPaxton commented 6 months ago

Thanks everyone for the kind help!

jasonacox commented 6 months ago

Thanks, @MarkPaxton - Great job on get it to work. I'm glad it work! Now we know... Use the Force! 😁

MarkPaxton commented 6 months ago

The other thing was that the gateway only supports maybe 3 concurrent connections, so it’s pretty unreliable when there’s several units on it. I switched persist=False so that the connections aren’t held open to mitigate the issue a bit.

uzlonewolf commented 6 months ago

Why do you need that many connections? You only need 1 connection to the gateway no matter how many BT sub-devices are attached.

MarkPaxton commented 6 months ago

It's the way that tuya-local seems to work at the moment: https://github.com/make-all/tuya-local/discussions/522#discussioncomment-6514357

As a quick hack I used configured the devices to poll only mode, to see if dropping the connection each time works better: https://github.com/make-all/tuya-local/blob/50d053386e2041b357d2d97a2f70b5b320f3d419/custom_components/tuya_local/device.py#L244

I haven't had time to dig into the code, but there must be a simple way to reuse a persistent connection of a parent device over the sub-devices, or at least get/reuse an existing connection...

njoye commented 6 months ago

@uzlonewolf @jasonacox I'm in a similar spot as @MarkPaxton was and am the author of https://github.com/PlusPlus-ua/ha_tuya_ble/issues/87 - trying to either get the direct BLE connection working or (even better) being able to control my devices with TinyTuya first. I'm stuck at pretty much the same place as Mark was where I can ping my gateway, I can also find it through python3 -m tinytuya scan (also with a force scan), getting this result

(base) ➜  ble python3 -m tinytuya scan       

TinyTuya (Tuya device scanner) [1.13.1]

[Loaded devices.json - 1 devices]

Scanning on UDP ports 6666 and 6667 and 7000 for devices for 18 seconds...

ZX-5012   Product ID = key7mn9kc48xep73  [Valid Broadcast]:
    Address = 192.168.178.81   Device ID = bfb728ad4c03b7259dbyto (len:22)  Local Key = ******  Version = 3.4  Type = default, MAC = 
    Polling 192.168.178.81 Failed: No response

However, when I try retrieving the status like this

tinytuya.set_debug(True)
gateway = tinytuya.Device(gateway_config['dev_id'], gateway_config['ip'], gateway_config['key'], )
gateway.set_version(3.4)
gateway.status()

I'm getting the same error

DEBUG:Timeout in _send_receive() - retry 5 / 5
DEBUG:sending payload quick
DEBUG:final payload: b'0123456789abcdef'
DEBUG:payload encrypted=b'000055aa0000001300000003000000444b3a4171d273236c4386d35e9a20fe1ba448b54f65efa9f98bd23cb6ecf2d0b4c51164e169d9db42f0d8d87a0a10862d4d2eaf42210e0dd478db2a3153ac91a10000aa55'
DEBUG:received data=b'000055aa0000c955000000040000006800000000786aba6dd20ffcd9f30a68f5016235cdd4310ab7b18cf63caddae8f6a8fe917c71d28c9a6180536c915a9c86a3e7d89ca448b54f65efa9f98bd23cb6ecf2d0b4107e99cb85dcd445aca20492c2e154c70200ec930d9bfac0f3afd49492c51d5e0000aa55'
DEBUG:decrypting=b'xj\xbam\xd2\x0f\xfc\xd9\xf3\nh\xf5\x01b5\xcd\xd41\n\xb7\xb1\x8c\xf6<\xad\xda\xe8\xf6\xa8\xfe\x91|q\xd2\x8c\x9aa\x80Sl\x91Z\x9c\x86\xa3\xe7\xd8\x9c\xa4H\xb5Oe\xef\xa9\xf9\x8b\xd2<\xb6\xec\xf2\xd0\xb4'
DEBUG:decrypted session key negotiation step 2 payload=b'230d7aad4828e049\xe8#\xb3\xc9O\xe0N\x1a*\xd1o\x94\x1d&\x1e\xc5 \xa9|s\x93\xa8\x1d\x10\xbab\xf7\x17\xdf\xb6\nh'
DEBUG:payload type = <class 'bytes'> len = 48
DEBUG:session local nonce: b'0123456789abcdef' remote nonce: b'230d7aad4828e049'
DEBUG:sending payload quick
DEBUG:final payload: b'\x89\xc3E\x0b\xef\xe2\xc4\xa5\xe7\xeb\xc4P.\x0c\x0e\x83m%0n\x1b\xfd\x87\xcfdk\x99\xbe\xe1V\xd3\xc8'
DEBUG:payload encrypted=b'000055aa0000001400000005000000540664534be1a6c61fd47d3a042c2ca237c78fd1870231539e5235ecb9bcfae017a448b54f65efa9f98bd23cb6ecf2d0b4a334a3b1dc4e99e695069e70091cafda30375b9ff1f5d465b692b5a68b8b20ee0000aa55'
DEBUG:Session nonce XOR'd: b'\x02\x02\x02W\x03TWS\x0c\x01SZ\x06TQ_'
DEBUG:Session key negotiate success! session key: b'\xb0O\xa5I\xb6\xcf\xc8\xa6\xa5\x8d\xa3\x1b\xef\xa9\xe4\x07'
DEBUG:sending payload
DEBUG:final payload: b'3.4\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00{"devId":"bfb728ad4c03b7259dbyto","uid":"bfb728ad4c03b7259dbyto","t":"1703353156","dps":{"1":null}}'
DEBUG:payload encrypted=b'000055aa000000150000000d000000a4a20cbb6569387ddf553843dd17c67cf8afd9932bded01de560f33abc7da631097ce2014e2113687690d88460499d76081b1db0fa8a2fa3213056c44b2d47d6d1b69bd3af851608c9443e86ed26d306f7ca27c5f14fb1294a2d2313539daceec583d42d6ecb8081aad2ff5ba069f9312638286c93d8c87c03a80d9e5210350008b595a0a9799cabe7d9e0a6e36f2be207f17c77a99a211274adf7a4038a4c3cb70000aa55'
DEBUG:Timeout in _send_receive() - retry 6 / 5
DEBUG:Exceeded tinytuya retry limit (5)
DEBUG:ERROR Check device key or version - 914 - payload: null

Pinging the device works just fine - the force scan unfortunately didn't help in my case. Any ideas as to where the issue could be would be greatly appreciated! Thanks already.

uzlonewolf commented 6 months ago

@njoye Gateways do not always respond to .status() requests as most do not have any DPs themselves. If you have a BLE device attached to the gateway you should attach it as a child and call .status() on that instead.

As for direct BLE communications, I looked into it a while ago and it was a completely different protocol. Since it couldn't reuse any tinytuya code I didn't proceed further with it.

uzlonewolf commented 6 months ago

Also, a list of online sub-devices can be queried with print( gateway.subdev_query() )

njoye commented 6 months ago

@uzlonewolf That appears to have done the trick - a thousand thanks! The querying worked and I used the id's that I got back as CIDs for creating a ThermostatDevice - however it appears that I'm getting a TypeError when trying to get the status from the device - am I doing something wrong here ?

gateway = tinytuya.Device(gateway_config['dev_id'], gateway_config['ip'], gateway_config['key'], )
gateway.set_version(3.4)
print(gateway.subdev_query())
thermostat = Contrib.ThermostatDevice(thermostat_config['dev_id'], parent=gateway, cid=thermostat_config['cid'])
thermostat.set_version(3.4)
print(thermostat.status())

{'reqType': 'subdev_online_stat_report', 'data': {'online': ['ea7e6e218ebb99b2', '08a84373e51449fc', 'ae861be0ea14e481'], 'offline': ['56f203f3d2a3d24f'], 'nearby': ['ea7e6e218ebb99b2', '08a84373e51449fc', 'ae861be0ea14e481']}}
Traceback (most recent call last):
  File "/Users/timomueller/ble/tt.py", line 22, in <module>
    print(thermostat.status())
  File "/Users/timomueller/miniforge3/envs/ros_env/lib/python3.9/site-packages/tinytuya/Contrib/ThermostatDevice.py", line 434, in status
    return super(ThermostatDevice, self).status()
  File "/Users/timomueller/miniforge3/envs/ros_env/lib/python3.9/site-packages/tinytuya/core.py", line 1598, in status
    data = self._send_receive(payload, 0, getresponse=(not nowait))
  File "/Users/timomueller/miniforge3/envs/ros_env/lib/python3.9/site-packages/tinytuya/core.py", line 1151, in _send_receive
    return self.parent._send_receive(payload, minresponse, getresponse, decode_response, from_child=self)
  File "/Users/timomueller/miniforge3/envs/ros_env/lib/python3.9/site-packages/tinytuya/core.py", line 1280, in _send_receive
    return self._process_message( msg, dev_type, from_child, minresponse, decode_response )
  File "/Users/timomueller/miniforge3/envs/ros_env/lib/python3.9/site-packages/tinytuya/core.py", line 1347, in _process_message
    return found_child._process_response(result)
  File "/Users/timomueller/miniforge3/envs/ros_env/lib/python3.9/site-packages/tinytuya/Contrib/ThermostatDevice.py", line 452, in _process_response
    data['changed_sensors'] += self.sensorlists[i].update( data['dps'][k] )
  File "/Users/timomueller/miniforge3/envs/ros_env/lib/python3.9/site-packages/tinytuya/Contrib/ThermostatDevice.py", line 928, in update
    raise TypeError( 'Unhandled Thermostat Sensor List data type' )
TypeError: Unhandled Thermostat Sensor List data type

uzlonewolf commented 6 months ago

Contrib.ThermostatDevice was written for a specific model of WiFi thermostat. One of the DPs packs a number of sensors into a single packet that the ThermostatDevice tries to decode, and if the unpacking fails then it throws the above error. I'd just stick with tinytuya.Device() unless you need the additional processing Contrib.ThermostatDevice does.

What does the DP map look like for the thermostat you're trying to connect to? It should be in devices.json if you answered "y" when the wizard asked to download it.

njoye commented 6 months ago

With the tinytuya.Device() I was able to retrieve the status.

{'dps': {'2': 44, '3': 204, '4': 'auto', '7': False, '21': 124, '101': 42, '102': 34, '105': 0, '107': 42, '108': False, '110': False, '121': 30, '122': 0, '124': False}, 'cid': 'ea7e6e218ebb99b2', 'device': Device( 'bf7e82j2h0zdmi8h', address=None, local_key='', dev_type='default', connection_timeout=5, version=3.4, persist=False, cid='ea7e6e218ebb99b2', parent='bfb728ad4c03b7259dbyto', children={} )}

This is the DP mapping of my device

"mapping": {
                "2": {
                    "code": "temp_set",
                    "type": "Integer",
                    "values": {
                        "unit": "\u00b0C",
                        "min": 1,
                        "max": 59,
                        "scale": 1,
                        "step": 5
                    }
                },
                "3": {
                    "code": "temp_current",
                    "type": "Integer",
                    "values": {
                        "unit": "\u00b0C",
                        "min": -50,
                        "max": 350,
                        "scale": 1,
                        "step": 5
                    }
                },
                "4": {
                    "code": "mode",
                    "type": "Enum",
                    "values": {
                        "range": [
                            "auto",
                            "manual",
                            "holiday"
                        ]
                    }
                },
                "7": {
                    "code": "child_lock",
                    "type": "Boolean",
                    "values": {}
                },
                "13": {
                    "code": "fault",
                    "type": "Bitmap",
                    "values": {
                        "label": [
                            "fault1",
                            "fault2",
                            "fault3"
                        ]
                    }
                },
                "21": {
                    "code": "battery_percentage",
                    "type": "Integer",
                    "values": {
                        "unit": "V",
                        "min": 0,
                        "max": 1000,
                        "scale": 2,
                        "step": 1
                    }
                },
                "103": {
                    "code": "holiday_set",
                    "type": "String",
                    "values": "{\"maxlen\": 255}"
                }
            }

Interestingly, almost all of them report the temp_set value as 44, even if I have vastly different target temperatures set for them (25 degrees and 20 degrees for example).

{'dps': {'2': 44, '3': 213, '4': 'auto', '7': False, '21': 123, '101': 42, '102': 34, '105': 0, '107': 51, '108': False, '110': False, '121': 30, '122': 0, '124': False}, 'cid': 'ea7e6e218ebb99b2', 'device': Device( 'bf7e82j2h0zdmi8h', address=None, local_key='', dev_type='default', connection_timeout=5, version=3.4, persist=False, cid='ea7e6e218ebb99b2', parent='bfb728ad4c03b7259dbyto', children={} )}

I know that this isn't the scope of this issue anymore and just wanted to ask if you had experience with how that mapping works or how I could get the factors that are used in the calculation - they don't seem to make a whole lot of sense right now. Other than that - thank you for your help! Seems like I am able to communicate with the devices now.

njoye commented 6 months ago

I will have to test with a check if the device is online. I believe some of the ones I tested weren't connected to the gateway and the gateway might buffer the last value it received. I'll have to debug this a little further. The factor should be 0.5 for the target temperature.

njoye commented 6 months ago

Okay, so something isn't right. I'm able to connect so that is good. But the data I'm getting from the .status() call on my thermostat is not up-to-date. Is there any way to force a refresh of that data?

MarkPaxton commented 6 months ago

You can change the mode on the gateway to disable the memory function. I tried it on mine via the Tuya developer portal but not sure it seemed much different to be honest.

On Mon, 25 Dec 2023 at 09:33, Timo Mueller @.***> wrote:

Okay, so something isn't right. I'm able to connect so that is good. But the data I'm getting from the .status() call on my thermostat is not up-to-date. Is there any way to force a refresh of that data?

— Reply to this email directly, view it on GitHub https://github.com/jasonacox/tinytuya/issues/435#issuecomment-1868855216, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACDG47AFN2GGNNOI3LSBTLYLE26HAVCNFSM6AAAAABASGXU4CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRYHA2TKMRRGY . You are receiving this because you were mentioned.Message ID: @.***>

njoye commented 6 months ago

@MarkPaxton How did you change the mode? My gateway doesn't have any DPs and I can't set anything in the settings in the app it seems. Also, the values in the app (when I open it) are changed - so I don't know exactly what's going on there because I would have assumed that if the data in the Tuya App changes, then the data from the gateway should also change?

njoye commented 6 months ago

After plugging the gateway out- and in again, and placing it closer to my thermostat (really close) it seems to update the values a lot better. Might have to get two more gateways. However, temp_set still shows a value of 44 (22 degrees) even though the actual temperature is set to 18 degrees (would expect a value of 36).

njoye commented 6 months ago

After digging into the datapoints a little more I figured out that the mapping provided by TinyTuya and the given datapoints doesn't seem correct. DP ID 7 is the currently set temperature, not DP 2.

uzlonewolf commented 6 months ago

You might want to check https://github.com/jasonacox/tinytuya/blob/master/DP_Mapping.md for both the hub and the device to see if you can convince it to give you more/better DP data.

sjpbailey commented 6 months ago

Merry Christmas Jason and Tintuya!On Dec 25, 2023, at 11:10 AM, uzlonewolf @.***> wrote: You might want to check https://github.com/jasonacox/tinytuya/blob/master/DP_Mapping.md for both the hub and the device to see if you can convince it to give you more/better DP data.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

sjpbailey commented 6 months ago

Merry Christmas Jason and Tintuya!On Dec 25, 2023, at 11:10 AM, uzlonewolf @.***> wrote: You might want to check https://github.com/jasonacox/tinytuya/blob/master/DP_Mapping.md for both the hub and the device to see if you can convince it to give you more/better DP data.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

njoye commented 6 months ago

@uzlonewolf That was a good idea, after changing the mode I get these values for the hub

        "mapping": {
            "1": {
                "code": "up_channel",
                "type": "Raw",
                "values": {}
            },
            "2": {
                "code": "down_channel",
                "type": "Raw",
                "values": {}
            }
        },
        "parent": ""
    }

and these for the thermostat

        "mapping": {
            "2": {
                "code": "temp_set",
                "type": "Integer",
                "values": {
                    "unit": "\u00b0C",
                    "min": 1,
                    "max": 59,
                    "scale": 1,
                    "step": 5
                }
            },
            "3": {
                "code": "temp_current",
                "type": "Integer",
                "values": {
                    "unit": "\u00b0C",
                    "min": -50,
                    "max": 350,
                    "scale": 1,
                    "step": 5
                }
            },
            "4": {
                "code": "mode",
                "type": "Enum",
                "values": {
                    "range": [
                        "auto",
                        "manual",
                        "holiday"
                    ]
                }
            },
            "7": {
                "code": "child_lock",
                "type": "Boolean",
                "values": {}
            },
            "13": {
                "code": "fault",
                "type": "Bitmap",
                "values": {
                    "label": [
                        "fault1",
                        "fault2",
                        "fault3"
                    ],
                    "maxlen": 3
                }
            },
            "21": {
                "code": "battery_percentage",
                "type": "Integer",
                "values": {
                    "unit": "V",
                    "min": 0,
                    "max": 1000,
                    "scale": 2,
                    "step": 1
                }
            },
            "101": {
                "code": "comfort_temp",
                "type": "Integer",
                "values": {
                    "unit": "\u00b0C",
                    "min": 1,
                    "max": 59,
                    "scale": 1,
                    "step": 5
                }
            },
            "102": {
                "code": "eco_temp",
                "type": "Integer",
                "values": {
                    "unit": "\u00b0C",
                    "min": 1,
                    "max": 59,
                    "scale": 1,
                    "step": 5
                }
            },
            "103": {
                "code": "holiday_set",
                "type": "Raw",
                "values": {}
            },
            "105": {
                "code": "temp_drift",
                "type": "Integer",
                "values": {
                    "unit": "\u00b0C",
                    "min": -55,
                    "max": 55,
                    "scale": 1,
                    "step": 1
                }
            },
            "107": {
                "code": "auto_temp",
                "type": "Integer",
                "values": {
                    "unit": "",
                    "min": 0,
                    "max": 59,
                    "scale": 1,
                    "step": 5
                }
            },
            "108": {
                "code": "rapid",
                "type": "Boolean",
                "values": {}
            },
            "110": {
                "code": "window",
                "type": "Boolean",
                "values": {}
            },
            "113": {
                "code": "dormancy",
                "type": "Boolean",
                "values": {}
            },
            "114": {
                "code": "monday",
                "type": "Raw",
                "values": {}
            },
            "115": {
                "code": "thursday",
                "type": "Raw",
                "values": {}
            },
            "116": {
                "code": "wednesday",
                "type": "Raw",
                "values": {}
            },
            "117": {
                "code": "tuesday",
                "type": "Raw",
                "values": {}
            },
            "118": {
                "code": "friday",
                "type": "Raw",
                "values": {}
            },
            "119": {
                "code": "saturday",
                "type": "Raw",
                "values": {}
            },
            "120": {
                "code": "sunday",
                "type": "Raw",
                "values": {}
            },
            "121": {
                "code": "window_temp",
                "type": "Integer",
                "values": {
                    "unit": "\u00b0C",
                    "min": 1,
                    "max": 59,
                    "scale": 1,
                    "step": 5
                }
            },
            "122": {
                "code": "windows_time",
                "type": "Integer",
                "values": {
                    "unit": "min",
                    "min": 0,
                    "max": 60,
                    "scale": 0,
                    "step": 1
                }
            },
            "123": {
                "code": "rapid_time",
                "type": "Integer",
                "values": {
                    "unit": "S",
                    "min": 0,
                    "max": 900,
                    "scale": 0,
                    "step": 1
                }
            },
            "124": {
                "code": "state",
                "type": "Boolean",
                "values": {}
            }
        },
        "parent": ""
    }

This morning the DP values were not current anymore. I figured out that calling updatedps seems to update the values in this case and apparently fixes the issue.

njoye commented 6 months ago

@MarkPaxton Did your changes to LocalTuya "fix" the problem with the connection limit ?

MarkPaxton commented 6 months ago

Not that I can tell, connections to the gateway with >3 subdevices are still unreliable, but maybe a little less. You can try the 'poll device' option when you configure the devices as it does the same thing to not keep the socket open. See if there's a change in behaviour.

njoye commented 6 months ago

@MarkPaxton Thanks for the hint. I am currently working with only one thermostat (in poll-only mode) to fix any issues that might occur. Right now, the biggest one I'm seeing is that the current temperature is only updating when I change the target temperature through HA (which wasn't working from my phone yesterday night, but that's a different issue). When I open the Tuya app, the values in HA are also updated. Do you know of any way to have TuyaLocal trigger this update or should I just run a script that regularly calls updatedps() on my thermostats?

njoye commented 6 months ago

Okay, I will open a new issue in TuyaLocal to address the issues I'm having with my devices since it worked perfectly through TinyTuya when I called updatedps() on my thermostat regularly.

jasonacox / tinytuya

Connection reset by peer: LSC WiFi Bulb, Hombli WiFi/BLE Gateway #435