Hier die erste, mir bekannte Outdoor Sirene die mit Z-Wave funktioniert:
http://www.popp.eu/products/actuators/outdoor-siren/
Aktueller Internetpreis ist 220,- EUR. Ich befürchte, dass man die akustische und optische Alarmierung nicht getrennt voneinander aktivieren kann. Ich würde gerne den Flash auch für andere Fälle als einen Einbruchsalarm nutzen wollen. Das geht wohl nur durch eine Änderung der Konfig (flash only), dann auf on setzen und anschließend wieder die Sirene in der Konfig aktivieren. :-\
Hat die schon jemand im Einsatz?
Ich werte das dann mal als nein. ;D
Noch nicht, aber womöglich bald!
Danke für den Hinweis!
Woher weißt Du, daß man Licht und Ton nicht getrennt aktivieren kann? Hast Du eine Bedienungsanleitung gefunden?
Falls ja, bitte um Link, danke!
Habe eine Vision Sirene (leider nur für Indoor, dafür einiges günstiger (40,- €)) auf die trifft das auch zu.
Hier das Manual:
http://www.popp.eu/wp-content/uploads/2015/09/Manual_Solar-Siren_POPP_En.pdf
Daraus entnehme ich, dSs man mit Parameter 5 konfigurieren kann, ob optisch, akustisch oder mit beidem alarmieren möchte und ein on wird es dann aktivieren.
Bei youtube ist auch ein Video, leider ohne Ton und im Zeitraffer...
Hallo!
Hab mir jetzt so ein Gerät zugelegt. Die Konfig. in der openzwave DB wird aber leider noch nicht gefunden!
Hier die Readings:
Readings
SECURITY
ENABLED
2015-11-27 17:24:56
assocGroups
1
2015-11-27 17:27:13
basicReport
00
2015-11-27 17:27:44
battery
100 %
2015-11-27 17:27:20
model
0x0154 0x0004 0x0002
2015-11-27 17:26:33
modelId
0154-0004-0002
2015-11-27 17:26:33
neighborList
empty
2015-11-27 17:37:13
powerlvl
current 0 remain 0
2015-11-27 17:35:52
reportedState
off
2015-11-27 17:37:05
state
off
2015-11-27 17:37:05
temperature
28.0 C
2015-11-27 17:36:59
transmit
OK
2015-11-27 17:37:05
version
Lib 3 Prot 4.5 App 1.1 HW 1 FWCounter 0
2015-11-27 17:28:27
zwavePlusInfo
version:01 role:AlwaysOnSlave node:Z-Wave+Node installerIcon:0d01 userIcon:0f00
2015-11-27 17:28:01
Hier auch das Log der Inclusion:
2015.11.27 17:24:44.068 4: ZWDongle set ZWDongle_0 addNode on sec
2015.11.27 17:24:44.069 5: ZWDongle_Write 00 4a8101
2015.11.27 17:24:44.070 5: SW: 0105004a810130
2015.11.27 17:24:44.080 5: ACK received, removing 0105004a810130 from dongle sendstack
2015.11.27 17:24:44.081 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 004a01010000
2015.11.27 17:24:44.081 5: SW: 06
2015.11.27 17:24:44.083 5: ZWDongle_0 dispatch 004a01010000
2015.11.27 17:24:44.083 4: ZWDongle_0 CMD:ZW_ADD_NODE_TO_NETWORK ID:01 ARG:0000
2015.11.27 17:24:44.091 4: ZWDongle_0 ZW_ADD_NODE_TO_NETWORK learnReady
2015.11.27 17:24:53.348 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 004a01020000
2015.11.27 17:24:53.349 5: SW: 06
2015.11.27 17:24:53.350 5: ZWDongle_0 dispatch 004a01020000
2015.11.27 17:24:53.351 4: ZWDongle_0 CMD:ZW_ADD_NODE_TO_NETWORK ID:02 ARG:0000
2015.11.27 17:24:53.363 4: ZWDongle_0 ZW_ADD_NODE_TO_NETWORK nodeFound
2015.11.27 17:24:53.520 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 004a010310130410055e20253071317085807a5a5973988672
2015.11.27 17:24:53.520 5: SW: 06
2015.11.27 17:24:53.522 5: ZWDongle_0 dispatch 004a010310130410055e20253071317085807a5a5973988672
2015.11.27 17:24:53.522 4: ZWDongle_0 CMD:ZW_ADD_NODE_TO_NETWORK ID:03 ARG:10130410055e20253071317085807a5a5973988672
2015.11.27 17:24:53.530 2: autocreate: define ZWave_SWITCH_BINARY_16 ZWave xxxxxxxx 16 5e20253071317085807a5a5973988672
2015.11.27 17:24:53.534 2: autocreate: define FileLog_ZWave_SWITCH_BINARY_16 FileLog ./log/ZWave_SWITCH_BINARY_16-%Y.log ZWave_SWITCH_BINARY_16
2015.11.27 17:24:55.080 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 004a01051000
2015.11.27 17:24:55.080 5: SW: 06
2015.11.27 17:24:55.082 5: ZWDongle_0 dispatch 004a01051000
2015.11.27 17:24:55.102 4: ZWDongle_0 CMD:ZW_ADD_NODE_TO_NETWORK ID:05 ARG:1000
2015.11.27 17:24:55.102 2: ZWAVE Starting secure init
2015.11.27 17:24:55.104 5: ZWDongle_Write 00 1310039804002510
2015.11.27 17:24:55.105 5: SW: 010a0013100398040025105c
2015.11.27 17:24:55.107 5: ACK received, WaitForAck=>2 for 010a0013100398040025105c
2015.11.27 17:24:55.115 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.27 17:24:55.115 5: SW: 06
2015.11.27 17:24:55.117 5: ZWDongle_0 dispatch 011301
2015.11.27 17:24:56.264 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 001310000074
2015.11.27 17:24:56.264 5: SW: 06
2015.11.27 17:24:56.266 5: device ack reveived, removing 010a0013100398040025105c from dongle sendstack
2015.11.27 17:24:56.266 5: ZWDongle_0 dispatch 001310000074
2015.11.27 17:24:56.267 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0074
2015.11.27 17:24:56.267 4: ZWDongle_0 transmit OK for 10
2015.11.27 17:24:56.276 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0004001003980500
2015.11.27 17:24:56.276 5: SW: 06
2015.11.27 17:24:56.278 5: ZWDongle_0 dispatch 0004001003980500
2015.11.27 17:24:56.279 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:10 ARG:03980500
2015.11.27 17:24:56.281 5: ZWDongle_Write 00 13100298402510
2015.11.27 17:24:56.281 5: SW: 010900131002984025101a
2015.11.27 17:24:56.283 4: ZWDongle_ReadAnswer arg:secNonce regexp:^00040010..98
2015.11.27 17:24:56.284 5: ACK received, WaitForAck=>2 for 010900131002984025101a
2015.11.27 17:24:56.291 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.27 17:24:56.291 5: SW: 06
2015.11.27 17:24:56.293 5: ZWDongle_0 dispatch 011301
2015.11.27 17:24:56.319 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 001310000003
2015.11.27 17:24:56.319 5: SW: 06
2015.11.27 17:24:56.321 5: device ack reveived, removing 010900131002984025101a from dongle sendstack
2015.11.27 17:24:56.321 5: ZWDongle_0 dispatch 001310000003
2015.11.27 17:24:56.322 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0003
2015.11.27 17:24:56.322 4: ZWDongle_0 transmit OK for 10
2015.11.27 17:24:56.335 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400100a988052d5b82cd7f57f27
2015.11.27 17:24:56.335 5: SW: 06
2015.11.27 17:24:56.337 4: ZWDongle_ReadAnswer for secNonce: 000400100a988052d5b82cd7f57f27
2015.11.27 17:24:56.337 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:10 ARG:0a988052d5b82cd7f57f27
2015.11.27 17:24:56.340 5: ZWDongle_Write 00 1310269881f3a9bf3eba2ac9d952f3730a4980b6208a271e2494f7d57651699452288188c99bf051c92510
2015.11.27 17:24:56.341 5: SW: 012d001310269881f3a9bf3eba2ac9d952f3730a4980b6208a271e2494f7d57651699452288188c99bf051c92510b5
2015.11.27 17:24:56.345 5: ACK received, WaitForAck=>2 for 012d001310269881f3a9bf3eba2ac9d952f3730a4980b6208a271e2494f7d57651699452288188c99bf051c92510b5
2015.11.27 17:24:56.354 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.27 17:24:56.354 5: SW: 06
2015.11.27 17:24:56.356 5: ZWDongle_0 dispatch 011301
2015.11.27 17:24:56.381 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 001310000004
2015.11.27 17:24:56.381 5: SW: 06
2015.11.27 17:24:56.383 5: device ack reveived, removing 012d001310269881f3a9bf3eba2ac9d952f3730a4980b6208a271e2494f7d57651699452288188c99bf051c92510b5 from dongle sendstack
2015.11.27 17:24:56.383 5: ZWDongle_0 dispatch 001310000004
2015.11.27 17:24:56.384 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0004
2015.11.27 17:24:56.384 4: ZWDongle_0 transmit OK for 10
2015.11.27 17:24:56.410 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040010029840
2015.11.27 17:24:56.410 5: SW: 06
2015.11.27 17:24:56.412 5: ZWDongle_0 dispatch 00040010029840
2015.11.27 17:24:56.412 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:10 ARG:029840
2015.11.27 17:24:56.414 5: ZWDongle_Write 00 13100a9880d4d5f1ef36251e472510
2015.11.27 17:24:56.415 5: SW: 01110013100a9880d4d5f1ef36251e4725109f
2015.11.27 17:24:56.418 5: ACK received, WaitForAck=>2 for 01110013100a9880d4d5f1ef36251e4725109f
2015.11.27 17:24:56.425 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.27 17:24:56.425 5: SW: 06
2015.11.27 17:24:56.427 5: ZWDongle_0 dispatch 011301
2015.11.27 17:24:56.446 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 001310000002
2015.11.27 17:24:56.446 5: SW: 06
2015.11.27 17:24:56.448 5: device ack reveived, removing 01110013100a9880d4d5f1ef36251e4725109f from dongle sendstack
2015.11.27 17:24:56.448 5: ZWDongle_0 dispatch 001310000002
2015.11.27 17:24:56.449 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0002
2015.11.27 17:24:56.449 4: ZWDongle_0 transmit OK for 10
2015.11.27 17:24:56.629 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400101698816e528dee9fe6f8fbb0132fd4d48f17c65ad668c9
2015.11.27 17:24:56.629 5: SW: 06
2015.11.27 17:24:56.631 5: ZWDongle_0 dispatch 000400101698816e528dee9fe6f8fbb0132fd4d48f17c65ad668c9
2015.11.27 17:24:56.632 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:10 ARG:1698816e528dee9fe6f8fbb0132fd4d48f17c65ad668c9
2015.11.27 17:24:56.633 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:10 ARG:029807
2015.11.27 17:24:56.634 3: ZWave_SWITCH_BINARY_16: SECURITY enabled, networkkey was verified
2015.11.27 17:24:56.635 2: ZWave get ZWave_SWITCH_BINARY_16 secSupported
2015.11.27 17:24:56.637 5: ZWDongle_Write 00 13100298402510
2015.11.27 17:24:56.638 5: SW: 010900131002984025101a
2015.11.27 17:24:56.639 4: ZWDongle_ReadAnswer arg:secNonce regexp:^00040010..98
2015.11.27 17:24:56.640 5: ACK received, WaitForAck=>2 for 010900131002984025101a
2015.11.27 17:24:56.647 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.27 17:24:56.648 5: SW: 06
2015.11.27 17:24:56.649 5: ZWDongle_0 dispatch 011301
2015.11.27 17:24:56.666 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 001310000002
2015.11.27 17:24:56.666 5: SW: 06
2015.11.27 17:24:56.668 5: device ack reveived, removing 010900131002984025101a from dongle sendstack
2015.11.27 17:24:56.668 5: ZWDongle_0 dispatch 001310000002
2015.11.27 17:24:56.669 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0002
2015.11.27 17:24:56.669 4: ZWDongle_0 transmit OK for 10
2015.11.27 17:24:56.685 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400100a9880ea1b174a6aa6f9a8
2015.11.27 17:24:56.685 5: SW: 06
2015.11.27 17:24:56.687 4: ZWDongle_ReadAnswer for secNonce: 000400100a9880ea1b174a6aa6f9a8
2015.11.27 17:24:56.687 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:10 ARG:0a9880ea1b174a6aa6f9a8
2015.11.27 17:24:56.690 5: ZWDongle_Write 00 1310169881fd0739c35d348a208c277bea0d7b15e4547a65e92510
2015.11.27 17:24:56.691 5: SW: 011d001310169881fd0739c35d348a208c277bea0d7b15e4547a65e9251007
2015.11.27 17:24:56.694 5: ACK received, WaitForAck=>2 for 011d001310169881fd0739c35d348a208c277bea0d7b15e4547a65e9251007
2015.11.27 17:24:56.701 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.27 17:24:56.701 5: SW: 06
2015.11.27 17:24:56.703 5: ZWDongle_0 dispatch 011301
2015.11.27 17:24:56.726 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 001310000003
2015.11.27 17:24:56.726 5: SW: 06
2015.11.27 17:24:56.728 5: device ack reveived, removing 011d001310169881fd0739c35d348a208c277bea0d7b15e4547a65e9251007 from dongle sendstack
2015.11.27 17:24:56.728 5: ZWDongle_0 dispatch 001310000003
2015.11.27 17:24:56.729 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0003
2015.11.27 17:24:56.729 4: ZWDongle_0 transmit OK for 10
2015.11.27 17:24:56.743 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040010029840
2015.11.27 17:24:56.743 5: SW: 06
2015.11.27 17:24:56.745 5: ZWDongle_0 dispatch 00040010029840
2015.11.27 17:24:56.746 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:10 ARG:029840
2015.11.27 17:24:56.748 5: ZWDongle_Write 00 13100a98803783a10d44fbfe082510
2015.11.27 17:24:56.748 5: SW: 01110013100a98803783a10d44fbfe0825109b
2015.11.27 17:24:56.751 5: ACK received, WaitForAck=>2 for 01110013100a98803783a10d44fbfe0825109b
2015.11.27 17:24:56.758 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.27 17:24:56.758 5: SW: 06
2015.11.27 17:24:56.760 5: ZWDongle_0 dispatch 011301
2015.11.27 17:24:56.781 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 001310000003
2015.11.27 17:24:56.781 5: SW: 06
2015.11.27 17:24:56.783 5: device ack reveived, removing 01110013100a98803783a10d44fbfe0825109b from dongle sendstack
2015.11.27 17:24:56.783 5: ZWDongle_0 dispatch 001310000003
2015.11.27 17:24:56.784 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0003
2015.11.27 17:24:56.784 4: ZWDongle_0 transmit OK for 10
2015.11.27 17:24:56.812 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040010229881844ca0a4911291bec72c8e22499bac3249c3436cab3546372943da489b31310b
2015.11.27 17:24:56.812 5: SW: 06
2015.11.27 17:24:56.814 5: ZWDongle_0 dispatch 00040010229881844ca0a4911291bec72c8e22499bac3249c3436cab3546372943da489b31310b
2015.11.27 17:24:56.815 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:10 ARG:229881844ca0a4911291bec72c8e22499bac3249c3436cab3546372943da489b31310b
2015.11.27 17:24:56.816 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:10 ARG:0e9803005e20253071317059858672
2015.11.27 17:24:57.320 2: ZWave set ZWave_SWITCH_BINARY_16 associationAdd 1 01
2015.11.27 17:24:57.322 5: ZWDongle_Write 00 13100298402510
2015.11.27 17:24:57.323 5: SW: 010900131002984025101a
2015.11.27 17:24:57.324 4: ZWDongle_ReadAnswer arg:secNonce regexp:^00040010..98
2015.11.27 17:24:57.325 5: ACK received, WaitForAck=>2 for 010900131002984025101a
2015.11.27 17:24:57.333 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.27 17:24:57.333 5: SW: 06
2015.11.27 17:24:57.335 5: ZWDongle_0 dispatch 011301
2015.11.27 17:24:57.353 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 001310000003
2015.11.27 17:24:57.353 5: SW: 06
2015.11.27 17:24:57.355 5: device ack reveived, removing 010900131002984025101a from dongle sendstack
2015.11.27 17:24:57.355 5: ZWDongle_0 dispatch 001310000003
2015.11.27 17:24:57.356 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0003
2015.11.27 17:24:57.356 4: ZWDongle_0 transmit OK for 10
2015.11.27 17:24:57.370 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400100a98801568dc62f09aa083
2015.11.27 17:24:57.370 5: SW: 06
2015.11.27 17:24:57.372 4: ZWDongle_ReadAnswer for secNonce: 000400100a98801568dc62f09aa083
2015.11.27 17:24:57.372 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:10 ARG:0a98801568dc62f09aa083
2015.11.27 17:24:57.375 5: ZWDongle_Write 00 13101898814e2f75ea50f0ba838b5f97ff8115f2cbbdcd2b0a1f522510
2015.11.27 17:24:57.375 5: SW: 011f0013101898814e2f75ea50f0ba838b5f97ff8115f2cbbdcd2b0a1f522510bd
2015.11.27 17:24:57.390 5: ACK received, WaitForAck=>2 for 011f0013101898814e2f75ea50f0ba838b5f97ff8115f2cbbdcd2b0a1f522510bd
2015.11.27 17:24:57.391 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.27 17:24:57.391 5: SW: 06
2015.11.27 17:24:57.393 5: ZWDongle_0 dispatch 011301
2015.11.27 17:24:57.411 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 001310000003
2015.11.27 17:24:57.411 5: SW: 06
2015.11.27 17:24:57.413 5: device ack reveived, removing 011f0013101898814e2f75ea50f0ba838b5f97ff8115f2cbbdcd2b0a1f522510bd from dongle sendstack
2015.11.27 17:24:57.413 5: ZWDongle_0 dispatch 001310000003
2015.11.27 17:24:57.414 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0003
2015.11.27 17:24:57.414 4: ZWDongle_0 transmit OK for 10
2015.11.27 17:24:57.892 2: ZWave get ZWave_SWITCH_BINARY_16 model
2015.11.27 17:24:57.894 5: ZWDongle_Write 00 13100298402510
2015.11.27 17:24:57.895 5: SW: 010900131002984025101a
2015.11.27 17:24:57.896 4: ZWDongle_ReadAnswer arg:secNonce regexp:^00040010..98
2015.11.27 17:24:57.897 5: ACK received, WaitForAck=>2 for 010900131002984025101a
2015.11.27 17:24:57.904 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.27 17:24:57.904 5: SW: 06
2015.11.27 17:24:57.906 5: ZWDongle_0 dispatch 011301
2015.11.27 17:24:57.923 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 001310000003
2015.11.27 17:24:57.923 5: SW: 06
2015.11.27 17:24:57.925 5: device ack reveived, removing 010900131002984025101a from dongle sendstack
2015.11.27 17:24:57.925 5: ZWDongle_0 dispatch 001310000003
2015.11.27 17:24:57.926 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0003
2015.11.27 17:24:57.926 4: ZWDongle_0 transmit OK for 10
2015.11.27 17:24:57.942 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400100a9880d56aea343c4a0c44
2015.11.27 17:24:57.942 5: SW: 06
2015.11.27 17:24:57.944 4: ZWDongle_ReadAnswer for secNonce: 000400100a9880d56aea343c4a0c44
2015.11.27 17:24:57.944 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:10 ARG:0a9880d56aea343c4a0c44
2015.11.27 17:24:57.947 5: ZWDongle_Write 00 13101698810944de07218d146e83ec2ad5a30bb45116b1211a2510
2015.11.27 17:24:57.947 5: SW: 011d0013101698810944de07218d146e83ec2ad5a30bb45116b1211a2510d8
2015.11.27 17:24:57.951 5: ACK received, WaitForAck=>2 for 011d0013101698810944de07218d146e83ec2ad5a30bb45116b1211a2510d8
2015.11.27 17:24:57.959 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.27 17:24:57.959 5: SW: 06
2015.11.27 17:24:57.961 5: ZWDongle_0 dispatch 011301
2015.11.27 17:24:57.983 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 001310000003
2015.11.27 17:24:57.983 5: SW: 06
2015.11.27 17:24:57.985 5: device ack reveived, removing 011d0013101698810944de07218d146e83ec2ad5a30bb45116b1211a2510d8 from dongle sendstack
2015.11.27 17:24:57.986 5: ZWDongle_0 dispatch 001310000003
2015.11.27 17:24:57.986 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0003
2015.11.27 17:24:57.986 4: ZWDongle_0 transmit OK for 10
2015.11.27 17:24:58.000 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040010029840
2015.11.27 17:24:58.000 5: SW: 06
2015.11.27 17:24:58.002 5: ZWDongle_0 dispatch 00040010029840
2015.11.27 17:24:58.003 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:10 ARG:029840
2015.11.27 17:24:58.005 5: ZWDongle_Write 00 13100a988016b795498c4a305e2510
2015.11.27 17:24:58.005 5: SW: 01110013100a988016b795498c4a305e25101f
2015.11.27 17:24:58.008 5: ACK received, WaitForAck=>2 for 01110013100a988016b795498c4a305e25101f
2015.11.27 17:24:58.014 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.27 17:24:58.014 5: SW: 06
2015.11.27 17:24:58.016 5: ZWDongle_0 dispatch 011301
2015.11.27 17:24:58.037 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 001310000002
2015.11.27 17:24:58.037 5: SW: 06
2015.11.27 17:24:58.039 5: device ack reveived, removing 01110013100a988016b795498c4a305e25101f from dongle sendstack
2015.11.27 17:24:58.039 5: ZWDongle_0 dispatch 001310000002
2015.11.27 17:24:58.040 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0002
2015.11.27 17:24:58.040 4: ZWDongle_0 transmit OK for 10
2015.11.27 17:24:58.065 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400101c9881f7e259b0196233b1da5d14c67c45eb309f16b5a382aad0cbecd4
2015.11.27 17:24:58.065 5: SW: 06
2015.11.27 17:24:58.067 5: ZWDongle_0 dispatch 000400101c9881f7e259b0196233b1da5d14c67c45eb309f16b5a382aad0cbecd4
2015.11.27 17:24:58.068 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:10 ARG:1c9881f7e259b0196233b1da5d14c67c45eb309f16b5a382aad0cbecd4
2015.11.27 17:24:58.069 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:10 ARG:087205015400040002
2015.11.27 17:25:50.003 4: ZWDongle set ZWDongle_0 addNode off
Hallo!
Hatte die unter der anderen ManufacturerID von Popp drin (siehe anderen Thread). Ich habe das jetzt verschoben. Ab morgen ca. 8 Uhr per update oder sofort per http://sourceforge.net/p/fhem/code/10021/tree//trunk/fhem/FHEM/lib/openzwave_manufacturer_specific.xml Download und speichern in ./fhem/FHEM/lib und bitte "get <device> model" neu ausführen.
Bin mal gespannt unter welchen ManufIDs die noch auftaucht.
Gruß, Christian
Hi gamauf,
Kannst du etwas zum Ton und der Lautstärke sagen?
Zitatkrikan: ...Ab morgen ca. 8 Uhr per update ...
Hallo Christian!
Danke für die rasche Reraktion!
Zwei Kleinigkeiten sind mir noch aufgefallen:
1.) Parameter Nr. 6 fehlt noch (Auto Off):
Paramter No. 6 Size 1 Default 5
Name Added Auto OFF
Description If the value is set, the siren will be switched off automatically after a defined alarm time.
Type rangemapped
Values
0 -> no auto off
1 min - -1 min -> Define an auto off time.2.) Der Lin auf die Pepper-DB fehlt:
http://pepper1.net/zwavedb/device/842 (http://pepper1.net/zwavedb/device/842)
Danke
Rainer
Hallo Lars!
ZitatKannst du etwas zum Ton und der Lautstärke sagen?
Lautstärke:
Verdammt laut, vor allem wenn man das Ding gleich neben sich am Schreibtisch liegen hat.
Ton:
Wenn ich 'was mach, das die Sirene auslöst, hab ich dabei den Finger (bzw. Mauszeiger) schon am "Aus"-Knopf (siehe Lautstärke), daher hab ich noch nicht lange zugehört! ;-)
Grüße
Rainer
Zitat von: gamauf am 30 November 2015, 13:10:40
Zwei Kleinigkeiten sind mir noch aufgefallen:
1.) Parameter Nr. 6 fehlt noch (Auto Off):
Paramter No. 6 Size 1 Default 5
Name Added Auto OFF
Description If the value is set, the siren will be switched off automatically after a defined alarm time.
Type rangemapped
Values
0 -> no auto off
1 min - -1 min -> Define an auto off time.
Mit einer Anpassung meinerseits würde ich erst einmal noch ein wenig warten. Das ist "nur" eine vorläufige XML-Datei von jeedom-ozw. Es sei denn, Du lieferst direkt eine korrigierte XML-Datei ;).
Zitat2.) Der Lin auf die Pepper-DB fehlt:
http://pepper1.net/zwavedb/device/842 (http://pepper1.net/zwavedb/device/842)
Das ist normal, da der pepper1-Eintrag für die modelId des (baugleichen?) Gerätes von zwave.me ist. Darum kann das durch FHEM nicht erkannt werden.
Anträge, das anzupassen bitte derzeit an Rudi. Wobei ich eigentlich dagegen bin, da das vermutlich manueller Pflegeaufwand ist.
Gruß, Christian
1.)
wohin soll ich eone koregierte XML datei liefern?
Das wäre der Abschnitt für die POP Solar Sirene:
<Product sourceFile="popp/solar-siren.xml">
<CommandClass id="112">
<Value type="list" genre="config" instance="1" index="1" label="Siren triggering mode" value="0" size="1">
<Help>Sets the tamper triggering mode when removed from the holder</Help>
<Item label="The Siren triggers automatically when it's removed from the holder. Must be turned off, using the button or from the controller (Def
<Item label="The Siren triggers automatically when it's removed from the holder and turns off, when placed back on the holder" value="1" />
<Item label="Siren doesn't trigger at all, when removed from the holder. Service Mode" value="2" />
</Value>
<Value type="byte" genre="config" instance="1" index="2" label="Temperature adjustments" size="1" min="0" max="255" value="0">
<Help>Temperature correction. For positive value 10 = 1 °C, for negative value x = 256 - (T°C * 10). Example, if need shift -2.6°C, value calcula
</Value>
<Value type="byte" genre="config" instance="1" index="3" label="Send unsolicited temperature report" size="1" min="0" max="255" value="0">
<Help>Threshold temperature to send unsolicited report. 10 = 1°C</Help>
</Value>
<Value type="short" genre="config" instance="1" index="4" label="Send unsolicited temperature report after N wake up" size="2" min="0" max="65535"
<Help>If the value is set, after N wake up number (measurement is every 4 minutes) the temperature report will be sent. By default it's 15 = ever
</Value>
<Value type="list" genre="config" instance="1" index="5" label="Switch mode" size="1" value="2">
<Help>Siren only, flash only, flash + siren</Help>
<Item label="Siren only" value="0" />
<Item label="Flash only" value="1" />
<Item label="Flash + Siren (Default)" value="2" />
</Value>
<Value type="byte" genre="config" instance="1" index="6" label="Auto OFF" size="1" value="5">
<Help>If the value is set, the siren will be switched off automatically after a defined alarm time in minutes.</Help>
</Value>
</CommandClass>
<CommandClass id="133">
<Associations num_groups="1">
<Group index="1" max_associations="10" label="Lifeline" auto="true"/>
</Associations>
</CommandClass>
</Product>
(wie kritisch ist das " label" Attribut? in der Doku heißt die Funktion "Added Auto OFF", aber da hat man vermutlich zu viel aus der Change History kopiert! "Auto OFF" beschreibt die Funktion nach miner Mieinung besser!)
2.)
Für die Z-Wave.me Variante gibt's zwei Einträge auf pepper1.net. In der zwave_pepperlinks.csv.gz Datei wird auf die unvolständige verwiesen:
http://pepper1.net/zwavedb/device/740 (http://pepper1.net/zwavedb/device/740)
Die hier:
http://pepper1.net/zwavedb/device/842 (http://pepper1.net/zwavedb/device/842)
schaut vollständig(er) aus.
Der Popp Support hat mich auf den zweiten Link verwiesen.
Wird die Datei zwave_pepperlinks.csv.gz automatisiert erstellt oder manuell gewartet?
Grüße
Rainer
Hallo Rainer!
Zitatwohin soll ich eone koregierte XML datei liefern?
Hier hin :) . Danke. Packe ich in Kürze rein.
Zitatkritisch ist das " label" Attribut?
Was heißt kritisch in diesem Zusammenhang? Du darfst die Texte belegen wie Du magst; hast es schließlich erstellt.
ZitatWird die Datei zwave_pepperlinks.csv.gz automatisiert erstellt oder manuell gewartet?
Manuell: http://forum.fhem.de/index.php/topic,43218.msg352188.html#msg352188
Gruß, Christian
na wenn die zwave_pepperlinks.csv.gz eh manuel gewartet wird, hätte ich hier die erste Zeile als Korektur und die zeweite als Ergänzung:
0115-0004-0002,842,a430f3875c3a4fadc550f43725c83e0c7dd0483c.jpg
0154-0004-0002,842,a430f3875c3a4fadc550f43725c83e0c7dd0483c.jpg
Grüße
Rainer
Geänderte XML ist eingecheckt. Wird morgen ab ca. 8 Uhr per update verteilt.
Hallo!
Diese Außensirene hat ja auch eine Temperatursensor den ich nutze. Nachdem es jetzt kalt geworden ist, fällt mir auf, daß bei Temperaturen unter 0°C um ca. 2360°C zu viel angezeigt wird. Also statt -4,4°C wird +2355.6°C von dem Gerät gemeldet!
Wo setzte ich da am besten an? Beim Hersteller, oder kann man das im FHEM beheben?
Grüße
Rainer
Hallo Rainer!
Zunächst sollten wir bei FHEM anfangen, da uns keiner Doku zu den Command Classes liefert und wir das selbst austüfteln dürfen:
Ich kann Dir leider mit den knappen Angaben nicht helfen (keine Ahnung, ob Rudi es schafft.).
Ich bräuchte alles was dort http://www.fhemwiki.de/wiki/Z-Wave#Welche_Infos_sollten_Anfragen_im_ZWave-Forum_enthalten.3F steht, insbesondere mit Abfrage "set <device> versionClassRequest".
Zudem log verbose 5 mit Abfrage der Temperatur und der tatsächlichen Temperatur.
Gruß, Christian
Hallo Christian!
List:
Internals:
DEF xxxxxxxx 16
IODev ZWDongle_0
LASTInputDev ZWDongle_0
MSGCNT 67
NAME ZW_Sirene_A1
NR 176
STATE versionClassRequest SECURITY
TYPE ZWave
ZWDongle_0_MSGCNT 67
ZWDongle_0_RAWMSG 000400101a9881886861f4e2d30a1c267ff5532aea8986f705976e341c2fa3
ZWDongle_0_TIME 2015-12-11 09:02:32
homeId xxxxxxxx
isWakeUp
lastMsgSent 1449820952.35443
nodeIdHex 10
Readings:
2015-11-27 17:24:56 SECURITY ENABLED
2015-12-02 14:49:19 alarm HomeSecurity: Event cleared: Tampering, product covering removed
2015-12-11 08:52:54 assocGroup_1 Max 10 Nodes ZWDongle_0
2015-12-11 08:52:54 assocGroups 1
2015-11-27 17:27:44 basicReport 00
2015-12-03 09:50:18 battery 100 %
2015-11-30 16:56:09 configAddedAutoOFF 0
2015-12-11 08:53:24 configAutoOFF 0
2015-12-11 08:53:24 configSendUnsolicitedTemperatureReport 5
2015-12-11 08:53:24 configSendUnsolicitedTemperatureReport4 5
2015-12-11 08:54:18 configSirenTriggeringMode
2015-12-11 08:53:25 configSwitchMode FlashSirenDefault
2015-12-11 08:53:25 configTemperatureAdjustments 0
2015-11-27 18:10:40 config_1 2
2015-11-27 18:10:52 config_2 0
2015-11-27 18:11:44 config_3 10
2015-11-27 18:12:10 config_4 15
2015-11-27 18:12:22 config_5 2
2015-11-27 18:14:40 config_6 0
2015-12-02 07:46:01 model Popp Solar Powered Outdoor Siren
2015-12-02 07:46:01 modelConfig popp/solar-siren.xml
2015-12-02 07:46:01 modelId 0154-0004-0002
2015-11-29 11:10:21 neighborList ZWDongle_0 ZW_Sirene_1
2015-11-30 08:47:19 powerlvl current 0 remain 0
2015-11-30 08:47:26 powerlvlTest node 0 status 0 frameAck 0
2015-12-10 12:08:31 reportedState off
2015-12-11 08:59:08 state versionClassRequest SECURITY
2015-12-02 14:49:18 tamper 00
2015-12-11 09:02:32 temperature 2356.5 C
2015-12-11 09:02:32 transmit OK
2015-11-28 11:33:26 version Lib 3 Prot 4.5 App 1.1 HW 1 FWCounter 0
2015-12-11 08:59:38 zwavePlusInfo version:01 role:AlwaysOnSlave node:Z-Wave+Node installerIcon:0d01 userIcon:0f00
secMsg:
Attributes:
IODev ZWDongle_0
alarmDevice Actor
alarmSettings alarm5,alarm6,|set ZW_Sirene_A1 on|set ZW_Sirene_A1 off|20
classes ZWAVEPLUS_INFO BASIC SWITCH_BINARY SENSOR_BINARY ALARM SENSOR_MULTILEVEL CONFIGURATION ASSOCIATION BATTERY FIRMWARE_UPDATE_MD DEVICE_RESET_LOCALLY ASSOCIATION_GRP_INFO POWERLEVEL SECURITY VERSION MANUFACTURER_SPECIFIC
icon secur_alarm
room Laubengang,Alarm,ZWave
secure_classes ZWAVEPLUS_INFO BASIC SWITCH_BINARY SENSOR_BINARY ALARM SENSOR_MULTILEVEL CONFIGURATION ASSOCIATION_GRP_INFO ASSOCIATION VERSION MANUFACTURER_SPECIFIC
vclasses ALARM:05 ASSOCIATION:02 ASSOCIATION_GRP_INFO:01 BASIC:01 BATTERY:01 CONFIGURATION:01 DEVICE_RESET_LOCALLY:01 FIRMWARE_UPDATE_MD:03 MANUFACTURER_SPECIFIC:02 POWERLEVEL:01 SECURITY:01 SENSOR_BINARY:02 SENSOR_MULTILEVEL:05 SWITCH_BINARY:01 VERSION:02 ZWAVEPLUS_INFO:02
und das Log der Temperaturabfrage:
2015.12.11 09:02:30 2: ZWave get ZW_Sirene_A1 smStatus
2015.12.11 09:02:30 5: ZWDongle_Write 00 13100298402510
2015.12.11 09:02:30 5: SW: 010900131002984025101a
2015.12.11 09:02:30 4: ZWDongle_ReadAnswer arg:secNonce regexp:^00040010..98
2015.12.11 09:02:30 5: ACK received, WaitForAck=>2 for 010900131002984025101a
2015.12.11 09:02:30 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.12.11 09:02:30 5: SW: 06
2015.12.11 09:02:30 5: ZWDongle_0 dispatch 011301
2015.12.11 09:02:32 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 001310000081
2015.12.11 09:02:32 5: SW: 06
2015.12.11 09:02:32 5: device ack reveived, removing 010900131002984025101a from dongle sendstack
2015.12.11 09:02:32 5: ZWDongle_0 dispatch 001310000081
2015.12.11 09:02:32 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0081
2015.12.11 09:02:32 4: ZWDongle_0 transmit OK for 10
2015.12.11 09:02:32 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400100a98800b2fbc46208d5279
2015.12.11 09:02:32 5: SW: 06
2015.12.11 09:02:32 4: ZWDongle_ReadAnswer for secNonce: 000400100a98800b2fbc46208d5279
2015.12.11 09:02:32 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:10 ARG:0a98800b2fbc46208d5279
2015.12.11 09:02:32 5: ZWDongle_Write 00 13101698817ad215db9e1d79c795330f0b1dff9941ae05ec052510
2015.12.11 09:02:32 5: SW: 011d0013101698817ad215db9e1d79c795330f0b1dff9941ae05ec0525105a
2015.12.11 09:02:32 5: ACK received, WaitForAck=>2 for 011d0013101698817ad215db9e1d79c795330f0b1dff9941ae05ec0525105a
2015.12.11 09:02:32 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.12.11 09:02:32 5: SW: 06
2015.12.11 09:02:32 5: ZWDongle_0 dispatch 011301
2015.12.11 09:02:32 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 001310000003
2015.12.11 09:02:32 5: SW: 06
2015.12.11 09:02:32 5: device ack reveived, removing 011d0013101698817ad215db9e1d79c795330f0b1dff9941ae05ec0525105a from dongle sendstack
2015.12.11 09:02:32 5: ZWDongle_0 dispatch 001310000003
2015.12.11 09:02:32 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0003
2015.12.11 09:02:32 4: ZWDongle_0 transmit OK for 10
2015.12.11 09:02:32 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040010029840
2015.12.11 09:02:32 5: SW: 06
2015.12.11 09:02:32 5: ZWDongle_0 dispatch 00040010029840
2015.12.11 09:02:32 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:10 ARG:029840
2015.12.11 09:02:32 5: ZWDongle_Write 00 13100a988086906693dcc8313c2510
2015.12.11 09:02:32 5: SW: 01110013100a988086906693dcc8313c251030
2015.12.11 09:02:32 5: ACK received, WaitForAck=>2 for 01110013100a988086906693dcc8313c251030
2015.12.11 09:02:32 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.12.11 09:02:32 5: SW: 06
2015.12.11 09:02:32 5: ZWDongle_0 dispatch 011301
2015.12.11 09:02:32 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 001310000003
2015.12.11 09:02:32 5: SW: 06
2015.12.11 09:02:32 5: device ack reveived, removing 01110013100a988086906693dcc8313c251030 from dongle sendstack
2015.12.11 09:02:32 5: ZWDongle_0 dispatch 001310000003
2015.12.11 09:02:32 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0003
2015.12.11 09:02:32 4: ZWDongle_0 transmit OK for 10
2015.12.11 09:02:32 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400101a9881886861f4e2d30a1c267ff5532aea8986f705976e341c2fa3
2015.12.11 09:02:32 5: SW: 06
2015.12.11 09:02:32 5: ZWDongle_0 dispatch 000400101a9881886861f4e2d30a1c267ff5532aea8986f705976e341c2fa3
2015.12.11 09:02:32 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:10 ARG:1a9881886861f4e2d30a1c267ff5532aea8986f705976e341c2fa3
2015.12.11 09:02:32 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:10 ARG:06310501225c0d
Tatsächliche Temperatur (vermutlich): -3,5°C
Danke
Rainer
Keine guten Nachrichten für Dich. Wenn ich
Zitat06310501225c0d
anhand der mir bekannten Infos analysiere, komme ich genau auf das Ergebnis, was FHEM Dir anzeigt: 2356,5. (5c0dhex=23565 mit 1 Dezimalstelle)
Es gibt kein zusätzliches Byte/Bit zu den alten Class-Versionen. Alles sieht für mich altbekannt aus; Negativ-Bit ist nicht gesetzt.
Eine Änderung im vorliegenden Nachrichtenaufbau würde die Rückwärtskompatibilität der Command Classes durchbrechen, die ZWave hochhält. Also glaube ich nicht daran.
Es gibt nach Deiner XML einen Korrekturfaktor in den Configs. Könnte der nicht einen Einfluß haben? Ist der richtig gesetzt?
Waren die positiven Temperaturen korrekt?
ja, die positiven Temperaturwerte waren korrekt.
Der Korrekturfaktor ist auf 0 gesetzt.
Danke!
Hattest Du auch spontan gemeldete Werte, d.h. ohne Abfrage mit get", die evtl. anders sind?
Hintergrund:
Bei den get-Abfragen gibt es wohl eine Änderung ab Command Class Version 5. Glaube zwar immer noch nicht, dass dadurch Rückwärtskompatibilität durchbrochen wird, aber wer weiss schon...
ja, auch die Werte die das Gerät unaufgefordert sendet sind im selben Bereich (über 2000°C)
Hi,
da mich das interessiert hat habe ich gerade mal meinen AEOTEC Multisensor 6 (auch mit SENSOR_MULTILEVEL:05) in das Eisfach gelegt... (und natürlich prompt darin vergessen...)
Der Sensor meldet jetzt -16.1°C:
000400ab0631050122ff5f
Was übersetzt bedeutet:
31 05 (Command Class für Mulit-Sensor, Report)
01 (temperature sensor)
22 (Bitfeld: 0010 0010 -> 3bit-precision: 001 2bit-scale: 00 3bit-size:010 -> 1 Nachkommastelle, Celsius-Skala, 2 Byte
ff5f = 65375, Vorzeichen bit gesetzt-> -161
mit 1 Nachkommastelle dann -16.1°C
Also mit meinem Sensor funktioniert das mit Version 5 von der SENSOR_MULTILEVEL Kommandoklasse einwandfrei.
Da hat Krikan wohl leider recht und es ist ein Problem von dem Gerät:
@Krikan: V5 akzeptiert noch zwei weitere Bytes bei dem Get, Byte1:Sensortyp, Byte2:Skalierung (in bit3 und bit4). Ich habe damit rumgespielt und kann die Abfrage dann z.B. in Farenheit machen, ändert aber nichts am Verhalten. In dem Report wird die Skalierung ja mitgeschickt, daher sehe ich nicht es hier Probleme mit der Kompatibilität der verschiedenen Versionen gibt.
Gruß,
Andreas.
Daher sieht es wohl wirklich schlecht
Statement vom Popp Support:
can confirm the problem. Its a bug that will be fixed. We will provide a
firmware update you can load on
the device when the new FW is ready. You will need a software that
supports FW update Over the air.
The Popp HUB does this.
Kann FHEM Firmware-Updates auf Z-Wave Geräten durchführen?
Zitatcan confirm the problem. Its a bug that will be fixed.
Danke für die Info.
Zitat von: gamauf am 14 Dezember 2015, 14:10:57
Kann FHEM Firmware-Updates auf Z-Wave Geräten durchführen?
Nein, die notwendige Command Class FIRMWARE_UPDATE_MD kann FHEM bisher nicht (http://www.fhemwiki.de/wiki/Z-Wave_Command_Classes). Es fehlte hier bisher ein Produkt für das Firmwareupdates zur Verfügung gestellt wurden; und damit letztlich die Notwendigkeit.
Popp HUB nutzt OEM-zway.
Hallo Christian,
wenn's danach geht kann ich für den AEOTEC Multisensor Gen5 die Version 1.3 (EU) anbieten.
Ist allerdings auch ein Flasher mit Hilfe eines ZWave-USB-Stick dabei. Ging mit dem Gen5-Stick von
gleichnamiger Firma problemlos unter einer Win10-VM.
Gruß
Thomas
Hallo Thomas!
Den Sensor habe ich auch, aber noch nicht mit einem Firmwareupdate versorgt. Habe mir sogar den Updater schon angesehen, nur das vergessen. Theoretisch und vermutlich praktisch (u.a. ZWave@CUL) könnte man das jetzt analysieren. Aber ich frage mich beim Überdenken, ob es wirklich sinnvoll ist. Ich habe keine Ahnung, ob ich das schaffe und wie testet man das anschließend. Gibt es ein Downgrade? Ich möchte eigentlich nicht verantwortlich sein, für fehlgeschlagene Firmwareupdates und Elekronikschrott. Dennoch interessant.
Gruß, Christian
Stimmt schon. Möchte auch nicht für gehimmelte Hardware mitschuldig sein. Vielleicht sollte Firma Popp gleich einen passenden Flasher mitliefern!
Ich fand den Sigma?-Flasher übrigens schon sehr "verbose" - vielleicht muss man da kaum sniffen.
So, das FW Update ist da:
http://new.zwave.eu/ota.php (http://new.zwave.eu/ota.php)
Popp empfiehlt den Popp Hub, Popps Variante von Z-Way fürs FW-Upgrade.
Fürchte nur, mein Z-Wave USB Stick (ZME_UZB1) wird ohne €50,- terure Lizenz von Z-Way nicht unterstützt. Außerdem scheint diese "Lizenz" den Stick zu verändern. Ob er dann noch für FHEM zu gebrauchen ist?
...
Zitat von: gamauf am 18 Dezember 2015, 13:57:42
Ob er dann noch für FHEM zu gebrauchen ist?
Ja.
Aber wenn Du einen Raspberry hast, überlege, ob Du nicht für den gleichen Preis den razberry inkl. z-way nimmst. Dann hast Du noch ein Backup-Gateway.
ZitatSo, das FW Update ist da:
Habe mir das Firmware-Update von AEOTEC angeschaut und durchgeführt.
Leider haben die die Firmware-Datei irgendwie im Updatetool gekapselt, so dass ich keine reine BIN-Update-Datei habe. Zudem brauchte der Updatevorgang relativ lange und besteht aus einer Vielzahl von abhängigen Befehlen, die aber schön im Log dokumentiert werden. Ich selbst werde mich dennoch nicht an der Implementierung in FHEM probieren. Meine Sorge vor Erfolglosigkeit und Elektronikschrott ist zu groß.
Hast Du den Link vom Hersteller oder gibt es auch eine offizielle Firmwareupdate-Ankündigung?
Gruß, Christian
Hab den Link heute per Mail vom Popp Support bekommen.
Grüße
Rainer
Hallo!
Hatte jetzt eine Weile keine Zeit mich um die Sirene und ihr Minustemperaturen-Problem zu kümmern. Jetzt zwingt mich aber ein neues Problem mich mit der Sirene zu beschäftigen:
Habe mir im November '15 zwei dieser Sirenen gekauft und die erste gleich in Betrieb genommen. Sie hat auch über den Winter gut funktioniert.
Aber seit erstem März verliert FHEM die Verbindung zur Sirene:
ZW_Sirene_A1.log:
2016-03-25_11:33:18 ZW_Sirene_A1 SEND_DATA: failed:00
2016-03-25_11:33:18 ZW_Sirene_A1 TRANSMIT_NO_ACK
fhem.log:
2016.03.25 11:33:17 2: ERROR: cannot SEND_DATA to ZW_Sirene_A1: transmit queue overflow
2016.03.25 11:33:18 3: ZW_Sirene_A1: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2016.03.25 11:33:18 2: ZWDongle_0 transmit NO_ACK for CB 05, target ZW_Sirene_A1
In diesem Zustand leuchten die Blitz-LEDs der Sirene schwach und es ist ein leises Pfeifen zu hören. Ich muß dann die Sirene vom Halter nehmen, aufschrauben, am internen Schalter ausschalten, wieder einschalten und den Sabotagealarm quittieren (das ganze am Besten mit Gehörschutz!).
Beim Einschalten wird einmal "battery: low" gesendet, danach meldet die Sirene aber gleich wieder "battery: 100 %". Ich messe eine Batteriespannung von über 8V. Bei einer Nennspannung von 7,4V ist das wohl mehr als geladen.
Auch die zweite Sirene, die den Winter in der Wohnung verbracht hat, zeigt nach wenigen Tagen im Freien dieses Verhalten.
Als eine Ursache könnte ich mir die im Frühling höheren Temperaturunterschiede zwischen Tag und Nacht vorstellen, wodurch die internen Klemmen, oder eine Lötstelle nicht mehr richtig kontaktieren.
Wie kann ich ein Software-Problem ausschließen?
Das Problem ist das erste Mal am 1.3. aufgetreten nachdem ich am 28.2.2016 ein FHEM-Update eingespielt habe. auch die Z-Wave Innensirene hat im März 6 mal:"ZWDongle_0 transmit NO_ACK for CB 08, target ZW_Sirene_I1" gemeldet, was vorher nie vorkam! Die Innensirene funktioniert dann aber von alleine wieder.
Andere Z-Wave Geräte hab ich derzeit nicht.
Könnte das Verhalten durch eine Änderung Ende Februar in 00_ZWDongle.pm oder 10_ZWave.pm augelöst worden sein?
Noch eine Info: Die Außensirenen kommunizieren verschlüsselt, die Innensirene (derzeit) nicht.
LG
Rainer
..noch 'was anderes:
mir ist inzwischen aufgefallen, daß die längeren Zeilen in meinen Änderungen für sie fhem_zwave_deviceconfig.xml.gz, die ich hier https://forum.fhem.de/index.php/topic,42736.msg367326.html#msg367326 (https://forum.fhem.de/index.php/topic,42736.msg367326.html#msg367326) gepostet habe, abgeschnitten sind.
Daher poste ich im Dateianhang nochmals den vollständigen Eintrag mit der Bitte die fhem_zwave_deviceconfig.xml.gz zu korrigieren.
Danke!!
Zitat von: gamauf am 29 März 2016, 17:52:51
Daher poste ich im Dateianhang nochmals den vollständigen Eintrag mit der Bitte die fhem_zwave_deviceconfig.xml.gz zu korrigieren.
Habe ich eingecheckt. Ab morgen per update oder heute aus dem SVN.
Gruß, Christian
Zitat von: krikan am 29 März 2016, 18:07:12
Habe ich eingecheckt. Ab morgen per update oder heute aus dem SVN.
Gruß, Christian
Danke!!
LG
Rainer
Zu Deinem eigentlichen Thema:
Ein Log der Fehlersituation mit verbose 5 bei ZWDongle mit den aktuellen Modulversionen könnte bei der Klärung evtl. helfen. Die Infos sind mMn eigentlich zu schmal.
Softwareproblem würde ich versuchen auszuschließen, indem ich alten Stand aus svn oder restoreDir der lokalen Installation zurückspiele und teste. Andererseits sollten die neuesten Module (ohne SECURITY) noch einmal deutlich besser auch extreme Funksituationen meistern als zu Beginn des Jahres; so zumindest meine Einschätzung/Tests.
Hast Du optimale Funkbedingungen? D.h. gibt es überhaupt Router in Deinem ZWave-Netz?
Witterung/Position hat auch Einfluß auf Funkkommunikation. Darauf würde ich bei NO_ACK tippen.
Aufgrund Deiner Infos und der alten Temperaturprobleme geht man Verdacht derzeit noch in eine andere Richtung....
So, wenn ich jetzt schon dabei bin schreib ich gleich alles was mit zu dieser Sirene so am Herzen liegt:
Firmware-Update:
Habe den Popp-Support nach Hash für Firmware-File gefragt um fehlerfreien Download überprüfen zu können. Antwort war: brauch ich nicht; FW-File ist signiert. Wenn sich bei Download Fehler eingeschlichen hat wäre Signatur ungültig und Gerät verweigert Installation.
Daraus schließe ich, daß das Programmieren eines OTA-FW-Update im FHEM keine Gefahr des "Bricken" des Z-Wave Gerätes birgt.
Ich weiß zwar nicht aus welcher Befehlsfolge so ein FW-Update besteht, stelle es mir aber ganz naiv so vor:
man schickt den Befehl "update FW", danach schickt man die FW-Datei.
Ist der Befehl falsch tut das Gerät nichts.
Kommt die FW-Datei nicht richtig an, dann stimmt die Signatur nicht, das Gerät tut auch nichts.
Erst wenn man alles richtig macht tut das Gerät etwas: es aktualisiert seine FW!
Wie seht Ihr das?
Minustemperaturen-Problem im FHEM korrigieren:
(Die Sirene hat auch ein Thermometer eingebaut; Minus-Temperaturen werden jedoch ab 2359 °C abwärts angezeigt! 0°C wird als 2359 °C angezeigt)
Hab mir als Work-around einen Dummy per Notify mit folgender Formel befüllt:
{
my $x;
my $AbsolutNull;
my $KorrekturWert;
$AbsolutNull=-273.15;
$KorrekturWert=2359;
$x=$EVTPART1;
if($x > ($KorrekturWert + $AbsolutNull)) { #um den positiven Temp.bereich nicht unnötig einzuschränken ;-)
$x -= $KorrekturWert;
$x = int(100*$x)/100;
fhem("set Temperatur_Dummy $x°C"); }
else {
fhem("set Temperatur_Dummy $x°C");; }
}
(2086,85°C entspricht -273,15°C = 0 K; kälter gehts nicht!)
Aber es wäre natürlich bequemer wenn FHEM gleich die richtigen Werte ins Reading und ins Log schreibt.
Hätte mir ein Attribut für Z-Wave Geräte mit dem Korrektur-Wert vorgestellt. Ist das Attribut nicht vorhanden, oder null werden die Temperaturwerte des Gerätes 1:1 übernommen. ist Das Attribut mit einem anderen Korrektur-Wert befüllt wird obige Formel zur Korrektur der Temperaturwerte herangezogen.
Ich verstehe leider die ZWave Module zu wenig um diese Änderungen selber einzubauen. Für den Programmierer des Moduls ist es aber wahrscheinlich nur eine Kleinigkeit. Oder?
LG
Rainer
Zitat von: krikan am 29 März 2016, 18:31:08
Zu Deinem eigentlichen Thema:
Ein Log der Fehlersituation mit verbose 5 bei ZWDongle mit den aktuellen Modulversionen könnte bei der Klärung evtl. helfen. Die Infos sind mMn eigentlich zu schmal.
ist klar, werde das Loggong hochdrehen...
Zitat von: krikan am 29 März 2016, 18:31:08
Softwareproblem würde ich versuchen auszuschließen, indem ich alten Stand aus svn oder restoreDir der lokalen Installation zurückspiele und teste. Andererseits sollten die neuesten Module (ohne SECURITY) noch einmal deutlich besser auch extreme Funksituationen meistern als zu Beginn des Jahres; so zumindest meine Einschätzung/Tests.
mein ältester Eintrag im Restore dir ist vom 4.3. :-(
hab zu oft aktualisiert!
Zitat von: krikan am 29 März 2016, 18:31:08
Hast Du optimale Funkbedingungen? D.h. gibt es überhaupt Router in Deinem ZWave-Netz?
Witterung/Position hat auch Einfluß auf Funkkommunikation. Darauf würde ich bei NO_ACK tippen.
Den USB-Stick und die Sirene trennen keine fünf Meter und eine Ziegelwand...
Der USB-Stick ist zwar seit Mite Jänner etwas weiter weg von der Sirene, aber bis Anfang März hats ja problemlos funktioniert.
Die Innensirene liegt zwischen Controller und Außensirene. Können Geräte die nicht verschlüsseln die verschlüsselte Kommunikation für andere Geräte routen?
Wie sehe ich ob geroutet wird? In der neighborList haben sich die Geräte gegenseitig.
Z-Wave Geräte zeigen keine RSSI an. Gibt es eine Möglichkeit die Signalstärke zu ermitteln?
Zitat von: krikan am 29 März 2016, 18:31:08
Aufgrund Deiner Infos und der alten Temperaturprobleme geht man Verdacht derzeit noch in eine andere Richtung....
und zwar?
Mit "alten Temperaturprobleme" meinst du, daß die Minustemperaturen über 2000°C angezeigt werden?
Das ist ein, von Popp bestätigter, FW-Bug.
Danke für Deine Antwort!
Schönen Abend
Rainer
ZitatFür den Programmierer des Moduls ist es aber wahrscheinlich nur eine Kleinigkeit.
Nicht unbedingt, wenn es generisch sein soll. @krikan: sollen wir sowas auf die TODO setzen?
Alternativ macht man es mit userReadings, ist nicht so kompliziert:
attr POPE005107 userReadings tmpCorr:temperature { my $t = ReadingsVal("POPE005107","temperature",0);; ($t > 2086.85 ? round($t-2359,2) : $t)."°C"}
Wobei ich zwischen Zahl und °C ein Leerzeichen lassen wuerde.
Zitathab zu oft aktualisiert!
oder "attr global restoreDirs" ist zu klein. Bleibt noch
https://sourceforge.net/p/fhem/code/11149/log/?path=/trunk/fhem/FHEM/10_ZWave.pm
ZitatWie sehe ich ob geroutet wird?
Mir faellt nur ZWCUL ein :)
Zitat von: rudolfkoenig am 29 März 2016, 21:15:35
Nicht unbedingt, wenn es generisch sein soll. @krikan: sollen wir sowas auf die TODO setzen?
Na, dann bin ich es eben Schuld ;) Hatte mich extra zurückgehalten, um anderen die Entscheidung zu überlassen...
Kurz: Nein.
Lang: Das Problem beruht doch auf einem Firmwarebug, der durch ein bereits existentes Firmwareupdate behoben werden kann. Wenn wir jetzt auch noch beginnen so etwas zu behandeln, fehlt die Zeit für
WichtigeresSpannenderes. Einfache Lösung gibt es ohne Modulanpassung über userReadings. Von mir aus packe ich das ins Wiki, wenn ich die Info bekomme, welche Firmwareversion betroffen ist und ab wann behoben.
Hallo!
Danke für Eure Antworten!
Werde das mit dem userReading probieren. Sollte damit auch ohne Modulanpassung auskommen.
Ist die Schreibweise "IF-Abfrage
? Then-Block
: Else-Block" Perl oder ein FHEM Spezifikum?
Zitat von: rudolfkoenig am 29 März 2016, 21:15:35
...
Mir faellt nur ZWCUL ein :)
Habe keinen CUL (für Z-Wave) sondern einen Z-Wave Me USB Stick.
In der neighborList hat jedes Gerät die anderen. Im nodeInfo steht bei
allen drei Geräten "ROUTING_SLAVE sleeping frequentListening:64 beaming:16 routing 40kBaud Vers:4 Security:0"
(hmmmm... die zwei Außensirenen sollten Seurity aktiviert haben!??)
Aber welche Route das Funksignal nimmt kann ich beim ZWDongle nicht herauslesen.
Danke für Eure Unterstützung!
LG
Rainer
Hallo Rainer!
Zitat"ROUTING_SLAVE sleeping frequentListening:64 beaming:16 routing 40kBaud Vers:4 Security:0"
Steht für FLIRS (batteriebetriebene) ZWave-Geräte. FLIRS-Geräte sind keine Router (leiten keine Nachrichten weiter) und helfen Dir nicht die Stabilität des Netzes zu verbessern. Also muss der Controller mit den Sirenen direkt Kontakt haben, sonst bricht die Verbindung zusammen. Bei ZWave-Geräten würde ich bei 5m mit Wand auf Kommunikationsprobleme tippen. Bei Zwave+ muss das nicht so sein, ist aber nicht auszuschließen. Ein ZWave-Netz ohne netzgespeiste Geräte ist grds. suboptimal. Ich behaupte sogar frech, das ist einer der größten Fehler, der bei ZWave immer wieder gemacht wird.
Zitat
(hmmmm... die zwei Außensirenen sollten Seurity aktiviert haben!??)
Kannst Du nicht aus der nodeInfo schließen. Dort besteht noch Verbesserungspotential, das auf meiner Todo verweilt.
ZitatAber welche Route das Funksignal nimmt kann ich beim ZWDongle nicht herauslesen.
Korrekt. Aber da Du keine Router hast bleibt nur direkte Kommunikation.
Experimentieren kannst Du bzgl. der Signalqualität mit den Funktionen der CC Powerlevel. Gibt zumindest eine grobe Abschätzung. Habe das aber nie mit FLIRS-Geräten getestet und mit anderen Geräten trat hier vereinzelt ein Hängenbleiben des Gerätes auf. Also evtl. Ohrschutz anlegen ;).
Das Thema CC FIRMWARE_UPDATE: Ich persönlich werde dort -wie oben erwähnt- nicht dran basteln. Das ist mMn insgesamt eine undankbare Aufgabe die CC in FHEM einzubauen, wenn man kein Testgerät hat. Die CC verschickt Unmengen an Telegrammen. Zudem geht der Bedarf gegen 1 Person. Es gibt mWn nur die Sirene für die überhaupt ein verfügbares Firmwareupdate existiert. Vielleicht hat jemand anderes Spass daran, aber ich wollte Dir zumindest das Problem aufschreiben.
Gruß, Christian
PS: Ist Perl.
Hallo Christian!
Ich will's nicht verschreien, aber seit ich das Logging des ZW-Dongles hochgedreht hab, hängt sich die Sirene nicht mehr auf. Aber es hat die letzten Nächte auch nicht mehr so stark abgekühlt...
Meine (3) Geräte sind alle ZWave+
Die Funkverbindung hat drei Monate lang auch ohne Router gut funktioniert.
Mir ist schon klar, daß ZWave als Mesh-Netzt konzipiert ist, aber da anscheinend nur (Strom-)Netz-betriebene Geräte als Router fungieren, würde meine Alarmanlage bei Stromausfall nicht mehr funktionieren! (FHEM hängt an der USV und läuft bei Stromausfall daher noch einige Zeit weiter.)
Deine letzten Sätze verstehe ich nicht ganz, da ich nicht weiß wofür "CC" steht. Bitte um Aufklärung!
Es ist schon klar und nachvollziehbar, daß Ihr (die, die an der Entwicklung von FHEM mitarbeiten) keine (größeren) Aufwände treibt die nur einem Einzelnen zu gute kommen.
Den Bedarf fürs FW-Update hätte ich größer eingeschätzt. Aber wenn es, wie Du sagst, tatsächlich erst ein Gerät gibt für das ein Update zur Verfügung steht und die Zahl der Benutzer dieses Gerätes sich auch noch recht in Grenzen hält (wie man an der Beteiligung in diesen Thread sieht), gibt es derzeit sicher höher priorisierte Tasks.
Welche Sirenen verwenden andere Leute?
Diese hier hat doch einige Vorteile:
- Kabellos - keine Stemmarbeiten, einfach zu installieren
- Batteriebetrieben - funktioniert auch bei Stromausfall
- Solarzellen zum Aufladen der Batterie - kein Batterietausch notwendig
Gibt es ZWave Repeater die ich über die Ethernet-Verkabelung mit Strom versorgen könnte? (Also mit Niederspannung, keine 230V)
So bin am Ende etwas abgeschweift...
Danke für Deine Antworten!
LG
Rainer
Hallo Rainer!
Worauf die nicht so starke Abkühlung und bleibende Funktionsfähigkeit jetzt hindeutet, wissen wir dann leider immer noch nicht. Entweder verträgt die Sirene keine starken Temperaturschwankungen oder die Funkverbindung war bei der Witterung besser oder FHEM hat keinen Fehler gemacht oder....
CC steht für Command Class. Die CC Powerlevel dient der Ermittlung der Qualität der Funkverbindung. Details findest Du in der commandref zum ZWave-Modul oder hier im Forum vergraben. Deine Popp-Sirene unterstützt die Command Class laut pepper1.
Hier wird auch für Einzelne entwickelt ;-) , wenn jemand Spass daran hat. Hoffe und warte einfach, wenn es nicht drängt. Manchmal/Oft geht es schneller als man denkt. Bevor der falsche Eindruck entsteht: Bin definitiv kein Developer.
Nutze selbst eine netzbetriebene AEOTEC Innensirene, die eine Backup-Batterie hat. Selbst wenn der Strom ausfällt, lärmt die weiter UND routet. Letzteres habe ich selbst getestet. Wie lange, kann ich aber nicht sagen.
Kenne keinen solchen Repeater. Einziger mit bekannter, halbwegs aktueller Repeater ist von AEOTEC. Der hat aber kein ZWave+ und macht Dir afaik die +-Funkeigenschaften der Geräte ggfs. kaputt.
Gruß, Christian
Hallo Christian!
Ist das diese: Aeotec Sirene ZW080-BI - Z-Wave Plus
Und die routet auch im Batteriebetrieb?
Wäre dann die Überlegung wert das Gerät als Router einzusetzen!
Danke für die Infos!
LG
Rainer
Diese: http://products.zwavealliance.com/products/1136
ZitatUnd die routet auch im Batteriebetrieb?
Nach meinen Feststellungen: Ja
Hat mich bei Reichweitentest zur Verzweifelung getrieben. Ich wusste nicht, warum mein batteriebetriebener Sensor plötzlich Riesenreichweite hatte, obwohl alle netzbetriebenen Router ausgesteckt/stromlos waren. Erst Sirene im Metall-Kochtopf brachte plausible Rechweiten. -> Schlußfolgerung siehe oben
Wie lange eingebaute Backup-Batterie (Akku) hält kann ich aber nicht sagen.
Letzte Gewissheit bietet Dir nur Auskunft von AEOTEC. Die antworten normalerweise auch kompetent und zügig. Wenn Du fragst, bitte berichten.
ZitatWäre dann die Überlegung wert das Gerät als Router einzusetzen!
Wenn das denn wirklich Dein ZWave-Problem löst/ist.
Gruß, Christian
Hi,
Zitat von: krikan am 30 März 2016, 21:27:46
Das Thema CC FIRMWARE_UPDATE: Ich persönlich werde dort -wie oben erwähnt- nicht dran basteln. Das ist mMn insgesamt eine undankbare Aufgabe die CC in FHEM einzubauen, wenn man kein Testgerät hat. Die CC verschickt Unmengen an Telegrammen. Zudem geht der Bedarf gegen 1 Person. Es gibt mWn nur die Sirene für die überhaupt ein verfügbares Firmwareupdate existiert. Vielleicht hat jemand anderes Spass daran, aber ich wollte Dir zumindest das Problem aufschreiben.
ich hatte mal angefangen mir das anzuschauen aber mangels eines verfügbaren Update-Files erst mal nicht weiter verfolgt. Problem ist das z.B. AEOTEC das Updatefile nicht so freigibt, die wollen ein NDA haben und das File soll anscheinend in die Applikation integriert/eincompiliert werden, damit es nicht so "offen" rumliegt. Das ist bei einem Open-Source Perl Projekt schon mal nicht so ohne weiteres machbar... Daher habe ich das erst mal wieder liegen lassen, vor allem da ja noch einige Sachen in Security und dem ZWCul offen sind.
Die Implementation wäre vermutlich gar nicht soooo schwierig/aufwändig, aber der Nutzen liegt nur ganz knapp im messbaren Bereich...
Gruß,
Andreas.
Hallo Christian!
Danke für die Infos
Zitat von: krikan am 01 April 2016, 20:01:28
Wenn das denn wirklich Dein ZWave-Problem löst/ist.
Das aktuelle Problem halte ich eher nicht für ein Funkreichweitenproblem. Aber die erwähnet zweite Sirene, die ich noch nicht montiert habe, soll an einem Platz der derzeit außerhalb der Funkreichweite des ZWave-Dongels liegt. Da würde mir diese Innensirene als Repeater durchaus helfen!
So nach fünf Tagen hat sich das Teil jetzt wieder aufgehängt!
Hier das Log:
2016.04.03 11:40:59 4: ZWDongle_Read ZWDongle_0: rcvd 00040012029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.04.03 11:40:59 5: SW: 06
2016.04.03 11:40:59 5: ZWDongle_0 dispatch 00040012029840
2016.04.03 11:40:59 4: CMD:APPLICATION_COMMAND_HANDLER ID:12 ARG:029840 CB:00
2016.04.03 11:40:59 5: ZWDongle_Write 0013120a988059d9cb48fef1b3cb2576 (cb838b79)
2016.04.03 11:40:59 5: SW: 01110013120a988059d9cb48fef1b3cb2576da
2016.04.03 11:40:59 5: ACK received, WaitForAck=>2 for 01110013120a988059d9cb48fef1b3cb2576da
2016.04.03 11:40:59 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.04.03 11:40:59 5: SW: 06
2016.04.03 11:40:59 5: ZWDongle_0 dispatch 011301
2016.04.03 11:40:59 4: ZWDongle_Read ZWDongle_0: rcvd 001376000003 (request ZW_SEND_DATA), sending ACK
2016.04.03 11:40:59 5: SW: 06
2016.04.03 11:40:59 5: device ack reveived, removing 01110013120a988059d9cb48fef1b3cb2576da from dongle sendstack
2016.04.03 11:40:59 5: ZWDongle_0 dispatch 001376000003
2016.04.03 11:40:59 4: CMD:ZW_SEND_DATA ID:00 ARG:0003 CB:76
2016.04.03 11:40:59 4: ZWDongle_0 transmit OK for CB 76, target ZW_Sirene_A2
2016.04.03 11:40:59 4: ZWDongle_Read ZWDongle_0: rcvd 000400121a9881b7b6bf8b944a12d26d1885617fe33059fe688d43091a4803 (request APPLICATION_C
2016.04.03 11:40:59 5: SW: 06
2016.04.03 11:40:59 5: ZWDongle_0 dispatch 000400121a9881b7b6bf8b944a12d26d1885617fe33059fe688d43091a4803
2016.04.03 11:40:59 4: CMD:APPLICATION_COMMAND_HANDLER ID:12 ARG:1a9881b7b6bf8b944a12d26d1885617fe33059fe688d43091a4803 CB:00
2016.04.03 11:40:59 4: CMD:APPLICATION_COMMAND_HANDLER ID:12 ARG:063105012200b9 CB:00
2016.04.03 11:40:59 1: PERL WARNING: Argument "18.5 C" isn't numeric in numeric gt (>) at (eval 1056) line 1.
2016.04.03 11:40:59 1: PERL WARNING: Argument "18.5 °C" isn't numeric in numeric gt (>) at (eval 1057) line 1.
2016.04.03 11:40:59 1: PERL WARNING: Argument "18.5 °C" isn't numeric in numeric gt (>) at (eval 1058) line 1.
...
2016.04.04 12:02:37 2: ZWave get ZW_Sirene_A2 battery
2016.04.04 12:02:37 5: ZWDongle_Write 0013120280022577 (cb838b79)
2016.04.04 12:02:37 5: SW: 0109001312028002257725
2016.04.04 12:02:37 4: ZWDongle_ReadAnswer arg:battery regexp:^00040012..80
2016.04.04 12:02:37 5: ACK received, WaitForAck=>2 for 0109001312028002257725
2016.04.04 12:02:37 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.04.04 12:02:37 5: SW: 06
2016.04.04 12:02:37 5: ZWDongle_0 dispatch 011301
2016.04.04 12:02:38 5: ZWDongle_ReadAnswer: select timeout
2016.04.04 12:02:39 4: no response from device, removing 0109001312028002257725 from dongle sendstack
2016.04.04 12:02:42 2: ZWave: No ACK from ZW_Sirene_A2 after 5s for sentget:13120280022577
2016.04.04 12:02:44 4: ZWDongle_Read ZWDongle_0: rcvd 0013770102c4 (request ZW_SEND_DATA), sending ACK
2016.04.04 12:02:44 5: SW: 06
2016.04.04 12:02:44 5: ZWDongle_0 dispatch 0013770102c4
2016.04.04 12:02:44 4: CMD:ZW_SEND_DATA ID:01 ARG:02c4 CB:77
2016.04.04 12:02:44 2: ZWDongle_0 transmit NO_ACK for CB 77, target ZW_Sirene_A2
2016.04.04 12:03:05 1: PERL WARNING: Argument "22.8 C" isn't numeric in numeric gt (>) at (eval 1189) line 1.
2016.04.04 12:03:05 1: PERL WARNING: Argument "18.5 C" isn't numeric in numeric gt (>) at (eval 1190) line 1.
2016.04.04 12:03:05 1: PERL WARNING: Argument "18.5 °C" isn't numeric in numeric gt (>) at (eval 1191) line 1.
2016.04.04 12:03:10 1: PERL WARNING: Argument "22.8 C" isn't numeric in numeric gt (>) at (eval 1197) line 1.
2016.04.04 12:03:10 1: PERL WARNING: Argument "18.5 C" isn't numeric in numeric gt (>) at (eval 1198) line 1.
2016.04.04 12:03:10 1: PERL WARNING: Argument "18.5 °C" isn't numeric in numeric gt (>) at (eval 1199) line 1.Am 3.4.2016 um 11:40 kam die letzte Temperaturmeldung herein, seither herrscht Funkstille (bei der Außensirene).
(Einträge anderer Geräte hab ich aus dem Log gelöscht...)
Nachdem mir heute aufgefallen ist, daß keine aktuelle Temperatur vorliegt, hab ich ein "ZWave get ZW_Sirene_A2 battery" abgesetzt, auf das keine Antwort kam.
Siehst Du mehr im Log?
In diesem Zustand triggert das Gerät auch nicht bei Auslösung des Sabotagekontaktes, was doch auch ohne Verbindung zur Zentrale funktionieren sollte!
Für mich sieht das aus, als würde sich das Gerät, warum auch immer, aufhängen (sein Prozessor abstürzen)!
Zitat von: A.Harrenberg am 02 April 2016, 19:21:24
...ich hatte mal angefangen mir das anzuschauen aber mangels eines verfügbaren Update-Files erst mal nicht weiter verfolgt.
...
Daher habe ich das erst mal wieder liegen lassen, vor allem da ja noch einige Sachen in Security und dem ZWCul offen sind.
Hallo Andreas!
Falls Du es doch noch einmal probieren willst, gibt es hier: http://new.zwave.eu/ota.php (http://new.zwave.eu/ota.php) ein FW-File, ganz ohne NDA, zum herunterladen.
Aber auch ich bin der Menung, daß eine funktionierende Security derzeit wichtiger ist als die Möglichkeit des FW-Update.
LG
Rainer
Zitat von: gamauf am 04 April 2016, 12:44:08
Siehst Du mehr im Log?
Sehe auch nur, dass keine Antwort kommt. Habe aber von SECURITY, das im Log auftaucht, keine Ahnung.
Empfängt ZWDongle in dem gelöschten Log-Zeitraum noch andere Geräte?
Musst Du jetzt die Sirene stromlos machen, damit die wieder funktioniert?
Btw. Vermute die PERL WARNING könnten aus obigen userReadings kommen. Nutze mal ReadingsNum statt ReadingsVal und schau, ob die dann weg sind.
Ich vermute, Andreas meinte mit "Security und ZWCUL" die Moeglichekeit auch mit dem CUL die Klasse Security verwenden zu koennen.
Mit dem ZWDongle sind mir keine Security-Probleme bekannt.
Zitat von: krikan am 04 April 2016, 13:36:52
Empfängt ZWDongle in dem gelöschten Log-Zeitraum noch andere Geräte?
Musst Du jetzt die Sirene stromlos machen, damit die wieder funktioniert?
Außer der Außensirene ist derzeit nur noch die Innensirene aktiv. Da sie von sich aus nichts sendet (hat kein Termometer eingebaut) und es auch sonst keinen Grund gab sie anzusprechen steht nichts im Log. Sie ist aber Ansprechbar:
2016.04.04 14:29:16 2: ZWave get ZW_Sirene_I1 battery
2016.04.04 14:29:16 5: ZWDongle_Write 00130f0280022578 (cb838b79)
2016.04.04 14:29:16 5: SW: 010900130f028002257837
2016.04.04 14:29:16 4: ZWDongle_ReadAnswer arg:battery regexp:^0004000f..80
2016.04.04 14:29:16 5: ACK received, WaitForAck=>2 for 010900130f028002257837
2016.04.04 14:29:16 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.04.04 14:29:16 5: SW: 06
2016.04.04 14:29:16 5: ZWDongle_0 dispatch 011301
2016.04.04 14:29:17 5: ZWDongle_ReadAnswer: select timeout
2016.04.04 14:29:17 4: ZWDongle_Read ZWDongle_0: rcvd 001378000084 (request ZW_SEND_DATA), sending ACK
2016.04.04 14:29:17 5: SW: 06
2016.04.04 14:29:17 5: device ack reveived, removing 010900130f028002257837 from dongle sendstack
2016.04.04 14:29:17 5: ZWDongle_0 dispatch 001378000084
2016.04.04 14:29:17 4: CMD:ZW_SEND_DATA ID:00 ARG:0084 CB:78
2016.04.04 14:29:17 4: ZWDongle_0 transmit OK for CB 78, target ZW_Sirene_I1
2016.04.04 14:29:17 4: ZWDongle_Read ZWDongle_0: rcvd 0004000f03800346 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.04.04 14:29:17 5: SW: 06
2016.04.04 14:29:17 5: ZWDongle_0 dispatch 0004000f03800346
2016.04.04 14:29:17 4: CMD:APPLICATION_COMMAND_HANDLER ID:0f ARG:03800346 CB:00
...
2016.04.04 14:33:01 2: ZWave get ZW_Sirene_A2 smStatus
2016.04.04 14:33:01 5: ZWDongle_Write 001312029840257a (cb838b79)
2016.04.04 14:33:01 5: SW: 0109001312029840257a72
2016.04.04 14:33:01 5: ACK received, WaitForAck=>2 for 0109001312029840257a72
2016.04.04 14:33:01 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.04.04 14:33:01 5: SW: 06
2016.04.04 14:33:01 5: ZWDongle_0 dispatch 011301
2016.04.04 14:33:03 4: no response from device, removing 0109001312029840257a72 from dongle sendstack
2016.04.04 14:33:04 4: ZWDongle_Read ZWDongle_0: rcvd 00137a01015b (request ZW_SEND_DATA), sending ACK
2016.04.04 14:33:04 5: SW: 06
2016.04.04 14:33:04 5: ZWDongle_0 dispatch 00137a01015b
2016.04.04 14:33:04 4: CMD:ZW_SEND_DATA ID:01 ARG:015b CB:7a
2016.04.04 14:33:04 2: ZWDongle_0 transmit NO_ACK for CB 7a, target ZW_Sirene_A2
2016.04.04 14:33:06 2: ZWave: No ACK from ZW_Sirene_A2 after 5s for sentset:1312029840257a
2016.04.04 14:33:08 3: ZW_Sirene_A2: secStart older than 6 seconds detected, secUnlock will call Zwave_secEndJa, damit die Außensirene wieder funktioniert muß ich sie aus- und wieder einschalten (Stromlos machen).
Zitat von: krikan am 04 April 2016, 13:36:52
Btw. Vermute die PERL WARNING könnten aus obigen userReadings kommen. Nutze mal ReadingsNum statt ReadingsVal und schau, ob die dann weg sind.
Die PERL WARNINGs kommen von einer ReadingsGroup die Temperaturmeßwerte zusammenfaßt. Die Geräte hängen an den Temperaturwert ein "C" dran. Hab noch nicht herausgefunden, wie ich das wegbekomme. Es ist warscheinlich das "valueStyle" Attribut in dem ich "$VALUE" mit einem Zahlenwert vergleiche. "$VALUE" endet auf " C", was keine Zahl ist...
(Das hat natürlich nichts mit der ZWave Kommunikation zu tun, ich hab die Logzeilen aber drin gelassen, damit sie Dir vielleicht auffallen und Du möglw. einen Tipp für mich hast! ;-) )
Zitat von: rudolfkoenig am 04 April 2016, 14:23:10
...
Mit dem ZWDongle sind mir keine Security-Probleme bekannt.
Sehr gut!
Danke!
Zitat von: gamauf am 04 April 2016, 14:43:52
Sie ist aber Ansprechbar:
...
Ja, damit die Außensirene wieder funktioniert muß ich sie aus- und wieder einschalten (Stromlos machen).
Also kein hängengebliebenes Dongle.
Dann bin ich am Ende mit (Nebel)Tipps ;)
Firmwareupdate wäre wohl sinnvoll. Evtl. hilft das. Ansonsten bleibt nur eine andere Schlußfolgerung...
Zitat
Die PERL WARNINGs kommen von einer ReadingsGroup die Temperaturmeßwerte zusammenfaßt.
@Rudi: Sorry
Hi Rainer,
Zitat von: gamauf am 04 April 2016, 12:44:08
Hallo Andreas!
Falls Du es doch noch einmal probieren willst, gibt es hier: http://new.zwave.eu/ota.php (http://new.zwave.eu/ota.php) ein FW-File, ganz ohne NDA, zum herunterladen.
Aber auch ich bin der Menung, daß eine funktionierende Security derzeit wichtiger ist als die Möglichkeit des FW-Update.
Danke, aber das nutzt mir nichts da ich das dazugehörende Gerät ja nicht habe...
Ich schau mir das File aber trotzdem bei Gelegenheit mal an um zu sehen ob da die Checksumme mit in dem File drin steht oder ob man die extern berechnen muss.
Gruß,
Andreas.
Hallo!
Erst einmal danke für Eure Tipps.
Ich fasse nochmal die von mir festgestellten "Problemchen" zusammen:
- Temperaturen unter 0°C:
0°C wird als 2359°C, Temperaturen unter 0 mit entsprechend "kleineren" Werten angezeigt.
Workaround: kann durch ein Userreading im FHEM korigiert werden.
Fix: forhandenes FW Update, das dieses Problem beheben soll kann mit FHEM nicht eingespielt werden. - Parameter 6 "auto OFF" kann nicht gesetzt werden.
Hab mehrmals versicht, sowohl über "set <Device> ConfigAutoOFF 2" als auch "set <Device> configByte 6 2" den Parameter vom default "0" auf "2" zu ändern, nach einem "get <Device> configAutoOFF" oder auch "get <Device> config 6" oder "get <Device> configAll" ist es immer noch auf "0"
Workaround: aus FHEM programmatisch nach 2 Minuten wieder abschalten
Fix: keiner bekannt - egal was in Parameter 4 (Send unsolicited temperature report after N wake up) steht die Sirene meldet nur neue Temperaturwerte wenn sich die gemessene Temperatur um mehr als in Parameter 3 angegeben Ändert.
Workaround: Watchgdog, der wenn der letzte gemeldete Temperaturwert älter als eine Stunde ist die aktuelle Temperatur abfragt.
Fix: keiner bekannt - Das Gerät meldet von sich aus keinen Batteriestand, außer nach einem der oben genannten Hänger ein "battery: low". Wenn mann unmittelbar darauf (hab ich automatisiert) den Batteriestand abfragt ("get <Device> battery") wird "battery: 100 %" gemeldet. Hab von dem Gerät auf "get <Device> battery" noch nie eine andere Antwort als "battery: 100 %" bekommen!
Workaround: keiner bekannt
Fix: keiner bekannt - Und zum Schluß der hier viel besprochene Hänger.
Wie äußert sich so ein Hänger:
- Keine Reaktion auf Anfragen/Komandios von FHEM
- Sendet auch vin sich aus keine Meldungen (Temperatur, Sabotagemeldung, etc.)
- es ist ein leises Pfeifen zu hören
- Die Blitz-LEDs glimmen schwach
- Nimmt man das Gerät von der Wandhalterung geht es nicht los, obwohl es entsprechend konfiguriert ist (parameter 1 set to "0", parameter 5 set to "2")
Um die Sirene wieder zum Leben zu erwecken kan man entweder
oder
- Das Gerät von der Wand nehmen, es aufschrauben, es ausschalten und wieder einschalten, worauf der Alarm los geht, wenn man es nicht auf der Wandhalterung hat (oder dies durch einen Magneten an der richtigen Stelle vortäuscht)!
Der Popp Support sieht zwei möglich Ursachen:
- Bei direkter Sonneneinstrahlung kann das Gerät über 80°C bekommen was an der grenze der Spezifikation des ZWave Chips ist.
Man hat mir angeboten das Gerät zurückzukaufen
(Mein Gerät hat erst Temperaturen bis knapp über 40°C gemeldet) - Fehlender FLIRS Support des Controllers
So weit ich weiß ist FLIRS eine Methode wie der Controller ein Batterie-betriebenes Gerät sofort aufwecken kann.
Würde FHEM die Sirene nicht aufwecken können, würde das Gerät wenige Minuten nach dem Einschalten auf FHEM nicht mehr reagieren. Sehr wohl würde es aber von sich aus Meldungen an FHEM absetzen können: Temperatur Meldungen Sabotage-Alarm, etc., bzw. unabhängig von FHEM Losheulen wenn man es von der Wand nimmt. Das ist aber bei einem "Hänger" nicht der Fall! Solange sich die Sirene nicht aufgehängt hat kann FHEM aber sehr wohl Temperatur abfragen (geschieht stündlich) oder auch sonst mit dem Gerät kommunizieren. Auch Stunden nach dem Einschalten.
Fehlender FLIRS Support klingt für mich daher nicht plausibel.
Ich vermute viel eher ein Problem mit der Stromversorgung bzw. dr Ladeschaltung des Accus:
Habe den Eindruck, daß wen zu viel Licht auf das große Solar-Panel fällt die Hänger auftreten.
Daher experimentiere ich derzeit damit die Solarzellen teilweise abzudecken. Habe den Eindruck, daß die Hänger jetzt seltener auftreten.
Im Winter wird man die Abdeckung aber vermutlich wieder entfernen oder reduzieren müssen! Vielleicht wären auch Lamellen die bei höherem Sonnenstand abschatten, bei flachem Sonnenstand aber direkte Bestrahlung zulassen eine Möglichkeit.
Hier muß ich noch weiter experimentieren...
Halte Euch auf dem Laufenden.
LG
Rainer
Dein ZWave.me UZB1 kann grds. FLIRS. Es sei denn, er ist defekt oder inkompatibel zur Popp Sirene. Letzteres würde mich wundern, da zwave.me auch bei der Sirene mitmischt.
Nachdem mein Popp Rauchmelder irrtümlich die modelId Deiner Sirene hat (https://forum.fhem.de/index.php/topic,53315.msg455109.html#msg455109) bin ich leicht hinsichtlich Popp verunsichert...
Nachtrag zum Problem Nr. 2:
Zitat von: gamauf am 08 Juni 2016, 17:29:05
- Parameter 6 "auto OFF" kann nicht gesetzt werden.
Hab mehrmals versicht, sowohl über "set <Device> ConfigAutoOFF 2" als auch "set <Device> configByte 6 2" den Parameter vom default "0" auf "2" zu ändern, nach einem "get <Device> configAutoOFF" oder auch "get <Device> config 6" oder "get <Device> configAll" ist es immer noch auf "0"
Workaround: aus FHEM programmatisch nach 2 Minuten wieder abschalten
Fix: keiner bekannt
Laut Popp Support ligt der Fehler ausschlißlich an der Abfrage des Parameter 6; es wird immer "0" zurückgemeldet. Aber der gesetzte Wert wird angeblich vom Gerät berücksichtigt!
Also ein "set <Device> ConfigAutoOFF 2" bewirkt angeblich sehr wohl, daß sich die Sirene nach zwei Minuten wieder abstellt, auch wenn bei "get <Device> configAutoOFF" immer "0" zurückgegeben wird.
d.h. Firmwarefehler und Firmware-Update kommt?
Zitat von: krikan am 23 Juni 2016, 15:10:37
d.h. Firmwarefehler und Firmware-Update kommt?
davon hat Popp Support nichts gesagt:
Zitat
> One other "minor problem" I forgot to mention is, that I am not able
> to set parameter 6 (auto OFF)
> after setting it to "2" and the queering its value the device always
> returns "0"
> Also it never had the default value of "5" mentioned in the manual.
this is true, we found this but too. The value is set but the wrong
value is returned.
Auch zu den Problemen 3 & 4 hat er sich nicht geäußert und auf mein letztes Nachfrage-Mail am 9.6. nicht mehr geantwortet.
Ich bin pessimistisch ... mein ganz persönlicher Eindruck ist, daß das Interesse von Popp an diesem Produkt schwindet...
:-(
...aber vielleicht sind sie motivierter die Probleme zu beheben, wenn sich mehr Kunden bei Popp melden...
Hallo Rainer!
Da ich versuche ein wenig Durchblick bei der CC FIRMWARE_UPDATE_MD zu bekommen, waere es für mich hilfreich, wenn ich die Hexantwort der Popp Sirene auf die nachfolgende Abfrage der Firmwareinfos haette:
get <ZWDongle> raw 13[nodeIdHex]027a0125
Könntest Du das bitte machen, wenn Du die Sirene noch in FHEM eingebunden hast?
[nodeIdHex] muss durch die entsprechende hexadezimale NodeId (2stellig) ersetzt werden. Das Ergebnis steht anschließend im Reading UNPARSED der Device-Details der Sirene oder bei verbose 5 bei ZWDongle auch im Log.
Die Abfrage liefert Infos zur manufId, FirmwareId, FirmwareChecksumme u.a. .
Danke und Gruß, Christian
PS: Falls Du keine Zeit/Lust dazu hast, ist das auch Ok :).
Hallo Christian!
Die Antwort im "UNPASED" Reading:
FIRMWARE_UPDATE_MD 0e7a0201150101b5220100001e0000
LG
Rainer
Hallo Reiner!
Das ging schnell. :)
Ergebnis nach meiner derzeitigen Interpretation in (Halb)klartext (work in progress):
manufId 0115 fwId 0101 fwChecksum b522 upgradable 01 nrTargets 00 maxFragmentSize 001e fwId1 0000
manufId ist die von zwave.me und nicht von Popp analog zu den Popp Rauchmeldern.
Du hast noch kein Firmwareupdate auf http://ota.zwave.eu/OTA/POPE005107/POPE005107_BOOT_V1.3_FOR_OTA_15_12_2015.bin gemacht. Korrekt?
Wenn Du "get <device> version" abrufst, ist dann App = 1.01?
Ansonsten muss ich noch weiter suchen/basteln..
Gruß, Christian
Hallo Christian!
Wenn Du das FW-Update hin bekommst profetiere ich ja auch davon; ist also in meinem eigenen Interesse Dir zu helfen!
;)
Ich glaube Popp läßt alles bei zwave.me entwickeln...
Richtig, ich habe das Update NICHT installiert.
Nein, App = 1.1
version Lib 3 Prot 4.5 App 1.1 HW 1 FWCounter 0
Viel Erfolg!
LG
Rainer
Zitat von: gamauf am 05 August 2016, 18:37:29
Wenn Du das FW-Update hin bekommst profetiere ich ja auch davon; ist also in meinem eigenen Interesse Dir zu helfen!
Langsam an ;) Ist bisher ein steiniger Weg wegen wenig Infos und insbesondere Beispiele. V2 der Class klappt zumindest mit AEOTEC Multisensor schon, aber mir fehlen noch viele Details und V3 für die Popp Sirene und meine Popp Rauchmelder ist derzeit für mich noch ein Riesenfragezeichen mit eingebauter Elektroschrottproduktionsgefahr..
ZitatIch glaube Popp läßt alles bei zwave.me entwickeln...
Ja, das sieht so aus.
ZitatNein, App = 1.1
version Lib 3 Prot 4.5 App 1.1 HW 1 FWCounter 0
Ja, sieht in der Anzeige momentan wie .1 aus, Raw-Wert ist aber 01hex. Das interpretiere ich als .01 also 1.01 und habe für mich 10_Zwave.pm so umgebaut.
Dabei sind sich die Hersteller aber auch nicht einig: 07hex ist bei Fibaro .7 und bei Aeotec .07
Gruß, Christian
Zitat von: krikan am 05 August 2016, 21:44:57
Ja, sieht in der Anzeige momentan wie .1 aus, Raw-Wert ist aber 01hex. Das interpretiere ich als .01 also 1.01 und habe für mich 10_Zwave.pm so umgebaut.
Dabei sind sich die Hersteller aber auch nicht einig: 07hex ist bei Fibaro .7 und bei Aeotec .07
Vielleicht könntest Du mir doch das Log mit verbose 5 der "get <device> version" - Abfrage mit der Antwort posten. Nicht, dass es doch 1.1 ist und ich etwas übersehe.
Hallo Rainer,
Sigma Designs hat für den Raspberry eine vorkonfigurierte Z-Ware Installation unter http://z-wave.sigmadesigns.com/design-z-wave/z-wave-public-specification/ (Seite ganz untern) veröffentlicht, die auch FIRMWARE_UPDATE_MD bis zur Version 3 unterstützt. Vielleicht hilft Dir das für das Sirenen-Update.
Ob und wann ich bei der Class weiterarbeite habe ich angesichts der Veröffentlichung der Specs und der Z-Ware noch nicht entschieden.
Gruß, Christian
Hallo Christian!
Freut mich, daß Du an mich gedacht hast. Danke!
Vielleicht probier ich's, wenn ich mal viel Zeit übrig hab, aus, aber da ich mit dem UserReading einen funktionierenden Workarround für das einzige Problem das dezeit in der neuen FW gefixt ist habe ist die Priorität für mich da derzeit eher gering...
aber so straight forward dürfte das mit dem Raspberry image auch nicht klappen wie man hier lesen kann:
https://forum.fhem.de/index.php/topic,57300.msg488275.html#msg488275 (https://forum.fhem.de/index.php/topic,57300.msg488275.html#msg488275)
Kann es sein das ich Dir hier noch eine Antwort schulde?:
Zitat von: krikan am 05 August 2016, 22:12:15
Vielleicht könntest Du mir doch das Log mit verbose 5 der "get <device> version" - Abfrage mit der Antwort posten. Nicht, dass es doch 1.1 ist und ich etwas übersehe.
Hab das womöglich in der Ferienzeit übersehen!
Grüße
Rainer
Hi,
Zitat von: gamauf am 06 September 2016, 12:42:39
aber so straight forward dürfte das mit dem Raspberry image auch nicht klappen wie man hier lesen kann:
https://forum.fhem.de/index.php/topic,57300.msg488275.html#msg488275 (https://forum.fhem.de/index.php/topic,57300.msg488275.html#msg488275)
na ja, ich habe auch nicht wirklich VIEL Energie reingsteckt um die Dokus zu lesen ,-)
Aber ja, ZWave-Stick reinstecken und booten reicht anscheinend schon mal nicht aus um das was rauszukitzeln.
Gruß,
Andreas.
Zitat von: A.Harrenberg am 06 September 2016, 12:58:52
Aber ja, ZWave-Stick reinstecken und booten reicht anscheinend schon mal nicht aus um das was rauszukitzeln.
genau das hab ich gemeint ... ohne viel Energie rein zu stecken schnell mal ein FW-Update einspielen... wird nicht funktionieren.
und die viele Energie ist bei mir derzeit wo anders besser aufgehoben... ;)
Grüße
Rainer
Hi,
Zitat von: gamauf am 06 September 2016, 14:43:17
genau das hab ich gemeint ... ohne viel Energie rein zu stecken schnell mal ein FW-Update einspielen... wird nicht funktionieren.
selbst wenn das System "läuft" kommst Du erst mal nicht weiter, Du brauchst ja ein Updatefile das vom Aufbau her zu dem System "passt". Und ich würde mich nicht darauf verlassen das solche Files immer nur die reinen Binärdaten enthalten und nicht vielleicht auch irgendwelche Zusatzinfos die der Update des jeweiligen Herstellers dann auswertet und "ausfiltert".
Gruß,
Andreas.
Hallo!
Das von Reiner beschrieben Problem (Antwort #53; hängt sich auf) tritt auch bei meiner Sirene (Lib 3 Prot 4.5 App 1.3 HW 1 FWCounter 0) auf.
Der Popp-Support (Antwort von heute) verweist nun auf eine aktuelle Firmware 1.4 (http://ota.zwave.eu/).
Das Firmware-Update soll über Z-Way laufen:
http://manuals-backend.z-wave.info/make.php?lang=de&sku=pope005107&type=popp
Hat damit schon jemand Erfahrungen gesammelt?
Außerdem kam die Aussage: "...bei der Sirene handelt es sich um ein Flirs Gerät. Dieses darf nicht vom Controller gepollt werden. Dies kann zu Ihrem beschriebenen Fehlerbild passen....".
Ich habe mein nächtliches "get battery" jetzt deaktiviert, obwohl die "Aufhänger" nicht zeitgleich oder direkt nach dieser Abfrage auftreten.
Kann ich noch etwas tun?
Nachtrag:
Das Problem existiert seit Firmware 1.1 (hier im Beitrag; ich habe 1.3; aktuellste ist 1.4). Der Popp-Hub ist auch nur ein Raspberry. Ich kann mir schwer vorstellen, dass dieses Problem seit Firmware 1.1 auftritt und nicht in 1.2 und 1.3 behoben wurde. Also muss der Popp-Hub "etwas anders" machen – oder er zeigt den Sirenen-Ausfall einfach nicht an und keiner merkt es, bis es wieder von selber zum Laufen kommt.
Gruß
René
Hallo Rene!
Zitat"...bei der Sirene handelt es sich um ein Flirs Gerät. Dieses darf nicht vom Controller gepollt werden. Dies kann zu Ihrem beschriebenen Fehlerbild passen....".
Ein mal pro Tag "get battery" würde ich persönlich nicht als Pollen einordnen. Darf man dann bei der Sirene gar keine Befehle verschicken oder nur im Monatsrhytmus? Das ist eine ersnstgemeinte Frage :) .
Meine Popp FLIRS-Rauchmelder (modelId ist aufgrund einer (immer noch unbehobenen?) Firmwareschwäche gleich der Popp Sirene) hängen sich nicht auf, auch wenn ich sie gelegentlich mit Abfragen quäle.
ZitatAlso muss der Popp-Hub "etwas anders" machen
Hast Du das selbst festgestellt? Falls ja, dann kannst Du evtl. ein Log vom Hub liefern.
Gruß, Christian
Hallo Christian,
ich habe keinen Popp-Hub zum Vergleich. War nur eine Vermutung, weshalb das Problem bei Popp nicht bekannt ist. Ich habe dem Popp-Support geschildert, dass ich die Sirene 1x/Tag abfrage und wurde aufgefordert, diese Abfrage nicht durchzuführen. Das habe ich nun gemacht, obwohl es, wie Du schreibst, wenige logisch klingt.
Der Support betrachtet auch ein Temperaturproblem durch Sonneneinstrahlung als kritisch - sehr gut bei einem Solargerät ;-). Aber das kommt bei mir nicht in Frage. Die Ausfälle treten auch bei kalten Temperaturen und wenig Sonne auf. Ich habe einen Umweltsensor im Einsatz und konnte anhand der Temperatur und Helligkeitswerte kein Schema für die Ausfälle erkennen.
Ich frage den transmit-readings-Wert ab und schicke mir eine Email, wenn ein NO_ACK kommt.
Aber wie wird das NO_ACK eigentlich festgestellt, wenn die Sirene nicht gepollt wird, was sie ja nach Aussage Support (auch in der Doku siehe Link explizit aufgeführt) nicht darf?
Gruß
René
ZitatAber wie wird das NO_ACK eigentlich festgestellt, wenn die Sirene nicht gepollt wird, was sie ja nach Aussage Support (auch in der Doku siehe Link explizit aufgeführt) nicht darf?
NO_ACK kann nur bei Kommunikation zwischen FHEM und Gerät entstehen. Von alleine stößt FHEM mWn keine Kommunikation mit der Sirene an. Das muss grds. durch den User eingerichtet sein. Bei Dir bspw. das "get battery". Wenn NO_ACK für Sirene nach Entfernen von "get battery" immer noch kommt, dann bitte verbose 5 und einmal Log zeigen.
Vorteil von Popp Hub: Softwareentwicklung für Hub und Firmwareentwicklung von Sirene erfolgen afaik vom gleichen Hersteller zwave.me, der die komplette Doku kennt.
Hallo,
als kurze Info zu dem Thema:
Ich war auch in Kontakt mit dem Support wegen der oben von Reiner beschriebenen Probleme (Antwort #53).
Habe jetzt mit Hilfe eines Popp Hubs ein Firmware Update der Sirene von 1.1 auf 1.4 durchgeführt.
Da es allerdings Probleme bei Verwendung der oben verlinkten FW-Dateien gab (keine Reaktion der Sirene nach Abschicken des FW-Updates), habe ich eine (spezielle?) 1.4 Firmware Datei vom Support zugesendet bekommen, die ich hier 'mal anhänge (Erlaubnis vom Popp Support liegt vor).
Damit hat das Update geklappt.
Ob damit jedoch alle Probleme behoben sind, kann ich noch nicht sagen, habe die Sirene noch nicht wieder im "Produktionsbetrieb".
Melde mich dann noch mit weiteren Erfahrungen.
Andreas
Edit:
Noch eine Eigenart, die ich im Laufe meiner Beschäftigung mit dem Gerät herausgefunden habe:
Die Temperaturreports werden von der Sirene nur gesendet, wenn sie auf dem Halter montiert ist!
Was soll der Blödsinn mit "man darf die Sirene nicht pollen"?!
Das ist ja wie mit Schrödingers Katze: schau ja nicht in die Kiste, sonst ist die Katze drinnen tot! Aber solange du nicht hineinschaust weißt du nicht ob sie noch lebt...!
Man merkt dann erst, wenn sie bei einem Einbruch nicht losgeht, dass sie wieder hängt! Guter Vorschlag!!!
Gut zu wissen, dass es eine neue FW gibt, die mehr als nur das Problem mit der negativen Temperatur fixt!
Bin gespannt auf Andreas' (scootys) feedback ob die neue FW hilft. Falls ja, muß ich mir dann eine Möglickkeit suchen die neue FW auf meine Sirenen zu bekommen...
LG
Rainer
Ich musste gestern auf die Leiter und habe die Sirene aus/eingeschaltet, da sie seit 3 Tage nicht mehr geantwortet hat und auch nicht von selbst "zurück gekommen" ist. Die Blitz-LEDs haben geglimmt, ein Pfeifen war diesmal nicht zu hören. Sofort danach ein "get battery" → 100%.
Mit verbose 5 kamen bei mir anschließend bei einem einfachen "off" Fehlermeldungen:
no stored commands in Internal secMsg found
Error, nonce reveived but no stored command for encryption found
Error, no send_nonce to decrypt message available
Der Befehl wurde aber ausgeführt.
Ich habe dann, um Fehlalarm beim Testen zu vermeiden, ein "set Aussensirene configSwitchMode FlashOnly" eingetragen – danach waren diese Fehlermeldungen weg????
Nur eine blöde Idee: Vielleicht muss regelmäßig ein "set-Befehl" abgesetzt werden, damit die Sirene in einem "stabilen Zustand" ist... (werde ich testen)
@Andreas (scooty): Wie hast Du das Update durchgeführt? Kannst Du bitte eine kurze Anleitung zusammenschreiben. Wenn ich irgendwann wieder auf die Leiter muss, möchte ich gleich updaten. Danke!
Gruß
René
Hi,
Zitat von: refi am 09 Dezember 2016, 08:05:32
Mit verbose 5 kamen bei mir anschließend bei einem einfachen "off" Fehlermeldungen:
no stored commands in Internal secMsg found
Error, nonce reveived but no stored command for encryption found
Error, no send_nonce to decrypt message available
das sind typische Fehlermeldungen wenn während der Kommunikation mit Security was schief gelaufen ist und zwischendurch ein Paket verlorengegangen ist. Der Ablauf kommt dann leider durcheinander und es können dabei leider auch Befehle auf dem Security-Sendstack liegen bleiben was dann dazu führt das die ganze Kommunikation ab dann nicht mehr in Ordnung ist ,-(
Wenn Du mal ein Listing des Gerätes machst solltest Du mal schauen ob es im Listing einen Abschnitt mit "secMsg" gibt der noch Befehle enthält. Falls ja hilft momentan leider nur ein Neustart von fhem...
Zitat von: refi am 09 Dezember 2016, 08:05:32
Der Befehl wurde aber ausgeführt.
Ich habe dann, um Fehlalarm beim Testen zu vermeiden, ein "set Aussensirene configSwitchMode FlashOnly" eingetragen – danach waren diese Fehlermeldungen weg????
Ich vermute das DIESER Befehl NICHT ausgeführt wurde sondern ein "älterer" der noch in dem security-Stack lag... Das wäre eine typische Fehlersituation wenn die Kommunikation durcheinander gekommen ist. Es bleiben Befehle auf dem Stack liegen und bei der nächsten Runde wird der alte Befehl ausgeführt und der neue bleibt dann wieder auf dem Stack liegen ,-(
Ein Update das die Robustheit der Kommunikation erhöht wird gerade noch ein wenig getestet und ich werde es voraussichtlich in den nächsten Tagen bei Rudi abgeben damit er es einbaut.
Zitat von: refi am 09 Dezember 2016, 08:05:32
Nur eine blöde Idee: Vielleicht muss regelmäßig ein "set-Befehl" abgesetzt werden, damit die Sirene in einem "stabilen Zustand" ist... (werde ich testen)
Theoretisch möglich, ich halte es aber für nicht sehr wahrscheinlich.
Gruß,
Andreas.
Tauchen die Probleme mit dem "Absturz" der Sirene eigentlich nur bei Einbindung über SECURITY auf? Hat das schon mal jemand getestet?
Hi,
war es nicht so das die Sirene ohne SECURITY keine Funktionen bereitstellt und daher immer mit SECURITY betrieben werden muss?
Gruß,
Andreas.
Keine Ahnung. Laut Handbuch würde ich tippen es geht auch ohne:
ZitatThe secure communication is activated on default during inclusion unless explicitly suppressed.
Hallo,
ich habe nochmal die Logs nach allen "Aufhängern" seit April 2016 durchforstet. Auffällig ist, dass die letzte Meldung vor einem Ausfall folgende ist:
secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
Direkt danach kam jeweils ein NO_ACK von der Sirene.
Zu diesen Zeitpunkten gab es keine Kommunikation zur Sirene, welche durch Aktionen von mir initiiert wurden. Ob die Sirene zu diesem Zeitpunkt versucht hat, ein Temperaturupdate zu senden, kann ich nicht nachvollziehen.
Andreas (Harrenberg) hat in einem anderen Beitrag diese Meldung erklärt (secStart wenn Security-Kommunikation beginnt, danach sollte ein secEnd kommen - wenn secEnd nicht kommt = diese Fehlermeldung).
Ein Betrieb der Sirene ohne Security habe ich bisher nicht versucht.
Weil ich keine Lust habe, ständig auf die Leiter zu steigen, versuche ich jetzt eher unlogische Aktionen:
jede Nacht läuft jetzt ein "set configSwitchMode FlashSirenDefault"
Hoffnung: durch eine Konfigänderung werden alle Register/Queues auf default gesetzt/zurückgesetzt
Ich berichte, wenn der Fehler wieder auftritt.
Gruß
René
Hi
Zitat von: refi am 10 Dezember 2016, 14:58:10
ich habe nochmal die Logs nach allen "Aufghängern" seit April 2016 durchforstet. Auffällig ist, dass die letzte Meldung vor einem Ausfall folgende ist:
secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
Direkt danach kam ein NO_ACK.
Zu diesen Zeitpunkten gab es keine Kommunikation zur Sirene, welche durch Aktionen von mir initiiert wurden. Ob die Sirene zu diesem Zeitpunkt versucht hat ein Temperaturupdate zu senden, kann ich nicht nachvollziehen.
Die Meldung sagt im Grunde das für mehr als 6 sekunden auf eine Antwort auf eine secure-Nachricht gewartet wurde ohne das eine gekommen wäre... Das NO_ACK im Anschluss bestätigt ja auch das es dort Kommunikationsproleme gibt.
Falls Dein Log für das Gerät mit verbose 5 läuft könntest Du mal einen Abschnitt daraus posten, dann schaue ich rein. Wenn Du kein "at" oder notify auf das WakeUp hast, dann wird die Sirene wohl versucht haben was zu schicken. Dazu fragt die Sirene nach einer NONCE und das Verschicken (oder das versuchte senden) dieser Nonce startet dann über secStart den Timer der dann hier nach 6 sekunden aufgibt.
Hier können verschiedene Ursachen möglich sein:
- das Gerät antwortet einfach nicht
- der Befehl wurde gar nicht verschickt weil z.B. der Dongle hängt
- ...
Gruß,
Andreas.
Zitat von: A.Harrenberg am 10 Dezember 2016, 16:01:55
Falls Dein Log für das Gerät mit verbose 5 läuft könntest Du mal einen Abschnitt daraus posten
verbose 5 läuft erst seit meiner letzten "Leiterbesteigung" - ich melde mich, wenn wieder ein Aufhänger kommt
at oder notify lief nicht zu den Ausfallzeiten nur doif auf reading transmit: NO_ACK
Gruß
René
Hallo Leute,
ich habe diese Sirene am 26.11.2016 erworben und habe sie seit ca einem Monat montiert.
Gestern morgen hatte ich das gleiche Problem wie hier beschrieben.
Keine Reaktion
Keine Temperaturupdates
LEDs glimmen
Keine Reaktion auf Tamper Sensor.
Allerding betreibe ich kein fhem sondern benutze Indigo auf eine Mac Server.
Da das Fehlerbild exakt identisch ist, wollte ich Euch nur wissen lassen, dass es wohl kein fhem Problem ist.
Allerdings seid Ihr die Einzigen, denen ich zutraue die Ursache zu finden.
Meine Sirene hat übrigens Firmware 1.03. Gibt es Erkenntnisse, dass 1.04 an dem Fehlerbild irgendwas verbessert und hat jemand dieses Update schon gemacht und wie?
Ich denke eingentlich, das Popp den Fehler beseitigen sollte, glaube aber nicht daran, dass man es dort schafft.
Euch allen ein Frohes neues Jahr.
Umtauscher
ja, laut Martin Sutton, Popp Support, passiert das, wenn der Z-Wave Chip in der Sirene durch Sonneneinstrahlung auf über 80°C aufgeheizt wird!
Ich schließe daraus, dass Du nicht in Europa sondern (viel) weiter südlicher daheim bist, da solche Temperaturen hier Ende Dezember / Anfang Jänner wohl eher nicht vorkommen! ;)
Wünsche ebenfalls ein gutes neues Jahr!!!
....nicht zu vergessen: Solargerät nicht in die Sonne hängen, sondern nur wohltemperierter Halbschatten – zur Not mehrfach täglich mit Sonnenwanderung umhängen. Mehrere Halterungen gibt es als Sonderausstattung (vermute ich) ;) ...
Seitdem ich täglich ein "set configSwitchMode FlashSirenDefault" mache, habe ich (seit 10.12.16) keine Ausfälle. Die Hoffnung stirbt zuletzt...
Gruß
René
Hallo Jungs, erstam danke für Eure erhellenden Antworten. ;-)
Ich finde die "Ursachenanalyse" bzw. "Lösungsvorschläge" von Popp auch lächerlich.
Natürlich ist das Gerät bei mir erst nach dem Ablauf der Rückgabefrist das erste Mal ausgestiegen. (Bei ca -5 °C)
Eine Reparatur scheidet ja bei dem Fehlerbild aus, deshalb die vorsichtige Frage, ob die 1.04 irgend etwas diesbezüglich bringt.
Hallo!
scooty scheint hier bisher der einzige zu sein, der ein FW Update durchgeführt hat (siehe Post #73).
Vielleicht kann er uns berichten?
Mindestens drei andere User wären dankbar!
LG
Rainer
Na, dann 'mal schauen, ob ich etwas zur "Entspannung" beitragen kann.
;)
Seit 2 Wochen ist die Sirene nun mit der 1.04 FW wieder im Outdoor-Einsatz und ist bisher (noch?) nicht wieder ausgestiegen.
Minusgraden von -5°C hat sie bisher standgehalten, befestigt ist sie an der Ostseite des Hauses (also derzeit keine direkte Sonneneinstrahlung).
Habe die Sirene allerdings erst einmal so konfiguriert, dass sie mir keine Temperaturmeldungen sendet (warum? Ich will sie einfach "in Ruhe lassen" und habe genügend andere Sendsoren für Temperaturwerte).
Täglich (besser gesagt "nächtlich") wird der Batteriestand einmal abgefragt, nur einmal ging sie bisher in den Status "transmit NotOK", hat sich aber nach einem erneuten manuellen Versuch am Tage wieder berappelt und brav den Batteriestand gemeldet.
Bin also vorsichtig optimistisch,
Andreas
Danke, dann muss ich es jetzt nur noch schaffen, die Firmware in das Ding zu bekommen....
... und das scheint nicht zu funktionieren.
Ich habe die Übertragung mit z-way vorgenommen.
Nach ca. 5 minütigen Datenverkehr pasuiert die Sirene kurz und löst dann Alarm aus - vermutlich Reset und merk dann, dass der Sabotagekontakt geöffnet ist.
Die Firmwareversion wird danach auch nach exclude und include immer noch als 1.03 angezeigt.
Gibt's da einen Trick, ist das normal oder bin ich zu blöd?
Ich habe übrigens beide 1.4 Dateien ausprobiert.
Zitat von: umtauscher am 03 Januar 2017, 17:10:11
Die Firmwareversion wird danach auch nach exclude und include immer noch als 1.03 angezeigt.
Auch schon einen Reset auf Werkseinstellung nach dem flashen probiert?
War glaube ich auch noch ein Hinweise des Popp Supports.
ZitatHalten Sie die Z-Wave Taste 10 Sekunden lang gedrückt. Nach 5 Sekunden beginnt die LED zu blinken. Nach 10 Sekunden bestätigt ein kurzes Piepsen das die Sirene wieder im Auslieferungszustand ist.
Andreas
Hallo Andreas,
danke für die Antwort. Die Info mit dem Werksreset ist in der Dokumentation auch nicht erwähnt.
Habe ich jetzt versucht - aber auch danach wird die Firmware mit 1.03 angezeigt.
Mann, was ist das alles für ein Frickel.
Wilhelm
Hallo Adreas,
nur der Vollständigkeit halber hier noch ein vorläufiger Schlussbericht:
Nachdem der Hersteller nach dem mißglückten Update die Sirene als defekt bezeichnet hat, habe ich Sie durch den Händler ausgetauscht bekommen.
Auch diese Sirene hatte die Firmware 1.3 - auch hier funktionierte das Update auf 1.4 mit beiden Firmwaredateien nicht.
Daraufhin wurde mir eine 3. Firmwareversion zugeschickt - ebernfalls 1.4 aber diesmal wohl für die Firmware 1.3
Damit hat das Update jetzt funktioniert - unglaublich.
Bleibt festzuhalten, dass es für jede Ausgangsversion ein anderes Update auf 1.4 gibt.
Wie ich schon sagt: Was für ein Frickel.
Jetzt bleibt nur zu hoffen, das das Gerät jetzt endlich stabil läuft.
Danke nochmal für Deine/Eure Hilfe.
Wilhelm
Hallo Wilhelm!
Das heißt mit Z-Way und dem richtigem FW-File (1.3 auf 1.4) hat das FW-Update jetzt geklappt?
Würdest Du das FW-File bitte posten?
Sind in der letzten FW jetzt die Bugs die ich im Post #53 (https://forum.fhem.de/index.php/topic,42736.msg459895.html#msg459895 (https://forum.fhem.de/index.php/topic,42736.msg459895.html#msg459895)) erwähnt habe gefixt?
Falls ja, werde ich mir eine Z-Way Lizenz zulegen (müssen) und auch das Update einspielen. Ich bin noch auf 1.1
Grüße Rainer
Hallo Rainer,
das Update liegt seit heute auf der offiziellen Firmware Seite.
Ob es ein Update von 1.1 auf 1.4 gibt, weiß ich nicht.
Zu den Fehlern kann ich noch nicht viel sagen - die regelmäßige Temperaturmeldung kommt jedenfalls nicht, wenn man den entsprechenden Parameter auf 1 stellt - also alle 4 Minuten.
Ich werde berichten.
Wilhelm
Zitat von: umtauscher am 12 Januar 2017, 19:00:44
...
das Update liegt seit heute auf der offiziellen Firmware Seite.
Ob es ein Update von 1.1 auf 1.4 gibt, weiß ich nicht.
...
Hier http://ota.zwave.eu/ (http://ota.zwave.eu/) gibt es 1.3 -> 1.4 und 1.1 -> 1.4
Da steht auch, dass drei (Parameter 6, minus Temperatur & Batteriemeldungen) meiner fünf Kritikpunkte gefixt sein sollen.
Danke für die Rückmeldung!
Wünsche einen schönen Abend
Rainer
So, ein paar Bemerkungen habe ich jetzt:
nachdem die neue Firmware nun seit gestern läuft, muss ich feststellen, das das Gerät entgegen der Dokumentation weder Batterie noch Temperaturmeldungen versendet.
Ich habe inzwischen Parameter 3 (Temperaturschwellwert) auf 1 sowie Parameter 4 (Regelmäßiges Senden eines Temperaturreports) auf 1 gesetzt. Es sollte also alle 15 Minuten eine Meldung geben. Trotzdem erhalte ich nur Meldungen, wenn sich die Temperatur um mehr als 1 Grad ändert.
Bleibt die Temperatur Konstant, gibt es keine Meldungen.
Für Batteriemeldungen gilt das Gleiche.
Schaltete man die Sirene am internen Schalter aus und wieder ein, wird eine Medlung generiert. Diese zeigt aber nur 0% Ladezustand an.
Ich habe den Eindruck, das bei diesem Teil immer noch nichts funktioniert wie es soll.
Ich habe inzwischen auch eine Art Watchdog programmiert, der bei eingehenden Meldungen einen Zähler zurücksetzt. Dieser Zähler läuft jetzt testweise nach 5 Stunden ab.
Und immer noch bekomme ich dadurch Meldungen, dass die Sirene den Betrieb eingestellt hat, weil für so lange Zeit keine Reaktion von der Sirene erfolgt.
Ich habe dem Support meine Erkenntnisse ebenfalls mitgeteilt.
Kann man so ein unzuverlässiges Teil als Teil einer Alarmanlage brauchen?
Ich meine nein....
Für alle, die's noch interessiert.
Die Sirene verhält sich bezogen auf die Temperturmessung und Parameter fehlerhaft bzw. völlig anders als dokumentiert.
1. Setzt man Parameter "3 Temperturschwellwert" auf 0 sendet die Sirene alle 4 Minuten einen Temperturbericht. Immer alle 4 Minuten. Wird der Parameter anders gesetzt sendet die Sirene nur bei Temeperaturänderungen, der Temperaturschwellwert wird aber auf jeden Fall nicht eingehalten
2. "Parameter 4 Regelmäßiges Senden eines Temperturberichts" hat absolut keine Wirkung auf den Temperaturbericht.
Will man also sehen, on die Sirene noch "lebt" ist die einzige Möglichkeit regelmäßige Medlungen zu bekommen die Methode 1 mit Schwellwert 0
Batteriemeldungen werden nie freiwillig verschickt und müssen explizit abgefragt werden.
Ich hoffe das hilft irgend jemandem.
Wilhelm
Hallo Wilhelm!
Vielen Dank für Deinen Bericht.
Mich interessiert das durchaus!
Hast Du für Battery je einen anderen Wert als "100 %" (oder "low") bekommen? (seit FW-Update auf 1.4)
LG
Rainer
Hallo Rainer,
nach dem Reset meldet die Sirene erstmal 0%.
Freiwillig sendet Sie die Batterieinformation anscheinend nie.
Wenn man das Batterie device manuell abfragt, kommt ein plausibler Wert zurück. Bei mir momentan nach 24 std mäßiger Sonne 85%.
Des Weiteren habe ich gerade eine Nachricht von z-wave Erurope GmbH erhalten. (Der support von Popp)
ZitatUm einen Temperaturreport nach Zeit zu erhalten, sind ein Paar Einstellungen nötig. Bitte überprüfen Sie, ob Sie all diese Einstellungen auch gemacht haben.
- Sie müssen den Parameter 3 auf den Wert "0" setzen (kein Automatischer Report nach Temperaturänderung)
- dann den Parameter 4 auf den gewünschten Wert . Beachten Sie die Multiplikation (Wert x 4 Minuten). Das bedeutet bei Wert 3 wären es 12 Minuten.
- Beachten Sie das ein NIF (NodeInformationFrame) nur gesendet wird wenn die Sirene auf der Montageplatte installiert ist.
Desweiteren ist es nicht zu empfehlen sich einen Wert in kurzen Zeitabständen zusenden zu lassen. Dies kann die Batterielebensdauer reduzieren.
Dazu ist zu sagen, dass ich die Sache mit Parameter 3 ja schon herausgefunden hatte und Parameter 4 definitiv keine Wirkung hat.
Ich werde dort jetzt antworten und halte Euch auf dem Laufenden.
Wilhelm
Neuer Zwischenstand:
Die Sirene hat sich gestern nachmittag wieder aufgehängt.
Nach 5 Stunden habe ich sie geöffnet und einen PowerOff PowerOn Reset duchgeführt. Der Akku hatte zu diesem Zeitpunkt eine Spannung von 8,4 V, die Außentemperatur betrug bei der letzten Meldung 3°C.
Ich habe Sie danach mit gleicher AkkuLadung wieder angebracht und sie hat ohne weitere Aussetzer die ganze Nacht Temperaturreports geschickt. Minmaltemperatur war -8,4°C
LG
Wilhelm
Hallo,
seit weiteren 2 Wochen keine Ausfälle der Sirene.
Wie beschrieben alle 24h ein "set configSwitchMode FlashSirenDefault".
Alle 24h ein "get battery". Das kann ich mir eigentlich sparen, da scheinbar bis Firmware 1.3 nur 0% oder 100% gemeldet werden.
Konfig:
configSendUnsolicitedTemperatureReport: 10
configSendUnsolicitedTemperatureReport4: 15
configTemperatureAdjustments: 0
Gruß
René
Na da hast Du ja Glück. Ich drücke Dir die Daumen, dass es so bleibt.
Ich glaube aber nicht, dass es an den Abfragen liegt.
Gruß
Wilhelm
Hallo Wilhelm,
probiere es doch mal aus, wenn die Firmware 1.4 scheinbar auch keine Besserung bringt und so schnell ein neuer Ausfall aufgetreten ist.
Wenn ich mir meine Logs anschaue, habe ich noch nie einen "so langen" Zeitraum ohne Ausfall gehabt.
Klar, der Zeitraum reicht für eine Erfolgsmeldung noch nicht aus, da ich auch keinen Überblick über Ausfälle zu dieser Jahreszeit habe (wenn Temperatur etc. überhaupt eine Rolle spielt; letzten Winter hatte ich die Sirene noch nicht).
Gruß
René
Hallo René,
danke für Deine Antwort.
Ich habe inzwischen vom Support andere Hinweise bekommen.
Ich soll die Solarzelle abklemmen und die Sirene erstmal so betreiben. Wenn der Akku leer ist, könne ich die Solarzelle wieder anklemmen. Außerdem wäre eine neue Hardwareversion in Arbeit.
Das lässt darauf schließen, dass das Problem durch einen Fehler in der Ladeschaltung verursacht wird.
Gestern ist die Sirene (mit aktiver Ladeschaltung) zu dem Zeitpunkt ausgefallen, als die Sonne nicht mehr direkt auf die Solarzelle schien - vielleicht Zufall.
Ich habe das Solarpanel jetzt erstmal abgeklemmt und werde berichten.
LG
Wilhelm
Hallo,
der erste sehr sonnenreiche Tag in diesem Jahr und ... die Sirene ist nicht mehr ansprechbar. Bis Mittag kamen noch Temperaturupdates.
In den Logs sieht es bis dahin gut aus – danach ist Sendepause.
Ich bin am Boden zerstört - werde mir einen Wachhund kaufen. ;)
Gruß
René
Hallo René,
ich hatte das gleiche Problem.
Meine Sirene läuft jetzt seitdem ohne Probleme. (Solarzelle abgeklemmt)
Es wird eine neue Harware Revsion geben.
Ich hoffe, das hilft Dir erstmal.
Du hast doch bestimmt noch Gewährleistung, oder?
Zitat von: umtauscher am 29 Januar 2017, 17:54:20
Du hast doch bestimmt noch Gewährleistung, oder?
ja, habe die Sirene seit 04/2016 und 12/2016 habe ich den Fehler das 1. mal dem Support gemeldet
Ich habe wochenlang mit denen kommuniziert, bis ich diese Rückmeldung bekommen habe. Einmal wurde das Gerät vom Händler bereits ausgetauscht.
Ich werde auch nichts mehr herumbasteln – scheint wirklich ein Konstruktionsfehler zu sein. Aufgrund Neigung der Solarzelle, Sonnenstand jetzt im Winter und keine Blätter an Nachbars Bäumen, bin ich der Meinung, dass heute sogar mehr Sonne die Solarzelle "getroffen" hat als im Hochsommer.
Hallo,
neueste Antwort/Bestätigung vom Support:
Akku wird durch Solarzelle überladen und Elektronik schaltet ab. Eine neue Hardware-Version ist in Arbeit. Abhilfe bis dahin: Solarzelle abklemmen.
Gruß
René
Nach dem Verstummen der Temperaturmeldungen und ein sanftes Leuchten der Alarm-LEDs habe ich meine zurückgesetzt und nun vom freundlichen zwave.eu-Support repariert zurückbekommen. Die Firmware ist von 1.3 auf 1.4 aktualisiert. In den Readings ist keine neue Hardware vermerkt. Ob etwas ausgetauscht wurde kann ich nicht erkennen. Bin gespannt ob die Sirene nun ausfallfrei läuft.
vorher:
version: Lib 3 Prot 4.05 App 1.3 HW 1 FWCounter 0
nachher:
version: Lib 3 Prot 4.05 App 1.4 HW 1 FWCounter 0
Ein sonniges WE
Hallo,
habe heute als Vorabtausch eine nagelneue Sirene bekommen.
Aufdruck auf der Platine: Rev. 1.0.0.9 (C)2017
Layout ist bis auf einen Widerstand+SMD-Diode identisch. Firmware auch 1.4
Gruß
René
Hallo,
habe testweise eine stündliche Batterieabfrage eingerichtet.
Trotz sehr sonnenreicher Tage bisher keine Ladung über 86%.
Die überarbeitete Platine funktioniert.
Gruß
René
Hallo René!
Funktioniert die Sirene noch immer ohne Probleme, auch im direkten Sonnenlicht?
Du hast nicht zufällig ein Foto der neuen Platine gemacht, dass du weitergeben würdest?
Falls nein, würde ich dich bitten eines zu machen, wenn du das nächste mal das Gerät herunter nimmst, aber dazu gibt es ja hoffentlich keinen Grund mehr!
LG
Rainer
Hallo Reiner,
funktioniert immer noch tadellos. Allerdings habe ich auch schon mal 95% Ladung gesehen. Es kam auch schon mal 30%. Bei sofortiger erneuten Abfrage waren es dann aber wieder über 90%. Unter 80% war ich bisher nie.
Ich habe ein Foto der Platine. Keine Ahnung, ob ich dieses hier anhängen darf. (vlt. besser Email-Adresse per PM)
Gruß René
Hallo René!
Danke für dein Feedback!
Solange du selber das Foto gemacht hast, kann eigentlich keiner etwas dagegen haben es hier anzuhängen. Aber wenn es die lieber ist geb ich dir meine Email-Adresse.
LG
Rainer
Hallo,
Ich kremple disen Tread noch mal raus, es geht um die blink Funktion (z.B. set Aussensirene blink 1 0.5) so klappt das normalerweise, jedoch nicht immer (in dem fall wird aus der halben Sekunde ca. 1.5 Sekunden.
Woran könnte das liegen ?
Danke
Zitat von: chopsor am 03 Januar 2019, 23:18:01
Hallo,
Ich kremple disen Tread noch mal raus, es geht um die blink Funktion (z.B. set Aussensirene blink 1 0.5) so klappt das normalerweise, jedoch nicht immer (in dem fall wird aus der halben Sekunde ca. 1.5 Sekunden.
Woran könnte das liegen ?
Die Sirene ist ein FliRS-Gerät mit afaik 1000ms - Beam zum "Aufwecken". Daher sind Zeiten vom Absetzen des Befehls durch den Controller bis zum ACK durch das Gerät von mehr als 1 Sekunde normal (siehe Reading timeToAck).
Gruß, Christian
Oh daran könnte es dann wohl liegen.. , habe seit deinem Post sporadisch diesen wert nachgesehen der schwankt in der Tat von 0.034 -1.229.
Hallo,
Als ich sie vor einem Jahr gekauft habe, habe ich die Sirene vor der endgültigen Montage an der Fassade getestet und hatte genau die gleichen Probleme, das sie ziemlich schnell leer wurde.
Der Support hat gefragt, ob ich es mit oder ohne Halteplatte getestet habe. Genau das war auch mein Problem. Ich habe es immer ohne Halteplatte getestet, dabei ist die Sirene ständig eingeschaltet und verbraucht auch sehr viel Strom.
Seitdem hängt sie bereits seit einem Jahr auf der Hausfassade und funktioniert ohne Probleme.
Es gab keine Kontaktprobleme oder leere Akkus.
Vielleicht konnte ich mit meiner Erfahrung weiterhelfen.
lg Martin
Weiss zufällig jemand warum mir das Gerät seit der erneuten Inklusion (diesmal ohne Security wegen der Latenz) keine Temperatur Daten mehr angibt (ist jetzt ca 1 Monat her, dass ich es neu exkludiert und neu inkludiert habe)?
Danke.
Hallo chopsor,
ohne Halteplatte kommen, wenn ich mich richtig erinnere, auch keine Temperatur-Updates.
Hängt das Teil wieder an der Wand oder testest Du noch?
Habe die Sirene seit März 2017 nicht mehr in der Hand gehabt, da sie nun problemlos läuft.
Gruß
René
Hallo,
Die hängt wieder in 8 Meter höhe ( mir ist aber aufgefallen, dass ich die Temperatur manuell über get <devicename> smStatus abfragen kann (hatte einen Defekt des Temperatur Sensors befürchtet.
configSendUnsolicitedTemperatureReport steht auf 10
configSendUnsolicitedTemperatureReport4 steht bei mir auf 15 (default) und sollte mir folglich alle Stunde einen Report geben wenn ein Temperaturunterschied von 1°C festgestellt wird.
(wollte ein stündliches abfragen seitens Fhem (at) eigentlich vermeiden, ich sehe aber im Moment keinen richtige Lösung)
... der ZWDongle steht aber in der assocGroup_1 ??
Gruß
René
Gegenfrage: wie kann ich das feststellen ?
Sehe beim Controller kein reading/internal welcher so heisst.
(Von anderen geräten z.B. Fibaro Motion sensor bekomme ich die Lux und Temp Daten automatisch.
Danke.
Du machst ein "get associationAll" und danach ein "neu laden" der Seite. Dann sollte der Dongle in der Gruppe1 auftauchen. Wenn nicht, dann "set associationAdd 1 1".
Gruß
René
bei der get liste habe ich kein associationAll lediglich:
(siehe Bild)
Zitat von: chopsor am 09 April 2019, 12:00:14
bei der get liste habe ich kein associationAll lediglich:
(siehe Bild)
Bitte beim ZWave-Device und nicht beim ZWDongle-Device nachschauen.
Gruß, Christian
Okay ... ::)
Hatte
ZitatDu machst ein "get associationAll" und danach ein "neu laden" der Seite. Dann sollte der Dongle in der Gruppe1 auftauchen. Wenn nicht, dann "set associationAdd 1 1".
falsch interpretiert ::), assocGroups stand bereits auf 1, jedoch scheint es jetzt wieder zu funktionieren nachdem ich normal
set associationAdd 1 1 abgesetzt habe... ???
Danke !