Werte von OpenHAB in CCU Systemvariable schlägt fehl

Moderator: seppy

Antworten
Jakobxyz
Beiträge: 26
Registriert: 10. Apr 2020 12:32

Werte von OpenHAB in CCU Systemvariable schlägt fehl

Beitrag von Jakobxyz »

Hallo,

ich versuche die maximale Temperatur von OpenHAB in die CCU3 als Systemvariable zu bekommen. Dies klappt leider nicht ganz. In der CCU habe ich eine Systemvariable als Typ Zahl angelegt, im Bereich von -100 bis 100. Ich habe in OpenHAB diese rule angelegt:

Code: Alles auswählen

rule "Maximale Temperatur von Binding in Homematic Regelmäßiges Update"
when Item SchalterTest1 changed
then GATEWAYEXTRAS1MaximaleTemperaturHeute.postUpdate(OpenweathermapOneCallAPIWetterUndVorhersageForecastTodayMaxTemperatureohneC.state)
end
Wenn ich jetzt den Switch zum testen betätige wird der neue Wert kurz in die CCU Systemvarable geschrieben, aber dann sofort wieder mit -100 überschrieben.

Benutzeravatar
udo1toni
Beiträge: 9814
Registriert: 11. Apr 2018 18:05
Answers: 131
Wohnort: Darmstadt

Re: Werte von OpenHAB in CCU Systemvariable schlägt fehl

Beitrag von udo1toni »

Also, der erste Punkt: Wenn Du Daten an ein Binding schicken willst, so ist das (bis auf eine Ausnahme) immer ein Befehl. Du müsstest also statt .postUpdate() einfach nur .sendCommand() verwenden.

Die andere Sache... ähm... sie sage ich es neutral... Du kannst natürlich einen Thomas-Mann-Satz ohne Leerzeichen als Namen eines Items verwenden, so dass sich dieser Itemname dann über zwei Bildschirmseiten hinzieht. Aber wie Du an Deiner Rule sehen kannst, ist das suboptimal. Niemand kann das vernünftig lesen oder in einer Rule damit arbeiten. (Ja, das war neutral :P )

Weiterhin ist es so, dass Du eigentlich gar keine zwei Items bräuchtest.
Du willst die Daten eines Channels des Bindings A in einen Channel des Bindings B transferieren.
Dazu verknüpfst Du einfach die beiden Channel mit dem gleichen Item und setzt für den "Slave"-Channel in den Metadaten die Option "Follow".
Du brauchst dazu keine Rule.

Noch mal zu den Itemnamen: Es gibt in openHAB zwei Schichten. Die eine Schicht ist die Hardware Ebene (auch wenn hier natürlich viele Dinge mit rein spielen, die gar keine Hardware betreffen... vielleicht sollten wir besser von einer externen Ebene sprechen) - diese Ebene wird mit Things und Channels abgebildet. Wenn ein System einen Bus hat, der dann mehrere gleichartige Things anbinden kann, so gibt es als zusätzliche Teilebene zu Channel und Thing noch die Bridge, die ist aber auch nur ein spezielles Thing.
Things sind also hardwareabhängig.

Die andere Ebene in openHAB ist der openHAB Bus (eigentlich steht das B in openHAB für Bus).
Auf dem openHAB Bus gibt es nur Items.
Und Events.
Und noch ein paar Status, die nicht in Items abgebildet sind...
Aber eigentlich gibt es nur Items ;)

Items sind niemals(!) Hardware abhängig. Allenfalls sind Items an einen Channel gebunden, der zu einer Hardware gehört. Aber die Items beziehen dann lediglich ihren Status und/oder Befehle von dieser Hardware und/oder senden ihrerseits Status und/oder Befehle an diesen Channel.

Daraus ergibt sich: Namen von Things sind sinnvoll auf konkrete Geräte zu beziehen, z.B. ein Homematic Aktor, ein MQTT-gesteuertes Device, eine Squeezebox, ein Samsung Fernseher, eine FRITZ!Box... Du verstehst, was ich meine.

Itemnamen sollten sich nicht auf eine Hardware beziehen, sondern ausschließlich auf ihre Funktion. Hier wäre z.B. MaximaleTemperaturHeute als Itemname in Ordnung, allerdings auch sehr länglich. Du als Administrator des Systems wirst genausogut mit TempMaxHeute auskommen, ohne auch nur den geringsten Teil einer Information zu verlieren. TempMaxHeute ist super lesbar. Niemand wird auf die Idee kommen, Temp als temporär auszulegen, oder als Bezug auf Tempo.

