For standard device types the category_num attribute is not set

Plugins & Plugin Development openLuup
#1

Hi AK,

As of a few releases I noticed that the category_num attribute is not set if you create a child device in your plugin using luup.chdev.append. For example see a Temperature of Humidity device for Netatmo or DarkSky Weather. You will see that the category_num attribute is zero where it should be 16 or 17 respectively. I did notice that none of the Vera’s standard device files like D_TemperatureSensor1.xml or D_HumiditySensor1.xml have the category_num specified and this is probably why. It seems Vera just sets the category_num attribute based on the device type.

What is your advice? In ALTUI it does not matter, but Imperihome is now dropping these standard device types unless I set the category_num manually.

Cheers Rene

openLuup: Version Log
#2

Just to chime in, I have long noted the inconsistencies on Vera in handling category and subcategory, both, and so I make a practice of setting them myself as part of the first-time initialization of the device, whatever it may be, even if it’s my own type and I specify the category and subcategory in the device file.

1 Like
#3

Hi rigpapa,

I can do that for my own plugins, but not for others.

Cheers Rene

#4

Well, yes, another Luup / Vera API inconsistency.

Neither luup.create_device() nor luup.chdev.append() have parameters to set attributes… they don’t even have the same parameter list. In openLuup, I have a separate table-driven create_device() function which can set anything.

To do this properly requires a built-in database of device types / categories / sub-categories, which is the sort of thing I’ve strenuously tried to avoid. However, openLuup does, in fact, have a small and little-used database which allows a device to be created simply from its device type (something which works in Vera, but AltUI has no interface to do this.)

I could extend said database to do what you need. How extensive does it actually need to be? At the moment it looks like this…


local mcv  = "urn:schemas-micasaverde-com:device:"
local upnp = "urn:schemas-upnp-org:device:"

local categories_lookup =             -- info about device types and categories
{
  {id =  1, name = "Interface",          type = mcv  .. "HomeAutomationGateway:1"},
  {id =  2, name = "Dimmable Switch",    type = upnp .. "DimmableLight:1"},  
  {id =  3, name = "On/Off Switch",      type = upnp .. "BinaryLight:1"},
  {id =  4, name = "Sensor",             type = mcv  .. "DoorSensor:1"},
  {id =  5, name = "HVAC",               type = upnp .. "HVAC_ZoneThermostat:1"}, 
  {id =  6, name = "Camera",             type = upnp .. "DigitalSecurityCamera:1"},  
  {id =  6, name = "Camera",             type = upnp .. "DigitalSecurityCamera:2"},  
  {id =  7, name = "Door Lock",          type = mcv  .. "DoorLock:1"},
  {id =  8, name = "Window Covering",    type = mcv  .. "WindowCovering:1"},
  {id =  9, name = "Remote Control",     type = mcv  .. "RemoteControl:1"}, 
  {id = 10, name = "IR Transmitter",     type = mcv  .. "IrTransmitter:1"}, 
  {id = 11, name = "Generic I/O",        type = mcv  .. "GenericIO:1"},
  {id = 12, name = "Generic Sensor",     type = mcv  .. "GenericSensor:1"},
  {id = 13, name = "Serial Port",        type =         "urn:micasaverde-org:device:SerialPort:1"},  -- yes, it really IS different       
  {id = 14, name = "Scene Controller",   type = mcv  .. "SceneController:1"},
  {id = 15, name = "A/V",                type = mcv  .. "avmisc:1"},
  {id = 16, name = "Humidity Sensor",    type = mcv  .. "HumiditySensor:1"},
  {id = 17, name = "Temperature Sensor", type = mcv  .. "TemperatureSensor:1"},
  {id = 18, name = "Light Sensor",       type = mcv  .. "LightSensor:1"},
  {id = 19, name = "Z-Wave Interface",   type = mcv  .. "ZWaveNetwork:1"},
  {id = 20, name = "Insteon Interface",  type = mcv  .. "InsteonNetwork:1"},
  {id = 21, name = "Power Meter",        type = mcv  .. "PowerMeter:1"},
  {id = 22, name = "Alarm Panel",        type = mcv  .. "AlarmPanel:1"},
  {id = 23, name = "Alarm Partition",    type = mcv  .. "AlarmPartition:1"},
  {id = 23, name = "Alarm Partition",    type = mcv  .. "AlarmPartition:2"},
  {id = 24, name = "Siren",              type = mcv  .. "Siren:1"},
--[[
also:  --TODO: find out device types for new categories
  25 	Weather 		
  26 	Philips Controller 		
  27 	Appliance 		
  28 	UV Sensor 		
  29 	Mouse Trap 		
  30 	Doorbell 		
  31 	Keypad
]]
}

Amusing to see yet another mistake in the device schema name for serial port device!

1 Like
#5

Thanks AK,

Yes the naming is sure lacking consistency. For device 28, UV sensor the device type is actually a LightSensor but with D_UVSensor1.json as the device json. In DarkSky I set that attribute after creating the child device and have to give the Vera another reload for it to take. O joy.

I can also have a look at my Imperihome driver and use the service type rather than the id, but that requires more processing. O well, it is on a PI in a separate thread from the LUUP one so should not be a biggy.

Cheers Rene

#6

Of course, I’m just acknowledging your finding.

@akbooer, if one passes the statevariables parameter to create_device or the parameters parameter for luup.chdev.append() with a name/value pair without a service ID, Luup interprets that as an attribute and sets it accordingly. At least, I’ve been successful doing that in Switchboard. It’s documented explicitly for create_device(), and works the same for chdev.append().

1 Like
#7

Hi rigpap,

Well spotted! That goes into my toolbox :smiley:

Cheers Rene

1 Like
#8

Ah, yes. Good spot, indeed. openLuup implements that behaviour for luup.variable_get/set() but I hadn’t thought of using that in the context of create_device(). That documentation is new (the page has been updated recently.)

#9

Yeah, looks like it crept in quietly in early 2017. I have no idea if that’s just a doc change, or it coincides with new work in firmware added around that time. And I actually never use create_device, but I’m a big consumer of chdev.append, where that feature isn’t documented. I just happened upon that text one day and noted that the structure of the parameter value was the same as its analogue in chdev.append and decided to try it to see if worked there as well, and sure enough, worked a treat.

Does this mirror a Vera behavior that isn’t documented? If so, then I declare it’s New Information Day on these forums, and everybody wins a prize–this one would be mine!

#10

Hi AK,

So it would not work on openLuup like this today?

Cheers Rene

#11

My source was here…
http://wiki.micasaverde.com/index.php/Luup_Requests#variableset

…and that page has been around since at least 2013. If the data request did this, then I figured that the Luup request did so too.

#12

Just checked chdev and, no, it doesn’t use luup.variable_set(), since the device may not yet exist. However, with a tiny change it could be made to exhibit that behaviour.

I’ll put it in the next release.

To your original question, though, nothing should have changed regarding the category numbers.

#13

Sorry, I lied! luup.variable_get/set() does NOT do this. Only the variableget/set requests via HTTP contain the necessary code:

  if (not p.serviceId) and p.Variable then
    luup.attr_set (p.Variable, p.Value, devNo)
  else
    luup.variable_set (p.serviceId, p.Variable, p.Value or '', devNo) 
  end

I’ll move that into the appropriate places to make the behaviour consistent.