openhab / openhab-addons

Add-ons for openHAB
https://www.openhab.org/
Eclipse Public License 2.0
1.88k stars 3.59k forks source link

KNX 2.0 - General Discussion Thread #17

Closed kgoderis closed 7 years ago

kgoderis commented 10 years ago

[New thread to discuss KNX 2.0]

Just did a small loading test for the new binding and defined a single Bridge with about 2500 GroupAddressThings underneath it. In the develop environment it took less than a second to create the 2500 Things, and about 7 seconds to create all the associated ThingHandlers. (with full debugging info set on)

After that there we no hiccups in processing incoming data, with about 4 to 8 telegrams arriving each second.

Having a "light-weight" GroupAddressThing does not seem to hamper performance at all....

kaikreuzer commented 10 years ago

Sounds ok so far, but I guess your "develop environment" is a 16-core enterprise server ;-) How will it look like on a Raspberry Pi instead...?

kgoderis commented 10 years ago

Nope - it is on my MacBook Air.

But I do not expect everyone to have 2500+ GA's, they are not crazy like me ;-)

On 10 Oct 2014, at 16:49, Kai Kreuzer notifications@github.com wrote:

Sounds ok so far, but I guess your "develop environment" is a 16-core enterprise server ;-) How will it look like on a Raspberry Pi instead...?

— Reply to this email directly or view it on GitHub.

kgoderis commented 9 years ago

FYI I will add a Discovery feature to the KNX 2.0 binding, that will "discover" GA's that are flying over the KNX bus. In fact, some of the other home automation solutions that support have the same kind of feature, to things linke importing the GA xml's generated by ETS4. Combined with the Paper UI/OH2.0 that will be very nice in terms of user experience: you add an actor, program in ETS4, and OH2.0 will pick it up automagically ;-)

haumacher commented 9 years ago

Just want to add the address of the repository to this thread - since it is somewhat hard to find:

https://github.com/kgoderis/openhab2

This is still the "normative" location for the KNX binding in openhab2?

kaikreuzer commented 9 years ago

It is much easier to find if you look at the pull requests: https://github.com/openhab/openhab2/pull/21 :-)

haumacher commented 9 years ago

Is there a way to unit test such a binding like KNX in openhab2 - other than uploading it to your home and pressing a button :-)?

haumacher commented 9 years ago

Regarding unit test, I found this: https://github.com/eclipse/smarthome/blob/master/docs/sources/development/unittesting.md

Is there any activity defining unit-tests for the KNX binding?

kgoderis commented 9 years ago

I did not do any testing so far

Sent from my iPhone

On 12 Apr 2015, at 13:13, haumacher notifications@github.com wrote:

Regarding unit test, I found this: https://github.com/eclipse/smarthome/blob/master/docs/sources/development/unittesting.md

Is there any activity defining unit-tests for the KNX binding?

— Reply to this email directly or view it on GitHub.

haumacher commented 9 years ago

Having dug somewhat deeper into the sources, I'm wondering, whether the Thing/ThingHandler API is the ideal level of abstraction to define a binding of the SmartHome virtual bus to the KNX physical bus.

If a Thing is the model of a real-world device within a SmartHome integration, I doubt whether there should be any necessity to explicitly code something for such a device.

When looking e.g. at the DimmerThingHandler or the SwitchThingHandler, these implementations roughly aggregate some state Items bound to group addresses on the KNX bus. I'm currently not convinced that a dimmer, switch, presence sensor, roller shutter, or heating valve connected to the KNX bus should be handled in any other way than a comparable device connected to any other physical network - ZigBee, Z-Wave and so on.

What I'd like to define (at least for the KNX example) is a binding for the state Items that should be bound to one or many group addresses for sending/receiving state updates and commands. This seems to be what the GAThingHandler does. Of cause already the name is somewhat strange, because on the one hand it is a ThingHandler, but on the other hand a group address is not a thing in the real world. Instead, a group address seems to roughly correspond to either a Channel or an Item in the SmartHome virtual bus. Wouldn't it be better to define a binding on the Item-level instead?

Having bound several command and state Items to interact with some concrete physical network, the aggregation of those Items to switches, dimmers, roller shutters, etc. would be completely independent of the concrete technology and could potentially be defined in a declarative way without the need for explicitly coding something for every new device.

