Aeotec MultiSensor 6 - Model wird nicht erkannt

[KraxelHuber]

Hallo zusammen,

ich habe massive Probleme einen Aeotec Multisensor 6, welcher per USB betrieben wird, korrekt in FHEM anzulernen. Als Gateway nutze ich einen Aeotech Z_Stick. Die Inklusion scheint auch zunächst gut zu funktionieren, allerdings scheinen bei weitem nicht alle Readings in FHEM anzukommen. Selbst das Modell wird nicht erkannt. Da der Sensor USB-betrieben ist, habe ich die Class "Wake up" entfernt. Ein "list buero_multisensor" sieht bei mir wie folgt aus:

Code Auswählen Erweitern

Internals:
   CFGFN
   DEF        dd3c89c7 22
   IODev      ZW_Stick
   NAME       buero_multisensor
   NR         102
   STATE      ???
   TYPE       ZWave
   ZWaveSubDevice no
   homeId     dd3c89c7
   isWakeUp   1
   nodeIdHex  16
   SendStack:
     get:1316038613712501
     get:1316038613852502
     get:1316038613592503
     get:1316038613332504
     get:1316038613702505
     get:13160386135a2506
     get:13160386137a2507
     get:1316038613722508
     get:1316038613002509
     get:131603861330250a
     get:131603861331250b
     get:131603861386250c
     get:131603861384250d
     get:13160386135e250e
     set:13160485010101250f
     set:1316068404015180012510
     get:13160272042511
     get:13160272042512
     get:13160272042513
Attributes:
   IODev      ZW_Stick
   classes    ZWAVEPLUS_INFO VERSION MANUFACTURER_SPECIFIC ASSOCIATION_GRP_INFO ASSOCIATION COLOR_CONTROL ALARM NO_OPERATION SENSOR_BINARY SENSOR_MULTILEVEL CONFIGURATION FIRMWARE_UPDATE_MD DEVICE_RESET_LOCALLY MARK
   room       ZWave

Ich habe das Device jetzt schon mehrfach exkludiert und wieder inkludiert, immer mit demselben Ergebnis. So langsam weiß ich nicht mehr weiter und wäre über jeden Tipp dankbar.

[A.Harrenberg]

Hi,

Du musst nach dem entfernen der WakeUp Klasse Fhem einmal neu starten damit der den Mode wieder neu erkennt. Das Ding ist intern immer noch als "isWakeUp" gekenntzeichnet, alle Befehle liegen auf dem Wartestack, werden aber nicht verarbeitet, da ja keine WakeUp-Notification mehr kommt.

Nach dem Neustart von Fhem sind alle Befehle vom Stack "verschwunden", dh. es kann sein das einige Konfigurationen noch mal neu gemacht werden müssen...

Meiner Meinung nach ist das eine kleine Unschönheit bei den Klassen... Wenn das Ding per USB betrieben wird sollte der mMn die WakeUp besser nicht melden...

Ich überlege mal ob man da keine Sonderbehandlung für das Ding einbauen sollte und wie man soetwas realisieren könnte.

Gruß,
Andreas.

[krikan]

Meiner Meinung nach ist das eine kleine Unschönheit bei den Klassen... Wenn das Ding per USB betrieben wird sollte der mMn die WakeUp besser nicht melden...

Ich überlege mal ob man da keine Sonderbehandlung für das Ding einbauen sollte und wie man soetwas realisieren könnte.

Hallo Andreas!
Bin mir nicht sicher, ob der Sensor nicht korrekterweise immer -egal ob batterie- oder usb-betrieben- die Class WAKE_UP meldet und die eigentliche Info, welche Versorgungsvariante vorliegt, über "get <device> nodeInfo" anzufordern ist. Hast Du Dir dazu schon mal Gedanken gemacht oder sogar Quellen im zwapi gefunden?
Gruß, Christian

[KraxelHuber]

Hi,

Du musst nach dem entfernen der WakeUp Klasse Fhem einmal neu starten damit der den Mode wieder neu erkennt. Das Ding ist intern immer noch als "isWakeUp" gekenntzeichnet, alle Befehle liegen auf dem Wartestack, werden aber nicht verarbeitet, da ja keine WakeUp-Notification mehr kommt.

Nach dem Neustart von Fhem sind alle Befehle vom Stack "verschwunden", dh. es kann sein das einige Konfigurationen noch mal neu gemacht werden müssen....

OK, das leuchtet ein. Nach einem Neustart ist das Feld "isWakeUp" nun leer. Wenn ich nun allerdings versuche mittels

Code Auswählen Erweitern

get buero_multisensor model
das Model abzufragen, kommt die Meldung "Timeout reading answer for model". Mein Verständnis ist, dass ich das Modell benötige, um weitere modellspezifische Einstellungen vorzunehmen, oder?

[rudolfkoenig]

Ja. Und "Timeout reading answer for model" deutet auf Kommunikationsschwierigkeiten hin. Mehr Details stehen im Log, falls man "attr ZW_Stick verbose 5" setzt.

