Über devStateIcon eines Devices ein fremdes/zweites Device steuern

[Nogga]

Das ist ein Cross-Post von https://forum.fhem.de/index.php/topic,110595.0.html

Folgende Konstellation:
Ich möchte gerne FHEM-Web "WAF" konform machen, auch für das Smartphone. Beim Smartphone wird in der Regel nur das erste Command, bzw. devStateIcon/State angezeigt. Das passt.
Meine HM-Rolllo-Aktoren kennen aber kein Toggle, sodass ich diese für eine Ein-Tasten-Steuerung über einen virtuellen Kanal der CCU gehe.

D.h.
Ich habe ein Device (-Rollo-Aktor), dessen devStateIcon per Klick das zweite Device (=virt. Kanal der CCU) triggern soll.

Geht das überhaupt?

[Beta-User]

Das geht, aber du mußt dafür "etwas Perl" verwenden...

Habe leider kein einfacheres Beispiel zur Hand, sondern nur meinen Code für einen ZWave-Aktor im Jalousiemodus. Der zeigt zwei (veränderliche) Icons, und das Icon für den Drehwinkel der Jalousie zeigt auf ein zweites Device. Das ist das, was du hier brauchst, die relevante Zeile aus dem Gesamtcode ist diese hier:
https://github.com/rejoe2/FHEM/blob/master/99_myUtils_ZWave.pm#L43

Code Auswählen Erweitern

$ret .= "<a href=\"/fhem?cmd.dummy=set $slatname $command_string&XHR=1\">" . FW_makeImage($symbol_string,"fts_blade_arc_close_100") . " $slatlevel \%</a>";

Der Rückgabewert muß also kompletter html-Code sein, und die set-Anweisung ist als href vercodet. Zum Testen mal eine statische Variante:

Code Auswählen Erweitern

