Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse SmartHome » Thoughts on a configuration interface(Configuration interface)
Thoughts on a configuration interface [message #1220728] Fri, 13 December 2013 10:13 Go to next message
Chris Jackson is currently offline Chris JacksonFriend
Messages: 12
Registered: December 2013
Junior 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 Smile 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 #1224753 is a reply to message #1220728] Fri, 27 December 2013 17:36 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 85
Registered: December 2011
Member
Hi Chris,

I agree that we need some way to provide meta information about configuration possibilities in order to allow easy implementation of configuration UIs.
I do not want to base this on the current (openHAB) version of the bindings though as I first want to make some refactorings there; in general we need to distinguish between general configuration and the "bindingconfigs", which are the specific configurations for each item.
As mentioned before, I think in general the OSGi MetaType service could be a good fit for this requirement.
The upcoming OSGi DAL specification might also be an option (see https://github.com/osgi/design/blob/master/rfcs/rfc0196/rfc-0196-DeviceAbstractionLayer.pdf).
Let me first finish the initial code contribution and then I'll dive deeper into this topic - thanks for your patience!
Re: Thoughts on a configuration interface [message #1224796 is a reply to message #1224753] Fri, 27 December 2013 20:23 Go to previous messageGo to next message
Werner Keil is currently offline Werner KeilFriend
Messages: 1083
Registered: July 2009
Senior Member
Hi,

Since SmartHome is largely based on Java(SE) please have a look at this
GitHub project, too:
https://github.com/java-config?source=cc

It's an approach to a standardized configuration interface for Java. Should
become a JSR shortly (designated Spec Leads Oracle and Credit Suisse)

Services aim at OSGi and you'll notice in the POM it is supposed as Felix
OSGi bundle.

Please check out the Google Group
https://groups.google.com/forum/?hl=de#!forum/java-config and if there is
input on how this API could be used for SmartHome, share it there.
Until the JSR has an official number please note the API could be subject to
change at any time (including changes you or other members of the community
require;-)

Cheers,
Werner

"Kai Kreuzer" schrieb im Newsbeitrag news:l9kdrb$j9u$1@xxxxxxxxe.org...

Hi Chris,

I agree that we need some way to provide meta information about
configuration possibilities in order to allow easy implementation of
configuration UIs.
I do not want to base this on the current (openHAB) version of the bindings
though as I first want to make some refactorings there; in general we need
to distinguish between general configuration and the "bindingconfigs", which
are the specific configurations for each item.
As mentioned before, I think in general the OSGi MetaType service could be a
good fit for this requirement.
The upcoming OSGi DAL specification might also be an option (see
https://github.com/osgi/design/blob/master/rfcs/rfc0196/rfc-0196-DeviceAbstractionLayer.pdf).
Let me first finish the initial code contribution and then I'll dive deeper
into this topic - thanks for your patience!


---
Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv.
http://www.avast.com
Re: Thoughts on a configuration interface [message #1232384 is a reply to message #1224796] Thu, 16 January 2014 20:37 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 85
Registered: December 2011
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 #1250673 is a reply to message #1232384] Wed, 19 February 2014 13:25 Go to previous messageGo to next message
Chris Jackson is currently offline Chris JacksonFriend
Messages: 12
Registered: December 2013
Junior Member
Hi Kai,
I think I said in my document that there is a problem with using the OSGi config system (in my opinion). The problem is that the system persists the settings - this is not a good thing for a configuration GUI where you may be requesting certain actions etc to be done, since when the binding restarts, the persistence will resend these commands.

The persisting is fine (and even helpful) where we are using it for straight configuration data, but not so good when it is used for a person to interact with a backend...

I will take a look at the interface Werner sent out (thanks). If there is something out there that already does this, then I'm more than happy to use it, but I also think we shouldn't try and force what we need into an existing system if it doesn't fit. We'd just end up unhappy Smile

Cheers
Chris
Re: Thoughts on a configuration interface [message #1250972 is a reply to message #1250673] Wed, 19 February 2014 19:52 Go to previous messageGo to next message
Chris Jackson is currently offline Chris JacksonFriend
Messages: 12
Registered: December 2013
Junior 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 #1266363 is a reply to message #1250972] Fri, 07 March 2014 10:45 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 85
Registered: December 2011
Member
Hi Chris,

You are right, OSGi DAL does not seem to be appropriate as it leaves many configuration aspects undefined - this does not seem to be a focus of that RfC.

I meanwhile also came to the conclusion that MetaType is probably not capable of serving all our needs; especially as it is tightly bound to the ConfigurationAdmin service, which brings some overhead here and there.
So our current thinking is to introduce our own set of Java annotations that can be put on classes, which are used for "configuration objects". Although this is also a static structure, it should make us more flexible for specific requirements.

I am not completely sure though if I fully understood your dynamic configuration data requirements. Is your point that the DATA changes and thus does not fit with the automatic persistence through the ConfigAdmin (which would be solved with the current suggestion)? Or do you have cases, where the structure of the configuration changes and thus cannot be described in any static metadata format (then it is not clear to me how the structure could be described at all in order to create dynamic UIs on top)?

Regards,
Kai
Re: Thoughts on a configuration interface [message #1267298 is a reply to message #1266363] Sat, 08 March 2014 20:25 Go to previous messageGo to next message
Chris Jackson is currently offline Chris JacksonFriend
Messages: 12
Registered: December 2013
Junior 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 #1299015 is a reply to message #1267298] Wed, 16 April 2014 17:21 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 85
Registered: December 2011
Member
Chris, I think I now got your point about needing more dynamics. Or at least not having to statically define configurations in code, but to read actual configurations from descriptors, such as XML files. We will probably have to come up with a metadata for configurations that can be provided through different kinds of implementations.
Our current approach for configuration UIs is the thing concept of the other thread. What you call "binding interface config" would actually be the configuration of the "bridges". Our goal of this concept is to make the physical things visible in the configuration UI (as you add usb dongles or devices to your system). For the "things" we will need some "thing stereotype", which will be the equivalent to your device xml files (while I think that even XMLs can be too static).
One additional topic that we try to address is that you might actually need setup flows for certain devices. Think of the need of pressing a pairing button or to step through an OAuth web flow. This makes config UIs even more complicated.
I really have to do a deep dive into HABmin soon - you have indeed done amazing stuff there. For the start I would want to concentrate on the setup and binding configuration (not the rule, sitemap or charts parts for the moment). I didn't see a description about how the REST API exposes the binding and device XML information. Do you have any information on this?
Always keep in mind that one of my design goals is to have these things working without any local DSL files written (as Xtext should not be a mandatory part for the runtime in the future). So this is a constrained that HABmin so far did not have - not sure, what impact this will have on your design ideas.
Re: Thoughts on a configuration interface [message #1327613 is a reply to message #1299015] Fri, 02 May 2014 08:41 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 85
Registered: December 2011
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 Go to previous messageGo to next message
Chris Jackson is currently offline Chris JacksonFriend
Messages: 12
Registered: December 2013
Junior 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 Razz
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 -:


  1. 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
  2. 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 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 85
Registered: December 2011
Member
Hi Chris,

Good to know that you agree to many of the statements above Smile

Chris Jackson wrote on Mon, 19 May 2014 12:56
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.

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 Go to previous messageGo to next message
Chris Jackson is currently offline Chris JacksonFriend
Messages: 12
Registered: December 2013
Junior Member
Kai Kreuzer wrote on Fri, 23 May 2014 09:53

Good to know that you agree to many of the statements above Smile

I try not to always disagree Razz


Kai Kreuzer wrote on Fri, 23 May 2014 09:53

Chris Jackson wrote on Mon, 19 May 2014 12:56
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.

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 #1376803 is a reply to message #1376618] Fri, 23 May 2014 15:36 Go to previous messageGo to next message
Chris Jackson is currently offline Chris JacksonFriend
Messages: 12
Registered: December 2013
Junior Member
Kai Kreuzer wrote on Fri, 23 May 2014 09:53

https://bugs.eclipse.org/bugs/show_bug.cgi?id=423552.

Kai, FYI this seems to be an invalid bug?

Chris
Re: Thoughts on a configuration interface [message #1376805 is a reply to message #1376803] Fri, 23 May 2014 15:39 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 85
Registered: December 2011
Member
Remove the dot at the end of the link, then it works!
Re: Thoughts on a configuration interface [message #1384374 is a reply to message #1376805] Wed, 28 May 2014 21:14 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 85
Registered: December 2011
Member
Quote:
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.


XStream looks indeed quite nice. Which XML parser are you using with it (if I see it right, it comes with a choice of different parsers)? Did you come across any negative things that one should have in mind when evaluating it for XML config description files (within an OSGi context)?
Re: Thoughts on a configuration interface [message #1384669 is a reply to message #1384374] Fri, 30 May 2014 07:58 Go to previous messageGo to next message
Chris Jackson is currently offline Chris JacksonFriend
Messages: 12
Registered: December 2013
Junior Member
Kai Kreuzer wrote on Wed, 28 May 2014 17:14

XStream looks indeed quite nice. Which XML parser are you using with it (if I see it right, it comes with a choice of different parsers)? Did you come across any negative things that one should have in mind when evaluating it for XML config description files (within an OSGi context)?

I'm using the Stax driver - not sure now why I chose that or what the trade-offs were between them. I've not really had any issues with it and it certainly generates/consumes XML in a much friendlier way than the standard options.

Cheers
Chris
Re: Thoughts on a configuration interface [message #1432293 is a reply to message #1220728] Fri, 26 September 2014 23:18 Go to previous messageGo to next message
Marcel Verpaalen is currently offline Marcel VerpaalenFriend
Messages: 3
Registered: September 2014
Junior Member
hi Kai,

From this thread I see a lot of good idea's. I think the current discovery is a very good start.
But indeed it needs to be complemented by some sort of configuration possibility like Chris is having in Habmin. That way we can truly ditch the flurry of applications that come with each device for configuration and have ESH be the real center for all your Thing configuration.

As this was a post from some time ago, is there already some development done in this area in ESH?






Re: Thoughts on a configuration interface [message #1434143 is a reply to message #1432293] Mon, 29 September 2014 18:40 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 85
Registered: December 2011
Member
Hi Marcel,

What has happened meanwhile is that we introduced a configuration description framework including parsers etc., which is also implicitly used by the binding and thing descriptions. See https://github.com/eclipse/smarthome/blob/master/docs/sources/architecture/configuration.md for details.

Regarding the UI itself, there isn't much progress yet. The idea is to have these configs within https://bugs.eclipse.org/bugs/show_bug.cgi?id=440012, which Dennis picked up recently.

Regards,
Kai
Re: Thoughts on a configuration interface [message #1434486 is a reply to message #1434143] Tue, 30 September 2014 06:39 Go to previous message
Dennis Nobel is currently offline Dennis NobelFriend
Messages: 17
Registered: September 2014
Junior 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
Previous Topic:Flow for creating Things and ThingHandlers
Next Topic:Channel Attributes
Goto Forum:
  


Current Time: Wed Dec 17 20:01:42 GMT 2014

Powered by FUDForum. Page generated in 0.46128 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software