FHEM Forum

Hallo allerseits,

seit dem eben getätigten Update kann ich keine Configs mehr lesen:
2015.11.08 14:30:08 2: ZWave get ID007_SW_KINO_AMBIENTE configALARMFLASHINGAlarmTime
2015.11.08 14:30:11 1: configALARMFLASHINGAlarmTime: Timeout reading answer for get configALARMFLASHINGAlarmTime
2015.11.08 14:30:11 2: ZWave get ID007_SW_KINO_AMBIENTE configAutoOffForRelay1
2015.11.08 14:30:14 1: configAutoOffForRelay1: Timeout reading answer for get configAutoOffForRelay1
2015.11.08 14:30:14 2: ZWave get ID007_SW_KINO_AMBIENTE configAutoOffForRelay2
2015.11.08 14:30:17 1: configAutoOffForRelay2: Timeout reading answer for get configAutoOffForRelay2
2015.11.08 14:30:17 2: ZWave get ID007_SW_KINO_AMBIENTE configAutoOffRelayAfterSpecifiedTime
2015.11.08 14:30:20 1: configAutoOffRelayAfterSpecifiedTime: Timeout reading answer for get configAutoOffRelayAfterSpecifiedTime
2015.11.08 14:30:20 2: ZWave get ID007_SW_KINO_AMBIENTE configControlKey2Behaviour
2015.11.08 14:30:20 2: ERROR: ID007_SW_KINO_AMBIENTE: cleaning commands without ack after 10s
2015.11.08 14:30:23 1: configControlKey2Behaviour: Timeout reading answer for get configControlKey2Behaviour
2015.11.08 14:30:23 2: ZWave get ID007_SW_KINO_AMBIENTE configDimmerRollerShutterControl
2015.11.08 14:30:26 1: configDimmerRollerShutterControl: Timeout reading answer for get configDimmerRollerShutterControl
2015.11.08 14:30:26 2: ZWave get ID007_SW_KINO_AMBIENTE configEnableDisableALLONOFF
2015.11.08 14:30:29 1: configEnableDisableALLONOFF: Timeout reading answer for get configEnableDisableALLONOFF
2015.11.08 14:30:29 2: ZWave get ID007_SW_KINO_AMBIENTE configInputsBehaviour
2015.11.08 14:30:32 1: configInputsBehaviour: Timeout reading answer for get configInputsBehaviour
2015.11.08 14:30:32 2: ZWave get ID007_SW_KINO_AMBIENTE configInputsButtonSwitchConfiguration
2015.11.08 14:30:32 2: ERROR: ID007_SW_KINO_AMBIENTE: cleaning commands without ack after 10s
2015.11.08 14:30:35 1: configInputsButtonSwitchConfiguration: Timeout reading answer for get configInputsButtonSwitchConfiguration
2015.11.08 14:30:35 2: ZWave get ID007_SW_KINO_AMBIENTE configRelay1ResponseToGeneralAlarm
2015.11.08 14:30:38 1: configRelay1ResponseToGeneralAlarm: Timeout reading answer for get configRelay1ResponseToGeneralAlarm
2015.11.08 14:30:38 2: ZWave get ID007_SW_KINO_AMBIENTE configRelay1ResponseToSmokeCOCO2Alarm
2015.11.08 14:30:41 1: configRelay1ResponseToSmokeCOCO2Alarm: Timeout reading answer for get configRelay1ResponseToSmokeCOCO2Alarm
2015.11.08 14:30:41 2: ZWave get ID007_SW_KINO_AMBIENTE configRelay1ResponseToTemperatureAlarm
2015.11.08 14:30:44 1: configRelay1ResponseToTemperatureAlarm: Timeout reading answer for get configRelay1ResponseToTemperatureAlarm
2015.11.08 14:30:44 2: ZWave get ID007_SW_KINO_AMBIENTE configRelay1ResponseToWaterFloodAlarm
2015.11.08 14:30:44 2: ERROR: ID007_SW_KINO_AMBIENTE: cleaning commands without ack after 10s
2015.11.08 14:30:47 1: configRelay1ResponseToWaterFloodAlarm: Timeout reading answer for get configRelay1ResponseToWaterFloodAlarm
2015.11.08 14:30:47 2: ZWave get ID007_SW_KINO_AMBIENTE configRelay2ResponseToGeneralAlarm
2015.11.08 14:30:50 1: configRelay2ResponseToGeneralAlarm: Timeout reading answer for get configRelay2ResponseToGeneralAlarm
2015.11.08 14:30:50 2: ZWave get ID007_SW_KINO_AMBIENTE configRelay2ResponseToSmokeCOCO2Alarm
2015.11.08 14:30:53 1: configRelay2ResponseToSmokeCOCO2Alarm: Timeout reading answer for get configRelay2ResponseToSmokeCOCO2Alarm
2015.11.08 14:30:53 2: ZWave get ID007_SW_KINO_AMBIENTE configRelay2ResponseToTemperatureAlarm
2015.11.08 14:30:56 1: configRelay2ResponseToTemperatureAlarm: Timeout reading answer for get configRelay2ResponseToTemperatureAlarm
2015.11.08 14:30:56 2: ZWave get ID007_SW_KINO_AMBIENTE configRelay2ResponseToWaterFloodAlarm
2015.11.08 14:30:56 2: ERROR: ID007_SW_KINO_AMBIENTE: cleaning commands without ack after 10s
2015.11.08 14:30:59 1: configRelay2ResponseToWaterFloodAlarm: Timeout reading answer for get configRelay2ResponseToWaterFloodAlarm
2015.11.08 14:30:59 2: ZWave get ID007_SW_KINO_AMBIENTE configSavingStateBeforePowerFaillure
2015.11.08 14:31:02 1: configSavingStateBeforePowerFaillure: Timeout reading answer for get configSavingStateBeforePowerFaillure
2015.11.08 14:31:02 2: ZWave get ID007_SW_KINO_AMBIENTE configSeparationOfAssociationSending6
2015.11.08 14:31:05 1: configSeparationOfAssociationSending6: Timeout reading answer for get configSeparationOfAssociationSending6

initiiert mit ConfigRequestAll - aber auch einzelnd

Da ich das Senden gerade umgebaut habe: kannst du das bitte mit dem update von morgen (ab 8:00) pruefen?
Oder sofort mit dem 00_ZWDongle.pm/10_ZWave.pm aus SVN.

reicht es einfach
update 00_ZWDongle.pm
&
update 10_ZWave.pm

einzugeben?

Morgen ab 8 Uhr: ja
Heute musst Du die beiden Dateien manuell aus dem SVN http://sourceforge.net/p/fhem/code/HEAD/tree/ herunterladen und in das passende Verzeichnis Deiner Installation kopieren.
Gruß, Christian

Hab ich gemacht..

leider keine Änderung. Die Configs können nicht mehr gelesen werden.

Kannst Du das bitte genauer erläutern; am Besten per Fhem-Logauszug.

sieht aus wie oben. Soll ich am verbose was ändern?

Funktioniert denn die Ansteuerung der Geräte?
Kannst Du an ZWDongle die caps abrufen?

Ansonsten bitte volles Programm an Infos, wenn keine anderen Ideen kommen: http://www.fhemwiki.de/wiki/Z-Wave#Welche_Infos_sollten_Anfragen_im_ZWave-Forum_enthalten.3F Für mich sind die Infos noch zu schmal.

Gruß, Christian

Die Ansteuerung funktioniert.

Hier die Dongle-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 UNKNOWN_b4 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

Ist der AEOTEC-Stick mit Akku.

ConfigRequestAll hat bisher immer funktioniert, ging recht schnell und hat bisher fast immer alle Configs in einem Rutsch gelesen.
Sind etwa 30 Geräte - seit dem Update funktioniert es bei keinem mehr. Manchmal (sehr selten) sporadisch bei Einzelwerten.
Meldungen von z.B. Bewegungsmeldern bekomme ich auch noch.

