[gelöst] Verständnisproblem HM-PB-6-WM55 ind virtuelle Devices

Begonnen von JoeALLb, 17 Oktober 2013, 13:32:48

Vorheriges Thema - Nächstes Thema

JoeALLb

Im Wiki ist jeweils beim HM-PB-6-WM55 und beim HM-PB-2-WM55
einkurzer Absatz über virtuelle Taster enthalten.
Da der beim HM-PB-6-WM55 deutlich kürzer ist,
habe ich auch den anderen Artikel herangezogen:
--> Sollte es nicht einen eigenen Artikel über virtuelle Taster geben, auf
welchen diese beiden Artikel nur verweisen?

Nun zu meinem Problem:
Ich habe den virtuellen Taster folgendermaßen angelegt,
bekomme jedoch keinen aktuellen Status angezeigt. Auch der Knopf blinkt immer nur gelb
und gibt mir somit kein Feedback über den Schaltstatus.

Kann mir jemand helfen, wo der Denkfehler liegt?


# Der Physikalische Schalter

define wz.Bedienung.dev CUL_HM 30D056
attr wz.Bedienung.dev .devInfo 060000
attr wz.Bedienung.dev .stc 40
attr wz.Bedienung.dev expert 2_full
attr wz.Bedienung.dev firmware 1.1
attr wz.Bedienung.dev model HM-PB-6-WM55
attr wz.Bedienung.dev peerIDs
attr wz.Bedienung.dev room Device
attr wz.Bedienung.dev serialNr KEQ0180156
attr wz.Bedienung.dev subType remote
attr wz.Bedienung.dev webCmd getConfig
attr wz.Bedienung.dev subType pushButton


# Button 1

define wz.Bedienung_01 CUL_HM 30D05601
attr wz.Bedienung_01 expert 1
....


# Der virtuelle Schalter

define wz.Bedienung.virt CUL_HM 123456
set wz.Bedienung.virt virtual 6

set wz.Bedienung_01 peerChan 0 wz.Bedienung.virt_Btn1 single set
set wz.Bedienung_02 peerChan 0 wz.Bedienung.virt_Btn2 single set
set wz.Bedienung_03 peerChan 0 wz.Bedienung.virt_Btn3 single set
set wz.Bedienung_04 peerChan 0 wz.Bedienung.virt_Btn4 single set
set wz.Bedienung_05 peerChan 0 wz.Bedienung.virt_Btn5 single set
set wz.Bedienung_06 peerChan 0 wz.Bedienung.virt_Btn6 single set

set wz.Bedienung.dev getConfig 



FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

betateilchen

Zitat von: JoeALLb am 17 Oktober 2013, 13:32:48
Kann mir jemand helfen, wo der Denkfehler liegt?

Du hast den virtuellen Aktor noch nicht mit einer Taste Deines PB-6 gepeert.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

JoeALLb

Also nach dem absetzen diesen Befehles
set wz.Bedienung_01 peerChan 0 wz.Bedienung.virt_Btn1 single set
auf der Rückseite des Tasters den Knopf zum anlernen drücken und danach auf dem Gerät
selbst die Taste 1 drücken?!

Setze ich DANACH das alles für die zweite Taste aus:?
set wz.Bedienung_02 peerChan 0 wz.Bedienung.virt_Btn2 single set
+ wieder anlernen drücken und die 2. Taste drücken?

Werd das heute Abend versuchen!
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

betateilchen

ja, für jede Taste. Könnte ja sein, dass Du eine Taste mit irgendwas anderem peeren möchtest als mit einem virtuellen Aktor.

Man kann übrigens auch auf den virtuellen Aktor komplett verzichten. Ob man nun ein notify auf den virtuellen Aktor triggert oder auf die Taste selbst, führt letztendlich zum gleichen Ergebnis - aber das ist ein anderes Thema :)
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

JoeALLb

Zitat von: betateilchen am 17 Oktober 2013, 14:31:36
Ob man nun ein notify auf den virtuellen Aktor triggert oder auf die Taste selbst, führt letztendlich zum gleichen Ergebnis - aber das ist ein anderes Thema :)

Laut dem Wiki weiß die Taste, wenn sie nicht direkt mit dem Aktor verbunden ist, jedoch ihren Status nicht und zeigt imme rnur ein oranges Licht als Bestätigung.
Die virtuelle Taste soll genau das "beheben". Da ich beim Schalten tatsächlich derzeit nur das orangen LED sehe, dachte ich, dass dies die empfohlene Lösung wäre....

