Seit neuestem bekomme ich reichlich Logeintraege dieser Art :
2019.03.29 14:14:37 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001338032601FF25b696
2019.03.29 14:14:41 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001338032601FF25b696
2019.03.29 14:14:41 2: ZWave: No ACK from LichtFlur after 5s for sentset:1338032601FF25b6
2019.03.29 14:14:43 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001338032601FF25b696
2019.03.29 14:16:37 3: ZWave set LichtFlur on
2019.03.29 14:21:37 3: ZWave set LichtFlur off
2019.03.29 14:22:39 3: ZWave set LichtFlur on
2019.03.29 14:24:40 3: ZWave set LichtFlur on
2019.03.29 14:29:40 3: ZWave set LichtFlur off
2019.03.29 14:30:43 3: ZWave set LichtFlur on
2019.03.29 14:32:45 3: ZWave set LichtFlur on
2019.03.29 14:37:45 3: ZWave set LichtFlur off
2019.03.29 14:38:47 3: ZWave set LichtFlur on
2019.03.29 14:40:48 3: ZWave set LichtFlur on
2019.03.29 14:45:48 3: ZWave set LichtFlur off
2019.03.29 14:46:51 3: ZWave set LichtFlur on
2019.03.29 14:48:53 3: ZWave set LichtFlur on
2019.03.29 14:48:54 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001338032601FF25c4e4
2019.03.29 14:48:56 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001338032601FF25c4e4
2019.03.29 14:53:53 3: ZWave set LichtFlur off
2019.03.29 14:53:54 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a0013380326010025c51a
2019.03.29 14:53:59 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a0013380326010025c51a
2019.03.29 14:53:59 2: ZWave: No ACK from LichtFlur after 5s for sentset:13380326010025c5
2019.03.29 14:54:56 3: ZWave set LichtFlur on
2019.03.29 14:56:56 3: ZWave set LichtFlur on
2019.03.29 14:59:53 3: ZWave set LichtFlur on
2019.03.29 14:59:54 3: ZWave set LichtFlur on
2019.03.29 14:59:55 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001338032601FF25c8e8
2019.03.29 15:00:39 3: ZWave set LichtFlur on
2019.03.29 15:00:39 3: ZWave set LichtFlur on
2019.03.29 15:00:41 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001338032601FF25caea
2019.03.29 15:00:57 3: ZWave set LichtFlur on
2019.03.29 15:00:57 3: ZWave set LichtFlur on
2019.03.29 15:00:58 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001338032601FF25ccec
2019.03.29 15:01:01 3: ZWave set WolfgangWarn on
2019.03.29 15:01:01 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001345032601FF25ce93
2019.03.29 15:01:04 3: ZWave set WolfgangWarn off
2019.03.29 15:01:06 2: ZWave: No ACK from WolfgangWarn after 5s for sentset:1345032601FF25ce
2019.03.29 15:01:11 2: ZWave: No ACK from WolfgangWarn after 5s for sentset:13450326010025cf
2019.03.29 15:01:48 3: ZWave set LichtFlur on
2019.03.29 15:01:49 3: ZWave set LichtFlur on
2019.03.29 15:01:49 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001338032601FF25d0f0
2019.03.29 15:01:51 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001338032601FF25d0f0
2019.03.29 15:01:51 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001338032601FF25d0f0
2019.03.29 15:03:44 3: ZWave set LichtFlur on
2019.03.29 15:03:44 3: ZWave set LichtFlur on
2019.03.29 15:03:46 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001338032601FF25d2f2
2019.03.29 15:04:28 3: ZWave set LichtFlur on
2019.03.29 15:04:28 3: ZWave set LichtFlur on
2019.03.29 15:04:29 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001338032601FF25d4f4
2019.03.29 15:09:28 3: ZWave set LichtFlur off
2019.03.29 15:10:24 3: ZWave set LichtFlur on
2019.03.29 15:10:25 3: ZWave set LichtFlur on
2019.03.29 15:10:26 3: ZWave set LichtFlur on
2019.03.29 15:10:26 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001338032601FF25d7f7
2019.03.29 15:11:08 3: ZWave set LichtFlur on
2019.03.29 15:11:08 3: ZWave set LichtFlur on
2019.03.29 15:11:10 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001338032601FF25dafa
2019.03.29 15:13:10 3: ZWave set LichtFlur on
2019.03.29 15:14:50 3: ZWave set LichtFlur on
2019.03.29 15:14:50 3: ZWave set LichtFlur on
2019.03.29 15:14:50 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001338032601FF25ddfd
2019.03.29 15:15:31 3: ZWave set LichtFlur on
2019.03.29 15:15:31 3: ZWave set LichtFlur on
2019.03.29 15:15:32 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001338032601FF25dfff
2019.03.29 15:20:31 3: ZWave set LichtFlur off
2019.03.29 15:21:34 3: ZWave set LichtFlur on
2019.03.29 15:21:34 3: ZWave set LichtFlur on
2019.03.29 15:21:41 3: ZWave set LichtFlur on
2019.03.29 15:21:41 3: ZWave set LichtFlur on
2019.03.29 15:21:41 3: ZWave set LichtFlur on
2019.03.29 15:21:41 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001338032601FF25e4c4
2019.03.29 15:22:26 3: ZWave set LichtFlur on
Und auch solche :
ZWDongle_ProcessSendStack: no ACK, resending message 010a001338032601FF253e1e
2019.03.29 17:27:53 2: ERROR: cannot SEND_DATA to LichtFlur: transmit queue overflow
2019.03.29 17:27:53 2: ZWave: No ACK from WolfgangWarn after 5s for set:1345032601FF2540
2019.03.29 17:27:55 2: ERROR: cannot SEND_DATA to WolfgangWarn: transmit queue overflow
2019.03.29 17:27:56 2: ZWave: No ACK from LichtFlur after 5s for set:1338032601FF253e
2019.03.29 17:27:58 2: ERROR: cannot SEND_DATA to LichtFlur: transmit queue overflow
2019.03.29 17:27:58 2: ZWave: No ACK from WolfgangWarn after 5s for set:1345032601FF2540
2019.03.29 17:28:00 2: ERROR: cannot SEND_DATA to WolfgangWarn: transmit queue overflow
2019.03.29 17:28:01 2: ZWave: No ACK from LichtFlur after 5s for set:1338032601FF253e
2019.03.29 17:28:03 2: ERROR: cannot SEND_DATA to LichtFlur: transmit queue overflow
2019.03.29 17:28:03 2: ZWave: No ACK from WolfgangWarn after 5s for set:1345032601FF2540
2019.03.29 17:28:05 2: ERROR: cannot SEND_DATA to WolfgangWarn: transmit queue overflow
2019.03.29 17:28:06 2: ZWave: No ACK from LichtFlur after 5s for set:1338032601FF253e
2019.03.29 17:28:08 2: ZWave: No ACK from WolfgangWarn after 5s for set:1345032601FF2540
2019.03.29 17:28:10 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001338032601FF253e1e
2019.03.29 17:28:11 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001338032601FF253e1e
2019.03.29 17:28:11 2: ZWave: No ACK from LichtFlur after 5s for sentset:1338032601FF253e
2019.03.29 17:28:11 2: ERROR: cannot SEND_DATA to LichtFlur: transmit queue overflow
2019.03.29 17:28:14 2: ZWave: No ACK from WolfgangWarn after 5s for sentset:1345032601FF2540
2019.03.29 17:28:15 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001345032601FF25401d
2019.03.29 17:28:16 2: ERROR: cannot SEND_DATA to WolfgangWarn: transmit queue overflow
2019.03.29 17:28:16 2: ZWave: No ACK from LichtFlur after 5s for set:1338032601FF253f
2019.03.29 17:28:19 2: ERROR: cannot SEND_DATA to LichtFlur: transmit queue overflow
2019.03.29 17:28:19 2: ERROR: cannot SEND_DATA to LichtFlur: transmit queue overflow
2019.03.29 17:28:19 2: ZWave: No ACK from WolfgangWarn after 5s for set:1345032601002541
2019.03.29 17:28:21 2: ERROR: cannot SEND_DATA to WolfgangWarn: transmit queue overflow
2019.03.29 17:28:21 2: ZWave: No ACK from LichtFlur after 5s for set:1338032601FF253f
2019.03.29 17:28:24 2: ERROR: cannot SEND_DATA to LichtFlur: transmit queue overflow
2019.03.29 17:28:24 2: ZWave: No ACK from WolfgangWarn after 5s for set:1345032601002541
Es funktioniert zwar alles, aber das kann doch nicht richtig sein ?
Zitat2019.03.29 15:03:46 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001338032601FF25d2f2
FHEM schickt dem Controller per USB was, kriegt aber keine Bestaetigung, dass diese Daten beim Controller angekommen sind.
Zitat019.03.29 17:27:55 2: ERROR: cannot SEND_DATA to WolfgangWarn: transmit queue overflow
Der ZWave-Controller meint, er kann gerade die Daten von FHEM nicht entgegennehmen, da seine eigene Puffer schon voll sind.
Zitat2019.03.29 17:27:56 2: ZWave: No ACK from LichtFlur after 5s for set:1338032601FF253e
Das FHEM-ZWave Modul hat nach 5s keine Empfangsbestaetigung vom Endgeraet bekommen.
Ich meine der Controller hat ein Problem, evtl. hilft Firmware-Update oder stromlos machen..
Danke
Ich wuerde gern ein komplettes
Reset machen.
Macht da ein Backup + Restore Sinn, oder setze ich
besser alles neu auf ?
Ich wuerde erst stromlos machen, dann mit ZWDongle-Backup/reset/Restore versuchen, und wenn das nicht hilft, einen neuen Controller kaufen :)
Hallo howi42,
habe das gleiche Leiden mein Log wird mehr oder weniger extrem
wie bei Dir vollgeschrieben.
Was für ein Dongle hast Du wenn ich mal fragen darf, bei mir ist ein Cyrus SmartHome USB Dongle Z-Wave Plus im Einsatz.
Hatte gedacht(vermutet) von der größeren Bauform her, ist eventuell mehr Platz für Antenne(Empfang) und weniger thermische Belastung.
Hatte mal anderes USB Kabel versucht und die Lage etwas verändert hat auch nichts gebracht.
Im Haus ohne Stahlbetondecken in fast jeden Zimmer ein oder zwei 230 Volt ZWave Geräte im Einsatz finde ist eher schlimmer geworden.
Kurios gestern früh Fibaro Zwischenstecker reagiert wiedermal nach ca, 6-7 Tagen nicht mehr, einige male händisch an und aus gemacht hat nichts gebracht(Funkbefehle)
sollte den Weg zum Wertstoffhof gehen, abends hat er wieder reagiert auf Funkbefehle. ??
Ein reopen an den Dongle ändert auch nichts weiter.
Firmwareupdate oder Möglichkeit hierzu habe ich leider zu diesem Teil im Netz nichts gefunden.
Hat jemand eventuell eine Empfehlung für einen gescheiten ZWave Dongle oder was ich an den Einstellungen versaubeutelt haben könnte?
@rudolfkönig Danke für die Erklärungen!
zum stromlos machen des Controllers Server komplett neu starten USB Hub vom Strom nehmen, im laufenden Betrieb abziehen kann ja wohl nicht das Wahre sein oder ?
Dieses Spiel dauerhaft durchziehen hmmm.....
Gibt es Stolpersteine hinsichtlich USB 3.0. ?
Bin als Laie erst mal am Ende. Anbei ein List vom Teil....
Internals:
CallbackNr 3
Clients :ZWave:
DEF /dev/serial/by-id/usb-0658_0200-if00@115200
DeviceName /dev/serial/by-id/usb-0658_0200-if00@115200
FD 21
FUUID 5c51583d-f33f-cca1-71e3-0f8096f6242fcf87
MaxSendRetries 3
NAME ZWDongle_1
NR 289
PARTIAL
RAWMSG 000400091e9881d319caf051c120e2e4926f054ee905ea1357ab3857dc2241bc652229
ReadTime 1553938909.58213
STATE Initialized
SendRetries 0
SendTime 1553938909.52384
TYPE ZWDongle
WaitForAck 0
ZWDongle_1_MSGCNT 50779
ZWDongle_1_TIME 2019-03-30 10:41:49
homeId ceb400ca
nodeIdHex 01
nrNAck 0
showSetInState 1
MatchList:
1:ZWave .*
READINGS:
2019-03-29 22:27:17 caps Vers:15 Rev:1 ManufID:0109 ProductType:1001 ProductID:0201 SERIAL_API_GET_INIT_DATA SERIAL_API_APPL_NODE_INFORMATION APPLICATION_COMMAND_HANDLER ZW_GET_CONTROLLER_CAPABILITIES SERIAL_API_SET_TIMEOUTS SERIAL_API_GET_CAPABILITIES SERIAL_API_SOFT_RESET UNKNOWN_09 UNKNOWN_0a ZW_SET_R_F_RECEIVE_MODE ZW_SET_SLEEP_MODE ZW_SEND_NODE_INFORMATION ZW_SEND_DATA ZW_SEND_DATA_MULTI ZW_GET_VERSION ZW_SEND_DATA_ABORT ZW_R_F_POWER_LEVEL_SET ZW_SEND_DATA_META ZW_GET_RANDOM MEMORY_GET_ID MEMORY_GET_BYTE MEMORY_PUT_BYTE MEMORY_GET_BUFFER MEMORY_PUT_BUFFER FLASH_AUTO_PROG_SET ZW_NVR_GET_VALUE NVM_GET_ID NVM_EXT_READ_LONG_BUFFER NVM_EXT_WRITE_LONG_BUFFER NVM_EXT_READ_LONG_BYTE NVM_EXT_WRITE_LONG_BYTE ZW_GET_NODE_PROTOCOL_INFO ZW_SET_DEFAULT ZW_REPLICATION_COMMAND_COMPLETE ZW_REPLICATION_SEND_DATA ZW_ASSIGN_RETURN_ROUTE ZW_DELETE_RETURN_ROUTE ZW_REQUEST_NODE_NEIGHBOR_UPDATE ZW_APPLICATION_UPDATE ZW_ADD_NODE_TO_NETWORK ZW_REMOVE_NODE_FROM_NETWORK ZW_CREATE_NEW_PRIMARY ZW_CONTROLLER_CHANGE ZW_SET_LEARN_MODE ZW_ASSIGN_SUC_RETURN_ROUTE ZW_REQUEST_NETWORK_UPDATE ZW_SET_SUC_NODE_ID ZW_DELETE_SUC_RETURN_ROUTE ZW_GET_SUC_NODE_ID ZW_SEND_SUC_ID ZW_EXPLORE_REQUEST_INCLUSION ZW_REQUEST_NODE_INFO ZW_REMOVE_FAILED_NODE_ID ZW_IS_FAILED_NODE ZW_REPLACE_FAILED_NODE UNKNOWN_66 UNKNOWN_67 GET_ROUTING_TABLE_LINE LOCK_ROUTE_RESPONSE ZW_GET_PRIORITY_ROUTE ZW_SET_PRIORITY_ROUTE UNKNOWN_98 ZW_SET_WUT_TIMEOUT ZW_WATCHDOG_ENABLE ZW_WATCHDOG_DISABLE ZW_WATCHDOG_CHECK ZW_SET_EXT_INT_LEVEL ZW_RF_POWERLEVEL_GET ZW_TYPE_LIBRARY ZW_SEND_TEST_FRAME ZW_GET_PROTOCOL_STATUS WATCHDOG_START WATCHDOG_STOP ZW_SET_ROUTING_MAX UNKNOWN_ee UNKNOWN_ef
2019-03-29 22:27:17 ctrlCaps PRIMARY SUC
2019-03-29 22:27:17 homeId HomeId:ceb400ca CtrlNodeIdHex:01
2019-03-21 20:45:10 isFailedNode_1 no
2018-10-22 17:57:23 isFailedNode_3 no
2018-10-22 17:25:36 isFailedNode_5 no
2018-10-21 19:04:45 isFailedNode_7 no
2019-03-12 08:53:29 isFailedNode_UNKNOWN_18 yes
2019-03-11 21:03:45 isFailedNode_UNKNOWN_3 yes
2019-03-12 08:52:41 neighborList_1 Thermostat_Buero fk_ost_buero Thermostat_Bad Steckd_POPP Thermostat1_UG_WZ MotionSensor_UG_WZ WZ_ZW_STECKDOSE ZWave_SWITCH_BINARY_15 WOH_ZW_THERMOSTAT_OST
2018-10-22 18:43:30 neighborList_5 ZWDongle_1 ZWave_THERMOSTAT_2 ZWave_SWITCH_BINARY_9
2018-12-17 10:25:26 nodeInfo_02 ProtocolVers:SDK4.5x+6.0x sleeping routing maxBaud:40kbps SpecificDev RoutingSlave BeamCap FrequentListen1000ms OptFunc SpeedExt:100kbps RoleType:N/A BasicDevClass:ROUTING_SLAVE GenericDevClass:THERMOSTAT SpecificDevClass:06
2019-03-29 22:06:46 nodeInfo_1 ProtocolVers:SDK4.5x+6.0x listening routing maxBaud:40kbps Controller SpecificDev BeamCap SpeedExt:100kbps RoleType:N/A BasicDevClass:STATIC_CONTROLLER GenericDevClass:STATIC_CONTROLLER SpecificDevClass:01
2019-03-12 19:19:26 nodeInfo_13 ProtocolVers:SDK4.5x+6.0x sleeping routing maxBaud:40kbps SpecificDev RoutingSlave BeamCap OptFunc SpeedExt:100kbps RoleType:N/A BasicDevClass:ROUTING_SLAVE GenericDevClass:SENSOR_NOTIFICATION SpecificDevClass:01
2019-03-12 19:20:20 nodeInfo_19 ProtocolVers:SDK4.5x+6.0x sleeping maxBaud:40kbps Controller SpecificDev BeamCap OptFunc SpeedExt:100kbps RoleType:N/A BasicDevClass:CONTROLLER GenericDevClass:GENERIC_CONTROLLER SpecificDevClass:06
2018-10-22 18:00:55 nodeInfo_3 ProtocolVers:SDK4.5x+6.0x listening routing maxBaud:40kbps SpecificDev RoutingSlave BeamCap OptFunc SpeedExt:100kbps RoleType:N/A BasicDevClass:ROUTING_SLAVE GenericDevClass:SWITCH_BINARY SpecificDevClass:01
2018-10-22 21:09:45 nodeInfo_5 ProtocolVers:SDK4.5x+6.0x sleeping routing maxBaud:40kbps SpecificDev RoutingSlave BeamCap FrequentListen1000ms OptFunc SpeedExt:100kbps RoleType:N/A BasicDevClass:ROUTING_SLAVE GenericDevClass:THERMOSTAT SpecificDevClass:06
2018-10-17 09:40:39 nodeInfo_6 ProtocolVers:SDK4.5x+6.0x sleeping routing maxBaud:40kbps SpecificDev RoutingSlave BeamCap OptFunc SpeedExt:100kbps RoleType:N/A BasicDevClass:ROUTING_SLAVE GenericDevClass:SENSOR_NOTIFICATION SpecificDevClass:01
2018-10-22 18:01:09 nodeInfo_9 ProtocolVers:SDK4.5x+6.0x listening routing maxBaud:40kbps SpecificDev RoutingSlave BeamCap OptFunc SpeedExt:100kbps RoleType:N/A BasicDevClass:ROUTING_SLAVE GenericDevClass:SWITCH_BINARY SpecificDevClass:01
2019-03-21 20:45:27 nodeList ZWDongle_1 Thermostat_Buero fk_ost_buero Thermostat_Bad fk_bad Steckd_POPP fk_ug_wz Thermostat1_UG_WZ Thermostat_OG_WZ MotionSensor_UG_WZ WZ_ZW_STECKDOSE1 ZWave_SWITCH_BINARY_15 WOH_ZW_THERMOSTAT_OST SZ_DECKE_ZW_DIM ZWave_GENERIC_CONTROLLER_19 WZ_ZW_STECKDOSE2 FLUR_ZW_STECKD ZWave_SWITCH_BINARY_22
2019-03-29 22:27:17 random 63ea67a0f2a4912496a2b09da07e7b19a54628c5940f97f954d252934c26386d
2019-03-15 14:26:14 routeFor_19 last at 100kbps
2018-10-22 17:58:46 routeFor_3 last at 40kbps
2018-10-22 17:58:19 routeFor_4 last at 100kbps
2018-10-22 17:58:33 routeFor_5 last at 40kbps
2018-10-17 19:14:32 routeFor_6 last ZWave_SWITCH_BINARY_3 at 100kbps
2019-03-29 22:27:17 state Initialized
2019-03-29 22:27:17 sucNodeId 1
2019-03-29 22:05:50 version Z-Wave 4.05 STATIC_CONTROLLER
SendStack:
Attributes:
DbLogExclude .*
alias ZWaveStick
group USB Gerät
homeId ceb400ca
icon cul_cul
model ZWDongle
neighborListPos 52.5,70
networkKey 12345678123456781234567812345678
room Steuerung->Interfaces,ZWave
Gruß
Hans-Jürgen
Das Teil ist ein UZB1 und hat eigentlich ganz gut seinen Dienst getan.
Ein Update ist mir nicht gelungen, da half auch z-way-server nicht, wobei mir bei der Software sowieso der Glaube an die Softwareentwicklung abhanden kommt.
Backup/Restore muss ich noch testen, sonst wird er ersetzt.
Ich habe noch einen alteren Razberry hier liegen, aner dessen
Reichweite ist so unterirdisch, dass er nur in einem Zimmer brauchbar ist
Da muss wohl ein neuer her ....,moeglicherweise nicht z-way-me.
Was mir auch auffaellt, die Nodelist des Kontrollers enthaelt sehr viele unbekannte Nodes, sicher ein Ergebnis langer Benutzung. Ich sehe aber keine Moeglichkeit, da aufzuraeumen.
Ich bin jetzt von dem UZB1 auf einen Aeotec-Stick umgestiegen.
Mit der Unterstuetzung im Forum hat das auch prima funktioniert :
Backup des alten
Restore auf den neuen.
Uebertragen der alten ID
Alles geht, nur ein paar Beobachtungen :
- die Nodelist des neuen Dongle besteht nur aus UNKNOWN_xx, davon reichlich ...
- scheint aber nicht weiter zu stoeren
- die Anzahl der Logeintraege ist wieder normal; ein gelegentliche 'Resend message' gab es schon immer, besonders beim Schalten mehrerer Lampen ueber eine 'structure'
Hallo howi42,
ZitatIch bin jetzt von dem UZB1 auf einen Aeotec-Stick umgestiegen.
Mit der Unterstuetzung im Forum hat das auch prima funktioniert :
Bin auch auf den Aeotec-Stick umgestiegen.
War leider für mich etwas fummelig wegen USB und serial by-id beide Sticks
hatten die gleiche id und beim an und abstecken des neuen lief er plötzlich unter tty.....?
Hatte ich nicht gleich bemerkt und das Backup einspielen wollte nicht, wollte schon komplett von vorne anfangen
mit ex includieren hatte es erst auf die unterschiedlichen Controler geschoben aber noch rechtzeitig bemerkt und hat
am Ende geklappt.
Lief dann aber auch nicht so richtig rund mit den Logeinträgen habe den
Aeotec vom Strom starken USB HUB abgesteckt und an einen extra USB Port am Server
gesteckt vermutlich? ist die Kombination mit 2 SAT Sticks am HUB nicht so optimal....
Nächste Baustelle, trotz jedes mal neu ex includieren hat mein zweiter Fibaro WallPlug wie der erste zum dritten Mal
nach 6-7 Tagen den Dienst verweigert, faxen Dicke, gehen wohl endgültig zum Wertstoffhof.
Logeinträge sind zwar weniger geworden aber die Thermostate Eurotronic Spirit sind noch Sorgenkinder
mit der u.a. 5s Meldung.
Vielleicht sollte ich mal wie bei den WallPlug die Firma wechseln??
Gruß
Hans-Jürgen
Das kann ich bestaetigen.
Nach dem Umstieg auf den Aeotec sind die Eintraege jetzt wieder da :
2019.04.07 12:56:20 3: ZWave set LichtFlur on
2019.04.07 12:56:21 3: ZWave set LichtFlur on
2019.04.07 12:56:22 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001338032601FF255b7b
2019.04.07 12:56:23 3: ZWave set LichtFlur on
2019.04.07 12:56:23 3: ZWave set LichtFlur on
2019.04.07 12:56:23 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001338032601FF255b7b
2019.04.07 12:56:24 3: ZWave set LichtFlur on
2019.04.07 12:57:45 3: ZWave set LichtFlur on
2019.04.07 12:57:45 3: ZWave set LichtFlur on
2019.04.07 12:57:46 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001338032601FF256040
2019.04.07 13:00:36 3: ZWave set LichtFlur on
2019.04.07 13:00:36 3: ZWave set LichtFlur on
2019.04.07 13:00:36 3: ZWave set LichtFlur on
2019.04.07 13:00:36 3: ZWave set LichtFlur on
2019.04.07 13:00:37 3: ZWave set LichtFlur on
2019.04.07 13:00:38 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001338032601FF256242
2019.04.07 13:01:05 3: ZWave set LichtFlur on
2019.04.07 13:01:06 3: ZWave set LichtFlur on
2019.04.07 13:01:06 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001338032601FF256747
2019.04.07 13:01:08 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001338032601FF256747
2019.04.07 13:06:09 3: ZWave set LichtFlur off
2019.04.07 13:06:45 3: ZWave set LichtFlur on
2019.04.07 13:06:46 3: ZWave set LichtFlur on
2019.04.07 13:06:48 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001338032601FF256a4a
2019.04.07 13:06:50 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001338032601FF256b4b
2019.04.07 13:08:31 3: ZWave set LichtFlur on
2019.04.07 13:08:31 3: ZWave set LichtFlur on
2019.04.07 13:08:32 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001338032601FF256c4c
2019.04.07 13:08:50 3: ZWave set LichtFlur on
2019.04.07 13:08:50 3: ZWave set LichtFlur on
2019.04.07 13:08:50 3: ZWave set LichtFlur on
2019.04.07 13:08:50 3: ZWave set LichtFlur on
2019.04.07 13:08:52 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001338032601FF256e4e
2019.04.07 13:09:26 3: ZWave set LichtFlur on
2019.04.07 13:09:26 3: ZWave set LichtFlur on
2019.04.07 13:09:27 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001338032601FF257252
2019.04.07 13:14:27 3: ZWave set LichtFlur off
Zum Verstaendnis :
2019.04.07 18:21:49 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001324032501FF252b14
sind Meldungen der Kommunikation zwischen Raspberry und Dongle, nicht zwischen Dongle und Node ?
Was mich dabei stoert :
Die Kommandos werden gerne vielfach ausgefuehrt, warum ?
Das Kommando, welches aufgelistet wird , ' set LichtFlur on', ist nicht das was ich sehen sollte,
das Kommando muesste sein 'set LichtFlur on-for-timer 300'.
Soll das so sein ?
Noch eine Bemerkung von wegen USB3.0 :
Ich boote meinen Raspi von einem USB-Stick ( vielleicht ist ja auch deswegen USB ueberlastet ? );
das geht bei mir nur von einem USB2.0 Stick.
Hallo howi42,
mit meinem neuen Aeotec Dongle(ohne USB Verlängerung) hat sich nichts geändert mein Log wird wie vorher
extrem vollgeschrieben.
Denke mal nicht das es bei Dir am Pi liegt, Hardware ist bei mir ein Industrieserver
eigentlich mit genug Power auf USB und auch am starken USB Hub ist es nicht anders.
Frage mich ob es generell unter Linux an USB liegt,(irgendwelche Einstellungen) andere Baudrate hatte ich mal probiert,
hat aber nichts gebracht. Ob jemand ohne Unmengen ZWave Logeinträge seine Hardware Zusammenstellung unter Linux
bekannt geben könnte und ob sich ZWave mit anderer Hardware an USB nicht verträgt ?
Im Netz habe ich hierzu leider nichts gefunden.
Als Laie ist für mich erst mal Ende der Fahnenstange :(
Gruß
Hans-Jürgen
Hallo howi42,
indiskrete Frage gestattet ?
Benutzt Du structur für Zwave Geräte ?
Gruß
Hans-Jürgen
Schaut mal in https://forum.fhem.de/index.php/topic,92899.0.html , bzgl. des "richtigen" Einsatzes von FHEM-Steuerungslogiken bei ZWave. Eure Probleme könnten auch aus einem falschen/ungeschickten Einsatz von notify/DOIF,.. entstehen. Anhaltspunkte dazu können eher verbose 5 Logs als die hier gezeigten Logs geben.
Gruß, Christian
Bin in ein paar Tagen wieder zu Hause, dann kann ich ausführlichere Logs herstellen
Zitat von: howi42 am 09 April 2019, 11:06:56
Bin in ein paar Tagen wieder zu Hause, dann kann ich ausführlichere Logs herstellen
Der Hinweis auf verbose 5 war eigentlich nicht als Aufforderung zum Posten des entsprechenden Logs gemeint, sondern iVm verlinktem Thread lediglich ein Hinweis auf bessere Analysegrundlage für Euch/Dich. :)
Gruß, Christian
Schon verstanden, aber das erhoeht im Moment nur meine Frustration :
- Wenn ich alle beteiligten Z-Wave-Geraete einschliesslich Dongle auf verbose=5 setze, passiert nichts anderes als vorher.
- erst, wenn ich global verbose=5 setze, bekomme ich auch von den Z-Wave-Teilen ausfuehrlichere Logs.
Diese Logs besagen, alles ist topfit; nicht ein Eintrag von wegen
2019.04.12 12:35:48 2 : ZWDongle_ProcessSendStack: no ACK, resending message 010a001324032501FF255d62
sprich, entweder werden die Fehlermeldungen bei hoeherem verbose-level nicht nur ausfuehrlicher, sondern auch geaendert
oder der Fehler taucht dann nicht mehr auf.
womit ich dann mal wieder am Ende des Debuggens angekommen bin.
Ein paar Beobachtungen :
Das USB am Pi3 hat schon so seine Tuecken ....
- Nachdem ich den Aeotec direkt in den Raspberry gesteckt habe, sind all 'SOF'-Fehler verschwunden ( vorher war er an einer kurzen Verlaengerung, der Stick ist leider etwas gross )
- Nachdem ich den USB-Stick mit dem Betriebssystem wieder durch eine SD-Karte ersetzt habe, ist die Anzahl obiger Z-Wave-Fehlermeldungen zurueckgegangen.
Wesentlicher Unterschied : Die Karte ist ein gutes Stueck schneller als der Stick.
Die Meldungen, die ich im Moment noch sehe, kann ich vielleicht auf die Verwendung eine 'Structure' fuer die Lampen zurueckfuehren.
Muss ich mal umbauen.
Zitat von: howi42 am 12 April 2019, 12:54:35
Schon verstanden, aber das erhoeht im Moment nur meine Frustration :
War nicht meine Absicht, sorry :-[ . Zeigen ist auch nicht verboten.
Zitat- Wenn ich alle beteiligten Z-Wave-Geraete einschliesslich Dongle auf verbose=5 setze, passiert nichts anderes als vorher.
- erst, wenn ich global verbose=5 setze, bekomme ich auch von den Z-Wave-Teilen ausfuehrlichere Logs.
verbose 5 am ZWDongle müsste für ZWave immer ausführliche Logs im globalen Logfile liefern. Die Filelogs der Devices sind nicht interessant.
ZitatDas USB am Pi3 hat schon so seine Tuecken ....
Das kann ich nur deutlich unterstreichen.
Freut mich, dass das Änderung in diesem Zusammenhang zur Problemreduzierung beigetragen haben.
ZitatDie Meldungen, die ich im Moment noch sehe, kann ich vielleicht auf die Verwendung eine 'Structure' fuer die Lampen zurueckfuehren.
Muss ich mal umbauen
Ohne passendes Attribut async_delay ist structure mit mehreren ZWave-Devices potentielle Problemquelle.
Gruß, Christian
Hallo howi42,
nicht verzagen ;) arbeite mich auch durch den Frust...
kurze Anmerkung zu USB Port, auffällig war an meinem Hub es ging der Dongle nicht komplett rein, machte Mucken
und musste kurzes Kabel nutzen, check dies mal.
Nebensächlich hatte KODI Mediacenter auch schon komplett über USB Stick am laufen am PI3 mit Netzwerk TV.
Thema Structur hatte ich an 2 Thermostate(Spirit) mit Zeitverzögerung am laufen hat auch nicht geholfen.
Bin jetzt neu auf DOIF mit wait plus Dummy umgestiegen bei HeatingControl mit PID20.
Was mir heute morgen auffiel Fehlermeldung zum Schaltzeitpunkt von HC im Raum Büro dort besteht Sichtkontakt von 2-3 Meter vom Dongle zum
Thermostat(Spirit).
NoAck..... dürfte also nicht sein.
Habe mal den in den Code geschaut und eventuell wird zuviel Gleichzeitig hintereinander aus DOIF,PID20 und HeatingControl gesendet,
wie umstellen auf Nummer sicher wie tmManuell,protechtion off und dim von PID20.
Bin gerade am Code umstellen mal sehen ob es was nützt.
Dir viel Erfolg wünscht
Hans-Jürgen
Zitat von: Deckoffizier am 12 April 2019, 13:26:58
Thema Structur hatte ich an 2 Thermostate(Spirit) mit Zeitverzögerung am laufen hat auch nicht geholfen.
Bin jetzt neu auf DOIF mit wait plus Dummy umgestiegen bei HeatingControl mit PID20.
Was mir heute morgen auffiel Fehlermeldung zum Schaltzeitpunkt von HC im Raum Büro dort besteht Sichtkontakt von 2-3 Meter vom Dongle zum
Thermostat(Spirit).
NoAck..... dürfte also nicht sein.
Bitte daran denken, dass beim Spirit und anderen FLIRS-Geräten Laufzeiten von über 1 Sekunde normal sind. Also entsprechende Reserven beim asyn_delay/Pause einplanen. Zudem lädt diese lange Laufzeit geradezu zu Kommunikationsstörungen ein. In einer Sekunde können von anderen Geräten eine Vielzahl von Telgrammen kommen. Also möglichst für Ruhe im Netz sorgen.
Gruß, Christian
Hallo Christian,
ZitatBitte daran denken, dass beim Spirit und anderen FLIRS-Geräten Laufzeiten von über 1 Sekunde normal sind.
Danke! für den Hinweis.
Hatte asyn_delay von 2 sec, habe irgendwo mal gelesen Werte von über 5sec können Probleme machen??
Ach so gibt es eine Möglichkeit für komplett alle ZWave Geräte in einem Durchgang ein neighborUpdate zu machen aktualisieren.
Hatte an einem Gerät noch ein totes(altes) Device gefunden. Bei Batteriegeräten wohl eher schwierig(wakeup).
Gruß
Hans-Jürgen
Zitat von: Deckoffizier am 12 April 2019, 13:46:03
Hallo Christian,
Danke! für den Hinweis.
Hatte asyn_delay von 2 sec, habe irgendwo mal gelesen Werte von über 5sec können Probleme machen??
Zu Problemen über 5 Sekunden ist mir nichts bekannt.
Vielleicht auch noch mal zu den Kommunikationsproblemen allgemein:
Wiederholungen (resends) sind in ZWave nicht tragisch, solange keine Telegramm-Verluste auftreten. Also nicht zu viel Energie in resend-Vermeidung.
ZitatAch so gibt es eine Möglichkeit für komplett alle ZWave Geräte in einem Durchgang ein neighborUpdate zu machen aktualisieren.
Hatte an einem Gerät noch ein totes(altes) Device gefunden. Bei Batteriegeräten wohl eher schwierig(wakeup).
set TYPE=ZWave:FILTER=ZWaveSubDevice=no neighborUpdate
Auch Wakeup-Geräte werden dadurch abgearbeitet; jedoch nur beim Wakeup.
Gruß, Christian
Danke fuer eure Unterstuetzung.
Ein async-delay von 1s hat jetzt erstmal Wunder bewirkt.
Hallo howi42,
hoffentlich hält Dein Wunder länger an ;)
@krikan mein Fehler, habe mich vertan zum asyncdelay, hatte unter WNMI_delay gelesen.
Gruß
Hans-Jürgen