{my $image =  FW_makeImage("fts_shutter_10","fts_blade_arc_close_100"); qq(<a href="/fhem?cmd.dummy=set CCU_VIRT_01 datapoint PRESS_SHORT 1&XHR=1">$image</a>");}set

[rudolfkoenig]

Waum nimmt man nicht das zweite Geraet zum steuern?

Alternativen zu der Perl-Loesung:
- per cmdalias toggle "implementieren"
- dummy mit setList und notify/notifies

[justme1968]

und warum braucht man toggle? devStateIcon kann doch je nach aktuellem zustand beim klick ein anderes kommando ausführen.

[Beta-User]

und warum braucht man toggle? devStateIcon kann doch je nach aktuellem zustand beim klick ein anderes kommando ausführen.

Na ja, bei dem HM-Aktor ist es ja so, dass der selber weiß, wie er als nächstes auf den short-Trigger reagieren muß, es geht also eigentlich nicht um toggle...

Waum nimmt man nicht das zweite Geraet zum steuern?

Hatte das so verstanden, dass nicht mal das erste Gerät zum Steuern genommen werden soll; da gäbe es vermutlich auch die Option, einen Schieberegler anzuzeigen und zumindest mit einem "normalen" devStateIcon irgendwie zu toggeln. Hier war aber - aus welchen Gründen auch immer - grade die Frage, wie man es mit einem "toggelnden" Einfachtaster macht (toggeln ist mMn. hier ungenau, denn das Verhalten des Aktors ist auch unterschiedlich, je nachdem, ob der gerade noch am Fahren ist oder schon angehalten hat...).

Wie immer: Viele Möglichkeiten es gibt...

[justme1968]

man schickt das kommando doch nicht zum taster sondern zum auktor.

ich vermute die vielen einwände kommen alle daher das die ursprüngliche frage nicht genau genug ist bzw. es den verdacht gibt das sie nicht das eigentliche problem beschreibt.

[Nogga]

Beta-User hat es genau richtig getroffen:

Ich möchte nicht nur toggle, sondern eine komplette Ein-Tasten-Steuerung (damit die Frau auch während des Laufs stoppen kann...). Also ähnlich wie ein Garagentor. Und dieses set gibt es per HMCCU nicht für diesen Aktor. Über eine virtuelle Direkt-Verknüpfung mit der CCU gibt es diese Funktion aber wiederum. Deshalb: Status und Anzeige über den HM-Aktor, "Toggle"-Steuerung über virt. CCU Kanal Verknüpfung.

Die Variante dieses Device gleich zur Kontrolle herzunehmen hatte ich auch schon, aber ich will gleichzeitig über das devStateIcon auch den Zustand anzeigen (offen/zu). D.h. ich brauch dann auch wieder den State im anderen Device - also Aufwand in beide Richtungen.

Natürlich habe ich bei der "langen Variante" auch die Einzeloptionen Schieberegler, hoch/runter, stopp - aber denkt an den WAF!!11!

Ich probier heute Abend mal die erste Perl-Variante und berichte!

[Beta-User]

Hmm, in dem anderen Thread ging es um einen virtuellen Kanal, der als Taster genutzt werden kann und mit dem Aktor gepeert ist. Der Befehl muß also zu diesem virtuellen Device in der CCU, die dann "so tut", als wäre irgendwo eine Fernbedienungstaste gedrückt worden und damit dann den Aktor indirekt beeinflußt.

Aber ich gebe euch recht, dass diese Lösung sehr "von hinten durch die Brust..." ist und das ganze vermutlich viel einfacher direkt am Aktor in FHEMWEB gelöst werden könnte.

Die Variante dieses Device gleich zur Kontrolle herzunehmen hatte ich auch schon, aber ich will gleichzeitig über das devStateIcon auch den Zustand anzeigen (offen/zu).

Das sollte sich über ein multiline-stateFormat und die passenden Angaben in devStateIcon aber auch einfacher lösen lassen (zwei Icons mit unterschiedlichen Funktionen direkt auf den Aktor).

Dazu bräuchte man aber ein list und die gewünschten Symbole+Reaktionen...

[justme1968]

ich weiß nicht ob du mit einer einknopf bedienung bei einem rollladen wirklich glücklich wirst weil du aus einer mittelstellung nicht direkt sagen kannst ob rauf oder runter.

ich denke es ist im zweifel besser das fehlende reading per notify ins eigentliche device zu kopieren statt per devStateIcon ein anderes
device zu steuern.

unabhängig davon: du bist bei devStateIcon nicht auf ein icon pro device angewiesen. du kannst auch hier mehrere icons unter oder nebeneinander anzeigen und bedienen. auch auf dem handy. schau mal ins wiki.

[Nogga]

Ich bin noch am rumspielen, aber sicherheitshalber die lists der betroffenen zwei Devices:

Code Auswählen Erweitern


Internals:
   DEF        OEQ1970888
   FUUID      5deec9e0-f33f-bfba-ab4f-cdba82f0dd666be8
   IODev      HM_CCU3
   NAME       EG_Wohnzimmer_Rollo
   NR         204
   STATE      closed
   TYPE       HMCCUDEV
   ccuaddr    OEQ1970888
   ccudevstate active
   ccuif      BidCos-RF
   ccuname    EG_WOHNZIMMER_ROLLO
   ccutype    HM-LC-Bl1PBU-FM
   channels   2
   firmware   2.11
   statevals  devstate
   READINGS:
     2020-05-05 20:33:32   1.DIRECTION     none
     2020-05-04 22:39:19   1.INHIBIT       unlocked
     2020-05-05 20:33:32   1.LEVEL         closed
     2020-05-05 20:33:32   1.WORKING       no
     2020-05-04 22:39:19   activity        alive
     2020-05-05 20:33:32   control         0
     2020-05-05 20:33:32   hmstate         closed
     2020-05-05 20:33:32   state           closed
   hmccu:
     devspec    OEQ1970888
     dp:
       0.AES_KEY:
         OVAL       0
         VAL        0
       0.CONFIG_PENDING:
         OVAL       false
         VAL        false
       0.DEVICE_IN_BOOTLOADER:
         OVAL       false
         VAL        false
       0.DUTYCYCLE:
         OVAL       false
         VAL        false
       0.RSSI_DEVICE:
         OVAL       1
         VAL        1
       0.RSSI_PEER:
         OVAL       1
         VAL        1
       0.STICKY_UNREACH:
         OVAL       false
         VAL        false
       0.UNREACH:
         OSVAL      alive
         OVAL       false
         SVAL       alive
         VAL        false
       0.UPDATE_PENDING:
         OVAL       false
         VAL        false
       1.DIRECTION:
         OSVAL      down
         OVAL       2
         SVAL       none
         VAL        0
       1.INHIBIT:
         OSVAL      unlocked
         OVAL       false
         SVAL       unlocked
         VAL        false
       1.LEVEL:
         OSVAL      open
         OVAL       1.000000
         SVAL       closed
         VAL        0.000000
       1.WORKING:
         OSVAL      yes
         OVAL       1
         SVAL       no
         VAL        0
Attributes:
   IODev      HM_CCU3
   alias      Wohnzimmer Rollo
   ccureadingfilter (LEVEL|INHIBIT|DIRECTION|WORKING)
   ccuscaleval LEVEL:0:1:0:100
   controldatapoint 1.LEVEL
   eventMap   /datapoint 1.STOP true:stop/datapoint 1.LEVEL 0:down/datapoint 1.LEVEL 100:up/
   group      Wohnzimmer
   room       HMCCU,Steuerung
   statedatapoint 1.LEVEL
   stripnumber 1
   substexcl  control
   substitute LEVEL!#0-0:closed,#100-100:open;DIRECTION!0:none,1:up,2:down,3:undefined;WORKING!(0|false):no,(1|true):yes
   webCmd     control:up:stop:down
   widgetOverride control:slider,0,10,100

Code Auswählen Erweitern


Internals:
   CFGFN     
   CHANGED   
   DEF        BidCoS-RF:1
   FUUID      5eb07f9e-f33f-bfba-5160-1e21f7a62a792a96
   IODev      HM_CCU3
   NAME       CCU_VIRT_01
   NR         293
   STATE      ???
   TYPE       HMCCUCHN
   ccuaddr    BidCoS-RF:1
   ccudevstate active
   ccuif      BidCos-RF
   ccuname    HM-RCV-50 BidCoS-RF:1
   ccutype    HM-RCV-50
   channels   1
   statevals  devstate
   READINGS:
   hmccu:
     devspec    BidCoS-RF:1
     dp:
       1.PRESS_SHORT:
         OVAL       1
         VAL        1
Attributes:
   IODev      HM_CCU3
   room       Steuerung

[Beta-User]

[OT]
Hast du eine Idee, ob man die virtuellen Kanäle auch ähnlich nutzen könnte wie virtuelle Fensterkontakte oder Temperaturfühler? Oder läuft das alles über die HMId der CCU? (Dann geht es nicht bzw. nur mit RT's).

[Nogga]

@OT-Frage: ich benutze die virtuellen Kanäle das erste Mal - habe also keine Antwort.

Ich habe jetzt eine funktionierende und "hübsche" Lösung:

Code Auswählen Erweitern

attr EG_Wohnzimmer_Rollo devStateIcon { my $pic = 'fts_shutter_50';; if (ReadingsVal($name, "1.LEVEL", "") eq "open") { $pic = 'fts_shutter_10';; } elsif (ReadingsVal($name, "1.LEVEL", "") eq "closed") { $pic = 'fts_shutter_100';; } "<div><a href=\"/fhem?cmd.dummy=set CCU_VIRT_01 datapoint PRESS_SHORT 1&XHR=1\">".FW_makeImage($pic)."</div>" }

Ich versuche jetzt herauszufinden, wie ich das gleiche auf der CCU per HMScript hinbekomme, dann kann ich mir die Belegung der virtuellen Kanäle und das zusätzliche Device in FHEM sparen...

[frank]

wenn die gesuchte funktion (ein-tasten-bedienung) bereits von einem gepeerten taster (zb self01) des rollos existiert, sollte das cmd "set rollo pressS self01" existieren und funktionieren.

das simuliert einen entsprechenden short press des buttons.

[Nogga]

Das geht vermutlich über einen CUL bei direkter Einbindung, aber leider nicht bei HMCCU.

[frank]

ok,
da hatte ich wohl zu ungenau gelesen.