[KraxelHuber]

Ja. Und "Timeout reading answer for model" deutet auf Kommunikationsschwierigkeiten hin. Mehr Details stehen im Log, falls man "attr ZW_Stick verbose 5" setzt.

Das hatte ich auch schon gedacht. Nachdem ich das Attribut dann auf verbose 5 gesetzt und noch einmal das Modell abgefragt hatte, kam tatsächlich eine Antwort. Wieso das jetzt funktioniert hat, ist mir allerdings nicht ganz klar. Mein "list buero_multisensor" sieht jetzt jedenfalls wie folgt aus:

Code Auswählen Erweitern

Internals:
   DEF        dd3c89c7 22
   IODev      ZW_Stick
   LASTInputDev ZW_Stick
   MSGCNT     44
   NAME       buero_multisensor
   NR         61
   STATE      ???
   TYPE       ZWave
   ZW_Stick_MSGCNT 44
   ZW_Stick_RAWMSG 00130a0101aa
   ZW_Stick_TIME 2016-10-24 14:14:57
   ZWaveSubDevice no
   homeId     dd3c89c7
   isWakeUp
   lastMsgSent 1477311292.80633
   nodeIdHex  16
   Readings:
     2016-10-24 13:24:14   CMD             ZW_APPLICATION_UPDATE
     2016-10-24 13:30:16   alarm           HomeSecurity: Tampering - product covering removed, arg 0000
     2016-10-24 12:27:14   basicSet        0
     2016-10-24 13:49:07   battery         100 %
     2016-10-24 13:49:06   humidity        58 %
     2016-10-24 13:49:08   luminance       24 Lux
     2016-10-24 14:14:54   model           Aeotec MultiSensor 6
     2016-10-24 14:14:54   modelConfig     aeotec/multisensor6.xml
     2016-10-24 14:14:54   modelId         0086-0002-0064
     2016-10-24 13:23:56   neighborList    ZW_Stick WZ_Dimmer
     2016-10-24 13:49:05   temperature     19.4 C
     2016-10-24 14:14:57   transmit        NO_ACK
     2016-10-24 13:49:09   ultraviolet     0 UV
Attributes:
   IODev      ZW_Stick
   classes    ZWAVEPLUS_INFO VERSION MANUFACTURER_SPECIFIC ASSOCIATION_GRP_INFO ASSOCIATION COLOR_CONTROL ALARM NO_OPERATION SENSOR_BINARY SENSOR_MULTILEVEL CONFIGURATION FIRMWARE_UPDATE_MD DEVICE_RESET_LOCALLY MARK
   room       ZWave

Ist das mit dem "transmit NO_ACK" eigentlich so wirklich richtig? Oder wie genau habe ich das zu deuten?

Viele Grüße

[rudolfkoenig]

"richtig" ist relativ. Aus meiner (Modulautor) Standpunkt schon, aus Deiner (Benutzer) Sicht nicht, sollte irgendwie (verschieben/Repeater hinzufuegen/usw) behoben werden.

[A.Harrenberg]

Hi Christian,

Bin mir nicht sicher, ob der Sensor nicht korrekterweise immer -egal ob batterie- oder usb-betrieben- die Class WAKE_UP meldet und die eigentliche Info, welche Versorgungsvariante vorliegt, über "get <device> nodeInfo" anzufordern ist. Hast Du Dir dazu schon mal Gedanken gemacht oder sogar Quellen im zwapi gefunden?

ja, laut Spezifikation ist das schon richtig das er das meldet, für "uns" ist da aber unschön, da wir ein Batteriegerät nur an der Klasse festmachen. Ich meine ich hätte mir damals mal das NIF mit Batterie und USB-Strom angeschaut und die waren identisch... Ich hatte damal jedenfalls beschlossen das es keine Möglichkeit gibt zu erkennen ob das Gerät nun WakeUp macht oder nicht...

Sollte man vielleicht noch mal machen um sicher zu gehen.

Gruß,
Andreas.

[krikan]

Mein usb-betriebener liefert auf "get <ZWDongle> nodeInfo" die Rückgabe:

Code Auswählen Erweitern

ProtocolVers:SDK4.5x+6.0x listening routing maxBaud:40kbps SpecificDev RoutingSlave BeamCap OptFunc SpeedExt:100kbps RoleType:N/A BasicDevClass:ROUTING_SLAVE GenericDevClass:SENSOR_MULTILEVEL SpecificDevClass:01
nodeInfo wird mWn aus den Controllerdaten, die bei der Inklusion gespeichert werden, ermittelt.
Wenn bei batteriebetriebenen die nodeInfo sleeping enthaelt, haette man ein Unterscheidungsmerkmal für eine Automatik.

Was ist, wenn man dann die Spannungsversorgung umstellt? Kann man das automatisch ermitteln? Glaube ich fast nicht.
Selbst wenn man die Versorgungsart automatisch ermitteln kann, ist es mir für einen FHEM-Einbau schon fast wieder zu viel Sonderbehandlung. Interessant ist das Thema trotzdem.