Home » Archived » Eclipse SmartHome » RfC: New Thing concept
RfC: New Thing concept [message #1266584] |
Fri, 07 March 2014 17:26 |
Kai Kreuzer Messages: 673 Registered: December 2011 |
Senior Member |
|
|
All, I would like share with you a proposal for a major refactoring of how bindings are implemented in order to solve a few issues we had in the past:
The Item concept in the Eclipse SmartHome framework is great to describe the functionality of different devices and services and to simply integrate and connect different types of those. However, when it comes to the representation, configuration and pairing of 'physical' devices, the Item concept does not fit. There is no direct information how many physical devices are connected to the framework and no common way to configure, pair or add them. Configuration is typically done inside the binding configs.
Instead of enriching the Item concept with meta data for physical devices, we propose to introduce a new concept in Eclipse SmartHome. The main entity of this new concept is called "Thing" (right, we are talking about the Internet of Things, aren't we?). A Thing is a physical device or a service that is connected to the Eclipse SmartHome framework. Things have Channels, which can be bound to Items. Moreover a Thing has a status (online, offline, etc.), meta properties (vendor, version, etc.) and a configuration. The configuration is managed through the OSGi ConfigurationAdmin. A Channel contains information about which Item type can be bound and contains a configuration, too.
Things are normally connected to the framework through some kind of peripheral like a USB stick or an IP gateway. We call this thing a Bridge. A Bridge contains or connects other Things.
All Things available in the framework are registered in the ThingRegistry. The ThingRegistry is managed, which means that there is a staging for Things: They are not automatically added and available, but they are only "proposed" by bindings and need to be approved (by the user or some other instance) in order to be added to the ThingRegistry. A Thing always belongs to one binding. Things can NOT be subclassed or implemented by bindings.
Instead, bindings work with Things by implementing ThingHandlers. A ThingHandler automatically receives command and update events, which are sent to Items bound to the channel of the Thing. Moreover the ThingHandler has access to the Thing and its Configuration. To simplify working with OSGi configuration admin, Dictionaries are automatically transformed into Java objects, which classes can be defined by the binding. Here is a class diagram, which shows the relation between these new concepts:
There are a few further changes that should be implicitly done:
- the binding configuration syntax in the item files is changed to JSON format, e.g.
Number temperature1 "Actual Temperature" {homematic = {channelId: "JEQ0626144:temperature", security: true } }
Number temperature2 "Target Temperature" {homematic = {channelId: "JEQ0626144:target"} }
- for all configurations (bridges, things, item2channel-binding) there exists a Java class with annotations that provide meta information (e.g. mandatory, descriptions, min/max values etc.) See also http://www.eclipse.org/forums/index.php/t/628353/
So what are the benefits of all this? Well, this:
- We have a concept for devices to enable auto-discovery and pairing features for bindings without interfering too much with the "abstracted" item concept.
- Information about required configuration is provided with bindings; this allows configuration GUIs like HABmin to dynamically render nice configuration pages.
- All configuration is persisted through ConfigurationAdmin, so configuration UIs do not need to deal with the items file syntax, which is only ONE way to provide a configuration.
- Bindings will support a multi-instance setup. So you can have multiple gateways of each type instead of just one.
- Bindings do not need to hold internal lookup tables for item names and their types and their according configuration. Instead, they directly receive the events for the Channel it is bound to.
- The syntax in the item file is homogenised for all bindings
I am looking forward to your feedback to this proposal! If the general direction seems to be ok, we will also soon publish some example code to better show how things are supposed to look like when this concept is realized.
Best regards,
Kai
|
|
| |
Re: RfC: New Thing concept [message #1267197 is a reply to message #1266584] |
Sat, 08 March 2014 16:39 |
Karel Goderis Messages: 198 Registered: March 2014 |
Senior Member |
|
|
Kai
I lost my original post. Here it is in bullet style
1. Things can only use 1 Bridge? what with devices that support ethernet, RS232 etc, and where a choice has to be made?
2. Are Thngs, Channels and Bridges exposed in the runtime (Scripts, ...)
3. Things can only communicate with each other via Bridges? Will there be an internal bus aka event bus?
4. Bindings are thus collections of ThingHandlers? is that the reason for the ThingHAndler factory? each time a thing is added to the binding, the Factory creates a handler. If so, how to deal with dependencies between THandlers?
5. Is the naming of the Channels generated by the configuration engine, or is this "choosable"
6. Why no subclassing of Things? How to support various variations of a piece of hardware? this then has to be done in the binding? Example Plugwise binding, Sonos binding.... all devices have same base capabilities but some stuff differs
7. Which Things will be defined at the Start? Items will then be "values" only, like String, Number etc? Things then to be RollerShutter, etc?
8. If Channel is exclusive to a Thing, should Channel not be part of the Thing class? or can Channels be detached from Things, and be hooked up to another Thing? could be nice feature for some classes of hardware etc.
9. ThingHandlers post events on a bus for Items, or Channels, or both? not clear
10. Users can enable/disable Channels on Things? e.g. expose only subset they require
K
|
|
| |
Re: RfC: New Thing concept [message #1267711 is a reply to message #1267638] |
Sun, 09 March 2014 12:40 |
Vincent Danjean Messages: 1 Registered: March 2014 |
Junior Member |
|
|
Hi,
There is different use cases I find a bit anoying with openHab. Perhaps, the restructuration could be the time to think about them. I think that all these use cases can be workaround by the use of "rules" but having a kind of support for them directly into openHab would probably be better.
1) absence of a kind of virtual hardware
OpenHab makes a strong relationship bewteen items (that are exposed to the interface) and real hardware. This relationship is done through the "binding" concept.
However, in my implementation, there are several times where I do not want to expose the raw hardware but instead I would like to expose a fake/virtual hardware/item. One example : openHab has a nice build-in feateure to manage roller shutters with an "up" a "down" and a "stop" bouton in the default interface. An dimmer could also be used to choice how the shutter is opened. Nice. But, at home, my shutter are controled by a (radio)remote which itself is controled by simulating keypress with 1-wire PIO switches (that control opto-coupler). So, to move my shutter, I need to send one 1-wire command (simulate the key press), wait a bit (0.3s), send a second 1-wire command (simulate the key release).
I did this by creating items linked to my 1-wire PIO switches. These items will never appear in the interface (sitemap). Then, I create fake/virtual items with lots of rules in order to get a "RollerShutter" item that works as would a "standard" RollerShutter hardware.
I've other example with lamp control where I use two different hardware items (one to switch the power, one to get back the current state that can also be modified directly by the user through plain switches)
What I would like would be a way to express that "theses hardware items must be hidden and combined into a virtual item" so that the latter would be the only thing to appear in the interfaces.
2) absence of scheduler/bus control
Lets go back to my previous example with my roller shutter. I've 4 of them, each one with their own remote. In order to work, remotes must not be used at the same time and a small period with nothing must be inserted between the use of different remotes. You remember that my remotes are controled with 1-wire switches and I must send two commands (one to press the remote key, another to release the remote key).
I do not find any easy way to explain this with the current openHab setup. It means that, when I want to close all my roller shutter, I must queue the order for each of them and replay them one at a time. A mix of rules and timers can do the trick. However, here again, it would have been better if openHab would have been the concept of "bus use" or a similar concept that can automatically differ (in time) the commands when the required bus is already used.
I also talk about "scheduler" because, if I want to be able to move my roller shutter at a precise position, I need to simulate a keypress/keyrelease on the remote and a second keypress/keyrelease after a precise time interval. Of course, if I want to do that with several of my roller shutters, I want to interleave them (ie do not wait that the first is stopped before starting to move the second). The constraints are:
1) no two remote keys must be pressed at the same time
2) after a key release, a few time must elapse before another keypress
3) I can start to move a roller shutter "when I want" (no time constraint for the start order) but the stop must be sent a precise time after the start (big time constraint for the "stop" order).
It would be good if there was a way to handle this kind of scheduling constraint.
Regards,
Vincent
PS: I'm rather new at openHab, so perhaps there is already some support for my "problems" that I did not yet find.
|
|
| |
Re: RfC: New Thing concept [message #1267864 is a reply to message #1267835] |
Sun, 09 March 2014 18:08 |
Kai Kreuzer Messages: 673 Registered: December 2011 |
Senior Member |
|
|
Karel,
Thanks for your good questions - let me try to answer them one by one:
1. Only one at a time; but I could imagine that a binding can provide an RS232-bridge or an IP-bridge and provide the same kind of Things behind these; but one concrete Thing is obviously always attached to only one bridge.
2. Good question; I think in general, it should not be necessary. To cater for cases where this is helpful, I would assume that we will also expose them.
3. Things do not communicate with each other - all communication is done through items as it is today. So you can have 2 things bound to the same item or you can have two items and define a rule that decides about the communication flow.
4. Yes, the idea is to delegate a lot of this to the ConfigurationAdmin; so all you do is to create a new configuration and the factories will create a bridge or thing instance for you. The only dependency is the one from a bridge to all connected things - as the bridge would create the new thing configurations, this is easy to deal with.
5. The Channel names would be chosen by the ThingHandler implementation.
6. No subclassing, because it would not allow the generic factory approach. What you can do though is to subclass the configuration classes for your things; so you can support different device types by simply providing different sets of configuration.
7. Not sure, if I understand the question. The items will remain as they are - so there will still be Rollershutter Items. And there will be devices (=Things) that provide a rollershutter functionality (=Channel). What you can do is to bind your item to such a channel. So channels are on the same level of abstraction like items; but they represent the "physical" world, while "items" are the "modelled/virtual" world. The advantage of this split is that you can assign an item to a different channel (bind it to a different hardware) at any time and keep your rules and UI definitions untouched.
8. Well, channels are a containment of Things, so in some way they are part of it. They can vary in number and thus are not hard coded.
9. Events on the bus are always for items. But there can be convenience methods in a ThingHandler that allow to post events for a channel (which is then automatically mapped to the according item, if any is bound to it).
10. Yes, a different configuration of the Thing can result in different Channels being supported by it. But besides this, "Channel" are anyhow not active per se, but only if they are bound to an item. So the user can also simply decide to ignore a channel and not use it.
Regards,
Kai
|
|
|
Re: RfC: New Thing concept [message #1268205 is a reply to message #1267864] |
Mon, 10 March 2014 07:27 |
Karel Goderis Messages: 198 Registered: March 2014 |
Senior Member |
|
|
Some more questions to clarify:
1. So, Channels are basically a kind of hook or subscription that you can subscribe to by binding it to an Item, much like the Topic concept in MQTT?
2. Are Things "generalised"? e.g. will they contain specific kinds of logic (example, a RollerShutter Thing that tracks how much % it is opened?) and so forth? If so, will Things then implement as much functionality as possible, and only off-load specific HW related things to the ThingHandler? Imagine a AudioPlayer Thing, it does all that an audio player should do, and so, when it received a Play command, it will then so some stuff, and order the physical counterpart, e.g. the binding, to execute that "Play" command?
3. It is a pity that Things can not communicate to each other, or by consequence have inter-dependencies. Imagine that you want to create and operate a multi-room sound system that goes the boundaries of a single HW vendor like Sonos? It is not clear to me who will and who will not post events on the Event Bus.
I think some sample code would be useful. I also think that some stuff will be very complex to code. I just - for one - try to imagine how the TCP bridge will work, knowing the issue that I encountered in the TCP binding to deal with the multiplexing stuff, the fact that OH can be a server / listening to a port,....
K
|
|
|
Re: RfC: New Thing concept [message #1268640 is a reply to message #1268205] |
Mon, 10 March 2014 19:48 |
Thomas Letsch Messages: 1 Registered: July 2009 |
Junior Member |
|
|
Hi Kai,
first of all, I like the concept of a thing that contains various channels. That fits better into the Homematic and EnOcean world.
And a lot of the other concepts are very familiar (some I implemented already in parts in the bindings) and very much welcome!
One remark from my point of view about the Thing thing:
The IoT seems for me to be some kind of marketing thing. Most of the hardware stuff attached to ESH are probably devices, if not all. A service seems something totally different to me.
A service in an internet way is for example addressed by an URL, not a Device / Channel combination. How about naming these two things as what they are and also handling them differently?
I would rather like to implement a HomematicDeviceHandler or a HomematicProtocolHandler. A HomematicThingHandler sounds somewhat strange
Another small addition: In your example of an item configuration, there are the deviceId and the channelId together in one field. Let me propose to seperate them into two fields:
I can image situations, when I even don't need to specify a channel to get my device configured (e.g. plain temperature sensor). A deviceId would then be sufficient and no channel used in the config.
In the handler then of course there would be internally the channel used since this a very basic homematic / enocean concept.
Speaking about changes and new ideas:
I would like to propose to have more concrete classes of devices known to ESH. Like a Rollershutter, but for all common devices (e.g. Temperature, Switch, PowerMeter etc.).
That does not need to be a concrete class for each of them, but an attribute type.
An UI could then display automatically the correct icon, could automatically display the correct widget without having to specify them in the site config. In my binding I know of what type the device is, but
the user still has to find out the correct widget and icon. We could ease the lives of our users. This can be one the MetaData at a device (or thing) or a channel.
Regards,
Thomas
|
|
| |
Re: RfC: New Thing concept [message #1269287 is a reply to message #1269092] |
Tue, 11 March 2014 16:54 |
|
I'm finding it hard to understand the new proposal, so +1 on calling things what they are (devices/services, etc).
Shouldn't there also be a BridgeHandler interface which can be implemented by the bindings?
For the nikobus binding for example, I have one device linked to a serial port which acts as a gateway to a bus with multiple switch modules and switch buttons.
So in the new terminology I guess that the gateway would be the Bridge and the Switch Modules and Switches would be Things.
As all the communication to the switch modules has to go through the Bridge and there should really only be one process coordinating all the read/write operations to that serial port, to me it would make sense to implement this logic in the BridgeHandler.
For the DMX binding, the artnet or OLA interface could be a Bridge and then the actual devices like a RGB strip could be a Thing.
But also here, all communication to the DMX universe should be handled by a single process, so having a BridgeHandler would help here too.
Davy
|
|
| | |
Re: RfC: New Thing concept [message #1269954 is a reply to message #1269397] |
Wed, 12 March 2014 10:53 |
Dennis Nobel Messages: 3 Registered: February 2014 |
Junior Member |
|
|
Hi,
I´m working with Kai at the Deutsche Telekom and was involved in the development of the 'Thing' concept. So i can also answer some question in order to help Kai a litte bit here.
Davy, you are right, the Gateway would be the bridge and the switches would be Things. Things, that are connected through a bridge, always have access to their Bridge. Moreover there is also a ThingHandler for the Bridge (we might call it a BridgeHandler). The ThingHandlers of the 'switch' Things have access to their according BridgeHandler. So you can delegate the handling of commands to your BridgeHandler. At the end its up to the binding developer how he wants to implement it.
Regarding the 'Thing' interface, it might be better, to have concrete subinterfaces for 'Device' and 'Service' that inherit from 'Thing'. So there could be a DeviceHandler and ServiceHandler.
Later, I will post two sample ThingHandlers for Philipps HUE here, so that everyone might get a better idea how a concrete ThingHandler implementation could look like.
|
|
| |
Re: RfC: New Thing concept [message #1270261 is a reply to message #1266584] |
Wed, 12 March 2014 19:20 |
|
Thanks Dennis, that already clarifies a lot. I have some more questions you may be able to shed some light on..
How are bridges linked to bindings? More specifically, how/by whom are things and bindings created and in which sequence?
Are they configured in a fixed sequence, e.g. bridges always before things?
Is this sequence respected when binding bundles are stopped/started?
What is the purpose of the 'staging' of things before they are added to the ThingRegistry? If a thing was added by a binding, but not configured by a user, it would have no impact, right?
|
|
|
Re: RfC: New Thing concept [message #1270904 is a reply to message #1269954] |
Thu, 13 March 2014 19:57 |
Karel Goderis Messages: 198 Registered: March 2014 |
Senior Member |
|
|
Dennis, Kai
Cfr the post on the BridgeHandler + the code snippets:
How is the relationship between a Bridge and BridgeHandler established? The code is clear, but in my understanding the BridgeHandler is a kind of "upper" bridge, that sits on top of the "lower" bridge, with the lower bridge taking a kind of technology/hub approach if necessary, thereby doing stuff like multiplexing data.
Cfr previous discussions on the OH forum, how would communication hubs fit in the Bridge world? e.g separate technology bindings like TCP, serial, bluetooth, etc from the rest. How can bindings, via their BridgeHandlers share Bridges?
Related to that, if you have various Things that talk to the same remote server, and for example share a single TCP connection to do so (because, for example, the remote device only accepts a single TCP connection), how will traffic be separated? what class is responsible for that... not clear to me.
Can BridgeHandlers be subclassed to allow for technology fail-over mechanisms, e.g. getBridgeHandler returning a bridge in function of the technology available? or, there is a base TCPBridgeHandler for example, that is subclassed to implement this multiplexing stuff if required?
Lastly, it is not very clear to me right now what stuff has to go in the ThingHandler, and what stuff needs to go into the BridgeHanlder. For some bindings this will be a though choice to be made, with possibly either one of th classes ending up being very "light"
K
|
|
|
Re: RfC: New Thing concept [message #1270911 is a reply to message #1270904] |
Thu, 13 March 2014 20:21 |
Will Stewart Messages: 6 Registered: March 2014 |
Junior Member |
|
|
Kai,
I like this concept, as it provides a layer of abstraction we sorely need. I've been thinking about how to broach this, and this is a perfect opportunity.
Most of the items we access fall into some classification (light switch, temperature sensor, thermostat, shutter control, etc), though we have been too often directly passing along the APIs to these devices instead of generic operations. For example a basic light switch would have the two operations;
- on
- off
Basic dimmers would have;
- increase(amount)
- decrease (amount)
Specializations could include;
- status (on/off) //for plain switches
- status (% illumination) //for dimmers
- dimmingRate (int) // for dimmers
Any vendor's special operations could be added in an additional specialization.
The same goes for virtually all of the items we have that are represented by more than one vendor or model.
This way, the rules would be more reusable and we could create libraries of rules that would require little to no rework.
|
|
|
Re: RfC: New Thing concept [message #1271073 is a reply to message #1270911] |
Fri, 14 March 2014 07:21 |
Dennis Nobel Messages: 3 Registered: February 2014 |
Junior Member |
|
|
Hi,
let me try to answer some of the last questions:
Davy: Things and Bridges are created through entries from the configuration admin. A 'ThingHandlerFactory' is called for each stored entry in the configuration admin. Unfortunately there is no specific order. But the binding developer has full control of the Thing creation process by implementing an own 'ThingHandlerFactory'. The following snippet shows a simple factory for the HueBridgeHandler which inherits from a BaseThingHandlerFactory, which already encapsulates a lot of complicated stuff around the configuration admin:
public class HueBridgeHandlerFactory extends BaseThingHandlerFactory<HueBridgeHandler, HueBridgeConfiguration> {
@Override
protected HueBridgeHandler createThingHandler(HueBridgeConfiguration configuration) {
return new HueBridgeHandler(configuration);
}
@Override
protected void removeThingHandler(HueBridgeHandler hueBridge) {
// nothing to do
}
}
According to staging. You are right, the idea is, that the user can control which Thing he wants to add to his system. But this might only taken into account in pairing UIs. In openhab the user defines it Things statically, so that there is no staging at all.
Karel: As Kai already mentioned, the Thing concept is for 'high-level' bindings. TCP, serial or blutooth binding are examples for more low-level bindings. The Bridge does not represent the protocol, it represents something like a Gateway or USB stick. But it could be possible to define base classes for common Thing or BridgeHandlers. For example you could have a HttpThingHandler, which already sets up an HttpClient, that can be subclassed for all Things or Bridges, that uses Http for communicating with their devices. From the model point of view, it is also possible to have hierarchies of bridges, because also a Bridge could have a parent Thing. But this makes it really complex.
|
|
| |
Re: RfC: New Thing concept [message #1271112 is a reply to message #1271093] |
Fri, 14 March 2014 09:47 |
Kai Kreuzer Messages: 673 Registered: December 2011 |
Senior Member |
|
|
@Davy: Just one addition regarding the "stating": This is to also allow bindings to do auto-discovery. Imagine e.g. IP cams that are found through UPnP. The user might not want all available cams to be used in his system - so bindings should first only tell that there is something new and the user can decide whether to activate its use or not. This "user acceptance" could be done interactively through a UI, by a specific configuration (acceptXYZ) or by some global configuration setting (auto-accept). Which way we choose in openHAB has still to be defined.
@Will: Please note that this concept is meant to be used for setup, configuration and administration use cases. It is not a replacement for the current "operational" behavior, i.e. the items that are used in rules, sitemaps, persistence etc. So rules will not be impacted by this - they should still use items and not things. Nonetheless, we are working on other new concepts to bring some context/semantics about items into the system, which is meant to simplify and generify rules - so stay tuned for this discussion to be launched soon!
@Karel: Yes, I see them coexisting; the "swiss-army-knife" bindings like tcp, exec, http etc. should definitely stay with their current implementation. Any "higher-level" binding I would want to see migrated to the new concepts for openHAB 2.0, though. As this will take a while, I am planning to look into providing a "1.x compatibility bundle" for openHAB 2.0, so that it should be possible to run (most of) the current bindings as well. Regarding timeline: Well, we have to see how quickly the new bindings will be implemented, so I cannot yet give a date for a first release. Nonetheless, I plan to create a 2.0 branch in the next weeks (latest end of April) and start building snapshot versions of it, so that binding developments can start.
|
|
| | |
Re: RfC: New Thing concept [message #1383890 is a reply to message #1383017] |
Mon, 26 May 2014 19:18 |
|
Wow, there sure are many things to look at It looks very promising.
Imho, writing bindings is less confusing if you only have to implement interfaces and not extend base classes. It would also be a cleaner decoupling between openHAB/SmartHome if it is strictly interface based. So for me personally, it would look even better if the functionality in the BaseThingHandlerFactory could be moved to the ThinkManager, so that bindings only have to implement the ThingHandlerFactory interface.
|
|
| | | | | | |
Goto Forum:
Current Time: Sat Nov 09 03:11:02 GMT 2024
Powered by FUDForum. Page generated in 0.06058 seconds
|