Ausgehend von einem State ein Doif triggern?

[Tedious]

Hallo zusammen,

mir fehlt irgendwie der richtige Ansatz, vielleicht kann mir jemand mal einen Schubs geben...

Bei mir steuert ein RPi den 3D-Drucker. Die Software (OctoPi) ist in der Lage nach Beendigung des Drucks den RPi herunterzufahren. Status des RPi liefert ein Lanping (online/offline). RPi und Drucker hängen an einer 3-fach Steckdose mit Schalter. Momentan schalte ich nach Druckende alles per Hand aus, soweit, so gut. Die Leiste sollte zukünftig eine IT-Funksteckdose schalten.

Ein stumpfes Doif erscheint mir nicht sinnvoll (wenn RPi aus und Leiste an schalte ab - Doalways) - denn würde er ja theoretisch ständig versuchen zu schalten, oder? Sprich, ich brauche einen Dummy der einen Wert setzt wenn der RPi als online auftaucht auf den ich denn triggern kann - und das Doif "scharf" schaltet. Wenn der RPi denn aus ist und der Dummy sich ändert soll er die Funksteckdose ausschalten. Ist der Ansatz richtig, oder denke ich da (mal wieder) ums Eck?

Grüße

Sascha

[Frank_Huber]

Du kannst die wiederholung des gleichen Kommandos per Attribut unterbinden.
musst halt überlegen wie Du die Leiste wieder anschaltest. derPI hängt ja da auch dran.

also DOIF (PI AUS) (set Steckdosenleiste aus)
DOELSEIF (anderer Trigger (set steckdosenleiste an)

attr repeatsame 1:1

[Tedious]

Hi,

danke für den Denkanstoß. Anschalten erfolgt via Handy/Tablet/PC stumpf auf die Dose. Es geht nur drum das Ganze sauber auszuschalten. Wenn der RPi an war und denn plötzlich aus ist (also heruntergefahren wurde) schalte den Drucker aus. Ich denke mal drüber nach, wie gesagt - ich denke oft um zu viele Ecken...

[amenomade]

Mit

Code Auswählen Erweitern

DOIF ([RPI] eq "aus") (set Leiste aus) ohne do always oder andere attr, sollte es reichen. Der DOIF wird erst wieder "scharf" geschaltet, wenn [RPI] nicht mehr "aus" ist.

[amenomade]

Mit so einem Konstrukt musst Du aber aufpassen: antwortet aus irgendwelchem Grund dein Pi zum Ping nicht mehr (Netzwerkproblem, SDKarte defekt,...), wird dein 3D Drucker  plötzlich stromlos. Evtl. auch während eines Druckvorgangs

[Tedious]

Danke. Ich hab also mal wieder zu kompliziert gedacht

Da packe ich auf jeden Fall noch ein absenceThreshold zum Abfangen rein und Fehlschaltungen weitgehend zu vermeiden. Da noch eine Leistungsmessung davor hängt habe ich - falls es Probleme geben sollte - noch die Möglichkeit die als zweite Bedingung einzufügen - der Verbrauch sinkt stark wenn Hotend und Heizbett abgeschaltet werden.

[Tedious]

Moin,

ich hab am WE mal alles geflasht und umgelötet, DOIF gebaut - funktioniert aber nicht:

Code Auswählen Erweitern

([sonoffpow_1:POWER = "on"] and [Octopi:presence = "OFFLINE"]) (set sonoffpow_1 off)

Wenn Sonoff an (RPI und 3D-Drucker hängen an einer vom Sonoff gesteuerten Steckerleiste) und der Octopi aus ist (fährt nach dem Druck automatisch per script runter) schalte den Sonoff aus. Leider macht er das nicht. Ein "set sonoffpow_1 off" aus FHEM heraus funktioniert. Wo liegt mein Denkfehler?

EDIT: wenn ich das manuell triggere ( set [DOIF] cmd1) schaltet das Doif brav aus...

[amenomade]

Nur von Syntax aus (habe nicht über Sinn der Bedingungen überlegt):

Code Auswählen Erweitern

([sonoffpow_1:POWER] eq "on" and [Octopi:presence] eq "OFFLINE") (set sonoffpow_1 off)

[Tedious]

Hmm... liegts denn am = statt eq? Wäre natürlich ein Ansatz. Ich teste das mal, besten Dank!

[nils_]

'=' ist eine zuweisung

d.h. es könnte dein problem schon lösen

[amenomade]

Hmm... liegts denn am = statt eq? Wäre natürlich ein Ansatz.

Nicht nur. Liegt auch an der Position der Klammern.

Mit [Device:Reading] wird es aufs Reading des Devices getriggert.
Dann [Device:Reading] eq "etwas" => wird getestet.

Aber [Device:Reading eq "etwas"] bedeutet nix

[Tedious]

Prima, danke für den Schubs. Ich schaus mir heute Abend mal an und teste.