I'm not saying the Thing abstraction is useless. I really like this very much for e.g. implementing virtual devices. I'm thinking of e.g. a virtual room controller that uses input from several physical temperature sensors and sends commands to the heating valves in the room for regulating the room temperature and being configured in the OpenHAB UI.

kgoderis commented 9 years ago

I am not sure that I entirely follow what you are saying here, but let me clarify the approach I took in developing the KNX 2.0 binding. In a first iteration I merely ported the KNX 1.0 binding as much as possible, and mapped KNX elements onto Things in order to get a good understanding of the OH2 architecture, as well as to have a basic version up and running very early on. The GAThingHandler is the result of that, in the sense that it does represent a single Group Address on the KNX bus. At the point in time, I made the assumption that the grouping of GA's into logical units would be done in the OH runtime, using rules and alike.

In a second iteration I started to group GA's at the level of the binding, in order to better represent real-life objects at the Thing level, and thus reduce complexity in the runtime. That is in fact how it is done in ETS as well: each actor and so forth is de facto a collection of GA's glued together with a bunch of device-specific parameters. No more, no less. The result are Things like SwitchThingHandler that capture some common logic, that is, common between that various device manufacturers. I then used plain java inheritance to further specialise those classes, and thus better match the real equipment I have in my environment, e.g. an MDT switch, and so forth. Obviously, I choose to develop Things that also match the OH Items in a certain way.

In this second iteration of the code base I also attempted to define all these things (dimmers,...) not as Things, but as Channels of the KNX Bridge Thing, so that you can define a Switch channel on the Bridge, instead of a separate Switch Thing underneath the Bridge. I only did that partially, because I rapidly ran into problems with the more complicated Things.

Both approaches are still in the code as a basis for discussion and review, so that everyone can see what are the hurdles or advantages in using one or the other approach. In the meantime I have it running in my operational environment, and this is how my .thing file looks like:

Bridge knx:ip:ip1 [ ipAddress="192.168.0.10", portNumber=3671, localIp="192.168.0.5", ipConnectionType="TUNNEL", readingPause=50, responseTimeOut=1000, readRetriesLimit=3, autoReconnectPeriod=1 ] { Things: Thing energyswitch AtticLight3Switch [ switchGA="1/5/0", statusGA="1/5/1", operatingGA="1/5/2", currentGA="1/5/3", energyGA="1/5/4", read=true, interval=3600] Thing energyswitch AtticOutlet2Switch [ switchGA="2/5/5", statusGA="2/5/6", operatingGA="2/5/7", currentGA="2/5/8", energyGA="2/5/9", read=true, interval=3600] ....

Channels: Number : ga_8_5_0 [ address="8/5/0", dpt="5.010", read=true, interval=3600] Number : ga_8_5_1 [ address="8/5/1", dpt="5.010", read=false, interval=0] Switch : ga_8_5_2 [ address="8/5/2", dpt="1.001", read=true, interval=3600] }

haumacher commented 9 years ago

Thanks for the insights into your approach. The possibility to define Channels directly linked to KNX group addresses is roughly what I suggested in the paragraph

What I'd like to define ... is a binding for the state Items that should be bound to one or many group addresses for sending/receiving state updates and commands

but not discovered from the code analysis.

What I tried to express is that the KNX specific stuff should be restricted to defining (a) the bridge configuration (IP and so on) and (b) the binding of the group addresses to channels. All other aggregation to higher level devices/things I would expect to be technology independent.

When applying this to your .thing example the KNX-specific configuration should be restricted to:

example.things:

Bridge knx:ip:ip1 [ ipAddress="192.168.0.10", portNumber=3671, ... ] {
   Channels:
      # AtticLight3
      Switch : AtticLight3Switch [ address="1/5/0", dpt="1.001"]
      Switch : AtticLight3Status [ address="1/5/1", dpt="1.001"]
      Switch : AtticLight3Operating [ address="1/5/2", dpt="1.001"]
      Number : AtticLight3Current [ address="1/5/3", dpt="5.010"]
      Number : AtticLight3Energy [ address="1/5/4", dpt="5.010"]

      # AtticOutlet2
      ...
}

Strictly speaking, the dpt="1.001" settings are still redundant, because the SmartHome item type Switch already marks this Channel as boolean-valued.

The polling settings like read=true, interval=3600 in your example is also a configuration that is not really KNX related. I think this should better be handled at item level with a technology-independent polling service configured like the in the following snipplet:

example.items:

