Hallo,
ich habe gerade neu begonnen mich mit dem Thema Heimautomatisieurng zu beschäftigen, und nach etwas Überlegung nun mal zum Start einen Aeon Labs Z-Stick (Aeotec AEOEZW090-C) und einen Fibaro Motion Sensor (allerdings wie ich später gesehn habe nicht den neusten, sondern einen älteren, Etikettenaufdruck V2/7 EU) gekauft [um damit später Lampen zu steuern].
Nun habe ich den Sensor in das Netz eingebunden, kann auch Konfigurationswerte ändern und auslesen (Wecke den Sensor dafür manuell auf); aber ... was ich auch mache, irgendwie sendet der Sensor nichts von sich aus/empfängt der Stick nichts unangefragtes ...
Nun ist ja hier mehrfach im Forum das Problem beschrieben worden, dass der Sensor nicht in der Richtigen association Group wie der Stick ist, das sollte aber eigentlich passen. (siehe Unten).
Ich spiele seit >4h an verschiedenen Werten rum, hab ihn auch schon neu eingefügt, den Stick resetet; ich weiss grade wirklich nicht was ich noch machen könnte.
Mach ich irgendwas offensichtlich falsch? Ich müsste die Events (Bewegungen, Tamper, Temperatur/Helligkeit Messwerte) doch unter 'Event Monitor' im Webinterface, 'inform on' in der Telnet-Konsole oder in den Logdateien irgendwie sehen? Anbei die Infos von Stick und Sensor.
fhem> list ZWDongle_1
Internals:
CallbackNr 1
Clients :ZWave:
DEF /dev/ttyACM0@115200
DeviceName /dev/ttyACM0@115200
FD 10
MaxSendRetries 3
NAME ZWDongle_1
NR 29
PARTIAL
ReadTime 1466549119.49352
STATE Initialized
SendRetries 0
SendTime 1466549119.49206
TYPE ZWDongle
WaitForAck 0
homeId [[homeId]]
nodeIdHex 01
nrNAck 0
Matchlist:
1:ZWave .*
Readings:
2016-06-22 00:41:30 caps Vers:1 Rev:0 ManufID:0086 ProductType:0001 ProductID:005a SERIAL_API_GET_INIT_DATA SERIAL_API_APPL_NODE_INFORMATION APPLICATION_COMMAND_HANDLER ZW_GET_CONTROLLER_CAPABILITIES SERIAL_API_SET_TIMEOUTS SERIAL_API_GET_CAPABILITIES SERIAL_API_SOFT_RESET UNKNOWN_09 ZW_SET_R_F_RECEIVE_MODE ZW_SET_SLEEP_MODE ZW_SEND_NODE_INFORMATION ZW_SEND_DATA ZW_SEND_DATA_MULTI ZW_GET_VERSION ZW_SEND_DATA_ABORT ZW_R_F_POWER_LEVEL_SET ZW_SEND_DATA_META ZW_GET_RANDOM MEMORY_GET_ID MEMORY_GET_BYTE MEMORY_PUT_BYTE MEMORY_GET_BUFFER MEMORY_PUT_BUFFER FLASH_AUTO_PROG_SET NVM_GET_ID NVM_EXT_READ_LONG_BUFFER NVM_EXT_WRITE_LONG_BUFFER NVM_EXT_READ_LONG_BYTE NVM_EXT_WRITE_LONG_BYTE ZW_GET_NODE_PROTOCOL_INFO ZW_SET_DEFAULT ZW_REPLICATION_COMMAND_COMPLETE ZW_REPLICATION_SEND_DATA ZW_ASSIGN_RETURN_ROUTE ZW_DELETE_RETURN_ROUTE ZW_REQUEST_NODE_NEIGHBOR_UPDATE ZW_APPLICATION_UPDATE ZW_ADD_NODE_TO_NETWORK ZW_REMOVE_NODE_FROM_NETWORK ZW_CREATE_NEW_PRIMARY ZW_CONTROLLER_CHANGE ZW_SET_LEARN_MODE ZW_ASSIGN_SUC_RETURN_ROUTE ZW_REQUEST_NETWORK_UPDATE ZW_SET_SUC_NODE_ID ZW_DELETE_SUC_RETURN_ROUTE ZW_GET_SUC_NODE_ID ZW_SEND_SUC_ID ZW_EXPLORE_REQUEST_INCLUSION ZW_REQUEST_NODE_INFO ZW_REMOVE_FAILED_NODE_ID ZW_IS_FAILED_NODE ZW_REPLACE_FAILED_NODE UNKNOWN_66 UNKNOWN_67 GET_ROUTING_TABLE_LINE LOCK_ROUTE_RESPONSE UNKNOWN_92 UNKNOWN_93 UNKNOWN_98 ZW_SET_WUT_TIMEOUT ZW_WATCHDOG_ENABLE ZW_WATCHDOG_DISABLE ZW_WATCHDOG_CHECK ZW_SET_EXT_INT_LEVEL ZW_RF_POWERLEVEL_GET ZW_TYPE_LIBRARY ZW_SEND_TEST_FRAME ZW_GET_PROTOCOL_STATUS WATCHDOG_START WATCHDOG_STOP UNKNOWN_d4 UNKNOWN_ee UNKNOWN_ef
2016-06-22 00:41:30 ctrlCaps PRIMARY
2016-06-22 00:41:30 homeId HomeId:[[homeId]] CtrlNodeIdHex:01
2016-06-21 22:54:34 nodeList ZWDongle_1 ZWave_SENSOR_BINARY_2
2016-06-22 00:41:30 random [[random]]
2016-06-22 00:41:30 state Initialized
2016-06-22 00:41:30 sucNodeId no
SendStack:
Attributes:
networkKey [[networkKey]]
verbose 5
fhem> list ZWave_SENSOR_BINARY_2
Internals:
DEF [[homeId]] 2
IODev ZWDongle_1
LASTInputDev ZWDongle_1
MSGCNT 33
NAME ZWave_SENSOR_BINARY_2
NR 30
STATE associationAdd 3 1
TYPE ZWave
ZWDongle_1_MSGCNT 33
ZWDongle_1_RAWMSG 0004000206850303010001
ZWDongle_1_TIME 2016-06-22 00:47:57
homeId [[homeId]]
isWakeUp 1
lastMsgSent 1466549277.50217
nodeIdHex 02
timeToAck 2.124
Readings:
2016-06-22 00:47:55 CMD ZW_APPLICATION_UPDATE
2016-06-22 00:47:57 assocGroup_1 Max 5 Nodes ZWDongle_1
2016-06-22 00:47:57 assocGroup_2 Max 5 Nodes ZWDongle_1
2016-06-22 00:47:57 assocGroup_3 Max 1 Nodes ZWDongle_1
2016-06-22 00:47:55 assocGroups 3
2016-06-21 23:50:39 basicReport 00
2016-06-22 00:47:55 configAmbientIlluminationLevelAbove83 1000
2016-06-22 00:47:55 configAmbientIlluminationLevelBelow82 100
2016-06-22 00:47:55 configBASICOFFCommandFrameValue 0
2016-06-22 00:47:55 configBASICONCommandFrameValue 255
2016-06-22 00:47:56 configBasicCommandClassFrames12 BASICONAndBASICOFFCommandFrames0
2016-06-22 00:47:56 configIlluminationReportThreshold 5
2016-06-22 00:47:56 configIlluminationReportsInterval 600
2016-06-22 00:47:56 configIntervalOfTemperatureMeasuring 900
2016-06-22 00:47:56 configLEDBrightness 50
2016-06-22 00:47:56 configLEDIndicatingTamperAlarm LEDIndicatesTamperAlarm
2016-06-22 00:47:56 configLEDSignalingMode LongBlinkThenShortBlinkLEDColour10
2016-06-22 00:47:56 configMaximumTemperatureResultingInRed87 28
2016-06-22 00:47:56 configMinimumTemperatureResultingIn86 18
2016-06-22 00:47:56 configMotionAlarmCancellationDelay 30
2016-06-22 00:47:56 configMotionSensorSBlindTime2 15
2016-06-22 00:47:56 configMotionSensorSSensitivity 10
2016-06-22 00:47:56 configNightDay 200
2016-06-22 00:47:56 configPIRSensorOperatingMode PIRSensorAlwaysActive
2016-06-22 00:47:56 configPIRSensorSPulseCounter 2Pulses
2016-06-22 00:47:56 configPIRSensorSWindowTime 12Seconds
2016-06-22 00:47:56 configTamperAlarmBroadcastMode TamperAlarmSentInBroadcastMode
2016-06-22 00:47:56 configTamperAlarmCancellationDelay 30
2016-06-22 00:47:56 configTamperOperatingModes Tamper
2016-06-22 00:47:56 configTamperSensitivity 15
2016-06-22 00:47:56 configTemperatureOffset 600
2016-06-22 00:47:56 configTemperatureReportThreshold 1
2016-06-22 00:47:56 configTemperatureReportsInterval 600
2016-06-21 22:54:27 model FIBARO System FGMS001 Motion Sensor
2016-06-21 22:54:27 modelConfig fibaro/fgms.xml
2016-06-21 22:54:27 modelId 010f-0800-1001
2016-06-21 22:54:27 state associationAdd 3 1
2016-06-22 00:47:59 transmit OK
2016-06-21 23:40:44 version Lib 3 Prot 3.67 App 2.7 HW 1 FWCounter 1 FW 2.7
2016-06-22 00:47:57 wakeupReport interval 600 target 1
Attributes:
IODev ZWDongle_1
classes SENSOR_BINARY WAKE_UP ASSOCIATION BATTERY MULTI_CMD CRC_16_ENCAP MANUFACTURER_SPECIFIC VERSION CONFIGURATION MULTI_CHANNEL_ASSOCIATION SENSOR_MULTILEVEL SENSOR_ALARM BASIC
room ZWave
vclasses ASSOCIATION:2 BASIC:1 BATTERY:1 CONFIGURATION:1 CRC_16_ENCAP:1 MANUFACTURER_SPECIFIC:1 MULTI_CHANNEL_ASSOCIATION:2 MULTI_CMD:1 SENSOR_ALARM:1 SENSOR_BINARY:1 SENSOR_MULTILEVEL:5 VERSION:2 WAKE_UP:1
Ich wäre für jeden Hinweis dankbar ...
Vielen Dank,
Viele Grüße
Christian
Ich kenne das Geraet nicht in Detail, von deinen Daten her vermute ich aber entweder ein Konfigurationsproblem (dh. config*) oder Geraet defekt.
Um ein (in diesem Fall unwahrscheinliches) FHEM Problem auszuschliessen, wuerde ich "attr ZWDongle_0 verbose 5" setzen, und schauen, ob im Log was auftaucht. wakeUpNotification sollte alle 10 Minuten erscheinen.
Hallo Chris,
ich kenne den Stick nicht, dafür aber den Sensor. Aber für mich sieht alles gut aus, inclusion, assocGroup3, etc. Verbose 5 auf dem Dongle hast du ja schon gesetzt und das Report und wakeUp Intervall entsprechend angepasst. Eigentlich sollte bei jeder 0.1° Temperaturänderung was sichtbar sein.
Was mich beim Controller total verunsichert ist, dass du dieses reading hast:
2016-06-22 00:41:30 sucNodeId no
Meines Erachtens nach sollte da auch eine 1, also die ControllerID stehen. Versuch mal ein "set sucNodeID 1". Vielleicht hilft das.
Im Vergleich zu meinem Razberry Controller gibt es noch andere Unterschiede, dass mag aber durchaus normal sein.
Im Prinzip ist ein Controller und ein batteriebetriebenes Device noch kein richtiges ZWave Netzwerk. Ich hätte da vielleicht eher mit einem Aktor angefangen. Da wäre die Funktionalität ZWave/FHEM sofort Testbar gewesen.
Bin neugierig was wirklich das Problem ist.
Grüße, Josef
Zitat von: jeep am 22 Juni 2016, 12:14:26
Aber jetzt was mich beim Controller total verunsichert ist, dass du diese reading hast
2016-06-22 00:41:30 sucNodeId no
Meines Erachtens nach sollte da auch eine 1, also die ControllerID stehen.
Dass der SUC nicht aktiviert ist, ist in Ordnung und dürfte nicht mit dem Problem zusammenhängen. UZB1 und Razberry aktivieren den SUC, anders als andere Controller, im Standard.
Gruß, Christian
Hallo,
vielen Dank für die schnellen Antworten!
Ich weiss zwar nicht, was das Problem war, konnte es nun aber Beheben: rudolfkoenig's Hinweis auf möglicherweise defekte Hardware rief mir in Erinnerung, dass ich zwar den Stick resettet hatte, und den Sensor mehrfach Ex- & Inkludiert hatte, aber nie den Sensor an sich zurückgesetzt hatte.
Nach einem Reset des Sensors funktionierte nun alles auf Anhieb! Dachte Ex- & Inkludieren wäre fast soetwas wie ein Reset für den Sensor, aber das hat wohl nicht gereicht.
Vielleicht hilft die Info ja später noch jemandem. Schade dass ich nicht drauf gekommen bin bevor ich hier den Thread schrieb ...
Vielen Dank, viele Grüße
Christian
Zitat von: krikan am 22 Juni 2016, 12:22:06
Dass der SUC nicht aktiviert ist, ist in Ordnung und dürfte nicht mit dem Problem zusammenhängen.
Gruß, Christian
Ja, so was ähnliches hab ich mir schon gedacht, aber den SUC sollte er doch trotzdem aktivieren, sonst ist das Netz nicht selbstheilend, was z.Z. ohne Routing Devices noch irrelevant ist. Empfohlen wird es alle mal. Aber schön das alles funktioniert.
Grüße, Josef
Zitat von: jeep am 22 Juni 2016, 19:36:48
Ja, so was ähnliches hab ich mir schon gedacht, aber den SUC sollte er doch trotzdem aktivieren, sonst ist das Netz nicht selbstheilend, was z.Z. ohne Routing Devices noch irrelevant ist. Empfohlen wird es alle mal.
Hallo Josef!
Hast Du die Empfehlung aus Paetz?
Ich widerspreche Dir ein wenig. Selbstheilung wird auch durch Explorer Frames erreicht. Voraussetzung ist allerdings, dass Controller und Endgeräte Explorer Frames können. Der SUC ist das Selbstheilungskonzept aus dem älteren SDK 5.
Wann der SUC bei Explorer Frames fähigen Geräten überhaupt noch zum Einsatz kommt, ist mir unklar. Ich könnte in 2 Wochen Experimenten keine SUC Nachrichten loggen. Theorie: SUC kommt nur noch in Verbindung mit SDK 5 Geräten, die ich nicht habe, zum Einsatz.
Nach meiner Erinnerung schreibt Paetz den Explorer Frames auch größere Selbstheilungskräfte zu.
Momentan sehe ich keine Notwendigkeit den aktiven SUC für FHEM als wichtig/sinnvoll zu deklarieren. Zudem setzt das auch ein aktives Setzen der Geräterouten voraus (sucRouteAdd). Also auch noch umständlich bei kaum noch vorhandener Bedeutung von SDK 5.
Lasse mich aber gerne vom Gegenteil überzeugen.
Gruß, Christian
Hallo Christian,
Danke für die Hinweise. Vermutlich sind meine Informationen veraltet, wie das SDK 5. Bestimmt stammt meine Info von vor 1 Jahr als ich mit ZWave angefangen habe. Da hatte ich 2 Düwi Zwischenstecker und bin mir fast sicher das die keine Explorer Frames konnten. Beim googeln bin ich noch über dieses gestolpert, könnte aber auch veraltet sein.
https://github.com/cdjackson/HABmin/wiki/ZWave-SUC-Controller-Mode
Grüße, Josef
Hallo Josef!
Ja, die Original-DÜWI nutzen SDK 5.
Bei Mischung von SDK 5 und SDK 4.5, 6.x hat der SUC vermutlich einen Nutzen mit großem Aufwand.
Der openhab Artikel berücksichtigt Explorer Frames und Network Wide Inklusion nicht, die mMn ein teilweiser Ersatz von SUC und SIS sind. Daher gehe ich davon aus, dass das nicht aktuell ist.
Aber vielleicht ändere ich meine Theorie auch noch einmal mit neuen Erkenntnissen...
Gruß, Christian