Home » Archived » Eclipse SmartHome » Multiple channels versus multiple channel types?
| Multiple channels versus multiple channel types? [message #1690579] |
Sun, 29 March 2015 11:20  |
 Chris Jackson
Messages: 256
Registered: December 2013 |
Senior Member |
|
|
I'm currently designing the updated zwave database (as per the other thread) and am wondering how best to handle the case where I have multiple switches in a thing...
I see there's two options -:
Specify two channels, each with the same channel-type, and then a single channel-type, or, specify two different thing-types...
To me, it should be the first - specify a single thing-type, but customise this in the channel definition -:
eg -:
<channels>
<channel id="dimmer1" typeId="dimmer">
<properties>
<property name="endpoint">1</property>
</properties>
</channel>
<channel id="dimmer2" typeId="dimmer">
<properties>
<property name="endpoint">2</property>
</properties>
</channel>
</channels>
<channel-type id="dimmer">
<item-type>Dimmer</item-type>
<label>Dimmer</label>
<description>Set the light level</description>
<category>Light</category>
</channel-type>
Is this how it's intended? I don't think the system currently supports the parameterisation of the channels? I see properties were recently added to things but I'm unclear it if covers channels? Also, while most of the configuration of the channel-type is the same for the two channels, it would be nice to provide a different label... Ideally, in my binding, I'd then see a combined list of properties for the channel, including information from the channel definition, and the channel-type, and if the same property existed in both places (eg label) it would be overridden by the channel definition.
The other option is to have two different channel-types, but then why are we separating the channel and channel-type if they are linked 1 to 1.
Have I missed something (probably  ), or how are others handling this situation?
|
|
| | | |
| Re: Multiple channels versus multiple channel types? [message #1690714 is a reply to message #1690648] |
Mon, 30 March 2015 18:21  |
Chris Jackson
Messages: 256
Registered: December 2013 |
Senior Member |
|
|
Hi Dennis,
In the old items system, we had the ability to add options to an item definition. In zwave, this might be things like the command class that this item is linked to, and the endpoint number, and possibly some other options like the sensor type or alarm level. I'm effectively looking for a way to add similar parameters to the channels...
Otherwise, I'd need to hard code this into the binding. Every zwave device is different (ok, not every one, but there's a lot of different implementations). I could maybe use the parameterisation at thing level to provide the information on the channel configuration, but this seems very wrong. The other way to do it might be to encode a string into the channel id to code in all this information, but again, this feels very wrong!
Again, this isn't binding specific information, or even thing specific - this is how the binding needs to be configured to talk to this single channel. Am I missing something maybe? How do you envisage that item configuration is done? Is it just mean to be that the binding knows the channel type 'switch1' uses command class=X, with endpoint 1, and 'switch 2' uses command class=Y with endpoint 2 - if so, I might need 20 different switch 'channel-types' which are all the same except for 2 parameters. There might be 5 different temperature 'channel-types' - again, all the same except the endpoint number changes. Then when a new device comes out, instead of updating the thing, I have to update the thing to add the new 'switch xx' with command class=A and endpoint 4 hardcoded into the code...
Is that how you see it's meant to be or do I miss something with how it's designed?
Chris
|
|
| | | | | | | |
| Re: Multiple channels versus multiple channel types? [message #1691164 is a reply to message #1691152] |
Thu, 02 April 2015 16:45 |
Chris Jackson
Messages: 256
Registered: December 2013 |
Senior Member |
|
|
Hi Dennis,
So, I can already have parameters inside channels? Great. So I can do something like this -:
<channel id="switch" typeId="switch">
<properties>
<property name="endpoint">1</property>
<property name="command_class">BINARY_SWITCH</property>
</properties>
</channel>
And then do I end up with a list or something in the channel?
Again, these parameters are not something a user will change. It is the parameterisation of the channel - it tells the BINDING what the configuration is and isn't something the user cares about at all. I've already given an example, so I'm not sure what else to do (obviously my example is not good?). It's also not associated with the device - the device might have 5 endpoints, and I need to link these to the channels somehow. As I think I said earlier, I could possibly add some sort of device level parameters that somehow link the device configuration back to the channels, but this seems the wrong way around. In the device configuration, we should configure the device (node ID, device type, manufacturer etc), and in the channel configuration, we should configure the channel (endpoint number etc) - at least that's what I think, but maybe I'm wrong?
Maybe I'm missing something, so I'll turn the question around - can you can tell me how the binding knows the difference between two light switches inside a device that has individually addressable endpoints without some sort of parameterisation to tell it what the endpoint is, and without hard coding the endpoint somehow? With zwave, there are literally hundreds of devices and I can't hard code all possible options into the binding, but maybe I'm missing how it's meant to work?
Chris
|
|
|
| Re: Multiple channels versus multiple channel types? [message #1691172 is a reply to message #1691164] |
Thu, 02 April 2015 19:12 |
Kai Kreuzer
Messages: 673
Registered: December 2011 |
Senior Member |
|
|
Hi Chris,
Ok, actually Dennis was right and what I suggested above was the wrong answer to your requirement. We are currently talking about different things, because we do not use the same vocabulary. When I referred to "parameters", I meant configuration parameters as in https://github.com/eclipse/smarthome/blob/master/docs/sources/architecture/configuration.md#example. These are meant to be changeable by the user in order to configure his personal instance of a thing, i.e. it means that these must be options that can be set on a device in order to behave differently. This is obviously not what you are after. The other thing are "properties" as in your XML example above. This is what we recently added on thing level, but which does NOT exist for channels (yet?). This is more or less static information that you can put in your thing descriptions and which is automatically added to the things. It is not meant to be changed by users and thus not evented.
> can you can tell me how the binding knows the difference between two light switches inside a device that has individually addressable endpoints
I would simply answer as Dennis: The channel id should be the clear identification. If you have device X with 2 switches with endpoints a and b, you would model Thing X with channel a and channel b.
What this answer probably misses is what you mean with "individually addressable endpoints" - could you help us understanding this bit? (sorry if we appear stupid and you explain it for the xth time, but that's life  )
Cheers,
Kai
|
|
|
| Re: Multiple channels versus multiple channel types? [message #1691181 is a reply to message #1691172] |
Thu, 02 April 2015 21:58 |
Chris Jackson
Messages: 256
Registered: December 2013 |
Senior Member |
|
|
Hi Kai,
A zwave device can have a number of 'endpoints'. This is like internal addresses - like a port in TCP - another instance of an internal 'thing'. There's no standardisation on these - so, a device might have a switch that uses endpoint 0, or a switch might use endpoint 1 and endpoint 2 (and/or 3 and 4 if we have a multi scene controller). Likewise for meters - we might have a switch that has 3 or 4 meters over different endpoints. Sensors are even worse - the multi_level_sensor class can employ multiple sensors in different endpoints, but each endpoint can support different, or the same sensor, so we end up with having to specify the endpoint, command class, and sensor type.......
If we don't have some sort of property to say what this configuration is for each channel, then I have to have some other way to tell the binding what the endpoint number is (along with other information such as the command_class, and sensor type etc).
Since there's no standardisation as such on how this all works in zwave - I need some way to link this information to the channel. If I use your concept that we just use the channel type, then I would need a huge number of channel types in zwave to link the different combination of endpoints, command class, sensor type etc. I think that with 180+ devices, I can't hardcode lots of channel options into the binding and then try and link them with the channel-type. Well, yes, it's technically possible, but I think really messy as there would be a lot of different options and it would be prone to error.
The other possibility is that I put the channel definitions into a different place in the database/thing definition, but that seems like a bodge to me (but the best of a number of other less desirable bodges).
Again, this is not user configurable information - I want to be able to specify this in the channel definitions and not have the user have to look at it (or adjust it!). If you've looked at the huge number of confused emails on the OH1 group list about these channel configurations (which are currently done in the binding strings) you'll understand why 
Chris
|
|
|
Goto Forum:
Current Time: Sat Apr 27 00:26:05 GMT 2024
Powered by FUDForum. Page generated in 0.04147 seconds |
] 
Search
Help
Register
Login
Home
