Z-Wave Multichannel Problem

[krikan]

Also meiner Meinung nach (unter Berücksichtigung auch von Geräten mit dynamischen Endpoints) zu ändern:

Code Auswählen Erweitern

$cmdFmt = "0d01$ch$cmdId$cmdFmt";
ersetzen durch

Code Auswählen Erweitern

$cmdFmt = "0d00$ch$cmdId$cmdFmt";
$ch sollte im Bit 7 nie 1 sein, da damit nicht ein einzelner Endpoint 0-127, sondern über eine Bitmaske die gleichzeitige Abfrage mehrerer Endpoints 1-7 ohne Antwortpflicht des Gerätes angesprochen wird.

Beispiel:
Bei meinem einzigen Gerät mit dynamischen Endpoints wird derzeit für den Endpoint 3 die Nachricht mit $ch=83 verschickt (= gleichzeitige Abfrage Endpoints 1 und 2) und das Gerät antwortet teilweise zwapi-konform nicht und FHEM meldet timeout bzw. antwortet auf den Endpoints 1 und 2. Setze ich das richtig auf $ch=03 (=Abfrage Endpoint 3), dann antwortet wie erwartet der Endpoint 3.

Code Auswählen Erweitern

$ep = ($1 ne "00" ? $1 : $2);
ersetzen durch

Code Auswählen Erweitern

$ep=$1
$2 ist der Destination-Endpoint und der sollte für den Controller/FHEM immer uninteressant sein. Mir fällt zumindest kein gegenteiliger Fall ein.
Bit 7 in $ep darf nie als 1 übernommen werden, da die Zuordnung des Endpoints bei dynamischen Endpoints erschwert wird. Passt zu zwapi, wonach Bit 7 ein reservierter Wert ist, der ignoriert werden soll.

Bit 7 bei MULTI_CHANNEL-Nachrichten führt zum anderen Problem der "falschen" Anlage von dynamischen Endpoint-Devices für meinen Test-Aktor durch FHEM:
FHEM legt per autocreate automatisch den dynamischen Endpoint 3 als  "ZWave_.*.131" mit entsprechendem DEF an. Damit die Zuordnung der Nachrichten zu den Endpoints passt, sollte mMn das Bit7, das einen dynamischen Endpoint signalisiert, durch autocreate ignoriert werden und das Device als "ZWave_.*.3" mit entsprechendem DEF angelegt werden. Wenn das gemacht würde, ist nach meinem Gedankengang die Bit7-Problematik in der 1. Codeänderung $ch automatisch hinfällig.

Hoffe, dass ist verständlich.

Bei meinem Test-Gerät mit einem dyn. Endpoint reichen die vorgeschlagenen Änderungen in FHEM aus. Problematisch wird es bei Geräten, die mehrere dynamische Endpoints haben und die Nummer des Endpoints sich nach Entfernen und neuem Hinzufügen automatisch ändern kann. In diesen Fällen müssten wohl FHEM-Devices bei der Entfernen-Funknachricht automatisch gelöscht werden. Das müsste man derzeit über notify/DOIF lösen. Praktische Relevanz=?

[krikan]

@Rudi: Achtung, habe im letzten Post editiert, da ich mMn destination und source verdreht hatte.

[rudolfkoenig]

Habs geaendert, die Erste genau, wie du es vorgeschlagen hast, die Zweite ist:

Code Auswählen Erweitern

$ep = sprintf("%02x", hex($1) & 0x7f); # Forum #50176
damit Bit-7 ignoriert wird.

Kann leider nicht einchecken, sourceforge bockt.

[krikan]

Code Auswählen Erweitern

$ep = sprintf("%02x", hex($1) & 0x7f); # Forum #50176


Danke. Dann hätte ich Dir auch meinen Patch geben können; habe das genauso gemacht. Jedoch dachte ich die sprintf/hex-Variante ist viel zu umständlich und es gibt etwas viel kürzeres für die simple Bitoperation, das ich nur nicht finde.

Kannst/Hast Du auch in ZWave_mcCapability($$) $chid analog angepasst, damit autocreate die korrekte Endpoint-Nummer für DEF und Device-Name bekommt?

[rudolfkoenig]

Habs jetzt eingecheckt,  ZWave_mcCapability auch geaendert, danke fuer den Hinweis.

[krikan]

Danke zurück. Laeuft. 

[scooty]

Hallo zusammen,

ich hoffe, hier bin ich richtig, da hier wohl die letzte Änderung der 10_ZWave.pm besprochen wird.

Mit der neuesten Version von 10_Zwave.pm funktioniert mein ZWave.me WALLC-S Wandschalter nicht mehr.
Bei Tastendruck werden nur im Hauptdevice Events á la

