Skip to content

note 4: Gateways and sensors

Jump to bottom
Marco Sillano edited this page Apr 10, 2024 · 124 revisions

One of the problems encountered in IOT applications is the limited number of possible WiFi connections: this number depends on the router-AP used.

For example, a budget router with a single-core processor and two antennas may only be able to handle up to 10 devices at the same time. In comparison, a more expensive router with a dual-core processor and four antennas may be able to handle up to 25 devices. The use of extenders does not increase the number of devices, it only extends the coverage.

As the network grows, you can change the router with a more performing one, or use a second router, splitting the WiFi network in two: In SmartLife it is necessary to define a new home, and probably 2 instances of tuyaDAEMON are needed (even on the same server).

Help can be provided by gateways: each gateway occupies only one WiFi slot and can manage many devices. Furthermore, the 'mesh' feature, since ZigBee 3.0 (2015) and Bluetooth 5.0 (2017), allows for more extension of the network.

Tuya can use the following protocols to connect devices:

  1. Wi-Fi
  2. Bluetooth low energy
  3. Zigbee
  4. Bluetooth mesh
Feature Zigbee 3.0 Gateway Bluetooth Gateway SIGMesh Gateway
Range Up to 100 meters Up to 10 meters Up to 100 meters
Power consumption Low Low Low
Max devices 64000 100 32000
Data rate 250 kbps 2 Mbps 1 Mbps
link reliability high medium high
Security AES-128 encryption 128-bit encryption 128-bit encryption
Cost Medium Low Medium
Ease of use Medium Low Medium

The use of gateways with tuyaDEMON has another beneficial effect:

  • A WiFi low-power sensor, not accessible with tuyapi because it is not always connected to the WiFi network, can be handled by tuyaDEMON only via TRIGGER or via OpenAPI.
  • Replacing such a sensor with the ZigBee/BLE version, the sensor can behave as a standard subdevice (or virtual device), as the gateways are permanently connected to the WiFi, and we can use tuyapi.

There are also Tuya IR gateways, which can control IR devices, such as TVs, air conditioners, stereos, etc... This can be useful if you want to handle these devices with your voice or automation or tuyaDAEMON. They must be present in every room where there are devices to control.

These are the premises and the positive aspects. But we are in the variegated Tuya universe, where exceptions and quirks are the norm. By now I've accumulated some experience with gateways and tuyaDEAMON. Therefore I can try to make the point, by gathering specific information here that I hope will be useful to other users.

Gateway and tuyaDEAMON

In tuyaDEAMON, the gateways are added on global.alldevices as real devices. Example:

		{
			"id": "**masked**",
			"name": "Zigbee Gateway",
                        "device": "ZigBee_Gateway_G01",
                        "capability": ["NONE"]
 			"power": "USB"
		},
  • In general, gateways don't have accessible DPs and produce very little data of their own, only about status (PUSH). They are limited to a bridging function. But there are exceptions.
  • Like any real device a gateway requires a dedicated tuya-smart-device node in the 'CORE_devices' flow.
  • On global.alldevices the "capability": ["NONE"] precludes any SET or GET directed to the gateway, while the control over the admissible operations for each subdevice is in the definition of the single virtual device.
  • In gateway devices, the word 'gateway' (or 'Gateway')MUST be present in 'name' or 'TuyaName' (e.g. 'multi_gateway', 'Zbee Gateway').

Sensor and tuyaDEAMON

In tuyaDEAMON, the Sensors are added on global.alldevices as virtual devices. Example:

        {
            "name": "Temperature 1",
            "device": "Temperature_Humidity_Sensor",
            "cid": "**MASKED**",
            "gateway": "**MASKED**",
            "capability": [
                "NONE"
            ],
            "dps": [
                {
                    "dp": 101,
                    "name": "humidity",
                    "capability": "PUSH"
                },
                {
                    "dp": 103,
                    "name": "temperature",
                    "capability": "PUSH"
                }
            ]
        },
  • This is a simple sensor, the only capability is to push data, a common behavior in sensors. But you can find subdevices with many capabilities and DPs, as an example see 'TRV_Thermostatic_Radiator_Valve' later.
  • The cid identifies the virtual device (or subdevice) while the gateway identifies the Zigbee or Bluetooth hub associated. Both data can be found using tuyapi wizard tool.