Hast Du einen anderen Ratschlag?
Danke jetzt schon mal für Deine Antworten!
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

betateilchen

ZitatDa ich beim Schalten tatsächlich derzeit nur das orangen LED sehe, dachte ich, dass dies die empfohlene Lösung wäre....

Jein...

Ich habe bei mir die Tasten des PB-6-WM55 einfach alle direkt mit dem HMLAN gepeert (bei mir ist der HMLAN in Wirklichkeit der HM-USB-Stick, aber das spielt keine Rolle). Dann funktioniert die Rückmeldung rot/grün direkt und ohne virtuellen Aktor und ich kann einfach die Tastendrücke per notify auswerten.

Der von Dir erwähnte Wiki-Eintrag ist insofern richtig, dass diese Methode des Peerings wohl bei älteren Tastern und Fernbedienungen noch nicht zur Verfügung stand und deshalb der Weg über den virtAct notwendig war.

Meine praktische Erfahrung ist, dass dies bei vielen neuen Devices (HM_RC-4-2, PB6, den PCB-Schaltaktoren usw) nicht mehr zwingend notwendig ist. Du gehst damit auch einigen Timing-Problemen innerhalb von Homematic komplett aus dem Weg.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

martinp876

eure peering-strategie verstehe ich nicht.

Man kann 6 virtuelle Aktor-channels anlegen - der PB5WM hat  tasten.

Ich gehe davon aus, dass der PB6 schon mit FHEM gepairt ist

man sollte jetzt die peer-kommandos für alle 6 Tasten absetzen können
danach einmal anlernen drücken.

sollte das nicht funktionieren wäre es gut, einen Log zu schicken. Dann kann ich nach der Besonderheit des PB6 suchen

Logs wie immer
attr global verbose 1
attr global mseclog 1
attr <hmlan> loglevel 1

dann die peeringprocedur durchführen, logs schicken

betateilchen

#7
Hallo Martin!

Was hat das jetzt mit dem zu tun, was ich vorher geschrieben habe? Nix...

Was verstehst ausgerechnet DU denn daran nicht?

Wozu brauche ich einen virtuellen Aktor mit x-beliebig vielen virtuellen Channels (unter denen sich > 90% aller Anwender ohnehin nix vorstellen können), der ausschließlich seinen Lebenszweck darin hat, ein notify zu triggern, das auf einen event reagiert, den der Taster am virtuellen Aktor auslöst? Das ist doch völlig überflüssig, wenn ich exakt den gleichen Event auch bekomme, wenn ich den Taster mit HMLAN peere. In diesem Fall übernimmt HMLAN die Rolle des Aktors und das funktioniert absolut transparent und 100% zuverlässig. Und man muss keine Gedankenkrämpfe bekommen, weil ein völlig überflüssiger virtueller Aktor dazwischenfunkt, wo es doch einen REALEN Aktor gibt.

Das gesamte Protokollhandling übernimmt dabei der HMLAN autark "nebenbei" und ich muss mich um keinerlei Verzögerungen oder sonstige Problemstellen kümmern.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

martinp876

was ich nicht verstehe, warum man 6mal (mindestens) anlernen drücken muss. das sollte auf einmal funktionieren. Nichts anderes habe ich geschrieben. was verstehst du daran nicht?

ich wusste nicht, dass HMLAN auf tasten-druck reagiert und diesen beantwortet. Alle messages beantwortet HMLAN jedenfalls nicht.
Es ist sache des Users wie er es realisieren will.
Ich selbst habe keinen in Betrieb.
Ob und wie du einfacher denkst wird sich mir sowieso nicht erschließen - das muss auch jeder andere für sich entscheiden.

Hatte ich irgend etwas erwähnt, dass man nicht mit FHEM peeren soll? Das von mir erwähnte Prinzip ändert sich dardurch sowieso nicht - was bist du also schon wieder so pampig?

JoeALLb

Ich kann den Taster nicht am HMLAN anlernen, er nimmt ihn einfach nicht!
Das Anlernen mit den virtuellen Devices hat jetzt funktioniert und ging mit einmaligem Druck auf das anlernen!

Nur... der Status scheint dennoch nicht ausgewertet zu werden, die Lichter leuchten nicht korrekt. Mach ich noch etwas falsch?

