2 features that would make Tuya device programming far more flexible

[robin]

Tuya device programming can be extremely frustrating. The devices are produced by thousands of different OEMs, and absolute compatibility is not guaranteed. I have been banging my head against a wall trying to get a thermostat to work properly–even though there is device support in Apilio to set the temperature, it isn’t working as advertised (I can currently only set the temperature to the nearest 2.5C). Whether this is a fault with Apilio or how the device specifies the services it supports I am not sure (and don’t really care), but what I do know is that it IS possible to program the device to do what I would like it to–I just can’t do it (quite) in Apilio.

There are also other frustrating things that I have come up against that would be good to find a solution for–Tuya smart lamps don’t seem to support setting their colour (even from within Smart Life itself!), which is absolutely bizarre given that is the main reason for having a coloured smart light bulb.

Having played around with the Tuya cloud programming interface, I have a suggestion for two things that it would be brilliant for Apilio to add (for all Tuya devices, irrespective of type), which would make all my headaches go away (for the moment, anyway!).

1. Support the generic Tuya “Send commands” command. This takes a JSON command string that allows you to do anything with a Tuya device. For my specific issues, it would allow me to set the temperature of my thermostats and also to specify the colour of my smart bulbs. To create this interface would be very easy for the Apilio developers as it is a pre-built command that just takes a string argument. Users would obviously have to be careful what they actually passed as the string, but it onus would be on the Apilio users to use this with care.

2. Support the generic Tuya “Get the status of a single device” command. If this could be done to return the output string from that command into a string variable of your choice, then it would be possible to extract values that are extremely useful yet not supported in the current interface. Going back to my headaches, for my thermostats this would let me read the current temperature; for my smart bulbs I could get the current colour.

I know that each of these are standard Tuya commands and so cannot be hard to implement given that Apilio is already making similar calls. They are easily prototyped for any device in question within the Tuya cloud developer environment, which is why I know for certain that if I had access to these calls I could get my devices to function as required. However, the way that Tuya works it is essentially impossible to replicate these calls from Apilio using web hooks.

Is there any chance of implementing these? Please? I’m sure they would enhance Tuya programming for lots of people…

[DanT]

Great suggestions, thanks @robin !

[Anna]

@robin

Support the generic Tuya “Get the status of a single device” command . If this could be done to return the output string from that command into a string variable of your choice, then it would be possible to extract values that are extremely useful yet not supported in the current interface. Going back to my headaches, for my thermostats this would let me read the current temperature; for my smart bulbs I could get the current colour.

Hi @robin ! You can get the status of a device directly on https://app.apilio.com/devices Statuses that are used in conditions are monitored automatically, but you can choose to monitor additional statuses there. Click or tap on the name to edit any of your devices to see all available statuses.

If this doesn’t cover your need, could you elaborate a little bit more? How would you use this? Thanks!!

[robin]

@Anna

If this doesn’t cover your need, could you elaborate a little bit more? How would you use this?

Hi Anna,
The status page within Apilio shows very little information. So, for example, one of my thermostats shows the following:

In contrast, if you go into the Tuya cloud development environment and execute the “Get the status of a single device” (Under General Device Management > General Devices Status) using the appropriate device_id, then the response for that same device is far richer, and is as below:

{
“result”: [
{
“code”: “switch”,
“value”: true
},
{
“code”: “temp_set”,
“value”: 50
},
{
“code”: “upper_temp”,
“value”: 55
},
{
“code”: “eco”,
“value”: false
},
{
“code”: “child_lock”,
“value”: true
}
],
“success”: true,
“t”: 1634545666534
}

If I could get this JSON string back, I could then actually use the values that are returned (with a bit of parsing that could be done via IFTTT). The significant value for me here in this example is “upper_temp” which is the actual sensor temperature multiplied by 2, so when that query was made the probe temperature was 27.5C.

Just so you can see that this isn’t just about some obscure requirement that I have to do with a thermostat, the return string for a smart colour-changing bulb is as below:

{
“result”: [
{
“code”: “switch_led”,
“value”: false
},
{
“code”: “work_mode”,
“value”: “colour”
},
{
“code”: “bright_value_v2”,
“value”: 10
},
{
“code”: “temp_value_v2”,
“value”: 0
},
{
“code”: “colour_data_v2”,
“value”: “{"h":39,"s":1000,"v":10}”
},
{
“code”: “scene_data_v2”,
“value”: “{"scene_num":2,"scene_units":[{"bright":1000,"h":0,"s":0,"temperature":500,"unit_change_mode":"static","unit_gradient_duration":13,"unit_switch_duration":14,"v":0}]}”
},
{
“code”: “countdown_1”,
“value”: 0
},
{
“code”: “music_data”,
“value”: “”
},
{
“code”: “control_data”,
“value”: “”
},
{
“code”: “rhythm_mode”,
“value”: “AAAAAAA=”
},
{
“code”: “sleep_mode”,
“value”: “AAA=”
},
{
“code”: “wakeup_mode”,
“value”: “AAA=”
}
],
“success”: true,
“t”: 1634546377979
}

Extracting colour_data_v2 would allow me to determine the current HSV colour setting for the bulb, which cannot be seen on your status page. Moreover, if you implemented the capability to pass a command string to a Tuya device then by passing a colour_data_v2 value I could actually set the lamp colour, which again isn’t possible via your current Tuya implementation.

[Anna]

@robin

The status page within Apilio shows very little information.

You can configure what’s shown on the status page: when you edit the statuses, you can drag and drop them and the first two are displayed:

And this is an example from a video camera that hast lots of statuses:

