TUYA Device work (switch) local but power/voltage/ampare wont be send

[xsasx]

Hi,

i have installed your tuya plugin (tested both dev and normal) Device is a power plug like the gosund sp1 its from GNCC and called SP11 - i use tuya smart app... but weather in tuya smart app or inj OH3 i got the energy status .. i got at first time a few now i got nothing ..any tip for me ?

[xsasx]

ok found out that the plug need internet for this - thought everything is local ? switch work without internet - and it works only if you have the tuya smart app on mobile device open

maybe intresting rospogrigio/localtuya#549

[J-N-K]

This is very astonishing. Which version of the binding are you using? With the latest 3.2.14 it should work.

[xsasx]

3.2.15-SNAPSHOT

[scatterthought]

I can confirm this in version 3.2.14. I disabled Internet access and power-cycled the smart plug. OH could still see that the plug was online, but the current was not reported (I don't use any other channels).

As soon as I enabled Internet access, the current immediately started populating again.

[J-N-K]

@scatterthought Which DPs are used?

[scatterthought]

@J-N-K Here are the device logs. Looks like the DPs are "Current", "Voltage", and "Power".

Here are the equivalents in the instruction set. Note that "add_ele" does not have a DP, so the calculation of kWh must be done in the cloud.

[stale]

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.

[scatterthought]

@J-N-K, just giving this a nudge since it got marked as stale. Not a huge priority, but would be great to have local access to power data. Cheers!

[HolgerHees]

I have a similar case with my "Stadler Karl Big" humidifier. Sending commands for switching ON/OFF, changing speed level etc, works. But it never updates it values like humidity. Also sending a REFRESH command to this item does not help.

I use the latest released version 3.2.15. My polling interval is 60 seconds and i blocked my internet for this device too.

If needed, I can provide logs too. But I dont know if I have to obfuscate some of the encoded raw data.

--- UPDATE ---

I analyzed my log a little bit deeper and maybe the device itself is not providing updated data, if it is not reaching the cloud.

2023-02-27 12:51:14.607 [DEBUG] [.internal.local.handlers.TuyaEncoder] - {my_dev_id}/{my_dev_ip}:6668: Sending DP_QUERY, payload {devId={my_dev_id}, uid={my_dev_id}, t=1677498674, dps=null, gwId={my_dev_id}}
2023-02-27 12:51:14.608 [TRACE] [.internal.local.handlers.TuyaEncoder] - {my_dev_id}/{my_dev_ip}:6668: Sending encoded {my_sended_encoded_payload}'
2023-02-27 12:51:14.608 [DEBUG] [al.local.handlers.TuyaMessageHandler] - {my_dev_id}/{my_dev_ip}:6668: Connection established.
2023-02-27 12:51:14.614 [TRACE] [.internal.local.handlers.TuyaDecoder] - {my_dev_id}/{my_dev_ip}:6668: Received encoded '{my_received_encoded_payload}'
2023-02-27 12:51:14.614 [TRACE] [.internal.local.handlers.TuyaDecoder] - {my_dev_id}//{my_dev_ip}:6668: Decoded raw payload: {"dps":{"1":false,"14":59,"22":0,"29":false,"33":83,"34":"Half","101":"level_1","102":false,"103":"CO","104":0}}

Based on this log this are my assumption

1. Device is switched on and is working. => visual verified
2. I can also control it by sending command and it will react to it => visual verified
3. But the received payload is telling me that the device is switched off (dps:{"1":false}) has outdated filter runtime (dps:{"33":83}) and wrong fan speed (dps:{"101":level_1})

I can send command to dps 1 to switch the device on and off
I can send command to dps 101 to change the fan speed

but I will always get the payload above back if the thing is fresh initialized and fetching data with DP_QUERY

I know that it was working in the beginning

---

here are some more logs

2023-02-27 13:08:13.597 [DEBUG] [.internal.local.handlers.TuyaEncoder] - {my_dev_id}/{my_dev_ip}:6668: Sending HEART_BEAT, payload {devId={my_dev_id}, uid={my_dev_id}, t=1677499693, dps=, gwId={my_dev_id}}
2023-02-27 13:08:13.597 [TRACE] [.internal.local.handlers.TuyaEncoder] - {my_dev_id}/{my_dev_ip}:6668: Sending encoded '{my_sended_encoded_payload}'
2023-02-27 13:08:13.600 [TRACE] [.internal.local.handlers.TuyaDecoder] - {my_dev_id}/{my_dev_ip}:6668: Received encoded '{my_received_encoded_payload}'
2023-02-27 13:08:13.600 [TRACE] [.internal.local.handlers.TuyaDecoder] - {my_dev_id}//{my_dev_ip}:6668: Decoded raw payload: 
2023-02-27 13:08:13.600 [DEBUG] [.internal.local.handlers.TuyaDecoder] - {my_dev_id}//{my_dev_ip}:6668: Received MessageWrapper{commandType=HEART_BEAT, content=''}
2023-02-27 13:08:14.913 [DEBUG] [.internal.local.handlers.TuyaEncoder] - {my_dev_id}/{my_dev_ip}:6668: Sending DP_REFRESH, payload {devId={my_dev_id}, uid={my_dev_id}, t=1677499694, dpId=[4, 5, 6, 18, 19, 20], gwId={my_dev_id}}
2023-02-27 13:08:14.913 [TRACE] [.internal.local.handlers.TuyaEncoder] - {my_dev_id}/{my_dev_ip}:6668: Sending encoded '{my_sended_encoded_payload}'
2023-02-27 13:08:14.918 [TRACE] [.internal.local.handlers.TuyaDecoder] - {my_dev_id}/{my_dev_ip}:6668: Received encoded '{my_received_encoded_payload}'
2023-02-27 13:08:14.919 [TRACE] [.internal.local.handlers.TuyaDecoder] - {my_dev_id}//{my_dev_ip}:6668: Decoded raw payload: 
2023-02-27 13:08:14.919 [DEBUG] [.internal.local.handlers.TuyaDecoder] - {my_dev_id}//{my_dev_ip}:6668: Received MessageWrapper{commandType=DP_REFRESH, content=''}

[scatterthought]

I wonder if it's similar to this limitation on TP-Link Tapo devices?

Note: If the Tapo device is to be isolated from the internet e.g. on an IoT LAN, the P110 will not expose its energy and power data until it has successfully synchronised it's clock with an NTP server - at time of writing, this was pool.ntp.org. To satisfy this requirement while keeping the device isolated, your router should be configured to either permit udp/123 out to the internet or a NAT rule created to redirect all internet bound NTP traffic to a local NTP server.

https://www.openhab.org/addons/bindings/tapocontrol/

[HolgerHees]

Instead of just sending ON/OFF, which results in a "soft" ON/OFF state. I removed the power cable for 10 seconds. After that time all values (e.g. filter runtime, humidity etc) are reported correctly. After plugging the power cord back in there was no blocked ntp request. Only blocked request on port 443 and port 886 to AWS cloud.

lets see how long I get correct values again.

[scatterthought]

This discussion on LocalTuya might be relevant.

rospogrigio/localtuya#194

[J-N-K]

Instead of just sending ON/OFF, which results in a "soft" ON/OFF state. I removed the power cable for 10 seconds. After that time all values (e.g. filter runtime, humidity etc) are reported correctly. After plugging the power cord back in there was no blocked ntp request. Only blocked request on port 443 and port 886 to AWS cloud.

lets see how long I get correct values again.

If that helps it should be added to the documentation. Also - in the issue linked by @scatterthought - it seems that discarding (instead of redirecting) DNS requests might help. DP18 handling is already part of the code, so that should work.

[HolgerHees]

I block dns requests now too.

Before, my dhcp server was assigning an internal dns who was still answering dns requests. Only the final internet traffic was blocked. Now, my dhcp server is assigning for tuya devices an public dns and all internet traffic is still blocked. This means, dns requests of tuya devices are now blocked too. Have verified it by checking logs.

I have to observe the tong time behavior of my humidifier. If I know more, I will write an update here.

[scatterthought]

It's possible that the humidity data is different from the energy data, as I don't think I've read anything that mentions humidity.

I don't think I have the ability to discard DNS requests on my network, so I can't test this. I looked in Pi-Hole and my Tuya devices are finding their way around it. Tuya must have hardcoded a DNS into them.

[HolgerHees]

My guess was that it has nothing to do with the kind of data. Only with the fact that a network connection is needed sometimes to report any data. And currently I try to find out if this is the case.

I don't know much about the protocol, but I think the data types are not classified by humidity/energy etc. They are classified more by generic types like string, number, bool etc.

[J-N-K]

@HolgerHees Did you find something that should be added to the documentation?

[HolgerHees]

not really. Still not working for me.

it works after I switched the device ON. But after some hours, it stops sending new values.

I ignore it for now, because sending commands like fan level, works the whole time. And thats the important part for me :-)

[J-N-K]

The problem is that a lot of Tuya devices are buggy and there is no documentation how it SHOULD work, so it's all guessing. It could be that some devices just fail if the connection is too "old".

[stale]

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.