In tuyaDAEMON all the user commands are directed to the virtual device, with the standard format:

      payload {
         "remote": undefined|`server-name`,                      
         "device": undefined|`dev-name`|`cid`|`id`,      
         "property": undefined|`dp-name`|`pseudoDP`|`dp`,
         "value": undefined|`any`|`accepted-value` 
          }

notes: For details see tuyaDAEMON commands. For remote instances info see here. For pseudoDP list see here.

At the low level, the subdevices can be accessed by sending messages like these to the 'tuya-smart-device' gateway node (see TuyAPI doc):

SET example:
                   {
                  "payload": {
                     "cid": "**MASKED**",        
                     "dps": "used-DP",
                     "set": num-Value|"str-Value"                                  
                   } }

GET example:
                   {
                  "payload": {
                     "cid": "**MASKED**",        
                     "operation": "GET",
                     "dps": "used-DP"
                   } }

SCHEMA example:
                   {
                  "payload": {
                     "cid": "**MASKED**",        
                     "operation": "GET",
                     "schema": true
                   } }

See also node-red, 'CORE' flow, node input 'low_level_IN'-Description.

ZigBee

  • ZigBee is a wireless personal area network (WPAN) technology that operates in the 2.4 GHz frequency band.
  • ZigBee mesh networks are self-healing and self-organizing. This means that if a node in the network fails, the network can automatically reroute messages around the failed node.

ZigBee net

Device Type Feature
Zigbee Gateway * Sets up the network * Assigns addresses to devices * Routes messages between devices * Only one per network
Zigbee Router * Forwards messages between devices * Can also act as an end device * Not required to route messages
Zigbee End Device * Receives and sends messages to the Zigbee coordinator or router * Does not route messages between devices
  • ZigBee devices are designed to operate on a very low power budget. This makes them ideal for battery-powered applications.

References:

Some known Zigbee Gateways

ZigBee gateway info here.
note: Very robust device, 2 years of trouble-free operation, covers a whole 3-room apartment by itself (90 sqm, 10+ devices)
Multifunction (ZigBee, BLE) gateway info here.
note: Good
Multifunction (ZigBee, BLE, IR) gateway info here.
This gateway sends a special message at startup (I did not find how to force it) see ISSUE#117 and the node 'format DPS' in 'CORE_devices' flow.
note: Untrusted device: hangup often (3-10 times/day)
  • To overcome this gateway hangup, I use a watchdog, which cuts off the gateway's power for a short time, causing the restart of the gateway (see here).

Some known Zigbee Sensors