You see you can choose here if you want to monitor all/none of them That would get you all available statuses. Or do you want to manipulate them in a specific way? I’m not sure if the issue you are describing impacts viewing information for you or manipulating it. Thanks!!

One more thing, maybe this screenshot is better, this is from one of my lightbulbs. Can you show us if the statuses from your request are also available on Apilio for you to monitor? Thanks!!

[robin]

Hi Anna, thanks for getting back to me. And wow… I had no idea those pages existed!

But whatever is being monitored there isn’t getting the values I can get from the Tuya developer envirnoment direct.
I now get:

For some reason the values being returned are both 0 when as you can see from my earlier post, they most certainly are not.

For the bulb I get:

Colour data v2 is not being returned it seems, possibly because the colour_data_v2 is a JSON string, not a numeric value? But bright_value_v2 should be 10 and is being returned as 0.

Even after enabling monitoring of colour_data_v2 it is not possible to set this value (which would need to be in the form of a string such as “{“h”:39,“s”:1000,“v”:10}”

[robin]

Hi @Anna ,

I take it back… I just had not waited long enough for the values to update. The device status settings only update when the values change. Even the colour_data_v2 string is showing correctly. Now if it was possible to also write that string back and change the colour that would be really cool…

Thanks,

Robin

[robin]

Hi @Anna ,

OK, I’ve been trying out the device status pages (that I didn’t realise could be configured as you described, so thank you!), and they almost do what I have requested… except for one very fundamental thing… as far as I can tell (unless I’ve missed this too ) there is no way to actually retrieve the status values themselves, you can only compare them to fixed values.

So for example, my thermostat has a value (Upper temp) that I would like to access. Although I can view it in the Apilio web app, I can’t see any way to get hold of it programmatically. If it was possible to copy the value into a variable I could then do things with it (for example I could send it to IFTTT where it would be possible to log it via Google sheets).

To implement this, one possibility would be to add an option to the webhook that updates variables, to add one that sets this from the status information. So you could add a “Set value from Device Status” option that would need to know the device name and status value name, but then would update the variable accordingly.

Perhaps implemented something along the lines of:

https://app.apilio.com/webhooks/v2/string_variables/XXXXXX/set_from_status?key=YYYYYY&device='Device name’&status=‘Status name’

Also, it would be useful to add an additional situation to the Tuya conditions that as well as the tests for “greater than / less than / equal to etc”, simply triggered when the specified value changed. If you had that plus the possibility to write the changed device status to a string variable, then it would be possible to act on the values and do something more sophisticated with them.

Robin

[philsj]

Interesting discussion.

One way of solving this could be to extend the Apilio REST API to allow querying devices (I suppose, specifically to expose the values on the device status page in the API). It seems likely the result would need to be returned as JSON given the variable nature of the devices. An appropriate Apilio variable could then be set to whatever value you liked from the device.

Although thinking about it, a more friendly approach would be to allow Apilio variables to be updated by Tuya statuses directly in the Apilio interface. Apilio already knows the status value and whether it’s a boolean, a number or a string, and so could allow only the appropriate values to be written into the different variable types. That could be quite useful actually.

[robin]

@philsj

Although thinking about it, a more friendly approach would be to allow Apilio variables to be updated by Tuya statuses directly in the Apilio interface. … That could be quite useful actually.

Fully agree… that would be the best way to do it. If you could opt to associate an Apilio variable with a status value then you could readily access it. You would then not need to add any additional functionality to allow REST API (or IFTTT) access, as reading a variable is already supported.

It would still be slightly tricky to test whether the status-associated variable had changed, given that you can only trigger a condition via comparison with another variable. However, you could set up a second variable with the “old” state and compare the status-associated variable with that. When the change happened you would then need to trigger a logicblock that included updating the “old” state to the new value. The snag is that the most direct route (webhook interface to update a variable) only takes a fixed value… It would, however, be possible to go via IFTTT by sending the value of the new variable (as the IFTTT actions allow variable values to be passed), then getting IFTTT to write the value back to update the variable that stores the “old” state. Slightly clunky, but it should work.

It would, however, be lovely (and far simpler) if you allowed a conditions to trigger when a variable value changes, not just when they are greater / less / equal to other variables.

[robin]

@philsj

@robin

The snag is that the most direct route (webhook interface to update a variable) only takes a fixed value…

While I think about it, how about improving the webhook interface from logicblocks to allow {{variable}} inclusions? After all, the IFTTT interface permits this already. If you did that, it would then be possible to update the value of a variable with that of a different one, without having to ask IFTTT to do it for you

[pebneter]

@robin

how about improving the webhook interface from logicblocks to allow {{variable}} inclusions

hmmm… I think what you are looking for is already available. Unless I am mistake about your idea:

[DanT]

Wow, we are even better than you thought we were!

[robin]

Wow… I didn’t realise you could do that!

I’ve just tested it by using a webhook to set a numeric variable to the value of a second one, by pasting the URL for the variable (minus the “?value=” part), then adding the key “value” and selecting the second variable in the value field.

It ALMOST works… but for a real number it seems to be stripping off the decimal places. So for example, if the second variable is ‘26.44’, then doing this sets the variable being accessed via the webhook to ‘26’.

Is this a bug?

[pebneter]

Hi @robin,
great that it (almost ) worked!
That sounds not quite right, actually, yes. I know that decimals a stripped if they are 0 (e.g. 26.00 becomes 26), but if they are there, they should be present.
I will check this!

[pebneter]

Update: We found the problem (it’s the handling of the incoming data, not the action) and a fix is under way.

[robin]

@pebneter

a fix is under way

Yay! Thank you for doing that so quickly!

[pebneter]

This is fixed now.

[DanT]

thanks so much @