Code Auswählen Erweitern

basicSet 255
bzw.

Code Auswählen Erweitern

basicSet 0
(oder entsprechende swmBegin../swmEnd) erzeugt.
Bei den endpointChildren erscheinen keine Events mehr.

Habe jetzt nicht wirklich die in diesem Thread beschriebenen Änderungen verstanden, aber mit der Vorversion

Code Auswählen Erweitern

10_ZWave.pm 12583 2016-11-15 14:46:43Z rudolfkoenig
werden die Events in den endpointChildren erzeugt.

Muss ich ggf. etwas umstellen (oder gerne noch weitere Infos liefern)?

Viele Grüße ,
Andreas

[krikan]

Hallo Andreas!
Denke Du bist richtig. 
Hast Du über MULTI_CHANNEL_ASSOCIATION assoziiert (das habe ich naemlich nicht analysiert)?
Kannst Du bitte die raw-Logs (verbose 5) der betroffenen Nachrichten mit Erlaeuterung der Tastendruecke zeigen?
Würde es mir dann anschauen. Danke.
Gruß, Christian

edit: Zur Sicherheit bitte auch Ausgaben von "list <device>"

[scooty]

Hallo Christian,

danke für die schnelle Reaktion.
Ja, meinem Verständnis nach ist der ZWave.me WALLC-Süber MULTI_CHANNEL_ASSOCIATION assoziiert (parent und child-Nodes sind angelegt).

Hier erst einmal das list des endpointParent-Devices:

Code Auswählen Erweitern

Internals:
   DEF        d79c8805 46
   IODev      ZW_Dongle
   LASTInputDev ZW_Dongle
   MSGCNT     8
   NAME       WZOG_ZB
   NR         418
   STATE      OK
   TYPE       ZWave
   ZW_Dongle_MSGCNT 8
   ZW_Dongle_RAWMSG 0004002e03800364
   ZW_Dongle_TIME 2016-11-19 09:11:54
   ZWaveSubDevice no
   endpointChildren WZOG_ZB_Links,WZOG_ZB_Rechts,WZOG_ZB_LinksDoppel,WZOG_ZB_RechtsDoppel
   homeId     d79c8805
   isWakeUp   1
   lastMsgSent 1479543116.37936
   nodeIdHex  2e
   Readings:
     2016-11-19 09:11:54   CMD             ZW_APPLICATION_UPDATE
     2016-01-02 10:34:18   assocGroup_1    Max 10 Nodes ZW_Dongle
     2016-01-02 10:34:18   assocGroup_2    Max 10 Nodes
     2016-01-02 10:34:19   assocGroup_3    Max 10 Nodes
     2016-01-02 10:34:19   assocGroup_4    Max 10 Nodes
     2016-01-02 10:34:19   assocGroup_5    Max 10 Nodes
     2016-01-02 10:34:18   assocGroups     5
     2016-11-19 08:42:56   basicSet        255
     2016-11-19 09:11:54   battery         100 %
     2016-11-19 08:32:15   configBlocksWakeupEvenWhenWakeup25 WakeupIsPossibleIfConfigured1
     2016-11-19 08:32:16   configButton1And3PairMode InPairWithDoubleClicks
     2016-11-19 08:32:16   configButton2And4PairMode InPairWithDoubleClicks
     2016-11-19 08:32:17   configCommandToControlGroupA SwitchOnOffAndDimSendBasicSetAnd1
     2016-11-19 08:32:17   configCommandToControlGroupB SwitchOnOffAndDimSendBasicSetAnd1
     2016-11-19 08:32:17   configCommandToControlGroupC SwitchOnOffAndDimSendBasicSetAnd1
     2016-11-19 08:32:17   configCommandToControlGroupD SwitchOnOffAndDimSendBasicSetAnd1
     2016-11-19 08:32:17   configInvertButtons NoDefault
     2016-01-02 09:56:39   configLEDConfirmationMode NoConfirmations
     2016-01-02 09:56:39   configModesForButton2And4 InPairWithDoubleClicks
     2016-11-19 08:32:17   configSendTheFollowingSwitchAll21 SwitchOffOnlyDefault
     2016-11-19 08:32:17   configSendUnsolicitedBatteryReportOn30 ToSameNodeAsWakeUpNotification1
     2016-01-02 10:04:10   configTypicalClickTimeout 0
     2016-01-02 10:44:42   mcaSupportedGroupings 5
     2015-11-18 21:41:26   mca_02          max:0a param:00000101
     2016-01-02 10:46:43   mca_03          max:0a param:00000102
     2016-01-02 10:47:06   mca_04          max:0a param:00000103
     2016-01-02 10:47:32   mca_05          max:0a param:00000104
     2016-01-02 10:06:04   model           Z-Wave.Me ZME_WALLC-S Secure Wall Controller
     2016-01-02 10:06:04   modelConfig     zwave.me/ZME_WALLC-S.xml
     2016-01-02 10:06:04   modelId         0115-0100-0101
     2016-08-18 12:30:07   neighborList    empty
     2016-11-19 08:17:08   reportedState   swmEnd
     2016-11-19 08:17:08   state           swmEnd
     2016-11-19 09:11:56   timeToAck       0.088
     2016-11-19 09:11:56   transmit        OK
     2016-11-19 09:11:54   wakeup          notification
     2016-11-19 08:36:52   wakeupReport    interval 86400 target 1
