Hallo,
habe mir für einen Test von Z-Wave den ZMEEUZB1-Stick und den Fibarao Dimmer 2 (FGD-212) zugelegt. Security ist aktiviert, der Dimmer ist angelernt. Bedient man den Dimmer zunächst per Schalter, reagiert das Licht und der Status wird in FHEM korrekt aktualisiert. Ist der Dimmer an und schaltet man ihn über FHEM aus, geht er auch aus.
Nur umgekehrt funktioniert es fast nie: Ist der Dimmer aus und schaltet man ihn über FHEM an, dann geht er kurz an und sofort (innerhalb 1 Sekunde) wieder aus. Im Dimmer-Log steht dann:
2016-01-01_17:41:55 Dimmer_WZ on
2016-01-01_17:41:56 Dimmer_WZ off
2016-01-01_17:41:56 Dimmer_WZ reportedState: off
2016-01-01_17:41:57 Dimmer_WZ power: 13.4 W
Da der Dimmer wirklich aus geht (state=off, reportedState=off, transmit=OK), ist das ja so auch stimmig - aber warum tut er das? Ist das eine Entscheidung des Dimmers? Kann oder muss man noch etwas konfigurieren? Oder sendet der Z-Wave-Treiber den alten Zustand noch mal an den Dimmer?
An bekommt ich den Dimmer nur, wenn ich den Befehl "on" über das Webinterface im "richtigen" Abstand zweimal kurz hintereinander absetzte, möglicherweise bevor bestimmte Telegramme vom Dimmer eintreffen.
Grüße,
Jens
Sorry, es sieht so aus, als wäre meine Frage ein Doppel von http://forum.fhem.de/index.php/topic,46030.0.html (http://forum.fhem.de/index.php/topic,46030.0.html), hatte ich vorhin leider beim suchen übersehen, dieser Thread kann also gelöscht werden.
Hallo,
auch mit dem im Thread http://forum.fhem.de/index.php/topic,46030.0.html (http://forum.fhem.de/index.php/topic,46030.0.html) empfohlenen Update auf den aktuellen Stand von FHEM tritt der hier http://forum.fhem.de/index.php/topic,46539.0.html (http://forum.fhem.de/index.php/topic,46539.0.html) beschriebene Effekt unverändert auf.
Hat jemand eine Idee, was man tun kann?
Grüße,
Jens
Hallo Jens,
das liest sich mehr als seltsam. Habe keine Vorstellung, wo das Problem liegen könnte, außer bei Fehlkonfiguration.
Gibt es notify bzw. DOIF, die auf Meldungen reagieren?
Wie hast Du konfiguriert?
Am sinnvollsten sind alle Infos inklusive Logs zu den Schaltvorgängen: http://www.fhemwiki.de/wiki/Z-Wave#Welche_Infos_sollten_Anfragen_im_ZWave-Forum_enthalten.3F
Gruß, Christian
PS: Habe die Threads zum gleichen Thema beim 1. zusammengeführt und den wieder geöfnet, damit das ein wenig übersichtlich bleibt.
Hallo Christian,
danke für die schnelle Antwort und fürs Aufräumen der Threads.
Habe hier mal was zusammen gestellt:
Internals:
CallbackNr 0
Clients :ZWave:
DEF /dev/ttyACM1
DeviceName /dev/ttyACM1
FD 25
MaxSendRetries 3
NAME ZWave
NR 114
PARTIAL
RAWMSG 000400040a320221440000000d0000
ReadTime 1451676436.44974
STATE Initialized
SendRetries 0
SendTime 1451675679.2558
TYPE ZWDongle
WaitForAck 0
ZWave_MSGCNT 29
ZWave_TIME 2016-01-01 20:27:16
homeId xxxxxxxx
nodeIdHex 01
nrNAck 0
Matchlist:
1:ZWave .*
Readings:
2016-01-01 20:12:01 caps Vers:5 Rev:1 ManufID:0115 ProductType:0400 ProductID:0001 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 UNKNOWN_0a 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 UNKNOWN_28 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 UNKNOWN_78 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_ef ZME_FREQ_CHANGE ZME_BOOTLOADER_FLASH UNKNOWN_f5
2016-01-01 20:12:01 homeId HomeId:xxxxxxxx CtrlNodeId:01
2015-12-31 19:03:40 nodeInfo_UNKNOWN_2 node UNKNOWN_2 is not present
2016-01-01 16:34:58 nodeList ZWave UNKNOWN_2 UNKNOWN_3 Dimmer_WZ
2016-01-01 20:12:02 random xx...xx
2016-01-01 20:12:02 state Initialized
2015-12-31 15:07:02 timeouts 0106640f
2016-01-01 16:34:51 version Z-Wave 3.99 STATIC_CONTROLLER
SendStack:
Attributes:
disable 0
icon cul_usb
networkKey xx...xx
room Raspberry,ZWave
verbose 3
Internals:
DEF f77586ab 4
IODev ZWave
LASTInputDev ZWave
MSGCNT 73
NAME Dimmer_WZ
NR 115
STATE dim 99
TYPE ZWave
ZWave_MSGCNT 73
ZWave_RAWMSG 0004000406310504220761
ZWave_TIME 2016-01-01 20:46:09
homeId xxxxxxxx
isWakeUp
lastMsgSent 1451677564.9818
nodeIdHex 04
Readings:
2016-01-01 15:08:06 CMD ZW_APPLICATION_UPDATE
2015-12-31 18:31:19 SECURITY ENABLED
2016-01-01 15:40:25 alarm PowerManagement: Load error, arg 00
2016-01-01 20:45:02 assocGroup_1 Max 1 Nodes ZWave
2016-01-01 20:45:02 assocGroup_2 Max 5 Nodes
2016-01-01 20:45:03 assocGroup_3 Max 5 Nodes
2016-01-01 20:45:03 assocGroup_4 Max 5 Nodes
2016-01-01 20:45:03 assocGroup_5 Max 5 Nodes
2016-01-01 20:45:01 assocGroups 5
2016-01-01 16:33:23 basicReport 00
2016-01-01 20:44:50 configActivePowerReports 10
2016-01-01 20:44:53 configApproximatedPowerAtTheMaximum53 10
2016-01-01 20:44:50 configAssignToggleSwitchStatusToThe22 DeviceChangesStatusOnSwitch0
2016-01-01 20:44:50 configAssociationsInZWaveNetwork27 15
2016-01-01 20:44:51 configAutoCalibrationAfterPowerOn AutoCalibrationPerformedAfter1
2016-01-01 20:44:51 configAutoCalibrationStatus DimmerOperatesOnAutoCalibration1
2016-01-01 20:44:51 configBehaviourOfTheDimmerAfterOVERCUR37 threeAtemptsToTurnOnTheLoad
2016-01-01 20:44:52 configBurntOutBulbDetection 30
2016-01-01 20:44:52 configCommandFramesSentIn2NdAnd3Rd24 0
2016-01-01 20:44:52 configCommandFramesSentIn4ThAnd5Th25 0
2016-01-01 20:44:52 configDimmabilityOfTheLoad LoadRecognizedAsDimmable
2016-01-01 20:44:52 configDoubleClickOption EnableDoubleClick
2016-01-01 20:44:52 configEnableDisableALLONOFF ALLONActiveALLOFFActive
2016-01-01 20:44:53 configForceAutoCalibration idle
2016-01-01 20:44:53 configForcedSwitchOnBrightnessLevel 0
2016-01-01 20:44:54 configIncandescenceLevelOfDimmable3 1
2016-01-01 20:44:54 configIncandescenceTimeOfDimmable4 0
2016-01-01 20:44:54 configInputsButtonSwitchConfiguration MonoStableInputButton
2016-01-01 20:44:54 configLOADERRORAlarmReport SendAnAlarmFrame
2016-01-01 20:44:54 configLoadControlMode trailingEdge
2016-01-01 20:44:55 configMaximumBrightnessLevel 79
2016-01-01 20:44:55 configMethodOfCalculatingTheActive58 powerMeasurementBasedOnThe0
2016-01-01 20:44:55 configMinimumBrightnessLevel 12
2016-01-01 20:44:55 configOVERCURRENTAlarmReport SendAnAlarmFrame
2016-01-01 20:44:56 configOVERHEATAndVOLTAGEDROPAlarm49 SendAnAlarmFrame
2016-01-01 20:44:56 configOVERLOADAlarmReport SendAnAlarmFrame
2016-01-01 20:44:56 configOnOffMode modeSelectedAutomatically
2016-01-01 20:44:56 configPeriodicActivePowerAndEnergy52 3600
2016-01-01 20:44:56 configPowerLimitOVERLOAD 250
2016-01-01 20:44:57 configResponseToGeneralPurposeAlarm ALARMFLASHINGDeviceWillTurnONAnd3
2016-01-01 20:44:57 configResponseToSmokeCOOrCO2Alarm ALARMFLASHINGDeviceWillTurnONAnd3
2016-01-01 20:44:57 configResponseToTemperatureAlarm ALARMDIMMERONDeviceTurnONUpon1
2016-01-01 20:44:57 configResponseToWaterFloodingAlarm ALARMDIMMEROFFDeviceWillTurnOFF2
2016-01-01 20:44:57 configSURGEAlarmReport SendAnAlarmFrame
2016-01-01 20:44:57 configSavingStateBeforePowerFaillure StateSavedAtPowerFailureAll1
2016-01-01 20:44:58 configSceneActivationFunctionality FunctionalityDeactivated
2016-01-01 20:44:58 configSelfMeasurement SelfMeasurementInactive
2016-01-01 20:44:59 configSoftStartFunctionality shortSoftStart01
2016-01-01 20:44:59 configSwitchFunctionalityOfS1AndS2 standardMode
2016-01-01 20:44:59 configTheFunctionOf3WaySwitch 3WaySwitchFunctionForS2Disabled
2016-01-01 20:44:59 configThePercentageOfADimmingStepAt5 1
2016-01-01 20:44:59 configThePercentageOfADimmingStepAt7 1
2016-01-01 20:45:00 configTheValueSentToAssociatedDevices21 0xFFValueIsSentWhichWillSet0
2016-01-01 20:45:00 configTimeDelayOfABurntOutBulb 5
2016-01-01 20:45:00 configTimeOfADimmingStepAtAutomatic6 1
2016-01-01 20:45:00 configTimeOfADimmingStepAtManual8 5
2016-01-01 20:45:01 configTimeOfAlarmState 600
2016-01-01 20:45:01 configTimerFunctionalityAutoOff 0
2016-01-01 16:25:04 config_30 2
2016-01-01 20:27:16 energy 0.13 kWh
2015-12-31 18:31:22 model FIBARO System FGD212 Dimmer 2
2015-12-31 18:31:22 modelConfig fibaro/fgd212.xml
2015-12-31 18:31:22 modelId 010f-0102-1000
2016-01-01 20:46:09 power 188.9 W
2016-01-01 20:46:05 reportedState dim 99
2016-01-01 20:46:05 state dim 99
2016-01-01 20:46:05 transmit OK
2016-01-01 16:33:39 version Lib 3 Prot 4.5 App 3.3 HW 2 FWCounter 1 FW 3.3
2015-12-31 18:38:21 zwavePlusInfo version:01 role:AlwaysOnSlave node:Z-Wave+Node installerIcon:0600 userIcon:0600
secMsg:
Attributes:
IODev ZWave
classes ZWAVEPLUS_INFO BASIC VERSION MANUFACTURER_SPECIFIC SWITCH_MULTILEVEL DEVICE_RESET_LOCALLY ASSOCIATION_GRP_INFO ASSOCIATION POWERLEVEL SECURITY FIRMWARE_UPDATE_MD CRC_16_ENCAP CONFIGURATION SENSOR_MULTILEVEL METER MULTI_CHANNEL_ASSOCIATION MULTI_CHANNEL PROTECTION ALARM SWITCH_ALL APPLICATION_STATUS MARK SCENE_ACTIVATION
icon light_control
room Wohnzimmer,ZWave
secure_classes BASIC DEVICE_RESET_LOCALLY ASSOCIATION SWITCH_MULTILEVEL MULTI_CHANNEL_ASSOCIATION MULTI_CHANNEL CONFIGURATION PROTECTION SWITCH_ALL MARK SCENE_ACTIVATION
vclasses ALARM:05 APPLICATION_STATUS:01 ASSOCIATION:02 ASSOCIATION_GRP_INFO:01 BASIC:01 CONFIGURATION:01 CRC_16_ENCAP:01 DEVICE_RESET_LOCALLY:01 FIRMWARE_UPDATE_MD:03 MANUFACTURER_SPECIFIC:02 METER:03 MULTI_CHANNEL:04 MULTI_CHANNEL_ASSOCIATION:03 POWERLEVEL:01 PROTECTION:02 SCENE_ACTIVATION:01 SECURITY:01 SENSOR_MULTILEVEL:04 SWITCH_ALL:01 SWITCH_MULTILEVEL:03 VERSION:02 ZWAVEPLUS_INFO:02
verbose 3
Ablauf: Dimmer ist aus, Einschalten über FHEM, Dimmer geht kurz an und sofort wieder aus
Zitat
2016.01.01 20:50:10.702 2: ZWave set Dimmer_WZ on
2016.01.01 20:50:10.703 5: Dimmer_WZ: SWITCH_MULTILEVEL is a secured class!
2016.01.01 20:50:10.704 5: Dimmer_WZ SECURITY: 2601FF stored for encryption
2016.01.01 20:50:10.710 4: ZWave get Dimmer_WZ secNonce
2016.01.01 20:50:10.711 5: ZWDongle_Write 0013040298402504 (f77586ab)
2016.01.01 20:50:10.713 5: SW: 010900130402984025041a
2016.01.01 20:50:10.715 4: ZWDongle_ReadAnswer arg:secNonce regexp:^00040004..98
2016.01.01 20:50:10.716 5: ACK received, WaitForAck=>2 for 010900130402984025041a
2016.01.01 20:50:10.722 4: ZWDongle_Read ZWave: sending ACK, processing 011301
2016.01.01 20:50:10.723 5: SW: 06
2016.01.01 20:50:10.725 5: ZWave dispatch 011301
2016.01.01 20:50:10.742 4: ZWDongle_Read ZWave: sending ACK, processing 001304000003
2016.01.01 20:50:10.743 5: SW: 06
2016.01.01 20:50:10.745 5: device ack reveived, removing 010900130402984025041a from dongle sendstack
2016.01.01 20:50:10.745 5: ZWave dispatch 001304000003
2016.01.01 20:50:10.746 4: ZWave CMD:ZW_SEND_DATA ID:00 ARG:0003
2016.01.01 20:50:10.747 4: ZWave transmit OK for 04
2016.01.01 20:50:10.758 4: ZWDongle_Read ZWave: sending ACK, processing 000400040a9880e4cdbf3ba57bb976
2016.01.01 20:50:10.758 5: SW: 06
2016.01.01 20:50:10.761 4: ZWDongle_ReadAnswer for secNonce: 000400040a9880e4cdbf3ba57bb976
2016.01.01 20:50:10.761 4: ZWave CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0a9880e4cdbf3ba57bb976
2016.01.01 20:50:10.764 5: Dimmer_WZ SECURITY: 2601FF set Dimmer_WZ on retrieved for encryption
2016.01.01 20:50:10.765 5: Dimmer_WZ: secEncrypt plain:002601FF enc:2873adc9
2016.01.01 20:50:10.771 4: ZWave set Dimmer_WZ secEncap 8188f3075e8d0761622873adc9e4907386a297ca9c2a
2016.01.01 20:50:10.772 5: ZWDongle_Write 00130417988188f3075e8d0761622873adc9e4907386a297ca9c2a2504 (f77586ab)
2016.01.01 20:50:10.774 5: SW: 011e00130417988188f3075e8d0761622873adc9e4907386a297ca9c2a250485
2016.01.01 20:50:10.813 5: Dimmer_WZ: type=set, cmd=on (2601FF set Dimmer_WZ on )
2016.01.01 20:50:10.833 5: ACK received, WaitForAck=>2 for 011e00130417988188f3075e8d0761622873adc9e4907386a297ca9c2a250485
2016.01.01 20:50:10.833 4: ZWDongle_Read ZWave: sending ACK, processing 011301
2016.01.01 20:50:10.834 5: SW: 06
2016.01.01 20:50:10.836 5: ZWave dispatch 011301
2016.01.01 20:50:10.839 4: ZWDongle_Read ZWave: sending ACK, processing 001304000003
2016.01.01 20:50:10.839 5: SW: 06
2016.01.01 20:50:10.841 5: device ack reveived, removing 011e00130417988188f3075e8d0761622873adc9e4907386a297ca9c2a250485 from dongle sendstack
2016.01.01 20:50:10.842 5: ZWave dispatch 001304000003
2016.01.01 20:50:10.843 4: ZWave CMD:ZW_SEND_DATA ID:00 ARG:0003
2016.01.01 20:50:10.843 4: ZWave transmit OK for 04
2016.01.01 20:50:11.325 4: ZWDongle_Read ZWave: sending ACK, processing 00040004029840
2016.01.01 20:50:11.325 5: SW: 06
2016.01.01 20:50:11.328 5: ZWave dispatch 00040004029840
2016.01.01 20:50:11.329 4: ZWave CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:029840
2016.01.01 20:50:11.339 4: ZWave set Dimmer_WZ sendNonce
2016.01.01 20:50:11.340 5: ZWDongle_Write 0013040a98805dbc064a222c7ff42504 (f77586ab)
2016.01.01 20:50:11.342 5: SW: 01110013040a98805dbc064a222c7ff42504e2
2016.01.01 20:50:11.349 5: ACK received, WaitForAck=>2 for 01110013040a98805dbc064a222c7ff42504e2
2016.01.01 20:50:11.353 4: ZWDongle_Read ZWave: sending ACK, processing 011301
2016.01.01 20:50:11.353 5: SW: 06
2016.01.01 20:50:11.359 5: ZWave dispatch 011301
2016.01.01 20:50:11.375 4: ZWDongle_Read ZWave: sending ACK, processing 001304000003
2016.01.01 20:50:11.375 5: SW: 06
2016.01.01 20:50:11.377 5: device ack reveived, removing 01110013040a98805dbc064a222c7ff42504e2 from dongle sendstack
2016.01.01 20:50:11.378 5: ZWave dispatch 001304000003
2016.01.01 20:50:11.379 4: ZWave CMD:ZW_SEND_DATA ID:00 ARG:0003
2016.01.01 20:50:11.379 4: ZWave transmit OK for 04
2016.01.01 20:50:11.396 4: ZWDongle_Read ZWave: sending ACK, processing 00040004179881d858dec93453f4960c99cb395d399068f5624e40c3
2016.01.01 20:50:11.397 5: SW: 06
2016.01.01 20:50:11.398 5: ZWave dispatch 00040004179881d858dec93453f4960c99cb395d399068f5624e40c3
2016.01.01 20:50:11.399 4: ZWave CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:179881d858dec93453f4960c99cb395d399068f5624e40c3
2016.01.01 20:50:11.402 5: Dimmer_WZ: secDecrypt: decrypted cmd 00260300
2016.01.01 20:50:11.403 5: Dimmer_WZ: secDecrypt: Sequencebyte 0, sequenced 0, secondFrame 0, sequenceCounter 00
2016.01.01 20:50:11.404 5: Dimmer_WZ: secDecrypt: calculated Authentication code 399068f5624e40c3
2016.01.01 20:50:11.404 5: Dimmer_WZ: secDecrypt: parsing 0004000403260300
2016.01.01 20:50:11.405 4: ZWave CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:03260300
Hier noch 'ne Kleinigkeit. Beim Neustart von FHEM erfolgt bei mir das Device-Open zweimal, allerdings ohne erkennbare Nebenwirkungen:
Zitat
2016.01.01 20:11:59 3: Opening ZWave device /dev/ttyACM1
2016.01.01 20:11:59 3: ZWave device opened
2016.01.01 20:12:00 3: Opening ZWave device /dev/ttyACM1
2016.01.01 20:12:00 3: ZWave device opened
Bitte warte mal auf Andreas (A.Harrenberg), den SECURITY-Entwickler, oder Rudi.
Ich sehe in Deinem 5er-Log keinen Ausschaltbefehl von FHEM wie oben im 3er-Log; aber in beiden den reportedState:off. Bin beim Lesen der SECURITY-Logs aber nicht wirklich fit, da ich den Detailablauf nicht verstehe. Beim 3er-Log sieht es ja so aus, als käme der Befehl von FHEM.
Bei den list erkenne ich kein Problem, wobei ich die enorme Anzahl Konfigurationsparameter nicht gecheckt habe.
Gruß, Christian
Hallo Christian,
man sieht das Ausschalten nur im FileLog und nicht im FHEM-Log. Über zusätzliches Logging in 10_ZWave habe ich bereits herausgefunden, dass das Ändern des state-Readings in ZWave_Parse über den Output von ZWave_getHash erfolgt, in dem definitiv das Event state:off enthalten ist. Allerdings habe ich keine Idee, woher diese Daten stammen. Werde warten, bis Andreas oder Rudi einen Blick drauf werfen können.
Grüße,
Jens
Hallo Jens,
frohes neues Jahr!
Tja, für mich sieht das nicht wie ein Problem mit SECURITY aus. Der Befehl wurde sauber verschlüsselt und versendet, die Statusrückmeldung vom Gerät sagt aber "aus"...
Mir scheint das eher von Deiner angeschlossenen Last bzw. der Konfiguration des Dimmers zu kommen. Du hast in den Readings einen "Alarm":
Zitat2016-01-01 15:40:25 alarm PowerManagement: Load error, arg 00
In der Anleitung gibt es dazu auch einen Hinweis:
B) LOAD ERROR
Dimmer 2 is equipped with functionality of detecting the burnt out bulb. In case of such situation, Dimmer 2 sends the notification about
load failure. Described function is not available for values of parameter 58 different than 0. Power variation is detected in accordance with the settings of parameters 15 and 16.
Example:
Parameter 15 set to 30%.
Parameter 16 set to 5 seconds.
Dimmer 2 will detect the change of load at the moment of power variation by 30% compared to standard power consumption (measured during the calibration) and after 5 seconds from brightness level
stabilization.
This function is available only in a control mode compliant with the mode recognized during the calibration (parameter 14 set to 1).
Appearing of an error may be the result of not connecting the load. It may suggest burning out all of the loads connected to the Dimmer 2.
Damaged load should be immediately replaced. After connecting the new load, FIBARO Dimmer 2 will return to normal operation.Du solltest mal die beiden Parameter 15 und 16 auslesen und evtl. anpassen. Da hier der Stromverbrauch im Vergleich zur "Kalibrierung" ausgewertet wird kann es sein das Du evtl. neu kalibrieren muss, falls Du z.B. während der Installation nicht oder mit einer anderen Lampe kalibriert hast.
Ich bin mir relativ sicher das es danach geht .-)
Gruß,
Andreas.
ZitatBeim Neustart von FHEM erfolgt bei mir das Device-Open zweimal, allerdings ohne erkennbare Nebenwirkungen:
Das ist definitiv falsch, bitte klaeren wieso, z.Bsp. mit "attr global verbose 5" beim startup.
Hallo Andreas, hallo Rudi,
ich wünsche euch beiden auch ein frohes neues Jahr!
Was das doppelte Open betrifft, hat "attr global verbose 5" geholfen. Es passiert wenn man am ZWDongle das Attribute "disable=0" hat. Löscht man das Attribut, erfolgt Open nur einmal.
Was den Rest betrifft, haben die letzten Stunden zwar viel Arbeit gemacht, aber das Ergebnis ist unverändert. Habe die Kalibrierung mehrfach ausgelöst, die Parameter 15 und 16 vergrößert, das Device auf Werkseinstellung zurückgesetzt und schließlich auch den Controller, danach den Dimmer wieder angelernt und alles war wie vorher.
Die Bedienung per Schalter funktioniert fehlerfrei. Ein Alarm tritt im Normalbetrieb nicht auf. Der weiter oben gepostete wurde wahrscheinlich geloggt, weil ich die Anschlussklemmen nachträglich unter Spannung nochmal verschraubt habe. Ausschalten über FHEM klappt, Einschalten nur mit Glück und richtigem Doppelklick-Timing.
Grüße,
Jens
Obwohl ich es nicht glaube, dass es die Lösung bringt:
Hast Du mal mit normaler Inklusion (ohne SECURITY) getestet? Gleiches Verhalten?
Falls ja, und Cul ist vorhanden mal mit http://fhem.de/commandref.html#ZWCUL sniffen probieren.
Hi Jens,
kannst Du den Dimmer eventuell mal ohne SECURITY anlernen? An den Befehlen ist zwar soweit alles in Ordnung, aber es köntte vielleicht sein das die Firmware von dem Ding einen Fehler im Zusammenhang mit SECURITY hat.
Ansonsten hätte ich jetzt auch keine weiteren Ideen mehr, außer "kaputt"... ;-(
Gruß,
Andreas.
So langsam werde ich warm mit dem an- und abmelden: Ohne Security ist alles einwandfrei. Das Licht wird fehlerfrei ein- und ausgeschaltet, egal ob über Schalter oder über FHEM. Scheinbar ist dann auch die leichte Rückmeldeverzögerung weg, wenn man über FHEM schaltet.
Beim Betrieb ohne Security möchte ich es aber nur ungern belassen. Der Security-Handshake scheint ja eine knappe Sekunde zu dauern. Kann es sein, dass es dadurch zu dem ungewollten Toggeln kommt?
Habe einen Busware-CUL den ich für FS20 nutzte, aber ist es nicht bei aktivierter Security einfacher ggf. zusätzliches Logging an bestimmten Stellen in ZWave bzw. ZWDongle einzufügen?
Sniffen würde ich nur ohne Security. Jetzt aber wohl unnötig.
Hi Jens,
Zitat von: jensb am 02 Januar 2016, 17:51:02
So langsam werde ich warm mit dem an- und abmelden: Ohne Security ist alles einwandfrei. Das Licht wird fehlerfrei ein- und ausgeschaltet, egal ob über Schalter oder über FHEM. Scheinbar ist dann auch die leichte Rückmeldeverzögerung weg, wenn man über FHEM schaltet.
Beim Betrieb ohne Security möchte ich es aber nur ungern belassen. Der Security-Handshake scheint ja eine knappe Sekunde zu dauern. Kann es sein, dass es dadurch zu dem ungewollten Toggeln kommt?
das sieht dann aber schwer nach einem Fehler in der Firmware des Dimmers aus...
Der Ablauf mit SECURITY dauert deutlich länger als ohne. Zum einen werden deutlich mehr Nachrichten übertragen:
Ohne Security: set + report = 2 Nachrichten plus die Bestätigungen
Mit Security: get nonce + nonce report + verschlüsselter set + nonce request + nonce report + verschlüsselter report = 6 Nachrichten plus die Bestätigungen
Hinzu kommt noch das die Devices anscheinend auch ein wenig länger brauchen um die verschlüsselte Nachricht zu erzeugen.
Zitat von: jensb am 02 Januar 2016, 17:51:02
Habe einen Busware-CUL den ich für FS20 nutzte, aber ist es nicht bei aktivierter Security einfacher ggf. zusätzliches Logging an bestimmten Stellen in ZWave bzw. ZWDongle einzufügen?
Da ist auf der Protokoll-Seite von FHEM nicht viel mehr zu loggen... Der gleiche Set-Befehl den Du jetzt ohne SECURITY nutzt wird verschlüsselt verschickt. Wenn das Gerät darauf anders reagiert dann ist das mit ziemlicher Sicherheit ein Fehler/Problem (in der Firmware) von dem Gerät.
Mit dem von Kirkan vorgeschlagenen "Sniffen" auf Transportebene (also Funkprotokoll) könnte man evtl. sehen ob das Paket vielleicht zwei Mal gesendet wird weil irgendwas an der Übertragung nicht in Ordnung war.
Soll das Gerät denn laut Anleitung irgendwie toggeln können wenn man mehrmal "on" sendet oder mehrfach den Schalter/Taster betätigt? Kannst Du anstatt von "on" auch auf einen bestimmten Dimm-Level springen? Wenn ja, was passiert dann?
Gruß,
Andreas.
Hi Andreas,
es ergibt keinen Unterschied, ob man mit FHEM von aus nach an wechselt oder von aus nach gedimmt. In beiden Fällen wird meist wieder nach aus getoggelt. Für den Dimmer ist es typisch, dass er auf "on" mit "dim 99%" antwortet bzw. mit dem letzten eingestellten Dimmerwert.
Es gibt den Parameter 22 "Assign toggle switch status to the device status" der sich aber nicht auf den beschriebenen Effekt auswirkt. Für Parameter 23 "Double click option - set the brightness level to MAX" gilt das Gleiche.
Merkwürdig bleibt das zuverlässige Abschalten über FHEM und das Verhalten auf den optimal getimeten FHEM-"Doppelklick"-Ein. Ich vermute, dass der 2. Klick irgendwo nach dem Versenden des "verschlüsselten set" Telegramm vom Webfrontend eintrifft und möglicherweise den Hash des Dimmer-Devices so ändert, das die nachfolgenden Telegramme das eigentlich gewünschte bewirken. Hier geht wahrscheinlich etwas mit den Daten durcheinander.
Zitat... könnte man evtl. sehen ob das Paket vielleicht zwei Mal gesendet ...
Das müsste sich dann aber auch im Log wiederfinden oder?
Mein Analyse hat gezeigt, dass "2016.01.01 20:50:11.329 4: ZWave CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:029840" das "state"-Reading auf off zurücksetzt. Was ich nicht überprüfen kann ist, ob der Dimmer zu diesem Zeitpunkt schon den Zustand aus angenommen hat und diesen meldet oder ob der Dimmer erst mit einem der folgenden Telegramme wieder ausgeschaltet wird. Dafür geht das ganze leider zu schnell. Vielleicht sollte ich in ZWave_Parse mal vorübergehend ein dickes Sleep einbauen?
Grüße,
Jens
Hi Jens,
Zitat von: jensb am 02 Januar 2016, 20:27:15
Merkwürdig bleibt das zuverlässige Abschalten über FHEM und das Verhalten auf den optimal getimeten FHEM-"Doppelklick"-Ein. Ich vermute, dass der 2. Klick irgendwo nach dem Versenden des "verschlüsselten set" Telegramm vom Webfrontend eintrifft und möglicherweise den Hash des Dimmer-Devices so ändert, das die nachfolgenden Telegramme das eigentlich gewünschte bewirken. Hier geht wahrscheinlich etwas mit den Daten durcheinander.
das ist unwahrscheinlich. Die Nachricht die versendet wird ist völlig unabhängig vom aktuellen Status des Devices. Die Nachrichten die Du siehst gehören alle zu dem einen Befehl!
Ich habe mal ein paar Kommentare in Dein Log aus Post #3 geschrieben:
2016.01.01 20:50:10.702 2: ZWave set Dimmer_WZ on
2016.01.01 20:50:10.703 5: Dimmer_WZ: SWITCH_MULTILEVEL is a secured class!
2016.01.01 20:50:10.704 5: Dimmer_WZ SECURITY: 2601FF stored for encryption
hier wurde der Befehl 2601FF (26 = Command Class SWITCH_MULTILEVEL, 01 = set, FF = on) "abgefangen" und auf einen internen Stack gelegt.
2016.01.01 20:50:10.710 4: ZWave get Dimmer_WZ secNonce
Zur Verschlüsselung wird eine sogennanten NONCE benötigt, diese wird vom Dimmer angefordert.
(9840: 98 = Command Class SECURITY, 40 = get NONCE)
2016.01.01 20:50:10.711 5: ZWDongle_Write 0013040298402504 (f77586ab)
2016.01.01 20:50:10.713 5: SW: 010900130402984025041a
2016.01.01 20:50:10.715 4: ZWDongle_ReadAnswer arg:secNonce regexp:^00040004..98
2016.01.01 20:50:10.716 5: ACK received, WaitForAck=>2 for 010900130402984025041a
2016.01.01 20:50:10.722 4: ZWDongle_Read ZWave: sending ACK, processing 011301
2016.01.01 20:50:10.723 5: SW: 06
2016.01.01 20:50:10.725 5: ZWave dispatch 011301
2016.01.01 20:50:10.742 4: ZWDongle_Read ZWave: sending ACK, processing 001304000003
2016.01.01 20:50:10.743 5: SW: 06
2016.01.01 20:50:10.745 5: device ack reveived, removing 010900130402984025041a from dongle sendstack
2016.01.01 20:50:10.745 5: ZWave dispatch 001304000003
2016.01.01 20:50:10.746 4: ZWave CMD:ZW_SEND_DATA ID:00 ARG:0003
2016.01.01 20:50:10.747 4: ZWave transmit OK for 04
Hier wurde der Befehl gesendet und die Übertragung vom Dongle und von Dimmer bestätigt
2016.01.01 20:50:10.758 4: ZWDongle_Read ZWave: sending ACK, processing 000400040a9880e4cdbf3ba57bb976
Das ist die angeforderte NONCE (9880.....)
2016.01.01 20:50:10.758 5: SW: 06
2016.01.01 20:50:10.761 4: ZWDongle_ReadAnswer for secNonce: 000400040a9880e4cdbf3ba57bb976
2016.01.01 20:50:10.761 4: ZWave CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0a9880e4cdbf3ba57bb976
2016.01.01 20:50:10.764 5: Dimmer_WZ SECURITY: 2601FF set Dimmer_WZ on retrieved for encryption
2016.01.01 20:50:10.765 5: Dimmer_WZ: secEncrypt plain:002601FF enc:2873adc9
Hier wird der abgegelegte Befehl verschlüsselt, Du erkennst die 2601FF von oben wieder...
2016.01.01 20:50:10.771 4: ZWave set Dimmer_WZ secEncap 8188f3075e8d0761622873adc9e4907386a297ca9c2a
2016.01.01 20:50:10.772 5: ZWDongle_Write 00130417988188f3075e8d0761622873adc9e4907386a297ca9c2a2504 (f77586ab)
Hier wird der verschlüsselte Befehl versendet
2016.01.01 20:50:10.774 5: SW: 011e00130417988188f3075e8d0761622873adc9e4907386a297ca9c2a250485
2016.01.01 20:50:10.813 5: Dimmer_WZ: type=set, cmd=on (2601FF set Dimmer_WZ on )
2016.01.01 20:50:10.833 5: ACK received, WaitForAck=>2 for 011e00130417988188f3075e8d0761622873adc9e4907386a297ca9c2a250485
2016.01.01 20:50:10.833 4: ZWDongle_Read ZWave: sending ACK, processing 011301
2016.01.01 20:50:10.834 5: SW: 06
2016.01.01 20:50:10.836 5: ZWave dispatch 011301
2016.01.01 20:50:10.839 4: ZWDongle_Read ZWave: sending ACK, processing 001304000003
2016.01.01 20:50:10.839 5: SW: 06
2016.01.01 20:50:10.841 5: device ack reveived, removing 011e00130417988188f3075e8d0761622873adc9e4907386a297ca9c2a250485 from dongle sendstack
2016.01.01 20:50:10.842 5: ZWave dispatch 001304000003
2016.01.01 20:50:10.843 4: ZWave CMD:ZW_SEND_DATA ID:00 ARG:0003
2016.01.01 20:50:10.843 4: ZWave transmit OK for 04
Hier ist der verschlüsselte Befehl von Dongel und vom Dimmer bestätigt worden.
2016.01.01 20:50:11.325 4: ZWDongle_Read ZWave: sending ACK, processing 00040004029840
Jetzt will uns der Dimmer etwas verschlüsseltes schicken und benötigt dazu eine NONCE von FHEM
2016.01.01 20:50:11.325 5: SW: 06
2016.01.01 20:50:11.328 5: ZWave dispatch 00040004029840
2016.01.01 20:50:11.329 4: ZWave CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:029840
2016.01.01 20:50:11.339 4: ZWave set Dimmer_WZ sendNonce
Der Befehl zum verschicken der NONCE wird ausgelöst
2016.01.01 20:50:11.340 5: ZWDongle_Write 0013040a98805dbc064a222c7ff42504 (f77586ab)
2016.01.01 20:50:11.342 5: SW: 01110013040a98805dbc064a222c7ff42504e2
Die NONCE wird an den Dimmer verschickt (9880....)
2016.01.01 20:50:11.349 5: ACK received, WaitForAck=>2 for 01110013040a98805dbc064a222c7ff42504e2
2016.01.01 20:50:11.353 4: ZWDongle_Read ZWave: sending ACK, processing 011301
2016.01.01 20:50:11.353 5: SW: 06
2016.01.01 20:50:11.359 5: ZWave dispatch 011301
2016.01.01 20:50:11.375 4: ZWDongle_Read ZWave: sending ACK, processing 001304000003
2016.01.01 20:50:11.375 5: SW: 06
2016.01.01 20:50:11.377 5: device ack reveived, removing 01110013040a98805dbc064a222c7ff42504e2 from dongle sendstack
2016.01.01 20:50:11.378 5: ZWave dispatch 001304000003
2016.01.01 20:50:11.379 4: ZWave CMD:ZW_SEND_DATA ID:00 ARG:0003
2016.01.01 20:50:11.379 4: ZWave transmit OK for 04
Die Übertragung wurde wieder vom Dongle und vom Dimmer bestätigt.
2016.01.01 20:50:11.396 4: ZWDongle_Read ZWave: sending ACK, processing 00040004179881d858dec93453f4960c99cb395d399068f5624e40c3
Die verschlüsselte Nachricht vom Dimmer kommt ist angekommen...
2016.01.01 20:50:11.397 5: SW: 06
2016.01.01 20:50:11.398 5: ZWave dispatch 00040004179881d858dec93453f4960c99cb395d399068f5624e40c3
2016.01.01 20:50:11.399 4: ZWave CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:179881d858dec93453f4960c99cb395d399068f5624e40c3
2016.01.01 20:50:11.402 5: Dimmer_WZ: secDecrypt: decrypted cmd 00260300
2016.01.01 20:50:11.403 5: Dimmer_WZ: secDecrypt: Sequencebyte 0, sequenced 0, secondFrame 0, sequenceCounter 00
2016.01.01 20:50:11.404 5: Dimmer_WZ: secDecrypt: calculated Authentication code 399068f5624e40c3
2016.01.01 20:50:11.404 5: Dimmer_WZ: secDecrypt: parsing 0004000403260300
2016.01.01 20:50:11.405 4: ZWave CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:03260300
Nach dem Entschlüssel findet sich eine 260300 Nachricht: 26 Command Class SWITCH_MULTILEVEL, 03 = Report, 00=off
Das heisst der Dimmer meldet das er aus.
Das ganze "hin-und-her" ist also wirklich nichts weiter als "schalt ein", "ich bin aus"...
Zitat von: jensb am 02 Januar 2016, 20:27:15
[zweifaches senden]
Das müsste sich dann aber auch im Log wiederfinden oder?
Nein, das macht der Dongle von ganz alleine... Falls er keine Bestätigung vom Dimmer bekommt sendet er noch mal ohne das auf Protokollebene zu melden. Erst wenn er gar keine Bestätigung bekommt meldet er ein "NO_ACK". Da das ganze hier aber nur bei einem Befehl auftritt ist es relativ unwahrscheinlich das hier ein Empfangsproblem zu einem mehrfachen Senden führt. Außerdem sollten die Geräte soetwas anhand einer fortlaufenden Nummer feststellen können (diese Nummer existiert nur auf der Funkebene, in der Protokollebene gibt es die nicht...)
Zitat von: jensb am 02 Januar 2016, 20:27:15
Mein Analyse hat gezeigt, dass "2016.01.01 20:50:11.329 4: ZWave CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:029840" das "state"-Reading auf off zurücksetzt. Was ich nicht überprüfen kann ist, ob der Dimmer zu diesem Zeitpunkt schon den Zustand aus angenommen hat und diesen meldet oder ob der Dimmer erst mit einem der folgenden Telegramme wieder ausgeschaltet wird. Dafür geht das ganze leider zu schnell. Vielleicht sollte ich in ZWave_Parse mal vorübergehend ein dickes Sleep einbauen?
Wie oben in Deinem Log beschrieben, der 029840 ist nur der Beginn der verschlüsselten Statusmeldung vom Dimmer. Da wird kein weiterer Befehl gesendet und nichts geschaltet. Das Ding geht wieder aus und meldet dies auch korrekt.
Ich gehe nach-wie-vor von einem Firmware-Problem des Dimmers aus.
Gruß,
Andreas.
Hallo Andreas,
danke für die ausführlichen Erklärungen, das ist schon sehr interessant und auch nachvollziehbar.
Gibt es nach deinen Infos jemanden spezielles bei Fibaro, den man wegen der Firmware ansprechen sollte oder ist eine Mail an support@fibaro.com der richtige Weg?
Grüße,
Jens
Habe mich mal bei den üblichen Foren nach dem Aktor umgesehen. Probleme werden häufiger berichtet. z-way (ZWave+ zertifiziert) scheint den Dimmer nicht zu untersützen: http://forum.z-wave.me/viewtopic.php?f=3423&t=22236. Dort kann man auch schon Fibaros Antwort auf Problemberichte finden. Bei ozw und den darauf aufbauenden Programmen gab es wohl auch Besonderheiten bei der Einbindung. Zu Security speziell habe ich aber nichts gefunden.
Vielleicht tatsächlich mal anschreiben und schauen, ob die Antwort anders als im ZWay-Forum ist.
Gruß, Christian
Die Support-Anfrage an Fibaro ist per Mail raus. Melde mich (spätestens) wieder, wenn ich eine Antwort habe.
Gruß,
Jens