State message should show switch(es) state of device, not just connected, connecting, disconnected?

[Jibun-no-Kage]

State message should show switch(es) state of device, not just connected, connecting, disconnected?

How does one query the given IoT device for its switch state? I have used several (older) Node Red modules that control TUYA IoT devices, and they will have a simple request option to query the switch state, even the switch state of a power strip, that may have up to for power sockets. But with your solution, I don't see a straight forward way to query the switch state?

For my power strip for example, using different tuya smart module for node red it would returns dsp[101] for the master switch, and dps[1] for socket 1, and dps[2] for socket 2. etc.

[Jibun-no-Kage]

I can't get the current state device? The state returned is useless because there is no way to link the state with the IoT device, please add the device name and id to the state returned so we know which device returned the state. Without this, you have to have many more nodes in the flow, because none of the information in the msg is pass through the state connector.

[msillano]

The 'node-red-contrib-tuya-smart-device' is a low level driver, with huge capabilities, but the programmer is responsible for the middleware. He must therefore go into the details and the oddities of the Tuya devices, which, let's remember, are not designed and produced by a single company. This is the strength of the Tuya ecosystem, but it can create some problems for the designer.

For your specific problems, we distinguish between 'node-status' (CONNECTED etc.) and 'device-status' (i.e. the values ​​of all data Points exposed by a device). In general, the GET {schema = true} (not well documented here, but you can look at 'get(options)' in library) command returns all the DPs of a device with their value (current or last), if this command is implemented by the device. I said 'in general' because there are exceptions, see for example the post ISSUE#96. The examined device NEVER sends the most important DPs with GET (SCHEMA).

Otherwise the single DPs can be read with GET (dp) or with SET (dp, null). When possible :)

Also yes, I always use one node per device, even if they are 10+. The needs change so much from one device to another (REFRESH or NO refresh, static retry or dynamic retry, etc ..) that I prefer to manage differences at node level. Enjoy.

[Jibun-no-Kage]

Reading my original question, I realize I did not present the need correctly.

The issue is not the actual GET result, but the fact that the id of the device is not returned with the GET result. This makes parsing or filtering the result returned more complex than it needs to be. Other nodes allow me to create a common flow because I always know which device is doing what. Where as if I don't know the device id, I have to create a (often duplicate) flow for each individual device.

Other nodes solutions make it easier to use a common flow across all devices because they return the GET result with the virtual id of the device or the device id, so that the resulting response or message is easy to refer to its source.

For example, say SmartAir-Life nodes, I send a SET or GET to device X, the response includes the result for device X. msg.deviceid=X as an example. If you compare this idea to other TUYA based models, you will set the difference. As noted, the SmartLife-Air nodes, explicitly return the results of every command or query made via its nodes with the virtual id, or device id in the same message, the status result returned.

[msillano]

I am very amazed at what you say.

• In my user experience with the tuya-smart-device node (ver. 4 and 5) this has NEVER happened to me. Indeed, I use deviceID as primary key, so in my code I have some 'assert' for malformed messages, which never activate.

• As for the tuya-smart-device hub node, that I don't use because it is poorly performing, out of curiosity I looked at the code: all outgoing messages have a structure like:

           node.send({
              payload: {
                 data: data,
                 deviceVirtualId: msg.payload.deviceVirtualId,
                 deviceKey: msg.payload.deviceKey,
                 deviceName: msg.payload.deviceName,
                 deviceIp: msg.payload.deviceIp,
                 requestID: requestID,
        },

  with a lot of informations, even more that in the tuya-smart-device device ! So I can't imagine how a responses to GET / SET can be present without the device ID, KEY. IP...

  With regard m.s.

[Jibun-no-Kage]

Are talking about the same set of nodes?

[msillano]

I hope so: we are in https://github.com/vinodsr/node-red-contrib-tuya-smart-device, so we are talking about node-red-contrib-tuya-smart-device, installed via palette on node-red :) or not?

[stale[bot]]

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.

[stale[bot]]

Auto closing the issue