Sleep Befehl MQTT

[Petrocelli63]

Hallo,
ich habe ein Problem.
Ich nutze eine Beweungsmelder um damit das Küchenlicht zu schalten. Gleichzeitig kann ich auch das Küchenlicht manuell schalten. In diesem Fall nutze ich einen Dummy mit dem ich über ein Notify das Küchenlicht manuell schalten kann. Im Code für das schalten mit dem Bewegungsmelder ist vorher eine If Abfrage, ob der Dummy bereits ON ist, damit in diesem Fall nicht mehr das Licht schaltet. Wenn das Licht (Dummy) allerdings OFF ist, startet das Küchenlicht wahre Schaltorgien. Ich glaube, das es mit dem Sleep Befehl zusammenhängt. Der Bewegungsmelder gibt ein neues Signal, obwohl das alte noch nicht abgeschlossen ist. Kann man diesen Sleep Befehl unterbrechen, um dem MQTT Device einen neuen Befehl zu geben, das heißt, wenn zB das MQTT noch im Sleep hängt, kurz bevor es dann wieder ausschaltet.

Code

Code Auswählen Erweitern


Bewegungsmelder4:on {
  if (Value("Tageslicht") eq "dunkel") {
     if (Value("Kuechenlicht") eq "off") { Abfrage Dummy ob manuell Licht angeschaltet
          fhem ("set MQTT2_sonoff_kuechenlicht on;sleep 120;set MQTT2_sonoff_kuechenlicht off;");
     }
  }
}
Code für den Dummy um das Licht manuell zu schalten:
Kuechenlicht:* {
  if ($EVENT eq "on") {
     fhem ("set MQTT2_sonoff_kuechenlicht on");
  } else {
     fhem ("set MQTT2_sonoff_kuechenlicht off");
  }
}


Grüße
Peter

[Beta-User]

Das zu schaltende Ziel-Device ist doch vom TYPE MQTT2_DEVICE, oder?
Dann nutze doch ein einfaches on-for-timer, dann brauchst du die timer nicht manuell zu überwachen. (Ansonsten suche mal nach "benanntem sleep"; da steht v.a. was in der cref).

Gruß, Beta-User

[Petrocelli63]

Danke,
on-for-timer scheint zu klappen. Ich hatte irgendwo in Forum gelesen, dass on-for-timer bei einem MQTT Device nicht funktioniert und es erst überhaupt nicht ausprobiert 
Aber geht bisher ganz gut. Jetzt muss ich nur noch hinbekommen, dass ich, wenn der Timer aktiv läuft und ich das Licht manuell schalte, der Timer das Licht nicht wieder ausschaltet. Also eigentlich den on-for-timer reseten.

[CoolTux]

Das kannst Du ganz einfach machen in dem Du wieder ein on-for-timer setzt. Dann wird der alte gelöscht und der neue angelegt.

[Beta-User]

Das mit den setExtensions ist einer der Vorteile, den MQTT2_DEVICE gegenüber MQTT_DEVICE hat.

Ich gehe mal davon aus, dass setExtensions auch so schlau ist, den internen Timer abzubrechen, wenn jemand auf on schaltet (jedenfalls, wenn es aus FHEM heraus geschieht). Habe das aber noch nicht getestet.

[CoolTux]

Das mit den setExtensions ist einer der Vorteile, den MQTT2_DEVICE gegenüber MQTT_DEVICE hat.

Ich gehe mal davon aus, dass setExtensions auch so schlau ist, den internen Timer abzubrechen, wenn jemand auf on schaltet (jedenfalls, wenn es aus FHEM heraus geschieht). Habe das aber noch nicht getestet.

Das ist in der Tat so.

[hexenmeister]

Das mit den setExtensions ist einer der Vorteile, den MQTT2_DEVICE gegenüber MQTT_DEVICE hat.

