Home » Archived » Eclipse SmartHome » Channel Attributes(How to use Channel Attributes + syntax in .items)
| Channel Attributes [message #1426159] |
Thu, 18 September 2014 10:20  |
 Karel Goderis
Messages: 198
Registered: March 2014 |
Senior Member |
|
|
Hi,
In the Hue binding implementation I saw in the things.xml that a lastDimValue attribute is defined for some of the Channels. However, browsing through the code (a branch on the qivicon repo) I saw that it was not used anywhere (admittedly, before you shoot me, it was a *very* quick browsing  . Hence my questions:
1. when to assign an Attribute to a Thing and when to a Channel
2. how to define a boundary between a Thing and a Channel-with-a-lot-of-Attributes, e.g. complex channels could/should become ThingTypes of their own? Or do we relentlessly stick to the mantra that we represent real-life things in a top-down way. In some cases it is not clear what should be the Thing, and what should be the Channel. . For example, in KNX, is the Thing the remote device/actor and the Group Address is the Channel, or is the Group Address the Thing in itself, with a "Value" channel, and so forth
3. How to use Channel attributes in the code? in the ThingHandlers, dynamically, or is it intended only for Configuration purposes?
4. How are attributes defined in the .items ?
small note : in the ESH repo (think master branch even) the demo.items is still using the OH1. format
Karel
|
|
| |
| Re: Channel Attributes [message #1427447 is a reply to message #1426239] |
Sat, 20 September 2014 07:10  |
Karel Goderis
Messages: 198
Registered: March 2014 |
Senior Member |
|
|
Kai,
Will it be possible to assign Channels to Items, but with different Attributes defined for the Channel? I presume that Things will parameterised in .things, and that Channels will be parameterised in the .items directly. The short answer might be "of course", but then the questions pops up: how will ThingHandlers handle the fact that there are for example two channels with different parameters? Will each ThingHandler have to assume that such a situation might occur, and therefore in fact, has to traverse all Channels before updating the channel with a value, knowing that the value that is subject of the update might vary based on the parameters of the Channel?
I have a practical situation: the IRTrans binding in OH1.x relates to the IRTrans hardware, which is typically a remote device with an IP address, and in each device there are multiple leds for sending and receiving infrared commands. The binding sends commands to the device under the "manufacturer,ircommand" format, for example, "Samsung,poweron" (in the reverse direction, when an IR command is received, you get similar strings as the device has an on-board database of ir commands that it maps on a readable "manuf,command" format). On top of this, the binding configuration is as such that you can define wildcards for the led to use, the manufacturer name as well as the command, so that you can for example do "Samsung,*" to be notified when *any* key on the remote control of the Samsung device is pressed. That being said, how do you do this in OH2?
Option 1:
Thing = infrared device, attribute IP address
Channel_1 = Switch, with as parameters {led, manufacturer, infrared command} // Switch ON when {l,m,i} is matched when an IR command is received by the device
Channel_2 = String, with as parameters {led} // String {m,i} is send to the parameterized led, or String is updated with {m,i} when such an IR command is received by the device
Option 2:
Bridge = the infrared device with IP address
Thing = a {l,m,i} tuple
Channel_1 = Switch, no params, which will be triggered accordingly
Channel_2 = String that can be fed with value, and that will be send to the device if it matches with the {l,m,i} tuple of the Thing
Cfr the initial part of the post, you might have Items that relate to the same IR transmitter, but with a different wildcard pattern, e.g. an Item to capture the Samsung commands, another one to capture the TV STB commands,.... because you would typically have 1 IRTrans device per room, with one receiving led for the room, and one blaster led per device that needs to be controlled
K
|
|
| | |
| Re: Channel Attributes [message #1431895 is a reply to message #1427673] |
Fri, 26 September 2014 09:48 |
Kai Kreuzer
Messages: 673
Registered: December 2011 |
Senior Member |
|
|
Hi Karel,
Sorry for my delayed reply on this.
There is no simple answer and your IRTrans use case is a rather complex one.
In general, I would tend for option 2. The "things" were introduced as a mean to make it possible to have nice UI support for setup, so considering the IRTrans module being a bridge that gives you access to your devices like TV etc. makes sense.
Quote:So, if channel attributes are static and defined in a .things file, would it then be possible to define the "same" (as in : generated UUID is the same) Thing twice, but with differently parameterised Channels in the .things?
The first "U" in UUID stands for "unique", so there should never be two things with the same UUID. Nonetheless, there can be multiple things of the same thing type of course - and in theory, these could even use the same physical device, although this is not really the intention.
Quote:if all configurations are meant to be static and pre-defined in .things
I believe we might have to split up the configuration into a static part that can be defined in .things and a dynamic one that is read from the device, that can be changed during runtime and that is persisted by a central service (the ThingRegistry?). Do we also have to add a third type, the "non-editable" properties of a device, such as firmware version etc.? Any suggestion on how to name these different categories?
|
|
| |
| Re: Channel Attributes [message #1434163 is a reply to message #1431895] |
Mon, 29 September 2014 19:11 |
Marcel Verpaalen
Messages: 59
Registered: September 2014 |
Member |
|
|
Quote:
I believe we might have to split up the configuration into a static part that can be defined in .things and a dynamic one that is read from the device, that can be changed during runtime and that is persisted by a central service (the ThingRegistry?). Do we also have to add a third type, the "non-editable" properties of a device, such as firmware version etc.? Any suggestion on how to name these different categories?
As far as I see we have 3 categories
1) The Channels -> Something that the Thing outputs and is linked to an item
2) The Connection definition parameters -> Defines how to communicate with the Thing, and how to identify it. This would typically be defined by discovering the item
3) Parameters
All configuration that defines how an Thing is operating.
* Can be read-only (e.g. firmware version) or writable (e.g. device specific settings)
* Can be persisted or not. I would assume most would be persisted on the Thing itself and read during initialization of the binding
* Is part of a configuration group, as I assume this configuration you typically want to group. e.g. the informational parts vs e.g. the thermostat display settings (in maxcube binding)
I would think that you should be able to use and set these parameters in the rules as well.
[Updated on: Mon, 29 September 2014 22:53] Report message to a moderator |
|
|
| Re: Channel Attributes [message #1434478 is a reply to message #1434163] |
Tue, 30 September 2014 06:21 |
Dennis Nobel
Messages: 166
Registered: September 2014 |
Senior Member |
|
|
Marcel Verpaalen wrote on Mon, 29 September 2014 19:11
As far as I see we have 3 categories
1) The Channels -> Something that the Thing outputs and is linked to an item
2) The Connection definition parameters -> Defines how to communicate with the Thing, and how to identify it. This would typically be defined by discovering the item
3) Parameters
All configuration that defines how an Thing is operating.
* Can be read-only (e.g. firmware version) or writable (e.g. device specific settings)
* Can be persisted or not. I would assume most would be persisted on the Thing itself and read during initialization of the binding
* Is part of a configuration group, as I assume this configuration you typically want to group. e.g. the informational parts vs e.g. the thermostat display settings (in maxcube binding)
I would think that you should be able to use and set these parameters in the rules as well.
I also agree that we need to differentiate between configuration that can be set by the user and device parameters, that are fixed. But the latter one is no configuration parameter in my opinion. Because a configuration is by definition meant to be changed by the user. So a "non-editable" or "mutable" parameter makes no sense.
A firmware version, or any other property that is read from the device, i would just call property. So we may introduce a method named 'getProperties' that returns a map of properties. These properties must not be persisted, but the binding developer can decide, if they are initialized on binding startup or lazy when someone requests the parameters. So the ThingHandler might get a new method 'getProperties', too.
But I don`t see a reason why we should separate configuration parameters that define connection parameters from others lets say operating parameters. For me the thing identification could just be a single parameter in the configuration, that is mandatory.
Marcel Verpaalen wrote on Mon, 29 September 2014 19:11
I would think that you should be able to use and set these parameters in the rules as well.
Rules should be based on the logic item level, only. Things are only there for setup and configuration. If there is functionality of a device, that should be used in rules, it must be represented as channel, so that an item can be bound to it. But i would definitly not lift the thing concept up to the control and automation level.
[Updated on: Tue, 30 September 2014 06:25] Report message to a moderator |
|
|
| Re: Channel Attributes [message #1435416 is a reply to message #1434478] |
Wed, 01 October 2014 13:00 |
Karel Goderis
Messages: 198
Registered: March 2014 |
Senior Member |
|
|
mmh... I do not agree at 100% here. Some parameters are fixed, but need to be set by the user. This holds true for identifiers like IP addresses, or UUDN on upnp, that you need in order to "bootstrap" the interaction with the device and read out its parameters. In addition, one would/could define a set of parameters that need to be present in order to flag the Thing as ready for operations. Those parameters could be both fixed or variable, pre-defined in a DSL, or discovered. IMO, you have:
- Parameters that are fixed and pre-defined in a DSL, required for doing a minmal set-up and interaction with the device
- Parameters that are variable and populated by a discovery process, or not (e.g. pre-set by the user), and of which you can specify whether there value can be overwritten by the results from the discovery process
- Parameters that have to be populated in order to have a fully functional device, per requirement of the binding or alike
Also - and maybe this is not intended in the architecture - it would be great to have the equivalent of CNAME of DNS in the ThingRegistry, whereby you can have a Thing with a canonical easy to remember name refer to another Thing with all the cryptic ID's coming from a discovery process or alike. a 'shadow' Thing or 'symlinked' Thing, that you can alter equally, but that in itself does not hold any information or state but just a pointer to another "real" Thing.
|
|
|
| Re: Channel Attributes [message #1435635 is a reply to message #1434478] |
Wed, 01 October 2014 19:39 |
Marcel Verpaalen
Messages: 59
Registered: September 2014 |
Member |
|
|
Marcel Verpaalen wrote on Mon, 29 September 2014 19:11
I would think that you should be able to use and set these parameters in the rules as well.
Rules should be based on the logic item level, only. Things are only there for setup and configuration. If there is functionality of a device, that should be used in rules, it must be represented as channel, so that an item can be bound to it. But i would definitly not lift the thing concept up to the control and automation level.[/quote]
I understand our position. Let me bit elaborate on why I believe this should be possible, and the less confusing for the user.
I think in general we have as a user a good feeling of what a output of a device is looking like, hence for most of the channels it is pretty clear. e.g. taking the example of the weather binding, the channels are logical
(temperature, humidity, pressure). If I take another example, e.g. a security camera, the output channels are also very clear, e.g. the picture, the movement alarm, the current state. However can totally imagine we would like to have an a rule in place where we change some of the configuration parameters changing dependent on when we are at home or not, e.g. I would like modify my security settings for accessing the camera when I'm at home vs when I'm away. (e.g. when I'm at home, I would not like my neighbors to be able to see my camera feed, but when I'm away and the alarm is going I want the video stream to be wide open). These are the typical things that the device by itself does not offer, but where the whole home automation can bring very cool features by combining information from the various sources (in this case presence in relation to device configuration). Now, I would say that the above described case of 'user access' parameters would be very confusing to see as channels to most people.
Quote:
I also agree that we need to differentiate between configuration that can be set by the user and device parameters, that are fixed. But the latter one is no configuration parameter in my opinion. Because a configuration is by definition meant to be changed by the user. So a "non-editable" or "mutable" parameter makes no sense.
A firmware version, or any other property that is read from the device, i would just call property. So we may introduce a method named 'getProperties' that returns a map of properties. These properties must not be persisted, but the binding developer can decide, if they are initialized on binding startup or lazy when someone requests the parameters. So the ThingHandler might get a new method 'getProperties', too
Indeed I do agree that these things are conceptionally not a configuration. However, I think you agree that these properties are many times in relation to configuration parameters. Take my security camera again as example, you want to have the left space on the device next to the automatically override files boolean configuration. Maybe this could be fixed in the UI and have the getProperties nicely aligned with he config stuff, but it seemed more easy and aligned with userexperience to have readonly/mutable flag.
I think that most devices you take and look at their configuration utilities you will see a mixture of readonly fields mixed with writable fields in a given screen.
|
|
|
Goto Forum:
Current Time: Tue Apr 16 05:16:31 GMT 2024
Powered by FUDForum. Page generated in 0.16214 seconds |
] 
Search
Help
Register
Login
Home
