Sending NTP time to KNX in OpenHAB3?

Hello,

i want to configure ntp binding to send to knx bus the Date and Time. But i have always a loop
all Time. I try the solutions from other Topics but that don`t solve my problem.

here is my config:

ntp.things

Thing ntp:ntp:germany [ hostname=“nl.pool.ntp.org” ]

knx.items

DateTime Datum “Datum & Zeit [%1$td.%1$tm.%1$tY %1$tH:%1$tM]” {channel=“knx:device:RASPI-EIB:Date_Device:knxDate”,channel=“knx:device:RASPI-EIB:Date_Device:knxTime”,channel=“ntp:ntp:germany:dateTime”}

knx.things

Bridge knx:ip:RASPI-EIB [
type=“TUNNEL”,
ipAddress=“192.168.1.28”,
portNumber=3671,
localIp=“192.168.1.34”,
readingPause=50,
responseTimeout=10,
readRetriesLimit=3,
autoReconnectPeriod=60,
localSourceAddr=“0.0.128”
] {
Thing device Date_Device
{
Type datetime-control : knxDate [ ga=“11.001:0/0/1” ]
Type datetime-control : knxTime [ ga=“10.001:0/0/2” ]
}
Thing device Temperature_Device
{
Type number-control : knxTemperature “Aussentemperatur” [ ga=“9.001:0/0/3” ]
}
}

and LOG:

==> /var/log/openhab/events.log <==
2021-01-06 22:32:03.882 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘knx:device:RASPI-EIB:Temperature_Device’ changed from UNINITIALIZED to UNINITIALIZED (HANDLER_MISSING_ERROR)
2021-01-06 22:32:03.890 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘knx:ip:RASPI-EIB’ changed from ONLINE to UNINITIALIZED
2021-01-06 22:32:04.091 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘knx:ip:RASPI-EIB’ changed from UNINITIALIZED to OFFLINE
2021-01-06 22:32:04.103 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘knx:ip:RASPI-EIB’ changed from OFFLINE to UNINITIALIZED (HANDLER_MISSING_ERROR)
2021-01-06 22:32:06.604 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘knx:ip:RASPI-EIB’ changed from UNINITIALIZED to INITIALIZING
2021-01-06 22:32:06.625 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘knx:ip:RASPI-EIB’ changed from INITIALIZING to UNKNOWN
2021-01-06 22:32:06.636 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘knx:device:RASPI-EIB:Date_Device’ changed from UNINITIALIZED to INITIALIZING
2021-01-06 22:32:06.654 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘knx:device:RASPI-EIB:Date_Device’ changed from INITIALIZING to OFFLINE (BRIDGE_OFFLINE)
2021-01-06 22:32:06.664 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘knx:device:RASPI-EIB:Temperature_Device’ changed from UNINITIALIZED to INITIALIZING
2021-01-06 22:32:06.682 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘knx:device:RASPI-EIB:Temperature_Device’ changed from INITIALIZING to OFFLINE (BRIDGE_OFFLINE)
2021-01-06 22:32:15.743 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘budDate’ changed from 2021-01-06T22:27:55.000+0100 to 2021-01-06T22:28:36.000+0100
2021-01-06 22:32:20.012 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘hc1_actualSupplyTemperature’ changed from 55.9 to 55.3
2021-01-06 22:32:49.246 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘Datum’ changed from 1970-01-07T00:00:00.000+0100 to 2021-01-06T22:32:49.238+0100
2021-01-06 22:32:55.485 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘budDate’ changed from 2021-01-06T22:28:36.000+0100 to 2021-01-06T22:29:15.000+0100
2021-01-06 22:32:59.263 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘hc1_actualSupplyTemperature’ changed from 55.3 to 55.8
2021-01-06 22:33:05.023 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘istBudWasser’ changed from 60.1 to 60.2
2021-01-06 22:33:06.646 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘knx:ip:RASPI-EIB’ changed from UNKNOWN to ONLINE
2021-01-06 22:33:06.650 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘knx:device:RASPI-EIB:Temperature_Device’ changed from OFFLINE (BRIDGE_OFFLINE) to ONLINE
2021-01-06 22:33:06.652 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘knx:device:RASPI-EIB:Date_Device’ changed from OFFLINE (BRIDGE_OFFLINE) to ONLINE
2021-01-06 22:33:35.707 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘budDate’ changed from 2021-01-06T22:29:15.000+0100 to 2021-01-06T22:29:56.000+0100
2021-01-06 22:33:39.515 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘hc1_actualSupplyTemperature’ changed from 55.8 to 55.0
2021-01-06 22:33:45.265 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘istBudWasser’ changed from 60.2 to 60.1

==> /var/log/openhab/openhab.log <==
2021-01-06 22:33:49.417 [WARN ] [nx.internal.client.AbstractKNXClient] - Value ‘1970-01-07T22:33:49.000+0100’ could not be sent to the KNX bus using datapoint ‘command DP 0/0/1 ‘knx:ip:RASPI-EIB’, DPT id 11.001, low priority’: 11.001 Date: invalid date: 1970-01-07. Giving up now.

the config is:

runtimeInfo:
version: 3.0.0
buildString: Release Build
locale: de_DE
systemInfo:
configFolder: /etc/openhab
userdataFolder: /var/lib/openhab
logFolder: /var/log/openhab
javaVersion: 11.0.9
javaVendor: Azul Systems, Inc.
javaVendorVersion: Zulu11.43+88-CA
osName: Linux
osVersion: 5.4.79-v7+
osArchitecture: arm
availableProcessors: 4
freeMemory: 104567224
totalMemory: 324403200
bindings:

  • avmfritz
  • bluetooth
  • darksky
  • enigma2
  • exec
  • harmonyhub
  • hue
  • hydrawise
  • icloud
  • ipcamera
  • km200
  • knx
  • lgwebos
  • mihome
  • mqtt
  • ntp
  • telegram
  • yamahamusiccast
  • yamahareceiver
  • yeelight
  • zigbee
  • zwave
    clientInfo:
    device:
    ios: false
    android: false
    androidChrome: false
    desktop: true
    iphone: false
    ipod: false
    ipad: false
    edge: false
    ie: false
    firefox: true
    macos: false
    windows: true
    cordova: false
    phonegap: false
    electron: false
    nwjs: false
    webView: false
    webview: false
    standalone: false
    os: windows
    pixelRatio: 1
    prefersColorScheme: light
    isSecureContext: false
    locationbarVisible: true
    menubarVisible: true
    navigator:
    cookieEnabled: true
    deviceMemory: N/A
    hardwareConcurrency: 8
    language: de
    languages:
    - de
    - en-US
    - en
    onLine: true
    platform: Win32
    screen:
    width: 1920
    height: 1080
    colorDepth: 24
    support:
    touch: false
    pointerEvents: true
    observer: true
    passiveListener: true
    gestures: false
    intersectionObserver: true
    themeOptions:
    dark: light
    filled: true
    pageTransitionAnimation: default
    bars: filled
    homeNavbar: default
    homeBackground: default
    expandableCardAnimation: default
    userAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:83.0) Gecko/20100101
    Firefox/83.0
    timestamp: 2021-01-06T21:36:13.978Z

Hello Toni,
EDIT:There is. somethings mixed up with thefollow profile in this post, please see my post 38 below for a complete working solution in OH 3.2 MainUI. You need either the follow profile or the control-channel, not both. Regards Thomas

I’m just shifting from 2.5 to 3.0 and was facing a loop as well.
The reason I saw a loop was that I had the same thing/item definition active on my 2.5 installation and on the new 3.0 installation.
Commenting the “old” item on 2.5 did solve it.

Nevertheless I dropped the textual config and did the thing in the MainUI, so here is a little “HowTo”:

Created a NTP thing:

UID: ntp:ntp:local
label: Lokale Zeit
thingTypeUID: ntp:ntp
configuration:
  timeZone: Europe/Berlin
  hostname: 0.pool.ntp.org
  serverPort: 123
  refreshInterval: 60
  refreshNtp: 30

Created a KNX thing:

UID: knx:device:KNXDateTime
label: KNX DateTime Wrapper
thingTypeUID: knx:device
configuration:
  pingInterval: 600
  readInterval: 0
  fetch: false
bridgeUID: knx:ip:Weinzierl730
channels:
  - id: time
    channelTypeUID: knx:datetime-control
    label: DateTime
    description: null
    configuration:
      ga: 10.001:6/0/1
  

Then created an item linked to the NTP things local time.

After this linked the same item to the KNX time channel of the “KNX DateTime Wrapper”, but with the “follow” profile.

Bildschirmfoto 2021-01-06 um 23.43.13

Each time the NTP local time changes, it updates the linked item. As the second channel (the knx time item) is linked with the profile “Follow”, it takes over the change from the first channel - this results in the time being written to the bus.

The group addresses for you will differ, but the concept should be clear I hope.

Regards
Thomas

6 Likes

I faced similar behavior, when migrating to a fresh installation while still having openHAB 2 running.

Doing the copying/migrating and commenting out in openHAB 2 befor saving the migrated configuration
has been the best practice for me while moving things partly to openHAB 3.

1 Like

Is this the only solution and working ? Because i have 2 GAs
to fill with Data. One is the Date and the Second is the Time.
So how can make it workable and is it only in GUI Functions
availiable like “Following” or is it text based possible?

Thanks for Reply.

Hey, i got the same Problem with looping:

Important for those who have another instance (oh2) running: Stop it!
That was the reason why i got the looping in the log:

08:35:40.100 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'NTPLOCALDATETIME' changed from 1970-01-01T08:35:17.000+0100 to 1970-01-01T00:00:00.000+0100
08:35:40.146 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'NTPLOCALDATETIME' received command 1970-01-01T00:00:00.000+0100
08:35:40.146 [INFO ] [openhab.event.ItemStatePredictedEvent] - Item 'NTPLOCALDATETIME' predicted to become 1970-01-01T00:00:00.000+0100
08:35:40.230 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'NTPLOCALDATETIME' received command 1970-01-01T00:00:00.000+0100
08:35:40.230 [INFO ] [openhab.event.ItemStatePredictedEvent] - Item 'NTPLOCALDATETIME' predicted to become 1970-01-01T00:00:00.000+0100
08:35:40.279 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'NTPLOCALDATETIME' received command 1970-01-01T00:00:00.000+0100
08:35:40.279 [INFO ] [openhab.event.ItemStatePredictedEvent] - Item 'NTPLOCALDATETIME' predicted to become 1970-01-01T00:00:00.000+0100
08:35:40.330 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'NTPLOCALDATETIME' received command 1970-01-01T00:00:00.000+0100
08:35:40.330 [INFO ] [openhab.event.ItemStatePredictedEvent] - Item 'NTPLOCALDATETIME' predicted to become 1970-01-01T00:00:00.000+0100
08:35:40.377 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'NTPLOCALDATETIME' received command 1970-01-01T00:00:00.000+0100
08:35:40.377 [INFO ] [openhab.event.ItemStatePredictedEvent] - Item 'NTPLOCALDATETIME' predicted to become 1970-01-01T00:00:00.000+0100
08:35:40.473 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'NTPLOCALDATETIME' 
And so on...

@gpowa : You could link both date and time GA to the same item (with the ‘follow’ profile):

image

image

i hope this helps

You can do this with .items and .things files In the same way. This was a stripped down example to show the basic idea, the date could be included as well (My time wrapper has more channels than I poster to keep it simple).

But as we are talking OH3 yaml-definitions did make sense. And it’s easy to copy&paste them into the code section of the things.

You may read this thread to get a textual definition in OH2.5 style.

Ok now i have an other loop! the following command dont work and i havent a second openhab.
So now i`m confused.whats wrong.Maybe at weekend i try with openhab 2.52.