Attributes:
   IODev      ZW_Dongle
   classes    ZWAVEPLUS_INFO MULTI_CMD POWERLEVEL SECURITY VERSION MANUFACTURER_SPECIFIC CONFIGURATION ASSOCIATION SCENE_CONTROLLER_CONF MULTI_CHANNEL_ASSOCIATION BATTERY WAKE_UP DEVICE_RESET_LOCALLY ASSOCIATION_GRP_INFO CENTRAL_SCENE MARK BASIC CENTRAL_SCENE SWITCH_MULTILEVEL SWITCH_ALL SCENE_ACTIVATION MULTI_CHANNEL
   group      OG
   icon       taster_ch_v@green
   neighborListPos 755.6488364949042,1274.1900342896101
   room       WZOG,ZWave
   stateFormat transmit
   webCmd     :
list des endpointParent-Devices:

Code Auswählen Erweitern

Internals:
   DEF        d79c8805 11777
   IODev      ZW_Dongle
   LASTInputDev ZW_Dongle
   MSGCNT     19
   NAME       WZOG_ZB_Links
   NR         419
   STATE      0
   TYPE       ZWave
   ZW_Dongle_MSGCNT 19
   ZW_Dongle_RAWMSG 0004002e06600d00012605
   ZW_Dongle_TIME 2016-11-19 10:54:32
   ZWaveSubDevice yes
   endpointParent WZOG_ZB
   homeId     d79c8805
   isWakeUp
   nodeIdHex  2e01
   Readings:
     2016-11-19 10:54:16   basicSet        0
     2016-11-19 10:54:32   reportedState   swmEnd
     2016-11-19 10:54:32   state           swmEnd
Attributes:
   IODev      ZW_Dongle
   eventMap   basicSet..255:UpShort basicSet..0:DownShort swmBeginUp:UpLong swmBeginDown:DownLong swmEnd:StopLong
   group      OG
   room       WZOG,ZWave
   stateFormat basicSet
Nun ein verbose 5 Log (mit 10_ZWave.pm 12583 2016-11-15 14:46:43):
Tastenabfolge (na ja, so ungefähr):
Linker Taster einfach hoch / 5 sec warten /
Linker Taster einfach runter / 5 sec warten /
Linker Taster lang hoch (2 sec) / 5 sec warten /
Linker Taster lang runter (2 sec) / 5 sec warten

Code Auswählen Erweitern