Danke für eure Hilfe!!!!
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

martinp876

hi,

starten wir einmal mit einem Schalter. Kannst du die Infos dazu schicken?
- list <aktor-channel>
- list <PB6-channel>

kommt der status in den readings des PB6 an wenn getriggert wird? Beispiel (steht in list)
mal sehen...
Gruss Martin

JoeALLb

Glaub schon...

list wz.Bedienung.virt_Btn3
Internals:
   DEF        12345603
   NAME       wz.Bedienung.virt_Btn3
   NR         287
   STATE      set_press short
   TYPE       CUL_HM
   chanNo     03
   device     wz.Bedienung.virt
   peerList   wz.Bedienung_03,
   Readings:
     2013-10-17 18:46:36   peerList        wz.Bedienung_03,
     2013-10-16 19:31:56   state           set_press short
     2013-10-17 18:00:18   trigLast        wz.Bedienung_03
     2013-10-17 18:00:18   trig_wz.Bedienung_03 -
   Helper:
     Role:
       chn        1
       vrt        1
     Shadowreg:
Attributes:
   expert     1
   model      virtual_6
   peerIDs    20D05603,
   room       CUL_HM
   webCmd     press short:press long



Internals:
   DEF        20D05603
   NAME       wz.Bedienung_03
   NR         165
   STATE      Short (to broadcast)
   TYPE       CUL_HM
   chanNo     03
   device     wz.Bedienung.dev
   peerList   wz.Bedienung.virt_Btn3,
   Readings:
     2013-10-16 20:47:11   R-wz.Bedienung.virt_Btn3-expectAES set_off
     2013-10-16 20:47:11   R-wz.Bedienung.virt_Btn3-peerNeedsBurst set_off
     2013-10-17 18:46:36   peerList        wz.Bedienung.virt_Btn3,
     2013-10-17 18:00:18   state           Short (to broadcast)
     2013-10-17 18:00:18   trigger         Short_2
   Helper:
     Role:
       chn        1
     Shadowreg:
Attributes:
   expert     1
   model      HM-PB-6-WM55
   peerIDs    12345603,
   room       Device,Schalter
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

martinp876

hier solltest du schon einmal einhacken:
     2013-10-16 20:47:11   R-wz.Bedienung.virt_Btn3-expectAES set_off
     2013-10-16 20:47:11   R-wz.Bedienung.virt_Btn3-peerNeedsBurst set_off

"set_" - du hast eine änderung vorbereitet- aber es ist nicht bestätigt, vielleicht noch nicht einmal gesendet.
also einmal getConfig senden und config drücken. Dann noch einmal nachsehen


     2013-10-17 18:46:36   peerList        wz.Bedienung.virt_Btn3,
gut
     2013-10-17 18:00:18   state           Short (to broadcast)
schlecht. es wird nach boadcast gesendet. eigentlich sollte es an einen peer gehen - wird sich auch mit getConfig klären.


betateilchen

Zitat von: martinp876 am 17 Oktober 2013, 18:53:39ich wusste nicht, dass HMLAN auf tasten-druck reagiert und diesen beantwortet.

Eigentlich solltest Du das wissen, seit wir gemeinsam vor einiger Zeit die neue Fernbedienung HM-RC-4-2 in Betrieb genommen haben. Dort habe ich dieses Weg das erste Mal hier im Forum beschrieben. Mit diesem Lösungsweg war ich mit einem Schlag alle Probleme los, über die wir zuvor tagelang gerätselt hatten. Du hast so eine Fernbedienung, probier es doch einfach aus!

Zitat von: martinp876 am 17 Oktober 2013, 18:53:39Es ist sache des Users wie er es realisieren will.

Ja. Aber DU schreibst hier gebetsmühlenartig vor, wie der User DEINER MEINUNG nach dazu vorzugehen hat.

Zitat von: martinp876 am 17 Oktober 2013, 18:53:39Ich selbst habe keinen in Betrieb.

Aber ich.

Zitat von: martinp876 am 17 Oktober 2013, 18:53:39Ob und wie du einfacher denkst wird sich mir sowieso nicht erschließen

Das liegt an einer Art ausgeprägter Betriebsblindheit in Deinem Denken, wenn es um Homematic geht. Und das ist jetzt nicht böse gemeint, diese Betriebsblindheit schleicht sich bei jedem Entwickler ein, der sehr tief in "seiner" Materie drinsteckt.

