Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » Eclipse SmartHome » RfC: New Thing concept
RfC: New Thing concept [message #1266584] Fri, 07 March 2014 17:26 Go to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
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:

index.php/fa/17679/0/

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 #1266726 is a reply to message #1266584] Fri, 07 March 2014 22:05 Go to previous messageGo to next message
Derek Adams is currently offline Derek AdamsFriend
Messages: 1
Registered: March 2014
Junior Member
This looks like a nice approach! Is there a plan to allow SmartHome to act as an aggregator that can report data to an external entity? It seems like SmartHome could be used as a proxy for interacting with registered devices -- abstracting the complexity of how they are connected and keeping some of the control logic local. I would be interested in integrating our project (sitewhere.org) with SmartHome so that the data, integration, and analytics for multiple systems can happen in the cloud.

Thanks,
Derek
Re: RfC: New Thing concept [message #1267197 is a reply to message #1266584] Sat, 08 March 2014 16:39 Go to previous messageGo to next message
Karel Goderis is currently offline Karel GoderisFriend
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 #1267638 is a reply to message #1266726] Sun, 09 March 2014 09:50 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 673
Registered: December 2011
Senior Member
Derek,

What you are probably looking for is a "persistence service" - these are the concept in SmartHome to export data to cloud services for further processing. You can find a nice example e.g. at http://airvantage.github.io/blog/2013/08/08/openhab-with-airvantage/.

Regards,
Kai
Re: RfC: New Thing concept [message #1267711 is a reply to message #1267638] Sun, 09 March 2014 12:40 Go to previous messageGo to next message
Vincent Danjean is currently offline Vincent DanjeanFriend
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 #1267835 is a reply to message #1267711] Sun, 09 March 2014 17:14 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 673
Registered: December 2011
Senior Member
Vincent,

I think your problems appear because of a wrong level of abstraction. You actually describe a lot of very device-specific behaviour that you need to know about and that must be taken into account. All thus specific logic imho needs to reside in the binding (=device driver). The 1-wire binding is a rather "low-level" binding, which does not have knowledge about more complex devices and their behavior. The solution is simple: You would need a dedicated binding that encapsulates this logic and allows you to bind it to a single rollershutter item. That's the only clean way to really reach an abstraction from specific details.

Regards,
Kai
Re: RfC: New Thing concept [message #1267864 is a reply to message #1267835] Sun, 09 March 2014 18:08 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
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 Go to previous messageGo to next message
Karel Goderis is currently offline Karel GoderisFriend
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 Go to previous messageGo to next message
Thomas Letsch is currently offline Thomas LetschFriend
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 Smile

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 #1269092 is a reply to message #1268205] Tue, 11 March 2014 11:17 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 673
Registered: December 2011
Senior Member
Let me try to answer all three questions at once:
"Thing" instances do not really hold any logic or code - they are a concept to have a handle for components that can be added or removed from the system and which bring functionality (=channels) that can be represented by items. Things do not directly offer items as they should not decide on their name, but the user should do this. That's why there are the channels.
Things and channels are not meant to interfere with any current "operational" concepts and behaviours; events only exist for items and items are what is used in rules, UIs etc. The ThingHandler only holds the "driver logic", i.e. the code that was contained so far in the XXXBinding classes - and it brings some structure on how to implement it and a couple of helper methods and other convenience stuff.
Let me add that the Thing concept is mainly meant for "higher-level" bindings, i.e. where you deal with clearly defined devices/services. So the TCP binding (likewise the serial, http and exec binding) will not be a good match; but nobody forces these low-level bindings to use the new concepts (with the side effect, that there won't be any generic UI and pairing support for them, but that is imho acceptable).

Regards,
Kai
Re: RfC: New Thing concept [message #1269287 is a reply to message #1269092] Tue, 11 March 2014 16:54 Go to previous messageGo to next message
Davy Vanherbergen is currently offline Davy VanherbergenFriend
Messages: 15
Registered: March 2014
Junior Member

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 #1269397 is a reply to message #1269287] Tue, 11 March 2014 20:26 Go to previous messageGo to next message
Theo Weiß is currently offline Theo WeißFriend
Messages: 9
Registered: January 2014
Junior Member
Hi Kai,

like Davy I find it hard to understand the proposal. Could you give us an example - not code just an explanation - using a concrete device/thing?

Regards,
Theo
Re: RfC: New Thing concept [message #1269430 is a reply to message #1266584] Tue, 11 March 2014 21:42 Go to previous messageGo to next message
Jaap Pelt is currently offline Jaap PeltFriend
Messages: 1
Registered: March 2014
Junior Member
Greetings,

My apologies for my limited understanding. I'm not very familiar with smart home, but the looks very promising. The Thing proposal reflects the actual situation nicely. I like to learn more about it.

Could you briefly describe how a plug-in developer would add support for a bridge with multiple types of connected devices? And how does this compare to the original implementation? Isn't adding the Thing layer also adding a layer of complexity?
Re: RfC: New Thing concept [message #1269954 is a reply to message #1269397] Wed, 12 March 2014 10:53 Go to previous messageGo to next message
Dennis Nobel is currently offline Dennis NobelFriend
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 #1270140 is a reply to message #1269954] Wed, 12 March 2014 14:39 Go to previous messageGo to next message
Dennis Nobel is currently offline Dennis NobelFriend
Messages: 3
Registered: February 2014
Junior Member
Here you can see two 'ThingHandler' implementations that both inherit from a class called 'BaseThingHandler'. The 'handleCommand' method is called when an item, bound to channel of the thing, receives a command. The HueLampHandler delegates the call to the HueBridgeHandler, which can make the actual HTTP call to the real HUE gateway.

public class HueLampHandler extends BaseThingHandler<HueLampConfiguration> {

    private static final String CHANNEL_ID_DIMMER = "dimmer";
    private Logger logger = LoggerFactory.getLogger(HueLampHandler.class.getName());

    public static class HueLampConfiguration extends ThingConfiguration {
        public String bridgeId;
        public Integer lampId;
    }

    public HueLampHandler(HueLampConfiguration configuration) {
        super(configuration);
    }

    @Override
    public void handleCommand(Channel channel, Command command) {

        HueBridgeHandler hueBridge = getBridgeHandler();
        if (hueBridge == null) {
            logger.warn("Cannot handle command without bridge.");
            return;
        }

        switch (channel.getId()) {
            case CHANNEL_ID_DIMMER:
                if ((command instanceof PercentType) && !(command instanceof HSBType)) {
                    PercentType percentType = (PercentType) command;
                    hueBridge.setLampBrightness(getConfiguration().lampId, percentType.intValue());
                }
                break;
            // TODO: define handling for further channels
            default:
                logger.warn("command is sent to an unknown channel");
                break;
        }

    }
}

public class HueBridgeHandler extends BaseThingHandler<HueBridgeConfiguration> {

    public HueBridgeHandler(HueBridgeConfiguration configuration) {
        super(configuration);
    }

    public static class HueBridgeConfiguration extends ThingConfiguration {
        public String ipAddress;
        @Default("ESH")
        public String secret;
        public String id;
    }

    @Override
    public void handleCommand(Channel componentPort, Command command) {
        // not needed
    }

    public void setLampBrightness(int lampId, int brightness) {
        // TODO: send HTTP request to HUE bridge
    }
    
}
Re: RfC: New Thing concept [message #1270261 is a reply to message #1266584] Wed, 12 March 2014 19:20 Go to previous messageGo to next message
Davy Vanherbergen is currently offline Davy VanherbergenFriend
Messages: 15
Registered: March 2014
Junior Member

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 Go to previous messageGo to next message
Karel Goderis is currently offline Karel GoderisFriend
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 Go to previous messageGo to next message
Will Stewart is currently offline Will StewartFriend
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 Go to previous messageGo to next message
Dennis Nobel is currently offline Dennis NobelFriend
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 #1271093 is a reply to message #1271073] Fri, 14 March 2014 08:38 Go to previous messageGo to next message
Karel Goderis is currently offline Karel GoderisFriend
Messages: 198
Registered: March 2014
Senior Member
I am looking forward to move some of the bindings to this architecture.

That being said, will both models (e.g. old and new) co-exists at a given point in time? moving the bindings into the new model will take quite some time IMHO, certainly the ones that are the result of reverse-engineering prop. protocols

Kai, any preliminary timeline you have in mind for "2.0"?
Re: RfC: New Thing concept [message #1271112 is a reply to message #1271093] Fri, 14 March 2014 09:47 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
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 #1378795 is a reply to message #1271112] Sat, 24 May 2014 11:51 Go to previous messageGo to next message
Davy Vanherbergen is currently offline Davy VanherbergenFriend
Messages: 15
Registered: March 2014
Junior Member

What is the current status of the Thing concept? Is it still in the planning or has the idea been abandoned?
Re: RfC: New Thing concept [message #1383017 is a reply to message #1378795] Mon, 26 May 2014 07:07 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 673
Registered: December 2011
Senior Member
No, not at all abandoned! We are just polishing an implementation of it to soon create a PR from it - current work can be found here: https://github.com/qivicon/smarthome/tree/master/bundles/core/org.eclipse.smarthome.core.thing. I will post here as soon as the PR is ready for it!
Re: RfC: New Thing concept [message #1383890 is a reply to message #1383017] Mon, 26 May 2014 19:18 Go to previous messageGo to next message
Davy Vanherbergen is currently offline Davy VanherbergenFriend
Messages: 15
Registered: March 2014
Junior Member

Wow, there sure are many things to look at Smile 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.
Re: RfC: New Thing concept [message #1383940 is a reply to message #1383890] Tue, 27 May 2014 10:20 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 673
Registered: December 2011
Senior Member
Well, you would be free to directly implement the ThingHandlerFactory interface. But the problem with programming against interfaces is that you have to know what you have to do. And our goal is to make life as simple as possible for binding developers and providing an abstract class seems to be the only feasible way here. Or would you have a good suggestion how the BaseThingHandlerFactory could be avoided?
Re: RfC: New Thing concept [message #1383963 is a reply to message #1383940] Tue, 27 May 2014 13:41 Go to previous messageGo to next message
Davy Vanherbergen is currently offline Davy VanherbergenFriend
Messages: 15
Registered: March 2014
Junior Member

I'll have a deeper look at the code and will try to come up with a more concrete solution.
Re: RfC: New Thing concept [message #1384008 is a reply to message #1383963] Tue, 27 May 2014 19:52 Go to previous messageGo to next message
Davy Vanherbergen is currently offline Davy VanherbergenFriend
Messages: 15
Registered: March 2014
Junior Member

I tried the code in https://github.com/qivicon/smarthome/tree/thing-refactoring . When I run this, I can register ThingHandlerFactories, but it seems that things themselves are not created. As far as I can tell, the method ManagedThingProvider.createThing is not called from anywhere. Is that part not implemented yet or am I missing something?
Re: RfC: New Thing concept [message #1384009 is a reply to message #1384008] Tue, 27 May 2014 19:55 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 673
Registered: December 2011
Senior Member
This falls under "as soon as the PR is ready for it" - please be patient and give us a bit more time to do finish things and do the PR; I won't answer any support requests until then Smile
Re: RfC: New Thing concept [message #1384012 is a reply to message #1384009] Tue, 27 May 2014 20:01 Go to previous messageGo to next message
Davy Vanherbergen is currently offline Davy VanherbergenFriend
Messages: 15
Registered: March 2014
Junior Member

No rush. When you said 'polishing' I assumed all the bits where already in place and just needed some minor tweaks or javadoc enhancement.
I'll be back after the PR Wink
Re: RfC: New Thing concept [message #1386200 is a reply to message #1384012] Sat, 14 June 2014 19:02 Go to previous message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 673
Registered: December 2011
Senior Member
FYI: The PR is now available, see https://github.com/eclipse/smarthome/pull/27
Please note that this is not yet ready to be fully used - we will add a few further PRs soon that also provide the config description side of things.
Previous Topic:Thoughts on extending Item properties
Next Topic:Rules events based on JMS queue
Goto Forum:
  


Current Time: Sat Nov 09 08:27:59 GMT 2024

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

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

Back to the top