here my config:

knx.items

DateTime Datum “Datum & Zeit [%1$td.%1$tm.%1$tY %1$tH:%1$tM]” (Status) { channel=“ntp:ntp:germany:dateTime”, channel=“knx:device:RASPI-EIB:Date_Device:knxDateTime” [profile=“follow”]}

knx.things

Thing device Date_Device “KNX Wrapper für Datum und Zeit” @ “HWR”
{
Type datetime-control : knxDateTime “Datum und Zeit” [ ga=“19.001:0/0/5” ]
}

ntp.things

Thing ntp:ntp:germany [ hostname=“ntp1.fau.de”, refreshInterval=60, refreshNtp=30, timeZone=“Europe/Berlin”, locale=“de_DE” ]

2021-01-08 01:06:31.666 [INFO ] [openhab.event.ItemCommandEvent ] - Item ‘Datum’ received command 2021-01-08T01:06:21.000+0100
2021-01-08 01:06:31.668 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item ‘Datum’ predicted to become 2021-01-08T01:06:21.000+0100
2021-01-08 01:06:31.762 [INFO ] [openhab.event.ItemCommandEvent ] - Item ‘Datum’ received command 2021-01-08T01:06:21.000+0100
2021-01-08 01:06:31.764 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item ‘Datum’ predicted to become 2021-01-08T01:06:21.000+0100
2021-01-08 01:06:31.851 [INFO ] [openhab.event.ItemCommandEvent ] - Item ‘Datum’ received command 2021-01-08T01:06:21.000+0100
2021-01-08 01:06:31.853 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item ‘Datum’ predicted to become 2021-01-08T01:06:21.000+0100
2021-01-08 01:06:31.943 [INFO ] [openhab.event.ItemCommandEvent ] - Item ‘Datum’ received command 2021-01-08T01:06:21.000+0100
2021-01-08 01:06:31.945 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item ‘Datum’ predicted to become 2021-01-08T01:06:21.000+0100
2021-01-08 01:06:32.031 [INFO ] [openhab.event.ItemCommandEvent ] - Item ‘Datum’ received command 2021-01-08T01:06:21.000+0100
2021-01-08 01:06:32.033 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item ‘Datum’ predicted to become 2021-01-08T01:06:21.000+0100

