Date/Time Problem: Migrationsstrategie OH2 => OH3

[int5749]

Hallo zusammen,

Nachdem ich nun diverse Threats mit unterschiedlichen Problemen bei der Migration nach OH3 gelesen habe, habe ich mir folgendes überlegt und bin auf Euer Feedback dazu gespannt, ob dies so funktionieren kann.

OH 2 läuft derzeit bei mir auf einem alten Windows 7 Rechner, der mittlerweile in die Jahre gekommen ist. Daher wird es für OH 3 neue Hardware geben, einen lüfterlosen miniPC mit Windows 10 (Linux ist nicht meins und ich möchte dies nicht auch noch erlernen, die ersten Versuche damit waren bereits sehr müßig).
Wenn ich das semantische Modell richtig verstanden habe, ist es die Zuordnung der Items in Gruppen, welches Räume im Gebäude wiederspiegeln? Dann habe ich dies in meiner items bereits seit OH1 so umgesetzt und nutze dies manchmal in der Sitemaps, da dann alle items der Gruppe direkt angezeigt werden(leider nicht immer sortiert)

Ansatz:

1) Installation Windows 10 und Voraussetzungen für OH3, nebst diesem als komplette Neuinstallation
2) Installation der notwendigen Bindings und add-ons
3) Übernahme der things und items Datei (derzeit habe ich dort alles konfiguriert, kein thing ist über die Auto-Erkennung erstellt. (Ja, in der Oh internen DB angelegt soll das System schneller sein, aber ich finde dies für mich so übersichtlicher)

Damit könnte das System dann doch parallel laufen, mein Gateway von MDT unterstützt 4 Parallele Zugriffe.

4) anlegen neuer Rules Dateien und dann würde ich Rule für Rule von der OH2 Installation aus-kommentieren und in OH 3 erstellen und ggfs anpassen, bis die alles übertragen wurde.

Seht ihr hier einen Fallstrick, den ich übersehen habe, oder wäre dies ein Ansatz??

Viele Grüße

[int5749]

Hallo zusammen

nach vielem lesen und überlegen, würde ich die Migration nun gemäß der Strategie "Don't change all at once" versuchen, es soll ja möglichst unterbrechungsfrei erfolgen und die Rules sind ja teilweise schon sehr verschachtelt bei mir. Bevor es also dann nativ auf OH3 geht und möglichst viel Konfig in der Basic UI, habe ich meine *.items und *.things auf das neue System übertragen.

Windows 10 mit installiertem openHAB 3.1.0 Snapshot

Die gute Nachricht: Alle Things sind online und die meisten Items mit Werten gefüllt.

Bevor ich nun die Rules angehen und diese an die neue Abfrage zu Zeit/Datum anzupassen, habe ich ein seltsames Verhalten im Log beobachtet.

Ich habe 2 Items, eines für Zeit und eines für das Datum.
Unter OH 3.1.0SS werden diese im sekundentakt befüllt und das log entsprechend geflutet. Dies war unter OH2.x definitiv nicht so und ich frage mich, ob es an einer Log Einstellung der SS Version liegen kann??

Thing

Code: Alles auswählen

//TUNNEL
Bridge knx:ip:bridge "MDT SCN-IP000.02" @ "Hausanschlußraum" [  
	type="TUNNEL",
	ipAddress="192.168.1.1",
	autoReconnectPeriod=60
] {
/* Virtuelle Items, keine Hardware */
    Thing device Vopenhab "virtuelle" @ "KNX" [
     ] {
        Type datetime-control : uhrzeit	"Zeit und Tag"	[ ga="10.001:0/6/6" ]
        Type datetime-control : datum	"Datum"		[ ga="11.001:0/6/7" ]
   }
}

Items

Code: Alles auswählen

DateTime Uhrzeit	"Zeit: [%1$tH:%1$tM]"	{channel="knx:device:bridge:Vopenhab:uhrzeit",channel="ntp:ntp:home:dateTime"}
DateTime Datum	"Datum [%1$td.%1$tm.%1$tY]"	<calendar> {channel="knx:device:bridge:Vopenhab:datum",channel="ntp:ntp:home:dateTime"}

