Home » Archived » Eclipse SmartHome » Device configuration system
|
| Re: Device configuration system [message #1738120 is a reply to message #1738116] |
Fri, 15 July 2016 20:35   |
 Lukasz Dywicki
Messages: 34
Registered: July 2009 |
Member |
|
|
Hey Chris,
I been thinking about that some time ago, cause I've found current things definition hard to use for a device database. It is possible, but not straight forward. For example when device uses limited set of channel types but with different configurations yet constant channel identifiers (such modbus, bacnet, partialy ebus), thing definition becomes just a template. Fairly limited in it's scope. Variable part is then just device identifier and bridge association, and - as you pointed - configuration.
[Updated on: Fri, 15 July 2016 20:36] Report message to a moderator |
|
| | | | |
| Re: Device configuration system [message #1739523 is a reply to message #1739444] |
Tue, 02 August 2016 16:30 |
Karel Goderis
Messages: 198
Registered: March 2014 |
Senior Member |
|
|
Kai Kreuzer wrote on Mon, 01 August 2016 11:06Quote:@kai, can you comment on what your thoughts are for this please.
I don't have any. To give some background on my statements like "was only meant to be a configuration of the handler", you can check out http://docs.openhab.org/tutorials/migration#understanding-things - from this, it should be clear that what the Things are is just a transformed version of the old binding configurations of openHAB 1 and they were always only meant to configure the binding (in ESH therefore the handler) to work and not the remote device itself.
I do not have any clear picture on how device management could fit in best; I only feel that it might be dangerous if we continue to mix these two topics.
I am open for any good suggestions.
Taking it forward from https://github.com/eclipse/smarthome/issues/588#issuecomment-236613419, I never saw that text you wrote (I got started on the the original schema's produced in the early days of this forum), but maybe my thinking changed over time as I got to implement bindings. I really thought of Things as being a runtime equivalent of a real-world thing - and maybe I was not alone on that route. For me the real-world "hurdle" I tried to solve is that part of the configuration is not know at configuration time, but only when the binding is running, e.g. some configuration info is fixed, and can be put in a DSL file, but some pieces of the binding can only be "parameterised" based on the actual real-world thing discovered. By that I do not necessarily mean the configuration of the device itself, but rather the "tuning" of the behaviour of the binding in function of the hardware it finally sees. That being said....
Referring to Kai Kreuzer
Why this? You can define your Thing dynamically without requiring a thing type. Ok right now this won't work with DSL defined things; but would it be all fine if we allowed in-memory changes to the channels without persisting them, just as we did for the properties? The problem with that might be that we also would not persist any potential configuration of such channels; so this would need to be recontructed by the binding as well on the next start. If this is fine for everyone, I would suggest to open a new issue to do something similar like #1682 for the updateThing() call within the handler.
I am ok with the proposal to go ahead with how you describe it here
|
|
|
| Re: Device configuration system [message #1739541 is a reply to message #1739523] |
Tue, 02 August 2016 18:25 |
Chris Jackson
Messages: 256
Registered: December 2013 |
Senior Member |
|
|
Also continuing the previous discussions...
Quote:
On the other side, if we stick to the original ESH concept, where the device is up and running we have a natural split: configuration is done with the tools the device provides (like you connect a router to a network and configure the router before using it with its own config UI) and usage of the device is done within ESH.
Personally, I really don't think this is acceptable. For ZWave at least, there is no general configuration tool provided by the device (or its supplier) - there are hundreds of manufacturers of devices and most provide no system for configuration.
I don't think that people want to have to run multiple tools to configure each of their systems - one for zwave, one for max, one for zigbee, hue... Each time requires the user to stop ESH to allow them to configure the system - I really don't think this is what people want (well, at least this user  ).
Quote:
Which one would you like to configure? Each of it? Only a part of it? You may very easily end up in a configuration hell.
In ZWave there are nearly 400 devices and they are updated often - most of the device configuration is statically defined in the XML, although I do use a combination of XML and dynamic definitions depending on the device. Certainly this is an issue, but I don't think the maintenance of devices is something that should stop the framework from providing services - this is a separate issue (IMHO).
ZWave makes extensive use of the current config definitions, and I think we can define a suitable system around the current implementation....
So...
Quote:
Maybe one idea for discussion: Since we are just about to introduce new channel types, would it be an option to cover device management functionality by "admin" channels
One problem I see with this is config descriptions would then be attached to a channel rather than a thing, so we could have 20 to 50 extra channels, and 20 to 50 extra config descriptions, each with a single parameter, which seems a bit excessive. Maybe there's something that can be done to resolve these issues.
Another possibility is to leave the existing definition, but add a flag to the config description that specified that the parameter is a transient, or dynamic parameter. This could mean that ESH doesn't store the configuration state/value, but leaves it up to the binding to retrieve the data from the device, and provide it to the system in a similar way to the ConfigStatus. Something like this would work quite well for ZWave as there would be no synchronisation issue between ESH config parameter store, and the actual device state. This would also solve the issue with trying to save parameters to things that aren't managed...
|
|
|
| Re: Device configuration system [message #1739914 is a reply to message #1739541] |
Fri, 05 August 2016 16:32 |
Kai Kreuzer
Messages: 673
Registered: December 2011 |
Senior Member |
|
|
Quote:I am ok with the proposal to go ahead with how you describe it here
I have created https://github.com/eclipse/smarthome/issues/1977 for it.
Quote:I don't think that people want to have to run multiple tools to configure each of their systems
You should note that Z-Wave and other USB-dongle based radio systems have quite a special stand here. If I look at my (favorite) KNX system, it is absolutely obvious that you use the ETS software to set it up and configure it and there is anyhow no other way to do it. I also use the Philips hue app to define the IP address of my hue gateway and to pair and name my bulbs. I use the LIFX app to pass the wifi credentials to my LIFX bulbs to hook it up to the network and I do the same for all WeMo devices. The digitalSTROM system is anyhow setup by an electrician and the Sonos speaker is setup through the Sonos app. If you want to replace all those apps and offer the same functionality through ESH/OH, you would probably have 100 times more effort than today, but only duplicating functionality that others (the different apps from the manufacturer) already have done (and probably better than you). What made openHAB successful was that you combine all those systems and devices for operatiion, not to have a uniform UI for administration.
Ok, but having said this, I nonetheless see the requirement for certain bindings and also solutions built on ESH, so we should find a way to accomodate that.
Quote:One problem I see with this is config descriptions would then be attached to a channel rather than a thing
If we used channels, we would not necessarily need config descriptions - we would have state descriptions on those.
Quote:Another possibility is to leave the existing definition, but add a flag to the config description that specified that the parameter is a transient, or dynamic parameter.
This would still leave it fuzzy (as today) about whether a parameter is meant for the handler or for the device. Take the IP address of a hue gateway as an example: This parameter configures the handler in a way that it finds the gateway in order to talk to it. Interpreting it as a "device configuration" would mean that changing it means that you are telling the gateway that it should change its internal settings and now listen on a different IP address - it is a completely different functionality and we must not mix up those things.
Besides using configs or channels, we can also think about introducing something completely new in the things. We might also want to have a look at existing device management standards like OMA DM or similar.
|
|
|
| Re: Device configuration system [message #1739924 is a reply to message #1739914] |
Fri, 05 August 2016 17:20 |
Chris Jackson
Messages: 256
Registered: December 2013 |
Senior Member |
|
|
Quote:
If I look at my (favorite) KNX system, it is absolutely obvious that you use the ETS software to set it up and configure it and there is anyhow no other way to do it.
I wasn't trying to say that no systems use other software, simply that I think the system should provide a mechanism within the framework to support this (but you got that I guess  ).
Quote:
If we used channels, we would not necessarily need config descriptions - we would have state descriptions on those.
I doubt that would work - we would need to increase the state description functionality to include the same mechanisms as config descriptions such as multiple selection, and no doubt a number of other things that were added a long time back to support device configuration in ZWave... It would seem a bit strange if we then have two mechanisms doing the same thing....
Quote:
This would still leave it fuzzy (as today) about whether a parameter is meant for the handler or for the device.
I'm not sure I agree. The binding author can decide if this is a local, or remote configuration - they are in control, and they can define how the configuration is managed. I don't think your example of the IP address should in any way be considered a device configuration - it's clearly configuring the thing handler, and I'm sure that the binding author would understand this and not change it to a device configuration.
In any case, from a framework perspective all we are doing is setting a flag that tells the framework if it's local or remote - the user doesn't see this difference. A binding author can still (incorrectly!) define the IP configuration to somehow change the gateway address if they want even in the current system - all we're doing is letting the framework know how to handle the configuration.
Anyway, it was just an idea to try and re-use the existing system as much as possible (which I personally think works reasonably well) but to solve the issues that we currently have...
Quote:
Besides using configs or channels, we can also think about introducing something completely new in the things. We might also want to have a look at existing device management standards like OMA DM or similar.
I just wonder what people actually need though? Yes, we could add support for complex configuration systems, and maybe this is a good idea, and maybe some bindings might need it - but maybe not. So far at least, I've been happy enough with the config descriptions and I would suggest that we implement something based on this for starters at least, otherwise it will probably be a long time before something is implemented.
|
|
|
| Re: Device configuration system [message #1739927 is a reply to message #1739914] |
Fri, 05 August 2016 17:49 |
Karel Goderis
Messages: 198
Registered: March 2014 |
Senior Member |
|
|
Kai Kreuzer wrote on Fri, 05 August 2016 12:32
You should note that Z-Wave and other USB-dongle based radio systems have quite a special stand here. If I look at my (favorite) KNX system, it is absolutely obvious that you use the ETS software to set it up and configure it and there is anyhow no other way to do it. I also use the Philips hue app to define the IP address of my hue gateway and to pair and name my bulbs. I use the LIFX app to pass the wifi credentials to my LIFX bulbs to hook it up to the network and I do the same for all WeMo devices. The digitalSTROM system is anyhow setup by an electrician and the Sonos speaker is setup through the Sonos app. If you want to replace all those apps and offer the same functionality through ESH/OH, you would probably have 100 times more effort than today, but only duplicating functionality that others (the different apps from the manufacturer) already have done (and probably better than you). What made openHAB successful was that you combine all those systems and devices for operatiion, not to have a uniform UI for administration.
I think what you say is very much true.
However
For example, the Helios IP Videophone I can administer through the web interface the thing is running, but, at runtime in ESH, I would like to steer the behaviour of the binding based on the actual hardware, therefore "configure" the Thing in ESH. I have no intention at all to configure the remote device through ESH, as you correctly point out, that does not make sense
[Btw, I almost got to configuring KNX through openHAB but I ran into bus load problems in my setup, and thus unable to complete the effort - the KNX protocol is *ahum* wonderful)]
|
|
|
| Re: Device configuration system [message #1740111 is a reply to message #1739924] |
Tue, 09 August 2016 11:24 |
|
Chris Jackson wrote on Fri, 05 August 2016 17:20I think the system should provide a mechanism within the framework to support this
Me, too. For Sonos, Hue, etc. we have separate apps to configure this separate systems and we can add the devices to ESH to use it. But I don't see any reason why we should not be able to configure that stuff also within the ESH framework. We don't need to do it better then the native apps, but the framework should support it, so if a binding developer would like to do it, he should be able to do it.
For other stuff like ZWave, EnOcean, ZigBee (I assume), there is not such an app that could handle all that stuff (I could be wrong). There are apps from different systems, but then you support only devices for one manufacturer etc.
So, it would be best if we can find a way to do it right.
I don't know if a user needs to know / care about if he configure the thing / device or the thing handler (at least I assume he don't in every case). Let's give me one example:
There are roller shutters that could be configured with values like "max runtime up", "max runtime down" etc. If that values are configured, you can send a percent value to the roller shutter (instead of simple up / down / stop commands) and the shutter drives to the correct position.
There are roller shutter that only support up / down / stop commands. For that roller shutters the thing handler could consume the max runtime configuration and provide the same mechanism "drive to percent". The mechanism e.g. send up and stop after a timeout of x ms could then be implemented in the handler.
If the device supports already "drive to position" that mechanism should be used, as it is more accurate (no send message delay etc.).
I have already done it for roller shutters using the current configuration mechanism, so you don't see any difference as an user point of view.
The example "IP address of the bridge" is surely valid, but a correct description "set the IP address used by the bridge" vs. "set the IP address that should be set to the bridge" (native speakers could give a better one) could (IMHO) be sufficient to differ between handler / thing config. Isn't it?
|
|
|
Goto Forum:
Current Time: Wed Apr 24 20:00:59 GMT 2024
Powered by FUDForum. Page generated in 0.03775 seconds |
] 
Search
Help
Register
Login
Home