Hier ein verbose5-log von einem getconfig mit anschließendem Timeout:
2015.11.08 18:37:19 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00041011033003ff
2015.11.08 18:37:19 5: SW: 06
2015.11.08 18:37:19 5: ZWDongle_1 dispatch 00041011033003ff
2015.11.08 18:37:19 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:11 ARG:033003ff
2015.11.08 18:37:19 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00041011033003ff
2015.11.08 18:37:19 5: SW: 06
2015.11.08 18:37:19 5: ZWDongle_1 dispatch 00041011033003ff
2015.11.08 18:37:19 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:11 ARG:033003ff
2015.11.08 18:37:19 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00041011033003ff
2015.11.08 18:37:19 5: SW: 06
2015.11.08 18:37:19 5: ZWDongle_1 dispatch 00041011033003ff
2015.11.08 18:37:19 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:11 ARG:033003ff
2015.11.08 18:37:19 2: ZWave set ID002_SW_VORFLUR on
2015.11.08 18:37:19 5: ZWDongle_Write 00 1302032501FF2502
2015.11.08 18:37:19 5: SW: 010a001302032501FF25021b
2015.11.08 18:37:19 5: ACK received, WaitForAck=>2 for 010a001302032501FF25021b
2015.11.08 18:37:19 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 011301
2015.11.08 18:37:19 5: SW: 06
2015.11.08 18:37:19 5: ZWDongle_1 dispatch 011301
2015.11.08 18:37:19 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 001302000007
2015.11.08 18:37:19 5: SW: 06
2015.11.08 18:37:19 5: device ack reveived, removing 010a001302032501FF25021b from dongle sendstack
2015.11.08 18:37:19 5: ZWDongle_1 dispatch 001302000007
2015.11.08 18:37:19 4: ZWDongle_1 CMD:ZW_SEND_DATA ID:00 ARG:0007
2015.11.08 18:37:19 4: ZWDongle_1 transmit OK for 02
2015.11.08 18:37:20 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00041011033003ff
2015.11.08 18:37:20 5: SW: 06
2015.11.08 18:37:20 5: ZWDongle_1 dispatch 00041011033003ff
2015.11.08 18:37:20 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:11 ARG:033003ff
2015.11.08 18:37:20 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00041011033003ff
2015.11.08 18:37:20 5: SW: 06
2015.11.08 18:37:20 5: ZWDongle_1 dispatch 00041011033003ff
2015.11.08 18:37:20 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:11 ARG:033003ff
2015.11.08 18:37:20 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00041011033003ff
2015.11.08 18:37:20 5: SW: 06
2015.11.08 18:37:20 5: ZWDongle_1 dispatch 00041011033003ff
2015.11.08 18:37:20 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:11 ARG:033003ff
2015.11.08 18:37:20 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00041011033003ff
2015.11.08 18:37:20 5: SW: 06
2015.11.08 18:37:20 5: ZWDongle_1 dispatch 00041011033003ff
2015.11.08 18:37:20 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:11 ARG:033003ff
2015.11.08 18:37:20 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00041011033003ff
2015.11.08 18:37:20 5: SW: 06
2015.11.08 18:37:20 5: ZWDongle_1 dispatch 00041011033003ff
2015.11.08 18:37:20 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:11 ARG:033003ff
2015.11.08 18:37:21 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00041002032503ff
2015.11.08 18:37:21 5: SW: 06
2015.11.08 18:37:21 5: ZWDongle_1 dispatch 00041002032503ff
2015.11.08 18:37:21 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:02 ARG:032503ff
2015.11.08 18:37:21 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00041002032503ff
2015.11.08 18:37:21 5: SW: 06
2015.11.08 18:37:21 5: ZWDongle_1 dispatch 00041002032503ff
2015.11.08 18:37:21 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:02 ARG:032503ff
2015.11.08 18:37:21 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00041002032503ff
2015.11.08 18:37:21 5: SW: 06
2015.11.08 18:37:21 5: ZWDongle_1 dispatch 00041002032503ff
2015.11.08 18:37:21 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:02 ARG:032503ff
2015.11.08 18:37:21 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00041002032503ff
2015.11.08 18:37:21 5: SW: 06
2015.11.08 18:37:21 5: ZWDongle_1 dispatch 00041002032503ff
2015.11.08 18:37:21 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:02 ARG:032503ff
2015.11.08 18:37:21 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00041002032503ff
2015.11.08 18:37:21 5: SW: 06
2015.11.08 18:37:21 5: ZWDongle_1 dispatch 00041002032503ff
2015.11.08 18:37:21 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:02 ARG:032503ff
2015.11.08 18:37:21 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00041002032503ff
2015.11.08 18:37:21 5: SW: 06
2015.11.08 18:37:21 5: ZWDongle_1 dispatch 00041002032503ff
2015.11.08 18:37:21 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:02 ARG:032503ff
2015.11.08 18:37:21 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00041002032503ff
2015.11.08 18:37:21 5: SW: 06
2015.11.08 18:37:21 5: ZWDongle_1 dispatch 00041002032503ff
2015.11.08 18:37:21 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:02 ARG:032503ff
2015.11.08 18:37:22 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00041002032503ff
2015.11.08 18:37:22 5: SW: 06
2015.11.08 18:37:22 5: ZWDongle_1 dispatch 00041002032503ff
2015.11.08 18:37:22 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:02 ARG:032503ff
2015.11.08 18:37:22 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00041002032503ff
2015.11.08 18:37:22 5: SW: 06
2015.11.08 18:37:22 5: ZWDongle_1 dispatch 00041002032503ff
2015.11.08 18:37:22 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:02 ARG:032503ff
2015.11.08 18:37:22 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00041002032503ff
2015.11.08 18:37:22 5: SW: 06
2015.11.08 18:37:22 5: ZWDongle_1 dispatch 00041002032503ff
2015.11.08 18:37:22 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:02 ARG:032503ff
2015.11.08 18:37:22 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00041002032503ff
2015.11.08 18:37:22 5: SW: 06
2015.11.08 18:37:22 5: ZWDongle_1 dispatch 00041002032503ff
2015.11.08 18:37:22 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:02 ARG:032503ff
2015.11.08 18:37:23 2: ZWave get ID002_SW_VORFLUR configActionOnButtonDoublePressOrHold
2015.11.08 18:37:23 5: ZWDongle_Write 00 13020370050e2502
2015.11.08 18:37:23 5: SW: 010a0013020370050e2502bb
2015.11.08 18:37:23 4: ZWDongle_ReadAnswer arg:configActionOnButtonDoublePressOrHold regexp:^00040002..70
2015.11.08 18:37:23 5: ACK received, WaitForAck=>2 for 010a0013020370050e2502bb
2015.11.08 18:37:23 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 011301
2015.11.08 18:37:23 5: SW: 06
2015.11.08 18:37:23 5: ZWDongle_1 dispatch 011301
2015.11.08 18:37:23 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 001302000006
2015.11.08 18:37:23 5: SW: 06
2015.11.08 18:37:23 5: device ack reveived, removing 010a0013020370050e2502bb from dongle sendstack
2015.11.08 18:37:23 5: ZWDongle_1 dispatch 001302000006
2015.11.08 18:37:23 4: ZWDongle_1 CMD:ZW_SEND_DATA ID:00 ARG:0006
2015.11.08 18:37:23 4: ZWDongle_1 transmit OK for 02
2015.11.08 18:37:24 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 000410020570060e0100
2015.11.08 18:37:24 5: SW: 06
2015.11.08 18:37:24 5: ZWDongle_1 dispatch 000410020570060e0100
2015.11.08 18:37:24 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:02 ARG:0570060e0100
2015.11.08 18:37:24 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 000410020570060e0100
2015.11.08 18:37:24 5: SW: 06
2015.11.08 18:37:24 5: ZWDongle_1 dispatch 000410020570060e0100
2015.11.08 18:37:24 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:02 ARG:0570060e0100
2015.11.08 18:37:24 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 000410020570060e0100
2015.11.08 18:37:24 5: SW: 06
2015.11.08 18:37:24 5: ZWDongle_1 dispatch 000410020570060e0100
2015.11.08 18:37:24 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:02 ARG:0570060e0100
2015.11.08 18:37:24 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 000410020570060e0100
2015.11.08 18:37:24 5: SW: 06
2015.11.08 18:37:24 5: ZWDongle_1 dispatch 000410020570060e0100
2015.11.08 18:37:24 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:02 ARG:0570060e0100
2015.11.08 18:37:25 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 000410020570060e0100
2015.11.08 18:37:25 5: SW: 06
2015.11.08 18:37:25 5: ZWDongle_1 dispatch 000410020570060e0100
2015.11.08 18:37:25 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:02 ARG:0570060e0100
2015.11.08 18:37:25 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 000410020570060e0100
2015.11.08 18:37:25 5: SW: 06
2015.11.08 18:37:25 5: ZWDongle_1 dispatch 000410020570060e0100
2015.11.08 18:37:25 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:02 ARG:0570060e0100
2015.11.08 18:37:25 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 000410020570060e0100
2015.11.08 18:37:25 5: SW: 06
2015.11.08 18:37:25 5: ZWDongle_1 dispatch 000410020570060e0100
2015.11.08 18:37:25 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:02 ARG:0570060e0100
2015.11.08 18:37:25 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 000410020570060e0100
2015.11.08 18:37:25 5: SW: 06
2015.11.08 18:37:25 5: ZWDongle_1 dispatch 000410020570060e0100
2015.11.08 18:37:25 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:02 ARG:0570060e0100
2015.11.08 18:37:25 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 000410020570060e0100
2015.11.08 18:37:25 5: SW: 06
2015.11.08 18:37:25 5: ZWDongle_1 dispatch 000410020570060e0100
2015.11.08 18:37:25 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:02 ARG:0570060e0100
2015.11.08 18:37:28 5: ZWDongle_ReadAnswer: select timeout

und hier ein Log von einem Schaltvorgang (funktioniert!)

2015.11.08 18:40:01 2: ZWave set ID002_SW_VORFLUR on
2015.11.08 18:40:01 5: ZWDongle_Write 00 1302032501FF2502
2015.11.08 18:40:01 5: SW: 010a001302032501FF25021b
2015.11.08 18:40:01 5: ACK received, WaitForAck=>2 for 010a001302032501FF25021b
2015.11.08 18:40:01 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 011301
2015.11.08 18:40:01 5: SW: 06
2015.11.08 18:40:01 5: ZWDongle_1 dispatch 011301
2015.11.08 18:40:01 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 001302000006
2015.11.08 18:40:01 5: SW: 06
2015.11.08 18:40:01 5: device ack reveived, removing 010a001302032501FF25021b from dongle sendstack
2015.11.08 18:40:01 5: ZWDongle_1 dispatch 001302000006
2015.11.08 18:40:01 4: ZWDongle_1 CMD:ZW_SEND_DATA ID:00 ARG:0006
2015.11.08 18:40:01 4: ZWDongle_1 transmit OK for 02
2015.11.08 18:40:03 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00041002032503ff
2015.11.08 18:40:03 5: SW: 06
2015.11.08 18:40:03 5: ZWDongle_1 dispatch 00041002032503ff
2015.11.08 18:40:03 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:02 ARG:032503ff
2015.11.08 18:40:03 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00041002032503ff
2015.11.08 18:40:03 5: SW: 06
2015.11.08 18:40:03 5: ZWDongle_1 dispatch 00041002032503ff
2015.11.08 18:40:03 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:02 ARG:032503ff
2015.11.08 18:40:03 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00041002032503ff
2015.11.08 18:40:03 5: SW: 06
2015.11.08 18:40:03 5: ZWDongle_1 dispatch 00041002032503ff
2015.11.08 18:40:03 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:02 ARG:032503ff
2015.11.08 18:40:03 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00041002032503ff
2015.11.08 18:40:03 5: SW: 06
2015.11.08 18:40:03 5: ZWDongle_1 dispatch 00041002032503ff
2015.11.08 18:40:03 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:02 ARG:032503ff
2015.11.08 18:40:03 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00041002032503ff
2015.11.08 18:40:03 5: SW: 06
2015.11.08 18:40:03 5: ZWDongle_1 dispatch 00041002032503ff
2015.11.08 18:40:03 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:02 ARG:032503ff
2015.11.08 18:40:03 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00041002032503ff
2015.11.08 18:40:03 5: SW: 06
2015.11.08 18:40:03 5: ZWDongle_1 dispatch 00041002032503ff
2015.11.08 18:40:03 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:02 ARG:032503ff
2015.11.08 18:40:03 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00041002032503ff
2015.11.08 18:40:03 5: SW: 06
2015.11.08 18:40:03 5: ZWDongle_1 dispatch 00041002032503ff
2015.11.08 18:40:03 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:02 ARG:032503ff

Habe keine Ideen, woran das liegen könnte.
Neustart und kurz stromlos machen des Gateways/Servers hast Du sicherlich schon gemacht.
Von welcher Version hast Du denn das update gemacht? Schau mal bitte ins restoreDir-Verzeichnis.

Folgende Versionen sind darin enthalten:
2015-11-02  2015-11-07  2015-11-08

Allerdings weiss ich nicht, ob ich gestern auch Configs auslesen wollte/konnte.

ABER: ich habe den Rpi2 mal neugestartet - jetzt geht es wieder. Sonderbar, dachte es reicht ein shutdown restart.
Ich behalte das mal im Auge, vielen Dank für Deine Hilfe!

Hallo allerseits!

Durch meine sonderbaren Probleme mit dem Raspberry2 bin ich jetzt auf einen Intel NUC umgezogen.
Ich habe meine fhem.conf und den AEOTEC-Gen5-Stick einfach mitgenommen.
Leider habe ich jetzt wieder neue Probleme mit batteriebetriebenen Geräten.  :'(

Ich erhalten beispielsweise bei der ZWave.me-Remote jetzt kein ZW_APPLICATION_UPDATE mehr bei 3xInclude-Button.
Genau das gleiche bei einem Fibaro-Motionsensor - es kommt einfach kein ZW_APPLICATION_UPDATE mehr an.
Werte (Temperatur, Helligkeit usw.) und auch gewünschte Schaltaktionen kommen aber beim Controller/FHEM an.

Dadurch kann ich leider meine Readings nicht mehr herstellen bei diesen Geräten.

Alle anderen stromversorgten Geräte funktionieren fehlerfrei. FHEM ist auf dem heutigen Stand.

Hat jemand Ahnung was da los sein könnte? Vielen Dank!

Viele Grüße
Thomas

Nachtrag:
Kurze Frage:
Ist es eigentlich normal, dass in keiner Neighbor-list mehr das Dongle (ID1) auftaucht? 

Nachtrag2:
ZW_APPLICATION_UPDATE funktioniert nur in unmittelbarer Nähe zum Dongle.
Neighbor-List wird auch aktualisiert - leider kann ich mich trotzdem nicht weiter entfernen um die Fernbedienung dort anzulernen wo sie gebraucht wird, weil ja das ZW_APPLICATION_UPDATE beim Controller nicht ankommt.
Das war früher anders, da konnte ich vom Keller aus das Update anstossen.

Nachtrag3:
Zur ZWave-Me-Remote: Schaltvorgänge kommen ja wie gesagt beim Controller an, jetzt blinkt die LED jeweils 3x Rot nach jedem mal

Nachtrag 4:
associationRequestAll funktioniert nicht mit ZWave-Me-Remote. 12 = $0C Associations
PERL WARNING: Argument "0c" isn't numeric in numeric ge (>=) at ./FHEM/10_ZWave.pm line 1835.

Was liefert "get <ZWDongle> ctrlCaps"?

Zitat
Ist es eigentlich normal, dass in keiner Neighbor-list mehr das Dongle (ID1) auftaucht? 

Nein.

ZWDongle_1 ctrlCaps => PRIMARY

Mmh, dann habe ich leider keine Idee.

Gibt es eventuell die Möglichkeit das Dongle wieder manuell in eine Neighbor-List hineinzubekommen?

Das manuelle Setzen von Routen ist in FHEM nicht eingebaut. Die Befehle müsstest Du Dir heraussuchen und per "get <ZWDongle> raw" absetzen.

Ohje - so weit bin ich leider nicht.

Sehr ärgerlich - ich müsste den Stick resetten und 30 Geräte neu inkludieren... und davon sind eine ganze Menge Fibaro-UP...
Da kommt eine riesige Arbeit auf mich zu. Zumal man den Grund nicht kennt weshalb der Controller aus der Neighbor-Liste
geflogen ist. Hast du bei einem Gerät in Controllernähe mal auf einer aktuellen FHEM-Version ein Neighbor-Update gemacht
und ist der Controller dann noch immer darin enthalten?

