GELÖST: Status und Status-Icon eines Gerätes ändern, OHNE die Aktion auszulösen?

Begonnen von Uli Zappe, 06 Juli 2016, 05:00:12

Vorheriges Thema - Nächstes Thema

Uli Zappe

Hallo allerseits,

ich stehe vor einem Problem, das ich so nicht erwartet hatte: Ich finde keinen Weg, den Status eines FHEM-Gerätes einschließlich des Icons auf der Web-Oberfläche verändern, ohne die zugehörige Aktion auszulösen.

Im Detail:

Ich habe etliche elektronische Geräte (HiFI-Anlage, Computer, Projektor, ...), die ich in FHEM integrieren will, d.h. ich will sehen können, ob sie an oder aus (= in Bereitschaft/im Schlafmodus) sind und sie schlafen legen bzw. aufwecken können.

All diesen Geräten ist gemein, dass sie auch völlig unabhängig von FHEM an- oder ausgeschaltet werden können, so dass ich eine Statusabfrage brauche, die unabhängig von den Ein-/Ausschaltvorgängen funktioniert. Das sind in meinem Fall bisher PRESENCE-Module mit Ping-Abfrage oder Shellskripten, die spezielle Binaries aufrufen, oder FS20-Stromverbrauchsmesser, die Statussignale (Strom/kein Strom) an FHEM senden.

Ebenso gibt es unterschiedliche Methoden zum An- und Ausschalten, die funktionieren aber alle prima und sind hier nicht das Thema.

Da das Problem, auf das ich stoße, immer dasselbe ist, beschränke ich mich im Folgenden beispielhaft auf die Ping-Abfrage mit PRESENCE.

Die Idee ist, dass PRESENCE über notify mit einer Aktion verknüpft ist, die überprüft, ob der Status, den PRESENCE meldet, dem gespeicherten Gerätestatus entspricht, und falls nicht, diesen ändert.

Als Beispiel für den Rechner woodstock (vereinfacht, nur die hier wichtigen Parameter):

define woodstock_STATE PRESENCE lan-ping woodstock 1 1
define woodstock_PAIRon notify woodstock_STATE:present { if(Value("woodstock") eq "off") { fhem("set woodstock on") } }
define woodstock_PAIRoff notify woodstock_STATE:absent { if(Value("woodstock") eq "on") { fhem("set woodstock off") } }


Diese Implementation hätte aber das Problem, dass eine Aktion ausgelöst wird, statt nur der gespeicherte Zustand geändert. Wenn woodstock z.B. durch einen Tastendruck an seiner Tastatur aufgeweckt wird, würde unsinnigerweise eine nochmalige Aktion ausgelöst, ihn aufzuwecken. Im besten Fall ist das harmloser Overhead, es kann aber leider auch zu diversen Problemen führen (spielt hier keine Rolle, welche genau). So geht es also definitiv nicht, das war von Beginn an klar.

Nur dachte ich, dass dies super-einfach zu lösen wäre, denn genau dafür – so meine Vermutung – gibt es ja den Befehl setstate in FHEM, der gerade keine Aktion beim Setzen des Status auslöst:

define woodstock_STATE PRESENCE lan-ping woodstock 1 1
define woodstock_PAIRon notify woodstock_STATE:present { if(Value("woodstock") eq "off") { fhem("setstate woodstock on") } }
define woodstock_PAIRoff notify woodstock_STATE:absent { if(Value("woodstock") eq "on") { fhem("setstate woodstock off") } }


In der Tat wird nun keine Aktion ausgelöst, zu meiner Überraschung wird aber das Status-Icon auf der Web-Oberfläche ebensowenig verändert, womit diese Lösung unbrauchbar ist.

Abhilfe schafft hier trigger:

define woodstock_STATE PRESENCE lan-ping woodstock 1 1
define woodstock_PAIRon notify woodstock_STATE:present { if(Value("woodstock") eq "off") { fhem("setstate woodstock on;; trigger woodstock on") } }
define woodstock_PAIRoff notify woodstock_STATE:absent { if(Value("woodstock") eq "on") { fhem("setstate woodstock off;; trigger woodstock off") } }


