This did work and sent the correct alarm-flag via bus, but since today (no changes at all to my installation at that time!) it doesn’t - there’s not even a reaction of some kind within knx-binding anymore?
2022-11-02 11:08:02.058 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'AlertFrost' received command OFF
2022-11-02 11:08:02.059 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'AlertFrost' predicted to become OFF
2022-11-02 11:08:02.071 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'AlertWind1' received command OFF
2022-11-02 11:08:02.072 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'AlertWind1' predicted to become OFF
==> /var/log/openhab/openhab.log <==
2022-11-02 11:08:03.735 [TRACE] [nx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.1.4' to '0/1/33' with value '[0, 3, 0, 2]'
2022-11-02 11:08:03.824 [TRACE] [nx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.1.4' to '0/2/43' with value '[0]'
2022-11-02 11:08:03.826 [DEBUG] [.internal.handler.DeviceThingHandler] - onGroupWrite Thing 'knx:device:local:1_1_3-Jalousieaktor16' received a GroupValueWrite telegram from '1.1.4' for destination '0/2/43'
2022-11-02 11:08:03.829 [TRACE] [.internal.handler.DeviceThingHandler] - onGroupWrite Thing 'knx:device:local:1_1_3-Jalousieaktor16' processes a GroupValueWrite telegram for destination '0/2/43' for channel 'knx:device:local:1_1_3-Jalousieaktor16:OGFlurDL'
2022-11-02 11:08:03.831 [TRACE] [g.knx.internal.dpt.KNXCoreTypeMapper] - toType datapoint DPT = 1.001
also strange:
since then, all my KNX-devices are marked as “offline”, if I configure them with their topology-addresses:
do you still have adresses available for that ip tunnel that are not used you know openhab and ets connecting at the same time ? maybe try restart that ip tunnel module see what happens
wait i dont understand so you have 0/4/4 wich you send off with a rule what is the connection to 1/2/0 and 0/4/0 ??
restart the ip tunnel device and try again if you say that everything worked before. Nothing has changed to the knx binding also the knx so most of the time this is a networking issue or device issue.
ok, use case for 0/4/x: these are alerts, which non-KNX devices send (frost-alert, wind-alert, …). I connected these with my external rollershutters - they go up, if either there’s an alert - or a “OFF”-warning isn’t sent within 5mins.
1/2/0 is just a “turn lights on”-GA, to proof, connection between OH3 and KNX bus is working.
I restarted the Weinzierl IP Interface. Now openHAB has 1.1.250 and ETS hast 1.1.251.
I set 0.0.0 within the KNX bridge - and now at least my “real” KNX devices (Gira Actuators mostly) are “ONLINE” again - as the KNX binding is now able to retrieve their information and status again.
and: sendCommand to a alarm-GA also works, openHAB ignores it no more:
2022-11-02 13:08:39.847 [TRACE] [.internal.handler.DeviceThingHandler] - Handling command 'OFF' for channel 'knx:device:local:1_1_245-openHAB:Frostalarm'
2022-11-02 13:08:39.849 [TRACE] [.knx.internal.channel.KNXChannelType] - getCommandSpec testing Keys '[ga]' for command 'OFF'
2022-11-02 13:08:39.850 [TRACE] [.knx.internal.channel.KNXChannelType] - getCommandSpec key 'ga' uses expectedTypeClass 'class org.openhab.core.library.types.OnOffType' which isInstance for command 'OFF' and dpt '1.005'
2022-11-02 13:08:39.852 [TRACE] [nx.internal.client.AbstractKNXClient] - writeToKNX groupAddress '0/4/4', commandSpec 'org.openhab.binding.knx.internal.channel.WriteSpecImpl@32e1b5'
2022-11-02 13:08:39.853 [TRACE] [nx.internal.client.AbstractKNXClient] - sendToKNX mappedValue: 'no alarm' groupAddress: '0/4/4'
2022-11-02 13:08:39.875 [DEBUG] [nx.internal.client.AbstractKNXClient] - Wrote value 'OFF' to datapoint 'command DP 0/4/4 'knx:ip:local', DPT 1.005, low priority' (0. attempt).
2022-11-02 13:08:39.876 [TRACE] [.internal.handler.DeviceThingHandler] - rememberRespondingSpec handled commandSpec for '0/4/4' size '4' added 'true'
2022-11-02 13:08:39.884 [TRACE] [.internal.handler.DeviceThingHandler] - Handling command 'OFF' for channel 'knx:device:local:1_1_245-openHAB:Windalarm1'
2022-11-02 13:08:39.885 [TRACE] [.knx.internal.channel.KNXChannelType] - getCommandSpec testing Keys '[ga]' for command 'OFF'
2022-11-02 13:08:39.886 [TRACE] [.knx.internal.channel.KNXChannelType] - getCommandSpec key 'ga' uses expectedTypeClass 'class org.openhab.core.library.types.OnOffType' which isInstance for command 'OFF' and dpt '1.005'
2022-11-02 13:08:39.887 [TRACE] [nx.internal.client.AbstractKNXClient] - writeToKNX groupAddress '0/4/0', commandSpec 'org.openhab.binding.knx.internal.channel.WriteSpecImpl@1f82d43'
2022-11-02 13:08:39.888 [TRACE] [nx.internal.client.AbstractKNXClient] - sendToKNX mappedValue: 'no alarm' groupAddress: '0/4/0'
2022-11-02 13:08:39.909 [DEBUG] [nx.internal.client.AbstractKNXClient] - Wrote value 'OFF' to datapoint 'command DP 0/4/0 'knx:ip:local', DPT 1.005, low priority' (0. attempt).
2022-11-02 13:08:39.910 [TRACE] [.internal.handler.DeviceThingHandler] - rememberRespondingSpec handled commandSpec for '0/4/0' size '4' added 'true'
2022-11-02 13:08:39.978 [TRACE] [nx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.1.2' to '1/1/103' with value '[0]'
==> /var/log/openhab/events.log <==
2022-11-02 13:08:39.829 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'AlertFrost' received command OFF
2022-11-02 13:08:39.833 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'AlertWind1' received command OFF
2022-11-02 13:08:39.834 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'AlertFrost' predicted to become OFF
2022-11-02 13:08:39.837 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'AlertWind1' predicted to become OFF
thanks for your help - strange, I didn’t need a reboot for my IP Interface since years now… but ok.
Knx bus was never meant to be hammered by fast processing programs like openhab. Its not uncommon that even a simple house have atleast 2-4 knx ip routers for each bus deployed keeping in mine each bus can only handle 50 telegrams per second. Anything over that you need buffering and devices that can handle all that
Didn’t have any problems since almost 2 years after that post!
Group Monitor running does not even catch close to that many telegrams - apart from “programming” a device. In “normal running mode” I have not more than 750 telegrams in about 30mins. My actuators send every 5 to 10 mins. openHAB regularly (every 2mins) sends the alerts and the time on the bus, but apart from that it’s “normal” behaviour with some ON/OFF/Dimmer GA telegrams and perhaps some “bulk”-telegrams with “turn off all lights”, but that’s rarely - as I usually use group-GAs (Sammeladressen) within KNX for that also, not only openHAB-group-items.
my 2 cents are: perhaps the Weinzierl IP interface did have some issues with the device adresses (ETS got another address) and that’s where openHAB got a hickup, which in turn caused some whatever misconfiguration on the interface… I’ll keep a eye on that and perhaps switch to a KNX router sometime. I figure, these things can be configured more stable.
maybe you are right in your situation where you say 700 telegram every 30 min.
Now reading for fun the manual of your device wich is not sold anymore says what your 2 cents are thinking maybe this helps ?
ETS Connection Manager
The KNX IP Interface 730 can only act as an interface to KNX
when the IP-configuration is valid.
The following configuration steps are required:
Select the button ‘Settings’ on the tab ‘Communication’ in the
main window of ETS4. All available connections are listed under
‘Discovered connections’. Select the desired connection.
The KNX IP Interface 730 supports up to 5 simultaneous tunneling connections. Each connection uses its own physical address.
The address of the first tunneling connection can be changed
within the ‘Local Interface Settings’.
Physical addresses of the additional tunneling connections can
be assigned directly on the device.
This is done by pressing the learn key on the device (3) longer
than one second. After that, the Learn-LED will start blinking,
which indicates that the assignment of the additional addresses
was successful.
The additional addresses are assigned as follows:
Tunneling connection 2 receives the next higher address than
tunneling connection 1, tunneling connection 3 the next higher
address than tunneling connection 2 etc..
For example:
Device address: 1.1.255 (address within ETS topology)
Connection 1: 1.1.250 (address within local settings)
Connection 2: 1.1.251 (assigned by learn key)
Connection 3: 1.1.252 (assigned by learn key)
Connection 4: 1.1.253 (assigned by learn key)
Connection 5: 1.1.254 (assigned by learn key)
All addresses have to be unique and valid within the sub line of
the interface. Note: be careful not to assign the same address as
the device address for a connection. The device address can be
changed within the topology view of the ETS software.
For new devices (i.e. in the factory settings state), only the additional individual address of the first connection is active with the
address 15.15.250. To support multiple concurrent connections
additional address assignment is required.
also another thing maybe not important but that bite me is having dhcp dealing with ip you should consider fixed it if possible
edit oh and you said the adresses changed when you reconnected … thinking maybe you really need to learn the connections to it like the manual says
The Interface gets a “static” IP from my DHCP.
and yes, it is configured as you found out. and it’s quite “uncommon” that new connections get device adresses that way. Normally, the device addresses did stay “forever” - so perhaps the Weinzierl got indeed a hick-up and this in turn broke something within the KNX binding logic. So I’ll have an eye on it.