Hallo Tom,
hallo Christian,

ZitatIst es eigentlich normal, dass in keiner Neighbor-list mehr das Dongle (ID1) auftaucht? 

hm, bei mir taucht die ID1 des Dongle auch in keinem device mehr auf. Eventuell hat es damit zu tun: http://forum.fhem.de/index.php?topic=43338.new;topicseen#new

Grüße,
Josef

Hallo Josef,

möglich - erklärt sich mir dann aber nicht, welches Gerät noch eine Verbindung zum Dongle hat.

@Josef:
Das steht mMn in keinem Zusammenhang. Der Befehl ist nur von ZWDongle zu den ZWave-Geräte-Devices verlagert  worden und das sollte keine Auswirkungen auf die ermittelten Lists haben. Die abgesetzten Befehle sind gleich.

@toms01
Ich glaube nicht, dass Du alles neu inkludieren musst. Das ZWDongle in den nodeLists fehlt dürfte auch nicht das eigentliche Problem sein. Dein Stick ist mir suspekt. Verstehe das System mit dem Batteriebetrieb nicht. Zudem bin ich mir bei Deiner ZWave.me Remote unschlüssg. Was ist das genau für eine?

Hi,

Zitat von: toms01 am 23 November 2015, 21:25:40
Ohje - so weit bin ich leider nicht.

Sehr ärgerlich - ich müsste den Stick resetten und 30 Geräte neu inkludieren... und davon sind eine ganze Menge Fibaro-UP...
Da kommt eine riesige Arbeit auf mich zu. Zumal man den Grund nicht kennt weshalb der Controller aus der Neighbor-Liste
geflogen ist. Hast du bei einem Gerät in Controllernähe mal auf einer aktuellen FHEM-Version ein Neighbor-Update gemacht
und ist der Controller dann noch immer darin enthalten?

welches Problem hast Du denn damit das der Controller nicht in der Liste drin ist?

Bei mir wird der Controller auch nicht mehr angezeigt, funktionieren tut aber noch alles.

Gruß,
Andreas.

Hallo zusammen,

Zitatmöglich - erklärt sich mir dann aber nicht, welches Gerät noch eine Verbindung zum Dongle hat.

klar, bei mir fumktioniert auch alles, aber ist die Frage von Tom nicht berechtigt?

Ich errinere mich noch vage das im Oktober vor meinem Urlaub der Dongle noch in der Liste zu sehen war, aber meine Hand ins Feuer würde ich dafür nicht legen.  ;)

Grüße,
Josef

Hallo Andreas,

ein Problem habe ich grundsätzlich nicht damit. Früher tauchte allerdings die ID 1 de Controllers in den Nodelists mit auf. Man konnte so die Routen
vollständig nachvollziehen. Jetzt weiss man nicht mehr, welche Geräte noch direkt in Verbindung mit dem Controller stehen.

Aber: Früher konnte ich ein ZW_APPLICATION_UPDATE irgendwo im Netz forcieren (bei dieser Ferndienung http://forum.fhem.de/index.php?topic=35513.0 3x Incl drücken) - das funktioniert jetzt nur noch in unmittelbarer Nähe des Controllers. Somit muss ich bei Config-Änderungen das Ding immer durchs ganze Haus zum Controller schleppen und dort das Update anschieben. Wäre schön wenn das wieder wie früher klappen könnte.

@krikan
Z-Wave.Me ZME_RC2 Remote Control

Hi Tom,

Zitat von: toms01 am 23 November 2015, 21:47:41
ein Problem habe ich grundsätzlich nicht damit. Früher tauchte allerdings die ID 1 de Controllers in den Nodelists mit auf. Man konnte so die Routen
vollständig nachvollziehen. Jetzt weiss man nicht mehr, welche Geräte noch direkt in Verbindung mit dem Controller stehen.

Also in der Nodelist des Controllers taucht er selbst mit auf... In der Neighborlist taucht der Controller jetzt anscheinend bei allen nicht auf.  Von der Logik her gebe ich Dir Recht, so weiß man nicht wer direkten Kontakt hat und wer geroutet wird. Da die Geräte das

Ich habe mir gestern abend mal die Rohdaten vom Gerät angeschaut, da wird der Controller nicht gemeldet, ist also kein FHEM Problem. Hat den jemand vielleicht alte Logfiles die man mal auf "0180" (Anfang der Neighborlist) durchsuchen könnte um nachzuvollziehen ob das wirklich früher mit gesendet wurde?

Ich habe noch nicht soo lange ZWave Geräte und habe die Neighborliste auch nie abgefragt, kann also da nicht mit Daten dienen.

Zitat von: toms01 am 23 November 2015, 21:47:41
Aber: Früher konnte ich ein ZW_APPLICATION_UPDATE irgendwo im Netz forcieren (bei dieser Ferndienung http://forum.fhem.de/index.php?topic=35513.0 3x Incl drücken) - das funktioniert jetzt nur noch in unmittelbarer Nähe des Controllers. Somit muss ich bei Config-Änderungen das Ding immer durchs ganze Haus zum Controller schleppen und dort das Update anschieben. Wäre schön wenn das wieder wie früher klappen könnte.

Ich würde aber erst mal davon absehen den Stick zu resetten und alles neu aufzubauen, ist ja noch gar nicht sicher ob das hilft, oder ob das wieder so endet...

Zumindest das Routing ZUM Gerät scheint aber zu funktionieren, oder hast Du da auch Probleme? Kannst Du denn normale Tastedrücke/Szenen mit der Fernbedienung von Ihrem normalen Aufenthaltsort empfangen?

Ich habe gerade mal versucht ein "set ... neighborUpdate" für ein Gerät zu machen, da bekomme ich einen NO_ACK, das könnte aber ein FHEM internes Problem sein, da der Befehl mMn zwar FÜR ein bestimmtes Device ist, der Befehl aber an den Controller geschickt wird und die Antwort auch vom Controller kommt. Könnte sein das FHEM da fälschlicherweise eine Antwort vom Gerät erwartet. Das kann ich mir mal genauer ansehen, dauert aber ein paar Tage. Mit Controller-Befehlen habe ich mich aber noch nicht wirklich beschäftigt...

@Krikan: Da meine neighborlist (ZWave.Me UZB) und die von Joseph den Controller auch nicht anzeigen bin ich mir nicht sicher ob das wirklich jemals so war, oder ob "damals" nur die Nodelist vom Controller abgerufen wurde.

@Krikan: Wie sieht denn Deine neighborlist aus? Ist der Controller da mit dabei? Hast Du evtl. noch mal die Möglichkeit unter OZW gegenzutesten was dann vom Gerät kommt?

@Tom: Da ich hier nur drei Testgeräte habe könnte ich mal schauen wie ich meinen Stick resetten kann und dann die Geräte noch mal neu anlernen und könnte dann berichten ob das einen Einfluß auf die Neighborlist hat.

Gruß,
Andreas.

Zitat von: A.Harrenberg am 24 November 2015, 07:48:38
In der Neighborlist taucht der Controller jetzt anscheinend bei allen nicht auf.

Bei mir aber wohl immer noch. Nicht bei allen, aber bei ungefähr der Hälfte. Mit einem Gerät habe ich neigborUpdate getestet und dort taucht Controller wieder auf. Hat aber nur Controller als neigbour.

ZitatIch habe mir gestern abend mal die Rohdaten vom Gerät angeschaut, da wird der Controller nicht gemeldet, ist also kein FHEM Problem. Hat den jemand vielleicht alte Logfiles die man mal auf "0180" (Anfang der Neighborlist) durchsuchen könnte um nachzuvollziehen ob das wirklich früher mit gesendet wurde?

Bestimmt, aber muss ich suchen und dauert. Ich bleibe aber dabei, dass der abgesetzte Befehl zum neigbourUpdate und neighbourList mMn gleich geblieben ist.

Zitat
Ich würde aber erst mal davon absehen den Stick zu resetten und alles neu aufzubauen, ist ja noch gar nicht sicher ob das hilft, oder ob das wieder so endet...

Ja.
@Toms01: Stick mal stromlos gemacht? Beim neigbourUpdate die Entfernung zum Controller schrittweise erhöht? Betrifft das nur Fernbedienung und Motionsensor? Gibt es noch mehr batteriebetriebene Devices?

ZitatIch habe gerade mal versucht ein "set ... neighborUpdate" für ein Gerät zu machen, da bekomme ich einen NO_ACK, das könnte aber ein FHEM internes Problem sein, da der Befehl mMn zwar FÜR ein bestimmtes Device ist, der Befehl aber an den Controller geschickt wird und die Antwort auch vom Controller kommt. Könnte sein das FHEM da fälschlicherweise eine Antwort vom Gerät erwartet. Das kann ich mir mal genauer ansehen, dauert aber ein paar Tage. Mit Controller-Befehlen habe ich mich aber noch nicht wirklich beschäftigt...

neigborUpdate geht an Geräte. NO_ACK ist richtig, wenn Dein Device nicht antwortet.
neigborList nur an Dongle.

ZitatHast Du evtl. noch mal die Möglichkeit unter OZW gegenzutesten was dann vom Gerät kommt?

Ja, aber wird nichts kurzfristig.


@Rudi:
Kleiner Schönheitsfehler in 10_ZWave.pm; denke den hast Du nicht gesehen, da er im Edit kam:

ZitatassociationRequestAll funktioniert nicht mit ZWave-Me-Remote. 12 = $0C Associations
PERL WARNING: Argument "0c" isn't numeric in numeric ge (>=) at ./FHEM/10_ZWave.pm line 1835.

Zitat von: A.Harrenberg am 24 November 2015, 07:48:38
Kannst Du denn normale Tastedrücke/Szenen mit der Fernbedienung von Ihrem normalen Aufenthaltsort empfangen?

Hallo Andreas, das ist es ja gerade - die Bedienung (auch zum Controller/FHEM) funktioniert aucht entfernt. Ich kann damit schalten.
Ich werde - wenn es die Zeit erlaubt - heute Abend mal den Controller auf verbose 5 setzen und schauen
ob grundsätzlich noch etwas beim forcierten Update ankommt von der Fernbedienung. Ansonsten stimmt wohl
irgendwas mit dem Routing dieser/dieses Meldung/Befehl nicht mehr. Wie auch immer...
Gleiches trifft ja auch auf einen Fibaro-Motion-Sensor zu. Ich habe noch ein paar Wall CS2-Funktsender
und ein paar AEOTEC-Bewegungsmelder. Ich muss mal schauen wie die sich so verhalten.
Eventuell baue ich diese Woche noch ein OpenHAB-Testsystem auf, mal schauen wie sich das so verhält.

Neben ein paar ZWave-ME-Schaltern sind noch Fibaros und drei AEOTEC-Repeater verbaut, auch sind noch
ein paar IP44-Aussenstreckdosen am Start.

Zitat von: krikan am 24 November 2015, 08:02:18
@Toms01: Stick mal stromlos gemacht? Beim neigbourUpdate die Entfernung zum Controller schrittweise erhöht? Betrifft das nur Fernbedienung und Motionsensor? Gibt es noch mehr batteriebetriebene Devices?

Hallo Krikan,
ich habe das System neu gebootet, mit und ohne Stick. Den Stick komplett stromlos zu machen ist glaube ich nicht möglich, da er einen Akku verbaut hat um damit
komfortabel im Haus Geräte anlernen/ablernen zu können.

Zusatz:
Klar, habe ich gemacht - schrittweise den Abstand erhöht und Neighbor-update gemacht - keine Änderung

Zitat von: krikan am 24 November 2015, 08:02:18
@Rudi:
Kleiner Schönheitsfehler in 10_ZWave.pm; denke den hast Du nicht gesehen, da er im Edit kam:

Als reinen Schönheitsfehler hatte ich das nicht angesehen, eher als Funktionsfehler.
"0C" wird wohl dann als 0 angesehen und es werden keine Assoziationen abgefragt.
Für Neulinge vielleicht ein Problem, die nicht alle Werte manuell abfragen.

Zitat von: toms01 am 24 November 2015, 10:11:58
Den Stick komplett stromlos zu machen ist glaube ich nicht möglich, da er einen Akku verbaut hat.

Genau deshalb ist mir das Ding sehr suspekt.

Zitatum damit
komfortabel im Haus Geräte anlernen/ablernen zu können.

Eben dadurch sind doch falsche Routen vorprogrammiert. (3 Repeater ist auch schon heftig.)

Jetzt mal produktiv:
Welche Route hast Du denn aktuell in der neigbourList der Problemdevices stehen und was soll da rein (bzw. war bei funktionierend drin)? Ich bräuchte das jeweils als NodeIds. Wenn ich es dann im Laufe der Woche schaffe, grübel und bastel ich etwas.
Hast Du mal nach Firmwareupdates des Controllers geschaut?

ZitatSchönheitsfehler hatte ich das nicht angesehen, eher als Funktionsfehler.

Man kann immer noch die einzelnen Assoziationen abfragen. Und ich persönlich halte es nicht für größeres Problem und freue mich, wenn das jemand in seiner Freizeit anschaut und ggfs. ändert....

Zitat
Genau deshalb ist mir das Ding sehr suspekt.Eben dadurch sind doch falsche Routen vorprogrammiert.
Hast Du mal nach Firmwareupdates des Controllers geschaut?

Mal abgesehen von dem Stromlos-Reset habe ich darüber andere Ansichten. Ich inkludiere einfach Geräte vorort mit dem Stick, die Nachbar-Nodes werden dann ja richtig erzeugt,
dann createnode und neighbor-update. In der Theorie sollte das dann ja gleich sein.
Von diesem Stick ist mir bisher nichts schlechtes/ungewöhnliches bekannt und (vielleicht auch deshalb) habe ich kein Firmware-Update gefunden.

Zitat
Welche Route hast Du denn aktuell in der neigbourList der Problemdevices stehen und was soll da rein (bzw. war bei funktionierend drin)? Ich bräuchte das jeweils als NodeIds. Wenn ich es dann im Laufe der Woche schaffe, grübel und bastel ich etwas.

Vielen Dank für dein Angebot. Kann ich im Laufe der Woche mal erstellen. Allerdings habe ich nicht mehr die Alt-Nodelists. Ich weiss allerdings mit Sicherheit, dass da vorher die Controller-ID mit drin war.

Zitat
Man kann immer noch die einzelnen Assoziationen abfragen. Und ich persönlich halte es nicht für größeres Problem und freue mich, wenn das jemand in seiner Freizeit anschaut und ggfs. ändert....

OT: Ich bin selbst Maintainer von einem OS-Projekt und freue mich eher über solche gemeldeten Funktionsfehler im Detail.
Unangenehmer finde ich immer die Aussage "funktioniert nicht" und man fängt dann immer von vorn an zu suchen.
Leider bin ich momentan nicht sehr nah an Perl - hätte dann womöglich ein diff gesendet. Vielleicht beim nächsten Mal.

Hi Christian,

Zitat von: krikan am 24 November 2015, 08:02:18
Bei mir aber wohl immer noch. Nicht bei allen, aber bei ungefähr der Hälfte. Mit einem Gerät habe ich neigborUpdate getestet und dort taucht Controller wieder auf. Hat aber nur Controller als neigbour.

ok, ich hätte jetzt gedacht das es allgemein so ist, aber das ist dann ja ein schlagkräfitges Argument dagegen  :)
Also da meine Testgeräte alle in einem Umkreis <1m voneinander, bzw. vom Dongle weg sind sollte die sich alle gegenseitig sehen. Keines meiner Geräte zeigt da was an, wobei ich das WakeUp-RFID-Pad noch mal testen muss.

Zitat von: krikan am 24 November 2015, 08:02:18
Bestimmt, aber muss ich suchen und dauert. Ich bleibe aber dabei, dass der abgesetzte Befehl zum neigbourUpdate und neighbourList mMn gleich geblieben ist.Ja.

Das hat sich ja jetzt eigentlich erledigt da einige Deiner Geräte den Controller noch melden. Würde also keine neuen Erkenntnisse bringen.

Zitat von: krikan am 24 November 2015, 08:02:18
neigborUpdate geht an Geräte. NO_ACK ist richtig, wenn Dein Device nicht antwortet.
neigborList nur an Dongle.

Das muss ich mir noch mal anschauen, ich habe da gestern nur kurz draufgeschaut und ich war der Meinung das da ein Controllerbefehl an das Dongle geschickt wird und der Dongle dann eine spezielle Nachricht an die Node.
Das mit dem NO_ACK habe ich ja nicht verstanden, daher dachte ich das es ein Controllerbefehl sei.

Hast Du vielleicht ein Log von Deinem erfolgreichen neigborUpdate?

Gruß,
Andreas.

Zitat von: A.Harrenberg am 24 November 2015, 13:05:21
Das muss ich mir noch mal anschauen, ich habe da gestern nur kurz draufgeschaut und ich war der Meinung das da ein Controllerbefehl an das Dongle geschickt wird und der Dongle dann eine spezielle Nachricht an die Node.
Das mit dem NO_ACK habe ich ja nicht verstanden, daher dachte ich das es ein Controllerbefehl sei.

Bin mir jetzt auch nicht mehr sicher, ob wir aneinander vorbeischreiben und Du nicht Recht hast!? Habe aber gerade keine längere Zeit zum Grübeln...

ZitatHast Du vielleicht ein Log von Deinem erfolgreichen neigborUpdate?

Ja, auf die Schnelle:
2015.11.23 22:47:54 4: ZWDongle_0 CMD:ZW_REQUEST_NODE_NEIGHBOR_UPDATE ID:21 ARG:
2015.11.23 22:47:54 4: ZWDongle_0 ZW_REQUEST_NODE_NEIGHBOR_UPDATE started
2015.11.23 22:47:54 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00480122
2015.11.23 22:47:54 5: SW: 06
2015.11.23 22:47:54 5: ZWDongle_0 dispatch 00480122
2015.11.23 22:47:54 4: ZWDongle_0 CMD:ZW_REQUEST_NODE_NEIGHBOR_UPDATE ID:22 ARG:
2015.11.23 22:47:54 4: ZWDongle_0 ZW_REQUEST_NODE_NEIGHBOR_UPDATE done

ZitatKleiner Schönheitsfehler in 10_ZWave.pm

Habs gefixt.

Zitat"0C" wird wohl dann als 0 angesehen und es werden keine Assoziationen abgefragt.

Es werden nur die Gruppen mit ID >= 10 nicht abgefragt. Hast du diese auch konfiguriert?

neighborList: mein zme meldet sich selbst nicht in der Liste, der "alte" Goodway schon. Kann natuerlich auch an den jeweils assoziierten Geraete liegen. In beiden Faellen habe ich die aktuellen FHEM-Module verwendet. Die erwaehnten Aenderugen duerften an einem "Verschwinden" keine Auswirkung haben, da sie "nur" die Nummer vor der Ausgabe nach Text konvertieren.

Zitat von: rudolfkoenig am 24 November 2015, 14:15:04
neighborList: mein zme meldet sich selbst nicht in der Liste, der "alte" Goodway schon.

Überdenkenswerte Angabe. Ich habe mit einem 400er Chipsatz Stick probiert, bei dem tlw. mit gemeldet wird. Alle anderen hier Vertretenen nutzen mWn Sticks/Razberry mit 500er Chipsatz.

ZitatEs werden nur die Gruppen mit ID >= 10 nicht abgefragt. Hast du diese auch konfiguriert?

Vielen Dank fürs ändern!
Könnte sein, dass ich bei der genannten FB nach deiner Anleitung vorgegangen bin, also per mca.
Dann würde das dort nicht auftauchen, oder?


Hab noch folgende Anfängerfrage: Bei anderen Projekten lese ich immer von Network-Healing o.ä. - wird wohl meist über Nacht angeworfen.
Passiert da noch mehr als ein Nodelist-Update?

ZitatKönnte sein, dass ich bei der genannten FB nach deiner Anleitung vorgegangen bin, also per mca.

mca (MULTI_CHANNEL_ASSOCIATION) und associationGroup (ASSOCIATION) sind unterschiedliche Klassen, und damit auch unterschiedliche Daten.

ok danke, hatte aber zumindest den Controller mit drin aber keine Assoziation zurückbekommen. Aber nun denn. Vielleicht hat ein Aufruf nicht gereicht.
Ist aber auch nicht so wichtig - mein Problem liegt momenten ganz woanders, vielleicht hängt ja alles damit zusammen. Ich bin gespannt ob eine sog. Healing-Funktion (ich teste mal OpenHAB über Nacht) am Stick die Funktionalität in FHEM zurückbringt. Vielleicht erstmal besser als alle Nodes neu zu assoziieren.

Zitat von: toms01 am 24 November 2015, 14:57:58
ok danke, hatte aber zumindest den Controller mit drin aber keine Assoziation zurückbekommen. Aber nun denn. Vielleicht hat ein Aufruf nicht gereicht.

Heißt das, dass die Geräte und Dongle nicht assoziert sind?

ZitatIch bin gespannt ob eine sog. Healing-Funktion (ich teste mal OpenHAB über Nacht) am Stick die Funktionalität in FHEM zurückbringt.

Wenn es dort ausführliche Logs gibt, nehme ich die gerne.  ;)

