When a groupWrite event is received, the same KNX telegram is sent again to se KNX bus when the internal ItemState is changed.
Is it possible to change this behavior?.
2015-11-29 21:46:37 [DEBUG] [.b.knx.internal.bus.KNXBinding:169 ] - Received groupWrite Event.
2015-11-29 21:46:37 [TRACE] [.b.knx.internal.bus.KNXBinding:212 ] - Added event (item='KNX_Test_Address', type='ON') to the ignore event list
2015-11-29 21:46:37 [TRACE] [.b.knx.internal.bus.KNXBinding:222 ] - Processed event (item='KNX_Test_Address', type='ON', destination='1/0/11')
2015-11-29 21:46:37 [DEBUG] [.core.common.ThreadPoolManager:171 ] - Created thread pool 'safeCall' with size 3-10
2015-11-29 21:46:37 [INFO ] [arthome.event.ItemCommandEvent:43 ] - Item 'KNX_Test_Address' received command ON
2015-11-29 21:46:37 [TRACE] [.b.knx.internal.bus.KNXBinding:102 ] - Received command (item='KNX_Test_Address', command='ON')
2015-11-29 21:46:37 [TRACE] [.b.knx.internal.bus.KNXBinding:122 ] - We received this event (item='KNX_Test_Address', state='ON') from KNX, so we don't send it back again -> ignore!
2015-11-29 21:46:37 [INFO ] [smarthome.event.ItemStateEvent:43 ] - KNX_Test_Address updated to ON
2015-11-29 21:46:37 [DEBUG] [.b.knx.internal.bus.KNXBinding:113 ] - Received update (item='KNX_Test_Address', state='ON')
2015-11-29 21:46:40 [WARN ] [.b.knx.internal.bus.KNXBinding:140 ] - Value 'ON' could not be sent to the KNX bus using datapoint 'command DP 1/0/11 KNX_Test_Address, DPT main 0 id 1.001, low priority' - retrying one time: no confirmation reply received
2015-11-29 21:46:43 [ERROR] [.b.knx.internal.bus.KNXBinding:148 ] - Value 'ON' could not be sent to the KNX bus using datapoint 'command DP 1/0/11 KNX_Test_Address, DPT main 0 id 1.001, low priority' - giving up after second try: no confirmation reply received
2015-11-29 21:46:43 [INFO ] [s.event.ItemStateChangedEvent :43 ] - KNX_Test_Address changed from NULL to ON
Could you please elaborate in how far this is an issue of openHAB 2? I assume the KNX binding is the 1.8 binding, right? Is this behaving differently on an openHAB 1.8 runtime?
I have made a test with 1.8-SNAPSHOT using same items, sitemap and knx
configuration
It seems to work as expected for me.
22:23:26.533 [DEBUG] [.b.knx.internal.bus.KNXBinding:169 ] - Received
groupWrite Event.
22:23:26.549 [TRACE] [.b.knx.internal.bus.KNXBinding:212 ] - Added
event (item='KNX_Test_Address', type='ON') to the ignore event list
22:23:26.549 [INFO ] [runtime.busevents :22 ] -
KNX_Test_Address received command ON
22:23:26.549 [TRACE] [.b.knx.internal.bus.KNXBinding:222 ] - Processed
event (item='KNX_Test_Address', type='ON', destination='1/0/11')
22:23:26.549 [TRACE] [.b.knx.internal.bus.KNXBinding:102 ] - Received
command (item='KNX_Test_Address', command='ON')
22:23:26.549 [TRACE] [.b.knx.internal.bus.KNXBinding:122 ] - We
received this event (item='KNX_Test_Address', state='ON') from KNX, so
we don't send it back again -> ignore!
Am 29.11.2015 um 22:00 schrieb Kai Kreuzer:
Could you please elaborate in how far this is an issue of openHAB 2? I
assume the KNX binding is the 1.8 binding, right? Is this behaving
differently on an openHAB 1.8 runtime?—
Reply to this email directly or view it on GitHub
https://github.com/openhab/openhab2/issues/503#issuecomment-160471026.
@kaikreuzer, @epike,
I have described this Effect here:
https://github.com/openhab/openhab/issues/2508#issuecomment-97488024
Workaround in KNX-Config 1.8:
# Ignore local KNX Events, prevents internal events coming from 'openHAB event bus'
# a second time to be sent back to the 'openHAB event bus'. (optional, defaults to false)
#knx:ignorelocalevents=
knx:ignorelocalevents=true
I have set this option also in 2.0, but it does not have any effect.
ignorelocalevents=true
I have set this option also in 2.0, but it does not have any effect.
2.0, as in OH2.0-with-KNX1.8 ?
This is definitely not the KNX 2.0 binding.
Btw, the KNX2.0 binding does solve this problem already
K
When it is already ported to 2.0, where can I get it? When i build, I only receive the 1.8 Binding.
Am 30.11.2015 um 08:25 schrieb Karel Goderis [email protected]:
I have set this option also in 2.0, but it does not have any effect.
2.0, as in OH2.0-with-KNX1.8 ?
This is definitely not the KNX 2.0 binding.
Btw, the KNX2.0 binding does solve this problem already
K
—
Reply to this email directly or view it on GitHub.
It is a pending PR currently on hold as it is waiting for updates from @teichsta, see https://github.com/openhab/openhab2/pull/21. It is therefore NOT yet part of openHAB 2.
If there is a problem with the 1.8 binding, we should in any case try to fix it.
https://github.com/openhab/openhab/issues/2508 seems to have a long history and I cannot easily understand the changes of the PR https://github.com/openhab/openhab/pull/2613.
@teichsta as you were reviewing and merging them: Could you please check what might be lacking here to make it also work on openHAB 2?
yes, i'll give it a try. However i will able to this on Thursday earliest …
Today i had a look into the code. What i've tested:
Switch Light_GF_Couch "Couch" (GF_Living, Lights) { knx="1/1/1" }. Use the KNX switch to switch the light. The according log looks like this:13:09:21.386 [DEBUG] [.b.knx.internal.bus.KNXBinding:169 ] - Received groupWrite Event.
13:09:21.387 [TRACE] [.o.b.k.i.dpt.KNXCoreTypeMapper:310 ] - toType datapoint DPT = 1.001
13:09:21.387 [TRACE] [.b.knx.internal.bus.KNXBinding:212 ] - Added event (item='Light_GF_Couch', type='ON') to the ignore event list
13:09:21.388 [TRACE] [.b.knx.internal.bus.KNXBinding:222 ] - Processed event (item='Light_GF_Couch', type='ON', destination='1/1/1')
13:09:21.388 [DEBUG] [.b.knx.internal.bus.KNXBinding:169 ] - Received groupWrite Event.
13:09:21.388 [DEBUG] [.b.knx.internal.bus.KNXBinding:201 ] - Received telegram for unknown group address 1/2/0
13:09:21.388 [DEBUG] [.b.knx.internal.bus.KNXBinding:169 ] - Received groupWrite Event.
13:09:21.388 [DEBUG] [.b.knx.internal.bus.KNXBinding:201 ] - Received telegram for unknown group address 1/2/1
13:09:21.390 [INFO ] [runtime.busevents :22 ] - Light_GF_Couch received command ON
13:09:21.390 [TRACE] [.b.knx.internal.bus.KNXBinding:102 ] - Received command (item='Light_GF_Couch', command='ON')
13:09:21.390 [TRACE] [.b.knx.internal.bus.KNXBinding:122 ] - We received this event (item='Light_GF_Couch', state='ON') from KNX, so we don't send it back again -> ignore!
2015-12-03 13:47:12 [DEBUG] [.b.knx.internal.bus.KNXBinding:169 ] - Received groupWrite Event.
2015-12-03 13:47:12 [TRACE] [.o.b.k.i.dpt.KNXCoreTypeMapper:310 ] - toType datapoint DPT = 1.001
2015-12-03 13:47:12 [TRACE] [.b.knx.internal.bus.KNXBinding:212 ] - Added event (item='Couch', type='OFF') to the ignore event list
2015-12-03 13:47:12 [TRACE] [.b.knx.internal.bus.KNXBinding:222 ] - Processed event (item='Couch', type='OFF', destination='1/1/1')
2015-12-03 13:47:12 [INFO ] [arthome.event.ItemCommandEvent:43 ] - Item 'Couch' received command OFF
2015-12-03 13:47:12 [TRACE] [.b.knx.internal.bus.KNXBinding:102 ] - Received command (item='Couch', command='OFF')
2015-12-03 13:47:12 [TRACE] [.b.knx.internal.bus.KNXBinding:122 ] - We received this event (item='Couch', state='OFF') from KNX, so we don't send it back again -> ignore!
2015-12-03 13:47:12 [DEBUG] [.b.knx.internal.bus.KNXBinding:113 ] - Received update (item='Couch', state='OFF')
2015-12-03 13:47:12 [TRACE] [.o.b.k.i.dpt.KNXCoreTypeMapper:491 ] - toTypeClass looking for dptId = 1.001
2015-12-03 13:47:12 [DEBUG] [.b.knx.internal.bus.KNXBinding:138 ] - Wrote value 'OFF' to datapoint 'command DP 1/1/1 Couch, DPT main 0 id 1.001, low priority'
2015-12-03 13:47:12 [INFO ] [s.event.ItemStateChangedEvent :43 ] - Couch changed from NULL to OFF
2015-12-03 13:47:12 [DEBUG] [.b.knx.internal.bus.KNXBinding:169 ] - Received groupWrite Event.
2015-12-03 13:47:12 [DEBUG] [.b.knx.internal.bus.KNXBinding:201 ] - Received telegram for unknown group address 1/2/0
2015-12-03 13:47:12 [DEBUG] [.b.knx.internal.bus.KNXBinding:169 ] - Received groupWrite Event.
2015-12-03 13:47:12 [DEBUG] [.b.knx.internal.bus.KNXBinding:201 ] - Received telegram for unknown group address 1/2/1
Which exactly shows your observation. When changing the item to Switch Couch (gLights) { knx="1/1/1", autoupdate="false" } the log looks a bit different though:
2015-12-03 13:46:05 [DEBUG] [.b.knx.internal.bus.KNXBinding:169 ] - Received groupWrite Event.
2015-12-03 13:46:05 [TRACE] [.o.b.k.i.dpt.KNXCoreTypeMapper:310 ] - toType datapoint DPT = 1.001
2015-12-03 13:46:05 [TRACE] [.b.knx.internal.bus.KNXBinding:212 ] - Added event (item='Couch', type='ON') to the ignore event list
2015-12-03 13:46:05 [TRACE] [.b.knx.internal.bus.KNXBinding:222 ] - Processed event (item='Couch', type='ON', destination='1/1/1')
2015-12-03 13:46:05 [DEBUG] [.b.knx.internal.bus.KNXBinding:169 ] - Received groupWrite Event.
2015-12-03 13:46:05 [DEBUG] [.b.knx.internal.bus.KNXBinding:201 ] - Received telegram for unknown group address 1/2/0
2015-12-03 13:46:05 [DEBUG] [.b.knx.internal.bus.KNXBinding:169 ] - Received groupWrite Event.
2015-12-03 13:46:05 [DEBUG] [.b.knx.internal.bus.KNXBinding:201 ] - Received telegram for unknown group address 1/2/1
2015-12-03 13:46:05 [INFO ] [arthome.event.ItemCommandEvent:43 ] - Item 'Couch' received command ON
2015-12-03 13:46:05 [TRACE] [.b.knx.internal.bus.KNXBinding:102 ] - Received command (item='Couch', command='ON')
2015-12-03 13:46:05 [TRACE] [.b.knx.internal.bus.KNXBinding:122 ] - We received this event (item='Couch', state='ON') from KNX, so we don't send it back again -> ignore!
which exactly shows the desired behaviour. It looks like the AutoUpdateBinding in OH2/ESH behaves differently as in OH1 it works without configuring the autoupdate binding. Interestingly the KnxBindingGenericBindingProvider implements AutoUpdateBindingProvider but doesn't publish the service, so autoUpdate() is never called and thus is always evaluated to TRUE.
Will have to dig deeper into the details which i cannot do now. Or probably @lewie could take over from here?
Best, Thomas E.-E.
I observe here quite interested !!!
There is too little time yet.
Would try it next weekend.
Helmut
I have build a solution thats works for me, I change the ignoreEventList in KNXBinding.java to a Map and added a timestamp to clean up. Now I added a parameter to isEcho method, so that I can decide to remove the event only on internalReceiveUpdate method. Additionally I implemented a little clean up method that removes all events after a second.
Erik
@epike,
I have implemented it for OH1 ( see in KNXBinding.java groupWrite(ProcessEvent e)):
You can identify every "Echo" by its sender.
If openHAB is the sender ignore it.
To identify use knx:busaddr=, so you don't need to handle a Map and you don't need to cleanup anything.
too busy yet sorry!
Best, Helmut
I've set knx:ignorelocalevents=true but my log now is spammed with warnings like this
19:31:41.455 [WARN ] [.binding.knx.internal.bus.KNXBinding] - Ignoring local Event, received from my local Source address 0.0.0 for Group address 1/2/10.
As I have explicitly activated this behavior, I would deem that warning unnecessary. I would like to see other warnings though, so I would rather not to set the log level to INFO. Could that be changed and maybe only logged in DEBUG?
Or maybe I did not understand the issue well enough and it is a valid warning after all?
As I coded this, I was not clear if these local events are a Bug or a miss configuration.
More and more it is clear, local events should be filtered by default.
Yes, makes sense to set this WARN to DEBUG now.
Will do that next time.
I'm running OH2 20160214 snapshot.
1) Item definition Switch Luce_011 "Luce" <light> (gLuci,gA4B_01) { knx="1/1/11+<1/5/11" }
The command was originated from KNX bus. Command and update events are fired and the command is sent again on the KNX bus.
2016-02-18 14:01:05.590 [DEBUG] [.binding.knx.internal.bus.KNXBinding] - Received groupWrite Event.
2016-02-18 14:01:05.593 [TRACE] [g.knx.internal.dpt.KNXCoreTypeMapper] - toType datapoint DPT = 1.001
2016-02-18 14:01:05.595 [TRACE] [.binding.knx.internal.bus.KNXBinding] - Added event (item='Luce_011', type='OFF') to the ignore event list
2016-02-18 14:01:05.598 [TRACE] [.binding.knx.internal.bus.KNXBinding] - Processed event (item='Luce_011', type='OFF', destination='1/1/11')
2016-02-18 14:01:05.606 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'Luce_011' received command OFF
2016-02-18 14:01:05.615 [TRACE] [.binding.knx.internal.bus.KNXBinding] - Received command (item='Luce_011', command='OFF')
2016-02-18 14:01:05.617 [TRACE] [.binding.knx.internal.bus.KNXBinding] - We received this event (item='Luce_011', state='OFF') from KNX, so we don't send it back again -> ignore!
2016-02-18 14:01:05.635 [DEBUG] [.binding.knx.internal.bus.KNXBinding] - Received update (item='Luce_011', state='OFF')
2016-02-18 14:01:05.644 [TRACE] [g.knx.internal.dpt.KNXCoreTypeMapper] - toTypeClass looking for dptId = 1.001
2016-02-18 14:01:05.658 [DEBUG] [.binding.knx.internal.bus.KNXBinding] - Wrote value 'OFF' to datapoint 'command DP 1/1/11 Luce_011, DPT main 0 id 1.001, low priority'
The command was originated from OH bus. Command and update events are fired and the command is sent on the KNX bus two times.
2016-02-18 16:24:04.261 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'Luce_011' received command ON
2016-02-18 16:24:04.295 [INFO ] [marthome.event.ItemStateChangedEvent] - Luce_011 changed from OFF to ON
2016-02-18 16:24:04.296 [TRACE] [.binding.knx.internal.bus.KNXBinding] - Received command (item='Luce_011', command='ON')
2016-02-18 16:24:04.298 [TRACE] [g.knx.internal.dpt.KNXCoreTypeMapper] - toTypeClass looking for dptId = 1.001
2016-02-18 16:24:04.298 [DEBUG] [.binding.knx.internal.bus.KNXBinding] - Received update (item='Luce_011', state='ON')
2016-02-18 16:24:04.300 [TRACE] [g.knx.internal.dpt.KNXCoreTypeMapper] - toTypeClass looking for dptId = 1.001
2016-02-18 16:24:04.307 [DEBUG] [.binding.knx.internal.bus.KNXBinding] - Wrote value 'ON' to datapoint 'command DP 1/1/11 Luce_011, DPT main 0 id 1.001, low priority'
2016-02-18 16:24:04.314 [DEBUG] [.binding.knx.internal.bus.KNXBinding] - Wrote value 'ON' to datapoint 'command DP 1/1/11 Luce_011, DPT main 0 id 1.001, low priority'
2) Item definition Switch Luce_011 "Luce" <light> (gLuci,gA4B_01) { knx="1/1/11+<1/5/11", autoupdate="false" }
The command was originated from KNX bus. Command event is fired, no indesidered KNX sending.
2016-02-18 14:56:51.383 [DEBUG] [.binding.knx.internal.bus.KNXBinding] - Received groupWrite Event.
2016-02-18 14:56:51.386 [TRACE] [g.knx.internal.dpt.KNXCoreTypeMapper] - toType datapoint DPT = 1.001
2016-02-18 14:56:51.388 [TRACE] [.binding.knx.internal.bus.KNXBinding] - Added event (item='Luce_011', type='OFF') to the ignore event list
2016-02-18 14:56:51.391 [TRACE] [.binding.knx.internal.bus.KNXBinding] - Processed event (item='Luce_011', type='OFF', destination='1/1/11')
2016-02-18 14:56:51.394 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'Luce_011' received command OFF
2016-02-18 14:56:51.398 [TRACE] [utoupdate.internal.AutoUpdateBinding] - Won't update item 'Luce_011' as it is not configured to update its state automatically.
2016-02-18 14:56:51.402 [TRACE] [.binding.knx.internal.bus.KNXBinding] - Received command (item='Luce_011', command='OFF')
2016-02-18 14:56:51.404 [TRACE] [.binding.knx.internal.bus.KNXBinding] - We received this event (item='Luce_011', state='OFF') from KNX, so we don't send it back again -> ignore!
The command was originated from OH bus. Command event is fired, no indesidered KNX sending.
2016-02-18 16:40:53.324 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'Luce_011' received command ON
2016-02-18 16:40:53.329 [TRACE] [utoupdate.internal.AutoUpdateBinding] - Won't update item 'Luce_011' as it is not configured to update its state automatically.
2016-02-18 16:40:53.336 [TRACE] [.binding.knx.internal.bus.KNXBinding] - Received command (item='Luce_011', command='ON')
2016-02-18 16:40:53.339 [TRACE] [g.knx.internal.dpt.KNXCoreTypeMapper] - toTypeClass looking for dptId = 1.001
2016-02-18 16:40:53.346 [DEBUG] [.binding.knx.internal.bus.KNXBinding] - Wrote value 'ON' to datapoint 'command DP 1/1/11 Luce_011, DPT main 0 id 1.001, low priority'
2016-02-18 16:40:53.508 [INFO ] [marthome.event.ItemStateChangedEvent] - Luce_011 changed from OFF to ON
3) It seems the AutoUpdateBinding is firing the update event after a command event because this expression is false only when autoupdate="false" is specified in the Item definition.
if (autoUpdate && command instanceof State) {
postUpdate(itemName, (State) command);
} else {
logger.trace("Won't update item '{}' as it is not configured to update its state automatically.", itemName);
}
Is there any solution to this problem? oh2 is flooding the knx bus with clone events, which seems like a serious problem to me...
Is someone looking into the problem right now? I'm happy to give it a try myself if someone could give me a little introduction what is known about the issue and what has been done/tried already.
Same issue here:
17:12:22.443 [WARN ] [.binding.knx.internal.bus.KNXBinding] - Ignoring local Event, received from my local Source address 0.0.0 for Group address 1/1/41.
@joltcoke Did you try alternating between multicast address and the IP address of your gateway?
In the KNX.cfg you can set
ip=
and/or
localIp=
However, if I fill in the ip= the LAN IP (192.x.x.x) an error pops up in the log stating it is not a multicast address.
I see the same problem in my setup. I'm guessing it might have been the reason for my MDT Rollershutter actor freezing up. Hope that's solved now the messages don't get repeated.
This behaviour is still present in OH2b4 (and the included KNX binding). It seems to relay many items back to the KNX bus (e.g. every switch that is configured).
I don't understand why received bus events are echoed at all (this is not intended for knx, and OH1 does not behave like this, as far as I know). If someone needs this behavior (and I definitely don't know any scenario which would fit for this), there should be a rule to solve this needs.
In fact, I'm about to upgrade to OH2 and had to realize, that as long as both openHAB instances are online, openHAB1 gets every knx item update twice (OH2 has no rules yet, ignorelocalevents is set to true), so I had to shutdown OH2. As I will make use of OH2-bindings, I have to get many informations for updating .items and .sitemap.
afaik at the current date the knx-binding version 2.0 is not yet officially merged to OH2; so everybody is still stuck with the 1.8 binding, which shows this behavior. Having the 2.0-bindings in review already, I guess no-one really will invest much time in fixing this issue in 1.8, right? However, 2.0-binding are in review for quite some time now...
Can't wait for the 2.x KNX Binding myself either :)
That double (echoed) message is bugging me (although not a big issue).
I send the status updates to the mqtt-eventbus also and the event is registered twice :(
@SuperOok
The KNX 1.8 binding works well!
To prevent echo effect you must set knx:ignorelocalevents=true.
And it is a good idea to set like knx:busaddr=15.15.249, for identifying the binding itself.
If you still have problems with the KNX 1.8 binding, please sign up.
The KNX 2.0 binding I can not judge.
I wish a very long time for the KNX 2.0 binding too!!!
Edit: The KNX 1.8 binding works well in OH1.8
@lewie ignorelocalevents is set to true and a busaddr is also assigned, oh2 is still sending out clone events.
Same here... clone events are generated with KNX 1.9 Binding in OH2
ignorelocalevents=true & busaddr=1.2.200 are already set
Log shows:
"2016-10-19 09:17:36.438 [WARN ] [.binding.knx.internal.bus.KNXBinding] - Ignoring local Event, received from my local Source address 1.2.200 for Group address 1/0/3.
2016-10-19 09:17:36.447 [WARN ] [.binding.knx.internal.bus.KNXBinding] - Ignoring local Event, received from my local Source address 1.2.200 for Group address 1/0/3."
Double entry for every command...
@lewie knx:ignorelocalevents is working fine, the issue is in the AutoUpdate! see my post of Feb 18th
@joltcoke, @mpattera,
OK, you are right, the KNX 2.0 binding since 2014 still does not work as expected.
So next days I will analyze the the KNX 1.8 binding. ;-)
@lewie Awesome! Thanks for your help. Let me know if I can support you in any way!
OK, you are right, the KNX 2.0 binding since 2014 still does not work as expected.
@lewie errr...? Helmut, do you have something specific in mind?
@kgoderis, you are right! Bash me on head... this sounds definitely not fair against you and all the other involved programmers, Karel sorry!!
For clarification:
Some parts with the things and GUI parts are not ready implemented, and so the KNX 2 binding currently cannot replace the old one, where the item definition simply is written in .items file yet.
OH2 is heavily in development and it takes time until all the threads (bundles) can work together perfect and everything is documented. (Even though I sometimes can not wait)
Your work is really, really great and I love your source code, the new KNX 2 binding will work great when all works round in OH2.
I was hoping I could help improve the KNX 2 binding with, but too many cooks only spoil the mush. As I have seen I delay the progress rather more.
As you can see here many users need a smooth working KNX binding in OH2 now. So it makes sense to search for and correct the bug in KNX1.8? Any other ideas?
@joltcoke, @mpattera, @DimitrisSar, @DimitrisSar, @udo1toni, @dka23, @RichardPasmans, @punkadiddle, @epike
I need some Testers in OH 2.0 and OH 1.8, please:
Edit:
Use this jar now:
https://github.com/openhab/openhab2-addons/issues/503#issuecomment-255582861
Edit2:
For Testers, please use: (no more use compatibilityOH2, it's obsolete)
https://github.com/lewie/openhab/raw/knx1-patch-for-oh2-2-test/org.openhab.binding.knx-1.9.0-SNAPSHOT.jar
Installed it with bundle:install
2016-10-22 21:33:57.939 [INFO ] [nx.internal.connection.KNXConnection] - KNXBinding configuration is not present. Please check your configuration file or if not needed remove the KNX addon.
knx.cfg is of course in the usual place. Reactivating the old bundle works just fine.
@joltcoke, I put it in addons folder (from there it is started automatically) and configured conf\services\knx.cfg, that's it.
I did not install knx bundle with Paperui before.
@lewie I will be running some tests on both OH1 & OH2 (beta 4 and snapshots) and I will report soon (hopefully later today) with trace logs, configs, etc.
Thanx for the update lewie!
@kgoderis : Keep up the great work on the development of KNX Binding 2.x ! :) We want to see that also 👍
@joltcoke, @mpattera, @DimitrisSar, @DimitrisSar, @udo1toni, @dka23, @RichardPasmans, @punkadiddle, @epike
The first jar was not compatible with OH1. Please use this now:
https://github.com/lewie/openhab/raw/lewie-knx1.8-test-patch-2/org.openhab.binding.knx-1.9.0-SNAPSHOT.jar
For testing with OH2 you MUST set a new configuration switch, add in knx.cfg:
# Compatibility Mode for openHAB 2 (optional, defaults in openHAB 1 to false)
compatibilityOH2 = true
Added:
For information: When openHAB is in a later state and KNX 2.x is ready, KNX 1.8 binding will be useless. Then it makes absolutely no sense to maintain two bundles anymore.
First test with:
OpenHab 2 - Beta 4 (Clean Install via apt-get) on Raspberry Pi 3
Installed the new binding in the following way:
1) Downloaded https://github.com/lewie/openhab/raw/lewie-knx1.8-test-patch-2/org.openhab.binding.knx-1.9.0-SNAPSHOT.jar into /usr/share/openhab2/addons/org.openhab.binding.knx-1.9.0-SNAPSHOT.jar (changed file ownership to openhab:openhab)
2) From Karaf console, feature:install openhab-runtime-compat1x & feature:install openhab-transport-serial to resolve module requirements (it wouldn't load otherwise)
3) log:set TRACE org.openhab.binding.knx & log:set TRACE tuwien.auto.calimero
4) Restart OH2
/etc/openhab2/services/knx.cfg:
compatibilityOH2=true
busaddr=1.2.200
ignorelocalevents=true
type=ROUTER
/etc/openhab2/items/test.items:
Switch P11_Light "P11 Light" {knx="1.001:1/0/10+<1/2/10"}
/etc/openhab2/sitemaps/test.sitemap:
sitemap test label="test"
{Frame label="test" { Switch item=P11_Light } }
The switch works fine (on/off) but I do get in my /var/log/openhab2/openhab2.log the following (for 1 action):
2016-10-23 18:08:06.745 [TRACE] [.binding.knx.internal.bus.KNXBinding] - Received command (item='P11_Light', command='ON')
2016-10-23 18:08:06.751 [DEBUG] [.binding.knx.internal.bus.KNXBinding] - Received update (item='P11_Light', state='ON')
2016-10-23 18:08:06.752 [TRACE] [g.knx.internal.dpt.KNXCoreTypeMapper] - toTypeClass looking for dptId = 1.001
2016-10-23 18:08:06.753 [INFO ] [tuwien.auto.calimero ] - [Thread-48] link 224.0.23.12:3671: send message to 1/0/10, wait for confirmation
2016-10-23 18:08:06.756 [DEBUG] [.binding.knx.internal.bus.KNXBinding] - Wrote value 'ON' to datapoint 'command DP 1/0/10 P11_Light, DPT main 0 id 1.001, low priority'
2016-10-23 18:08:06.755 [DEBUG] [.binding.knx.internal.bus.KNXBinding] - Received groupWrite Event.
2016-10-23 18:08:06.756 [DEBUG] [tuwien.auto.calimero ] - [Thread-48] link 224.0.23.12:3671: cEMI L-Data.ind from 1.2.200 to 1/0/10, low priority hop count 6 repeat tpdu 00 81
2016-10-23 18:08:06.758 [WARN ] [.binding.knx.internal.bus.KNXBinding] - Ignoring local Event, received from my local Source address 1.2.200 for Group address 1/0/10.
2016-10-23 18:08:06.758 [DEBUG] [tuwien.auto.calimero ] - [Thread-48] KNXnet/IP Routing 224.0.23.12:3671: sending cEMI frame, non-blocking, attempt 1
2016-10-23 18:08:06.759 [INFO ] [tuwien.auto.calimero ] - [KNXnet/IP receiver] link 224.0.23.12:3671: indication from 1.2.200
2016-10-23 18:08:06.760 [DEBUG] [tuwien.auto.calimero ] - [Thread-48] link 224.0.23.12:3671: send to 1/0/10 succeeded
2016-10-23 18:08:06.762 [DEBUG] [tuwien.auto.calimero ] - [Thread-48] process link 224.0.23.12:3671: group write to 1/0/10 succeeded
2016-10-23 18:08:06.881 [DEBUG] [.binding.knx.internal.bus.KNXBinding] - Received groupWrite Event.
2016-10-23 18:08:06.881 [INFO ] [tuwien.auto.calimero ] - [KNXnet/IP receiver] link 224.0.23.12:3671: indication from 15.15.255
2016-10-23 18:08:06.883 [TRACE] [g.knx.internal.dpt.KNXCoreTypeMapper] - toType datapoint DPT = 1.001
2016-10-23 18:08:06.883 [TRACE] [.binding.knx.internal.bus.KNXBinding] - Added event (item='P11_Light', type='ON') to the ignore event list
2016-10-23 18:08:06.885 [TRACE] [.binding.knx.internal.bus.KNXBinding] - Processed event (item='P11_Light', type='ON', destination='1/2/10')
2016-10-23 18:08:06.886 [DEBUG] [.binding.knx.internal.bus.KNXBinding] - Received update (item='P11_Light', state='ON')
2016-10-23 18:08:06.887 [TRACE] [.binding.knx.internal.bus.KNXBinding] - We received this event (item='P11_Light', state='ON') from KNX, so we don't send it back again -> ignore!
I will proceed with more tests and provide more info soon.
BR,
Dim
@DimitrisSar,
Ahrg... yes, I have forgotten to mention feature:install openhab-runtime-compat1x & feature:install openhab-transport-serial Thanks!
Your log looks good, doesn't it? :-)
As I can see, in my environment it works as expected, never doubled events on the KNX-bus.
I have tested like:
import org.openhab.core.library.types.*
import org.openhab.core.persistence.*
import org.openhab.model.script.actions.*
rule "knxTest_postUpdate"
when
Time cron "0/15 * * * * ?"
then
var isOFF = testSwitch.state == OFF
if(isOFF) {
testSwitch.postUpdate( ON )
} else {
testSwitch.postUpdate( OFF )
}
end
rule "knxTest_sendCommand"
when
Time cron "30/30 * * * * ?"
then
var isOFF = testSwitch.state == OFF
if(isOFF) {
testSwitch.sendCommand( ON )
} else {
testSwitch.sendCommand( OFF )
}
end
// testing if values are passed if value hasn't changed
rule "knxTest_nochange"
when
Time cron "45/45 * * * * ?"
then
testSwitch.sendCommand( OFF )
testSwitch.sendCommand( OFF )
testSwitch.sendCommand( OFF )
testSwitch.postUpdate( OFF )
testSwitch.postUpdate( OFF )
testSwitch.postUpdate( OFF )
end
@lewie
Log looks good, everything is working fine (and really fast)... No more clone events ! 👍 👍 👍
...but I still get that pointless warning (around the middle of the log above):
2016-10-23 18:08:06.758 [WARN ] [.binding.knx.internal.bus.KNXBinding] - Ignoring local Event, received from my local Source address 1.2.200 for Group address 1/0/10.
I don't know what is causing this... It's not a huge problem but it would be nice if I could get rid of it :) (maybe change it from WARN to DEBUG level? :))
By the way: I need some help with OH1... (1.8.3)
I deployed the org.openhab.binding.knx-1.9.0-SNAPSHOT.jar file in my /usr/share/openhab/addons folder but OH1 does not load it up. When I use the distribution jar (org.openhab.binding.knx-1.8.3.jar), OH1 loads it up just fine (with 1.8.3.jar, I do get the same "ignoring local event" warning also in OH1 log)
I saw one difference (1.8.3 vs 1.9.0-Snapshot) in the /OSGI-INF/knxbinding.xml file (immediate="true") but I didn't have the time to play around with the jar file and to modify it to see if removing it would help...
BR,
Dim
@DimitrisSar, it is a result of the filter entry _ignorelocalevents=true_. Is another discussion to change this to _debug_ or _trace_.
Hmm, _immediate="true"_ is the right value. I had never problems with a new installed OH 1.8.3, I cannot reproduce.
I would start a new OH 1.8.3 only with org.openhab.binding.knx-1.9.0-SNAPSHOT.jar on the same hardware. Maybe there is a old bundle or old configuration which transverses... ;-)
Ok. I will try again with a completely new OH1 installation.
Anyway... with your new org.openhab.binding.knx-1.9.0-SNAPSHOT.jar I don't have anymore double entries in my OH2 log for every action ! :)
I went from (2 log entries for 1 event):
2016-10-23 20:32:00.753 [WARN ] [.binding.knx.internal.bus.KNXBinding] - Ignoring local Event, received from my local Source address 1.2.200 for Group address 1/0/10.
2016-10-23 20:32:00.754 [WARN ] [.binding.knx.internal.bus.KNXBinding] - Ignoring local Event, received from my local Source address 1.2.200 for Group address 1/0/10.
to (1 log entry for 1 event):
2016-10-23 18:08:06.758 [WARN ] [.binding.knx.internal.bus.KNXBinding] - Ignoring local Event, received from my local Source address 1.2.200 for Group address 1/0/10.
This helps me since I used to get double entries in my MQTT event bus before... not anymore :)
Thanx @lewie 👍
BR,
Dim
Ps: Edit to upload the 2 logs
Old_KNX.txt = Based on OH2 Beta 4 + binding.knx-1.9.0.b4
New_KNX.txt = Based on OH2 Beta 4 + binding.knx-1.9.0-SNAPSHOT
@DimitrisSar,
see and test jar from here https://github.com/openhab/openhab/pull/4724#issuecomment-257236498. No more use compatibilityOH2, it's obsolete.
Test performed. All work good and fast and without events echo !
Base Scenario: OH 2.0.0-Snapshot Build # 560 with KNX Binding version 1.9.0.201610280119 from Cloudbees
Base Log: Old_KNX.txt
New Scenario: OH 2.0.0-Snapshot Build # 560 with KNX Binding 1.9.0-SNAPSHOT (1.9.0.201610310808) from https://github.com/lewie/openhab/raw/knx1-patch-for-oh2-2-test/org.openhab.binding.knx-1.9.0-SNAPSHOT.jar
New Log: New_KNX.txt
Also posted here for faster review:
2016-10-31 13:30:55.198 [TRACE] [.binding.knx.internal.bus.KNXBinding] - Received command (item='P11_Light', command='ON')
2016-10-31 13:30:55.204 [TRACE] [g.knx.internal.dpt.KNXCoreTypeMapper] - toTypeClass looking for dptId = 1.001
2016-10-31 13:30:55.208 [INFO ] [tuwien.auto.calimero ] - calimero.link.224.0.23.12:3671: send message to 1/0/10, wait for confirmation
2016-10-31 13:30:55.209 [DEBUG] [tuwien.auto.calimero ] - calimero.link.224.0.23.12:3671: cEMI L-Data.ind from 1.2.200 to 1/0/10, low priority hop count 6 tpdu 00 81
2016-10-31 13:30:55.210 [DEBUG] [tuwien.auto.calimero ] - KNXnet/IP Routing 224.0.23.12:3671: add to multicast loopback frame buffer: L-Data.ind from 1.2.200 to 1/0/10, low priority hop count 6 tpdu 00 81
2016-10-31 13:30:55.210 [DEBUG] [.binding.knx.internal.bus.KNXBinding] - Wrote value 'ON' to datapoint 'command DP 1/0/10 P11_Light, DPT main 0 id 1.001, low priority'
2016-10-31 13:30:55.211 [DEBUG] [tuwien.auto.calimero ] - KNXnet/IP Routing 224.0.23.12:3671: sending cEMI frame seq 0, non-blocking, attempt 1 (channel 0) 06 10 05 30 00 11 29 00 bc e0 12 c8 08 0a 01 00 81
2016-10-31 13:30:55.221 [DEBUG] [tuwien.auto.calimero ] - calimero.link.224.0.23.12:3671: send to 1/0/10 succeeded
2016-10-31 13:30:55.222 [DEBUG] [tuwien.auto.calimero ] - process 224.0.23.12:3671: group write to 1/0/10 succeeded
2016-10-31 13:30:55.222 [DEBUG] [tuwien.auto.calimero ] - KNXnet/IP Routing 224.0.23.12:3671: discard multicast loopback cEMI frame: L-Data.ind from 1.2.200 to 1/0/10, low priority hop count 6 tpdu 00 81
2016-10-31 13:30:55.337 [DEBUG] [.binding.knx.internal.bus.KNXBinding] - Received groupWrite Event.
2016-10-31 13:30:55.337 [DEBUG] [tuwien.auto.calimero ] - calimero.link.224.0.23.12:3671: indication from 1.1.1
2016-10-31 13:30:55.339 [TRACE] [g.knx.internal.dpt.KNXCoreTypeMapper] - toType datapoint DPT = 1.001
2016-10-31 13:30:55.339 [TRACE] [.binding.knx.internal.bus.KNXBinding] - Added event (item='P11_Light', type='ON') to the ignore event list
2016-10-31 13:30:55.340 [TRACE] [.binding.knx.internal.bus.KNXBinding] - Processed event (item='P11_Light', type='ON', destination='1/2/10')
2016-10-31 13:30:55.343 [TRACE] [.binding.knx.internal.bus.KNXBinding] - Received update (item='P11_Light', state='ON')
2016-10-31 13:30:55.343 [TRACE] [.binding.knx.internal.bus.KNXBinding] - We received this event (item='P11_Light', state='ON') from KNX, so we don't send it back again -> ignore!
BR,
Dim
Ps: The latest Calimero libs are v2.4-Snapshot (https://sourceforge.net/projects/calimero/files/Client%20GUI%20%28all%20in%20one%29/)
Perfect! Thank you for your quick tests. 👍
We use calimero-core not calimero-gui! I generated the calimero-core-2.3-beta.jar from the current master branch. There is no version 2.3 released yet:
https://github.com/calimero-project/calimero-core
Calimero 2.2 sends the "repeatFlag" to KNX-bus.
In calimero-core-2.3-beta.jar we have solved it:
https://github.com/calimero-project/calimero-core/issues/32
Best Regards
Helmut
I don't know details but I saw that the calimero-gui archive includes multiple jars (also calimero-core-2.4-SNAPSHOT.jar)
I don't know if you can use them... I also cannot find the 2.4 snapshot version on github... Anyway... All is good with your KNX Binding v1.9.0.201610310808 ! :)
Ah, didn't know about _calimero-core-2.4-SNAPSHOT.jar_ in calimero-gui.
Then I would not have to generate myself, no matter.
By the way, I think that the Java8 branch of Calimero (here: https://github.com/calimero-project/calimero-core/tree/feat/jse-embd8-c1) is more updated and it includes even a newer version (2.4-dev)...
Maybe Boris does not update anymore the https://github.com/calimero-project/calimero-core repository?
Can you use the Java8 version?
Now that https://github.com/openhab/openhab/pull/4736 is merged, I assume this issue can be closed?
@lewie
New Test performed. Something is broken with the new KNX Snapshot binding...
I have communication to the KNX Bus in Router mode, it reads the autorefresh statuses upon startup from the status GAs but it does not react on On/Off commands from BasicUI or HABPanel.
Base Scenario: OH 2.0.0-Snapshot Build # 581 with KNX Binding version 1.9.0.201611120211 from Cloudbees
Base Log: Old_KNX.txt
New Scenario: OH 2.0.0-Snapshot Build # 581 with KNX Binding 1.9.0-SNAPSHOT (1.9.0.201611111441) from https://github.com/lewie/openhab/raw/9e96c8998e67808b174c8860f7d37a9a19fbf9aa/org.openhab.binding.knx-1.9.0-SNAPSHOT.jar
New Log:
2016-11-12 06:22:47.341 [TRACE] [.binding.knx.internal.bus.KNXBinding] - 1. internalReceiveCommand from openHAB (item='P11_Light', command='OFF', operatingEnvironmentIsFelix = 'null'
Edit: Same behavior also on my parallel installation with OH2-Beta 4...
2016-11-12 06:52:50.836 [TRACE] [.binding.knx.internal.bus.KNXBinding] - 1. internalReceiveCommand from openHAB (item='P11_Light', command='ON', operatingEnvironmentIsFelix = 'true'
Events don't get triggered and no action is taken by OH2.
@DimitrisSar,
I used the snapshot and this testconfig:
_busaddr=15.15.244_
_ignorelocalevents=true_
_type=ROUTER_
in OH1 and OH2 no problems!
The displayed _'1. internalReceiveCommand' (was 'Received command')_ and _2. internalReceiveUpdate (was 'Received update')_ is ok.
If no action is taken in OH2 it is another issue, because it should look like:
OH1:
2016-11-16 16:43:07.749 [DEBUG] [.b.knx.internal.bus.KNXBinding] - Received groupWrite Event.
2016-11-16 16:43:07.751 [TRACE] [.o.b.k.i.dpt.KNXCoreTypeMapper] - toType datapoint DPT = 1.001
2016-11-16 16:43:07.752 [TRACE] [.b.knx.internal.bus.KNXBinding] - Added event (item='TestSwitch', type='ON') to the ignore event list
2016-11-16 16:43:07.755 [TRACE] [.b.knx.internal.bus.KNXBinding] - Processed event (item='TestSwitch', type='ON', destination='1/1/10')
2016-11-16 16:43:07.755 [TRACE] [.b.knx.internal.bus.KNXBinding] - 1. internalReceiveCommand from openHAB (item='TestSwitch', command='ON', operatingEnvironmentIsFelix = 'false'
2016-11-16 16:43:07.760 [TRACE] [.b.knx.internal.bus.KNXBinding] - We received this event (item='TestSwitch', state='ON') from KNX, so we don't send it back again -> ignore!
OH2:
2016-11-16 16:26:54.330 [DEBUG] [.binding.knx.internal.bus.KNXBinding] - Received groupWrite Event.
2016-11-16 16:26:54.330 [TRACE] [g.knx.internal.dpt.KNXCoreTypeMapper] - toType datapoint DPT = 1.001
2016-11-16 16:26:54.331 [TRACE] [.binding.knx.internal.bus.KNXBinding] - Added event (item='TestSwitch', type='ON') to the ignore event list
2016-11-16 16:26:54.331 [TRACE] [.binding.knx.internal.bus.KNXBinding] - Processed event (item='TestSwitch', type='ON', destination='1/1/10')
2016-11-16 16:26:54.331 [TRACE] [.binding.knx.internal.bus.KNXBinding] - 1. internalReceiveCommand from openHAB (item='TestSwitch', command='ON', operatingEnvironmentIsFelix = 'true'
2016-11-16 16:26:54.336 [TRACE] [.binding.knx.internal.bus.KNXBinding] - 2. internalReceiveUpdate from openHAB (item='TestSwitch', state='ON')
2016-11-16 16:26:54.338 [TRACE] [.binding.knx.internal.bus.KNXBinding] - We received this event (item='TestSwitch', state='ON') from KNX, so we don't send it back again -> ignore!
Background:
// openHAB1: After internalReceiveCommand from openHAB1, NO internalReceiveUpdate is triggered later.
// openHAB2: After internalReceiveCommand from openHAB2, ALWAYS internalReceiveUpdate is triggered later.
// In openHAB2 we ignore internalReceiveCommand and wait for receiving the internalReceiveUpdate from openHAB,
// then only this is sent to the KNX bus by openHAB.
Sorry for testing this very late - however it seems that with this snapshot items of type "Dimmer" and "Switch" are not transmitted to KNX bus anymore when changed from Basic UI or REST or the mobile app.
Otherwise I can also confirm that I cannot see any echoed events anymore.
@dka23, Thank you very much for testing!
Are you sure, Switch is not transmitted to KNX bus anymore? In my default new OH2 Installation Switch always is triggert. But Dimmer only with:
{ autoupdate="true", knx="5.001:1/5/2+<5.001:1/5/7" }
Please tell me your installed Bindings.
It would be helpfull, to get a Log, when a Switch is triggered and when a Dimmer is triggered.
Once more Background:
Dimmer is sending a command when triggered.
Switch is sending a command when triggered an additionally a postUpdate is triggered.
When Dimmer is configured with autoupdate="true", additionally a postUpdate is triggered like Switch does do that.
Testing with https://github.com/lewie/openhab/blob/KNX-OH1andOH2-test/org.openhab.binding.knx-1.9.0-SNAPSHOT.jar?raw=true
My item definition looks like:
Switch Licht_KG_Technik "Licht Technik [%s]" (G_Licht, G_KG_Technik) { knx="1/1/0+<2/1/0" }
... and I get no output sent to KNX.
However, changing this to
Switch Licht_KG_Technik "Licht Technik [%s]" (G_Licht, G_KG_Technik) { autoupdate="true", knx="1/1/0+<2/1/0" }
... makes the output work as it was before.
The same is true for dimmers (as you already explained ...).
I'm not sure if this is the intended behaviour?
BTW this is on OpenHAB2 b4.
@dka23,
Thank You for testing!
It is not really a intended behavior. :-(
I must explore further the openHAB background.
Will stick to the subject and keep you up to date.
I can confirm that with a change from 1.8 to recent 1.9 binding the behavior of the binding changed. It is the other way round:
rule "Dielenlicht"
when
Item Licht_Diele changed
then
logInfo("Diele","Licht_Diele changed: "+Licht_Diele.state)
end
The item Licht_Diele is
Dimmer Licht_Diele <dimmablelight>{knx="<0/2/6+0/5/6, 0/3/6, 0/4/6+0/6/6"}
The rule is never triggered, while the log shows
22:01:06.283 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'Licht_Diele' received command 100
Only when I add autoupdate=true to the item, then the rule gets triggered:
22:03:21.739 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'Licht_Diele' received command 100
22:03:21.751 [INFO ] [marthome.event.ItemStateChangedEvent] - Licht_Diele changed from 0 to 100
22:03:21.780 [INFO ] [eclipse.smarthome.model.script.Diele] - Licht_Diele changed: 100
So do I have to add these autoupdates to all items?
Next to that behavior I have a lot of messages of this kind in my log:
22:05:38.209 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Cannot read value for item 'Bewegungsmelder_Flur' from KNX bus: timeout waiting for group read response: timeout
22:05:38.211 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Remaining retries for address '0/7/4' = '1'
Is this related?
Hi
Unfortunately I have a similiar issue with OpenHAB 2 and the latest stable KNX 1.9 binding.
My dimmer config looks like this:
Dimmer dim1 "dimmer1" (dimmer_group) { knx="2/0/82,2/1/82,2/2/82" }
Every change on a slider in the web gui leads to 4 knx telegrams:

after that, the DALI gateway in my case sends back the status after the change, and this cause also another message send by openhab:

@sucre87, have you tested this:
Dimmer dim1 "dimmer1" (dimmer_group) {autoupdate="true", knx="2/0/82,2/1/82,2/2/82" }
or
Dimmer dim1 "dimmer1" (dimmer_group) {autoupdate="false", knx="2/0/82,2/1/82,2/2/82" }
@lewie:
I have the following behavior:
with:
OpenHAB does not reply to every incoming status telegram, but does also not react on update telegrams. Let's say the dimmer channel will be modified over knx and sends the new status (XX %), OpenHAB does not update the item.
If I trigger an update via rule with sendCommand, the dimmer receives the correct value, but the item itself (in OpenHAB) stays at his previous state.
E.g. dim1 = 60%. triggering sendCommand(dim1, 0%) will switch off the light, but the dim1 item stays at 60%.
If I use postUpdate(dim1, 0%) the light switches off and the item changes it's state to 0%.
Very weired, since I've used postUpdate to update item states in the past, without sending a command out of OpenHab.
For know it works as a workarround, to be able to use KNX with OpenHAB 2.0 at all. Hope that the KNX 2 plugin will be released soon, in order to be able to update item states based on incoming messages from the KNX bus.
Sounds this behavior familiar or do I have an error in my config?
Thanks
just for the sake of completeness:
a contact device configured like this updates his state also with autoupdate="false".
Contact contact1 "contact [MAP(door.map):%s]" { autoupdate="false",knx="6/1/0" }
compared to a switch item which only reacts on changes coming from the KNX bus if autoupdate="true", but this with the unwanted "echo" from OH2 back to KNX.
Just to add to this.
I'm using openhab2, with the kn. binding 1.9, and am seeing this issue also.
Unfortunately I'm a newbie to openhab, so I'm still learning about the various scripting options, so for now, I'll just have to live with the duplicate telegrams.
If I can help verify the 2.0 binding, or anything else, please let me know
@wzinet, have you tested autoupdate="true/false":
Dimmer dim1 "dimmer1" (dimmer_group) {autoupdate="true", knx="2/0/82,2/1/82,2/2/82" }
or
Dimmer dim1 "dimmer1" (dimmer_group) {autoupdate="false", knx="2/0/82,2/1/82,2/2/82" }
Is there a roadmap for the KNX 2 binding?
I also switch after a while to openHAB 2 with a Raspberry Pi 3 and the openhabian image. But know I have the same problem with resending of the knx command to the bus.
I found the problem because my dimmer lights (DALI) not working correctly
addons.cfg:
package = expert
remote = true
legacy = true
binding = http,knx,http1,knx1,modbus1,samsungtv
ui = habmin
persistence = db4o,rrd4j
transformation = map
misc = openhabcloud
knx.cfg:
ignorelocalevents=true
type=TUNNEL
port=3671
timeout=1000
compatibilityOH2=true
any news?
i have problems with double telegramms.
i use OH2 with binding-knx1 - 1.10.0 and Weinzirl 730 ip interface
I hope we get a KNX2 Binding soon! https://github.com/openhab/openhab2-addons/pull/2323#pullrequestreview-50719804
I'm having issues with duplicated telegrams too.
But only with items, that don't have a status address associated. Temperature Items for example.
Most of my switch items or the rollershutter items don't have these problems.
@cveith, have you tested autoupdate="true/false" like:
Dimmer dim1 "dimmer1" (dimmer_group) {autoupdate="true", knx="2/0/82,2/1/82,2/2/82" }
Did you set in knx.cfg:
ignorelocalevents=true
AND another busaddr as 0.0.0
busaddr=15.15.229
Additionally, you can see from where the echos are initiated while ETS is logging.
@lewie: ignorelocalevents is set to true and an individual busaddr is set as well.
i've tested an workaround and it works for me.
As only items with not status address are affected in my scenario i've changed the items which are only receiving data to the following:
Number Heizung_Stellwert { knx="+<5.001:12/3/0" }
The telegrams of 12/3/0 are not replayed by openhab after the change.
Setting autoupdate="false" stopped replaying the telegrams. But it also stopped updating the item states, which also prevents openhab from storing the data in the persistence databases.
Adding just the +< in front of the address works best for me at present.
I think this can be closed not that we have the KNX2 binding in place.
Same for me...
Following solve the problem for me
knx.cfg
ignorelocalevents=true
*.items
I add to all Dimmer items autoupdate="false" ... Until now, I haven't seen any negative effects
Dimmer itemname "text [(%.2f)]" (gGroupe) { autoupdate="false", knx="1/2/3+<1/2/4,<1/2/5,1/2/6"}
my versions:
## Release = Raspbian GNU/Linux 10 (buster)
## Kernel = Linux 4.19.66-v7l+
## Platform = Raspberry Pi 4 Model B Rev 1.1
openHAB 2.4.0-1 (Release Build)
openhab-binding-knx1 x 1.13.0 x x x Started x openhab-addons-legacy-2.4.0 x KNX Binding (1.x)
openhab-binding-knx x 2.4.0 x x Uninstalled x openhab-addons-2.4.0 x KNX Binding
Most helpful comment
I hope we get a KNX2 Binding soon! https://github.com/openhab/openhab2-addons/pull/2323#pullrequestreview-50719804