ZigBee 3 Gang info here. (Use example here:Step 3),
  • Used as remote to start Tuya automation, any button gives 3 distinct commands (single, double, long press)
  • In tuyaDAEMON, user actions are PUSHED, and also SET works, but it does not fire the automation (useless: TRIGGER required)
    • Temperature Humidity Sensor info here.
  • Not Tuya logo, but works very well. Sensitivity +/-1. Lacks battery (CR2032) status data: life more than one year.
  • In tuyaDAEMON, data is PUSHED at any change.
    • Temperature Humidity Sensor 2 info here.
  • Sensitivity +/-0.1, battery SOC (2xAAA)
  • In tuyaDAEMON good, complete RO access: GET, SCHEMA
    • TRV Thermostatic Radiator Valve info here.
  • Very good device, battery Alarm (2xAA), life one year.
  • In tuyaDAEMON, rich access: 10+ Write parameter, 20+ PUSH data

    • note: many non-Tuya ZigBee devices can be associated with a ZigBee-Tuya Hub. I use the following:

    Aqara intelligent air pressure temperature sensor humidity info here.
  • Very small device, battery life two years.
  • For Xiaomi Mijia Homekit app. With smartLife pushes temperature, humidity 20'-3h interval (no pressure)

    • Bluetooth and BLE

    • Bluetooth Low Energy (BLE) was first introduced by the Special Interest Group (Bluetooth SIG) in 2009. It was fully integrated into Bluetooth 4.0 in early 2010. BLE was designed for smart connectivity systems with low power requirements.

    • However, BLE networks were initially limited in their capabilities. BLE only allowed for one-to-one communication, and simple devices (such as beacons) within a network could only communicate through the central hub.

    • The release of the Bluetooth mesh networking standard in 2017 was a game-changer. The Mesh Profile specification, added to Bluetooth 5.0, allows for many-to-many communication.

    SIGMesh uses a routing protocol to ensure that messages reach their destination, even if there are obstacles or interference. BLE mesh, on the other hand, uses a flooding protocol, meaning messages are broadcast to all nodes in the network. This can be less efficient, but it is also simpler to implement.

    • BLE is a separate protocol from Bluetooth Classic. The two protocols are not compatible. BLE is designed for applications that require ultra-low power but do not require the transmission of large amounts of data.
    Device Type Feature
    Provisioner Sets up the mesh network and adds new nodes to it.
    Root node Central node in the mesh network. Routes messages between all the other nodes.
    Relay node Extends the range of the mesh network by relaying messages between nodes.
    LPN Designed to minimize power consumption. Only wakes up to receive messages and then goes back to sleep.
    Friend node Extends the range of LPNs. Acts as a bridge between LPNs and other nodes in the network.

    Personally I have always had many difficulties with Tuya and BLE (and Bluetooth): unreliable connections and disappointing results, very little data captured by tuyaDAEMON.

    References:

    Some known BLE and Bluetooth Gateways

    BLE gateway info here.
    This gateway sends a special message at startup (I did not find how to force it) see ISSUE#129 and the node 'format DPS' in 'CORE_devices' flow.
    note: Often disconnects from devices, sometimes from Tuya
    Multifunction (ZigBee, BLE) gateway info here.

    note: On tuyaDAEMON exposes two status DPs.
    Multifunction (ZigBee, BLE, IR) gateway info here.
    This gateway sends a special message at startup (I did not find how to force it) see ISSUE#117 and the node 'format DPS' in 'CORE_devices' flow.
    note: Untrusted device: hangup often (some times/day)

    The strange case of the soil probes

    I have designed both watering systems and timers for hydroponics. In both cases, soil moisture and nutrient level measurements are very useful. Thus began my hallucinatory journey into soil probes.

    Xiaomi Mi Flora plant sensor Bluetooth 4.1 BLE, battery CR2032
    Nutrient, soil moisture, temperature, and light detection,
    In apps "Flower Care" or "Mi Home" (Xiaomi) functioning is perfect.
    • For the tuyaDEAMON integration I tested a Python solution: it worked very well. But this solution requires at least a dedicated hub (Raspberry? WiFi + MQTT + Bluetooth + Python): it seemed excessive to me so I looked for other solutions (perhaps wrongly).

    references

    Some alternatives

    Xiaomi Tuya version (pink) Bluetooth 4.1 BLE, battery CR2032
    In SmartLife measures are not updated !
    In tuyaDEAMON ok commands, fail on RT data.

    A notable disappointment, from the specifications it seemed like the solution, but in practice (I tested two specimens) it is unusable with SmartLife (and tuyaDAEMON)

    • the first device always incorrectly reads the battery at '0' (even with a new battery and some commands working!)
    • the other device provides data (not rt, but fixes values) and not time series: Sometimes the local Bluetooth connection with the phone seems to work, while when the gateway is connected, SET/GET controls are okay, but no RT data exchange takes place, both on SmartLife and tuyaDAEMON
    Soil meter Bluetooth 4.1 BLE, battery 2xAAA
    In tuyaDEAMON PUSHes (fake) data and GET behave like SCHEMA.
    Temperature resolution: 0.1°C.

    Less performing than the Xiaomi device, it only measures humidity and temperature. This is in 'SmartLife' app: historical 24 h

    In tuyaDAEMON, GETs do not return the current value, but a fixed or random value.
    This is very strange, it is the first device that presents this behavior. Here is the result with a poll every 30 minutes:

    Soil meter ZigBeee, battery 2xAA
    In tuyaDEAMON PUSHes data and GET behave like SCHEMA.
    Temperature resolution: 1°C.

    This ZigBee solution has a similar performance to the previous one, and this is usable in tuyaDAEMON (24h, about 70 values):

    Conclusion

    Unlike indoor temperature and humidity Zigbee sensors, which work like a charm, soil sensors present numerous problems: careful tests are needed before choosing a model.

    Clone this wiki locally