Hi Christian,

anscheinend ist meine erste Antwort im Nirvana verschwunden, daher noch mal...

Zitat von: krikan am 24 November 2015, 13:14:46

Code Auswählen Erweitern

2015.11.23 22:47:54 4: ZWDongle_0 CMD:ZW_REQUEST_NODE_NEIGHBOR_UPDATE ID:21 ARG:
2015.11.23 22:47:54 4: ZWDongle_0 ZW_REQUEST_NODE_NEIGHBOR_UPDATE started
2015.11.23 22:47:54 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00480122
2015.11.23 22:47:54 5: SW: 06
2015.11.23 22:47:54 5: ZWDongle_0 dispatch 00480122
2015.11.23 22:47:54 4: ZWDongle_0 CMD:ZW_REQUEST_NODE_NEIGHBOR_UPDATE ID:22 ARG:
2015.11.23 22:47:54 4: ZWDongle_0 ZW_REQUEST_NODE_NEIGHBOR_UPDATE done

So sieht das bei mir prinzipiell auch aus, aber NACH dem "ZWDongle_0 ZW_REQUEST_NODE_NEIGHBOR_UPDATE done" kam bei mir noch ein NO_ACK hinterher...

Ich habe den Rest der Woche nicht mehr viel Zeit werde das aber noch mal machen und das Log posten.

Gruß,
Andreas.

Hallo Andreas,
meinst Du "10s NO_ACK"? Habe ich hier nicht kontrolliert; könnte also existieren.
Ich suche mal den Thread mit der Umstellung von neigborUpdate bei WakeUp-Geräten auf Wakeup-Sendstack; vielleicht liefert der Infos.
Gruß, Christian

Hi Christian,

Zitat von: krikan am 24 November 2015, 15:40:25
meinst Du "10s NO_ACK"? Habe ich hier nicht kontrolliert; könnte also existieren.
Ich suche mal den Thread mit der Umstellung von neigborUpdate bei WakeUp-Geräten auf Wakeup-Sendstack; vielleicht liefert der Infos.

hmm, ich meine das da nichts von 10 sekunden drin war, irgendwie war das auch "komisch", das ganze hat mich ja dazu gebracht das dies ein Controller-Befehl ist. Ich kann versuchen das heute abend schnell rauszusuchen und zu posten, habe aber nachher nicht viel Zeit.

Gruß,
Andreas.

Zitat von: krikan am 24 November 2015, 15:07:22
Heißt das, dass die Geräte und Dongle nicht assoziert sind?
Wenn es dort ausführliche Logs gibt, nehme ich die gerne.  ;)

Nein, das heisst es nicht. Alle Geräte sind zumindest mit dem Dongle assoziiert - darauf hab ich geachtet.  :)
Ich kenne OpenHAB gar nicht - mache mich mal langsam dran. Falls es da was zu loggen gibt, gebe ich das gern weiter.