Number AtticLight3Energy "Consumed Energy [%.1f Wh]" <energy> (Energy_Group) {
   channel="knx:ip:ip1:AtticLight3Energy" 
   pollingInterval="3600" 
}

Here, the Item AtticLight3Energy is linked to the Channel knx:ip:ip1:AtticLight3Energy from above, sorted into the Energy_Group and requested for polling every hour (by an hypothetical generic polling service).

If there is the need to aggregate things further, couldn't that be done in a separate technology-independent binding that provides things like dimmers, energy switches and so on? Could you explain further the problems you ran into when trying to follow the Channel only approach:

In this second iteration of the code base I also attempted to define all these things (dimmers,...) not as Things, but as Channels of the KNX Bridge Thing, so that you can define a Switch channel on the Bridge, instead of a separate Switch Thing underneath the Bridge. I only did that partially, because I rapidly ran into problems with the more complicated Things.

With the thing approach, how is the visualization of the energyswitch things realized? How can I define a group listing all energy consumption and e.g. summing up over several switches?

kgoderis commented 9 years ago

What I'd like to define ... is a binding for the state Items that should be bound to one or many group addresses for sending/receiving state updates and commands

That is possible, by defining multiple channel="..." in the .items file

Strictly speaking, the dpt="1.001" settings are still redundant, because the SmartHome item type Switch already marks this Channel as boolean-valued.

Yes, but this can not be generalised at all. What about DPT 1.002? DPT 1.009 and others.

"The polling settings like read=true, interval=3600 in your example is also a configuration that is not really KNX related.

In fact they are. The polling was included because of some issues/contraints in the OH1 binding whereby there was - for some people - a need to poll for variables on the bus to either initalize Items, and/or poll actors that are not sending updates at all, or frequently enough. Polling itself IMO should stay within the boundaries of a binding because of technology constraints: what works for one given technology, doesn't for another one.

With the thing approach, how is the visualization of the energyswitch things realized? How can I define a group listing all energy consumption and e.g. summing up over several switches?

I thin that is handled through Group Items. Visualisation is inherently not part of the binding at all. And if you need to visualise different values related to a Thing (e.g. on/off, the current energy consumption), then that would be done through different Channels of that Thing.

teichsta commented 9 years ago

Hi Karel et al,

did anything happen meanwhile?

When going through the different solution your second approach comes near to what i'd expect. It only comes near because i wouldn't try to create Things expressing real world KNX devices but rather Things representing the openHAB ItemTypes. Having that said there will Switch-, Dimmer-, Color-, Rollershutter-, etc. Things and generic KNXThing (pretty much like your GAThing) which provices GAs as Channels and can host all simple One-GA-Connections.

What do think?

Best, Thomas E.-E.

kgoderis commented 9 years ago

Hi Thomas

This is how I use it today:

Bridge knx:ip:ip1 [ ipAddress="192.168.0.10", portNumber=3671, localIp="192.168.0.183", ipConnectionType="TUNNEL", readingPause=50, responseTimeOut=1000, readRetriesLimit=3, autoReconnectPeriod=1 ] { Things: Thing energyswitch AtticLight3Switch [ switchGA="1/5/0", statusGA="1/5/1", operatingGA="1/5/2", currentGA="1/5/3", energyGA="1/5/4", read=true, interval=3600] Thing energyswitch AtticOutlet2Switch [ switchGA="2/5/5", statusGA="2/5/6", operatingGA="2/5/7", currentGA="2/5/8", energyGA="2/5/9", read=true, interval=3600] Thing energyswitch AtticValloxSwitch [ switchGA="2/5/0", statusGA="2/5/1", operatingGA="2/5/2", currentGA="2/5/3", energyGA="2/5/4", read=true, interval=3600] Thing rollershutter BathroomKidsBlindControl [ upDownGA="3/3/97", stopMoveGA="3/3/98", positionGA="3/3/100", positionStatusGA="3/3/102", read=true, interval=3600] Thing energyswitch BathroomKidsHalogeneSwitch [ switchGA="1/3/15", statusGA="1/3/16", operatingGA="1/3/17", currentGA="1/3/18", energyGA="1/3/19", read=true, interval=3600] ….

Channels: Number : ga_8_5_0 [ address="8/5/0", dpt="5.010", read=true, interval=3600] Number : ga_8_5_1 [ address="8/5/1", dpt="5.010", read=false, interval=0] Switch : ga_8_5_2 [ address="8/5/2", dpt="1.001", read=true, interval=3600] Switch : ga_8_5_3 [ address="8/5/3", dpt="1.001", read=true, interval=3600] Switch : ga_8_5_4 [ address="8/5/4", dpt="1.001", read=true, interval=3600] Number : ga_8_5_5 [ address="8/5/5", dpt="9.001", read=true, interval=3600] … }

