Hallo an die Runde,
ich habe vor kurzem von OH 3.4.5 auf OH 4.2.0 migriert. Der Umsteig ging relativ problemlos bis auf Blockly Rules. In tageszeitabhängigen Rules habe ich in OH3 mit den Blöcken "now" und "datetime" in If-Anweisungen gearbeitet. Dies schlägt in OH4 leider fehl (Rules laufen mit diesen so zusammengesetzten Blöcken nicht mehr).
Ist diese Erkenntnis "erwartbar" in OH4 Blockly Rules?
Wie sollte man in OH4 in Blockly Zeitvergleiche aufbauen?
Gibt es eurerseits weitere, bekannte Unterschiede in der Blockly Zusammensetzung im Vergleich OH3 und OH4?
Grüße
neuling10
OH 3.4 .-> OH4.2 Migration: Blockly datetime schlägt fehl
-
- Beiträge: 58
- Registriert: 26. Mär 2022 18:15
OH 3.4 .-> OH4.2 Migration: Blockly datetime schlägt fehl
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
-
- Beiträge: 371
- Registriert: 30. Apr 2021 13:13
Re: OH 3.4 .-> OH4.2 Migration: Blockly datetime schlägt fehl
Moin,
kein Plan, ob das so mal ging. Ich selbst habe Vergleiche mit dem ><= Block nur mit vorher extrahierter Stunde (und damit als Zahlen) durchgeführt. Für Vergleiche von Zeitwerten gibt es einen extra Block -> https://www.openhab.org/docs/configurat ... comparison
Ansonsten https://www.openhab.org/blog/2023-07-23 ... lease.html
und https://community.openhab.org/t/blockly ... 4-0/156275
kein Plan, ob das so mal ging. Ich selbst habe Vergleiche mit dem ><= Block nur mit vorher extrahierter Stunde (und damit als Zahlen) durchgeführt. Für Vergleiche von Zeitwerten gibt es einen extra Block -> https://www.openhab.org/docs/configurat ... comparison
Ansonsten https://www.openhab.org/blog/2023-07-23 ... lease.html
und https://community.openhab.org/t/blockly ... 4-0/156275
- udo1toni
- Beiträge: 14387
- Registriert: 11. Apr 2018 18:05
- Wohnort: Darmstadt
Re: OH 3.4 .-> OH4.2 Migration: Blockly datetime schlägt fehl
Der wichtigste Unterschied, Blockly betreffend (beim Umstieg von OH3 auf OH4) ist die Version von JavaScript. OH3 verwendet Nashorn, OH4 verwendet GraalVM, da gibt es nicht unerhebliche Unterschiede. Du kannst aber Nashorn explizit installieren, dann sollten die alten Rules unverändert funktionieren (besser wäre es aber, die fraglichen "Code"-Stellen anzupassen).
openHAB4.2.0 stable in einem Debian-Container (bookworm) (Proxmox 8.2.4, LXC), mit openHABian eingerichtet
-
- Beiträge: 58
- Registriert: 26. Mär 2022 18:15
Re: OH 3.4 .-> OH4.2 Migration: Blockly datetime schlägt fehl
Vielen Dank für Eure Hinweise, die Rules laufen wieder. Folgendermaßen konnte ich die Zeitvergleiche wieder zum Laufen bringen:
Blöde Frage aber gibt es vielleicht sowas wie einen "Simulations- oder Testmodus" für Rules? Also indem ich zwecks Rule-Testing Item States zu Testzwecken setzen kann oder ich vielleicht auch den dann gesetzten Item State ausgegeben bekomme, ohne den "produktiven" State zu verändern?
Ich habe viele Anweisungen in meinen Rules. Würde ich ich jeden relevanten Ast z.B. einen Logging Block setzen, um zu testen ob der Ast durchlaufen wird, wäre das schon ein immenser Aufwand...
Ich habe rund 80 Blockly Rules am Laufen. Ich wurde in der Doku leider nicht schlau, ob es ähnliche Fälle geben könnte? Also mit in OH4 nicht mehr funktionierenden Block-Konstellationen. Habt ihr hierzu vielleicht Erfahrung?Blöde Frage aber gibt es vielleicht sowas wie einen "Simulations- oder Testmodus" für Rules? Also indem ich zwecks Rule-Testing Item States zu Testzwecken setzen kann oder ich vielleicht auch den dann gesetzten Item State ausgegeben bekomme, ohne den "produktiven" State zu verändern?
Ich habe viele Anweisungen in meinen Rules. Würde ich ich jeden relevanten Ast z.B. einen Logging Block setzen, um zu testen ob der Ast durchlaufen wird, wäre das schon ein immenser Aufwand...
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
-
- Beiträge: 371
- Registriert: 30. Apr 2021 13:13
Re: OH 3.4 .-> OH4.2 Migration: Blockly datetime schlägt fehl
die häufigsten Fehler sind dieser Art -> viewtopic.php?p=61019
Nashorn war, was Typen (Nummer/String/Datetime ...) betrifft, toleranter aber auch unberechenbarer. Das ist nun sauber gelöst.
Du kannst auch, wie von Udo angedeutet, (übergangsweise) beide Versionen parallel laufen lassen um die Regeln in Ruhe zu testen und ggf. anzupassen. Ist hier beschrieben -> https://www.openhab.org/docs/configurat ... -migration
Einen Simulationsmodus kenne ich nicht. Entweder wird die Log-Ausgabe via Frontail genutzt oder eins der Dummy-Items, welche in einem extra "Testraum" in der Modellansicht angesiedelt sind.
Nashorn war, was Typen (Nummer/String/Datetime ...) betrifft, toleranter aber auch unberechenbarer. Das ist nun sauber gelöst.
Du kannst auch, wie von Udo angedeutet, (übergangsweise) beide Versionen parallel laufen lassen um die Regeln in Ruhe zu testen und ggf. anzupassen. Ist hier beschrieben -> https://www.openhab.org/docs/configurat ... -migration
Einen Simulationsmodus kenne ich nicht. Entweder wird die Log-Ausgabe via Frontail genutzt oder eins der Dummy-Items, welche in einem extra "Testraum" in der Modellansicht angesiedelt sind.
- udo1toni
- Beiträge: 14387
- Registriert: 11. Apr 2018 18:05
- Wohnort: Darmstadt
Re: OH 3.4 .-> OH4.2 Migration: Blockly datetime schlägt fehl
Du kannst Rules von Hand triggern, über den "Play-Button in der UI. Items setzen geht nur über die API (Schalter auch über die Developer Sidebar)
Ansonsten kann ich nur empfehlen, ein Testsystem aufzubauen (gerne z.B. in einer VM oder notfalls auch nativ auf einem Windows Desktop).
Logging Elemente einzubauen ist immer sinnvoll, man kann das Logging gezielt ein- und ausschalten, indem mal das Loglevel des Loggers einstellt. Dazu müssen allerdings getrennte Logger für die Rules existieren (auch das ist ohnehin sinnvoll).
Ansonsten kann ich nur empfehlen, ein Testsystem aufzubauen (gerne z.B. in einer VM oder notfalls auch nativ auf einem Windows Desktop).
Logging Elemente einzubauen ist immer sinnvoll, man kann das Logging gezielt ein- und ausschalten, indem mal das Loglevel des Loggers einstellt. Dazu müssen allerdings getrennte Logger für die Rules existieren (auch das ist ohnehin sinnvoll).
openHAB4.2.0 stable in einem Debian-Container (bookworm) (Proxmox 8.2.4, LXC), mit openHABian eingerichtet