Diese Zeile:
bewirkt das gleiche wie diese Zeile:
womit beide Rules einmal pro Sekunde ausgeführt werden. Der letzte Stern steht für das Jahr, die Angabe ist optional, kann also entfallen.
Es kann sein, dass die Rule mit Deinem Trigger zwischen 0 Uhr und 1 Uhr gar nicht ausgeführt wird, da bin ich mir nicht so ganz sicher ("beginnend mit 1 Uhr").
Nicht nur ist das absoluter Overkill (der Wert ändert sich nur einmal pro Stunde), Du hast auch zwei voneinander unabhängige Rules, die beide mit dem selben Time cron Trigger ausgelöst werden.
openHAB hat default zwei Threads, die für Scheduler Events verwendet werden. Es ist also sehr wahrscheinlich, dass weitere Timer durch diese beiden Rules nachhaltig gestört werden.
Um die Zeit in einem Item zu speichern, benötigt man gar keine Rule, stattdessen greift man zum NTP Binding, welches "nebenher" auch dafür sorgt, dass die Zeit immer korrekt ist - vorausgesetzt, man hat NTP auch korrekt konfiguriert, natürlich.
new DateTimeType greift hingegen auf die Rechneruhr zurück, falls man also keinen NTP Client auf Betriebssystemebene eingerichtet hat, läuft diese Zeit abhängig von Temperatur und Rechner weg - durchaus auch mehr als eine Minute pro Tag.
Die Anzeige der Uhrzeit in der UI kann man realisieren, aber ob das sekundengenau funktioniert, wage ich zu bezweifeln, weil die UI dafür nicht ausgelegt ist.
Im Allgemeinen wird eine Auflösung von 30 Sekunden ausreichen, was man so im NTP Binding konfigurieren kann (Update des Items alle 30 Sekunden, Synchronisation mit dem Server z.B. nach 120 Aktualisierungen, also einmal pro Stunde).
Der exakte Zeitpunkt des Tarifwechsels wird vermutlich aus dem Vertrag ersichtlich sein, ich gehe jetzt mal von der vollen Stunde aus. Was dann bedeutet, dass man den aktuellen Tarif einmal stündlich umschalten muss, am besten einige Sekunden nach dem Stundenwechsel, entsprechend wäre der Time cron Ausdruck dann:
für stündlich, fünf Sekunden nach der vollen Stunde.
sendCommand() schickt ein Kommando an alle verlinkten Channel. Default wird anschließend auch ein postUpdate() auf das selbe Item ausgeführt (kann man abschalten). Sofern man den Preis nicht über ein Binding irgendwohin schickt (http, mqtt, knx... whatever), sollte ein postUpdate() ausreichen, um die Anzeige in der UI zu ändern (und man kann auch Rules darauf triggern lassen).
Die Vergleichszeilen schreien nach einer Optimierung mit Konstanten, weil bis auf zwei Werte alle Werte mindestens zweimal verwendet werden. Es trüge auch zur Lesbarkeit der Rule bei

mal abgesehen von der Tatsache, dass die Rule umgehend eine null-Pointer Exception verursacht, wenn auch nur eines der Items zum Zeitpunkt der Ausführung kein gültiges Datum enthält, weil dieser Fall nicht abgefangen wird.
Zu guter Letzt ist der Vergleich des Zeitstempels ebenfalls unnötig, sofern man sicherstellt, dass die Preise tatsächlich aktuell sind, es reicht in dem Fall, die korrekte Stunde zu suchen. das geht z.B. so:
Es bietet sich dann an, gar nicht den genauen Zeitstempel zu speichern, sondern stattdessen die Stunde zu speichern oder gar immer den Preis für einen bestimmten Zeitraum im gleichen Item, dann kann man bei geschickter Namenswahl das betreffende Item direkt "errechnen". Also nicht den Preis in zwei Stunden in das Item Preis02 speichern, sondern den Preis für 2 Uhr in Preis02 speichern. alle Preise kommen in eine Gruppe gPreis. Dann reicht dies hier:
Code: Alles auswählen
aktuellerPreis.postUpdate(gPreis.members.filter[i|i.name.endsWith(String::format("%02d",now.getHourOfDay))].head.state as Number)
um immer den aktuellen Preis zu kopieren.