Hi,
das hier passiert bei meinem nieghborUpdate:
2015.11.24 18:16:27.002 2: ZWave set ZWave_SWITCH_BINARY_159 neighborUpdate
2015.11.24 18:16:27.003 5: ZWDongle_Write 00 489f
2015.11.24 18:16:27.003 5: SW: 010400489f2c
2015.11.24 18:16:27.127 5: ACK received, removing 010400489f2c from dongle sendstack
2015.11.24 18:16:27.238 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00480221
2015.11.24 18:16:27.239 5: SW: 06
2015.11.24 18:16:27.240 5: ZWDongle_0 dispatch 00480221
2015.11.24 18:16:27.240 4: ZWDongle_0 CMD:ZW_REQUEST_NODE_NEIGHBOR_UPDATE ID:21 ARG:
2015.11.24 18:16:27.240 4: ZWDongle_0 ZW_REQUEST_NODE_NEIGHBOR_UPDATE started
2015.11.24 18:16:27.421 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00480221
2015.11.24 18:16:27.421 5: SW: 06
2015.11.24 18:16:27.422 5: ZWDongle_0 dispatch 00480221
2015.11.24 18:16:27.422 4: ZWDongle_0 CMD:ZW_REQUEST_NODE_NEIGHBOR_UPDATE ID:21 ARG:
2015.11.24 18:16:27.422 4: ZWDongle_0 ZW_REQUEST_NODE_NEIGHBOR_UPDATE started
2015.11.24 18:16:27.761 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00480222
2015.11.24 18:16:27.761 5: SW: 06
2015.11.24 18:16:27.762 5: ZWDongle_0 dispatch 00480222
2015.11.24 18:16:27.762 4: ZWDongle_0 CMD:ZW_REQUEST_NODE_NEIGHBOR_UPDATE ID:22 ARG:
2015.11.24 18:16:27.762 4: ZWDongle_0 ZW_REQUEST_NODE_NEIGHBOR_UPDATE done
2015.11.24 18:16:37.005 2: ZWave: No ACK from ZWave_SWITCH_BINARY_159 after 10s for sent:489f

wobei ich der Meinung bin das
2015.11.24 18:16:27.003 5: ZWDongle_Write 00 489f
2015.11.24 18:16:27.003 5: SW: 010400489f2c
einen Controllerbefehl darstellt
'48'  => 'ZW_REQUEST_NODE_NEIGHBOR_UPDATE' (ZWDongle.pm)
mit 9f = node_id 159
2c Checksumme ?

Als "Antwort" kommt dann eine 00480221, was ich mangels Info nicht entschlüsseln kann, es scheint aber als neighbor update startet gedeutet zu werden. Dann kommt noch eine 00480222 hinterher was dann als "done" interpretiert wird.

Dann kommt das NO_ACK, das aber mMn hier eine Fehlmeldung ist, das nie ein Befehl direkt an 159 geschickt wurde sondern das zwischendurch irgendwo in einen Controllerbefehl umgesetzt wird.

EIn Get-NeighborList bringt nur den Nachbarn, nicht den Controller:
2015.11.24 18:23:37.428 4: ZWDongle_ReadAnswer for neighborList: 01800000000000000000000000000000000000000020000000000000000000

Zu mehr Diagnose / mehr Versuchen habe ich jetzt leider keine Zeit mehr.

Gruß,
Andreas.

Der Aufruf von neigborUpdate endet bei mit immer mit:
ZWave: No ACK from ZWave_xy after 10s for sent:48xy

Wenn das Endgerät erreichbar ist (wach oder eingesteckt), dann liefert neigborUpdate:
ZWDongle_Read ZWDongle_0: sending ACK, processing 00480222
SW: 06
ZWDongle_0 dispatch 00480222
ZWDongle_0 CMD:ZW_REQUEST_NODE_NEIGHBOR_UPDATE ID:22 ARG:
ZWDongle_0 ZW_REQUEST_NODE_NEIGHBOR_UPDATE done

Wenn das Endgerät nicht erreichbar ist (schlafend oder ausgesteckt), dann liefert neigborUpdate:
ZWDongle_Read ZWDongle_0: sending ACK, processing 00480123
SW: 06
ZWDongle_0 dispatch 00480123
ZWDongle_0 CMD:ZW_REQUEST_NODE_NEIGHBOR_UPDATE ID:23 ARG:
ZWDongle_0 ZW_REQUEST_NODE_NEIGHBOR_UPDATE failed

Meine derzeitige Schlussfolgerung:
Bei neigborUpdate bekommt man kein ACK (0013xy00), sondern die Erreichbarkeit des Endgerätes wird über done/failed (22/23) mitgeteilt.
neigborUpdate in  FHEM läuft korrekt durch; nur
ZWave: No ACK from ZWave_xy after 10s for sent:4806
könnte raus. Aber das ist mMn unerheblich.

Gruß, Christian

Zitat von: A.Harrenberg am 24 November 2015, 18:42:24
Als "Antwort" kommt dann eine 00480221, was ich mangels Info nicht entschlüsseln kann, es scheint aber als neighbor update startet gedeutet zu werden. Dann kommt noch eine 00480222 hinterher was dann als "done" interpretiert wird.

00 -> Request
48 -> ZW_REQUEST_NODE_NEIGHBOR_UPDATE
02 -> funcId=callbackId, da von FHEM im Befehlsaufruf nicht gesetzt, ist das "irgendetwas" -> Nebenwirkungen ?
21 -> bStatus= 21 started, 22 done, 23 failed

Hi Christian,

deckt sich mit meiner Einschätzung.
Ein ACK (0013xy00) kann da auch nicht kommen, da ja ein 0048, also ZW_REQUEST_NODE_NEIGHBOR_UPDATE verschickt wurde und kein 0013 ZW_SEND_DATA.

Ich frage mich nur was da auf der Protokollebene passiert wenn das neighborUpdate ja anscheinend einwandfrei beendet wird und auch danach ID 1 nicht gemeldet wird.

Könnte das irgendetwas mit Explorerframes zu tun haben? Ich weiß ist 'ne gewagte Assoziation, aber ansonsten fällt mir nur die etwas geänderte Initialisierung (anlässlich SECURITY) des Dongles als größere Änderung im ZWave-Code ein.

Gruß,
Andreas.

Zitat von: A.Harrenberg am 24 November 2015, 21:05:35
Ich frage mich nur was da auf der Protokollebene passiert wenn das neighborUpdate ja anscheinend einwandfrei beendet wird und auch danach ID 1 nicht gemeldet wird.

Finde Rudis Einwurf überdenkenswert und will das auch noch mal testen

ZitatKönnte das irgendetwas mit Explorerframes zu tun haben?

Wüsste nicht, warum. Mir fehlt da jeder Ansatzpunkt.
Dann müsste unter ozw auch das Gleiche passieren.

Gruß, Christian

Hi,

ich habe gerade was rausgefunden  :)

Die API Funktion GetRoutingInfo welche sich hinter dem "get ... neighborList" verbigt ("'80'  => 'GET_ROUTING_TABLE_LINE'"), hat folgende Parameter:
HOST->ZW: REQ | 0x80 | bNodeID | bRemoveBad | bRemoveNonReps | funcID
wobei
bRemoveNonReps  = GET_ROUTING_INFO_REMOVE_NON_REPS
Remove non-repeaters from the routing info
ist

