Initial contribution of the KNX 2.0 binding #21
Conversation
|
openhab » openhab2 #56 SUCCESS |
|
openhab » openhab2 #64 SUCCESS |
|
All changes are OK for ESH 20150430 stable release |
|
openhab » openhab2 #176 SUCCESS |
|
openHAB » openhab2 #224 SUCCESS |
|
@kgoderis yes we had the chance to implement some improvements (at least we think they are ;-)) but didn't get the permission to post them here. Once we are allowed to i let you know and would appreciate your feedback. |
|
Ok - I missed somehow the last 10 days of discussions in this thread. So, for my understanding @teichsta you implemented some stuff on top of the pending PR for the 2.0 binding? or is that 1.8 stuff you would like to see in the 2.0 ? |
|
we've implemented a GenericKnxThing which takes some configuration to represent either a single GA or a 16fold switch actuator. So it's especially for 2.0 and beside the current solution. It may probably replace the type specific ThingHandler. |
|
Mhh... When I developed the binding I had several cases whereby a logical grouping of GA's in a piece of Java code really made sense. Of course, they tend to follow the paradigm of my own equipment ( I have a lot of MDT and Gira), I am not sure to what extend we will be able to define all the specific wanted behaviour in a GenericKNXThing. Well, that is, without having to do a quasi-duplicate configuration of ETS4 of course. |
|
@kgoderis, @teichsta, are there any news with KNX 2 architecture and its implementation? While testing (https://github.com/openhab/openhab2-addons/issues/503) KNX for OH2. (with bootdelegation Version for karaf compatibility) So actually there is no usable KNX Bundle for OH2, I think this is really critical. Tomorrow, I will have a deeper look at KNX 1.8 in OH2. |
|
no unfortunately not from my side. We still have to clarify some internal issues … |
|
The KNX 2.0 binding is still pending for review. There is a separate issue on the tracker that deals with the KNX 2.0 binding, running on top of the Karaf container. I have the 2.0 running on a pre-Karaf snapshot without any problems, and it is actually very stable. |
|
Any news on the KNX 2.0 binding? I'm currently running the 1.9 version together with OH2 beta 2 and it works as it should. I do, however, experience the duplicate events/messages on the KNX bus even with ignorelocalevents set to true and it would be nice to move over to the real 2.0 binding. |
|
I have been following this discussion and have the binding in its current state happily running since a while with only minor tweaks. So all in all I'm pretty glad that it exists and would also like to help pushing it further. If I'm not mistaken, so far there is not really a common agreement on how the real world should be abstracted into Bridge, Thing & Channels. Currently everything is a Thing (with mostly only a single channel). Therefore we have an enormous amount of Things and also miss the opportunity to structure the stuff according to the real world (at least where it's possible). For these reasons I'd propose to move stuff to the Channel layer like in this example: In that way, users have the opportunity to structure their stuff (especially for actors IMHO that really makes sense). And if @kgoderis one day figures out how to detect if an actor is still alive by its physical address, we would have the right layer of abstraction to set a whole Thing (a.k.a. actor) offline if it died. Also, if one day we will include device configuration in ESH (dreaming is allowed, isn't it...?) and maybe some crazy guy out there comes up with something which replaces parts of the ETS this also would work nicely. However, I also see that for many GAs it does not make sense to put them onto a specific device, especially when they are not clearly tied to one actor. Those still could be defined as a channel on the bridge. So in the end, the user is not forced to define things at all - everything could be put as channels into the bridge. Then nothing is won, of course. But with this approach we at least enable and hopefully also encourage such structuring. The ThingHandler of course somehow needs to know what to do with a channel. Therefore it would make sense to factor the channel definitions out of the current thing definitions into standalone ChannelTypes. I have created eclipse-archived/smarthome#2343 in order to allow referencing them in the DSL then - for whatever reason this was missing so far. WDYT? |
That day was a long time ago. :-) I have the code in place that "ping" actors over the KNX bus and set their state ONLINE/OFFLINE. Also, Group Address discovery is in place by scanning and parsing the data tables exposed by KNX actors. But it is really experimental stuff as (at least in my case, with >120 actors) it floods the KNX bus very easily.
I am not crazy enough to give it a go. Actually, I did but had to give up (that was in the ETS4 era) Now, more seriously, on the channels: I had the whole binding set up with channels as you describe, more or less, but then had to switch to a "full" Thing approach because of eclipse-archived/smarthome#2042, which you provided a fix for (but I was impatient, since it broke my operational environment) in eclipse-archived/smarthome#2053 . I do agree that a large number of things renders UI like paperUI useless Finally, if you have nice tweaks/improvements, pls feel free to PR them to my branch and I will incorporate them. |
|
Hi, Regarding things/channels - I would agree with @SJKA - some actors, like dimmable lights have some natural channels - on/off status, dimming value. |
|
@kgoderis - One suggestion - make port number of IP bridge optional and default to constant 3671. Currently, if port number is not specified and debug is enablet, one gets NullPinter: |
|
Some additional thoughts: |
|
@uspringis In the binding the following discovery methods are provided: Regarding reading and parsing the ETS project export, I can only comment that these XML files are extremely complicated, long, and hard to decipher. I investigated this a long time and abandoned this pretty fast. With ETS5 there might be an option to do a new attempt based on the Web Services "output" add-in, but my hopes are limited. |
|
Checked out ETS 5 project export format, looks really nice and doable: <Buildings>
<BuildingPart Type="Building" Id="P-0441-0_BP-1" Name="Building 1" Puid="6">
<BuildingPart Type="Floor" Id="P-0441-0_BP-3" Name="Floor 1" Puid="8">
<BuildingPart Type="Room" Id="P-0441-0_BP-7" Name="Room 1" Puid="12">
<Function Id="P-0441-0_F-1" Name="Dimmabe lights" Type="DimmableLight" Puid="18">
<GroupAddressRef Id="P-0441-0_GF-1" Name="" Role="SwitchOnOff" RefId="P-0441-0_GA-1" Puid="25" />
<GroupAddressRef Id="P-0441-0_GF-2" Name="" Role="RelativeSetvalueControl" RefId="P-0441-0_GA-2" Puid="26" />
<GroupAddressRef Id="P-0441-0_GF-3" Name="" Role="ActualDimmingValue" RefId="P-0441-0_GA-3" Puid="27" />
<GroupAddressRef Id="P-0441-0_GF-4" Name="" Role="InfoOnOff" RefId="P-0441-0_GA-4" Puid="28" />
</Function>
.....
<GroupAddresses>
<GroupRanges>
<GroupRange Id="P-0441-0_GR-1" RangeStart="1" RangeEnd="2047" Name="New main group" Puid="19">
<GroupRange Id="P-0441-0_GR-2" RangeStart="1" RangeEnd="255" Name="New middle group" Puid="20">
<GroupAddress Id="P-0441-0_GA-1" Address="1" Name="Switching" Description="Room 1 Dimmabe lights" DatapointType="DPST-1-1" Puid="21" />
<GroupAddress Id="P-0441-0_GA-2" Address="2" Name="Dimming" Description="Room 1 Dimmabe lights" DatapointType="DPST-3-7" Puid="22" />
<GroupAddress Id="P-0441-0_GA-3" Address="3" Name="Value" Description="Room 1 Dimmabe lights" DatapointType="DPST-5-1" Puid="23" />
<GroupAddress Id="P-0441-0_GA-4" Address="4" Name="Status" Description="Room 1 Dimmabe lights" DatapointType="DPST-1-1" Puid="24" />
<GroupAddress Id="P-0441-0_GA-5" Address="5" Name="Current temperature" Description="Room 1 Heeted floor" DatapointType="DPST-9-1" Puid="30" />
<GroupAddress Id="P-0441-0_GA-6" Address="6" Name="Setpoint temperature" Description="Room 1 Heeted floor" DatapointType="DPST-9-1" Puid="31" />
<GroupAddress Id="P-0441-0_GA-7" Address="7" Name="Variable" Description="Room 1 Heeted floor" Puid="32" />
<GroupAddress Id="P-0441-0_GA-8" Address="8" Name="Operation mode" Description="Room 1 Heeted floor" DatapointType="DPST-20-102" Puid="33" />
<GroupAddress Id="P-0441-0_GA-9" Address="9" Name="Window contact" Description="Room 1 Heeted floor" DatapointType="DPST-1-19" Puid="34" />
</GroupRange>
</GroupRange>
</GroupRanges>
</GroupAddresses>
|
FTR: eclipse-archived/smarthome#2042 and eclipse-archived/smarthome#2053 are both fixed now, so I think all should be in place to go for the multi-channel thing approach that we discussed in the past (I just cannot find a link to the discussion, was that through email?). Just to give the gist of it: Allow "generic" KNX Things to be defined by the user, where any number of Channels can be added, each referring its type (of which we will have a set of KNX Channels like Switch, Dimmer, Rollershutter, etc.). These Things could be the same as a physical KNX device (e.g. if we manage to discover them), but they do not have to be. Afair, you agreed that this would be the best way of mapping KNX to ESH, right? What other architectural topics were open to discuss? |
I am not sure we are the same page here. Some of the complexity can not be easily captured in an approach as you describe it. At it's core, you would have a Bridge Thing and a bunch of Channels, since Group Addresses somehow are independent entities on the KNX bus. But you want to take it a step further, and define for example a RollerShutter Thing, which you would populate with Channels "a la carte" in function of the functionality required by the user. These Channel Types would be quite generic, e.g. almost mapped to a given DPT? For some types of Actors it would make sense to link channels in a smart way in order to better steer the behaviour of the Thing. For example, as you know, you have pretty often a GA for steering an actor, and an equivalent "status" GA the device uses to feed back the result of the action. Cfr the auto-update mechanism, if you want the OH runtime follow the actual state of the actor, you would have to combine both these GA's into a single channel, with the channel not getting "auto-updated" with the value it receives from the OH bus, but with the real value received over the KNX bus. Another example could be RollerShutters, where pretty often you get a bunch of related GA's that all serve the same purpose of controlling the shutter: direction of movement, absolute position setting/getting, drive to reference position and so forth. I think it is better to keep the linkage between these things in a Thing, rather than having unrelated Channels that you then capture functionality through linked Items in userland. I would therefore not always opt for "Generic" Things. Ofcourse, there should be Generic Things, but I would also provide Purposed Things (which some may be trivial, obviously) ;-) One other main reason to go further than a Bridge+Channels approach is that there is currently some low-level KNX stuff in the binding to read-out device tables, scanning the bus and so forth. One last item to discuss is the inclusion, or not, of Virtual KNX actors. E.g. Just imagine a scene controller in software, rather than in an expensive piece of hardware you would have to add. We can build software components with their own device addresses, their own set of GA's and behaviour, that could interact with other devices on the KNX bus. Now, specifically, the code to both approaches is still present in the binding - I have not deleted anything, so it might be worthwhile to glance through some of the ESH-INF and Thing Handlers to get an idea of where it can go to. |
|
Independent as at the end a virtual actuator in openHAB will be creatable. Is it also conceived to map all the abilities of a real KNX-actuator in openHAB? Specifically I ask, because a GA in KNX can typically be read out by other devices as well. Or later can be(from me) programmed a extended KNX I/O addon which provides this functionality? On KNX Side, each GA can have several Flags:
We began this discussion, upper here.
@kaikreuzer, I think when we discuss about architectural topics we need to have one eye on the "KNX perspective" too. ;-) As I learned here Smarthome/openHAB seams to be enough flexible to map such cases. |
|
@lewie Helmut, I not sure I fully understand your concern, but the flags you mention are in fact not related with the GA's as such nor the KNX Telegrams for that matter. They are indicators that describe the behaviour of the Group Objects that an actor exposes, and which are linked to GAs. [The real indicators in the protocol header are GroupValueRead, GroupValueResponse, GroupValueWrite] Virtualising an actor, so to speak, is thus just a question of exposing a wanted behaviour, which ideally, could be described in the documentation with the R/W/T.... flags. So, in short, you can invent a Thing Handler that responds to R requests, that sends U when something relevant happened we want the other actors on the bus to know about, and so forth. The possibilities are endless, the only thing is that virtual actors - and here @kaikreuzer will jump on the bandwagon - are not compatible (that is, from a conceptual point of view) with Eclipse Smarthome/openHAB in the sense that what we do in ESH/OH is rather provide avatars for real world objects, and thus, not create virtual ones that do not have a physical counterpart..... I am a KNX fan as well, Kai too, but he is - for good reasons - a purist ;-) (@kaikreuzer that was a compliment ;-) ) |
|
Karel, I'm trying to describe it more specifically. KNX GroupValueResponse is missed yet in openHAB. To get this functionallity, ItemRegistry is needed. So it should be implemented as a I/O addon. As addon consequently independent of the implementation of this KNX binding. And as @kaikreuzer aked; Yes, for me there are some architectural topics open to discuss:
@kgoderis Karel, I definitely do not want to steer to KNXio and a never ending discussion, a little with thought about my thoughts is enough. Much more important is to bring your genial binding online now! :-) |
|
@kaikreuzer Kai, so far we had a bunch of .io related bundles in both ESH, OH1 and OH2. They are obviously I/O related but they differ quite a bit in nature, and hence, they do not follow all the same design pattern. With respect to the above discussion, and those differences in mind, what is the way forward with respect to I/O bundles? should we adopt the tagging pattern as present in the HomeKit/Hue bindings, and link Items that way? in casu for KNX, we would then tag Items with for example a GA |
|
@kgoderis & @lewie: As it seems that we are on the same page regarding the functional split in KNX binding + KNX IO Add-on, let me suggest that we focus on what the issue title claims this PR is: a KNX 2.0 binding. My priority for the moment is to get a replacement for KNX 1.x merged as many people (including myself) would love to have this in place. And Karel is indeed waiting long enough already ;-) Hence I would like to move the "Virtual KNX Actor" discussion away from here as I think that it will otherwise result in further long discussions and prevent having the stuff merged on which we can easily agree. I do not mind if this might mean a later refactoring of shared classes - this should imho not be big efforts, but would help to keep the discussions clean. Would you be ok with that? Back to the "binding" architecture discussion:
No! This is not the approach that I meant. I had to search my inbox back to March 2015 to find our past discussion:
This is what I described above. There would be a generic KNX thing type without any channel definition by itself. The users would then create such a thing and add channels. A channel EXACTLY corresponds to what you currently find in OH1 as an item binding config, i.e. a combination of several GAs that combined resemble the functionality of an OH item. A knx.things file could look like: I think this is a very straight forward (as very strongly aligned with OH1) and yet very flexible approach. Does that make sense to you? |
|
@kaikreuzer I am ok to give it a try; what is described can be done within the existing frame of the PR without too much hassle, I hope. Would leave the other code in place just for future reference and enhancement. With channels Types being unique, how will we for example support different types of switches or rollershutter actor implementations? Make the type of rollershutter actor we want to support a channel configuration parameter? |
I'd prefer if you would take it out to keep it clean - store it in a branch in your fork for reference and create a new PR from it once it is time.
In OH1 we so far only have one type of rollershutter implementation, right? So that would be the starting point for me. |
Maybe I am a bit confused here as I am too DSL centric. As in: Switch Input/Output Channel ...Did we not have the item type as the "Type" qualifier in the DSL a long time ago in the early days, and then changed it? I don't remember. I am too tired.... Anyways, tx for the discussion, I have to have an updated PR shortly. |
This is what @SJKA implemented recently just for you: eclipse-archived/smarthome#2343
👍 |
|
@kaikreuzer, let us connect to the functionality of KNX1, sounds logical for me. Then we improve the functionality evolutionarily and as required. Thank You. |
|
Hey, i finally figured out howto build a binding ;-) at least i thought. But if i try to mvn clean install this binding, i got these Errors: |
|
Hi all, I have installed the knx addon, but im not able to create the binding. I get always the same exception in the log. Does somebody know the problem? 20:36:33.663 [ERROR] [org.openhab.binding.knx ] - FrameworkEvent ERROR - org.openhab.binding.knx thanks in advance |
|
Hi @muellerbenni, |
…ding-thing-types Fixed typo on the spelling of auxiliary
Initial contribution of the KNX 2.0 binding
Signed-off-by: Karel Goderis karel.goderis@me.com (github: kgoderis)