[SOLVED] KNX 2 - Binding how to send ntp Date and Time to the KNX bus (to two different group addresses)

I did read through the various posts regarding KNX and NTP time (and had my own post for the KNX 1.X Binding), but did not come up with a solution how I can send the time (to KNX group address 10/0/0) and the date (to KNX group address 10/0/1) using the time I get via the NTP binding.

In OH 2.3 with the KNX 1.X binding and the NTP (version 2) binding my item (and thing) definition was like this:

Thing ntp:ntp:germany  [ hostname="nl.pool.ntp.org", refreshInterval=60, refreshNtp=30, timeZone="America/Detroit", locale="de_DE"  ]
DateTime ntpDate  "Date  [%1$td.%1$tm.%1$tY %1$tH:%1$tM]" {channel="ntp:ntp:germany:dateTime",knx="10.001:10/0/0,11.001:10/0/1"}

So in a first attempt I changed my OH 2.4 KNX 2.4.0 binding settings to this ( no change for the NTP Thing):

KNX Thing/Channel definition:
Type datetime      : ntpDate  "Date  [%1$td.%1$tm.%1$tY %1$tH:%1$tM]"  [ ga="10.001:10/0/0,11.001:10/0/1" ]

(This did not produce any error.)
ā€¦ and the changed the item definition to this:

DateTime ntpDate  "Date  [%1$td.%1$tm.%1$tY %1$tH:%1$tM]" {channel="ntp:ntp:germany:dateTime",channel="knx:device:bridge:Datum_Device:ntpDate"}

With that I donā€™t see any error reported, but I also do not get the time send to the KNX bus.
I do see the ntpDate contain the correct time as I can see this via sitemap/app.

My next guess inspired from this -> [KNX2] Send date+time to KNX produces endless loop post was to set up two channels and add them to the Item:

Thing device Datum_Device 
    {
        Type datetime      : knxntpDate    [ ga="11.001:10/0/1" ]
        Type datetime      : knxntpTime    [ ga="10.001:10/0/0" ]
    }
DateTime ntpDate  "Gruna  [%1$td.%1$tm.%1$tY %1$tH:%1$tM]" {channel="ntp:ntp:germany:dateTime",channel="knx:device:bridge:Datum_Device:knxntpDate",channel="knx:device:bridge:Datum_Device:knxntpTime"}

But this unfortunately did not help as well. I am now out of ideas how I can send the time and the date on a regular base to the KNX bus (with the KNX2 binding).
Does anyone of you have a solution and can post it. (I have to make use of the NTP time.)
(In my KNX 1.X binding solution I did not have to run any rule to send the time to the KNX bus.)

Any hint is appreciated.

  1. You are in Germany, why use timeZone=ā€œAmerica/Detroitā€ instead of ā€œEurope/ā€¦ā€?
  2. Do you really want to sent the time to the bus each minute (refreshInterval=60)?
  3. ga=ā€œ10.001:10/0/0,11.001:10/0/1ā€ canā€™t work, as a Thing can only send to 1 ga, so you need your second approachā€¦ this should send to 10/0/0 though.
  4. Is your Thing defined inside the Bridge? If not the definition is incorrect.
  5. You donā€™t want your Thing to respond to read requests, so you should use datetime-control instead of datetime.
  6. The solution: put the ntp channel behind the two knx channelsā€¦ :wink:
1 Like

Thanks @HSorgYves - for your hints.
To your first point - the ā€œAmericaā€ setting was done to test that something is actually send to the bus.
Iā€™ll change it as soon as I had success sending the time and the date to KNX.
2) Yes - I want to send it once a minute. I think the frequency should be OK, itā€™s not a lot of traffic.
3) Thanks for confirming this. I was hoping I could simply re-use the old logic.
4) Yes the Thing is part of the Bridge (similar to the other 10 Thingā€™s I have set up)
5) OK - I did not really understand the difference between the ā€¦ and the ā€¦-control channels. Iā€™ll change it to your suggestion.
6) Will do this and hopefully this is the solution. Iā€™ll post the result.

Thanks for the great input!

That was quicker than I though!
Your suggestion to put the NTP channel at the end of the Item solved the problem.
Anyone feel free to explain why that is the case. :slight_smile:

I am happy with the solution - Thanks!!

Mind sharing your final thing and item definition here for reference?

Sure - happy to share it -
<openHAB 2.4 / NTP Binding (v2) / KNX Binding (v2) >

NTP Channel definition (complete content of my ntp.things file):

Thing ntp:ntp:germany  [ hostname="nl.pool.ntp.org", refreshInterval=60, refreshNtp=30, timeZone="Europe/Berlin", locale="de_DE"  ]

KNX channel definition (reduced to bridge & date/time thing settings - knx.things file)

Bridge knx:ip:bridge [ 
    type="TUNNEL", 
    ipAddress="127.0.0.1"
] {
    Thing device Date_Device 
    {
        Type datetime-control      : knxDate    [ ga="11.001:10/0/1" ]
        Type datetime-control      : knxTime    [ ga="10.001:10/0/0" ]
    }
}

and the item definition:

DateTime ntpDate  "Time Germany  [%1$td.%1$tm.%1$tY %1$tH:%1$tM]" {channel="knx:device:bridge:Date_Device:knxDate",channel="knx:device:bridge:Date_Device:knxTime",channel="ntp:ntp:germany:dateTime"}

No rules required. I put the item in my sitemap to see the (home) time, this is also why the 60 second interval is useful - so I have my home time available when being outside the country.
Hope this helps.

2 Likes

Dankeschƶn :+1:
Was struggling with the same :wink:

1 Like

This is the key part for your requirement.

In general, openHAB bindings listen for commands to Items/channels and forward them on to devices. Incoming data results in a binding making a state update via channel to Item.

So, in your case, the NTP binding updated state and the KNX binding ignored that - there is no command involved. All working as expected.

KNX binding also provides xxx-control type channels. These reverse the usual data flow; they are intended for incoming KNX to produce commands in openHAB e.g from a wall control panel. You donā€™t care about that, but a side effect of the reversal is that Item state updates get passed out to KNX - thatā€™s the unusual effect you wanted.

I donā€™t really believe the order that you link channels to Items makes any difference.

An alternative way to have done it with the ā€œregularā€ non-control type KNX channels would be to use the new follow profile feature on the channel. Again, this listens for state updates of the Item and passes them to the binding as though they were commands.
Your job would still require two channels, of course, each with a ā€˜followā€™.

2 Likes

OK - it now becomes clearer. Thanks for the explanation.

this one solved my issue finally, iā€™ve being trying a year to get this working!

Thanks