Toni,
did you try the solution we provided for OH3? It is working fine here. Did it work for you?
if yes:
Why do yo insist on this text file config ?
I used this in OH2, but shift to MainUI and yaml for OH3. Is it missing documentation/examples?
For OH3 you can do it in the things yaml and the UI, that’s why I provided it that
way.
OH3 should be the way to start if you setup a new system as sooner or later you will have to migrate and this will cause you efforts and some trouble.

now I am confused, do you want to switch completely to OH3? why try in 2.5 then?
All this put aside, how is your GA defined (0/0/5 and 6/0/1 at least). I got the suspicion one of them is set to “S”(end), so what happens is:

  1. you update the time from openHAB
  2. one GA gets updated AND sends the time and as this triggers openHAB to update also, this loops

So, please have a look in your ETS how your GAs are defined and secondly, please use code fences (```) and not quotes for code, makes it better readable.

I second that totally!
I was (and partly still am) an old-fashioned “textual configuration” guy. But with OH3 I completely switched over to GUI-configuration and not a single textual configuration. Why? because it saves me a sh%t ton of time trying to figure out, where my typo was or what syntax this binding and that binding uses.
given, the UI from time is annoying, because it does not allow bulk editing everywhere, but as I can see, the dev-team already works on further improving the OH3 GUI.

Hello binderth,

thanks for your advice, next time i use fences. So here is my config in ETS:


I want to try with openHAB 2.5 because i want to know, if this is a specific
openHAB 3 Problem or a config Problem. Kai Kreutzer said in other post
that the Solution with “datetime-control” worked in his config.

It works with everybody, I guess! :wink:
Judging from your ETS-screenshot you have your KNX switches/buttons all configured to “Ü”(bertragen=send) the time. I do think THAT is the loop, your looking for, because every single one of them will send the read-out value again to the Bus.
Simply put: you’ll send the time to 0//0/2, all your buttons read the time and at the same time send the time.
Try to remove the “Ü” flags.

1 Like

You are right, that seems to be the reason I´d say.
OH is fine, its a misconfiguration in the knx - either the Raumcontroller receives the date/time from the bus or it is generating a time signal and provides it for others. Both together makes no sense.
The datetime-control solution works in OH2.5 as well as OH3, it’s just configured differently. Using the items and things files from OH2.5 should work in OH3 as well (it did for me initially).

i tried with same result - the loop

Did you remove the Ü-Flags from all(!) the devices where this group address is linked ? They all react to the update they receive from the bus…

Jugding from the documentation of the “JUNG Kompakt-Raumcontroller-Modul” (at least, that is the article number I found online and it matches the KO number 130):

  1. The controller has an internal clock
  2. the internal clock can receive a time at KO 130 with dpt 10.001 (which is correctly set in your things file,as I can see)
  3. as far as I can see (didn’t read it all), there is no output of a time from the “Raumcontroller”

So, it seems, there’s other devices, which send the time? …and do you always have those changing states in your bridge status or is it because you restart the bridge/Binding?

yes the same log:

Item ‘Datum’ changed from 2021-01-08T12:18:15.000+0100 to 2021-01-08T12:20:15.000+0100
Item ‘Datum’ received command 2021-01-08T12:17:15.000+0100
Item ‘Datum’ predicted to become 2021-01-08T12:17:15.000+0100
Item ‘Datum’ changed from 2021-01-08T12:20:15.000+0100 to 2021-01-08T12:17:15.000+0100
Item ‘Datum’ received command 2021-01-08T12:19:15.000+0100
Item ‘Datum’ predicted to become 2021-01-08T12:19:15.000+0100
Item ‘Datum’ changed from 2021-01-08T12:17:15.000+0100 to 2021-01-08T12:19:15.000+0100
Item ‘Datum’ received command 2021-01-08T12:21:15.000+0100

so i try and change from Write “S” to Read “L” in the ETS but the same loop.

please start the Busmonitor in ETS and set the Filter to “0/0/2” and see what happens.

PS: That’s MORE extreme! :wink:
Please read some more on KNX flags… :wink:

K: ensures the communication on the KNX Bus
L: means the devices reacts on GroupValueRead-telegram on the Bus and writes the values on the Bus
S: means the devices reacts on GroupValueWrite-telegramon the Bus and changes its internal values accordingly
Ü: means the device reacts to a change in the value (usually by pressing a button, but some sensors also use this flag to relay telegrams) and writes the values on the Bus
A: means the device also reacts on a GroupValueRead-telegram

always take the perspective of the actuator/sensor, never the one of the Bus!

=> Item ‘Datum’ changed from 2021-01-08T12:18:15.000+0100 to 2021-01-08T12:20:15.000+0100
         Item ‘Datum’ received command 2021-01-08T12:17:15.000+0100
         Item ‘Datum’ predicted to become 2021-01-08T12:17:15.000+0100
=> Item ‘Datum’ changed from 2021-01-08T12:20:15.000+0100 to 2021-01-08T12:17:15.000+0100
         Item ‘Datum’ received command 2021-01-08T12:19:15.000+0100
         Item ‘Datum’ predicted to become 2021-01-08T12:19:15.000+0100
=> Item ‘Datum’ changed from 2021-01-08T12:17:15.000+0100 to 2021-01-08T12:19:15.000+0100
         Item ‘Datum’ received command 2021-01-08T12:21:15.000+0100

btw: That is NO loop. just standard openHAB behaviour, when you try to change an “auto update” item:

  1. the eventbus received an “sendCommand” to the item
  2. the eventbus predicts the item will change
  3. the eventbus changed the item.