In 10_ZWave.pm ist das Abrufen der neighborlist hart mit 0101 als Parameter codiert.
if($type eq "get") {
      # GET_ROUTING_TABLE_LINE, include dead links, non-routing neigbors
      $cmdList{neighborList}{fmt} = "80${id}0101";
Wenn man hier das Bit für bRemoveNonReps weglässt, also 0100 einträgt wird sowohl der Controller als auch mein WakeUp-Gerät gemeldet.

Der Controller wird also anscheinend als non-repeater betrachtet, wobei mir nicht klar ist ob der Controller wirklich als repeater agieren würde wenn zwei Geräte die sich nicht direkt empfangen können assoziiert werden, obwohl ich das schon so erwarten würde...

Warum einige Geräte das jetzt unterschiedlich melden ist mir aber weiterhin unklar.

Vielleicht hilft das ja schon mal etwas weiter.

Gruß,
Andreas.

Zitat von: A.Harrenberg am 24 November 2015, 22:12:11
Wenn man hier das Bit für bRemoveNonReps weglässt, also 0100 einträgt wird sowohl der Controller als auch mein WakeUp-Gerät gemeldet.

Bei meinem 400er-Stick ändert das nichts an der Meldung des Controllers. Wo in der Standardabfrage der Controller enthalten ist, bleibt er auch bei 0100 drin; wo er fehlt, fehlt er auch bei 0100 weiterhin.

Guten Morgen Christian,

Zitat von: krikan am 25 November 2015, 07:07:00
Bei meinem 400er-Stick ändert das nichts an der Meldung des Controllers. Wo in der Standardabfrage der Controller enthalten ist, bleibt er auch bei 0100 drin; wo er fehlt, fehlt er auch bei 0100 weiterhin.

hmm, das verstehe ich dann jetzt so gar nicht mehr...

Dachte das konnte zur Lösung des Problems beitragen, jetzt wirft es zumindest für mich mehr Fragen auf als es Antworten ermöglicht....

Keine weiteren Ideen,
Andreas.

Zitat von: A.Harrenberg am 25 November 2015, 07:23:14
das verstehe ich dann jetzt so gar nicht mehr...

Geht mir nicht anders. Wir bräuchten vermutlich mal ein Doku für den 500er Chipsatz. Ich glaube aber, dass die Meldung/Nicht-Meldung des Controllers in neigborList nicht problematisch ist. Aber.....

Hallo allerseits,

viel habe ich bisher nicht beizutragen. OpenHAB (mit HABmin) habe ich vorerst aufgegeben,
ich hätte anscheinend alles wieder reinkludieren müssen. Da ist mir der Aufwand noch
deutlich zu hoch.

Fortschritte gab es aber mit Domoticz, das benutzt ja OZW als Unterbau.
Folgende Topologie konnte ausgelesen werden:
topo: node=1 3,8,11,13,16,17,18,19,20,24,25,26,28
topo: node=2 4,5,8,9,11,13,15,16,17,18,20,24,26,27,28,29
topo: node=3 1,5,7,8,9,11,13,14,15,16,17,18,19,20,22,24,25,26,28,29
topo: node=4 2,5,8,9,11,16,24,25
topo: node=5 2,3,4,7,8,9,11,13,14,16,17,22,24,25,26,27,28,29
topo: node=7 3,5,8,9,13,14,15,16,17,18,20,22,24,25,26,28,29
topo: node=8 1,2,3,4,5,7,9,11,13,14,15,16,17,18,20,22,24,25,26,28,29
topo: node=9 2,3,4,5,7,8,11,13,14,15,16,17,18,20,22,24,25,26,27,28,29
topo: node=15 2,3,7,8,9,13,16,17,18,19,20,22,24,25,26,28,29
topo: node=16 1,2,3,4,5,7,8,9,13,15,17,18,19,20,22,24,25,26,27,28,29
topo: node=18 1,2,3,7,8,9,13,15,16,17,19,20,21,22,24,26,27,28,29
topo: node=21 13,17,18,20,22,24,25,26,27
topo: node=22 3,5,7,8,9,11,13,15,16,17,18,20,21,24,25,26,28,29
topo: node=24 1,2,3,4,5,7,8,9,11,13,15,16,17,18,20,21,22,25,26,27,28,29
topo: node=25 1,3,4,5,7,8,9,11,13,15,16,17,20,21,22,24,26,27,28,29
topo: node=26 1,2,3,5,7,8,9,13,15,16,17,18,19,20,21,22,24,25,27,28
topo: node=28 1,2,3,5,7,8,9,13,15,16,17,18,19,20,22,24,25,26,27,29
topo: node=29 2,3,5,7,8,9,11,13,15,16,17,18,20,22,24,25,28

Den Stick habe ich dann wieder mit FHEM betrieben und siehe da:
Bis auf die ID1 identisch. Also irgendwas liest man da nur noch nichts aus.
Warum kann man eigentlich auf dem Controller (ID1) keine Neighborlist lesen?

Oben ausgelesene Topologie macht übrigens nach den Geräteabständen Sinn.

Den gesamten Init-Log von Domoticz/OZW/Aeotec-Stick würde ich auch gern
weitergeben falls erwünscht, allerdings nicht hier öffentlich wegen der HomeID usw.

Gruß,
Thomas

Hallo Thomas,

Interesse hätte ich schon an den Logs, wenn es die ozw-logs aus Domoticz mit höchstem Loglevel sind (im Log vieeele hex-codes).
Jedoch bräuchte ich auch ein FHEM Log mit verbose 5 bei ZWDongle für die Abfrage der neigbourList zumindest für einen Node den FHEM ohne, aber ozw mit ID1 meldet. Ansonsten ist das nicht so aussagekräftig.

Es würde evtl. auch schon der Log-Auszug aus ozw im Vergleich zu FHEM für einen betroffenen Node jeweils mit Abfrage/Antwort reichen, wenn Du die kompletten Daten nicht so gerne herausgeben möchtest.

Und Du solltest nicht die Topologie nach Wechsel ozw zu FHEM umgestellt haben.

Gruß, Christian

Hallo Christian,

nach o.g. Topologie hab ich mal ID3 abgefragt:
2015.11.25 18:09:18 2: ZWave get ID003 neighborList
2015.11.25 18:09:18 5: ZWDongle_Write 00 80030101
2015.11.25 18:09:18 5: SW: 010600800301017a
2015.11.25 18:09:18 4: ZWDongle_ReadAnswer arg:neighborList regexp:^0180
2015.11.25 18:09:18 5: ACK received, removing 010600800301017a from dongle sendstack
2015.11.25 18:09:18 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 0180d0c1a21b00000000000000000000000000000000000000000000000000
2015.11.25 18:09:18 5: SW: 06
2015.11.25 18:09:18 4: ZWDongle_ReadAnswer for neighborList: 0180d0c1a21b00000000000000000000000000000000000000000000000000


Wie kann ich dir das Log zukommen lassen? Ich hoffe es ist ausreichend. Mehr LogLevel habe ich in Domoticz
nicht gefunden und Änderungen an der options.xml von ozw wurden bisweilen ignoriert.

Gruß,
Thomas

Die Logs von Thomas korrespondieren mit Andreas Erkenntnissen aus #51:
ozw setzt bei Abfrage von GetRoutingInfo andere Parameter. ozq fragt mit 80xy0000 ab, während FHEM 80xy0101 absetzt. Dass die Ergebnisse abweichen, erklärt sich daraus automatisch.

Warum die Abfrageergebnisse bei verschiedenen Chipsätzen der Controller abweichen, ist mir weiterhin unklar.

Was mir bei ozw (erneut) auffällt, aber den Sinn nicht erkenne:
Es werden die Routen bei Systemstart manuell gelöscht und neu gesetzt (ZW_DeleteReturnRoute und ZW_AssignReturnRoute).
Für jede Abfrage/Antwort-Kombination werden die Laufzeiten ermittelt. zway macht das auch.

Bei HABmin wird erklärt, was bei einem "Healing" passiert:

ZitatThe heal performs the following steps:

    - Ping the node to see if it's awake
    - Update all the neighbours so that all nodes know who is around them
    - Update the associations so that we know which nodes need to talk to others
    - Update the routes between devices that have associations set
    - Retrieve the neighbour list so that the binding knows who's out there
    - Ping the node to see if it's awake
    - Save the device files

Vielleicht macht ozw einen Teil davon jedesmal vorab um auf eine "geänderte" Umgebung zu reagieren.
Sicherheitshalber? Andere machen das "Healing" ja einmal pro Tag default.

https://github.com/cdjackson/HABmin/wiki/Z-Wave-Network-Healing

Hi Christian,

Zitat von: krikan am 25 November 2015, 20:22:00
Warum die Abfrageergebnisse bei verschiedenen Chipsätzen der Controller abweichen, ist mir weiterhin unklar.

Du hast in #28 aber auch gesagt das Du einer Node ein neighborUpdate gemacht hast und danach der Controller wieder dabei war, damit wäre der Chipsatz als alleiniger Verursacher ja eigentlich raus.

Da ich mich bisher mit Routen nicht beschäftigt habe, wie lese ich denn eine Route aus?

Die Neighborlist sagt ja noch nichts darüber aus wie die Route dann aussieht, besonders wenn es mehr als ein "Hop" wird. Soweit ich das verstanden habe "baut" der Controller sich seine Route anhand der Neighborlist, da er ja alle kennt, aber wie macht eine Node das?

Gruß,
Andreas.

Zitat von: A.Harrenberg am 26 November 2015, 07:45:02
Du hast in #28 aber auch gesagt das Du einer Node ein neighborUpdate gemacht hast und danach der Controller wieder dabei war, damit wäre der Chipsatz als alleiniger Verursacher ja eigentlich raus.

Der Controller war vor dem neigborUpdate drin und nachher auch noch. Mein Satz stand damit im Zusammenhang, dass FHEM "verdächtigt" wurde, nach einer Codeumstellung andere Ergebnisse zu liefern

ZitatDa ich mich bisher mit Routen nicht beschäftigt habe, wie lese ich denn eine Route aus?

Im Zusammenhang mit Explorer Frames habe ich danach gesucht, aber keine sinnvollen Infos gefunden. Also auch sehr wenig Ahnung. Kenne aber keine Funktion zum Auslesen, ausser die 0x80: GET_ROUTING_TABLE_LINE (400er Chipsatz: 0x80: GetRoutingInfo mit mehr Parametern). Und die oben genannten zum Löschen und Setzen, deren Sinn ich immer noch nicht verstanden habe und bisher als alte "Zöpfe" betrachtet habe.

@Toms01: Bisher von mir unterstellt: Der Betrieb mit ozw hat nach Wechsel zu FHEM keine Verbesserung Deines Problems gebracht. Ist das korrekt?

Hi Christian,

Zitat von: krikan am 26 November 2015, 09:12:00
Der Controller war vor dem neigborUpdate drin und nachher auch noch. Mein Satz stand damit im Zusammenhang, dass FHEM "verdächtigt" wurde, nach einer Codeumstellung andere Ergebnisse zu liefern

ok, dann habe ich das falsch verstanden.

Zitat von: krikan am 26 November 2015, 09:12:00
Im Zusammenhang mit Explorer Frames habe ich danach gesucht, aber keine sinnvollen Infos gefunden. Also auch sehr wenig Ahnung. Kenne aber keine Funktion zum Auslesen, ausser die 0x80: GET_ROUTING_TABLE_LINE (400er Chipsatz: 0x80: GetRoutingInfo mit mehr Parametern). Und die oben genannten zum Löschen und Setzen, deren Sinn ich immer noch nicht verstanden habe und bisher als alte "Zöpfe" betrachtet habe.

Ok, das tröstet mich ein wenig das Du da auch keine weiteren Informationen hast. Ich denke ich schau mir noch mal die Erklärung von Paetz an, vielleicht kann man da noch was reindeuten ,-)

Gruß,
Andreas.

Zitat von: A.Harrenberg am 26 November 2015, 10:50:12
Ich denke ich schau mir noch mal die Erklärung von Paetz an, vielleicht kann man da noch was reindeuten ,-)

http://razberry.z-wave.me/docs/zwayDev.pdf unter 2.3 S. 27 steht auch etwas. Macht mich aber nicht schlauer.

Zitat von: krikan am 26 November 2015, 09:12:00
@Toms01: Bisher von mir unterstellt: Der Betrieb mit ozw hat nach Wechsel zu FHEM keine Verbesserung Deines Problems gebracht. Ist das korrekt?

Das muss ich erst testen, da der Stick temporär zentral im Haus gelegen unter Domoticz/ozw läuft.
Sobald er an den FHEM-Platz umgezogen ist, ein "Netzwerk-Heal' ausgeführt wurde, kann ich das ausprobieren.
Alles andere funktioniert(e) ja.
Bin aber momentan arbeitstechnisch eingebunden, kann also noch 1-2 Tage dauern.

Aber nochmal zur Sicherheit: Ein bei einem batteriebetriebenen Gerät manuell ausgelöstes ZW_APPLICATION_UPDATE sollte definitiv durch das ganze Netz
geroutet werden können (ohne direkten Kontakt zum Controller), oder? Eventuell liegt es ja an den hinzugefügten AEOTEC Repeatern, vielleicht "verschlucken"
die ja irgendwelche Informationen.

Zitat von: toms01 am 26 November 2015, 12:12:02
Ein bei einem batteriebetriebenen Gerät manuell ausgelöstes ZW_APPLICATION_UPDATE sollte definitiv durch das ganze Netz
geroutet werden können (ohne direkten Kontakt zum Controller), oder?

Vermute nein. Warum auch? Durch das ganze Netz gehen ohne korrekt gesetzte Route bei einem Slave mWn nur Explorer Frames. Dann sind wir wieder bei falschen Routen....

ZitatEventuell liegt es ja an den hinzugefügten AEOTEC Repeatern, vielleicht "verschlucken"
die ja irgendwelche Informationen.

Möglich. Hierzu gab es vor kurzem einen Thread in Bezug auf ZWave+ mit Antwort vom Hersteller. Müsstest Du mal suchen.

Zitat von: krikan am 26 November 2015, 14:16:04
Vermute nein. Warum auch? Durch das ganze Netz gehen ohne korrekt gesetzte Route bei einem Slave mWn nur Explorer Frames. Dann sind wir wieder bei falschen Routen....

öhm, sorry - ich muss da einfach nochmal nachfragen, möchte das gern ansatzweise verstehen:

Wenn
- Fernbedienung korrekt assoziiert ist mit Controller
- Routen angenommen ok sind
- Fernbedienung kein direkten Kontakt (also nur indirekt über andere Nodes) mit Controller hat
müsste dann ZW_APPLICATION_UPDATE ankommen?

Sind dann Broadcasts an ID255 automatisch "Explorer Frames" oder wird da nur alles in der Neighborlist "abgearbeitet"?

@Thomas:
Keine Ahnung, ob ZW_APPLICATION_UPDATE per Broadcast läuft. Wird Broadcast geroutet? Falls ja, warum wurde dann NWI und Explorer Frames eingeführt, man hätte einfach Broadcast nutzen können?
In Doku findet sich bspw.:
"The routing slave can send unsolicited and non-routed broadcasts, singlecasts and multicasts.
Singlecasts can also be routed. [...] A received multicast or broadcast
results in a response route without routing."
Meine Vermutung daraus ist vermutlich klar, als Wissen würde ich es nicht bezeichnen.

@all
Abfrage der neigborList laut den mir vorliegenden Logs:
ozw, openhab: 80xy000003
zway: 80xy0000
funcId verstehe ich nun nicht mehr. ozw und openhab setzen die fest auf 03. zway setzt gar nichts. funcId=callbackId bin ich nicht mehr sicher.

@Thomas
Habe jetzt zu Hause noch mal meine gesammelten Notizen durchgeschaut:
- Broadcastnachrichten (Empfänger=alle Nodes) werden nicht geroutet. Jeder Node, der die Nachricht empfangen kann und will, kann sie verarbeiten. Mangels Routing eingeschränkte Reichweite.
- Explorer Frames / NWI  werden von allen Nodes mit Explorer Frames-Unterstützung verarbeitet und weitergeleitet.
- NIF wird in alter Doku (2002) als Broadcastnachricht bezeichnet. Ob APPLICATION_UPDATE auch per Broadcast oder Singlecast mit Routing abläuft, ist mir unbekannt. Tippe Broadcast, weil es zu Deinem Problem passen würde. Explorer Frames schließe ich aus.

Also Broadcast ungleich Explorer Frames.

Danke nochmals.

Habs hier
https://community.openhab.org/t/ge-switch-applicationupdate-message-to-trigger-rule/3562
in #2 gelesen. ApplicationUpdate wird nicht geroutet.

Also hab ich eigentlich kein Problem in diesem Sinne? Um neue Configs anzuschubsen bedarf es einfach Glück
um den Controller mit ApplicationUpdate zu erreichen?

Nachtrag:
Laut gedacht _kann_ das per Routing ja auch nicht funktionieren. Sonst würde ich ja nie eine Assoziation setzen können,
wenn das Ziel nicht bekannt ist

Nachtrag2:
Wie (besser wann) werden die Configs zu einem batteriebetriebenen Gerät gesendet?
Bei/nach einer Wakeup-Notification,oder? Diese wird auch manuell ausgelöst bei einem ApplicationUpdate vom Gerät.
Kommt das nicht an, dann werden die Configs spätestens bei dem gesetzen WakeupIntervall gesetzt.
Die Wakeup-Notification geht lt. Assoziation geroutet an den Controller. Falsch?