Und ja, openHAB schlägt die langen Namen vor. Aber Niemand zwingt Dich dazu, sie auch unverändert zu übernehmen.
openHAB2.5.12 in einem Debian-Container (Proxmox, LXC)

Jakobxyz
Beiträge: 26
Registriert: 10. Apr 2020 12:32

Re: Werte von OpenHAB in CCU Systemvariable schlägt fehl

Beitrag von Jakobxyz »

Namebezeichnung hin oder her, ich blick durch.

Nach langen probieren, ging das Verküpfen nicht, aber man muss die rule nur abändern statt .state -> .state.toString, dann gings

Benutzeravatar
udo1toni
Beiträge: 9814
Registriert: 11. Apr 2018 18:05
Answers: 131
Wohnort: Darmstadt

Re: Werte von OpenHAB in CCU Systemvariable schlägt fehl

Beitrag von udo1toni »

Wie gesagt... Das geht komplett ohne Rule.
openHAB2.5.12 in einem Debian-Container (Proxmox, LXC)

Benutzeravatar
peter-pan
Beiträge: 2183
Registriert: 28. Nov 2018 12:03
Answers: 22
Wohnort: Schwäbisch Gmünd

Re: Werte von OpenHAB in CCU Systemvariable schlägt fehl

Beitrag von peter-pan »

Jakobxyz hat geschrieben: 7. Jul 2022 11:36 Nach langen probieren, ging das Verküpfen nicht, aber man muss die rule nur abändern statt .state -> .state.toString, dann gings
Ich bin mir nicht sicher, ob das tatsächlich der richtige Weg ist.
Ich gehe mal davon aus, dass du die Systemvariable in deiner CCU als "Zahl" angelegt hast.
Auf der OH-Seite hast du dann dafür ein Number-Item mit dem Namen "GATEWAYEXTRAS1MaximaleTemperaturHeute" mit Channel-Link angelegt. Ausserdem hast du auf OH-Seite ein zusätzliches OWM-Item (OpenweathermapOneCallAPIWetterUndVorhersageForecastTodayMaxTemperatureohneC) vom Typ Number (ohne UoM) mit dem gleichen Channel-Link, wie das Original, angelegt.

Ich hab das dann mal mit dem ".state.toString" probiert.

Code: Alles auswählen

rule "Test Systemvariable"
 when 
   Item Dummy_4 changed  // Testschalter
 then GatewayExtras_1testzahl.sendCommand(OneCall_ForecastToday_MaxtemperatureOC.state.toString)
   logInfo("homematic","Gateway Testzahl")
end
Aber so richtig geklappt hat das nicht.

Was aber geklappt hat:

Code: Alles auswählen

rule "Test Systemvariable"
 when 
   Item Dummy_4 changed  // Testschalter
 then GatewayExtras_1testzahl.sendCommand(OneCall_ForecastToday_MaxtemperatureOC.state as Number)
   logInfo("homematic","Gateway Testzahl")
end
oder aber mit dem Original-Item(mit UoM):

Code: Alles auswählen

rule "Test Systemvariable"
 when 
   Item Dummy_4 changed  // Testschalter
 then GatewayExtras_1testzahl.sendCommand((OneCall_ForecastToday_Maxtemperature.state as Number).floatValue))
   logInfo("homematic","Gateway Testzahl")
end
Was die Item-Namen angeht, naja..., gehe ich mal davon aus, dass du da mit der Vorlage von RGroll aus dem internationalen Forum gearbeitet hast um mit dem Custom-Widget arbeiten zu können. Aber auch hier lässt sich(ein wenig :) ), trotz bestimmter Vorgaben, kürzen (z.B.: OneCall_ForecastToday_Maxtemperature).
udo1toni hat geschrieben: 7. Jul 2022 12:12 Wie gesagt... Das geht komplett ohne Rule.
Aber wie Udo schon sagte, das Ganze geht auch ohne Regel und der Wert wird auch kontinuierlich auf dem neuesten Stand gehalten. Und du brauchst auch kein zweites OWM-Item (ohne UoM).

Das sieht dann so aus:

Code: Alles auswählen

Number  GatewayExtras_1testzahl  "Test mit Systemvariablen "  <ccu3> (gCCU3)  ["Point"] {channel="openweathermap:onecall:bridge:local:forecastToday#max-temperature", channel="homematic:GATEWAY-EXTRAS-3014F711A0001F98A9AABCAF:3014F711A0001F98A9AABCAF:GWE00000000:1#test_Zahl" [profile="follow"]}

Antworten