Hallo zusammen
Ich habe eine neue HM Display-Fernbedienung "HM-RC-Dis-H-x-EU" und möchte damit über fhem Geräte steuern. Das Pairing mit der Zentrale hat geklappt, ich verwende eine HMLAN (keinen CUL).
Nun habe ich noch gemischte Rolläden FS20 und HM, in einer Structure, sodass ich alle gleichzeitig schalten kann. Das soll nun auch mit der Fernbedienung gehen, also kein direktes Pairing mit einem anderen Gerät, sondern über die Zentrale. Dazu habe ich hier im Forum schon einiges gelesen, bin mir ob der vielen Varianten aber so unsicher, dass ich doch nochmal nachfragen möchte.
Insbesondere dieser Artikel scheint recht hilfreich:
https://wiki.fhem.de/wiki/HM-RC-12_Funkfernbedienung_12_Tasten
Aber sollte ich die Kanäle der FB jetzt mit meinem echten HMLAN pairen oder einen HMLAN Dummy erstellen? Und dann die Kanäle des Dummys pairen?
Ziel ist wie gesagt, dass ich (wohl über ein DOIF) dann die AlleRolläden Structure schalten kann.
Und im weiteren... kann ich das so einrichten, dass short -> off und long -> on schaltet (von mir aus auch umgekehrt ;) ? Oder wird das immer ein "toggle" sein?
Das Pairen mit einer HM-Steckdose hat übrigens geklappt, aber auch hier macht sowohl short als auch long ein Toggle, also beide dasselbe. Kann man das direkte Pairen auch short -> off und long -> on (oder umgekehrt) modifizieren?
Vielen Dank!
Marcus
Hallo Marcus,
Du verwechselst pairen und peeren (https://wiki.fhem.de/wiki/Pairing_und_Peering)
Ich befürchte der Artikel im Wiki, den Du gefunden hast, ist so alt (2013), da stimmt quasi nix mehr.
Ich schaue mal was ich finde und Dir erklären kann.
Das was Du machen willst ist aber kein Problem, wenn Du schon gepairt hast ist erst mal alles gut. Mach mal den Event Monitor auf https://wiki.fhem.de/wiki/Event_monitor
Du kannst im Filter Deine Fernbedienung eintragen falls Du zu viele Events hast.
Wenn Du eine Taste auf Deiner Fernbedienung drückst siehts Du was passiert. Du kannst Dir ein DOIF direkt auf den Event erstellen lassen.
Natürlich kannst Du nach belieben Short und Long auswerten. Toggle macht das Gerät, das liefert der Taster nicht.
Wenn Die Fernbedienung eine Quittung von der Zentrale bekommen soll (grünes Licht) kannst Du die Tasten mit einem virtuellen Kanal peeren.
Es gibt für Dich als Lösung eine Menge Möglichkeiten. Ich kann jetzt auf die Schnelle nicht alle beschreiben.
Gruß Otto
Wie Otto sagte viele moeglichkeiten.
Philosophisch:
Ich verfechte direktest peeren wann immer moeglich. Vor kurzen ist mein pi mit sdkartenfehler ausgestiegen. Ich hatte 2 wochen keine zeit. Alle zentralenfunktionen waren tot. Die frau konnte mit den fernbedienungen noch alles schalten.
Homeautomation erhoeht die komplexitaet und fehleranfaelligkeit, ein licht schalten zu koennen.
Alle funktion in der zentrale zu programmieren ist cool und uebersichtlicher, aber eben single point of fail.
Ich wuerde alle hm aktoren mit der fb peeren und direkt schalten. Unbedingt.
Alle fs20 ueber fhem. Logisch. Virtuellen kanal der vccu nutzen.
Templates für hm kanäle anlegen. Dann hat man Übersichtlichkeit
My 5 cents
Hi,
Vielen Dank für die schnellen Antworten!
Einzeln zu schaltende HM-Geräte werde ich auf jeden Fall weiter direkt peeren, das ergibt natürlich Sinn. Aber im Rolladen-Usecase würde ich eben schon gerne mit Gruppen arbeiten, um nicht immer alle einzeln drücken zu müssen. Die Messages der Fernbedienung sehe ich im fhem Log - dass ich direkt darauf ein DOIF legen kann, darauf hätte ich ja mal kommen können ;)
Allerdings verlangt die FB ja, dass jeder Kanal gepairt werden muss, sonst wird er gar nicht angezeigt. Und da kommen, wenn ich recht verstehe, die virtuellen Kanäle ins Spiel. Ich habe bisher noch gar keine VCCU. Wenn ich das recht verstehe werde ich mir damit ja essenzielle Änderungen einführen - Alle HM-Geräte müssen ja neu gepaired werden, sehe ich das richtig?
Das scheint dann für mich eine Grundsatz-Entscheidung zu werden, ob ich den Cut jetzt mache... Welche Chance habe ich denn, Pairing mit virtuellen Kanälen ohne vccu zu machen - falls überhaupt eine solche Option besteht?
[EDIT]: Sehe gerade auf der vccu Seite, dass ich nicht neu pairen muss, wenn ich die hmid des HMLAN übernehme. Muss mich da mal ein wenig einarbeiten. Aber die Frage nach einer vccu-losen Lösung bleibt bestehen :)
Danke!
Marcus
Hi,
kleines Update mit Folgeproblem: Das Einrichten der VCCU hat problemlos funktioniert; habe direkt 20 virtuals angelegt, um diese mit den Buttons der Fernbedienung zu peeren.
Dazu kleine Verständnisfrage: Peere ich jeweils mit Channel 0 oder mit dem Channel der Knopfnummer?
Also für Button 3 zum Beispiel
Set HM_9F3750_Btn_03 peerChan 0 VCCU_Btn3 single set
oder
Set HM_9F3750_Btn_03 peerChan 3 VCCU_Btn3 single set
?
Tatsächlich macht beides bei mir wohl keinen Unterschied - wobei in den internals chanNo mit 03 angegeben ist. Mein eigentliches Problem ist aber folgendes: Ich möchte ja Short/Longrelease mittels DOIF auswerten. Das seltsame: Das DOIF wird nur ungefähr jedes zehnte Mal generiert. Also nicht wenn ich zehn Sekunden drücke, sondern wenn ich zehnmal lange gedrückt hatte (a 2-5 Long-Events). Ist aber nur ein Durchschnittswert und kann auch mal 20 lange Drückvorgänge brauchen. Ich sehe immer die Longs hochzählen, aber am Ende eben kein LongRelease. Das Peering scheint ja ein übliches Problem dabei zu sein, aber er sendet keine Broadcasts, sondern immer an VCCU.
Beispiel-Events zweier erfolgloser Longs (also ohne LongRelease):
2017-10-13 20:31:56 CUL_HM HM_9F3750 battery: ok
2017-10-13 20:31:56 CUL_HM HM_9F3750 CMDs_done
2017-10-13 20:31:56 CUL_HM HM_9F3750 HM_9F3750_Btn_03 Long
2017-10-13 20:31:56 CUL_HM HM_9F3750_Btn_03 Long 1_116 (to VCCU)
2017-10-13 20:31:56 CUL_HM HM_9F3750_Btn_03 trigger: Long_116
2017-10-13 20:31:56 CUL_HM HM_9F3750_Btn_03 trigger_cnt: 116
2017-10-13 20:31:56 CUL_HM VCCU_Btn3 trigLast: HM_9F3750_Btn_03:long
2017-10-13 20:31:56 CUL_HM VCCU_Btn3 trig_HM_9F3750_Btn_03: Long_116
2017-10-13 20:31:56 CUL_HM HM_9F3750 battery: ok
2017-10-13 20:31:56 CUL_HM HM_9F3750 CMDs_done
2017-10-13 20:31:56 CUL_HM HM_9F3750 HM_9F3750_Btn_03 Long
2017-10-13 20:31:56 CUL_HM HM_9F3750_Btn_03 Long 2_116 (to VCCU)
2017-10-13 20:31:56 CUL_HM HM_9F3750_Btn_03 trigger: Long_116
2017-10-13 20:31:56 CUL_HM HM_9F3750_Btn_03 trigger_cnt: 116
2017-10-13 20:31:56 CUL_HM VCCU_Btn3 trigLast: HM_9F3750_Btn_03:long
2017-10-13 20:31:56 CUL_HM VCCU_Btn3 trig_HM_9F3750_Btn_03: Long_116
2017-10-13 20:31:59 CUL_HM HM_9F3750 battery: ok
2017-10-13 20:31:59 CUL_HM HM_9F3750 CMDs_done
2017-10-13 20:31:59 CUL_HM HM_9F3750 HM_9F3750_Btn_03 Long
2017-10-13 20:31:59 CUL_HM HM_9F3750_Btn_03 Long 1_117 (to VCCU)
2017-10-13 20:31:59 CUL_HM HM_9F3750_Btn_03 trigger: Long_117
2017-10-13 20:31:59 CUL_HM HM_9F3750_Btn_03 trigger_cnt: 117
2017-10-13 20:32:00 CUL_HM VCCU_Btn3 trigLast: HM_9F3750_Btn_03:long
2017-10-13 20:32:00 CUL_HM VCCU_Btn3 trig_HM_9F3750_Btn_03: Long_117
2017-10-13 20:32:00 CUL_HM HM_9F3750 battery: ok
2017-10-13 20:32:00 CUL_HM HM_9F3750 CMDs_done
2017-10-13 20:32:00 CUL_HM HM_9F3750 HM_9F3750_Btn_03 Long
2017-10-13 20:32:00 CUL_HM HM_9F3750_Btn_03 Long 2_117 (to VCCU)
2017-10-13 20:32:00 CUL_HM HM_9F3750_Btn_03 trigger: Long_117
2017-10-13 20:32:00 CUL_HM HM_9F3750_Btn_03 trigger_cnt: 117
2017-10-13 20:32:00 CUL_HM VCCU_Btn3 trigLast: HM_9F3750_Btn_03:long
2017-10-13 20:32:00 CUL_HM VCCU_Btn3 trig_HM_9F3750_Btn_03: Long_117
2017-10-13 20:32:00 CUL_HM HM_9F3750 battery: ok
2017-10-13 20:32:00 CUL_HM HM_9F3750 CMDs_done
2017-10-13 20:32:00 CUL_HM HM_9F3750 HM_9F3750_Btn_03 Long
2017-10-13 20:32:00 CUL_HM HM_9F3750_Btn_03 Long 3_117 (to VCCU)
2017-10-13 20:32:00 CUL_HM HM_9F3750_Btn_03 trigger: Long_117
2017-10-13 20:32:00 CUL_HM HM_9F3750_Btn_03 trigger_cnt: 117
2017-10-13 20:32:00 CUL_HM VCCU_Btn3 trigLast: HM_9F3750_Btn_03:long
2017-10-13 20:32:00 CUL_HM VCCU_Btn3 trig_HM_9F3750_Btn_03: Long_117
2017-10-13 20:32:04 HMLAN HMLAN1 loadLvl: low
Und dann nach diesmal nur 3 Versuchen mal eines mit Release:
2017-10-13 20:33:09 CUL_HM HM_9F3750 HM_9F3750_Btn_03 Long
2017-10-13 20:33:09 CUL_HM HM_9F3750_Btn_03 Long 1_120 (to VCCU)
2017-10-13 20:33:09 CUL_HM HM_9F3750_Btn_03 trigger: Long_120
2017-10-13 20:33:09 CUL_HM HM_9F3750_Btn_03 trigger_cnt: 120
2017-10-13 20:33:09 CUL_HM VCCU_Btn3 trigLast: HM_9F3750_Btn_03:long
2017-10-13 20:33:09 CUL_HM VCCU_Btn3 trig_HM_9F3750_Btn_03: Long_120
2017-10-13 20:33:09 CUL_HM HM_9F3750 battery: ok
2017-10-13 20:33:09 CUL_HM HM_9F3750 CMDs_done
2017-10-13 20:33:09 CUL_HM HM_9F3750 HM_9F3750_Btn_03 Long
2017-10-13 20:33:09 CUL_HM HM_9F3750_Btn_03 Long 2_120 (to VCCU)
2017-10-13 20:33:09 CUL_HM HM_9F3750_Btn_03 trigger: Long_120
2017-10-13 20:33:09 CUL_HM HM_9F3750_Btn_03 trigger_cnt: 120
2017-10-13 20:33:09 CUL_HM VCCU_Btn3 trigLast: HM_9F3750_Btn_03:long
2017-10-13 20:33:09 CUL_HM VCCU_Btn3 trig_HM_9F3750_Btn_03: Long_120
2017-10-13 20:33:09 CUL_HM HM_9F3750 battery: ok
2017-10-13 20:33:09 CUL_HM HM_9F3750 CMDs_done
2017-10-13 20:33:09 CUL_HM HM_9F3750 HM_9F3750_Btn_03 LongRelease
2017-10-13 20:33:09 structure AlleRollos undefined
2017-10-13 20:33:09 structure Rollos_OG undefined
2017-10-13 20:33:09 structure Rollos_OG_NoSchlaf undefined
2017-10-13 20:33:09 CUL_HM Rol_Buero set_on
2017-10-13 20:33:09 DOIF di_FB20_Btn3 cmd_nr: 2
2017-10-13 20:33:09 DOIF di_FB20_Btn3 cmd: 2
2017-10-13 20:33:09 DOIF di_FB20_Btn3 cmd_event: HM_9F3750_Btn_03
2017-10-13 20:33:09 DOIF di_FB20_Btn3 cmd_2
2017-10-13 20:33:09 CUL_HM HM_9F3750_Btn_03 LongRelease 2_120 (to VCCU)
2017-10-13 20:33:09 CUL_HM HM_9F3750_Btn_03 trigger: Long_120
2017-10-13 20:33:09 CUL_HM HM_9F3750_Btn_03 trigger_cnt: 120
2017-10-13 20:33:09 CUL_HM VCCU_Btn3 trigLast: HM_9F3750_Btn_03:long
2017-10-13 20:33:09 CUL_HM VCCU_Btn3 trig_HM_9F3750_Btn_03: Long_120
Ich kann da echt kein Muster erkennen, warum das Release manchmal nicht erzeugt wird. Irgendjemand eine Idee?
Dank und Gruß
Marcus
Hallo Marcus,
das wäre richtig:
Set HM_9F3750_Btn_03 peerChan 0 VCCU_Btn3 single set
oder so
Set HM_9F3750 peerChan 3 VCCU_Btn3 single set
Quelle -> https://fhem.de/commandref_DE.html#CUL_HMpeerChan
Zum anderen Problem kann ich nix sagen. Nur einen Hinweis geben wo es auch Probleme mit longrelease gab.
https://forum.fhem.de/index.php/topic,77393.msg694874.html#msg694874
Gruß Otto
Hallo,
ich wollte nicht direkt ein neues Thema zur HomeMatic Displayfernbedienung aufmachen, drum hänge ich mich mal hier an.
Mit einer kleinen "Anleitung" aber auch noch mit einer Frage:
Da ich keine "einfache" Anleitung gefunden habe - mit welchen Schritten kann ich eine HomeMatic Displayfernbedienung in FHEM einrichten und sehe dann auf der FB auch irgendwas - beschreibe ich auch erstmal kurz meine Vorgehensweise, falls die Infos noch ein Einsteiger sucht..
Und auch die Info, wie man's eher nicht macht..
Fehlversuch:
Mein erster Gedanke war, die FB nicht mit FHEM zu koppeln, schließlich wollte ich div. Geräte (z.b. Rollladen) OHNE die Zentrale direkt steuern. Also hab ich mit einem Aktor versucht, diesen an die FB anzulernen. Dazu hab ich den Aktor auf Werkseinstellung rückgesetzt, dann die FB und den Aktor in Anlernmodus gesetzt - fertig. Hat zwar interessanterweise einige Anläufe gebraucht, bis ein Pairing zustande kam, dann hatte ich aber z.b. auf Kanal 1 der FB den Rollladenaktor und konnte den auf/ab/stop schalten. (im toggle-Modus)
Mit dem kleinen Nachteil: Der Rollladenaktor ist damit natürlich nicht mehr an die Zentrale (FHEM) gepaired und kann von dort aus nicht mehr gesteuert werden... also kann man die Variante vergessen... Den Aktor musste ich natürlich wieder in den Werkszustand versetzen und erneut an die FHEM-Zentrale anbinden.
Das hat leider auch nicht problemlos geklappt.
Den Aktor in den Anlern-Modus und die FHEM-Zentrale ebenfalls haben hier keinen Erfolg gebracht, die beiden haben nicht gepaired!
Auch das löschen des Devices und der Versuch ein neues Autocreate dieses Aktors zu machen hat nicht funktioniert!
Da war ich erstmal ratlos - keine Chance, der Aktor wurde von FHEM weder erkannt noch wurde irgendwas gepaired noch hat er irgendwie reagiert.
Dann bin ich durch Zufall draufgekommen, dass in dem IO-Device (HMUART) der Aktor immer noch gelistet war, aber das zugeordnete Device nicht den Namen der ursprünglichen Konfig mehr hatte, sondern "irgendeine" Nummer. (Das war vermutlich der Grund, warum das autocreate kein neues Gerät erkannt hat - ich hab aber keine Ahnung, wie man aus dem HMUART ein einmal erkanntes Gerät wieder löschen kann, sodass es dann vom autocreate neu erkannt werden würde..)
Also hab ich mit der ursprünglichen Konfig den Devicenamen auf diese Nummer geändert und siehe da plötzlich sprachen die nun doch wieder miteinander...
Nach div. anderen Ideen und Ansätzen bzgl. Fernbedienung hab ich dann gewagt, wovor ich mich erst scheute..
Erfolg:
Anlernen der FB an FHEM: FHEM hatte autocreate aktiv. Also hab ich den Versuch gewagt, an der FB den Kanal "Zentrale" zu wählen und diesen anzulernen.
Sehr schnell war in FHEM dann die Fernbedienung als Device und die 20 Buttons der Fernbedienung ersichtlich, hat also problemlos geklappt.
An der FB selbst jedoch zu sehen "Kein Gerät angelernt".
Nach div. Ansätzen, suchen und Ideen - ohne aber konkret zu wissen, wie hier gezielt vorzugehen ist, was der nächste Schritt wäre - bin ich auf div. Forenthemen mit der FB gestoßen und hab dann also versucht, einen Kanal der FB mit einem Aktor zu peeren.
Mit:
set HM_FB_BUTTON_01 peerChan 0 DEVICENAME single set
hat Fhem den Befehl mal "gefressen" ich wusste aber noch nicht ganz, wie ich das Ding nun auf die FB bekomme, dort stand (natürlich) immer noch "Kein Gerät angelernt".
Nach dem Trial-and-Error Prinzip hab ich dann einfach nochmal versucht an der Fernbedienung die Zentrale anzulernen, also FB nochmal im Kanal "Zentrale" auf anlernen.. nach längerem geblinke war das dann abgeschlossen und siehe da, plötzlich was an der FB zu sehen "Position 01".. bei Bestätigung mit dem Button schaltete der Aktor auch und in der Anzeige war der entsprechende Wert (0..100) + Pfeil nach oben bzw. nach unten zu sehen.
Nun noch den Kanal direkt an der FB mittels umständlicher Bedienung (lt. Anleitung) umbenennen und schon war 1 Kanal drauf.. fein!
Nun hab ich also gleich noch weitere Devices mit den div. FB-Buttons gepeert (mehrere auf einmal) und an der FB erneut angelernt... nach gleichem Prinzip, hat soweit auch funktioniert.
Annahme - das hab ich noch gemacht, konnte ich aber noch nicht testen, da ich erst 1 Rollladenaktor eingebaut habe, die anderen sind dzt. noch offline und warten auf den Umbau..
Da ich mehrere Rollläden habe, wollte ich natürlich mit 1 FB-Button auch alle gleichzeitig rauf bzw. runter schalten, daher habe ich mit
set HM_FB_BUTTON_XX peerChan 0 rollladen1 single set
set HM_FB_BUTTON_XX peerChan 1 rollladen2 single set
set HM_FB_BUTTON_XX peerChan 2 rollladen3 single set
set HM_FB_BUTTON_XX peerChan 3 rollladen4 single set
etc.
eingerichtet. Wie ich es verstanden habe müsste das gehen, wobei - während ich das so eingerichtet habe waren die betroffenen Aktoren OFFLINE, daher wird das vermutlich in meinem Fall nicht funktionieren, ich hab irgendwo gelesen, dass für's peering natürlich die betroffenen Geräte ONLINE sein müssen.. also werd ich wohl nochmal ein ... unset machen müssen und dann neu setzen..
Auch eine Info, wie man den Text nicht direkt an der FB umständlich ändern muss, sondern dies auch über FHEM machen kann :
Zitat aus: https://wiki.fhem.de/wiki/HM-Dis-WM55_Funk_Statusanzeige (https://wiki.fhem.de/wiki/HM-Dis-WM55_Funk_Statusanzeige)
"Um einen Kanal mit Text zu befüllen dient der text Befehl auf einen Kanal. Es werden beide Texte in einen Kanal gleichzeitig geschrieben. Will ich einen Text tauschen muss ich den anderen mit neu setzten. Für ein Leerzeichen \_ einsetzten
set HM-Dis-WM55_Dis_01 text Fenster\_auf Fenster\_zu
[/i]"
Zitat Ende.
Konnte ich noch nicht versuchen, werd ich aber noch.
Was ich auch versucht habe, ist einen meiner virtuellen Schalter, die ich in FHEM als "dummy" definiert habe mit der FB zu verbinden, das hat allerdings nicht funktioniert.
Da steh ich nun an und hab keine rechte Idee wie das zu lösen wäre.
Hab schon was von VCCU gelesen, da blick ich aber auch nicht so ganz durch..
Soweit ich es verstehe: Ich könnte eine VCCU anlegen, die die gleiche hmid verwendet wie die, die ich bereits habe, hierfür das bestehende IODev. (in meinem Fall HMUART) binden und dort dann virtuelle kanäle anlegen/einrichten, dann müsste ich auch keine Geräte neu pairen...
also z,b.
set MYVCCU CUL_HM 1234 # meine vorhandene hmid
attr MYVCCU IODev HMUART # also der VCCU mitteilen, welche I/O-Dev. sie nutzen soll.
set MYVCCU virtual 5
lieg ich das richtig oder ist da schon was falsch?
Und vor allem: Und dann weiter ?? wie kann ich dann einen Dummy-Schalter mit einem Kanal der VCCU verbinden und diesen Kanal der VCCU dann mit der FB?
Oder geht das ohnehin ganz anders??
Vielen Dank vorab!
Hi,
zur VCCU https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU
Halt Dich bitte an diese Anleitung bei der Einrichtung.
Aber der Hauptzweck der VCCU sind nicht virtuelle Kanäle, das ist eher Beiwerk! Die kannst Du auch mit separaten virtuellen Aktoren definieren.
Die werden genauso behandelt wie echte Aktoren, d.h. die kannst Du auch mit Hardware Geräten peeren.
Gruß Otto
ok, danke, dann versuch ich das nochmal, vermutlich hab ich nur beim peeren eines virtuellen Aktors mit der FB was falsch gemacht..
Hm ... da fehlt doch noch viel grundsätzliches Verständnis ...
Für die Zukunft: Homematics Fachbegriff "anlernen" bezieht sich sowohl auf die Bindung an eine Zentrale (in FHEM nennen wir das pairing) als auch auf die Verbindung zu einem anderen Gerät, die "Direktverknüpfung" - in FHEM "peering". Bittebitte nicht verwechseln, stiftet sonst gern Verwirrung.
Ein Peering (FB <-> Aktor) besteht unabhängig vom Status der Bindung zur Zentrale. Man kann also nicht zentralengebundene Geräte miteinander verknüpfen und diese Verknüpfung besteht weiter, wenn man beide an einer Zentrale anlernt. Sind sie jedoch an einer Zentrale gebunden, lassen sie sich nur noch über diese verknüpfen. Eine solche Verknüpfung bleibt aber auch bestehen, wenn man sie wieder von der Zentrale "ablernt" (FHEM: unpair), wenn man sie nicht gleichzeitig zurücksetzt (in der CCU möglich).
Dann: Die 0 in peerChan ist ein Relikt aus früheren Zeiten. Andere Werte als 0 haben dort nur Sinn im Zusammenhang mit einem peering über das Gerät direkt, nicht über einen Kanal (Button).
set HM_FB_BUTTON_XX peerChan 1 rollladen2 single set
macht also prinzipiell wenig Sinn, zumal die reale Bedeutung von 1+ sich je nach "single" oder "dual" unterscheidet. Es mag hier vll. sogar funktionieren.
Konkret richtig wäre also bspw.
set HM_FB_BUTTON_01 peerChan 0 rollladen1 single set
set HM_FB_BUTTON_02 peerChan 0 rollladen2 single set
set HM_FB_BUTTON_03 peerChan 0 rollladen3 single set
set HM_FB_BUTTON_04 peerChan 0 rollladen4 single set
Wegen der Einknopfbedienung ist hier übrigens nur "single" sinnvoll.
Drittens: Jede Übernahme einer Information an die Fernbedienung musst Du von dort anstoßen. Dafür ist der Knopf im Batteriefach. Nach jedem peering also sicherheitshalber einmal den Knopf drücken.
Und blind peeren (ohne gleichzeitig den Aktor zu programmieren) macht wirklich nur in Ausnahmefällen Sinn.
Viertens: Virtuelle Buttons in der VCCU sind hier übrigens oft nur aus einem Grund sinnvoll: Sie ergeben einen ACK-Partner für eine Verknüpfung, d.h. die FB zeigt über die grüne Einfärbung an, dass ihr Befehl in FHEM angekommen ist. Dafür reicht es, alle Kanäle mit demselben virtuellen Button zu peeren. Eine Ereignisauswertung selbst erfolgt in FHEM besser über die Events, die die FB selbst erzeugt. Dieses peering ist eigentlich auch nur nötig, wenn als Partner für diesen Kanal nicht bereits ein "richtiges" HM-Gerät gekoppelt ist. Schaden tut es nicht, erzeugt aber nur eine zusätzliche Funklast, weil sowohl Gerät als auch FHEM den Empfang des Befehls quittieren würden und die FB dann auch beide erwartet. Bei der Fehlersuche verwirrt dies aber eher, weil man den Empfang der FB-Signale in FHEM über den Event-Monitor viel einfacher kontrollieren kann.
Fünftens: Texte zu setzen funktioniert wie von Dir angedeutet sehr prima, hier aber direkt auf den Button selbst (und nicht wie beim WM55 auf einen Textspeicher).
set HM_FB_BUTTON_02 text1 text2
Die Sonderzeichen funktionieren auch bei der Displayfernbedienung super (in Auszügen):
"{" = "ä" "[" = "Ä"
"|" = "ö" "#" = "Ö"
"}" = "ü" "\$" = "Ü"
"'" = "=" "_" = "ß" "]" = "&"
">" = V auf dem Kopf (Pfeil nach oben)
"@" = (Pfeil nach unten, besser als V)
"\_" = Leerzeichen im Text
Quelle: https://forum.fhem.de/index.php/topic,29128.msg303847.html#msg303847https://forum.fhem.de/index.php/topic,29128.msg303847.html#msg303847
Ich nutze das Ding selbst sehr gern, in einer Mischumgebung aus Homematic-Geräten und anderen (über DOIFs, gezielte ein/aus über kurze/lange Tastendrücke).
Hi, vorab erstmal - VIELEN DANK für die detaillierte Info.
Ad1 -
Pairing/Peering habe ich soweit verstanden, vielleicht hatte ich mich da falsch ausgedrückt.
Ad2 -
soweit - also peering über Zentrale zw. Aktor und FB einzurichten ist mir das auch verständlich, dass dies 1:1 geht, also eben
set BUTTON01 peerChan 0 rollo01 single set
set BUTTON02 peerChan 0 rollo02 single set
...
Was ich aber meinte und erreichen wollte war, über einen FB-Button mehrere Rollos gleichzeitig anzusprechen. Genau daher eben, auf einen FB-Button die Kanäle des einen Buttons mit unterschiedlichen Aktoren peeren. Also:
set BUTTON20 peerChan 1 rollo01 single set
set BUTTON20 peerChan 2 rollo02 single set
..
Das hab ich gestern gecoded und das funktioniert soweit auch.
ABER - Problem dabei - das ist mir gestern dann bewußt geworden - ist, dass alle Rollos "getoggelt" würden. Wenn z.b. bei 5 Rollos vorher 2 runtergefahren waren und vorher 3 rauf, dann würde eine solche Aktion das nur umkehren. Die 2 würden dann rauffahren und die 3 anderen würden runterfahren. Was ich aber will ist alle Rollos in die gleiche Richtung zu steuern.
Das geht also nur mit einem virtuellen Button, den ich an der Zentrale ja ohnehin schon eingerichtet hatte, der dann bei notify Rollo_alle:off ein
set rollo1 set_0, set rollo2 set_0, set rollo2 set_0 ..
sendet .. oder eben set_100.
Ad 3 -
Ich hab gestern alle Rollladenaktoren konfiguriert (gestern sind erst weitere Stück bei mir eingetroffen), gepaired mit Zentrale, dort Basissetting (driveUp, driveDown etc.) gemacht und dann über Zentrale mit FB gepeert, dabei bin ich genau so vorgegangen, dass ich jeden Aktor aktiv und online hatte, dann das peering mit FB mittels set ... gemacht, danach noch den Text gesetzt und DANN an der FB anlernen Zentrale durchgeführt. Danach Test des Aktors über Fhem-Web und über FB. Hat soweit alles geklappt.
Eine merkwürdige Sache ist mir aufgefallen: An der FB hieß es nach Druck auf den Config-Button erst "Zentrale/Anlernen", nun heißt es plötzlich "Zentrale/Übernehmen" .. führt aber offensichtlich dennoch das anlernen - bzw. eben das peeren der FB mit den jeweiligen Aktoren aus, denn das hat dann geklappt.
Das blinde Peeren, das ich vorher schon mal gemacht hatte hat übrigens nicht geklappt, der Aktor, der offline war, den ich aber ansonsten mit gleicher Vorgehensweise peeren wollte hat über die FB nicht reagiert. Hier hab ich also ein unset gemacht und nochmal neu gepeert, dann ging das auch.
Ad 5 -
super, vielen Dank für die Info, hab ums verrecken gestern keine Sonderzeichen geschafft und wenn der Text zu lang wurde hat er plötzlich etwas anderes geschrieben (z.b. rallo statt rollo ...)
Ich nehme an text1 = zeile1, text2=zeile2?
und nun noch
Ad 4 - und einige Fragen und welche Probleme ich gestern damit hatte:
Ich hab bisher noch keine VCCU eingerichtet, da lt. Otto ein virtueller Button ja gleich zu peeren ist wie ein normaler Aktor.
Ich hab z.B. folgenden Button:
define ROLLO_ALLE_AUF dummy
setuuid ROLLO_ALLE_AUF 5d63e799-f33f-fcbf-72a1-5eef0edb9d79c894
attr ROLLO_ALLE_AUF cmdIcon on:Restart off:Shutdown statusRequest:unknown
attr ROLLO_ALLE_AUF devStateIcon on:10px-kreis-gruen off:10px-kreis-rot
attr ROLLO_ALLE_AUF group ROLLLAEDEN_KOMFORT
attr ROLLO_ALLE_AUF icon fts_shutter_40
attr ROLLO_ALLE_AUF room ROLLLAEDEN
attr ROLLO_ALLE_AUF webCmd on:off:statusRequest
Diesen Button wollte ich mittels
set BUTTON7 peerChan 0 ROLLO_ALLE_AUF single set
mit der FB peeren, das ging aber nicht, FHEMWEB brachte mir nur die Fehlermeldung: "please enter peer"
Was mach ich da noch falsch??
UND:
Ich habe einen HM-LC-SW2-FM, also 2-Kanal Schaltaktor, der mit FHEM gepaired ist, hier kann ich beide Kanäle über FHEMWEB schalten.
In der fhem.cfg ist der Aktor selbst sowie die beiden Schalter des Aktors als jeweiliges Device definiert.
Ich habe dann also den Schalter 1 mit der FB - z.b. Button 10 - über die Zentrale gepeert und auch den Schalter 2 mit der FB - Button 11 - über die Zentrale gepeert.
Ergebnis: Schalter 1 lässt sich über Button 10 schalten. Schalter 2 scheint an FB aber nicht mal auf...???
Hab ich was falsch gemacht? Einen Fehler hab ich nicht bekommen, ins log sehen ging sich dann zeitlich nicht mehr aus...
Moin,
ein Dummy ist kein virtueller CUL_HM Aktor!
Da hast Du was völlig falsch verstanden.
https://wiki.fhem.de/wiki/HomeMatic#Virtuelle_Entities
BTW: Hast Du hmInfo definiert? Hilft ungemein die HM Landschaft zu prüfen und Fehler zu finden.
Gruß Otto
Oh... DANKE!! Ich sehe ich muss noch viel darüber lernen.. d.h. ich muss nun mal alle meine Dummies (soweit über FB erforderlich) umbauen...
hmInfo sagt mir bisher auch noch nix, werd mich da auch mal einlesen..
Danke für eure Geduld!
Hab mich gestern noch länger damit beschäftigt..
Text setzen an FB ging ganz gut für die eingerichteten Kanäle, geht aber tatsächlich mit dem Befehl:
set <FB_BUTTON_XY> text <Textzeile1> <Textzeile2>
HMinfo hat auch ein wenig weitergeholfen, hier bin ich zumindest auf ein Problem draufgekommen.
Offensichtlich werden div. peerings nicht immer aus der fhem.cfg gelöscht. die fhem.cfg,
attr <device> peerIDs
scheint die grundlage für HMinfo zu sein.
Dazu eine Grundsatzfrage:
wenn ich in der fhem.cfg je Device ein
attr <device> peerIDs 00000000, <hmid_des_anderen_device>
setze, ist das dann nur in FHEM bekannt oder wird das auch im entsprechenden device selbst eingetragen?
Denn es scheint mir, als würde der Befehl
set <device> peerChan 0 <peer_device> single set actor
bzw. single unset ..
nicht immer korrekt ausgeführt.
Hintergrund:
Ich hatte einen HM-Zwischenstecker, den ich für eine Funktion TV vorgesehen hatte.
Dann hab ich aber umdisponiert und stattdessen einen HM-2fach Schalter dafür genutzt. Die Namen der Devices wollte ich aber beibehalten.
Also habe ich die HM-id des HM-Zwischensteckers in irgendwas anderes umbenannt und der HM-2fach Schalter, schalter_01 erhielt den alten Namen.
Wenn ich nun den schalter_01 mit der Fernbedienung peere, dann FUNKTIONIERT das schalten zwar, in dem attr <schalter_01> peerIDs scheint aber die HM-id des alten HM-Zwischensteckers auf..?
Das bringt in hminfo dann auch einen fehler.
MAnuell in der fhem.cfg korrigiert verschwindet der fehler und es funktioniert weiterhin.
Für mich stellt sich daraus die Frage:
kann ich ein peering auch "manuell" einzeln bei den div. beteiligten Devices eintragen, also z.b.: Fernbedienung, Button XY soll mit Aktor AB gepeert werden:
- manuelles setzen einer peering ID direkt in Fernbedienung, Button XY (hmid des Aktors AB)
- manuelles setzen einer peering ID direkt im Aktor AB (hmid der Fernbedienung, Button XY)
- Eintragen der peerids in den attr der beiden devices (Fernbedienung, Button XY + Aktor AB) in der fhem.cfg
vom befehl set ..peerChan .. sehe ich nämlich leider keinerlei Ergebnis oder Rückmeldung..
Und ich hatte gestern trotz vieler Versuche keinen Erfolg dabei, von eben dem 2-fach Schaltaktor den 2. Kanal mit einem Button der FB zu peeren.
Was immer ich auch versuche, der 2.kanal/Schalter des Schaltaktors erscheint nie auf der Fernbedienung, nur den 1. kann ich peeren, der funktioniert auch wie gewünscht.
Der Schaltaktor hat eine HM-ID z.b. 123456, der 1. Schalter eine separate ID: 12345601, der 2.Schalter ebenfalls: 12345602 (01/02 sind dabei vermutlich die Kanäle der Haupt HM-id, ist ja auch bei der FB so..)
Zu den virtuellen Schaltern/Entities bin ich gestern leider nicht mehr gekommen..
Moin,
3 Tipps zu Beginn
1. Man sollte die fhem.cfg nicht per Hand editieren
2. Man sollte die fhem.cfg nicht per Hand editieren
3. Man sollte die fhem.cfg nicht per Hand editieren
Das peering wird im Gerät eingetragen, Sinn und Zweck ist ja, dass die Geräte mit einander reden ohne das die Zentrale (FHEM) irgendwas tun muss. Also die Hardware funktioniert auch wenn FHEM ausfällt.
Also lass bitte die Experimente mit den attributen.
Das peering erfolgt an Hand der ID, die Namen im FHEM werden nur dort aufgelöst.
Wenn Du gepeerte Geräte austauscht, muss Du das peering löschen und neu machen.
Gruß Otto
Tipp 1-3 hab ich natürlich schon mehrmals gesehen, früher mal, als ich mein fhem das erste mal aufsetzte war das noch nicht so, da war standardmäßig die fhem.cfg über web auch editierbar...
Ich hab ja stets im ersten ansatz die peerings über web gesetzt, gelöscht etc.. aber wie ich in der fhem.cfg sehe greift das nicht immer und überall. das löschen der peerings hab ich natürlich vorm umbenennen gemacht.
Die Frage ist also im Grunde, ob ich direkt im jeweiligen Device die HMID des anderen device in einem Register eintragen/setzen oder auch löschen kann.
set <devicename1> peerChan 0 <devicename2> single set actor
ersetzt ja offensichtlich den devicenamen durch die hmid und setzt das entsprechende peering-register in BEIDEN devices. in der fhem.cfg trägt das aber scheinbar nichts, ein daher ergibt sich für mich die Frage - wozu wird das attr <device> peerIDs xxxx in fhem.cfg dann überhaupt eingetragen und von wem und wann?
Fragen über Fragen, aber ich würd's gern ordentlich verstehen..
Also folgendes:
Die "Wahrheit" (wie Otto schon geschrieben hat) steht in den Registern der ECHTEN GERÄTE!
Fhem liest dann mit getConfig zurück und schreibt das dann in die fhem.cfg
Wenn du also änderst per Peer-Befehl und kein getConfig machst oder nicht wartest bis dies fertig ist, stimmt nat tatsächlicher Zustand und fhem.cfg nicht.
Hminfo stützt sich nat. auf die fhem.cfg sonst müssten ja jedesmal alle Geräte abgefragt werden: dauert und produziert Funklast...
Hmid etc. einfach umeditieren macht mehr kaputt als es hilft!
Weil wenn du den anderen Aktor mit ja noch im Register eingetragenen Peering wieder nutzt wird er auch schalten...
...und er wird sich ja auch unter SEINEM Namen wieder bei fhem melden: Durcheinander!
Gruß, Joachim
Zitatdas löschen der peerings hab ich natürlich vorm umbenennen gemacht.
Löschen der peerings erfolgt aber nicht durch löschen in der config!
Das erfolgt durch
peerchan ... unset
peerBulk <peerch1,peerch2,...> unset
Und diese erfordert immer eine Datenübertragung!!! Es schreibt im Gerät! Bei den meisten Batteriegeräten muss man die Datenübertragung anstossen (configtaster)! Steht aber alles auch im Wiki.
Deswegen mein 4. Tipp - Hör auf die fhem.cfg zu lesen, es steht alles in der Weboberfläche. Lies lieber in der Doku, im Wiki oder kauf Dir ein gutes Buch ;)
Wozu es in den attributen steht weiß ich auch nicht. Das ist wahrscheinlich ein relikt aus den Anfängen von FHEM. Es steht ja in den Internals als (Teil)Abbild der Register.
Gruß Otto
Das Löschen der peerings hab ich natürlich über den Befehl ..peerChan...unset (und nicht die fhem.cfg) gemacht.
Bei den stromnetz-versorgten Aktoren hab ich nach peerings keine explizite Datenübertragung angestoßen.. der Hinweis, dass dies auch etwas dauern kann könnte hier noch ein Thema sein..
Batteriebetriebene Devices peere ich derzeit - außer der Fernbedienung - keine, und an der FB habe ich nach jedem Peering direkt die Übertragung aktiv angestoßen und vollständig abgewartet. (Hat ja zumeist auch funktioniert aber nicht immer).
Ich werd wohl nochmal in Ruhe die nicht funktionierenden Themen angehen und vor allem die get .. Readings der Geräte holen/ansehen..
entscheidend ist aus meiner Sicht:
configCheck von hminfo meldet keine Fehler.
Das peering kann man dort auch separat mit peerXref testen.
Wenn Peers in den Internals nicht mit Namen gezeigt (aufgelöst) werden sondern die achstellige ID drin steht, fehlt FHEM zwar der Peer - es muss aber trotzdem nicht falsch sein. Wenn man es als falsch ermittelt kann man die nur mit peerBulk löschen.
Man kann sich die peerList übrigens auch leicht anzeigen lassen:
list TYPE=CUL_HM i:peerList
Gruß Otto
Zitat von: zenzi123 am 12 September 2019, 07:16:21
Hi, vorab erstmal - VIELEN DANK für die detaillierte Info.
set BUTTON20 peerChan 1 rollo01 single set
set BUTTON20 peerChan 2 rollo02 single set
..
Das hab ich gestern gecoded und das funktioniert soweit auch.
Dann wird hier die Kanalnummer offenbar ignoriert - Sinn macht sie ja nur aus dem Gerät.
set BUTTON20 peerChan 0 rollo01 single set
set BUTTON20 peerChan 0 rollo02 single set
hätte den gleichen Effekt gehabt.
Zitat
ABER - Problem dabei - das ist mir gestern dann bewußt geworden - ist, dass alle Rollos "getoggelt" würden. Wenn z.b. bei 5 Rollos vorher 2 runtergefahren waren und vorher 3 rauf, dann würde eine solche Aktion das nur umkehren. Die 2 würden dann rauffahren und die 3 anderen würden runterfahren. Was ich aber will ist alle Rollos in die gleiche Richtung zu steuern.
Auch dafür gibt es Abhilfe. Ich bin gerade in Eile (wie die letzten Tage auch), aber es ist möglich Aktoren so umzuprogrammieren, dass sie je nach Zustand nur auf jeden gerade oder jeden ungeraden toggle (die Events werden ja hochgezählt) reagieren. So könnte im Toggle bspw. nur jeder ungerade hoch- und jeder gerade herunterfahren. Bei unterschiedlichen letzten Kommandos reagieren die so programmierten Events auf den Toggle ggf. nicht (z.B. wenn sie hochfahren sollen und schon oben sind). Wie auch immer: Es reicht zu sehen dass EIN Aktor in die richtige Richtung fährt um zu wissen dass es alle anderen auch so tun.
---
edit: war doch einfach:
shActionType | literal | required | options:jmpToTarget,toggleToCnt,toggleToCntInv,offAlso in jedem Aktor gibt es für den jeweiligen Peer (bei Dir bspw. BUTTON20) ein Register shActionType, das default auf "jmpToTarget" steht.
Wenn Du alle Aktoren in diesem Register auf "toggleToCnt" setzt, fahren sie immer in die gleiche Richtung.
Gleiches passiert bei "toggleToCntInv". Jedoch werden dann alle diese Aktoren genau entgegengesetzt zu "toggleToCnt" fahren.
Die Änderungen betreffen nur den speziellen gepeerten Button und machen daher speziell für "globale" Fernbedienungen" mit Einknopfbedienung Sinn.
edit2: Versuch eines Befehls (ersetze <Aktor> durch die Namen deines Rolladenaktors und <Button> durch den Namen der Fernbedienungstaste)
set <Aktor> regSet shActionType toggleToCnt <Button>---
Zitat
Eine merkwürdige Sache ist mir aufgefallen: An der FB hieß es nach Druck auf den Config-Button erst "Zentrale/Anlernen", nun heißt es plötzlich "Zentrale/Übernehmen" .. führt aber offensichtlich dennoch das anlernen - bzw. eben das peeren der FB mit den jeweiligen Aktoren aus, denn das hat dann geklappt.
Bedeutet das gleiche. Bei "Anlernen" werden peers wohl neu angelegt, mit "Übernehmen" Konfigurationsänderungen (oder das Hinzufügen von Peers) übernommen. Ist völlig egal.
Zitat
Das blinde Peeren, das ich vorher schon mal gemacht hatte hat übrigens nicht geklappt, der Aktor, der offline war, den ich aber ansonsten mit gleicher Vorgehensweise peeren wollte hat über die FB nicht reagiert. Hier hab ich also ein unset gemacht und nochmal neu gepeert, dann ging das auch.
FHEM speichert Konfigurationsbefehle nur begrenzt. Du kannst nie erwarten, dass ein Gerät dass offline ist, einen Konfig-Befehl nach Tagen nachgereicht bekommt.
Zitat
super, vielen Dank für die Info, hab ums verrecken gestern keine Sonderzeichen geschafft und wenn der Text zu lang wurde hat er plötzlich etwas anderes geschrieben (z.b. rallo statt rollo ...)
Ich nehme an text1 = zeile1, text2=zeile2?
Genau so. Es werden genau zwei Strings in dem Befehl erwatet, die keine Leerzeichen enthalten dürfen, deswegen ja der Konstrukt mit \_.
Der Rest wurde wohl schon bearbeitet.
Danke für die Infos, bin leider erst jetzt wieder mal dazu gekommen mich damit zu beschäftigen.
Ich hab einen HM 2-Kanal Switch/Aktor (HM-LC_SW2-FM), an dem hängt an einem Kanal ein TV, am anderen ein Licht.
Der Aktor ist definiert als CUL_HM mit der ID z.b. A00001, hat ein IODev, etc, und es sind 2 weitere devices definiert, ebenfalls als CUL_HM mit ID A0000101 (Device TV) und A0000102 (Device TV_Licht)- was ja offensichtlich die 2 Kanäle des Aktors sind.
Ich hab erstmal das Device TV mit der Fernbedienung gepeert, das funktioniert einwandfrei, ich kann mit der entsprechenden Taste der FB den TV ein- bzw. ausschalten.
Dann hab ich auf dem genau gleichen Weg versucht, einen anderen (unbelegten) Button der Fernbedienung mit dem anderen Device (TV_Licht) zu peeren. Das will ums verrecken nicht funktionieren.
Ich bekomme nach einem neuen Anlernen bzw. Konfig übernehmen an der FB trotzdem keinen weiteren Button aktiv. Ich hab's mehrmals versucht, nach einem Fehlschlag auch mit unset wieder sauber gelöscht und nochmal ganz sauber von vorne.. auch einen anderen Button der FB hab ich versucht - keine Chance.
Dann hab ich's über einen Umweg versucht - einen virtuellen Aktor definiert, hier einen Button Btn1 auf Kanal1 am virt. Aktor und mit notify ..Btn1:set_press.* schalte ich das Device TV_Licht auf on bzw. toggle.
Der virtuelle Aktor-Button Btn1 funktioniert auch, wenn ich ihn aus Fhem aufrufe und tut wie er soll.
Nun hab ich versucht, diesen virtuellen Button Btn1 mit einem Button der FB zu peeren.
set BUTTON11 peerChan 0 virt_Btn1 single set
Auch hier - keine Chance... er zeigt mir an der FB keinen neuen Button wenn ich erneut an Zentrale anlerne bzw. config aktualisiere.
Was mache ich hier noch falsch??
Zitat von: zenzi123 am 09 Oktober 2019, 07:14:56
Was mache ich hier noch falsch??
Das frage ich mich auch. Ich versuche mal zusammenzufassen:
- die Prozeduren sitzen: peerChan, dann Knopf an der FB drücken, Übernahme starten
- Aktor Sw2-FM ist richtig angelegt, zwei Kanäle, kann aus FHEM schalten
- virtueller Button <-> Kanal 2 funktioniert
Demnach scheint (!) es keine Probleme mit dem Aktor zu geben.
- DisplayFB <-> virt. Button funktioniert NICHT
- DisplayFB <-> Kanal 2 funktioniert NICHT.
Die Fernbedienung kann nicht gepeert werden, weder mit einem virtuellen Button noch mit einem realen Aktor.
- Ein spezielles model-Problem mit dem 2-Kanal-Aktor kann hier nicht vorliegen, da das Koppeln mit einem virt. Button immer funktionieren müsste.
Was ich noch dazu weiß:
- Ein Button ist auf der DisplayFB erst anwähl- und bedienbar, wenn es einen Peer gibt.
- es ist möglich Lücken zu lassen (Button1-3, dann ab Button 11) - die leeren Plätze werden beim Anwählen mit dem Rad übersprungen
Bis hierhin alles richtig und logisch.
unset macht nur Sinn, wenn es peer-Reste gibt, etwa im Aktor. Wenn beide Geräte keinen peer ausweisen, bringt es nichts.
Ich würde folgendes tun, wenn nicht bereits geschehen:
- "set BUTTON11 clear msgEvents". Nicht dass da was den Kanal verstopft und deswegen neuere Befehle nicht abgearbeitet werden können.
- immer nach einem Peer-Versuch: "set BUTTON11 getconfig" - und Übernahme an der FB starten
jetzt erst ist eine Aussage über erfolgreiche Peers möglich
Probiere außerdem einmal, den virtuellen Button mit dem 2-Kanal-Aktor zu peeren. Du hast ja nur eine Kopplung via Notify beschrieben. Dann führt eine Betätigung des virtuellen Buttons auch ohne Notify zu einer Aktion am Aktor. Aber eigentlich sollte das funktionieren, ist mehr akademisch.
Gibt es eine saubere Übernahme an der FB? in der Regel werden erfolgreiche Prozesse mit grün quittiert, bin gerade nicht sicher wie das die DisplayFB macht. Davon unterscheidet sich das Verhalten, wenn man ohne anstehende Konfigurationsarbeit aus FHEM heraus an der FB den Prozess startet. Das blinkt dann dort etwas länger bis zum Timeout, während eine erfolgreiche Aktion nach wenigen Sekunden beendet ist.
Ende des Lateins.
Danke, ja, die Zusammenfassung ist genau richtig.
Das mit Set Button clear msgEvents und getconfig werd ich mal checken.
Und ja, wenn ich ein set FB_button peerChan... in Fhem mache und dann an der FB übernehme Startet die Display-FB mit Grüner Schrift, blinkt dann rot (bzw. orange) und abschließend endet sie dann mit grün. wenn nix geändert wurde und ich lerne an, dann blinkt sie länger (ich glaub in grün).. bis zum timeout.
also passieren tut da schon was. ich werd evtl. auch mal einen funktionierenden button unpeeren und neu peeren.. nur um -akademisch- zu testen...
den virt. button mit aktor peeren kann ich auch versuchen..
eigentlich müssts ja sowieso direkt und ohne virt. button gehen.. sehr komisch..
Ich hab mir das gestern nochmal angesehen und hab nochmal sicherheitshalber ein set FB_BtnX peerChan ... unset für ALLE buttons gemacht, die ich an der FB nicht brauchte und die nicht belegt sein SOLLTEN.
nach jedem unset brach angelernt/übernommen etc..
Dann hab ich nochmal versucht den 2. kanal vom switch mit einem button der FB zu peeren.... und plötzlich das unerwartete - ES HAT FUNKTIONIERT!!
Offensichtlich war es tatsächlich so, dass noch irgendein peering "festhing" (obwohl ich in den registern und bei peerCheck nicht unpassendes gesehen hätte) und durch das unset dann gelöst wurde.
Nun konnte ich plötzlich auch ganz einfach einen virtuellen button mit einem FB-button peeren.
das press an der FB hat zwar noch nicht funktioniert, hatte dann aber keine zeit mehr mir das noch anzusehen, das kann wohl nix dramatisches mehr sein...
ok.. leider hab ich doch noch ein weiteres Problem, evtl versteh ich'S noch nicht so ganz..
Ich hab nun also einen virtuellen Button vbtn1.
der ist in fhemweb mit wbcmd press short und press long verfügbar.
Ich hab ein notify für den button vbtn1 eingerichtet
defmod test notify vbtn1:set_press.* {DebianMail("mail@domain.com","text"," ") }
Wenn ich den button über web betätige wird das mail gesendet.
Den Button habe ich mit der Fernbedienung gepeert.
An der Fernbedienung ist der neu gepeerte Kanal nun auch aktiv.
Wenn ich aber den entsprechenden kanal an der Fernbedienung drücke, dann löst der notify nicht aus.
An der Fernbedienung wird die Kanalbezeichnung beim drücken ORANGE, kurz darauf dann ROT - was ja bedeutet, dass er kein OK von fhem retour bekommt.
Ich hab keine rechte Idee, wie ich checken kann, ob die Fernbedienung überhaupt ein notify beim drücken des buttons sendet oder wo hier das Problem liegt.
Ich hab zum test mal das notify so eingerichtet:
defmod test notify vbtn1:* {DebianMail("mail@domain.com","text"," ") }
Idee: er soll bei jeder aktion ein mail auslösen.
Problem ist, dass die fernbedienung offensichtlich ziemlich viel sendet, denn nun werde ich mit diesem mail zugespamt.
hab auch notify vbtn1:Short.* .. versucht.. funktioniert auch nicht..
Wo und wie finde ich raus OB die Fernbedienung was beim drücken sendet und WAS sie da sendet?
:-[
Immer wieder im Eventmonitor :)
Aufmachen vbtn1.* als Filter und zuschauen ::)
hat der virtuelle Button die FB als peer eingetragen? Dann passiert das ACK (orange-grün) automatisch...