Log

09:35:13.730 [INFO ] [openhab.event.ItemStatePredictedEvent] - Item 'Datum' predicted to become 2021-01-08T00:00:00.000+0100
09:35:13.823 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Uhrzeit' received command 1970-01-02T09:34:59.000+0100
09:35:13.823 [INFO ] [openhab.event.ItemStatePredictedEvent] - Item 'Uhrzeit' predicted to become 1970-01-02T09:34:59.000+0100
09:35:13.823 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Uhrzeit' changed from 1970-01-02T09:35:10.000+0100 to 1970-01-02T09:34:59.000+0100
09:35:13.886 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Uhrzeit' received command 1970-01-02T09:34:59.000+0100
09:35:13.886 [INFO ] [openhab.event.ItemStatePredictedEvent] - Item 'Uhrzeit' predicted to become 1970-01-02T09:34:59.000+0100
09:35:13.933 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Uhrzeit' received command 1970-01-02T09:35:10.000+0100
09:35:13.933 [INFO ] [openhab.event.ItemStatePredictedEvent] - Item 'Uhrzeit' predicted to become 1970-01-02T09:35:10.000+0100
09:35:13.933 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Uhrzeit' changed from 1970-01-02T09:34:59.000+0100 to 1970-01-02T09:35:10.000+0100
09:35:13.980 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Datum' received command 2021-01-08T00:00:00.000+0100
09:35:13.980 [INFO ] [openhab.event.ItemStatePredictedEvent] - Item 'Datum' predicted to become 2021-01-08T00:00:00.000+0100

Nachtrag: Ich habe die Konfig gerade auch mal unter openHAB 3.0.0 stable durchgeführt und dort das gleiche Verhalten :-/

Viele Grüße
Jörg

[int5749]

Hier einmal das Log der OH2 Installation, da liegt das Update im Minuten Bereich

2021-01-08 15:00:11.394 [vent.ItemStateChangedEvent] - Datum changed from 2021-01-08T14:58:33.706+0100 to 2021-01-08T14:59:33.934+0100
2021-01-08 15:00:11.425 [vent.ItemStateChangedEvent] - Uhrzeit changed from 2021-01-08T14:58:33.706+0100 to 2021-01-08T14:59:33.934+0100
2021-01-08 15:01:11.642 [vent.ItemStateChangedEvent] - Datum changed from 2021-01-08T14:59:33.934+0100 to 2021-01-08T15:00:34.151+0100
2021-01-08 15:01:11.673 [vent.ItemStateChangedEvent] - Uhrzeit changed from 2021-01-08T14:59:33.934+0100 to 2021-01-08T15:00:34.151+0100
2021-01-08 15:02:11.750 [vent.ItemStateChangedEvent] - Datum changed from 2021-01-08T15:00:34.151+0100 to 2021-01-08T15:01:34.291+0100
2021-01-08 15:02:11.766 [vent.ItemStateChangedEvent] - Uhrzeit changed from 2021-01-08T15:00:34.151+0100 to 2021-01-08T15:01:34.291+0100
2021-01-08 15:03:11.919 [vent.ItemStateChangedEvent] - Datum changed from 2021-01-08T15:01:34.291+0100 to 2021-01-08T15:02:34.460+0100
2021-01-08 15:03:11.935 [vent.ItemStateChangedEvent] - Uhrzeit changed from 2021-01-08T15:01:34.291+0100 to 2021-01-08T15:02:34.460+0100
2021-01-08 15:04:12.076 [vent.ItemStateChangedEvent] - Datum changed from 2021-01-08T15:02:34.460+0100 to 2021-01-08T15:03:34.616+0100
2021-01-08 15:04:12.091 [vent.ItemStateChangedEvent] - Uhrzeit changed from 2021-01-08T15:02:34.460+0100 to 2021-01-08T15:03:34.616+0100

[udo1toni]

Wie hast Du denn das NTP-Thing definiert? Dieses ist für die Zeit zuständig. Laufen beide Instanzen parallel? dann kann es zu Kuddelmuddel kommen

