I have almost 2 years running OH. After a crash of my RPI I thought it was time to upgrade to OH2.
I’ve tried everything but I get the KNX connection not working. Sonos and Yamaha is not a problem except for KNX
My openhab log
tuwien.auto.calimero.exception.KNXIllegalArgumentException: non-valid routing multicast /192.168.1.12
# KNX gateway IP address
# (optional, if serialPort or connection type 'ROUTER' is specified)
# Local KNX Binding bus address.
# Use it, when two or more openHAB Instances are connected to the same KNX bus.
# (optional, defaults to 0.0.0)
# Ignore local KNX Events, prevents internal events coming from
# 'openHAB event bus' a second time to be sent back to the 'openHAB event bus'.
# Note: To send back events second time is a Bug, but for backward compatibility, the behavior is not changed.
# For new installations, its recommend to set "ignorelocalevents=true"
# (optional, defaults to false)
# KNX IP connection type. Could be either TUNNEL or ROUTER (optional, defaults to TUNNEL)
# Note: If you cannot get the ROUTER mode working (even if it claims it is connected),
# use TUNNEL mode instead with setting both the ip of the KNX gateway and the localIp.
# KNX gateway port (optional, defaults to 3671)
# Note: If you use eibd, setting to 6720
# Local endpoint to specify the multicast interface, no port is used (optional)
# Serial port of FT1.2 KNX interface (ignored, if ip is specified)
# Valid values are e.g. COM1 for Windows and /dev/ttyS0 or /dev/ttyUSB0 for Linux
# Pause in milliseconds between two read requests on the KNX bus during
# initialization (optional, defaults to 50)
# Timeout in milliseconds to wait for a response from the KNX bus (optional,
# defaults to 10000)
# Number of read retries while initialization items from the KNX bus (optional,
# defaults to 3)
# Seconds between connect retries when KNX link has been lost
# 0 means never retry, it will only reconnect on next write or read request
# Note: without periodic retries all events will be lost up to the next read/write
# (optional, default is 0)
### Auto refresh feature
# Number of entries permissible in the item refresher queue.
# (optional, defaults to 10000)
# Number of parallel threads for refreshing items. (optional, defaults to 5)
# Seconds to wait for an orderly shutdown of the auto refresher's
# ScheduledExecutorService. (optional, defaults to 5)
# Use NAT (Network Address Translation)
# (optional; defaults to false)
I use a Gira Router.
In OH1.8.3 I used the same configuration, and it was no problem and this worked perfectly.
Does anyone have an idea ?
I tried on a NAS, Windows, and an RPI but same results everywhere.
MY KNX binding is working. When I send a value to the bus, this fine. However openhab not receive updates from the knx bus.
I suspect that something is wrong with my toplogy.
My configuration is as follows:
(to enter into the Karaf console: "ssh openhab@localhost -p 8101" (password: habopen))
Maybe some stale config parameters are stored and are causing the problems…
You should make sure that you have ignorelocalevents = true to avoid telegram echo.
Even with this parameter set, the older version of the KNX Binding had some problems (sending 2 times the telegram to the KNX Bus). See here: https://github.com/openhab/openhab2-addons/issues/503 (by the way… I need to do some more testing @lewie )
Regarding the status updates: Are you using a dummy application in your ETS?
You should have the GAs mapped to that dummy app in order for the GIRA KNX/IP Router to allow them to pass the filter table (and finally reach openHAB 2)
This is strange… Are you using Tunnel or Router type of connection from OH1?
This means that the telegrams are crossing the GIRA Router and they reach to the openHAB (1) Host. So you don’t need to worry about the filter table (or the dummy app).
I can’t think what could be wrong when you use OH2 with the status updates…
Try enabling TRACE for the KNX binding and post the output… maybe we see there something regarding telegrams reaching OH2 but being dropped (for some strange reason…)
No, I haven’t used the NUC yet. I see that some models accept a Hard Disk (which is good versus SD Cards)
Note: If you are planning to keep opanHAB in a simple / medium complexity level, you will be fine with the rPi3
If you want more advanced stuff to be deployed (like persistence, graphing, heavy logging, etc) you may want to consider a cheap laptop with a hard disk. The SD Cards can become corrupted when used heavily.
I have a Laptop running OH2 in parallel to the rPi3 and I am planning to move everything there (mostly for reliability, not necessarily performance)