I use Things for the more complex actors, where you have more > 1 GA to encapsulate a certain behaviour, and then Channels for the “simple” ones that can be directly mapped onto an Item

On 08 Jun 2015, at 20:58, Thomas Eichstädt-Engelen notifications@github.com wrote:

Hi Karel et al,

did anything happen meanwhile?

When going through the different solution your second approach comes near to what i'd expect. It only comes near because i wouldn't try to create Things expressing real world KNX devices but rather Things representing the openHAB ItemTypes. Having that said there will Switch-, Dimmer-, Color-, Rollershutter-, etc. Things and generic KNXThing (pretty much like your GAThing) which provices GAs as Channels and can host all simple One-GA-Connections.

What do think?

Best, Thomas E.-E.

— Reply to this email directly or view it on GitHub https://github.com/openhab/openhab2/issues/17#issuecomment-110107744.

madon commented 8 years ago

Hi,

I checked the Source of the 2.0 binding and it seems that there is still no solution for the start/stop dimming issue. It would be nice if this issue is addressd in the 2.0 binding release.

kgoderis commented 8 years ago

err...time to revisit the exact description of the issue. I remember vaguely that some dimmer stuff is not yet implemented, but it has been a long time. I have not progressed the binding (and things that need to be solved outside of the binding) as I await other KNX user's feedback first. (although it runs very well in my env.)

madon commented 8 years ago

the default way of dimming with DPT3.007 is to send a start telegram at start of dimming and an stop telegram at the end. At the moment the knx binding only supports the cyclic mode, where the telegram is send out cyclic. There are dimmers on the market not supporting the cyclic mode and also there are buttons wich only support the start/stop dimming mode like at least the MDT glas buttons. In my case I use a lot MDT buttons and it's not possible to use them to change the volume of the soundsystem or change the color of an RGB LED. So it would be very nice if this gets implemented. I think the KNX binding should at least support the basic KNX devices, and in my opinion a dimmer is an basic device, in the way the KNX standard defines it.

I'll switch to OH2 the next few days and I'll also test the 2.0 KNX binding.

kgoderis commented 8 years ago

For these case you could extend https://github.com/kgoderis/openhab2/blob/knx/addons/binding/org.openhab.binding.knx/src/main/java/org/openhab/binding/knx/handler/DimmerThingHandler.java for example.

I was referring to https://github.com/kgoderis/openhab2/blob/knx/addons/binding/org.openhab.binding.knx/src/main/java/org/openhab/binding/knx/handler/KNXBridgeBaseThingHandler.java#L720 where I did an attempt to deal with secondary telegrams for a given function. Did not complete that at the time, and then reverted back to implementing specially classes like the DimmerThingHandler

mpattera commented 8 years ago

I'm not very into the Things world and my idea is that in 2.x the binding should implement Things that may or may not specialize that much as discussed before, but keeping the possibility to link raw GAs to Items without specifically declare Channels.

The actual approach with 1.x binding is very compact and functional Rollershutter Rollershutter_001 "Rollershutter" (gRollershutters) { knx="0/1/1+<0/5/1,0/1/61,0/1/91+<0/5/91" }

I understand that having defined all about real world aspects somewhere else, the Item definition will be lighter (no GAs in it) and may either became like this (single channels defined through a Bridge) Rollershutter Rollershutter_001 "Rollershutter" (gRollershutters) { channel="knx:shutter001_operation,knx:shutter001_stop,knx:shutter001_position" } or like this (single channels defined through a Thing) Rollershutter Rollershutter_001 "Rollershutter" (gRollershutters) { channel="knx:shutter001:operation,knx:shutter001:stop,knx:shutter001:position" } but there should be the possibility to keep it simple and immediate like now Rollershutter Rollershutter_001 "Rollershutter" (gRollershutters) { channel="knx:0/1/1+<0/5/1,knx:0/1/61,knx:0/1/91+<0/5/91" } or hopefully also keeping the same syntax as before for backward compatibility.

