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:
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.
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.
Zitat von: A.Harrenberg am 23 Oktober 2016, 22:28:50
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
Zitat von: A.Harrenberg am 23 Oktober 2016, 22:28:50
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
get buero_multisensor modeldas 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?
Ja. Und "Timeout reading answer for model" deutet auf Kommunikationsschwierigkeiten hin. Mehr Details stehen im Log, falls man "attr ZW_Stick verbose 5" setzt.
Zitat von: rudolfkoenig am 24 Oktober 2016, 13:42:01
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:
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
"richtig" ist relativ. Aus meiner (Modulautor) Standpunkt schon, aus Deiner (Benutzer) Sicht nicht, sollte irgendwie (verschieben/Repeater hinzufuegen/usw) behoben werden.
Hi Christian,
Zitat von: krikan am 24 Oktober 2016, 08:15:02
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.
Mein usb-betriebener liefert auf "get <ZWDongle> nodeInfo" die Rückgabe:
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. :)