Nachtrag3:
Wobei man bei FHEM per WakeupIntervall ja setzen kann an wen die Meldung gehen soll.
Diese Zielsetzung habe ich übrigens bei z.B. Domoticz nicht gefunden, was wird dort als "Wakeup-Ziel"
angesehen? Der Default-Wert? Oftmals ja ID1 oder Broadcast

Nachtrag4:
Hierbei fragt sich, ob dann die Wakeup-Notification an ID1 auch per "Broadcast" versendet wird wie an ID255.
Dann wäre ja wieder nicht sichergestellt, dass diese Meldung auch ankommt.

Hallo Thomas!

Zitat von: toms01 am 26 November 2015, 21:15:01
Also hab ich eigentlich kein Problem in diesem Sinne? Um neue Configs anzuschubsen bedarf es einfach Glück
um den Controller mit ApplicationUpdate zu erreichen?

Nicht unbedingt Glück, sondern ausreichende Nähe zu Deinem Controller

ZitatWie (besser wann) werden die Configs zu einem batteriebetriebenen Gerät gesendet?
Bei/nach einer Wakeup-Notification,oder?

Ja, siehe http://www.fhemwiki.de/wiki/Z-Wave#Ger.C3.A4te-Besonderheiten

ZitatKommt das nicht an, dann werden die Configs spätestens bei dem gesetzen WakeupIntervall gesetzt.

Nein, gesendet ist gesendet. Die Daten gehen dann quasi verloren und Du musst die Config neu machen.

ZitatDie Wakeup-Notification geht lt. Assoziation geroutet an den Controller. Falsch?

Wakeup-Notification geht geroutet an Controller, wenn der als Empfänger der Nachricht eingestellt ist. Ist Broadcast 255 -was bei vielen Geräten standardmäßig eingestellt ist- nicht geändert, dann ungeroutet.
-> set <device> wakeupInterval

ZitatDiese Zielsetzung habe ich übrigens bei z.B. Domoticz nicht gefunden, was wird dort als "Wakeup-Ziel"
angesehen? Der Default-Wert? Oftmals ja ID1 oder Broadcast

Setzen vermutlich wmi automatisch auf Controller. ozw, openhab,... koppeln den User mehr von den ZWave-Interna ab. Das oben von Dir zitierte Healing, kann man auch mit FHEM machen; man muss es nur einrichten. Ich will z.B. nicht, dass so etwas automatisch abläuft; möchte die volle Kontrolle haben. Das ist auch einer der Gründe, warum ich bei FHEM gelandet bin. Ich werde hier nicht vom Programm bevormundet  ;) .

Zitat
Hierbei fragt sich, ob dann die Wakeup-Notification an ID1 auch per "Broadcast" versendet wird wie an ID255.

Nein, geroutet. Darum ist das auch immer stabiler. Ansonsten könnte man die batteriebetriebenen Geräte nur in Nähe des Controllers betreiben.

Jetzt die neugierige Frage: Kennst Du das FHEMWiki zu Zwave http://www.fhemwiki.de/wiki/Z-Wave? Vieles steht dazu mMn drin. Da ich aber einiges selbst geschrieben habe, ist es evtl. unverständlich, zu kurz, oder... Wenn Du Ergänzungs-/Verbesserungsvorschläge hast, kannst Du die im Wiki gerne aufnehmen bzw. ergänzen. Ich komme dazu momentan nicht.

Gruß, Christian

Hallo Christian,

danke für deine ausfühliche Antworten. Ja ich weiss - RTFM! - sorry dafür, aber das Problem mit dem Broadcast und dem eventuell
dann nicht-ankommen hatte ich dort nicht gefunden oder überlesen.

Ich schau nachher mal ob ich im wakeupIntervall eventuell den Broadcast habe, das würde ja das Ausbleiben der Wakeup-Notification
erklären und somit ist mein Problem gelöst.

Kurz noch zum Problem mit der Controller-Neighborlist:
Würde ihr das Verfahren zur Neighborlist dem des ozw-Projekts o.ä. anpassen, damit man wieder sehen kann welches Gerät
direkt mit dem Controller verbunden ist? Könnte man eine Neighborlist auch am Controller darstellen? (siehe gepostete
ozw-Topologie 1. Zeile)

Zitat von: toms01 am 27 November 2015, 08:27:32
Kurz noch zum Problem mit der Controller-Neighborlist:
Würde ihr das Verfahren zur Neighborlist dem des ozw-Projekts o.ä. anpassen, damit man wieder sehen kann welches Gerät
direkt mit dem Controller verbunden ist? Könnte man eine Neighborlist auch am Controller darstellen? (siehe gepostete
ozw-Topologie 1. Zeile)

Das ist Rudis Entscheidung. Wir könnten ihm zur Erleichterung und Entscheidungshilfe einen Patch liefern. Bin dann aber dafür alle Parameter wählbar zu machen. Letztlich zögere ich persönlich daran zu basteln, da mir immer noch der volle Einblick in ZW_GetRoutingInfo und den Parametern fehlt.

Hi Christian, hi Thomas,

Zitat von: krikan am 27 November 2015, 08:36:23
Das ist Rudis Entscheidung. Wir könnten ihm zur Erleichterung und Entscheidungshilfe einen Patch liefern. Bin dann aber dafür alle Parameter wählbar zu machen. Letztlich zögere ich persönlich daran zu basteln, da mir immer noch der volle Einblick in ZW_GetRoutingInfo und den Parametern fehlt.

das sollte ja machbar sein, die Frage ist wie immer nur die Umsetzung. Da es zwei Parameter mit zwei Möglichkeiten gibt müsste man 4 fest codierte Befehle daraus machen oder dem Benutzer ein Dropdown mit den 4 Möglichkeiten anbieten. Die Beschreibung der beiden Parameter ist jetzt nicht sooo eindeutig, aber mMn doch schon recht verständlich. Der erste Parameter bRemoveBad  sollte die Anzeige von eingetragenen aber nicht (mehr) funktionierenden Routen steuern, der zweite Parameter bRemoveNonReps die Anzeige der "non-Repeater" aka WakeUp-Geräte steuern. Warum beim zweiten Parameter dann auch der Controller ein- oder ausgeschaltet wird ist mir nicht klar.

Den "dritten" Parameter (funcID den ozw und openhab auf 03 setzen) würde ich da rauslassen. Ich habe da mal ein paar Tests mit gemacht und keinerlei Einfluß/Unterschied feststellen können.
Ich denke das diese funcId/CallBackFuntion nur für den internen Aufruf einer CallBackFunktion im GERÄT ist, und wir da über die API gar nicht dran kommen. (Wozu auch...)

Ich seh' aber schon das ich mich demnächst mal etwas mehr mit Routen beschäftigen muss... Nicht nur weil es da so wenige Informationen gibt, sondern auch aus praktischen Gründen da mein RFID-Pad in letzter Zeit häufiger ein Reichweitenproblem hat und ich da mal eine Steckdosenschalter als Router platzieren muss...

Gruß,
Andreas.

Hallo Andreas,

bin mit den 2 Parametern etwas unsicher. Suche mal "INS10682-9 400" für den 400er Chipsatz mit einer Suchmaschine. Demnach kann man bei der Abfrage auch noch wählen, ob nur 9600, 40k, 100k Geräte oder eben alle gemeldet werden. Wie verstehe ich nicht. Zu 9600 Abfrage hatte ich mal etwas gefunden; nur leider anscheinend nicht aufgeschrieben...

ZitatDen "dritten" Parameter (funcID den ozw und openhab auf 03 setzen) würde ich da rauslassen. Ich habe da mal ein paar Tests mit gemacht und keinerlei Einfluß/Unterschied feststellen können.
Ich denke das diese funcId/CallBackFuntion nur für den internen Aufruf einer CallBackFunktion im GERÄT ist, und wir da über die API gar nicht dran kommen. (Wozu auch...)

Könnte passen und schließe mich an. Z-way sollte wissen, wie es geht.

Gruß, Christian

Hi Christian

Zitat von: krikan am 27 November 2015, 09:23:57
bin mit den 2 Parametern etwas unsicher. Suche mal "INS10682-9 400" für den 400er Chipsatz mit einer Suchmaschine. Demnach kann man bei der Abfrage auch noch wählen, ob nur 9600, 40k, 100k Geräte oder eben alle gemeldet werden. Wie verstehe ich nicht. Zu 9600 Abfrage hatte ich mal etwas gefunden; nur leider anscheinend nicht aufgeschrieben...

muss ich mir mal von zu Hause anschauen, wird aber 'ne Woche dauern...
Das mit den 9600 hatte ich auch schon mal gesehen, das war bei dem zweiten Parameter. Ich bin davon ausgegangen das der Wert bit-codiert ist und habe mal mit 0x02, 0x04 und 0x08 probiert, hatte aber jedesmal nur den gleichen Effekt als ob ich 0x01 gesetzt habe. Da habe ich dann aufgehört zu testen da es anscheinend eben nicht bitcodiert ist...

Gruß,
Andreas.

Neu:
- get neighborList in ZWave verwendet ab sofort 0100 statt bisher 0000, also "no dead links, include repeater". Bisher war es "no dead links, no repeater". Syntax bleibt gleich, also ohne Optionen.
- ZWDongle hat wieder eine neighborList, usage: "get ZWDongle neighborList [noRepeater] [includeDead] nodeId"

Mein altes Goodway ignoriert beide Optionen: repeater werden immer gemeldet, und Tote (d.h. welche mit isFailedNode = yes) auch. Der zme respektiert noRepeater, tote Knoten habe ich nicht probiert.

Apropos INS10682:
- kriegt man dieses Dokument auch als PDF? Ich habe nur online-reader gefunden.
- solange ich nicht weiss, welche Nummer die 9600-er Parameter haben, kann ich es auch nicht einbauen. Wer Info hat...

Vielen Dank an alle beteiligten Personen!

Ich bin übrigens weiter, es war die ID255 (Broadcast) als Wakeup-Ziel eingetragen.
Jetzt mit ID1 kommt die Notification an  :)

Allerdings bekomme ich bei der Fernbedienung kein funktionierendes Neighbor-Update hin:

2015.11.27 17:21:13 2: ZWave set ID013_RC_KINO neighborUpdate
2015.11.27 17:24:48 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 0004000d028407
2015.11.27 17:24:48 5: SW: 06
2015.11.27 17:24:48 5: ZWDongle_1 dispatch 0004000d028407
2015.11.27 17:24:48 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:0d ARG:028407
2015.11.27 17:24:48 5: ZWDongle_Write 00 480d
2015.11.27 17:24:48 5: SW: 010400480dbe
2015.11.27 17:24:48 5: ACK received, removing 010400480dbe from dongle sendstack
2015.11.27 17:24:48 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00480221
2015.11.27 17:24:48 5: SW: 06
2015.11.27 17:24:48 5: ZWDongle_1 dispatch 00480221
2015.11.27 17:24:48 4: ZWDongle_1 CMD:ZW_REQUEST_NODE_NEIGHBOR_UPDATE ID:21 ARG:
2015.11.27 17:24:48 4: ZWDongle_1 ZW_REQUEST_NODE_NEIGHBOR_UPDATE started
2015.11.27 17:24:48 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 0004000d03800364
2015.11.27 17:24:48 5: SW: 06
2015.11.27 17:24:48 5: ZWDongle_1 dispatch 0004000d03800364
2015.11.27 17:24:48 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:0d ARG:03800364
2015.11.27 17:24:58 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00480223
2015.11.27 17:24:58 5: SW: 06
2015.11.27 17:24:58 5: ZWDongle_1 dispatch 00480223
2015.11.27 17:24:58 4: ZWDongle_1 CMD:ZW_REQUEST_NODE_NEIGHBOR_UPDATE ID:23 ARG:
2015.11.27 17:24:58 4: ZWDongle_1 ZW_REQUEST_NODE_NEIGHBOR_UPDATE failed

Dauert auch recht lange bis das 'failed' kommt.
Bei den strombetriebenen Geräten funktioniert alles.

Zitat von: rudolfkoenig am 27 November 2015, 11:25:59
Neu:
- get neighborList in ZWave verwendet ab sofort 0100 statt bisher 0000, also "no dead links, include repeater". Bisher war es "no dead links, no repeater". Syntax bleibt gleich, also ohne Optionen.
- ZWDongle hat wieder eine neighborList, usage: "get ZWDongle neighborList [noRepeater] [includeDead] nodeId"