Am I wrong?

ccaramel commented 8 years ago

Hi kgoderis, could you please send your jar file of knx 2.0 binding. regards

kgoderis commented 8 years ago

@ccaramel Sure, whereto ?

ccaramel commented 8 years ago

@kgoderis, thanks I already installed eclipse and compiled it. I'm still testing it but I already notice some problems, especially with GA Things. When defining with PaperUI or HABMIN, linking GA channel to items seems not working. When I physically send a value to KNX TP (ETS) it seems that GA Things does not update items. I also can notice that when adding a IP/KNX gateway, you should enter its physical adress (default one by leaving blank doesn't work).

ccaramel commented 8 years ago

will try to define them manually

kgoderis commented 8 years ago

FYI I never use the PaperUI so I can not comment on that, but the GA Things I defined through the .things DSL were working fine for me, but I do not have them in my operational environment though

ccaramel commented 8 years ago

Thank you for the answer. Damn, it was much more easy to make a link between things under OpenHab1... Things are working better by defining them in manual mode. But I cannot find a way to manually declare a Label for KNX things? could you help? Do you know if there is a way to manually edit links, items or things defined in Karaf? With Openhab1 I was able to make a link between KNX switch and Play/Pause command of Sonos, but now... Do you already implement such type of link? Maybe a good idea could be to make a KNX things that uses the same architecture of the Sonos "control" channel. Regards

kgoderis commented 8 years ago

@ccaramel OH2 needs a bit of adjustment, indeed.

Is this

Dimmer GardenSonosVolume (sonosVolumeGroup) {channel="sonos:CONNECTAMP:Garden:volume", channel="knx:ip:ip1:ga_5_0_7", channel="knx:ip:ip1:ga_5_0_8"}

an example what you are looking for?

With respect to Play/Pause, these are indeed since a long time not controlled anymore with a binary switch, but with a Player item, e.g. in .items you define

Player GardenControl "Garden" (sonosControlGroup,sonosControlGroupGardenControl) {channel="sonos:CONNECTAMP:Garden:control"}

But it will indeed make the "bridge" with KNX more difficult, e.g you will have to write a small Rule that converts the KNX data point you are using into a Play/Pause/... Command you send to the relative Player Item.

ccaramel commented 8 years ago

yeh, muche more complicated than: Switch PlayBureau "Play/Pause" (Sonos, GRdC_Bureau) {sonos="[ON:Bureau:play],[OFF:Bureau:pause]", knx="10/0/0"} with respect to Dimmer example it looks interesting, what kind of DPT are your knx channel? ga_5_0_7 and ga_5_0_8?

The other problem I have is focused on Labels, all my things got "switch" or "KNX Dimmer" label, I'm sure I've missed something but I'm quite new to OH2 ;-)

kgoderis commented 8 years ago
Dimmer : ga_5_0_7 [ address="5/0/7", dpt="3.007", read=false, interval=0]
Number : ga_5_0_8 [ address="5/0/8", dpt="5.001", read=false, interval=0]

These are defined as a channel on the ip gateway Bridge

polarathene commented 8 years ago

@kgoderis Has KNX binding changed with OH2? I've been reading through issues/forum posts/etc all day trying to get KNX working with openHAB(new to openHAB). I've been using the official Docker container with OH2. I've not had much luck with the various configs I've tried, here is one I came across where I've only changed the address. I have installed the binding via Paper UI, it appears to be 1.9.

/openhab/conf/items/knx.things

Group:Switch:OR(ON, OFF) gAllLights "All Lights [%d]"
Group:Switch:OR(ON, OFF) gLights_1st "All Lights 1st Floor [%d]" (gAllLights)

Switch Lights_1st_Room1_L6 "Ceiling Lamp" (gLights_1st) { knx="0/0/1" }

/openhab/conf/sitemaps/knx_sitemap.sitemap:

sitemap knx_sitemap label="KNX Sitemap"
{
    Frame {
        Text item=gAllLights label="All Lights [%d]" icon="light" {
            Switch item=gLights_1st label="All Lights 1st floor" mappings=[ON="All on", OFF="All Off"]
            Group item=gLights_1st
        }
    }
}

I've used the karaf console and run log:set DEBUG org.openhab.binding.knx which has reports in the log file like this:

2016-06-20 05:02:07.810 [DEBUG] [.binding.knx.internal.bus.KNXBinding] - Received groupWrite Event.
2016-06-20 05:02:07.810 [DEBUG] [.binding.knx.internal.bus.KNXBinding] - Received telegram for unknown group address 0/0/1

I get this error for any KNX group address that is being read. The KNX setup was working with a previous platform, so it's due to something I'm doing wrong with openHAB. Any ideas?

In /openhab/conf/services/knx.cfg I have set the following: ip, busaddr, ignorelocalevents, localIp. The connection is for an IP tunnel. Using HABmin 2, I can see that the sitemap I set up works, but UI intereaction does nothing on the KNX end, I don't think anything is being sent out. I have errors in the log:

2016-06-20 05:01:58.304 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'gLights_1st' for widget org.eclipse.smarthome.model.sitemap.Switch
2016-06-20 05:01:58.304 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'gLights_1st' for widget org.eclipse.smarthome.model.sitemap.Switch
2016-06-20 05:01:58.304 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item for widget org.eclipse.smarthome.model.sitemap.Switch
2016-06-20 05:01:58.305 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'gLights_1st' for widget org.eclipse.smarthome.model.sitemap.Group
2016-06-20 05:01:58.306 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'gLights_1st' for widget org.eclipse.smarthome.model.sitemap.Group
2016-06-20 05:01:58.312 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item for widget org.eclipse.smarthome.model.sitemap.Group
2016-06-20 05:01:58.316 [WARN ] [ui.internal.items.ItemUIRegistryImpl] - Group 'null' could not be found.
org.eclipse.smarthome.core.items.ItemNotFoundException: Item 'gLights_1st' could not be found in the item registry

...

2016-06-20 05:01:58.332 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'gAllLights' for widget org.eclipse.smarthome.model.sitemap.Text
2016-06-20 05:01:58.333 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'gAllLights' for widget org.eclipse.smarthome.model.sitemap.Text
2016-06-20 05:01:58.333 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item for widget org.eclipse.smarthome.model.sitemap.Text
2016-06-20 05:01:58.333 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item for widget org.eclipse.smarthome.model.sitemap.Text
2016-06-20 05:01:58.333 [WARN ] [ui.internal.items.ItemUIRegistryImpl] - Group 'null' could not be found.
org.eclipse.smarthome.core.items.ItemNotFoundException: Item 'gLights_1st' could not be found in the item registry
polarathene commented 8 years ago

Well I feel a bit stupid, used the .things extension instead of .items for some reason. I'm no longer getting all the errors, but the UI doesn't seem to update when I trigger the physical switch, nor does the UI seem to send the message to KNX address.

I've spun up a Docker image of node-red and a KNX extension that was easy to test I could send messages which worked. So still missing something with openHAB.

/openhab/conf/items/knx.items: Switch knx_desk_light "Ceiling Lamp2" { knx="<0/0/3" }

/openhab/conf/sitemaps/knx_sitemap.sitemap:

sitemap knx_sitemap label="KNX Sitemap"
{
    Frame {
        Switch item=knx_desk_light label="The Desk Lights" mappings=[1="ON", 0="OFF"]
    }
}

Using cURL as follows works: curl --header "Content-Type: text/plain" --request PUT --data "ON" http://localhost:8080/rest/items/knx_desk_light/state

kgoderis commented 8 years ago

@polarathene Brennan, what you are actually running is the KNX 1.9 binding on OH2 through the compatibility layer. That in itself is fine and Ok to do, but note that the KNX 2.0 binding (as it is proposed in a PR) will differ completely from the KNX 1.x bindings

polarathene commented 8 years ago

@kgoderis Where would I track the progress/eta of 2.0? Are there many issues with the current state of 2.0 or would it be fairly safe to jump straight to that?

ccaramel commented 8 years ago

@kgoderis

Dimmer : ga_5_0_7 [ address="5/0/7", dpt="3.007", read=false, interval=0] Number : ga_5_0_8 [ address="5/0/8", dpt="5.001", read=false, interval=0] These are defined as a channel on the ip gateway Bridge

