openhabforum.de


https://openhabforum.de/

Date/Time Problem: Migrationsstrategie OH2 => OH3

https://openhabforum.de/viewtopic.php?t=4584

Seite 1 von 2

Date/Time Problem: Migrationsstrategie OH2 => OH3

Verfasst: 2. Jan 2021 23:44
von 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

Re: Migrationsstrategie OH2 => OH3

Verfasst: 8. Jan 2021 09:36
von 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

Date/Time Problem: Migrationsstrategie OH2 => OH3

Verfasst: 8. Jan 2021 19:00
von 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

Re: Date/Time Problem: Migrationsstrategie OH2 => OH3

Verfasst: 9. Jan 2021 00:39
von 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

Re: Date/Time Problem: Migrationsstrategie OH2 => OH3

Verfasst: 9. Jan 2021 10:45
von int5749
Hallo Udo
udo1toni hat geschrieben: ↑9. Jan 2021 00:39 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.

Re: Date/Time Problem: Migrationsstrategie OH2 => OH3

Verfasst: 9. Jan 2021 19:52
von udo1toni
Aber das tust Du doch gar nicht?
int5749 hat geschrieben: 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

Re: Date/Time Problem: Migrationsstrategie OH2 => OH3

Verfasst: 9. Jan 2021 19:59
von int5749
udo1toni hat geschrieben: ↑9. Jan 2021 19:52 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 :roll:

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

Re: Date/Time Problem: Migrationsstrategie OH2 => OH3

Verfasst: 9. Jan 2021 22:51
von 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.

Re: Date/Time Problem: Migrationsstrategie OH2 => OH3

Verfasst: 9. Jan 2021 23:00
von 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)

Re: Date/Time Problem: Migrationsstrategie OH2 => OH3

Verfasst: 9. Jan 2021 23:59
von udo1toni
Diese Möglichkeit hatte ich ja schon oben erwähnt... ;)
Alle Zeiten sind UTC+02:00
Seite 1 von 2

Powered by phpBB® Forum Software © phpBB Limited

Deutsche Übersetzung durch phpBB.de