KNX - listening group address

[rak]

Hello guys,

I was absent for about 6 month and come back and see what happened really a lot seen from v1.0 which I used before ,-). You are amazing. Well done. I managed to get a lot of new functionalities running in my smart home and I am looking forward to 1.4. soon.

One feature which was lacking since the MIsterhouse days (ancient history) is to know from which of the two buttons my daughter turns of the light. Why, because when it is after 9pm and it is turned of from the switch near the bed she is going to sleep and I can react on this with a dedicated rule (e.g. turn the sonos into sleep mode).

In MH there was a possibility to get the physical adress of the device which initiated the change. In OH this is not possible. Thats why I tried the following.

In KNX:

• Created two different group addresses. One for the switch near the door (1/1/1) and one for the switch at the bed (1/1/2).
• On the door one address is used for sending (1/1/1) and the other as listening address (1/1/2)
• On the bed switch the other address is used for sending (1/1/2) and the listening address is (1/1/1)
• The actor switching the light is set to both group addresses

In KNX this is working as expected. On both (hardware) switches I can turn on/off the light.

In OH:

• created two Switch Items
• Switch Light_FF_Kind1 "Deckenlicht" <blight> (FF_Kind1, Lights)         { knx="1/1/1+1/1/2" }
  
• Switch Light_FF_Kind1_vomBett "Deckenlicht" <blight> (FF_Kind1, Lights) { knx="1/1/2+1/1/1" }

I expected to have both items always the same status in OH as both are listening to each other GA. But exactly this is not happening.

What went wrong? Any hints? Is this the way how listening group addresses should work or did I made  mistake?

Kind regards.

Ralf

[rak]

Hello guys,

I investigated further on this end. It seems only one Switch item is updated in OH. I did a dedicated set of items

test.items

Group gTest "Testitems"

Switch Test1 (gTest) { knx="7/1/1+7/1/2" }

Switch Test2 (gTest) { knx="7/1/2+7/1/1" }

If you send messages with ETS to the bus the following happens:

start condition in OH: Test1 and Tes2 are OFF, Both GA 7/1/1 and 7/1/2 are set to [0]

send in ETS 7/1/1->[1] : Switch Item Test1 is ON as expected

send in ETS 7/1/2->[0] : Switch Item Test1 is OFF as expected

send in ETS 7/1/1->[0] : Switch Item Test1 stays OFF as expected

send in ETS 7/1/2->[1] : Switch Item Test1 is ON as expected, Test2 stays OFF unexpectedly

I would expect with the above definition both Switch Items have always the same state when changes coming form the KNX bus.

I have no clue whats going on here. Can someone help? Or do I have a total misunderstanding of the concept of "listening GA"?

Kind regards.

Ralf

[Karel Goderis]

Kai

What if we add a definition like

{ knx="@1/1/1+1/1/2" }

to rather update the item (which should be of StringType) with the source physical address, instead of the value itself? It does partly away with abstracting KNX in the OH userland space

an alternative could be to include a PA syntax to the binding config so that the right switch (if more > 1 listening to the same address) is updated based on the source that is emitting the telegram

something like

{ knx="1.2.3@1/1/1+1/1/2" }

K

--
You received this message because you are subscribed to the Google Groups "openhab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhab+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
Visit this group at http://groups.google.com/group/openhab.
For more options, visit https://groups.google.com/groups/opt_out.

[Kai Kreuzer]

Hi Ralf,

I agree that this should work - looks like a bug to me…

Regards,

Kai

[rak]

Ok. What to do? I must admit I am not familiar with github? Creating an issue? Confirmed ? I assume I need to have an account on github. I will give it a try.

[Thomas Eichstädt-Engelen]

Hi RaK,

yes, you'll have to have an account. But never mind a) it is cool to have an account at Github ;-) and b) you can use for as federated login provider for many other (dev centric) pages ;-)

Cheers,

Thomas E.-E.

On 05 Jan 2014, at 20:13, rak <ralf.k...@googlemail.com> wrote:

> Ok. What to do? I must admit I am not familiar with github? Creating an issue? Confirmed ? I assume I need to have an account on github. I will give it a try.
>

[staeh...@googlemail.com]

It seems to me, that this bug also is responsible for ignoring messages from central function. In my case, "All Off"-Switch is just recognized from the last switch item in list. All other switches remain in the "old" state. Therefore just one item is updated to the correct state and the OH GUI is in inconsistent state.
Would be very nice, if this "feature" will be removed soon ;-)

[mac...@zrodlana.com]

Hello,

what I had experienced with the KNX binding is, that in case of two identical KNX group addresses, only one is updated. 

So, in case of Ralf's:

Group gTest "Testitems"

Switch Test1 (gTest) { knx="7/1/1" }

Switch Test2 (gTest) { knx="7/1/1" }

Only one switch is updated correctly.

I had expierenced taht trying to read energy meter into two separate items. 

I'm using OH 1.4.

Do you have same experience?

Kind regards,

Maciej

[mac...@zrodlana.com]

Hi Michael,

In case you would need the same data in two different items, I would suggest the following:

demo.items:

Group gTest "Testitems"

Switch Test1 (gTest) { knx="7/1/1+7/1/2" }

Switch Test2 (gTest) 

demo.rules:

// every time the switch is changing the state we do the update of the second switch 

rule "Switch change"

when

      // every time the KNX is updating the Test1 switch

Item Test1 changed

then

    if (Test1.state == ON)

        { sendCommand(Test2,ON)

        } else

       { sendCommand(Test2,OFF)

        } 

end

With the above you could keep updated both switches and also do some other required actions.

That's what I did with my power readings.

Please give a try and let me know the results.

Cheers,

Maciej

Hi Maciej,
I have exactly the same experience you described. Are you trying to fix it? I'ld highly appreciate that, because at the moment I have no good idea to work around.
Kind regards, Michael

[Thomas Eichstädt-Engelen]

Hi,

thanks for noticing … could you probably update the existing issue https://github.com/openhab/openhab/issues/762 to keep of this?

Thanks,

Thomas E.-E.