Matthias Alphart

I'm curious what the use case for that would be. Always_callback was initially meant for devices sending periodically on their own or sending things like scene numbers that are meant...

This sounds more like an InfluxDB issue then 🙃

Just found this and well, it seems to be a known problem for quite some time. 😦 https://github.com/influxdata/influxdb/issues/6878

I think the influx issue should be specifically handled in the `influxdb` integration - by some expiration timer or such writing to the db regularly. Its not a KNX issue...

Hi 👋! What would be the usecase for this? On a HA restart the previous value should already have been sent on its last update before the shutdown.

Hi 👋! If one is more comfortable in looking at Java there is also the Calimero project having Knx USB support. https://github.com/calimero-project @kistlin I personally do not have any thoughts...

Hi! For Application layer information I'd look at `03_03_07 Application Layer v01.06.02 AS` - in xknx we have the `xknx.telegram.apci` module for the different services. This can be passed to...

Yes sounds reasonable. The L_Data.req example here is a CEMI Frame - so this is what you get by creating a `xknx.telegram.Telegram` and encapsule it in a cemi frame `xknx.knxip.cemi_frame.CEMIFrame`...

Sure for an initial proof of concept implementation this sounds reasonable. Later we can always rename `knxip_interface` to `knx_interface` and maybe consolidate the ConnectionConfig classes somehow so the KNXInterface class...

Yes it seems no TunnelingACK is sent on USB, which is good. I guess L_DATA.con confirmation CEMI frames will be received (and should be waited for) just like on IP...