simeonovp / node-red-contrib-tuya-devices

Support for Tuya devices in SmartHome projects using Node-RED. The goal of the project is to allow using local devices supports Tuya in Node-Red
MIT License
8 stars 1 forks source link

No device connections. #10

Open VladimirTuzovGitHub opened 1 month ago

VladimirTuzovGitHub commented 1 month ago

Hello! As I understand it, the manager connects to the cloud and received a list of devices, but the devices do not connect to manage them and are constantly in the Search and Disconnected status. I have been trying to figure this out for many days, but to no avail. Please help me figure this out. image image image image image

simeonovp commented 1 month ago

At first glance, the configuration looks good. It sounds like a communication problem. Is Node-Red in the same IP network as the devices? You could possibly check "Cache Announcements" in the manager configuration. Then you can look in the file "announcements.json" in the local cache (.node-red/node_modules/node-red-contrib-tuya-devices/resources//) to see whether the devices are announcing themselves.

VladimirTuzovGitHub commented 1 month ago

Yes, Node-Red is on the same network as all devices. announcements.json Why are not all devices in "announcements.json"?

VladimirTuzovGitHub commented 1 month ago

image

VladimirTuzovGitHub commented 1 month ago

I also found some interesting behavior in the file "announcements.json" the device is 20421503ecfabcb12127 which is not in the Tuya app or cloud. It is at home in my local network and is connected to another ecosystem.

simeonovp commented 1 month ago

@VladimirTuzovGitHub : Something went wrong during the installation. A referenced package (arp-lookup) seems to not been installed correctly. You can search for the package in ".node-red/package-lock.json"

VladimirTuzovGitHub commented 1 month ago

@simeonovp Hello! package-lock.json

VladimirTuzovGitHub commented 1 month ago

@simeonovp Did the file help you understand the reason?

simeonovp commented 1 month ago

@simeonovp Hello! package-lock.json

The "arp-lookup" module appears to be installed correctly. It must be another problem. I will look for it when I get the chance. Due to capacity reasons, I am unfortunately unable to offer quick support for hobby projects. I will get back to you as soon as I have news.

gattokotatsu commented 2 weeks ago

Sorry to bother you with this question. I have a temperature and humidity sensor I want to handle with node-red, but it's battery operated, and comes online every now and then (1 hour in my case), as I think is the usual behaviour for devices like these. Can I handle this type of device? How does it work? The value is retrieved using the tuya cloud API from tuya servers? Or the node is just waiting for the device to announce it's online and transmitting? And even in that case, after the first value received, what happens if I try to read it again?

Thanks for your time!

simeonovp commented 2 weeks ago

@gattokotatsu This is a device-specific behavior. The node uses the tuyapi module. It has an alive flag and checks cyclically whether the device is online. If the device is online and supports events, the node receives these events with data and reports them. In addition, the data can also be retrieved via polling. My TH sensors are battery-operated and communicate via a Tuya BLE gateway. This makes the online status transparent for the node.

gattokotatsu commented 2 weeks ago

@simeonovp thanks for your response (and for all your work). I tried to setup all as shown in the tutorial, but I end up with the decice having always "device not connected" and no debug data output. The manager node is Online, The devices (1 in my case, a temperature and humidity, the model should be wsdcg) are shown. All information on models, home, user, is in cache and looks ok. tuya-project node looks ok. tuya-model node looks ok (events and action are empty). tuya-local-device looks ok (no gateway, but is auto-generated, I assume is ok). tuya-cloud look ok.

Am I missing something? Is it possible that this kind of device just wakes up, makes an http call home and that's it, without sending events on local network?

simeonovp commented 1 week ago

@gattokotatsu If you have connection to the device than you must have an item for the device in the "announcements.json". If there is nothing, than you must check the network connectivity

gattokotatsu commented 1 week ago

@simeonovp that file is empty. The network connectivity of what, exactly? The sensor is working, I guess it comes online, it connects to the network as it was configured to do (same subnet of node-red, I suppose, same wi-fi network), read the temp and humidity, successfully post the value on tuya servers, then go to sleep. I have readings all the time (with the app). And node-red is connected to the network, it has several other stuff running, all is ok, incoming and outgoing traffic. So "separately" node-red and the sensor have network connectivity. If there is something preventing the sensor to connect to node-red I really don't know. And what? I don't know how (and if) the sensor announces itself. I think it's easier to just retrieve the data from tuya server with an HTTP call, can I do it with this node? I would like to keep it all local, but if I there is no other way...

And again! Thanks for your help.

simeonovp commented 1 week ago

@gattokotatsu The Node module is designed exclusively for local communication (not via the cloud) with Tuya devices. For this, the Node-Red server must be in the same network segment as the devices used. Many Tuya devices are not WiFi-capable and use Bluetooth, ZigBee, etc. Communication takes place via corresponding gateways. These must be accessible in the local network. For example, a mobile phone can simultaneously play the role of a Tuya client and a Bluetooth gateway (if it is within the Bluetooth range of the device) for the cloud connection.

simeonovp commented 1 week ago

I also found some interesting behavior in the file "announcements.json" the device is 20421503ecfabcb12127 which is not in the Tuya app or cloud. It is at home in my local network and is connected to another ecosystem.

@VladimirTuzovGitHub The Arp package is an optional feature. In the current package (1.3.5) there are improvements that enable the functionality of the nodes even in case of problems with the Arp package. The file "announcements.json" caches locally the announcements of all Tuya devices in the local network segment. These are used when you want to add a new device

gattokotatsu commented 1 week ago

@simeonovp The node red server is connected to the same router, and all IPs are on the same subnet. Well, the sensor one I guess is in the same subnet, the sensor is WiFi, connected to the same wifi network as all the devices in our home are. I set it to read values every 5 minutes, and it runs without issues. And the only way it has to upload data is getting an IP from the router in the same subnet of all other devices. The Raspberry Pi where node-red is installed could block the announcement because of the firewall? I really don't want to sniff traffic and check what the sensor does in his wake up time, it's not worth the time. If I don't find out why it doesn't work with your node, I will create a function to read it from the cloud API. I hate relying on web services, but if there is no other way...

gattokotatsu commented 1 week ago

@simeonovp Update, everything seems to work. To test if it worked I just connected a debug node to the battery pin to get battery status, but all data just came from the main (data) pin and I didn't get anything out of the battery pin. I never used a multi output node like that and I assumed all pins could be used separately. My mistake., sorry. Temp comes as a integer number and I have to divide by ten to get the value, but I guess is normal for celsius temp. And I receive two identical buffer messages, But I guess that is normal too.

Sorry I wasted some of your time.

gattokotatsu commented 1 week ago

@simeonovp Well, another update. I set the update of the sensor every 5 minute, and I get a message in node-red every now and then. A burst of three one after the other (every 5 minutes), then nothing for hours maybe. It seem random. If I remove and put back batteries it seems the first try always is "captured". But after that, it looks really random.

Alacika commented 1 week ago

I have the same situation as @gattokotatsu. All connections seem to be fine:

"The manager node is Online, The devices are shown. All information on models, home, user, is in cache and looks ok. tuya-project node looks ok. tuya-model node looks ok (events and action are empty). tuya-local-device looks ok. tuya-cloud look ok."

The Node-Red is configured to IP address 10.0.0.160 and the Tuya Smart Switch is configured to IP address 10.0.0.31. I can ping 10.0.0.31 from the console of the Node-Red. But the device node status is yellow "search" or red "Device not connected", and the "announcements.json" is empty. (The device can be accessed and managed from an automatically configured Home Assistant plugin running on the same IP address (10.0.0.160), but I would like to manage it independently.) I don't know how to find the cause of the problem. Do you have any suggestions? Thank you!

gattokotatsu commented 1 week ago

@Alacika I gave up. In my case the sensor woke up every 5 minutes, and sometimes I get readings for 3 or 4 times one after the other. Sometimes hours pass without a single reading. So I just built a few nodes that connect to the Tuya cloud API and read the sensor data... I hate relying on web services. I like handling all locally, but for now it works... And anyway, when I got readings, MQTT messages from this node for some reason force the reset of the broker connection ti openHab and with this other node setup I used the standard node-red mqtt without any problem.

simeonovp commented 6 days ago

@Alacika Normally, the tuya broadcasts the announcements cyclically on port 6666 or 6667. The packet also contains the IP address of the device. These are cached in the JSON file and the connection to the device is established using the information. You can use a monitor tool (e.g. Wireshark) to look for UDP packets on these ports on the network. If no announcements arrive, local communication is not possible. The packets may be present and a firewall or something similar is blocking reception.

Alacika commented 6 days ago

@simeonovp Thank you again for your guidance! This information about the ports was very important! I saw that tcpdump shows communication on ports 6666/6667, so that's fine. My environment is Proxmox -> Docker -> Node-Red. I just published these ports to Node-Red in Docker. The Device Node immediately got a "connected" status. I can move on... ;-)