Jetzt wird das Icon wieder aktualisiert, aber jetzt werden auch die Aktionen wieder gesendet, d.h. ich bin wieder am Anfang. (Ich vermute mal, dass de facto set nichts anderes ist als setstate plus trigger.)

Mein Problem also: Wie kann ich den Status eines FHEM-Gerätes einschließlich des Icons auf der Web-Oberfläche verändern, ohne die zugehörige Aktion auszulösen?

Danke im Voraus für alle Antworten!

Starkstrombastler

Probiere mal folgendes:
definiere vier Stati:  on, off, ON, OFF
Presence setzt Status auf ON oder OFF
attr devStateIcon  device on:icon-on:off ON:icon-on:off off:icon-off:on OFF:icon-off:on
Das notify auf device schaltet nur bei 'on' oder 'off' das Zielgerät
IPC\Ubuntu + Fhem, 1wire, Shellies, Siemens Logo!, Z-Wave, PhilipsTV, Vu+duo2, KM200

justme1968

der longpoll update für das frontend hängt an genau dem gleichen event wie dein notify und das bei der bei änderung der readings und mit dem trigger erzeugt wird. so lange es das gleiche event ist geht das eine nicht ohne das andere. d.h. du musst unterschiedliche events verwenden.

z.b. mit dem vorschlag von oben.

genau für deine anwendung gib es in PRESENCE aber auch schon das powerCmd attribut und das power kommando.

im attribut konfigurierst du die kommandos die zum ein- und ausschalten verwendet und. in devState icon und anderswo verwendest du das power kommando. damit hast du die events zum schalten und für den status getrennt und beides kommt sich nicht mehr in die quere.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Uli Zappe

Danke für Eure Tipps!  :D

Ich hoffe, ich werde heute Abend Zeit haben, das auszuprobieren (und dann natürlich hier berichten).

Uli Zappe

Zitat von: justme1968 am 06 Juli 2016, 08:28:57
genau für deine anwendung gib es in PRESENCE aber auch schon das powerCmd attribut und das power kommando.

im attribut konfigurierst du die kommandos die zum ein- und ausschalten verwendet und. in devState icon und anderswo verwendest du das power kommando. damit hast du die events zum schalten und für den status getrennt und beides kommt sich nicht mehr in die quere.
Ich habe jetzt versucht, das auszuprobieren, aber ich befürchte, ich bin zu blöd dafür. Dein Vorschlag klang so simpel, aber ich kriege es einfach nicht hin, und es scheint in realiter auch deutlich komplizierter zu sein.

Also Schritt für Schritt:

Zum Aufwecken und Schlafenlegen des Computers woodstock verwende ich zwei völlig getrennte Kommandozeilenprogramme. Der power-Befehl von PRESENCE kann aber nur ein einen Befehl mit zwei Attributen für ein und aus auslösen, folglich brauche ich zur Übersetzung erstmal einen dummy mit zwei notifys:

define woodstock_SWITCH dummy
attr woodstock_SWITCH setList on off
define woodstock_SWITCHon notify woodstock_SWITCH:on "/usr/local/bin/wake woodstock"
define woodstock_SWITCHoff notify woodstock_SWITCH:off "/usr/local/bin/sleepmac woodstock"

OK?

Dann kann ich problemlos den power-Befehl in PRESENCE definieren:

define woodstock_STATE PRESENCE lan-ping woodstock 1 1
attr woodstock_STATE powerCmd set woodstock_SWITCH $ARGUMENT

OK?

PRESENCE selbst bietet aber keine Möglichkeit, Schalter auf der Weboberfläche darzustellen. Folglich brauche ich dazu einen weiteren dummy samt dazugehörigem notify:

define woodstock dummy
attr woodstock setList on off
define woodstockOnOff notify woodstock set woodstock_STATE power $EVENT

OK?

