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?
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
$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:
{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
Waum nimmt man nicht das zweite Geraet zum steuern?
Alternativen zu der Perl-Loesung:
- per cmdalias toggle "implementieren"
- dummy mit setList und notify/notifies
und warum braucht man toggle? devStateIcon kann doch je nach aktuellem zustand beim klick ein anderes kommando ausführen.
Zitat von: justme1968 am 05 Mai 2020, 17:40:25
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...
Zitat von: rudolfkoenig am 05 Mai 2020, 16:31:16
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...
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.
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!
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.
Zitat von: Nogga am 05 Mai 2020, 17:52:31
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...
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.
Ich bin noch am rumspielen, aber sicherheitshalber die lists der betroffenen zwei Devices:
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
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
[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).
@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:
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...
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.
Das geht vermutlich über einen CUL bei direkter Einbindung, aber leider nicht bei HMCCU.
ok,
da hatte ich wohl zu ungenau gelesen. ;)