Home » Archived » Eclipse SmartHome » Thoughts on a configuration interface(Configuration interface)
| Thoughts on a configuration interface [message #1220728] |
Fri, 13 December 2013 10:13  |
 Chris Jackson
Messages: 256
Registered: December 2013 |
Senior Member |
|
|
I thought I'd present my thoughts on a configuration interface for SmartHome. This was originally posted to the openHAB forum last week, but is better suited to this forum.... Unfortunately since it's (currently) not possible to attach files to this forum, the attachment needs to be read from the openHAB mailing list (ok, so I also can't post links to sites other than Eclipse.org, so please just look at the openHAB google group list. If someone can add permissions for attachments, that would be good.
The first question is what I mean by this. This is an interface within the java definition - not a user interface or whatever, but a software interface that would allow a binding to describe its internal configuration, and a user interface to receive this data and present it to the user. It should be generic so that it can be used by any binding, and self describing so that the user interface doesn't need to know anything else about the binding, thus avoid customising UIs for different bindings. It wouldn't be a requirement for a binding to support this, but it could certainly make complex bindings easier for the user to work with. It also provides a mechanism, other than through log files, for a binding to return status information etc (a list of unknown/unattached devices etc) which again I feel is very useful.
This was discussed briefly in issue 420 (code.google.com/p/openhab/issues/detail?id=420), and since then I've implemented a prototype interface within the zWave binding. Without this, zWave users need to use a third party software package to configure the network. This needs a few tweaks (from lessons learnt) and ultimately I would like to see such an interface implemented within the openHAB core.
I'd appreciate anyone interested in this taking a look at the attachment and providing your feedback. Any comments are appreciated - if there's better ways to do this, then I'd love to hear them  I'm quite keen to move this forward if it's of interest to the community, and I again note that the only necessary part of the core is the interface definition. While I would of course implement this in HABmin, any other interface that others wanted to support could easily be supported instead of, or alongside other implementations.
Cheers
Chris
|
|
| | |
| Re: Thoughts on a configuration interface [message #1232384 is a reply to message #1224796] |
Thu, 16 January 2014 20:37  |
Kai Kreuzer
Messages: 673
Registered: December 2011 |
Senior Member |
|
|
Werner, Thanks for the hint on java-config. Looking at it, it seems a bit too "enterprisy" and focussing on bigger setups of applications.
Chris, I meanwhile had a closer look at the XML files that you have defined for HABmin. For the pure configuration aspects, the content looks pretty similar to what OSGi MetaTypes can achieve. The only missing feature for the moment seems to be constraints on the values like min and max (which you use).
Given that the Configuration Admin service is a useful thing as it also takes care of persisting any settings, I think MetaType can indeed be the way to go. We could add some "SmartHome" extension to it, which bring things like min/max and other properties that we might think are useful to nicely describe the configuration, so that UIs can make use of this information.
Another positive effect of using MetaType would be that it would nicely integrate with Eclipse Kura, which as well brings a graphical configuration tool based on OSGi MetaTypes.
What do you think?
Regards,
Kai
|
|
| |
| Re: Thoughts on a configuration interface [message #1250972 is a reply to message #1250673] |
Wed, 19 February 2014 19:52 |
Chris Jackson
Messages: 256
Registered: December 2013 |
Senior Member |
|
|
Hi Kai,
Just catching up on this a bit more (I was travelling again today).
I've had a look at the Device (DAL) spec - it looks interesting, but it's not doing the same thing as the configuration system is doing (from my quick look at least).
What I'd like to see, and what I think ESH needs is a (reasonably) rich configuration and status interface and of course it needs to account for the different types of configuration and status (eg the general config and item config you mention). This is currently done in HABmin, but there are some different requirements between the two I think...
Some configuration can be static (eg probably most of the general configuration - port numbers, refresh periods etc - most of the openhab.cfg file). This could probably be managed through a static XML file, or something similar, and the OSGi service would probably be ok for this.
However there is also the more dynamic data - and I don't think this fits with the MetaType. The zwave configuration is an example of this - it provides an interactive dynamic interface, allowing the user to get information about the status of devices, updates etc. This is not suited (I believe) to the OSGi due to persistence, and also I personally don't think it's rich enough.
Regarding your point about the XML files used in HABmin - the current XML files are not a 'final' solution by any means. This might be ok for the static content, but is clearly no use for the dynamic content.
Do you have an idea of when the ESH will be online and we'd be in a position to see a roadmap/plan for the future? I really think this is quite important to at least get such a roadmap started - I'd be really interested to see the direction this is planned to go and to contribute if that's possible.
Werner - is there an overview document for your interface/API that you can point at?
Cheers
Chris
|
|
| |
| Re: Thoughts on a configuration interface [message #1267298 is a reply to message #1266363] |
Sat, 08 March 2014 20:25 |
Chris Jackson
Messages: 256
Registered: December 2013 |
Senior Member |
|
|
Hi Kai,
I think it is difficult to define everything in a static way. For simple devices/items/things/?, yes, this might be possible. This was also my thinking when I put together the XML files some months ago, however as we now have a lot of experience with zwave, I can see this is not the end of the story....
For dynamic configuration, again using zwave as an example, not all zwave devices are born equally. They all support different command classes and have different sensor compliments, and different numbers of association groups, different endpoints, etc. So, we can't define this in a simple, static way as the UI will need to be a little different for each device (or thing?).
In the zwave binding, we have an XML 'database' of devices. This provides a configuration for each device - some of the data is used internally within the binding so that the binding knows how to do some parts of the configuration, and other parts are effectively passed across the configuration interface so that the GUI can properly represent the device.
The above shows that devices need dynamic settings, but the other part of the dynamic question is the values that can be set. Again, this needs to be dynamic - even for a simple device/item configuration. An example here is for some items in the current OH definition, we define an interface in the cfg file (eg owserver:box1.port=192.168.1.1), and then in the item definition we use this interface (ie box1). You don't want the user to have to remember these names, or even to type them in - they should be available as a dropdown list so there's no potential for mistakes.
The interface I originally proposed seems to work reasonably well, although with some lessons learnt I would probably add a few things. The interface is abstract, so UIs can do present the information however they like, but it's rich enough that we can give the user a nice UI. Given that we're going for a custom interface, I think it should be dynamic, and provide a rich feature set, otherwise we will not have a pleasant user experience.
I think Thomas is setting up a zwave system, so maybe he can show you what I mean using HABmin. Alternatively, I'd be happy to chat on Skype and somehow share my screen to show you how things currently look in HABmin...
Cheers
Chris
|
|
| |
| Re: Thoughts on a configuration interface [message #1327613 is a reply to message #1299015] |
Fri, 02 May 2014 08:41 |
Kai Kreuzer
Messages: 673
Registered: December 2011 |
Senior Member |
|
|
All,
Just a brief update after some further thinking and discussions.
In general, I think I now better understand Chris' remarks and concerns and the required consequences on configuration mechanisms.
So just to recap: I have revisited the idea to use OSGi DAL for both aspects (ThingConcept + Configuration Metadata), but it turns out that it is not what we are looking for due to the following reasons:
- The focus is clearly on the "device" notion with properties like firmware versions, manufacturer etc. In Eclipse SmartHome, we want to have a more general approach that can also cover cloud services etc.
- The spec does not clearly differentiate between configuration and behaviour of devices
- Its model with device properties on the one hand and device operations on the other hand is not really compatible with the item model concepts of Eclipse SmartHome
- It does not offer any concept for what we call "bridge", i.e. a kind of gateway to another "universe of things"
- It does not describe how to instantiate instances and their typical lifecycle.
- It does not define any generic configuration mechanisms and ways to declare meta-information
In common with it is the insight, that the Configuration Admin service is not the best thing to use for the configuration of things. As Chris pointed out correctly, there are settings that need to be changed in or by the device and storing all in ConfigAdmin duplicates things and introduces synchronization problems.
In consequence, the MetaType service cannot be used to describe configuration meta data either. Thus we have to come up with something similar, but something that is not tied to the ConfigAdmin service and OSGi services in general.
Our idea is to go for an XML description similar to what Chris' did in HABmin (e.g. https://github.com/cdjackson/HABmin/blob/master/openhab/owserver.xml), but to also allow other ways to provide meta-information, e.g. dynamically through code itself or through configuration classes with specific annotations.
One aspect that I would like to cover is that this description should be usable for all kinds of configurable stuff, not only for bindings (but e.g. also for persistence services, rule actions etc.). A more specific configuration for bindings would then simply make use of this.
Regards,
Kai
|
|
|
| Re: Thoughts on a configuration interface [message #1366527 is a reply to message #1327613] |
Mon, 19 May 2014 10:56 |
Chris Jackson
Messages: 256
Registered: December 2013 |
Senior Member |
|
|
Kai Kreuzer wrote on Fri, 02 May 2014 04:41
In general, I think I now better understand Chris' remarks and concerns and the required consequences on configuration mechanisms.
Great - is there any sort of spec that we can look at (maybe 'spec' is to strong a word - but something that we can comment on. As I said, the zwave interface has been running for a while now and it has brought some very useful experience - I'd like to be able to feed this into the discussion if possible?
Kai Kreuzer wrote on Fri, 02 May 2014 04:41
Our idea is to go for an XML description similar to what Chris' did in HABmin (e.g. github.com/cdjackson/HABmin/blob/master/openhab/owserver.xml), but to also allow other ways to provide meta-information, e.g. dynamically through code itself or through configuration classes with specific annotations.
Brilliant. I was also looking at using an annotation system but decided to hold off until ESH direction was clearer so this is great. Again, it would be nice if there was something to review?
Kai Kreuzer wrote on Fri, 02 May 2014 04:41
One aspect that I would like to cover is that this description should be usable for all kinds of configurable stuff, not only for bindings (but e.g. also for persistence services, rule actions etc.). A more specific configuration for bindings would then simply make use of this.
Yep - we agree again 
The interface I used for the zwave was designed to provide an abstraction of a 'user interface' - in theory allowing the openHAB end (nominally the binding) to decide what information would be presented and 'where' and the client side to be free to actually present the information however it wants. For your average binding, this can be a generic GUI - maybe more complex bindings might want to have a different UI and present the data with some additional knowledge, but the interface remains the same. As such, there should be nothing stopping other data from being sent although I've not tried to apply the model to other data types.
Now to throw something else into the mix....
Have you thought about asynchronous notifications? This is something I'm coming up with in HABmin and there are 2 use cases -:
- Configuration data (or device status) updates and we want to let the user know so we can update a device - this is directly linked to the configuration interface
- Something happens and we want to let the user know - some sort of notification not directly linked to the configuration of a device.
Some examples -:
Currently, I poll the zwave status information periodically. In HABmin the information is displayed in a tree, and I only poll visible items to avoid excess traffic. However, for the poor old RPi, this is still too much and an async system is definately better. So, this is just keeping the GUI in sync with the configuration data.
If a new device is found, we want to let the user know - this isn't directly linked to the config data, and we probably need to be able to send 'text notifications' rather than the config type information. This could allow the binding to provide feedback on the status of device inclusion for example.
For the above, I've thought about using the message bus - this is probably doable, but I think would be a kludge and we'd be better off designing in the ability for the system to let the user know about an update or notification in the administration and keeping it outside of the current systems...
Cheers
Chris
|
|
|
| Re: Thoughts on a configuration interface [message #1376618 is a reply to message #1366527] |
Fri, 23 May 2014 13:53 |
Kai Kreuzer
Messages: 673
Registered: December 2011 |
Senior Member |
|
|
Hi Chris,
Good to know that you agree to many of the statements above
Chris Jackson wrote on Mon, 19 May 2014 12:56Great - is there any sort of spec that we can look at (maybe 'spec' is to strong a word - but something that we can comment on.
It's still a bit early for it as it is in the middle of construction, but you can find a some very initial code in this fork: https://github.com/qivicon/smarthome/tree/master/bundles/config/org.eclipse.smarthome.config.core/src/main/java/org/eclipse/smarthome/config/core
Note that this is only the "general" configuration metadata mechanism and nothing specific to bindings yet.
The XML schema is then supposed to be included in specific binding / thing / services meta-info files.
We actually found that we probably won't be able to stay with JAXB for the parsing as it is not really working well with OSGi (i.e. including a schema and its generated object model in a different bundle), so we might have to go for another parsing mechanism.
Chris Jackson wrote on Mon, 19 May 2014 12:56
Have you thought about asynchronous notifications?
Yes, I think we will have many different "UI events" in the future and we need a channel to pass them on.
The REST API is imho not really the best place as to me, REST is somewhat incompatible with push notifications. I was actually thinking of introducing a SSE (server-side event, e.g. through https://github.com/jetty-project/jetty-eventsource-servlet) mechanism in the context of https://bugs.eclipse.org/bugs/show_bug.cgi?id=423552. This could also be used as a replacement for the current REST long-polling, i.e. the UI could simply receive an event that it needs to update the page and does not need to keep the request open all the time.
If we have such a mechanism, we would only have to agree on the different kinds of events that should be sent across it for the different use cases.
Does that meet your expectations? Would you maybe be interested in investigating this further?
Chris Jackson wrote on Mon, 19 May 2014 12:56
If a new device is found, we want to let the user know
For this special use case, we are actually working on a specific "thing inbox" service, where discovery mechanisms can put stuff into and it is then easy to "instantiate" a thing from an entry in the inbox. I will soon be able to share more about this idea.
Best regards,
Kai
|
|
|
| Re: Thoughts on a configuration interface [message #1376794 is a reply to message #1376618] |
Fri, 23 May 2014 15:32 |
Chris Jackson
Messages: 256
Registered: December 2013 |
Senior Member |
|
|
Kai Kreuzer wrote on Fri, 23 May 2014 09:53
Good to know that you agree to many of the statements above
I try not to always disagree
Kai Kreuzer wrote on Fri, 23 May 2014 09:53
Chris Jackson wrote on Mon, 19 May 2014 12:56Great - is there any sort of spec that we can look at (maybe 'spec' is to strong a word - but something that we can comment on.
It's still a bit early for it as it is in the middle of construction, but you can find a some very initial code in this fork:
Thanks - I'll take a look.
Kai Kreuzer wrote on Fri, 23 May 2014 09:53
We actually found that we probably won't be able to stay with JAXB for the parsing as it is not really working well with OSGi (i.e. including a schema and its generated object model in a different bundle), so we might have to go for another parsing mechanism.
Hmmm - I think when I first wrote the HABmin XML defs I came across problems here and moved to the XStream library which seems quite nice and allows reasonably well structured XML. I'm using this a lot to save configuration information etc in HABmin and also the zwave binding.
Kai Kreuzer wrote on Fri, 23 May 2014 09:53
Chris Jackson wrote on Mon, 19 May 2014 12:56
Have you thought about asynchronous notifications?
Yes, I think we will have many different "UI events" in the future and we need a channel to pass them on.
....
Does that meet your expectations? Would you maybe be interested in investigating this further?
I don't know about this, but I will take a look and if it looks good I'd be happy to see how it can be integrated - I'll let you know what I think.
Kai Kreuzer wrote on Fri, 23 May 2014 09:53
Chris Jackson wrote on Mon, 19 May 2014 12:56
If a new device is found, we want to let the user know
For this special use case, we are actually working on a specific "thing inbox" service, where discovery mechanisms can put stuff into and it is then easy to "instantiate" a thing from an entry in the inbox. I will soon be able to share more about this idea.
Ok - I'll look forward to that. I think I read that you are also thinking like me that new devices shouldn't be automatically included without at least a 'click' from the administrator? At the end of the day if this is handled separately that's fine just so long as there's a notification channel somewhere.
Cheers
Chris
|
|
| | | | | | |
| Re: Thoughts on a configuration interface [message #1434486 is a reply to message #1434143] |
Tue, 30 September 2014 06:39 |
Dennis Nobel
Messages: 166
Registered: September 2014 |
Senior Member |
|
|
Hi,
I started with a simple UI based on Angular JS and the Polymer Paper Elements that supports:
1) Simple control of items (no support for sitemaps so far)
2) Inbox view with options to approve, ignore and delete entries
3) Discovery service view, which allows to start a discovery scan
4) Binding view, which lists all installed bindings
5) Item view, which allows to manage items (add, remove)
6) Thing view, which allows to manage things (add, edit, remove, link to items)
I will contribute the UI, if this basic feature set is completed. But there will be a lot of work left, for example:
* Support for sitemaps and widgets
* Support for thing configuration based on parameter description
* Introduction of a push mechanism, if Eclipse SmartHome supports one
* UI improvements in general
* Support for extensibility
* Support for customizability
* Rule management
* ...
Regards
Dennis
|
|
|
Goto Forum:
Current Time: Thu Apr 18 21:45:12 GMT 2024
Powered by FUDForum. Page generated in 0.04238 seconds |
] 
Search
Help
Register
Login
Home