So, und jetzt stehe ich komplett auf dem Schlauch. Wie sorge ich jetzt dafür, dass der vom dummy woodstock auf der Weboberfläche erzeugte Schalter jederzeit den aktuellen Status der PRESENCE-Instanz woodstock_STATE darstellt und beim Klick auf den Schalter entsprechend toggelt (also set woodstock_STATE power on sendet, wenn der Status off ist und umgekehrt)? Ich verstehe nicht, wie das mit devStateIcon funktionieren soll. Und ein notify von woodstock_STATE an woodstock zum Statusupdate kann ich genauso wenig senden, weil ich ja dann wieder in die Situation käme, dass dadurch ungewollt die entsprechende Aktion ausgelöst wird ...

Kannst Du mir sagen, mit welchem Code genau das gehen soll? Alles, was ich probiert habe, hat nicht funktioniert ...  ::)

Danke!

marvin78

Lagere den Aufruf der Skripte einfach in eine sub der myUtils aus, dann benötigst du weder dummys noch sonst irgendwelche weiteren Hilfen. Im powerCmd des PRESENCE Devices rufst du dann nur diese sub mit den entsprechenden Argumenten auf (siehe Doku zu PRESENCE). Die sub entscheidet dann anhand der Argumente, welches Skript es aufruft. Ein wenig Perl ist hier natürlich nötig.

Uli Zappe

Zitat von: marvin78 am 07 Juli 2016, 07:39:36
Lagere den Aufruf der Skripte einfach in eine sub der myUtils aus, dann benötigst du weder dummys noch sonst irgendwelche weiteren Hilfen. Im powerCmd des PRESENCE Devices rufst du dann nur diese sub mit den entsprechenden Argumenten auf (siehe Doku zu PRESENCE). Die sub entscheidet dann anhand der Argumente, welches Skript es aufruft. Ein wenig Perl ist hier natürlich nötig.
Aber das Problem ist doch nicht die Entscheidung, welches Skript aufzurufen ist – das geht ja prima mit dem dummy, auch wenn es mit einer eigenen sub natürlich kompakter zu lösen wäre.

Das Problem ist die Statusanzeige im Schalter auf der Weboberfläche, und da hilft mir auch keine sub weiter, jedenfalls nicht, wenn ich ganz grundsätzlich nicht kapiere, wie ich die Statusanzeige auf dem Schalter ändern kann, ohne gleichzeitig ungewollt den Schaltvorgang erneut auszulösen.

marvin78

Warum möchtest du, dass dein Device einen Status anzeigt, den es noch gar nicht hat? Das erschließt sich mir nicht. Die PRESENCE Lösung sorgt dafür dass du schalten kannst und in dem Moment, in dem Das Gerät an (oder aus) ist, liefert PRESENCE auch den richtigen Status (-> richtiges Icon).

Du benötigst hier keine weiteren notifys, setstate oder ähnliches. Es lässt sich alles in PRESENCE lösen.

Uli Zappe

Zitat von: marvin78 am 07 Juli 2016, 08:33:57
Es lässt sich alles in PRESENCE lösen.
Aber wie?

Sorry, es hilft mir nix, dass jemand sagt, dass etwas geht, wenn ich eben nicht weiß, wie es geht.

PRESENCE kann doch (auch bei definiertem power-Befehl) keine Schalter auf der Weboberfläche erzeugen, oder sehe ich das falsch?

Wenn es das aber nicht kann, benötige ich dafür mindestens einen dummy, den ich irgendwie mit PRESENCE koppeln muss – und da gehen die Probleme dann los.

Wo liegt mein Denkfehler?


justme1968

der schalter ist das icon des PRESENCE device. und da legst du mit devStateIcon das power kommando drauf.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

marvin78

Doch. Das kann es. Du brauchst keinen dummy (was dir hier ja schon beschrieben wurde). Der Schalter ist das ICON des PRESENCE Devices (über devStateIcon einstellbar). Wenn man die Doku oder eben viele viele Beispiele hier im Forum dazu liest, kommt man auch schnell drauf, wie das geht. Aber ich verstehe schon, du willst ein komplettes Kochrezept und nicht selbst was machen.

Hier ein komplettes Beispiel:

List vom PRESENCE Device:
Internals:
   ADDRESS    192.168.178.31
   CHANGED
   DEF        lan-ping 192.168.178.31 80 90
   MODE       lan-ping
   NAME       OG.sr.XX.ServerOnline.pres
   NOTIFYDEV  global
   NR         475
   NTFY_ORDER 50-OG.sr.XX.ServerOnline.pres
   STATE      present
   TIMEOUT_NORMAL 80
   TIMEOUT_PRESENT 90
   TYPE       PRESENCE
   Helper:
     Dblog:
       State:
         Logdb:
           TIME       1467858083.05397
           VALUE      statusRequest
   Readings:
     2016-05-02 17:03:10   powerCmd        executed
     2016-07-07 08:42:41   presence        present
     2016-07-07 08:42:41   state           present
   Helper:
Attributes:
   DbLogExclude powerCmd
   alias      Server
   devStateIcon present:rc_GREEN:off absent:rc_RED:on set_on:rc_YELLOW set_off:rc_STOP
   event-on-change-reading state
   eventMap   /power on:on/ /power off:off/ /power reboot:reboot/
   group      IT
   icon       it_nas
   powerCmd   {StartStopServer("$ARGUMENT","$NAME")}
   room       Serverschrank
   sortby     B04


sub in der myUtils:


sub StartStopServer($$) {
    my ($action,$dev) = @_;
    system('wakeonlan 00:11:32:29:5B:FF') if ($action eq "on" && Value($dev) ne "present");
  system('/opt/fhem/scripts/poweroff_mediaserver.sh &') if ($action eq "off" && Value($dev) eq "present");
  if ($action eq "reboot" && Value($dev) eq "present") {
      system('/opt/fhem/scripts/reboot_mediaserver.sh &');
  }
  Log 4, "MediaServer: power".$action;
  return undef;
}

Uli Zappe

Zitat von: marvin78 am 07 Juli 2016, 08:46:15
Doch. Das kann es.
OK, das war mir halt nicht klar.

ZitatDu brauchst keinen dummy (was dir hier ja schon beschrieben wurde).
Von Dir vor ein paar Minuten, ja. Vorher nicht.

ZitatDer Schalter ist das ICON des PRESENCE Devices
Nur dass meine PRESENCE-Geräte dummerweise keine Icons haben ...

Zitat(über devStateIcon einstellbar)
Ahaaa! Das ist die entscheidende Information. Das war mir nicht klar.

ZitatWenn man die Doku oder eben viele viele Beispiele hier im Forum dazu liest, kommt man auch schnell drauf, wie das geht.
Vielleicht, wenn man so clever ist wie Du. Ich hatte jetzt geschlagene 11 Stunden damit zugebracht, das herauszufinden, und war keinen Schritt weitergekommen.

Denn sorry, in der Dokumentation steht das einfach nicht. Ich habe aufgrund der vorangegangenen Hinweise wirklich alles, was in der Doku zu devStateIcon steht, mehrfach gelesen. Aus nichts lässt sich entnehmen, dass devStateIcon Geräten, die von Haus aus überhaupt keine Schalter abbilden, welche erzeugt. Wenn man schon weiß, dass das so ist, lassen die Texte sich so verstehen, das habe ich mir gerade noch einmal angesehen, ja. Wenn man das aber nicht weiß, kommt man durch die Infos in der Dokumentation absolut nicht drauf. Ich war mir sicher, dass devStateIcon nur genau dann weiterhilft, wenn bereits ein klickbarer Statustext da ist, man aber stattdessen ein Icon möchte (das suggeriert ja auch der Name). Einen klickbaren Text gibt es per Default in PRESENCE aber nicht.

Und im Forum habe ich etliche Suchbegriffe ausprobiert, ohne etwas für mich Einschlägiges zu finden. Das ist das Problem, wenn einem die Sache so unklar ist, dass man gar nicht weiß, wie man die Suche eingrenzen soll. Und alle 3740 Treffer auf fhem.de zu devStateIcon zu lesen – sorry, das schaffe ich nicht.

