Possible to add a subcategory_num if that field is not present?

Hi

Is it possible to add a subcategory_num field and value for a device that doesn’t appear to have a subcategory_num already ?

In the web GUI under the devices Advanced - Params tab I see no subcategory_num at all.

My Philips Hue lights in Vera via the AltHue plugin, none of them appear to have a subcategory_num and this is causing import issues with the 3rd Party dashboard app “Home Remote”

Thanks

OK this seems to work in the Apps - Develop Apps - Test Luup code (Lua)

luup.attr_set('subcategory_num', 4, 442)

4 is the subcategory_num and 442 is the device number you want to set it on.

I can now see the subcategory_num field in the devices Advanced - Params tab and it also now apprears in SDATA as “subcategory”: 4

Just a side-note of caution here, since I see it has come up a few times:

sdata is really to be avoided if you’re intending to do any kind of integration or bridge. It has a fatal flaw: the “shortcodes” are not qualified with a service ID, so if a device has two different services that happen to use the same shortcode, one will overwrite the other in sdata (only one instance of each shortcode is injected), and that’s not deterministic. This creates problems for devices like thermostats, particularly dual-setpoint thermostats: there are two setpoint services active on the device (one for heating, one for cooling), but the shortcode for each is setpoint and you only see it one time in sdata, and whether it’s heating or cooling is random (whoever writes last wins). This is why pyvera, which is used by Hass for its bridge component, is such a mess.

Using user_data for an initial query followed by status queries is the way to go. These requests also can take dataversion and loadtime parameters, so you can do incremental updates (only changed states/devices) with long-polling, and it’s fairly efficient in most cases.

So, not sure what you’re using sdata for, but there be monsters…

I don’t know to be honest, its Bill at the Home Remote who has done the Vera integration and I don’t know the ins and outs of how he has done it ?

If I have problems with Vera devices not behaving as I expect in the Home Remote desktop designer software or the Android dashboard app, he always asks me to check that devices output in the Vera SDATA stream.

If he’s using that for dashboard integration, it’s eventually going to fail him, and it’s less efficient than it could be. He should, as I suggested, using an initial user_data query (to get the full device information for all devices), and then status queries after with incremental updates. It will improve the responsiveness of his app and, more importantly, give him correct data.

OK I will mention this to him and link him to your comments.

See what he says ?

Thanks

This is the exact problem I’m having with The Home Remote, thought it was a bug

My thermostat is a basic Z-Wave one with just a set point for heat.

Secure SRT322

@rigpapa Thanks for your suggestions. I was originally using a combination of both user_data & status in earlier versions of the Home Remote. The 1st 4 years of this product were actually using status. It wasn’t until the version 3 release last December that I switched to sdata. I found sdata to be quite a bit more efficient so that was the main reason for the change.

There are a couple things I’d like further clarification if you don’t mind.

How is sdata less efficient than status? From my experience, sdata has been far more efficient than status. Both sdata & status accept the loadtime & dataversion parameters. Since there is less data in sdata it changes less often. Now, my calls can actually sit & wait 60 seconds until something changes. Whereas with status it seemed that something was always changing every few seconds. Often variables I didn’t care about. During runtime it’d have to make quite a few more data_request calls than sdata would.

This is not true, at least for newer systems. There are both heat & cool shortcodes in the sdata. Believe me, that would have been a huge deal-breaker if I couldn’t monitor both the heating & cooling setpoints:) Both heat & cool exist in the majority of my thermostat integrations that use sdata. Again, maybe originally they didn’t exist but they are definitely there now.

Hi Bill, isnt the bug that I reported in the home remote forum the exact issue @rigpapa is explaining? I was seeing the cool setpoint when the thermostat was set to heat. But other times it was showing the correct heat setpoint, there was no pattern.

It’s possible they’ve fixed this issue; I’ve long abandoned sdata for my own dashboards and other integrations, so I don’t use it and any fix/workaround would not come up on my radar. Nonetheless, it is the case that an overlapping shortcode name between two services will create a collision, unless they start hard-coding exceptions (a famous Vera approach and if, as you say, this has changed, it’s likely such a one-off–the UI is rife with hard-coded exceptions for thermostats especially). I favor the more specific, but to each his own.

@rigpapa do you think the setpoint issue with sdata may be also present when having a thermostat set to just heat or cool? I am seeing cool setpoints for my thermostat in home remote when its set to heat, but it randomly seems to happen.

Any time two services use the same shortcode, the collision will occur (unless, of course, Vera hacks an exception into Luup for that particular service).

I just checked an sdata with AVT, and sure enough, there are new “heatsp” and “coolsp” shortcodes that are not defined by the services that are used, so it appears Vera has made a special-case/on-the-fly modification for thermostats (or these services in particular). As I said, that’s no surprise, since they have historically used a large number of hard-coded exceptions for thermostats in the UI.

However, I have another plugin with overlapping shortcode definitions in services, and those are still showing the collision problem endemic to the way they define/handle shortcodes and sdata. This may not be an issue for @bill_v; I don’t know how he handles plugin device UIs (i.e. for non-Vera-defined device types).

I have also started with The Home Remote app as a replacement of Imperihome. So far it goes very well thanks to the input and support of @bill_v and @cw-kid.
Now I’m also facing some challenges that have to do with this sdata.
I have adapted some virtual sensors and even “real” sensors with some extra variables. For example rainsensor with a variable “rainYesterday” that I calculate via Lua code and then write to the rainsensor every day around midnight. But this variable is not showing up in the sdata ouput.
Any way or workaround to get these data in The Home Remote app ?