Hallo zusammen,
ich habe mir kürzlich die HM-RC-DIS-H-X-EU angeschafft.
Mit ein bisschen Mühe habe ich es geschafft, einen Stecker mit der Fernbedienung zu koppeln. Ich konnte bisher nicht so recht herausfinden können, was man mit der Fernbedienung noch genau machen kann. Gibt es hier noch eine Übersichtsseite? Im fhem-Wiki konnte ich nicht wirklich etwas finden.
Insbesondere wäre für mich wichtig/interessant, dass der aktuelle Zustand eines Aktors angezeigt wird.
Wenn die Fernbedienung ungekoppelt ist, gibt es ein Einstellungsmenü, wo ich zum Beispiel den Anzeige-Timeout des Displays und noch andere Dinge einstellen kann. Diese Einstellungsmöglichkeiten sind aber weg, sobald die Fernbedienung mit fhem (CUL) gekoppelt ist.
Ich bin für hilfreiche Hinweise dankbar :)
Ich habe die FB selbst und nutze sie als Universalwaffe fürs Wohnzimmer. Einige Aktoren sind direkt gekoppelt, andere neben einer vccu-Kopplung zur ACK-Erzeugung werden nur als Events in FHEM ausgewertet (für nicht HM-Hardware).
Übersichtsseite ... hm, nein, im Wiki haben wir auch nichts, soso.
Die Handfernbedienung ist von der Art her mit dem Display-Wandtaster verwandt: https://wiki.fhem.de/wiki/HM-PB-4DIS-WM_Funk-Wandtaster_mit_Display
Der Wandtaster zeigt 10 Seiten 2 Buttons, die Handfernbedienung 20 Seiten mit einem Button. In FHEM werden beide mit 20 Kanälen dargestellt.
Auf der FB bekommst Du nur Buttons zur Auswahl und Benutzung, für die ein peer vorhanden ist. Du musst also einen Kanal zuerst peeren (eben mit einem Aktor oder einem virtuellen Button in FHEM), bevor Du ihn dann auf der Fernbedienung nutzen kannst. Die Programmierung der Anzeigetexte ist dann auch möglich. Das passiert analog zum Wanddisplay, siehe Wiki-Artikel.
Die FB kann nicht "geweckt" werden. Daher muss man für Konfigurationsänderungen den Config-Button kurz (!) drücken und die Übertragung abwarten (siehe Display). Daraus resultiert auch, dass der Status eines Aktors nicht angezeigt werden kann. Allerdings wird der während einer "Sendung" vom zu steuernden Gerät rückgemeldete Zustand noch angezeigt. Bei Dimmern kann man damit bspw. die aktuelle Dimmstufe verfolgen.
Die im ungekoppelten Zustand möglichen Einstellungen kannn man nach der Kopplung via FHEM (im Gerätekanal, nicht bei den Channels) einstellen:
list: register | range | peer | description
0: language | literal | | Language options:English,German
0: pairCentral | 0 to 16777215 | | pairing to central
0: stbyTime2 | 1 to 120s | | Standby Time
0: wakeupBehavior | literal | | wakeup behavior options:on,off
0: wakeupDefChan | 0 to 20 | | wakeup default channel
Standby Time dürfte die Anzeigezeit des Displays sein, Language erklärt sich selbst. Bei wakeup behavior bin ich selbst überfragt.
Zitat von: Pfriemler am 07 März 2020, 15:04:30
Ich habe die FB selbst und nutze sie als Universalwaffe fürs Wohnzimmer. Einige Aktoren sind direkt gekoppelt, andere neben einer vccu-Kopplung zur ACK-Erzeugung werden nur als Events in FHEM ausgewertet (für nicht HM-Hardware).
"Direkt gekoppelt" heißt also Display-Fernbedienung<->Aktor ohne den "Umweg" fhem?
Zitat von: Pfriemler am 07 März 2020, 15:04:30
Übersichtsseite ... hm, nein, im Wiki haben wir auch nichts, soso.
Die Handfernbedienung ist von der Art her mit dem Display-Wandtaster verwandt: https://wiki.fhem.de/wiki/HM-PB-4DIS-WM_Funk-Wandtaster_mit_Display
Die hatte ich zwischenzeitlich auch schon gesehen, aber genau diese "Verwandschaft" ist auf der Seite nicht erwähnt.
Ich danke dir für deine Infos.
Hm, ich hatte so die Idee, die Texte in der Fernbedienung nutzen zu können, um damit, auch dynamisch, Informationen anzeigen zu können.
Dafür ist am ehesten wohl die Funk-Statusanzeige HM-Dis-EP-WM55 geeignet, in der OLED-Variante hier beschrieben: https://wiki.fhem.de/wiki/HM-Dis-WM55_Funk_Statusanzeige. Allerdings wird oben zwar geschrieben, die Texte werden auch dort nur nach Druck auf die Config-Taste übernommen, unten aber ein "Hack" beschrieben, um auch dynamisch Texte anzeigen zu können.
In diesem Thread: https://forum.fhem.de/index.php/topic,53380.15.html
verstehe ich das ebenfalls so, dass man das Display auch von extern "bespielen" kann. Aber dann wiederum würde ich die Fähigkeit Aktoren zu steuern verlieren, weil idR Taster 1/2 für "Vor / Zurück" drauf gehen?
Zitat von: samdave11 am 24 März 2020, 20:01:58
"Direkt gekoppelt" heißt also Display-Fernbedienung<->Aktor ohne den "Umweg" fhem?
Genau so. Fast verzögerungsfrei und mit bestimmen Aktoren wie Dimmern oder Rolladenantrieben sehr viel praktischer. FHEM liest natürlich mit und ist immer auf dem letzten Stand.
ZitatHm, ich hatte so die Idee, die Texte in der Fernbedienung nutzen zu können, um damit, auch dynamisch, Informationen anzeigen zu können.
Das kann sie nicht leisten.
ZitatDafür ist am ehesten wohl die Funk-Statusanzeige HM-Dis-EP-WM55 geeignet,
Sowohl EP- als auch OLED-Variante gestatten meines Wissens keine Direktverknüpfung.
Ach, wie genau das ging, weiß ich auch nicht mehr. Aber im Grunde geht es so, dass auf Tastendruck eine Kommunikation mit der Zentrale (CCU oder FHEM) stattfindet und die Texte dynamisch rückübermittelt werden. Das ist ziemlich zäh und auch nicht ganz unkompliziert. Die EP-Variante ist aber meines Wissens "fernbestückbar", d.h. ohne Aktion am Display selbst. Details findest Du in einem riesigen Thread dazu, ich habe mein OLED-Display wieder verkauft, weil ich nicht damit zurechtgekommen bin (und andere Lösungen dann spannender fand).
ZitatAber dann wiederum würde ich die Fähigkeit Aktoren zu steuern verlieren, weil idR Taster 1/2 für "Vor / Zurück" drauf gehen?
Sozusagen. Allerdings bekommt man zwei "zusätzliche" Tasten durch entsprechenden längeren Tastendruck. Man kann also eine Auswahl mit vor/zurück realisieren und eine Bestätigung/Cancel mit langem Tastendruck. So kann man Hauptmenüs und Untermenüs betreten und verlassen und schließlich auch eine Steuerung (auf unterster Ebene) realisieren - allerdings eben nicht mehr unbedingt in lang/kurz-Unterscheidung, wie sie für eine Dimmersteuerung praktisch unabdingbar ist. Die gesamte Menüstruktur und die "Zustandsmaschine" dazu muss man in FHEM selbst abbilden und ausführen.
Die Displayhandfernbedienung und das Äquivalent Wanddisplay hingegen speichern bis zu 20 Partner zur direkten Auwahl und Ansprache im Gerät.
Bescheidene Frage: wie hast du zusätzlich zur Verbindung mit fhem noch direkte Kopplungen gemacht? Ich muss doch mit "Zentrale" anlernen, weil ich sonst keine Texte einstellen, etc., kann. Aber wenn ich die Fernbedienung mit fhem/CUL als Zentrale gekoppelt habe, kann ich doch keine direkten Kopplungen auf Kanalbasis mehr machen?
ZitatAber wenn ich die Fernbedienung mit fhem/CUL als Zentrale gekoppelt habe, kann ich doch keine direkten Kopplungen auf Kanalbasis mehr machen?
woher kommt diese falsche info?
jede zentrale darf und kann zusätzliche direkte verbindungen im device anlegen.
unter cul_hm/fhem nennt sich das "
peeren".
dafür gibt es extra befehle:
1. am einfachsten sollte
peerSmart sein. beide partner werden per klick ausgewählt.
eventuell noch nicht für alle device kombinationen verfügbar.
2.
peerChan sollte immer funktionieren.
3.
peerBulk ist eher auf raw-ebene für experten und notfälle.
Hm...
ich habe die Fernbedienung gerade mal zurückgesetzt und neu angelernt, um das zu testen.
Entweder funktioniert hier was nicht richtig, oder ich mache immer etwas falsch ;D
Das Übernehmen der Config scheint sehr unzuverlässig zu funktionieren.
Ich beobachte den State der Fernbedienung in der Detail-Übersicht. Hier steht CMDs_pending, und so habe ich mehrfach im Config-Menü der Fernbedienung "Übernehmen" bei Zentrale gedrückt.
Wenn ich das richtig sehe, sollte es so sein:
fhem sagt CMDs_pending
Ich gehe in der FB auf "Zentrale" "Übernehmen"
Config wird übernommen (ggf. nach mehrmaligem "Übernehmen") und fhem wechselt auf CMDs_done.
Wenn ich jedoch versuche, Konfigurationsänderungen zu übernehmen, blinkt Zentrale immer nur grün und hört damit dann auf, am Status CMDs_pending ändert sich meist nichts, auch nicht nach ~10 mal "Übernehmen".
Zwischendrin gibt es jedoch mal Fehlermeldungen, wie:
RESPONSE TIMEOUT:RegisterRead
MISSING ACK
Anders sieht es aus, wenn ich "clear msgEvents" und dann explizit "getConfig" ausführe. Dann blinkt in der Fernbedienung
"Zentrale" einige Sekunden orange (in dieser Zeit sagt fhem "CMDs_processing...") und zum Schluss kurz grün.
Dazu folgende Verständnisfrage(n)
Nehmen wir an, die Fernbedienung heißt "FB" und ich habe eine Homematic-Funksteckdose die "Funkstecker" heißt.
Dann wäre der korrekte Befehl
set FB_Btn_01 peerChan 0 Funkstecker single set
und es handelt sich dabei dann um eine direkte Kopplung ?
Speichert fhem diese direkten Kopplungen, sodass ich sie einsehen könnte (und sie über getConfig ggf. rückspielbar sind), oder nutze ich fhem an der Stelle lediglich, um die entsprechenden Steuernachrichten über HM rauszusenden?
Wiedemauchsei, ich habe jetzt auf Btn_02 ein clear all ausgeführt, das mehrfache Konfig-Übernehmen hat dann dazu geführt, dass tatsächlich nochmal alle Buttons gelöscht und der 1. Button korrekt angelegt wurde, sodass für den Moment jetzt wieder alles so ist wie vorher :)
Für die Beantwortung meiner Fragen wäre ich dennoch dankbar, damit ich insb. nachvollziehen kann, warum das teilw. so "wackelig" ist.
Prinzipiell siehst Du das schon richtig.
wie frank schon sagte: Die Zentrale kann immer Direktverknüpfungen vornehmen, die in den Geräten abgelegt werden. Dein "set ...peerChan..." Beispiel tut genau das.
Über die ausgelesenen Register aus den Geräten rekonstruiert FHEM die Zusammenhänge, d.h. es weiß schon prinzipiell, welche Geräte/Kanäle miteinander verknüpft sind. Nicht umsonst gibt es auch im Modul hminfo (unbedingt anlegen wenn noch nicht passiert, ebenso vccu) "peerCheck". Dort steht dann schon, wenn FHEM noch Register fehlen.
Prinzipiell immer gut: Immer eins nach dem anderen, mit Config-Taste alles abarbeiten lassen, bei Fehlern "clear msgEvents" durchführen und erst dann Befehl wiederholen.
Und Grundregel "Richtiger Abstand" immer bedenken. Zwischen Zentralen-IO und Gerät immer mindestens einen Meter, besser zwei, Abstand lassen. Sonst bölkt sich das gegenseitig taub.
"wackelig" => schlechtes timing und/oder schlechter funk.
zb schlechtes io, schlechte fw auf io, latenzen von fhem zum io, freezes in fhem, ....
besonders auffällig bei batterie geräten und aes.
hast du einen cul ohne tsculfw?
So, da bin ich wieder ;D
"Wackelig" hatte ich nur den Eindruck, dass die Config-Übernahme auf der Fernbedienung läuft. Mittlerweile weiß ich, dass "Zentrale" schnell orange blinken muss und dass das das Zeichen dafür ist, dass config übertragen wird. Und, dass das manchmal auch mehrfach nötig ist.
Ich habe zwischenzeitlich mal mit OpenHAB+homegear experimentiert, mich aber dazu entschlossen, doch bei fhem zu bleiben und bin jetzt nochmal neu eingestiegen.
Meinen CUL habe ich dazu auch nochmal geflasht, er läuft jetzt mit der letzten Firmware von culfw.de.
Steckdosen steuern klappt nun wie gewollt. Ich möchte nun aber ein paar "Sonderfunktionen" haben und frage mich, was der richtige/beste Weg ist, das umzusetzen.
Ich möchte gerne eine Taste auf der Fernbedienung haben, mit der ich mehrere Funkstecker zusammen grundsätzlich ausschalte.
Die erste Frage ist bereits, ob das auf Basis einer IO Entity oder virtuellen Entity gemacht werden muss. So richtig den Unterschied habe ich da noch nicht herauslesen können.
Und dann wäre die Frage: eher die Aktoren in einem structure binden, oder ein Notify anlegen, was die OFF-Kommandos schickt, oder doch ganz anders?
ich würde alle aktoren mit dieser taste peeren (peerSmart, peerChan). das funktioniert dann auch ohne fhem.
ZitatMeinen CUL habe ich dazu auch nochmal geflasht, er läuft jetzt mit der letzten Firmware von culfw.de.
das hat aber nichts mit der empfohlenen tsculfw zu tun.
Zitat von: frank am 14 Mai 2020, 10:04:33
ich würde alle aktoren mit dieser taste peeren (peerSmart, peerChan). das funktioniert dann auch ohne fhem.
OK. Wenn ich das nur mit einem Button mache, schaltet er damit beide Aktoren immer an. Ich würde gerne einen Button haben, der alle Aktoren grundsätzlich ausschaltet.
Zitat von: frank am 14 Mai 2020, 10:04:33
das hat aber nichts mit der empfohlenen tsculfw zu tun.
Verstehe ich gerade nicht. Im fhem-Wiki steht nichts zu tsculfw.
Ich habe
https://forum.fhem.de/index.php/topic,24436.msg1047116.html#msg1047116
gefunden, demzufolge ist das eine andere Firmware für den CUL + angepasste Module für fhem?
Zitatdemzufolge ist das eine andere Firmware für den CUL + angepasste Module für fhem?
genau. das ist die einzige fw für cul, die exaktes timing für homematic ermöglicht.
nach dem peeren, muss das verhalten der aktoren auf den tastendruck in den registern der aktoren noch angepasst werden.
ausserdem sollte es befehle "set tplSet_<peer>" geben, um entsprechende templates zum setzen der richtigen register auszuführen.
zeig mal "get tplInfo".
Zitat von: samdave11 am 14 Mai 2020, 10:48:11
Verstehe ich gerade nicht. Im fhem-Wiki steht nichts zu tsculfw.
Kannst Du sagen wo im Wiki da nichts dazu steht?
Hier steht es eigentlich https://wiki.fhem.de/wiki/HomeMatic#FHEM_als_Zentrale
Ich kann da noch die Abkürzung hinschreiben aber eigentlich dachte ich "HomeMatic optimierte CUL-firmware TimeStamp Firmware" ist ok?
Edit: Jetzt findet die Wiki Suche auch Franks Abkürzung tsculfw ;D
Ich war noch nie ein Freund der tsculfw. Die Informationen dazu sind erstens relativ verstreut. Ernsthaft: Der von Otto erwähnte Link führt auf einen Forumsthread, der auf eine neueren Beitrag verweist. Dieser Beitrag gehört ins Wiki, nach redaktionieller Überarbeitung. Und einer Klarstellung, was genau man gegenüber dem originalen Setting verändern
muss und was man dem gegenüber optional verändern
kann (und das ist dann schon teilweise sehr speziell, aber auch sehr mächtig). Das ist aber alles nix für Anfänger. Denen sollte man weiter ausschließlich zu einem "richtigen" HM-IO raten.
Zitat von: samdave11 am 14 Mai 2020, 10:48:11
OK. Wenn ich das nur mit einem Button mache, schaltet er damit beide Aktoren immer an. Ich würde gerne einen Button haben, der alle Aktoren grundsätzlich ausschaltet.
Wenn Du ausschließlich mit HM-Aktoren arbeitest, ist das kein Problem. Du kannst unabhängig von allen anderen Konstellationen eine (fast) beliebige Anzahl von Aktoren mit einem Button (hier: einem von 20 Kanälen) zusätzlich peeren und anschließend per Register die Einschaltoperationen "lahmlegen": Der Aktor ignoriert den Tastenbefehl dann, wenn er schon aus ist, statt sich einzuschalten.
Es gäbe einen Grund, von dieser Prozedur abzuweichen, nämlich wenn man Verwaltungsaufwand scheut und vorhat, mehrere solcher Buttons/Schalter/Trigger zu verwenden. Dann sollte man all diese Aktoren lieber mit einem virtuellen Button in FHEM peeren. Opfert man dafür ein Buttonpärchen (von denen eine VCCU ganz nebenbei bis zu 25 bereitstellt) und peert dual, so sind die Register aller Aktoren für den reinen Ausschaltvorgang bereits auf einen Button eingerichtet. Anschließend peert man den einen Knopf der Fernbedienung mit diesem Ausschaltbutton der VCCU - und das war es dann. Der Tastendruck auf der FB triggert dann den virtuellen Button in FHEM, der wiederum die Aktoren retriggert. Jeder weitere Alles-Aus-Button wird dann nur noch mit diesem virtuellen Button in FHEM gepeert.
Die ganze Aktion ist dann wiederum nur bei laufendem FHEM funktionabel - sonst ein Vorteil, den man sich damit verspielt.
Bei zwei oder drei Aktoren würde ich das aber einmalig und nur direkt zwischen FB und Aktoren machen und gut. Das Zauberwort heißt "shJtOff bzw. "lgJtOff" :-)
Habe ich was übersehen?
ZitatDieser Beitrag gehört ins Wiki, nach redaktionieller Überarbeitung.
Kann ich leider nicht. Ich bin ja schon froh überhaupt eine Info dort zu haben ;)
Zunächst einmal: vielen Dank für eure Hilfe!
Ich habe wie von frank vorgeschlagen mit tplSet gearbeitet. Es funktioniert!
Ich habe mich dann direkt gefragt, wie ich, wenn ich in 2 Monaten vergessen habe, was ich hier getan habe, diese Einstellung nachvollziehen kann. Gibt es einen besseren Weg als get regTable?
Jetzt hätte ich für den Moment nur noch einen Wunsch: ich möchte mit der Fernbedienung Shellskripte triggern. Dafür nehme ich dann eine virtuelle entity(?) + einen notify?
ZitatDafür nehme ich dann eine virtuelle entity(?) + einen notify?
Ist ein guter Weg. Wobei der Trigger auch direkt funktioniert.
gegen vergessen hilft alle Schritte aufschreiben :)
ZitatIch habe mich dann direkt gefragt, wie ich, wenn ich in 2 Monaten vergessen habe, was ich hier getan habe, diese Einstellung nachvollziehen kann. Gibt es einen besseren Weg als get regTable?
cul_hm bietet auch eine "verwaltung" bestehender konfigurationen/peerings der devices. entweder lokal im device und/oder zentral über hminfo.
zum sichern zb "get saveConfig". siehe auch wiki.
Also,
ohne virtuelle Entity wird es nicht gehen, da auf der Fernbedienung die Buttons erst erscheinen, wenn es ein peering gibt.
Das passiert im Event monitor, wenn ich den gewünschten Button drücke:
2020-05-15 20:32:44 CUL_HM FB battery: ok
2020-05-15 20:32:44 CUL_HM FB FB_Btn_05 Short
2020-05-15 20:32:44 CUL_HM FB_Btn_05 Short 1_58 (to adapterdings)
2020-05-15 20:32:44 CUL_HM FB_Btn_05 trigger: Short_58
2020-05-15 20:32:44 CUL_HM FB_Btn_05 triggerTo_adapterdings: Short_58
2020-05-15 20:32:44 CUL_HM FB_Btn_05 trigger_cnt: 58
"adapterdings" ist meine virtuelle Entity.
Ich würde gerne das Event möglichst scharf beschreiben, um im Notify z. B. die unterschiedlichen Tastendrücke (short/long) unterschiedlich auswerten können.
Was funktioniert ist:
FB_Btn_05:triggerTo_adapterdings:.* {system ("meinsupershellskript.sh")}
Was aber bspw. nicht funktioniert, ist:
FB_Btn_05:triggerTo_adapterdings:Short_.* {system ("meinsupershellskript.sh")}
Selbst wenn ich spaßeshalber mal ein Short mit konkretem Zähler einstelle, klappt das auch nicht.
Beginnen wir mal hinten:
{system ("meinsupershellskript.sh")} brauchst Du normal nicht. Es geht auch:
"meinsupershellskript.sh"
Funktioniert das genauso (also MIT "") in der FHEM Kommmandozeile?
Nimm doch als Trigger: Mach ich meistens so, das ist doch ziemlich exakt :)
FB_Btn_05:Short
Oder Du triggerst auf adapterdings :) der macht auch Events.
Gruß Otto
FB_Btn_05:triggerTo_adapterdings:.Short_.* {system ("meinsupershellskript.sh")}
da hat wenigstens ein "punkt" für ein leerzeichen gefehlt.
Zitat von: Otto123 am 15 Mai 2020, 21:09:18
Beginnen wir mal hinten:
{system ("meinsupershellskript.sh")} brauchst Du normal nicht. Es geht auch:
"meinsupershellskript.sh"
Funktioniert das genauso (also MIT "") in der FHEM Kommmandozeile?
Das muss ich mir mal anschauen. Ich hatte da jetzt erstmal Code von meiner "Ist meine Waschmaschine fertig?"-Überwachung kopiert, der ist sehr alt und seinerseits auch von woanders herkopiert. Wenn jetzt die Nummer mit der Fernbedienung funktional läuft, wollte ich eh mal die Config aufräumen, das käme dann dazu.
Zitat von: Otto123 am 15 Mai 2020, 21:09:18
Nimm doch als Trigger: Mach ich meistens so, das ist doch ziemlich exakt :)
FB_Btn_05:Short
Funktioniert nicht.
Was hingegen funktioniert, ist:
FB_Btn_05.Short.*
Zitat von: frank am 15 Mai 2020, 21:51:08
FB_Btn_05:triggerTo_adapterdings:.Short_.* {system ("meinsupershellskript.sh")}
da hat wenigstens ein "punkt" für ein leerzeichen gefehlt.
Aha! Das war das Problem.
Ist das generell ein "richtiger" Perl-Regexp, oder ist die Syntax dort nur angelehnt?
".*" ist ja dann einfach "0 bis n mal beliebiges Zeichen".
Ja Sorry, meine Variante war:
FB:FB_Btn_05.Short
Deine Variante ist nicht gut, hab ich letztens gelernt. 8)
FB_Btn_05.Short.* muss sich gegen alle Events deines Systems "beweisen"
FB_Btn_05:Short.* muss sich nur gegen alle Events des Devices FB_Btn_05 "beweisen"
Beim notify regexp wird glaube ich intern noch ^ vorn und $ hinten angefügt, ansonsten ist der Trigger mMn richtiger regExp
Wunderbar!
Das einzige, was noch fehlt ist dass die Befehle bestätigt werden. Das Senden des Kommandos wird aktuell noch rot.
Dazu ist wohl relevant:
https://wiki.fhem.de/wiki/HM-RC-4-2_Funkfernbedienung_4_Tasten#LED_.2F_R.C3.BCckantwort
Kann es sein, dass der Abschnitt nicht mehr aktuell ist?
Und wenn ich das model zu ändern versuche, wird auf modelForce verwiesen, aber in der Liste gibt es den generischen Typen receiver nicht. Muss ich da dann einfach irgendeinen konkreten Homematic-Aktor wählen?
wenn es rot gibt, erwartet die FB die Antwort von einem peer, der aber nicht kommt.
Ansonsten ist es richtig, dass die Buttons dieser FB erst erscheinen, wenn es einen peer gibt. Da kann man aber für alle 20 dieser FB (und noch mehr) denselben virtuellen Button nehmen (sofern nicht eh ein "echtes" HM-Gerät gepeert ist). Die Auswertung sollte man dann aber doch wie beschrieben am Tasterevent machen.
FB_Btn_05:Short
funktioniert nicht weil es kein matchendes Event "Short" gibt (sondern sowas wie "Short_xx (to VCCU"). Otto hat schon die Lösung im Text.
ZitatDas Senden des Kommandos wird aktuell noch rot.
Das bedeutet Du hast Deinen virtuellen Peer falsch gemacht.
Um das zu beurteilen müsstest Du mal alle beteiligte Geräte posten.
hminfo configCheck hilft Dir auch bei der Fehlersuche. ;)
Der Abschnitt in dem Wiki Artikel den Du gepostet hast kommt mir komisch vor. Allein das dort 3 mal der Begriff HMID falsch geschrieben steht ::) muss ich mir mal in Ruhe anschauen. Voriges Jahr gab es einige einschneidende Veränderungen in CUL_HM - kann sein, dass das so nicht mehr funktioniert.
Ich nutze für so etwas channels der VCCU, die ist sowieso da. Und ein ein Channel davon eignet sich prima als virtueller Peer für alle Fernbedienungen.
Zitat von: Pfriemler am 15 Mai 2020, 23:47:22
wenn es rot gibt, erwartet die FB die Antwort von einem peer, der aber nicht kommt.
Jau, das habe ich verstanden.
Zitat von: Pfriemler am 15 Mai 2020, 23:47:22
Ansonsten ist es richtig, dass die Buttons dieser FB erst erscheinen, wenn es einen peer gibt. Da kann man aber für alle 20 dieser FB (und noch mehr) denselben virtuellen Button nehmen (sofern nicht eh ein "echtes" HM-Gerät gepeert ist).
Stimmt, guter Hinweis.
Zitat von: Otto123 am 16 Mai 2020, 09:39:33
Das bedeutet Du hast Deinen virtuellen Peer falsch gemacht.
Der ist anscheinend garnicht gemacht worden. Die Liste der peers bei meiner virtuellen Entity war leer. Das habe ich dann behoben, wie auf dieser Wikiseite als zweiter Vorschlag unter C angegeben ist:
https://wiki.fhem.de/wiki/Diskussion:HM-RC-12_Funkfernbedienung_12_Tasten
Wobei, das war ja nur einseitig, ich habe dann wie unter 6. angegeben nochmal ein peerChan gemacht, jetzt ist das peering beidseitig und hmConfig beschwert sich über nichts mehr was diese Geräte angeht :)
Zitat von: Otto123 am 16 Mai 2020, 09:39:33
Ich nutze für so etwas channels der VCCU, die ist sowieso da. Und ein ein Channel davon eignet sich prima als virtueller Peer für alle Fernbedienungen.
Ich habe sowieso noch nicht verstanden, wo da der fundamentale Unterschied ist :)
Bezüglich Wiki: nicht nur da, auch in der FHEM-Doku sind mir schon öfter Tippfehler bzw. schlechtes/kaputtes Englisch aufgefallen. Ich könnte anbieten, da mal was zu überarbeiten.
Zitat von: Otto123 am 16 Mai 2020, 09:39:33
Der Abschnitt in dem Wiki Artikel den Du gepostet hast kommt mir komisch vor. Allein das dort 3 mal der Begriff HMID falsch geschrieben steht ::) muss ich mir mal in Ruhe anschauen. ...
Die ganze Erklärung der Definition eines virtuellen Devices ist fragwürdig. Schon mal versucht bei einem CUL_HM-Gerät ein Attribut "hmClass" zu setzen? und der subType wäre ein virtual.
So, wo anfangen?
Für's Wiki muss man nur einmalig einen gesonderten Zugang beantragen. Jede Hilfe ist willkommen.
Zitat von: samdave11 am 16 Mai 2020, 10:22:25
Bezüglich Wiki: nicht nur da, auch in der FHEM-Doku sind mir schon öfter Tippfehler bzw. schlechtes/kaputtes Englisch aufgefallen. Ich könnte anbieten, da mal was zu überarbeiten.
Das wird gern gesehen! Fürs Wiki kannst Du auf der Wiki Seite einfach einen Account beantragen.
Unterschied: Virtuelle "Aktoren" oder Geräte und Kanäle der VCCU:
Warum genau es so ist kann ich auch nicht sagen, aber die Kanäle der VCCU können nicht "alles".
Es gibt auch immer wieder die Eigenheit, das man den ersten Channel des virtuellen Gerätes braucht, d.h. man braucht dann auf alle Fälle schon mal Eines mehr. Und VCCU geht eigentlich bloß einmal.
Mir geht es wie Pfriemler, den Befehl attr hmclass habe ich noch nie gesehen ::)