Stimmt nicht ganz. Habe Es wurde seit geraumer Zeit setExtentions-Unterstützung in MQTT_DEVICE eingebaut (vor ca. 2-3 Jahren).
Die Definitionen sind anders, vermutlich in dem Neuen etwas logischer, ansonsten sind die Devices in ihrer Funktionalität weitgehend gleichwertig.
Bei IOs sieht es schon etwas anders aus. Server unterstützt autocreate (wer's braucht...) und Client unterstützt TLS. Verschlüsselung ist tatsächlich ein wichtiger Vorteil. Sonst sehe ich keine, die ich als wirklich relevant ansehen würde

[Beta-User]

Stimmt nicht ganz. Habe seit geraumer Zeit setExtentions-Unterstützung in MQTT_DEVICE eingebaut (vor ca. 2-3 Jahren).

Danke für die Info, das war mir nicht bewußt...

EDIT: Grade gefunden, als ich mich auf die Suche begeben habe, was eigentlich für MySensors noch erforderlich ist, damit das funtioniert: https://forum.fhem.de/index.php/topic,82240.msg743072.html#msg743072
Das was Anfang 2018; ist zwar auch schon eine Weile her, und dass man dafür ein Attribut setzen. Das erlärt vermutlich, warum mir das verborgen geblieben ist .

[hexenmeister]

Stimmt. Kam in meiner Erinnerung als eine Ewigkeit vor...
Das Attribut habe ich aus Sorge um Abwärtskompatibilität eingeführt.

[hexenmeister]

Stimmt. Kam in meiner Erinnerung als eine Ewigkeit vor...
Das Attribut habe ich aus Sorge um Abwärtskompatibilität eingeführt.

Huch... War ja gar nicht mein Patch. Habe mir (ungewollt) fremde Lorbeeren zugeschrieben

[Beta-User]

  Alles gut...

[OT]
Wenn du magst, könntest du "als Ausgleich" mal einen Blick in die MySensors-Module werfen (die sind ja ähnlich "besonders" gestickt wie MQTT-V1). Mir ist überhaupt nicht klar, wie der ursprüngliche code funktioniert hat mit den GPUtils. Jedenfalls scheint es nicht (mehr ?) zu funktionieren, oder übersehe ich irgendwas?

[hexenmeister]

Beides wurde damals von Norbert entwickelt. Leider ist er seit Jahren nicht mehr hier im Forum aktiv.
Fanktionieren sollte es alles noch, geht ja im MQTT auch. Eine Änderung ist nicht einfach und ist testintensiv. Hatte für MQTT mal vor, habe aber sein gelassen. Eine Neuentwicklung ist voraussichtlich zielführender.
Welches Problem genau besteht mit MY_SENSORS?

[Beta-User]

Über das Client-Matching bin ich gestolpert, weil ich eine abgewandelte Version benötigen würde, um den passenden Client für Messages an ein "Kanal76"-IO rauszufinden (MYSBootloader-OTA, wenn man sonst nicht Kanal 76 nutzt). Sonst funktioniert alles weitgehend - eben bis auf setExtensions, für das ich jedenfalls keine sets usw. sehe...
Ich wollte dazu ggf. ein paar templates basteln für AttrTemplate; in dem Zusammenhang ist mir das überhaupt erst aufgefallen, dass da zwar im Code setExtensions irgendwie einbezogen wird, aber die sets nicht da sind. Ist aber evtl. auch darin begründet, dass alles "eine Ebene tiefer" liegt, also eigentlich ein bestimmter von mehreren Kanälen geschaltet wird (wenn man z.B. mehrere Relais angeschlossen hat).

Die matching-Funktion bekomme ich vermutlich vollends mit einer geänderten Kopie aus GPUtils hin, aber ich will auch keine großen Böcke schießen, und wenn ich eh' dabei bin...

[hexenmeister]

SetExtensions muss aufgrerufen werden, wenn keine Argumente in SetFn passen.
Soweit es dort steht:

Code Auswählen Erweitern

return grep (/(^on$)|(^off$)/,keys %{$hash->{sets}}) == 2 ? SetExtensions($hash, $list, $name, $command, @values) : "Unknown argument $command, choose one of $list";
verstehe ich das so, dass das dann hier der Fall ist, wenn unter 'sets' beide Werte 'on' und 'off' vorkommen. Irgendwie logisch. Steht auch so im Commandref. SetExtensionsCancel sollte noch aufgerufen werden.

Was passiert, wenn man on-for-timer auswählt? Wird nie wieder ausgeschaltet oder wird gar nicht erst angeboten?

[Beta-User]

..das hatte ich auch so verstanden, steht auch so hier: https://wiki.fhem.de/wiki/DevelopmentModuleIntro#X_Set
Das "Problem" ist, dass es bereits eine ähnliche Funktion gibt, die dann in die GPUtils verweist (Zeile 311, 320, z.B.), von der ich wiederum - jedenfalls bislang, ich kenne das Thema auch erst seit ein paar Tagen - nicht so recht weiß, was da passiert; so wie das konstruiert ist, müßte nach meinem Verständnis seinerseits innerhalb der aufgerufenen Funktion setExtensions aufgerufen werden...

Jedenfalls gibt es bei meinen Nodes kein "set ... on-for-timer ..." usw., das wird gar nicht angeboten (auch nicht da, wo es on/off für statusx gibt). Und da es im Prinzip auch so ist, dass in der Regel nicht der Status gesetzt wird ("set MYSENSOR_96 status1 on-for-timer 20"), landet ein on-for-timer auch "nur" im entsprechenden Reading; das sieht nicht so aus, als liefe da ein Timer; nach 20 Sek.  kommt in diesem Beispiel auch kein off).