I seems not be working properly. I've defined 2 channels in IP/KNX: Dimmer : ga_10_2_15 [ address="10/2/15", dpt="3.007", read=false, interval=0] Number : ga_10_2_100 [ address="10/2/200", dpt="5.001", read=false, interval=0] I've defined 1 item: Dimmer VolBureau_U_D "Volume Bureau U/D" (Sonos) {channel="knx:ip:ip1:ga_10_2_15", channel="knx:ip:ip1:ga_10_2_100"} I made a link with web admin interface and I've got some problems: 2016-06-20 18:22:17.650 [ERROR] [ome.core.thing.internal.ThingManager] - Exception occured while calling handler: java.lang.ClassCastException: tuwien.auto.calimero.dptxlator.DPT cannot be cast to tuwien.auto.calimero.dptxlator.DPTXlator3BitControlled$DPT3BitControlled java.util.concurrent.ExecutionException: java.lang.ClassCastException: tuwien.auto.calimero.dptxlator.DPT cannot be cast to tuwien.auto.calimero.dptxlator.DPTXlator3BitControlled$DPT3BitControlled at java.util.concurrent.FutureTask.report(FutureTask.java:122)[:1.8.0_73] at java.util.concurrent.FutureTask.get(FutureTask.java:206)[:1.8.0_73] at org.eclipse.smarthome.core.common.SafeMethodCaller.callAsynchronous(SafeMethodCaller.java:179)[98:org.eclipse.smarthome.core:0.8.0.b5] at org.eclipse.smarthome.core.common.SafeMethodCaller.call(SafeMethodCaller.java:72)[98:org.eclipse.smarthome.core:0.8.0.b5] at org.eclipse.smarthome.core.common.SafeMethodCaller.call(SafeMethodCaller.java:56)[98:org.eclipse.smarthome.core:0.8.0.b5] at org.eclipse.smarthome.core.thing.internal.ThingManager.receiveCommand(ThingManager.java:368)[104:org.eclipse.smarthome.core.thing:0.8.0.b5] at org.eclipse.smarthome.core.items.events.AbstractItemEventSubscriber.receive(AbstractItemEventSubscriber.java:46)[98:org.eclipse.smarthome.core:0.8.0.b5] at org.eclipse.smarthome.core.internal.events.OSGiEventManager$1.call(OSGiEventManager.java:192)[98:org.eclipse.smarthome.core:0.8.0.b5] at org.eclipse.smarthome.core.internal.events.OSGiEventManager$1.call(OSGiEventManager.java:1)[98:org.eclipse.smarthome.core:0.8.0.b5] at org.eclipse.smarthome.core.common.SafeMethodCaller$CallableWrapper.call(SafeMethodCaller.java:170)[98:org.eclipse.smarthome.core:0.8.0.b5] at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_73] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_73] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_73] at java.lang.Thread.run(Thread.java:745)[:1.8.0_73] Caused by: java.lang.ClassCastException: tuwien.auto.calimero.dptxlator.DPT cannot be cast to tuwien.auto.calimero.dptxlator.DPTXlator3BitControlled$DPT3BitControlled at org.openhab.binding.knx.internal.dpt.KNXCoreTypeMapper.toDPTValue(KNXCoreTypeMapper.java:267)[200:org.openhab.binding.knx:2.0.0.qualifier] at org.openhab.binding.knx.handler.KNXBridgeBaseThingHandler.toDPTValue(KNXBridgeBaseThingHandler.java:993)[200:org.openhab.binding.knx:2.0.0.qualifier] at org.openhab.binding.knx.handler.KNXBridgeBaseThingHandler.writeToKNX(KNXBridgeBaseThingHandler.java:871)[200:org.openhab.binding.knx:2.0.0.qualifier] at org.openhab.binding.knx.handler.KNXBridgeBaseThingHandler.writeToKNX(KNXBridgeBaseThingHandler.java:861)[200:org.openhab.binding.knx:2.0.0.qualifier] at org.openhab.binding.knx.handler.KNXBridgeBaseThingHandler.handleCommand(KNXBridgeBaseThingHandler.java:579)[200:org.openhab.binding.knx:2.0.0.qualifier] at org.eclipse.smarthome.core.thing.internal.ThingManager$2.call(ThingManager.java:371)[104:org.eclipse.smarthome.core.thing:0.8.0.b5] at org.eclipse.smarthome.core.thing.internal.ThingManager$2.call(ThingManager.java:1)[104:org.eclipse.smarthome.core.thing:0.8.0.b5] ... 5 more 2016-06-20 18:22:17.666 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'VolBureau_U_D' received command INCREASE 2016-06-20 18:22:17.845 [INFO ] [marthome.event.ItemStateChangedEvent] - VolBureau_U_D changed from 12 to 13 2016-06-20 18:22:17.848 [WARN ] [ome.core.thing.internal.ThingManager] - Cannot delegate update '13' for item 'sonos_PLAY3_RINCON_000E58721D9801400_volume' to handler for channel 'knx:ga:189f2317:string', because no thing with the UID 'knx:ga:189f2317' could be found. 2016-06-20 18:22:17.864 [INFO ] [marthome.event.ItemStateChangedEvent] - sonos_PLAY3_RINCON_000E58721D9801400_volume changed from 12 to 13 2016-06-20 18:22:18.191 [WARN ] [nx.handler.KNXBridgeBaseThingHandler] - Ignoring KNX bus data: couldn't transform to an openHAB type (not supported). Destination='10/2/15', datapoint='command DP 10/2/15 knx:ip:ip1, DPT main 0 id 3.007, low priority', data='0x08' Thus the "VolumeBureau_U_D" item doesn't accept increase command from knx (just 1 step increase/decrease). When sending a 5.001 value on knx, nothing appends.