Irgendwie habe ich da einen Knoten im Kopf. Meiner Meinung stimmt etwas bei den Angaben nicht; scheinen verdreht (0=enthalten , 1=entfernen).

neigborList bei ZWave:
bisher: 0101 -> entferne deadNodes und entferne nonRepeater (Kommentar im alten Code  war mMn falsch); batterbetriebe Devices wurden nicht als neigbor angezeigt
neu: 0100 -> entferne deadNodes und zeige nonRepeater; batteriebetriebene Devices werden als neihbor angezeigt

neigorList bei ZWDongle:
noRepeater -> schließt batteriebetriebene Geräte aus
includeDead -> hat bei meinem Vision keine Auswirkung, deadNodes werden immer angzeigt

Zitatbatteriebetriebene Devices werden als neihbor angezeigt

Hmm. Ich bin nach den zway Quellen gegangen, da heisst dieser Flag (falls gesetzt) remove_repeaters.
In OpenZwave heisst es "remove non repeater", was sinnvoller waere.
Bist du sicher, dass letzteres gilt? Falls ja, wuerde ich ZWave wieder auf 0101 aendern, und das ZWDongle Flag bzw. default umbenennen.

Habe das jeweils mit meinem Vision Stick probiert. In alter 10_ZWave-Fassung (0101) waren batteriebetriebene Devices in neighborList nicht enthalten. In neuer Fassung (0100) sind sie drin. Gleiches Spiel bei ZWDongle. Also laut Test relativ sicher.

Wundere mich auch, warum deadNodes keine Auswirkung hat und experimentiere noch. Aus zwapi lese ich: BYTE bRemove. Daraus hänge ich noch der Vermutung von Andreas hinterher, dass die Einstellungen in einem Byte vorgenommen werden müssen, statt in 2...

Zitat von: krikan am 28 November 2015, 09:27:37
Wundere mich auch, warum deadNodes keine Auswirkung hat und experimentiere noch. Aus zwapi lese ich: BYTE bRemove. Daraus hänge ich noch der Vermutung von Andreas hinterher, dass die Einstellungen in einem Byte vorgenommen werden müssen, statt in 2...

Habe jetzt mit diversen Kombinationen bis ffff getestet -> keine Auswirkungen in Rohnachrichten beim Vision, außer, dass sobald im 2. Byte das 01 enstprechende Bit gesetzt ist, die batteriebetriebenen Geräte (noRepeater) nicht gemeldet werden.

ZitatFalls ja, wuerde ich ZWave wieder auf 0101 aendern, und das ZWDongle Flag bzw. default umbenennen.

Ja.

Nach etwas gruebeln: default bleibt 0100, d.h. es werden keine "toten" Knoten angezeigt (soweit das ueberhaupt funktioniert), aber non-Repeating Geraete werden angezeigt. Sinn: damit sehe ich bei einem Repeating Geraet auch die Batteriebetriebene als Nachbar, d.h. ich kann damit rechnen, dass sie ueber dieses Geraet geroutet werden.

Im ZWDongle ist die Voreinstellung auch 0100, und die Option heisst onlyRep. includeDead habe ich entfernt, um doofe Fragen zu vermeiden: mWn gibt es z.Zt. kein dongle, was diesen Flag beachtet.

Einwaende?

ZitatEinwaende?

Ja,
könntest Du das nicht in ZWDongle excludeDead -von mir aus stillweigend- drin lassen. Das sind nämlich laut zwapi "bad routes" und keine deadNodes, wie ich irtümlich annahm. Ein Zusammenhang mit "isFailedNode -> yes" ist mMn nur indirekt gegeben. Nur wenn die Route mit dem toten Node zuletzt vom Dongle genutzt wurde, kann sie auch als "bad" markiert sein. Enthält die Standardroute zum Gerät aber nicht den toten Node, dann ist sie evtl. noch nicht als "bad"markiert. Die zuletzt funktionierende Route wird mWn solange als Standard genutzt, bis sie nicht mehr funktioniert. Erst dann kommen die anderen Routen zum Zug. Mir fehlt da momentan die Idee für ein Testsetup.

Habe excludeDead eingebaut.

Ich weiss erstmal nicht weiter, ich muss wohl meinen Feldtest nochmal unter einem ozw-Unterbau erweitern - leider.
Die Wakeup-Notifications kamen heute Mittag plötzlich nach 13:17 Uhr nicht mehr. Kurz davor wurde der Batterie-Status auch
nicht mehr gesendet. Erst nach dem Application_Update am Gerät direkt am Controller mit erneut gesetzem Wakeup-Intervall
gings weiter. Vielleicht hätte auch nur das Application_Update gereicht.

2015-11-27_20:19:25 ID013_RC_KINO wakeupReport: interval 1680 target 1
2015-11-27_21:19:10 ID013_RC_KINO wakeup: notification
2015-11-27_21:19:11 ID013_RC_KINO battery: 100 %
2015-11-27_21:47:22 ID013_RC_KINO wakeup: notification
2015-11-27_21:47:22 ID013_RC_KINO battery: 100 %
2015-11-27_22:15:34 ID013_RC_KINO wakeup: notification
2015-11-27_22:15:34 ID013_RC_KINO battery: 100 %
2015-11-27_22:43:45 ID013_RC_KINO wakeup: notification
2015-11-27_23:11:57 ID013_RC_KINO wakeup: notification
2015-11-27_23:11:57 ID013_RC_KINO battery: 100 %
2015-11-27_23:40:09 ID013_RC_KINO wakeup: notification
2015-11-27_23:40:09 ID013_RC_KINO battery: 100 %
2015-11-28_00:08:21 ID013_RC_KINO wakeup: notification
2015-11-28_00:08:21 ID013_RC_KINO battery: 100 %
2015-11-28_00:36:32 ID013_RC_KINO wakeup: notification
2015-11-28_00:36:32 ID013_RC_KINO battery: 100 %
2015-11-28_01:04:43 ID013_RC_KINO wakeup: notification
2015-11-28_01:04:44 ID013_RC_KINO battery: 100 %
2015-11-28_01:32:55 ID013_RC_KINO wakeup: notification
2015-11-28_01:32:55 ID013_RC_KINO battery: 100 %
2015-11-28_02:01:06 ID013_RC_KINO wakeup: notification
2015-11-28_02:01:06 ID013_RC_KINO battery: 100 %
2015-11-28_02:29:18 ID013_RC_KINO wakeup: notification
2015-11-28_02:29:18 ID013_RC_KINO battery: 100 %
2015-11-28_02:57:30 ID013_RC_KINO wakeup: notification
2015-11-28_02:57:30 ID013_RC_KINO battery: 100 %
2015-11-28_03:25:42 ID013_RC_KINO wakeup: notification
2015-11-28_03:25:42 ID013_RC_KINO battery: 100 %
2015-11-28_03:53:54 ID013_RC_KINO wakeup: notification
2015-11-28_03:53:55 ID013_RC_KINO battery: 100 %
2015-11-28_04:22:06 ID013_RC_KINO wakeup: notification
2015-11-28_04:22:06 ID013_RC_KINO battery: 100 %
2015-11-28_04:50:19 ID013_RC_KINO wakeup: notification
2015-11-28_04:50:19 ID013_RC_KINO battery: 100 %
2015-11-28_05:18:30 ID013_RC_KINO wakeup: notification
2015-11-28_05:18:30 ID013_RC_KINO battery: 100 %
2015-11-28_05:46:41 ID013_RC_KINO wakeup: notification
2015-11-28_05:46:41 ID013_RC_KINO battery: 100 %
2015-11-28_06:14:52 ID013_RC_KINO wakeup: notification
2015-11-28_06:14:52 ID013_RC_KINO battery: 100 %
2015-11-28_06:43:05 ID013_RC_KINO wakeup: notification
2015-11-28_06:43:06 ID013_RC_KINO battery: 100 %
2015-11-28_07:11:18 ID013_RC_KINO wakeup: notification
2015-11-28_07:11:18 ID013_RC_KINO battery: 100 %
2015-11-28_07:39:30 ID013_RC_KINO wakeup: notification
2015-11-28_07:39:30 ID013_RC_KINO battery: 100 %
2015-11-28_08:07:41 ID013_RC_KINO wakeup: notification
2015-11-28_08:07:42 ID013_RC_KINO battery: 100 %
2015-11-28_08:35:52 ID013_RC_KINO wakeup: notification
2015-11-28_08:35:52 ID013_RC_KINO battery: 100 %
2015-11-28_09:04:03 ID013_RC_KINO wakeup: notification
2015-11-28_09:04:03 ID013_RC_KINO battery: 100 %
2015-11-28_09:32:15 ID013_RC_KINO wakeup: notification
2015-11-28_09:32:15 ID013_RC_KINO battery: 100 %
2015-11-28_10:00:26 ID013_RC_KINO wakeup: notification
2015-11-28_10:00:26 ID013_RC_KINO battery: 100 %
2015-11-28_10:28:38 ID013_RC_KINO wakeup: notification
2015-11-28_10:28:38 ID013_RC_KINO battery: 100 %
2015-11-28_10:56:50 ID013_RC_KINO wakeup: notification
2015-11-28_10:56:50 ID013_RC_KINO battery: 100 %
2015-11-28_11:25:02 ID013_RC_KINO wakeup: notification
2015-11-28_11:25:02 ID013_RC_KINO battery: 100 %
2015-11-28_11:53:13 ID013_RC_KINO wakeup: notification
2015-11-28_11:53:13 ID013_RC_KINO battery: 100 %
2015-11-28_12:21:26 ID013_RC_KINO wakeup: notification
2015-11-28_12:21:26 ID013_RC_KINO battery: 100 %
2015-11-28_12:49:37 ID013_RC_KINO wakeup: notification
2015-11-28_13:17:51 ID013_RC_KINO wakeup: notification
2015-11-28_16:29:54 ID013_RC_KINO CMD: ZW_APPLICATION_UPDATE
2015-11-28_16:30:03 ID013_RC_KINO CMD: ZW_APPLICATION_UPDATE
2015-11-28_17:02:15 ID013_RC_KINO wakeup: notification
2015-11-28_17:02:16 ID013_RC_KINO battery: 100 %
2015-11-28_17:34:30 ID013_RC_KINO wakeup: notification
2015-11-28_17:34:30 ID013_RC_KINO battery: 100 %

Hallo,

falls es noch jemanden interessiert, schreibe ich hier nochmal meine Erkenntnisse zusammen.

- APPLICATION_UPDATE reicht nicht allein um WUN wiederherzustellen, es muss explizit das Wakeup-Intervall neu gesetzt werden
- Bin mir nicht sicher, was das auf der ZME_RC2-Fernbedienung auslöst, es schien vorhin ein anderes NeighborUpdate gewesen zu sein
- Neighbor-Update bei Fibaro Motion Sensor (ähnlicher Abstand) klappt - ZME_RC2 ist immer fehlerhaft (siehe oben)
- Kann zwar nach Rudis Anleitung Befehle an FHEM senden, aber Status-Led blinkt danach immer Orange/Rot oder Blau/Rot,
was wohl nach Manual "Der Befehl on/off ist fehlgeschlagen" heisst.

Gruß
Thomas

Zitat von: toms01 am 29 November 2015, 13:51:53
- APPLICATION_UPDATE reicht nicht allein um WUN wiederherzustellen, es muss explizit das Wakeup-Intervall neu gesetzt werden

Verstehe ich nicht. Wurde das Gerät zwischendurch resetet? Ansonsten dürfte sich nichts automatisch am WakeupInterval ändern.

Das ist ja das was ich auch nicht verstehe, an dem Gerät wurde in der ganzen Zeit bis zum Ausbleiben der WUN nichts verändert.
Klar habe ich an den anderen Komponenten hier und da auch noch ein Neighbor-Update gemacht, weil der Stick an seinen
ursprünglichen Ort zurückgegangen ist.

Wenn das Ding aufhört die WUN zu senden, reicht ein APPLICATION_UPDATE allein nicht aus um das wieder in Gang
zu bringen. Man muss explizit das WUI neu setzen.

Vorhin hat anscheinend nur das Neighbor-Update des Fibaro Motion Sensors gelangt, dass die Fernbedienung wieder seine WUN-Meldung vergessen hat.
Der Sensor funktioniert einwandfrei.