[int5749]

Hallo Udo

Wie hast Du denn das NTP-Thing definiert?

Dies habe ich 1:1 übernommen

Code: Alles auswählen

//TUNNEL
Bridge knx:ip:bridge "MDT SCN-IP000.02" @ "Hausanschlußraum" [  
	type="TUNNEL",
	ipAddress="192.168.10.1",
	autoReconnectPeriod=60
] {
/* Virtuelle Items, keine Hardware */
    Thing device Vopenhab "virtuelle" @ "KNX" [
     ] {
        Type datetime-control : uhrzeit	"Zeit und Tag"	[ ga="10.001:0/6/6" ]
        Type datetime-control : datum	"Datum"			[ ga="11.001:0/6/7" ]
   }
}

Da ich ja die Systemzeit schon mit NTP synchronisiere, wollte ich weiterhin - wie unter OH2 - auf das NTP Bindung verzichten.

[udo1toni]

Aber das tust Du doch gar nicht?

DateTime Uhrzeit "Zeit: [%1$tH:%1$tM]" {channel="knx:device:bridge:Vopenhab:uhrzeit",channel="ntp:ntp:home:dateTime"}
DateTime Datum "Datum [%1$td.%1$tm.%1$tY]" <calendar> {channel="knx:device:bridge:Vopenhab:datum",channel="ntp:ntp:home:dateTime"}
[/code]

Da sind beide Items sowohl mit dem knx Channel als auch mit dem ntp Channel gekoppelt, und nichts anderes würde ich hier erwarten. Die Frage ist nun aber, wie das ntp-Thing definiert ist...


Gesendet von iPad mit Tapatalk

[int5749]

Die Frage ist nun aber, wie das ntp-Thing definiert ist...

Hmm, habe dies so von Dir - vor langer Zeit - übernommen und scheinbar bis heute nicht richtig verstanden

Code: Alles auswählen

/* NTP Binding */
Thing ntp:ntp:home "Lokale Zeit" [
	hostname="0.de.pool.ntp.org",
	refresh=120, 
	refreshNtp=30, 
	locale="de_DE", 
	timeZone="Europe/Berlin"
]

Demnach sollte es ja nicht im Sekunden-Takt pushen?

Viele Grüße,
Jörg

[udo1toni]

Für den Moment sehe ich leider keinen Fehler. Es könnte allerdings sein, dass refresh nun refreshInterval heißt. Bei mir sieht das Thing im OH3 Testsystem so aus:

Code: Alles auswählen

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

Vermutlich wurde also der Parameter umbenannt.

[int5749]

Und Du hast einen Intervall von 60 hingegen zu meinen 120, wobei dies ja keine Auswirkung haben sollte.

Aber ich denke dies war ein typisches Beispiel von: Die besten Fehler sind die, die man(n) sich selber einbaut.

Habe vor 10 Minuten nochmal so siniert und ich habe ja beide Installationen OH2 und OH3 parallel laufen, ausser die Rules, die laufen derzeit noch fast alle auf dem OH2 System. Dies, da ich auch die Hardware "refreshed" habe.

Somit heissen alle Items identisch etc und eigentlich läuft dies stabil nebeneinander. Nur die beiden Items zicken da wohl rum.
Daher habe ich auf dem OH2 System die Items nun ohne Channel gespeichert und die Items unter OH3 wieder aktiviert.

Voilá => Update der Items erfolgt im Minuten-Takt.

Fazit: Auch wenn die beiden Installationen gut nebeneinander laufen, gibt es den einen oder anderen Fallstrick. Evtl.hilft dies ja auch der/dem einen oder anderen beim Umstieg, falls eine ähnliche Strategie gewählt wird.

Den Parameter werde ich auch mal prüfen, denn dies würde auch erklären warum er alle 60s ein Update sendet (default value) und nicht alle 120s. (angepasst, nachdem ich noch einmal die Binding Beschreibung gelesen habe)

[udo1toni]

Diese Möglichkeit hatte ich ja schon oben erwähnt...