kgoderis commented 8 years ago

@kgoderis Where would I track the progress/eta of 2.0? Are there many issues with the current state of 2.0 or would it be fairly safe to jump straight to that?

The proposed PR for the KNX 2.0 binding is still to be reviewed in the sense that I have implemented several parallel approaches in the binding with respect to configuration as well as functionality, and that a discussion amongst other KNX users to be had in terms of way forward. It is thus quite experimental, but as author I use in in my operational environment without major issues. The easiest way to go forward is to clone the code from my github repo and compile it.

kgoderis commented 8 years ago

@ccaramel This is a bug. I personally use Dimmer things (knx:dimmer) to do dimming (I have Dimmer channels defined as well, but coincidently I am not using them)

@lewie I copied over your version of the KNXCoreTypeMapper (or at least integrated a patch) some time ago, did you test the 3.007 DPT in your installation?

lewie commented 8 years ago

@kgoderis, as I can see, I did not test 3.007 DPT yet! It is on my Todo-List now.

kgoderis commented 8 years ago

@lewie the error here above should also occur in OH 1.8 as the KNXTypeMapper is quite similar. Maybe there was a change in Calimero cfr the fact that the error here above seems to be internal to Calimero.

ccaramel commented 8 years ago

@kgoderis Hi thank you for your answers. I also noticed that modifying knx:ip bridge things, KNX connection stop OK but doesn't start again. Regards.

polarathene commented 8 years ago

@kgoderis Is this config you shared from a year ago still relevant today? I've not had luck finding documentation on .things configuration in OH2.

kgoderis commented 8 years ago

@polarathene Yet it is. However, there is not documentation as the KNX 2.0 is still "in development" . The only place to get cues from is the actual source code, unfortunately

ccaramel commented 8 years ago

Ok, I've investigated furthermore what it works and doesn't. I can modify a dimmer item value linked to a knx thing directly thru knx bus I can send a 5.001 message on knx bus by modifying the dimmer item value linked to a knx thing I can modify a dimmer item value linked to a sonos volume channel thru sonos app I can modify sonos volume channel by modifying a dimmer item value But when the dimmer item is modified by sonos, it doesn't send its value to knx thing when the dimmer item is modified by knx, it doesn't sent its value to sonos volume channel

it looks like one unique link could be used at the same time Regards.

drummer3333 commented 7 years ago

I'm currently stuck with the problem madon expland on 20 Jan 2016. My MDT switch can't send cyclic DECREASE/INCREASE Telegrams, but I want to dim my DMX lights via OpenHAB 2.

Is this fixed in the 2.0 Binding?

The suggested solution to extend DimmerThingHandler.java ist not possible anymore.

guw commented 7 years ago

Greetings,

I'm new to the game and exploring openHAB2 with KNX. Is there an overview/readme somewhere explaining the status of the KNX binding? For example, I tried the one exposed via AddOn but that installation does not seem to do anything. I was expecting some kind of configuration UI.

Will this be different with the new binding? What is the status of it and how can I test it?

Thanks!

kaikreuzer commented 7 years ago

Hi Gunnar! I'd suggest you use our forum for support, so that the issue tracker is not flooded with support comment. The currently official KNX binding is version 1.9.0, see the documentation here.

kgoderis commented 7 years ago

Content not 100% relevant after the recent refactoring of the KNX 2.0 binding. It will only confuse people