ZitatAber ich verstehe schon, du willst ein komplettes Kochrezept und nicht selbst was machen.
Ich habe bestimmt insgesamt 30, 40 Stunden versucht, das selbst zu machen. Ich habe es halt nicht geschafft. Deshalb habe ich jetzt um Hilfe gebeten. Ist das denn so verwerflich?

ZitatHier ein komplettes Beispiel:
Danke!

marvin78

Dass devStateIcon auf ALLE Devices angewendet kann, steht schon implizit in der Doku und ist natürlich Grundlagenwissen. Auch der Name "devStateIcon" impliziert eigentlich nicht, dass man es nur bei klickbaren Devices anwenden kann. Es impliziert, dass es ein Icon für den STATE einrichtet.

Ich mache dir gar keinen Vorwurf aber mir persönlich wäre deine Vorgehensweise zu anstrengend. Man sollte sich von den Grundlagen zu "höheren" Dingen durcharbeiten. Beispiele für devStateIcon finden man so viele, dass es einen erschlägt, ja, aber man muss sich ja nur wenige anschauen, um es zu kapieren.

Die Doku zu PRESENCE ist im Übrigen auch eindeutig.

Kleiner Tipp: Nicht die fhem.cfg direkt editieren, sondern Attribute über das Frontend (Detailansicht) setzen. Dann weißt du ganz genau, welche Attribute dir für das entsprechende Device zur Verfügung stehen.

Uli Zappe

Zitat von: marvin78 am 07 Juli 2016, 09:28:07
Dass devStateIcon auf ALLE Devices angewendet kann, steht schon implizit in der Doku
Naja, es steht implizit da ist letztlich eine nette Umschreibung für es steht nicht da ...  ;)

Zitatund ist natürlich Grundlagenwissen.
Was heißt ,,natürlich"? Woher soll dieses Wissen denn kommen? Wenn es Grundlagenwissen wäre, würde ich erwarten, dass etwas darüber in der PDF-Einführung steht, da taucht devStateIcon nicht einmal auf ... Und die Beschreibung in commandref ist sehr knapp und äußerst kryptisch; es werden sofort zwei Fälle unterschieden, statt erstmal in einem Satz zu klären, wofür das Attribut überhaupt gut ist.

ZitatMan sollte sich von den Grundlagen zu "höheren" Dingen durcharbeiten.
Ja, aber irgendwann sollte man auch fertig werden mit seiner Haussteuerung ...  :P

Ich bin ja nun kein komplettes Greenhorn, ich nutze FHEM seit 4 Jahren, habe mittlerweile eine ziemlich komplexe Konfiguration, die ansonsten wunderbar funktioniert, und übrigens mit zahllosen definierten devStateIcon-Attributen – halt immer in Geräten, die schon von Haus aus Schalter hatten. Ein ganz klein bisschen Code von mir hat es sogar in die FHEM-Distribution geschafft.

Nur das Problem, das ich jetzt hatte, hatte ich eben noch nie, und es wurde Zeit, es zu lösen.

ZitatBeispiele für devStateIcon finden man so viele, dass es einen erschlägt
Forumsbeiträge, ja. Instruktive Code-Beispiele habe ich in all den Forums-Fundstellen, die ich mir angesehen habe, keine gefunden.

Zitatja, aber man muss sich ja nur wenige anschauen, um es zu kapieren.
Nein, wenn man felsenfest davon überzeugt ist, dass sich devStateIcon nur bei Geräten anwenden lässt, die schon Schalter besitzen, dann kann man schauen, solange man will, und kommt nicht auf diese Idee.

ZitatDie Doku zu PRESENCE ist im Übrigen auch eindeutig.
?? In der Dokumentation zu PRESENCE taucht devStateIcon überhaupt nicht auf ...

Wie auch immer, ich werde mich jetzt mal dransetzen, beide vorgeschlagenen Varianten zu implementieren und dann berichten.

marvin78

Ich bin raus. Beiträge zerpflücken ist nicht der Stil, in dem ich mich unterhalte. Im Zusammenhang lesen ist mein Rat an dich.