Wieder direkt die Frage: Wozu der Uhrschalter? Warum prüfst du stündlich den Zustand? Warum über zwei Rules?
.sendCommand() sendet einen Befehl.
.postUpdate() setzt einen Status. Ich gehe davon aus, dass Du das Item Uhrschalter eingebaut hast, um darüber die Rule quasi zu deaktivieren oder zu aktivieren. Aber ob das in der gewählten Form tatsächlich sinnvoll ist?
Besser, in einer Rule:
Code: Alles auswählen
rule "Uhrschalter setzen"
when
Time cron "0 0 * * * ?" // Regel stündlich ausführen
then
var soll = ON // Default Sollwert ON
if(now.getHour > 8 && now.getHour < 19) // falls aktuelle Zeit 09:00:00 Uhr bis 18:59:59 Uhr
soll = OFF // Ändere Sollwert auf OFF
if(Uhrschalter.state != soll) // falls Uhrschalter Status von soll abweicht
Uhrschalter.postUpdate(soll.toString) // Setze Uhrschalter auf Sollwert
end
Falls Du noch openHAB2 einsetzt, musst Du
getHour durch
getHourOfDay ersetzen, ansonsten bleibt die Rule gleich.
Beim Senden des Status
kann es auch ohne das
.toString funktionieren, auf der sicheren Seite sind wir aber mit dem
.toString, so funktioniert es auf jeden Fall korrekt.
Die "eigentliche" Rule:
Code: Alles auswählen
rule "Wechselrichter Soyosorce"
when
Item VerbrauchTest changed
then
if(Uhrschalter.state != ON) // Rule nicht aktiv?
return; // dann raus!
if(!(newState instanceof Number)) // keine Zahl?
return; // dann raus!
var zahl = (newState as Number).floatValue // weise zu
if(zahl < 1) // Wert kleiner 1?
zahl = 10 // dann setze Wert 10
if(zahl > 550) // Wert größer 550?
zahl = 500 // dann setze Wert 500
val mqttActions = getActions("mqtt","mqtt:broker:neuer")
mqttActions.publishMQTT("Leistung", zahl.toString) // schreibe in Leistung
end
Bitte keine Semikola, wo keine hingehören! (Konkret ausschließlich nach dem Schlüsselwort return, sonst nirgends. Nie.
Du hast Die Abfrage von Uhrschalter falsch eingebaut, letztlich hätte der Uhrschalter bei Deiner Version dafür gesorgt, dass nur zwischen 19 und 9 Uhr geprüft wird, ob ein gültiger Zahlenwert vorliegt und falls das nicht der Fall wäre dann die Rule abgebrochen. Auf jeden Fall würde aber der auf Werte zwischen 1 und 550 begrenzte Zahlenwert in das Topic Leistung geschrieben, wenn Uhrschalter auf OFF würde die Rule ohne vorliegenden gültigen Wert halt eine nullPointer Exception werfen.
Die Version hier bricht nun ab, wenn Uhrschalter nicht auf ON steht. Da der Wert kein zweites Mal gebraucht wird, ist es unsinnig, ihn zuerst in eine Variable zu speichern. Auch besteht kein Anlass, den Wert zuerst in einen String zu wandeln, openHAB kann sehr gut mit Status umgehen.
Falls die Rule weiterläuft (d.h. Uhrschalter steht auf ON), wird nun geprüft, ob ein gültiger Zahlenwert vorliegt. Ist das nicht der Fall, bricht die Rule ab.
Läuft die Rule immer noch, so wird der Zahlenwert als Float Zahl in der Variablen zahl gespeichert.
Nun folgt ein Vergleich mit den beiden Grenzwerten. Ist
zahl kleiner als 1, so wird der Wert 10 gesetzt, ist
zahl größer als 550, wird 500 gesetzt (Ich frage mich immer noch, warum Du auf andere Werte prüfst als Du schließlich setzt... sinnvoller wäre, auf
< 10 zu prüfen und falls das zutrifft auf
10 zu setzen, sowie auf
> 500 zu prüfen und gegebenenfalls
500 zu setzen.
Hier mit else zu arbeiten ist nicht sinnvoll, es trifft ohnehin nur maximal eine der beiden Bedingungen zu.
Und warum nutzt Du publishMQTT?
Viel sinnvoller wäre, einen Channel zu definieren und den Wert an den Channel zu senden. Falls das Gerät selbst auf den Befehl antwortet, so kann man die Antwort mutmaßlich im selben Channel empfangen und an das selbe Item als Status übergeben - zwei Fliegen mit einer Klappe.
Liefert der Channel keine Rückmeldung und der Channel ist writeOnly, so hast Du zumindest im Item immer die zuletzt gesendete Leistung und kannst diese direkt in der UI zur Anzeige nutzen, Du bekommst außerdem Persistence frei Haus und kannst später genau nachvollziehen, wie der Verlauf der Leistung über den Tag, die Woche, das Jahr war.
Außerdem ersparst Du Dir die Definition der Action (eine Stelle zusätzlich in der Konfiguration, die Du anpassen musst, wenn Du mal was an der Bridge anpasst).
Es gibt sehr gute Gründe, in Rules die mqtt Action einzusetzen, hier jedoch definitiv nicht.
openHAB4.3.3 stable in einem Debian-Container (bookworm) (Proxmox 8.3.5, LXC), mit openHABian eingerichtet
) - Und ich habe nicht mal ein außerordentlich großes openHAB System, ich hatte nur immer irgendwas anderes zu erledigen.
)
Speichersystem das tagsüber geladen wird und in der Nacht einspeisen soll. Damit die Batterien nicht Schaden nehmen gibt es ein dreistufiges System.