Zitat von: martinp876 am 17 Oktober 2013, 18:53:39was bist du also schon wieder so pampig?

Das muss Dich noch nicht wundern. Für Dich gibt es doch hier im Forum immer nur zwei Meinungen: DEINE und eine FALSCHE. Das ist nicht zum ersten Mal hier im Forum so. Deine Kompetenz in Sachen Homematic ist unbestritten und wird von niemandem ernsthaft in Frage gestellt. Aber Dir fehlt einfach die Bereitschaft, vielleicht auch einmal darüber nachzudenken, ob sich nicht auch Homematic technisch weiterentwickelt. Für Dich ist immer nur das richtig, was Du "schon immer so" machst.

Deine Lösungswege sind ja nicht falsch, aber überlege doch ab und an auch einmal, ob sie noch zeitgemäß sind. Die Sache mit dem Peeren mit HMLAN - die geht z.B. bei der RC-19 noch nicht, da wird man um den virtuellen Aktor nicht rumkommen. Aber mit neueren Geräten funktioniert das völlig super. Warum soll man dann immer noch den umständlichen Weg über den virutellen Aktor gehen, wenn es inzwischen eine sehr viel einfachere und logischere Lösung gibt?

Nur weil der Martin das so will und nicht bereit ist, über den ihm bekannten (oder in Erinnerung gebliebenen) Tellerrand rauszuschauen? Das ist mir ehrlich gesagt zu wenig Argumentation als Antwort auf die Frage.

DEINER Meinung nach ist ja auch autoReadReg_4 der allheilbringende Rundumschlag - ist Dir eigentlich schon aufgefallen, wieviele neue Probleme Du mit dieser aufgezwungenen Maßnahme inzwischen geschaffen hast - glücklicherweise nicht nur bei  mir, wie den Kommantaren einiger anderer Nutzer zu entnehmen ist! - und mit wieviel Flickwerk Du inzwischen versuchst, das durch aRR4 geschaffene Chaos stückweise wieder gradezuziehen? Wo hast Du denn inzwischen das aRR4 inzwischen schon wieder überall ausgebaut, um Symptome zu beseitigen?

Das ist wie Aspirin: Die Kopfschmerzen gehen kurzfristig (vielleicht) weg, aber die Ursache bleibt unbehandelt. Aber konzeptionell willst Du das auf keinen Fall nicht in Frage stellen - lieber weiterwurschteln und hoffen, dass irgendwann keiner mehr meckert. Das könnte dann aber auch daran liegen, dass Anwender die Hoffnung auf eine korrekte Funktion zwischenzeitlich aufgegeben und sich in ihrem Schicksal ergeben haben...

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

JoeALLb

Sorry Leute, dazu nehme ich keine Stellung.
Ich habe mich jedenfalls über beide eurer Hilfeversuche sehr gefreut.
Schade, dass das peeren mit dem HMLAN für mich nicht funktioniert hat... auch wenn ich nicht genau weiß warum.
Habe ihn mehrmals komplett zurückgesetzt.

Mit Getconfig konnte ich das Problem nicht lösen, die Ausgabe hat sich nicht geändert. Hen virtuellen Taster daher neu erstellt und, siehe da,
das Ergebnis änderte sich! Das mit dem set_ steht aber noch.... muss ich mir dazu gedanken machen?

list wz.Bedienung_03
Internals:
   DEF        20D05603
   NAME       wz.Bedienung_03
   NR         165
   STATE      Short (to wz.Bedienung.virt)
   TYPE       CUL_HM
   chanNo     03
   device     wz.Bedienung.dev
   Readings:
     2013-10-17 19:47:23   R-dblPress      0 s
     2013-10-17 19:47:23   R-longPress     0.4 s
     2013-10-17 19:47:23   R-sign          off
     2013-10-17 19:48:32   R-wz.Bedienung.virt_Btn3-expectAES set_off
     2013-10-17 19:48:32   R-wz.Bedienung.virt_Btn3-peerNeedsBurst set_off
     2013-10-17 20:02:43   state           Short (to wz.Bedienung.virt)
     2013-10-17 20:02:43   trigger         Short_14
   Helper:
     getCfgList all
     getCfgListNo 4
     peerIDsRaw ,00000000
     Role:
       chn        1
     Shadowreg:
Attributes:
   expert     1
   model      HM-PB-6-WM55
   peerIDs    00000000,
   room       Device,Schalter
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270