mad-mike hat geschrieben: ↑22. Aug 2022 01:14
Sobald ich dort "Write / Read" markiere, wechselt das Item von OFF zu Undef.
Nein, das ist der Channel. der spielt hier aber keine Rolle, der darf durchaus write only bleiben.
Du musst aber dafür sorgen, dass das Item den Status passend zum letzten gesendeten Befehl bekommt. Ich gehe davon aus, dass das Licht auch über openHAB geschaltet wird. Im Item definierst Du über die Metadaten autoupdate = true. Danach sollte der Status des Items immer dem letzten Befehl folgen, also auf ON oder OFF wechseln. Der Vergleich prüft genau das ab, ob der Status von OFF abweicht oder nicht. Und da könnte auch der Fehler liegen, wenn nämlich der Status NULL oder UNDEV ist, ist er ebenfalls von OFF verschieden, dann käme die Nachricht ebenfalls.
Nun ist die Frage, was schlimmer ist: Eine Nachricht, die Dir sagt, das Licht sei noch an, obwohl das nicht der Fall ist, oder keine Nachricht, obwohl das Licht an ist - deshalb die Prüfung in dieser Form. Man könnte auch if(... == ON) prüfen, aber dann bekommst Du nicht mit, wenn ein Fehler vorliegt, wegen dem die Rule nie Alarm schlägt.
mad-mike hat geschrieben: ↑22. Aug 2022 01:14
Aus irgendeinem Grund hatte sich der Timer vorgestern abend nicht gelöscht oder so. Habe die Ganze Nacht, alle 30 Min, Nachricht bekommen, das die Lampe noch an ist.
Ja, siehe oben. Am einfachsten wird man das los, indem man das Licht gezielt einmal ein- und wieder ausschaltet. Die Rule löscht zuverlässig den Timer weg, bei jedem Schaltvorgang (bzw. wenn sich der Zustand des Items ändert).
mad-mike hat geschrieben: ↑22. Aug 2022 01:14
Ich ändere Die Item Namen dann Passend ab. Das heisst, das Item hat den Namen: Garten, Flutlicht klein.
So wird mir das auch in der Sitemap angezeigt. (also Alle Namen die ich vergebe, werden in der Sitemap korrekt angezeigt).
Nur in der Rule, muss ich dann halt:
Code: Alles auswählen
HTTPURLThing_km1
eingeben.
Da bringst Du was durcheinander. Das ist nicht der Name des Items, sondern das Label. Das Label kannst Du immer nach eigenem Gusto beschriften.
Ich rede aber vom Namen des Items, auch dieser Name sollte nicht vom Channel oder gar Thing abhängen.
Stell Dir mal vor, Du hast eine Schaltsteckdose zum dazwischen stecken. Die Technologie ist Homematic (nur als Beispiel) und Du schaltest damit im Wohnzimmer eine Stehlampe.
Du nennst das Item Homematik_Zwischenstecker_3_Power_Switch. (Weil es ein Homematic Zwischenstecker ist, der dritte, den Du eingebunden hast...)
Jetzt stößt Du auf Sonoff Basic Module, die man mit einer alternativen Firmware bespielen kann. Die Module sind so kompakt, dass Du eines davon direkt in den Fuß der Leuchte einbauen kannst, womit der hässliche Klotz an der Wand endlich weg kann.
Du baust die Leuchte um.
Und weil Du diverse Regeln hast, in denen Du die Stehlampe schaltest, bist Du in einem Dilemma, denn entweder legst Du nun zusätzlich zum neuen Generic MQTT Thing für das Sonoff Basic noch ein neues Item MQTT_Sonoff_Basic_1_Power_Switch an und tauschst den Namen in allen Rules aus (und es sind eeeecht viele Rules...) oder Du verlinkst einfach das alte Item mit der neuen Hardware, aber der Name passt dann überhaupt nicht mehr.
Hättest Du mal auf meinen Ratschlag gehört und das Item GF_WZ_Stehlampe genannt...
Das ist nämlich einer der wichtigen Punkte in openHAB: die beiden Teile, Channel und Items, sind voneinander getrennt. Man kann jederzeit Verbindungen anders konfigurieren und muss nichts an den Abhängigkeiten anpassen.
Und wenn man die Itemnamen systematisch erstellt, muss man nicht mal zwingend nachschauen, wie das Item heißt, es reicht, zu wissen, dass das Wohnzimmer im Erdgeschoss ist (GF = Ground Floor) und als WZ in allen Itemnamen auftaucht. Da die Stehlampe im Wohnzimmer steht, ist der Name dann einfach herzuleiten. Auch das Semantic Model kann da äußerst hilfreich sein.
Ich habe meine Itemnamen auch mal an der Hardware ausgerichtet und bin schon sehr lange davon abgekommen, es ist einfach komplett unlogisch, so vorzugehen. Dass openHAB die Namen aus den Things generiert, ist da kein Widerspruch, schließlich weiß openHAB es nicht besser.