2016.11.19 11:02:31.639 4: ZWDongle_Read ZW_Dongle: rcvd 0004002e07600d00012001ff (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.19 11:02:31.640 5: SW: 06
2016.11.19 11:02:31.642 5: ZW_Dongle dispatch 0004002e07600d00012001ff
2016.11.19 11:02:31.644 4: CMD:APPLICATION_COMMAND_HANDLER ID:2e ARG:07600d00012001ff CB:00
2016.11.19 11:02:39.536 4: ZWDongle_Read ZW_Dongle: rcvd 0004002e07600d0001200100 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.19 11:02:39.537 5: SW: 06
2016.11.19 11:02:39.539 5: ZW_Dongle dispatch 0004002e07600d0001200100
2016.11.19 11:02:39.540 4: CMD:APPLICATION_COMMAND_HANDLER ID:2e ARG:07600d0001200100 CB:00
2016.11.19 11:02:46.946 4: ZWDongle_Read ZW_Dongle: rcvd 0004002e08600d000126042000 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.19 11:02:46.947 5: SW: 06
2016.11.19 11:02:46.948 5: ZW_Dongle dispatch 0004002e08600d000126042000
2016.11.19 11:02:46.949 4: CMD:APPLICATION_COMMAND_HANDLER ID:2e ARG:08600d000126042000 CB:00
2016.11.19 11:02:49.104 4: ZWDongle_Read ZW_Dongle: rcvd 0004002e06600d00012605 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.19 11:02:49.105 5: SW: 06
2016.11.19 11:02:49.106 5: ZW_Dongle dispatch 0004002e06600d00012605
2016.11.19 11:02:49.107 4: CMD:APPLICATION_COMMAND_HANDLER ID:2e ARG:06600d00012605 CB:00
2016.11.19 11:02:56.162 4: ZWDongle_Read ZW_Dongle: rcvd 0004002e08600d000126046000 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.19 11:02:56.163 5: SW: 06
2016.11.19 11:02:56.164 5: ZW_Dongle dispatch 0004002e08600d000126046000
2016.11.19 11:02:56.165 4: CMD:APPLICATION_COMMAND_HANDLER ID:2e ARG:08600d000126046000 CB:00
2016.11.19 11:02:58.731 4: ZWDongle_Read ZW_Dongle: rcvd 0004002e06600d00012605 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.19 11:02:58.732 5: SW: 06
2016.11.19 11:02:58.734 5: ZW_Dongle dispatch 0004002e06600d00012605
2016.11.19 11:02:58.735 4: CMD:APPLICATION_COMMAND_HANDLER ID:2e ARG:06600d00012605 CB:00

Hoffe, alles relevante erwischt zu haben, falls nicht oder weitere Infos gewünscht sind, lass es mich bitte wissen.

Vielen Dank für Deine Unterstützung,
Andreas

[krikan]

Hallo Andreas!

Kannst Du bitte von einem anderen Taster noch ein raw-Telegramm posten. Hätte ich noch gerne zum Weiterdenken.

Grundsätzlich ist mir das Problem schon klar. Rudis ursprünglicher Code im alten 10_ZWave.pm:

Code Auswählen Erweitern

$ep = ($1 ne "00" ? $1 : $2);
sorgte in diesem Fall für die Zuordnung zum "korrekten" Endpointdevice. Jetzt erkenne ich den Grund des Codes. Der ist aber aufgrund meines Vorschlages herausgeflogen (ich wars  )
Aber ich begreife nicht, warum der Taster den Tastendruck nicht mit seinen Endpoint (01) als Quelle angibt, sondern mit seinem Hauptdevice (00) und als Ziel einen (nicht vorhandenen?) Endpoint (01) des Controllers. Lese noch einmal nach.
Müsste mir auch MULTI_CANNEL_ASSOCIATION mal  in zwapi durchlesen, testen und grübeln.
Das dauert alles noch ein wenig.

Gruß, Christian

[scooty]

Kannst Du bitte von einem anderen Taster noch ein raw-Telegramm posten.

Hallo Christian,

hoffe, ich habe Dich jetzt richtig verstanden.
Anbei das "verbose 5"-Log mit der gleichen Tastenabfolge wie oben für den rechten Taster des ZWave.me WALLC-S:

Code Auswählen Erweitern

2016.11.19 16:21:10.946 4: ZWDongle_Read ZW_Dongle: rcvd 000400280631050122005b (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.19 16:21:10.947 5: SW: 06
2016.11.19 16:21:10.949 5: ZW_Dongle dispatch 000400280631050122005b
2016.11.19 16:21:10.950 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:0631050122005b CB:00
2016.11.19 16:21:15.125 4: ZWDongle_Read ZW_Dongle: rcvd 0004002e07600d00022001ff (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.19 16:21:15.125 5: SW: 06
2016.11.19 16:21:15.127 5: ZW_Dongle dispatch 0004002e07600d00022001ff
2016.11.19 16:21:15.128 4: CMD:APPLICATION_COMMAND_HANDLER ID:2e ARG:07600d00022001ff CB:00
2016.11.19 16:21:22.231 4: ZWDongle_Read ZW_Dongle: rcvd 0004002e07600d0002200100 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.19 16:21:22.232 5: SW: 06
2016.11.19 16:21:22.235 5: ZW_Dongle dispatch 0004002e07600d0002200100
2016.11.19 16:21:22.236 4: CMD:APPLICATION_COMMAND_HANDLER ID:2e ARG:07600d0002200100 CB:00
2016.11.19 16:21:29.886 4: ZWDongle_Read ZW_Dongle: rcvd 0004002e08600d000226042000 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.19 16:21:29.886 5: SW: 06
2016.11.19 16:21:29.888 5: ZW_Dongle dispatch 0004002e08600d000226042000
2016.11.19 16:21:29.889 4: CMD:APPLICATION_COMMAND_HANDLER ID:2e ARG:08600d000226042000 CB:00
2016.11.19 16:21:31.895 4: ZWDongle_Read ZW_Dongle: rcvd 0004002e06600d00022605 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.19 16:21:31.896 5: SW: 06
2016.11.19 16:21:31.898 5: ZW_Dongle dispatch 0004002e06600d00022605
2016.11.19 16:21:31.900 4: CMD:APPLICATION_COMMAND_HANDLER ID:2e ARG:06600d00022605 CB:00
2016.11.19 16:21:39.459 4: ZWDongle_Read ZW_Dongle: rcvd 0004002e08600d000226046000 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.19 16:21:39.460 5: SW: 06
2016.11.19 16:21:39.461 5: ZW_Dongle dispatch 0004002e08600d000226046000
2016.11.19 16:21:39.462 4: CMD:APPLICATION_COMMAND_HANDLER ID:2e ARG:08600d000226046000 CB:00
2016.11.19 16:21:41.357 4: ZWDongle_Read ZW_Dongle: rcvd 0004002e06600d00022605 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.19 16:21:41.358 5: SW: 06
2016.11.19 16:21:41.362 5: ZW_Dongle dispatch 0004002e06600d00022605
2016.11.19 16:21:41.364 4: CMD:APPLICATION_COMMAND_HANDLER ID:2e ARG:06600d00022605 CB:00


Viele Grüße,
Andreas

[krikan]

Danke Andreas, das meinte ich. Passt.

Rudi, anhaengend ein (ungetesteter) Mini-Patch, der "Deine" if-Bedingung bei $ep wieder einbaut:

Bei mcaAdd gibt sich der Controller mMn als Node mit einem Endpoint aus und assoziiert das mit der NodeId und nicht einem Endpoint des Geraetes. Darum verschickt das Geraet von root=00 eine Nachricht an Endpoint des Controllers > 0. Das war dann der Grund Deines schon richtigen Codes.

Was ich nicht herausgefunden habe: Wie assoziert man einen Endpoint mit einem Endpoint?

edit: Patch gelöscht, da in nachfolgendem Patch enthalten

[krikan]

Die Auswertung von "get <device> mca" hat wohl durch die Hex- auf Dezimalkonvertierung etwas "gelitten"und Interpretation ist für mich teilweise schwierig.

Bei langen Antwort-Telegrammen kommt eine Warnung:

Code Auswählen Erweitern

2016.11.19 15:44:17.019 4: CMD:APPLICATION_COMMAND_HANDLER ID:2a ARG:0a8e03030a000301000103 CB:00
2016.11.19 15:44:17.020 1: PERL WARNING: Hexadecimal number > 0xffffffff non-portable at (eval 5267) line 1.
2016.11.19 15:44:17.020 1: stacktrace:
2016.11.19 15:44:17.020 1:     main::__ANON__                      called by (eval 5267) (1)
2016.11.19 15:44:17.020 1:     (eval)                              called by ./FHEM/10_ZWave.pm (4446)
2016.11.19 15:44:17.021 1:     main::ZWave_Parse                   called by fhem.pl (3425)
2016.11.19 15:44:17.021 1:     main::Dispatch                      called by ./FHEM/00_ZWDongle.pm (891)
2016.11.19 15:44:17.021 1:     main::ZWDongle_Parse                called by ./FHEM/00_ZWDongle.pm (788)
2016.11.19 15:44:17.021 1:     main::ZWDongle_Read                 called by fhem.pl (3264)
2016.11.19 15:44:17.021 1:     main::CallFn                        called by fhem.pl (672)

[krikan]

Anliegender Patch behebt die Warnung und ergibt eine einfacher zu interpretierendes Reading/Event angelehnt an Ergebnis von "get <device> association".
Sicherlich noch verbesserungsfaehig.

[krikan]

Die Zuordnung der Nachrichten zu den FHEM-Devices mit der if-Variante loest bei mir ein (leichtes) Störgefühl aus, obwohl ich den Rückdrehpatch geliefert habe.

Rein aus Praktikabiliaetsgründen verdrehen wir die Angaben zum Absender/Empfaenger der Nachrichten. In den meisten Faellen wird es vermutlich nicht stören bzw. auffallen (A.Harrenberg war mMn der Erste, der darüber gestolpert ist), weil man es nur in den Roh-Nachrichten erkennt. Eigentlich müssten aber die tatsaechlichen Angaben zu Ziel und Quelle der Nachricht irgendwie auswertbar sein.

Mir fallen leider nur umstaendliche Konstrukte mit neuen Attributen oder unnoetigen Verlaengerungen der Events ein, so dass ich if-Variante für ertraeglich halte. Evtl. habt ihr noch andere Ideen.