search

smarthomej / addons

SmartHome/J addons for openHAB
Eclipse Public License 2.0
59 stars 23 forks source link

[tuya] API readings are OK but direct connection to thermostats fails with connection refused message #560

Closed theater closed 3 months ago

theater commented 5 months ago

Hi, thanks a lot for the binding. I have issue that it seems that the metadata is read correctly via the API (without the local IP addresses which I had to configure manually) but the connection attempts result in "connection refused" on port 6888. Tried to switch the different protocol versions but the result is the same.

Attached are the logs in TRACE level and the thing configuration from the discovery as requested for support.

Thanks in advance for any suggestions, K. tuya.log tuya_thermostat.conf.log

J-N-K commented 5 months ago

Is the device on the same subnet? Some devices refuse connections from other subnets.

theater commented 5 months ago

Hi, yes.

I'm hosting openhab on a NUC device with Ubuntu OS with a docker container. The outbound address is 192.168.254.45 in the same subnet. Do you think the docker configuration may somehow mess up the communication? I can try to do some tcpdump on the outbound connection from the Ubuntu...

Cheers, K.

theater commented 5 months ago

I noticed one more thing... I have to start the smart home app in order the device to become online, otherwise it returns connection timeout. Also I have to keep a command prompt with constant pinging in order the device not to come back to sleep. The binding seem to not wake it up.

theater commented 5 months ago

Here an example tcpdump. Hope it helps in a way... root@nuc:~# tcpdump -av | grep 192.168.254.172 tcpdump: listening on eno1, link-type EN10MB (Ethernet), snapshot length 262144 bytes 18:03:39.232990 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.254.172 tell nuc, length 28 18:03:39.430795 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.254.172 is-at c4:82:e1:c8:8c:46 (oui Unknown), length 46 nuc.39180 > 192.168.254.172.6668: Flags [S], cksum 0x7e4b (incorrect -> 0xd48d), seq 3787640500, win 64240, options [mss 1460,sackOK,TS val 2060852222 ecr 0,nop,wscale 7], length 0 nuc.39180 > 192.168.254.172.6668: Flags [S], cksum 0x7e4b (incorrect -> 0xd0a2), seq 3787640500, win 64240, options [mss 1460,sackOK,TS val 2060853225 ecr 0,nop,wscale 7], length 0 192.168.254.172.6668 > nuc.39180: Flags [R.], cksum 0xb19e (correct), seq 0, ack 3787640501, win 7300, length 0 192.168.254.172.6668 > nuc.39180: Flags [R.], cksum 0xb19e (correct), seq 0, ack 1, win 7300, length 0 nuc.57312 > 192.168.254.172.6668: Flags [S], cksum 0x7e4b (incorrect -> 0x83dd), seq 2945380200, win 64240, options [mss 1460,sackOK,TS val 2060859226 ecr 0,nop,wscale 7], length 0 192.168.254.172.6668 > nuc.57312: Flags [R.], cksum 0x7c4a (correct), seq 0, ack 2945380201, win 7300, length 0 nuc.57322 > 192.168.254.172.6668: Flags [S], cksum 0x7e4b (incorrect -> 0x5161), seq 749964655, win 64240, options [mss 1460,sackOK,TS val 2060865185 ecr 0,nop,wscale 7], length 0 nuc.57322 > 192.168.254.172.6668: Flags [S], cksum 0x7e4b (incorrect -> 0x4d59), seq 749964655, win 64240, options [mss 1460,sackOK,TS val 2060866217 ecr 0,nop,wscale 7], length 0 192.168.254.172.6668 > nuc.57322: Flags [R.], cksum 0x6115 (correct), seq 0, ack 749964656, win 7300, length 0 192.168.254.172.6668 > nuc.57322: Flags [R.], cksum 0x6115 (correct), seq 0, ack 1, win 7300, length 0 nuc.45892 > 192.168.254.172.6668: Flags [S], cksum 0x7e4b (incorrect -> 0x8dec), seq 4186937518, win 64240, options [mss 1460,sackOK,TS val 2060871328 ecr 0,nop,wscale 7], length 0 nuc.45892 > 192.168.254.172.6668: Flags [S], cksum 0x7e4b (incorrect -> 0x8a03), seq 4186937518, win 64240, options [mss 1460,sackOK,TS val 2060872329 ecr 0,nop,wscale 7], length 0 18:04:04.023956 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.254.172 tell 192.168.254.190, length 46 18:04:05.009686 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.254.172 tell 192.168.254.190, length 46 18:04:05.995269 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.254.172 tell 192.168.254.190, length 46 192.168.254.172.6668 > nuc.45892: Flags [R.], cksum 0xb59f (correct), seq 0, ack 4186937519, win 7300, length 0 192.168.254.172.6668 > nuc.45892: Flags [R.], cksum 0xb59f (correct), seq 0, ack 1, win 7300, length 0 nuc.42268 > 192.168.254.172.6668: Flags [S], cksum 0x7e4b (incorrect -> 0xd5cc), seq 2492246175, win 64240, options [mss 1460,sackOK,TS val 2060878330 ecr 0,nop,wscale 7], length 0 192.168.254.172.6668 > nuc.42268: Flags [R.], cksum 0x18da (correct), seq 0, ack 2492246176, win 7300, length 0

J-N-K commented 5 months ago

I'm not sure. I don't like docker because it always causes trouble, especially with network settings. Maybe it's also an issue with TTL or similar (I have seen that with Sonos in the past).

theater commented 5 months ago

Do you notice this cksum incorrect part: nuc.42268 > 192.168.254.172.6668: Flags [S], cksum 0x7e4b (incorrect -> 0xd5cc), seq 2492246175, win 64240, options [mss 1460,sackOK,TS val 2060878330 ecr 0,nop,wscale 7], length 0 Could it be a new protocol? Is it reverse engineered or they have it documented on the API site? Maybe I can sync the code and play a bit with this unless it's reverse engineered and I have to do some byte-code mapping :)

stale[bot] commented 3 months ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.