Hi I added tuya project etx. it found few things but all of them have status : CONFIGURATION_PENDING
Waiting for IP address
This are temp sensors and smart plugs but not at my home just on other network. Is it possible to get readings from this devices ? OH 4.1.1 binding 4.1. On tuya cloud i see this devices and all of them are imported automaticly to my OH
I believe that the devices still have to be on the same network as your openHAB server. The cloud is only used for discovery. So for this to work, you’d have to set up a VPN.
I have had a slightly different experience in my system, to the following:
It only works for devices on the same subnet because broadcast messages used for the IP configuration are limited to the subnet
…as my Tuya device (EV Wallbox) and OpenHAB server are on different subnets, and working perfectly.
I’m not basing this on specific knowledge of the Tuya EcoSystem, nor knowledge of the OH binding operation, however the following are my observations:
Yes, for the initial Device (tuya) setup and configuration, from memory, the Mobile Phone or tablet (running the Tuya app) needs to be on the same subnet as the Tuya Device
The OP asked about devices in different networks. From the traffic I have captured, I would concur that I can’t see any obvious means to enable ‘Local’ control integration with OH, other than the suggestion already made to configure a VPN. In this instance, I presume this was meant as a Site-2-Site VPN
I do however run the OpenHAB server, and Tuya device in different subnets. Note the distinction from Networks: At a high-level, for the purposes of this discussion this means traffic can be routed between them, but they are in different broadcast domains.
Not only this, but the subnets are also separated by a PFsense firewall, so only traffic I explicitly allow can flow between the devices. In this instance, a firewall rule allowing the OpenHAB server to connect to the Tuya device (with return traffic on the same TCP connection) is all I needed
Yes I do see UDP broadcast messages coming out of the Tuya device, but they go absolutely nowhere. Between the different broadcast domains, and the firewall stopping these, I can be assured these never reach the OpenHAB server.
I have no doubt this would stop any device discovery working however, but that’s not been an issue/requirement for me
Not sure if this makes a difference, but my Tuya device is running Protocol version 3.3
The above binding has been running rock solid (for at least 6 months) with the above configuration, in spite of me just realising now the documentation says I should not be using my Tuya App at the same time(oops!!).
Tuya devices can be controlled locally and one the cloud. Most (all?) devices only support one local connection. The app can use both, but seems to prefer the cloud connection. As long as it uses the cloud connection, everything is working fine. Otherwise the app connection will disconnect openHAB, then openHAB disconnects the cloud and so on. That is why using the app and openHAB in parallel is not recommended.
The binding needs the IP address of the device. Devices announce themself by broadcast UDP packets and those are detected by the binding and used to configure the IP address. These UDP addresses are usually not routed and bound to the local subnet (although it is possible with special router configuration to forward them to other subnets). The IP can also be configured manually, in that case the thing does not depend on the broadcast packets. Some Tuya devices don’t accept the local TCP connection from another subnet. Its hard to predict which one do and which don’t.
Thanks @J-N-K - Great explanation. Based on this, I suspect I now know the reason mine has worked well, and has not been affected by the one local connection limit issue:
I run a separate Automation vLAN (also with its own corresponding WiFi network) which the Tuya based device (and most of my Automation devices) are connected to.
My phone (where the Tuya app is running) is connected to a ‘Home’ network, which is almost totally isolated from the Automation network
As an aside, the openHAB server is also on a completely different (firewalled) network, but with specific rules to allow access to the Tuya device
The Tuya app therefore is forced to connect to the Tuya device via the cloud, due to the isolation, leaving the only local connection to be used by OpenHAB. The packet captures I have done, seem to confirm this
Based on your explanation above, its seems I was both lucky that my specific device supported local packets routed from another subnet, and that my network design prevented the client from connecting locally and interfering with OpenHAB operations. I might go and buy a lottery ticket
