Ich mache hier mal einen seperaten Thread auf, das Thema hatte ich schon in einem anderen Thread angesprochen.
FHEM reagiert nach einer weile nicht mehr auf die Fibaro Türsensoren wenn sie open / close reporten.
Die Sensoren zeigen mir durch einmaliges Blinken an das sie zum UZB1 Dongel ihre Daten erfolgreich auch gesendet haben, jedoch in Fhem kommt nichts an.
Das senden von On/Off an Z-Wave Funksteckdosen funktioniert aber noch. Also reagiert das Modul irgendwann nicht mehr auf Ereignisse die von den Sensoren kommen. Bzw. es greift vom USB Dongle die Daten nicht mehr ab. USB seitig ist alles ok, dmesg zeigt mir keine Probleme auf.
Ich habe jetzt das Modul 10_ZWave.pm gegen ein altes von 2016 ausgetauscht, und voila, schon funktioniert alles wieder ohne ausfälle.
Also liegt es irgendwo an dem Modul, das es nach einer weile einfach nicht mehr sauber funktioniert.
Genau das gleiche Problem habe ich auch.
Ich habe allerdings keine Fensterkontakte, sondern ein Multisensor.
Dieser löst nach einer Zeit nicht mehr aus.
Die Bewegung wird aber erkannt, nur in FHEM sehe ich nichts mehr.
Der Sensor liefert mir auch die Helligkeit und die Luftfeuchtigkeit. In Fhem habe ich dafür einen Graphen erstellt und darin sehe ich dann keine Daten mehr.
Ein Shutdown/restart in fhem reaktiviert es wieder. Ebenso ein Aus und wieder Einstecken des Sticks.
Ich werde es auch einmal mit dem älteren Modul testen.
Handelt es sich in beiden Fällen um einen UZB1?
Falls ja, ist das Dongle gemäß zwave.me Anleitung mit einer USB-Verlängerung angeschlossen?
Falls nein, bitte ändern und testen.
Welche Serverhardware wird genutzt?
Ist das Dongle über einen Hub angeschlossen? Falls ja, bitte direkt anschließen.
Bei Raspi: Ist das Netzteil stark genug?
Dass es an der 10_ZWave.pm liegt, wage ich frech zu bezweifeln.
Gruß, Christian
Ich habe 2 UZB1 getestet, sowohl direkt am raspi verschiedene Ports, mit Verlängerung und ohne, auch mit HUB. Mit dem HUB hat es 2 Jahre ohne Probleme funktioniert genau in dieser Konstellation.
Netzteil hat genug Leistung. Nach rückspielen des alten Moduls läuft es jetzt stabil.
Kannst Du bitte schreiben, welche alten Modulversionen Du jetzt einsetzt?
Ausgabe von
version ZW
Danke.
Auch ich benutze den UZB1.
Er ist direkt am Raspberry angeschlossen.
Auch mein Netzteil ist start genug.
Ich habe es mit einer 10_ZWave.pm aus 2016 versucht, aber das Problem ist nicht verschwunden.
Zitat von: fritzhugo123 am 16 Mai 2018, 14:19:33
Er ist direkt am Raspberry angeschlossen.
Teste es bitte einmal mit Anschluss über USB-Verlängerung entsprechend UZB1-Anleitung (https://z-wave.me/download/ZMEXUZB1_Manual1.pdf).
Probleme mit Funkreichweite kannst Du ausschließen? Kleine Veränderungen können bei schlechter Funkqualität zum Verbindungsabbruch führen.
Gibt es genügend netzbetriebene Router?
kurzer Zwischenstand von meiner Seite, ich teste gerade noch ein paar sachen durch, bis jetzt läuft es.
version ZW liefert aktuell folgendes:
File Rev Last Change
10_ZWave.pm 12758 2016-12-12 20:34:02Z rudolfkoenig
00_ZWDongle.pm 12654 2016-11-25 19:18:53Z rudolfkoenig
ZWLib.pm 15466 2017-11-20 22:22:19Z rudolfkoenig
@fritzhugo123 evtl. kann es sein das du ein anderes Thema hast als ich. Nicht das wir hier 2 ähnliche Themen vermischen. Ich habe 35 ZWave Geräte, auch Funksteckdosen die ich einschalten kann. Nachdem ich eine Steckdose schalte, funktioniert auch wieder das Empfangen. Falls du so etwas hast dann teste das mal so. Einen reboot brauchst du eigentlich auch nicht, wenn du auf den Dongle einen reopen machst geht es zumindest bei mir auch wieder.
Checke bitte auch diese Einträge: sudo dmesg -T danach lösche mal die messages mit sudo dmesg -C, wenn dein Fehler wieder auftritt frage nochmals die dmesg Einträge ab. Sollte hier der UZB1 Stick erscheinen hast du evtl. doch ein Stromproblem.
Damit du weist welche device ID welches USB gerät ist kannst du auch den USB Bus abfragen mit sudo lsusb
Nein, das Problem ist aus meiner Sicht zu 100% das gleiche.
Ich habe zwei schaltbare Steckdosen, eine keyfob Fernbedienung und einen Multisensor.
Sowohl die Fernbedienung als auch der Multisensor steigen aus. Das heißt ich kann nichts mehr schalten und der Sensor liefert keine Daten wie Luftfeuchtigkeit und Helligkeit mehr und auch das gekoppelte Licht im Flur schaltet nicht mehr.
Mittlerweile habe ich auch herausgefunden und kann bestätigen, dass das Schalten der Steckdose ausreicht, um die Funktion zu reaktivieren.
Gestern Nachmittag habe ich wie vorgeschlagen den Stick aus dem Raspberry gezogen und mit einer USB Verlängerung angeschlossen.
Die Verbidnung lief bis heute morgen und ist dann wieder abgebrochen.
Wenn das Schalten der Steckdose die Verbindung reaktiviert, verstehe ich nicht, wie es ein Verbindungsproblem zwischen Stick und Geräte sein kann.
Man könnte mit einem reopen des Sticks oder Schaltbefehlen an die Steckdose per at das Problem mildern, aber die Ursache ist damit leider nicht gefunden und unglückliche Seiteneffekte könnten auftreten.
Ich stochere mal weiter, obwohl mir Ideen ehrlicherweise fehlen. Kann mich bei EnOcean daran erinnern, dass es mal Probleme mit volllaufender RAWMSG im Dongle-Device gab, die sich in fehlenden weiteren Events aller EnO-Devices zeigten.
ZitatDie Verbidnung lief bis heute morgen und ist dann wieder abgebrochen.
Wie wird nach dem Abbruch der Zustand des ZWDongle-Devices angezeigt?
Wie sieht "list <ZWDongle>" und "list <ZWdevice>" bei Abbruch aus?
Gib es verbose 5 Logs mit Zeitpunkt des Abbruchs?
Liefert die Steckdose auch keine Events/automatischen Infos bei einem Abbruch oder sind nur batteriebetrieben Devices betroffen?
@laserrichi: Hast Du auch eine alte DevIo.pm eingespielt?
@fritzhugo123: Hattest Du auch eine alte 00_ZWDongle.pm eingespielt oder nur 10_ZWave.pm?
Der Zustand des ZWDongel verändert sich nicht. Sowohl vorher als auch nachher sehe ich Initialized.
dongle:
Internals:
CallbackNr 0
Clients :ZWave:
DEF /dev/ttyACM0@115200
DeviceName /dev/ttyACM0@115200
FD 104
MaxSendRetries 3
NAME ZWDongle_1
NR 543
PARTIAL
RAWMSG 000400040a32022112001a00000000
ReadTime 1526728603.32528
STATE Initialized
SendRetries 0
SendTime 1526718945.6343
TYPE ZWDongle
WaitForAck 0
ZWDongle_1_MSGCNT 14516
ZWDongle_1_TIME 2018-05-19 13:16:43
homeId d7e3bf57
nodeIdHex 01
nrNAck 0
Matchlist:
1:ZWave .*
Readings:
2018-05-17 09:00:25 caps Vers:5 Rev:6 ManufID:0115 ProductType:0400 ProductID:0001 SERIAL_API_GET_INIT_DATA SERIAL_API_APPL_NODE_INFORMATION APPLICATION_COMMAND_HANDLER ZW_GET_CONTROLLER_CAPABILITIES SERIAL_API_SET_TIMEOUTS SERIAL_API_GET_CAPABILITIES SERIAL_API_SOFT_RESET UNKNOWN_09 UNKNOWN_0a ZW_SET_R_F_RECEIVE_MODE ZW_SET_SLEEP_MODE ZW_SEND_NODE_INFORMATION ZW_SEND_DATA ZW_SEND_DATA_MULTI ZW_GET_VERSION ZW_SEND_DATA_ABORT ZW_R_F_POWER_LEVEL_SET ZW_SEND_DATA_META ZW_GET_RANDOM MEMORY_GET_ID MEMORY_GET_BYTE MEMORY_PUT_BYTE MEMORY_GET_BUFFER MEMORY_PUT_BUFFER FLASH_AUTO_PROG_SET UNKNOWN_28 NVM_GET_ID NVM_EXT_READ_LONG_BUFFER NVM_EXT_WRITE_LONG_BUFFER NVM_EXT_READ_LONG_BYTE NVM_EXT_WRITE_LONG_BYTE ZW_GET_NODE_PROTOCOL_INFO ZW_SET_DEFAULT ZW_REPLICATION_COMMAND_COMPLETE ZW_REPLICATION_SEND_DATA ZW_ASSIGN_RETURN_ROUTE ZW_DELETE_RETURN_ROUTE ZW_REQUEST_NODE_NEIGHBOR_UPDATE ZW_APPLICATION_UPDATE ZW_ADD_NODE_TO_NETWORK ZW_REMOVE_NODE_FROM_NETWORK ZW_CREATE_NEW_PRIMARY ZW_CONTROLLER_CHANGE ZW_SET_LEARN_MODE ZW_ASSIGN_SUC_RETURN_ROUTE ZW_REQUEST_NETWORK_UPDATE ZW_SET_SUC_NODE_ID ZW_DELETE_SUC_RETURN_ROUTE ZW_GET_SUC_NODE_ID ZW_SEND_SUC_ID ZW_EXPLORE_REQUEST_INCLUSION ZW_REQUEST_NODE_INFO ZW_REMOVE_FAILED_NODE_ID ZW_IS_FAILED_NODE ZW_REPLACE_FAILED_NODE UNKNOWN_66 UNKNOWN_67 UNKNOWN_78 GET_ROUTING_TABLE_LINE LOCK_ROUTE_RESPONSE 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 UNKNOWN_d4 UNKNOWN_ef ZME_FREQ_CHANGE ZME_BOOTLOADER_FLASH UNKNOWN_f5
2018-05-17 09:00:26 ctrlCaps PRIMARY
2018-05-17 09:00:26 homeId HomeId:d7e3bf57 CtrlNodeIdHex:01
2017-03-11 14:25:41 nodeList ZWDongle_1 ZWave_SWITCH_BINARY_2
2018-05-17 09:00:26 random 55a4644989733b747d92fb49612f70c1f55c5d12c8cdb19cb207a9b21ad202bf
2018-05-17 09:00:26 state Initialized
2018-05-17 09:00:26 sucNodeId no
SendStack:
Attributes:
verbose 3
device:
Internals:
DEF d7e3bf57 3
IODev ZWDongle_1
LASTInputDev ZWDongle_1
MSGCNT 8479
NAME ZWave_SENSOR_MULTILEVEL_3
NR 574
STATE configLong 101 224
TYPE ZWave
ZWDongle_1_MSGCNT 8479
ZWDongle_1_RAWMSG 000400030a7105000000ff07080000
ZWDongle_1_TIME 2018-05-19 13:16:43
ZWaveSubDevice no
homeId d7e3bf57
isWakeUp
nodeIdHex 03
Readings:
2018-01-31 20:17:49 UNPARSED METER 0a3203214400007b120000
2018-05-19 13:16:43 alarm HomeSecurity: Motion Detection - Unknown Location, arg 0000
2018-05-19 13:16:43 basicSet 255
2018-05-19 13:15:49 dewpoint 9.0
2018-05-19 13:15:49 humidity 41 %
2018-05-19 13:15:50 luminance 126 Lux
2018-01-30 00:49:55 power 95.2 W
2017-08-17 08:36:47 state configLong 101 224
2018-05-19 13:15:49 temperature 23.0 C
Attributes:
IODev ZWDongle_1
classes ZWAVEPLUS_INFO VERSION MANUFACTURER_SPECIFIC ASSOCIATION_GRP_INFO ASSOCIATION POWERLEVEL ALARM BASIC BATTERY SENSOR_BINARY SENSOR_MULTILEVEL CONFIGURATION FIRMWARE_UPDATE_MD DEVICE_RESET_LOCALLY MARK
room ZWave
vclasses ALARM:3 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BATTERY:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:2 MANUFACTURER_SPECIFIC:2 POWERLEVEL:1 SENSOR_BINARY:1 SENSOR_MULTILEVEL:5 VERSION:2 WAKE_UP:2 ZWAVEPLUS_INFO:2
Die Steckdosen liefern auch keine Daten mehr, wie den aktuellen Verbrauch.
Ich habe nur die 10_ZWave.pm ausgetaucht. Die ZWDongle ist ja schon von 2016.
Zitat von: fritzhugo123 am 19 Mai 2018, 14:45:09
Ich habe nur die 10_ZWave.pm ausgetaucht. Die ZWDongle ist ja schon von 2016.
Darüber bin ich verwundert. 00_ZWDongle.pm ist seit 2016 diverse Male angepasst worden.
Wenn 00_ZWDongle.pm und 10_ZWave.pm nicht in aufeinander abgestimmten Versionen eingesetzt werden, sind Probleme vorprogrammiert. Das gilt auch im Zusammenspiel mit anderen Modulen.
Wurde bereits mit dem aktuellen FHEM-update-Stand aller Module probiert und sind damit die genannten Abbrüche auch vorhanden?
Ich habe ein FHEM update gemacht.
Folgende Version läuft nun. Ich werde testen und berichten.
File Rev Last Change
10_ZWave.pm 16266 2018-02-25 18:22:51Z rudolfkoenig
00_ZWCUL.pm 16552 2018-04-04 19:24:18Z rudolfkoenig
00_ZWDongle.pm 16293 2018-02-28 21:33:57Z rudolfkoenig
ZWLib.pm 15466 2017-11-20 22:22:19Z rudolfkoenig
Es hat sich leider nichts geändert.
Die Verbindung läuft einige Zeit und dann "schläft" sie ein.
Erst, wenn über FHEM ein schaltbares Gerät benutzt wird, baut sich die Verbindung wieder auf.
Nur mal so als Idee ... wie ist der "Stromsparmodus" im USB-Bereich eingestellt?
jetzt von mir mal ein feedback, solch tests brauchen auch eine gewissen Zeit, und bei mir läuft bis jetzt alles mit dem alten Modul.
Gerade ist mir etwas aufgefallen, ich hatte nur die 10_ZWave.pm ausgetaucht, die 00_ZWDongle.pm war bei mir noch auf Stand 2016, hatte die aber nicht angefasst. Updates mache ich eigentlich regelmäßig. Oder ich habs doch aus versehen getauscht, bei so vielen Versuchen weis man am ende nicht mehr was man alles probiert hat.
Wäre vieleicht eine Erklärung, passt aber nicht bei fritzhugo123
Habe jetzt nochmal upgedated, und beobachte weiter mit dem Stand:
10_ZWave.pm 16266 2018-02-25 18:22:51Z rudolfkoenig
00_ZWDongle.pm 16293 2018-02-28 21:33:57Z rudolfkoenig
Hallo zusammen, hatte leider wenig Zeit damit zu spielen, aber seitdem ich auf aktuellem Stand bin hab ich das Problem wieder.
Das selbe Spiel, senden geht immer, aber Empfang geht irgendwann nicht mehr. Als ob fhem den Dongle nicht mehr abfrägt, bzw. nichts mehr akzeptiert was da reinkommt.
Hallo,
auch bei mir ist das selbe Problem. Ich dachte es läge an einem OS Fehler und hab einen neuen Raspi besorgt und alles neu aufgesetzt (verwende RasPi mit starkem Netzteil und Razberry Modul) - jedoch ist der selbe Effekt nachweißbar. Es passiert ca. alle 7 - 14 Tage, dann werde im FHEM keine Sensorwerte mehr empfangen bzw. vielleicht schon aber FHEM verarbeitet diese nicht? Ein FHEM restart bringt keine Lösung sonder nur ein Reboot vom OS. Da ich mitlerweile seit mehr als 1 Jahr ca. 40 ZWave Geräte verwende und doch sehr viel automatisiert habe, ist das Verhalten eine Katastrophe für mich.
Hat jemand eine Idee?
Danke!
Damit wir das Problem lokalisieren koennen: Kann bitte jeder mit dem Problem die genaue Hardware und OS Version nennen?
Ok, hier mal meine Config:
der Zwave UZB1 hängt direkt am Raspberry mit kabel und 1m davon entfernt, ich habe einen zweiten UZB1 und daran liegt es schon mal nicht, reichweite ist auch ausgeschlossen, ist egal ob im selben Raum oder weiter weg.
Die beiden QinHeng Electronics Geräte sind Arduino nano mit Signalduino 433 und 868Mhz bestückt. Stromaufnahme des USB Hubs mit den Rademacher und Signalduinos habe ich gemessen und ist im grünen Bereich, wobei ich mit denen noch nie ein Problem hatte.
OS = Stretch
Raspberry Pi 3 Model B Rev 1.2
ARMv7 Processor rev 4 (v7l)
Hardware : BCM2835
Revision : a02082
-usbhost
product: DWC OTG Controller
vendor: Linux 4.14.34-v7+ dwc_otg_hcd
physical id: 1
bus info: usb@1
logical name: usb1
version: 4.14
capabilities: usb-2.00
configuration: driver=hub slots=1 speed=480Mbit/s
*-usb
description: USB hub
product: SMC9514 Hub
vendor: Standard Microsystems Corp.
physical id: 1
bus info: usb@1:1
version: 2.00
capabilities: usb-2.00
configuration: driver=hub maxpower=2mA slots=5 speed=480Mbit/s
*-usb:0
description: Generic USB device
product: SMSC9512/9514 Fast Ethernet Adapter
vendor: Standard Microsystems Corp.
physical id: 1
bus info: usb@1:1.1
version: 2.00
capabilities: usb-2.00
configuration: driver=smsc95xx maxpower=2mA speed=480Mbit/s
*-usb:1
description: Human interface device
product: Back-UPS CS 500 FW:808.q7.I USB FW:q7
vendor: American Power Conversion
physical id: 2
bus info: usb@1:1.2
version: 0.06
serial: BB0635020036
capabilities: usb-1.10
configuration: driver=usbhid speed=1Mbit/s
*-usb:2
description: Communication device
vendor: Sigma Designs, Inc.
physical id: 3
bus info: usb@1:1.3
version: 0.00
capabilities: usb-2.00
configuration: driver=cdc_acm maxpower=100mA speed=12Mbit/s
*-usb:3
description: USB hub
product: USB 2.0 Hub [MTT]
vendor: Terminus Technology Inc.
physical id: 5
bus info: usb@1:1.5
version: 1.00
capabilities: usb-2.00
configuration: driver=hub maxpower=100mA slots=7 speed=480Mbit/s
*-usb:0
description: Generic USB device
product: USB2.0-Serial
vendor: QinHeng Electronics
physical id: 2
bus info: usb@1:1.5.2
version: 2.54
capabilities: usb-1.10
description: Generic USB device
product: USB2.0-Serial
vendor: QinHeng Electronics
physical id: 2
bus info: usb@1:1.5.2
version: 2.54
capabilities: usb-1.10
configuration: driver=ch341 maxpower=96mA speed=12Mbit/s
*-usb:1
description: Generic USB device
product: USB2.0-Serial
vendor: QinHeng Electronics
physical id: 5
bus info: usb@1:1.5.5
version: 2.54
capabilities: usb-1.10
configuration: driver=ch341 maxpower=96mA speed=12Mbit/s
*-usb:2
description: Generic USB device
product: DuoFern USB-Stick
vendor: Rademacher
physical id: 7
bus info: usb@1:1.5.7
version: 6.00
serial: WR02I9MX
capabilities: usb-2.00
configuration: driver=ftdi_sio maxpower=90mA speed=12Mbit/s
*-network
description: Ethernet interface
physical id: 2
logical name: eth0
serial: b8:27:eb:XX:XX:XX
size: 100Mbit/s
capacity: 100Mbit/s
capabilities: ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=smsc95xx driverversion=22-Aug-2005 duplex=full firmware=smsc95xx USB 2.0 Ethernet ip=XX.XX.XX.XX link=yes multicast=yes port=MII speed=100Mbit/s
$ vcgencmd version
Apr 16 2018 18:16:56
Copyright (c) 2012 Broadcom
version af8084725947aa2c7314172068f79dad9be1c8b4 (clean) (release)
Bus 001 Device 011: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 001 Device 010: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
Bus 001 Device 009: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
Bus 001 Device 007: ID 1a40:0201 Terminus Technology Inc. FE 2.1 7-port Hub
Bus 001 Device 024: ID 0658:0200 Sigma Designs, Inc.
Bus 001 Device 021: ID 051d:0002 American Power Conversion Uninterruptible Power Supply
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
hier noch in der Baumansicht:
Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/5p, 480M
|__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=smsc95xx, 480M
|__ Port 2: Dev 21, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 3: Dev 24, If 0, Class=Communications, Driver=cdc_acm, 12M
|__ Port 3: Dev 24, If 1, Class=CDC Data, Driver=cdc_acm, 12M
|__ Port 5: Dev 7, If 0, Class=Hub, Driver=hub/7p, 480M
|__ Port 2: Dev 9, If 0, Class=Vendor Specific Class, Driver=ch341, 12M
|__ Port 5: Dev 10, If 0, Class=Vendor Specific Class, Driver=ch341, 12M
|__ Port 7: Dev 11, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M
Moin,
ich habe das Problem jetzt auch https://forum.fhem.de/index.php?topic=88671.msg811490#msg811490
Leider ist nicht reproduzierbar, wann der USB_Dongle "einschläft". Vorgestern morgen, dann wieder gestern Abend. Dazwischen lief alles wieder gut.
Ich rufe jetzt als Notlösung per "at" jede Stunde ein "get <device> nodeId" auf.
Wenn ich weitere Lists hinzufügen soll was der Fehlersuche dienlich sein soll, bitte melden.
ZitatWenn ich weitere Lists hinzufügen soll was der Fehlersuche dienlich sein soll, bitte melden.
Ja, bitte OS und Hardware Version mitteilen, wie ich das zwei Beitraege vorher geschrieben habe.
Ok,
OS:
PRETTY_NAME="Debian GNU/Linux 8 (jessie)"
NAME="Debian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=debian
USB:
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 011: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x UART Br idge / myAVR mySmartUSB light
Bus 001 Device 014: ID 0403:6001 Future Technology Devices International, Ltd FT 232 USB-Serial (UART) IC
Bus 001 Device 008: ID 0835:8502 Action Star Enterprise Co., Ltd
Bus 001 Device 007: ID 0835:8500 Action Star Enterprise Co., Ltd
Bus 001 Device 006: ID 0403:6015 Future Technology Devices International, Ltd Br idge(I2C/SPI/UART/FIFO)
Bus 001 Device 005: ID 1b1f:c00f
Bus 001 Device 004: ID 0658:0200 Sigma Designs, Inc.
Bus 001 Device 003: ID 0835:8501 Action Star Enterprise Co., Ltd
Bus 001 Device 002: ID 0835:8500 Action Star Enterprise Co., Ltd
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
ZWave-USB_Dongle
Internals:
CallbackNr 0
Clients :ZWave:
DEF /dev/serial/by-id/usb-0658_0200-if00@115200
DeviceName /dev/serial/by-id/usb-0658_0200-if00@115200
FD 108
MaxSendRetries 3
NAME ZWDongle_1
NR 916
PARTIAL
RAWMSG 0004000d0531051b0102
ReadTime 1530118519.97188
STATE Initialized
SendRetries 0
SendTime 1530116004.79884
TYPE ZWDongle
WaitForAck 0
ZWDongle_1_MSGCNT 34467
ZWDongle_1_TIME 2018-06-27 18:55:19
homeId xxxxxxxxx
nodeIdHex 01
nrNAck 0
MatchList:
1:ZWave .*
READINGS:
2018-06-25 08:08:10 caps Vers:5 Rev:5 ManufID:0115 ProductType:0400 ProductID:0001 SERIAL_API_GET_INIT_DATA SERIAL_API_APPL_NODE_INFORMATION APPLICATION_COMMAND_HANDLER ZW_GET_CONTROLLER_CAPABILITIES SERIAL_API_SET_TIMEOUTS SERIAL_API_GET_CAPABILITIES SERIAL_API_SOFT_RESET UNKNOWN_09 UNKNOWN_0a ZW_SET_R_F_RECEIVE_MODE ZW_SET_SLEEP_MODE ZW_SEND_NODE_INFORMATION ZW_SEND_DATA ZW_SEND_DATA_MULTI ZW_GET_VERSION ZW_SEND_DATA_ABORT ZW_R_F_POWER_LEVEL_SET ZW_SEND_DATA_META ZW_GET_RANDOM MEMORY_GET_ID MEMORY_GET_BYTE MEMORY_PUT_BYTE MEMORY_GET_BUFFER MEMORY_PUT_BUFFER FLASH_AUTO_PROG_SET UNKNOWN_28 NVM_GET_ID NVM_EXT_READ_LONG_BUFFER NVM_EXT_WRITE_LONG_BUFFER NVM_EXT_READ_LONG_BYTE NVM_EXT_WRITE_LONG_BYTE ZW_GET_NODE_PROTOCOL_INFO ZW_SET_DEFAULT ZW_REPLICATION_COMMAND_COMPLETE ZW_REPLICATION_SEND_DATA ZW_ASSIGN_RETURN_ROUTE ZW_DELETE_RETURN_ROUTE ZW_REQUEST_NODE_NEIGHBOR_UPDATE ZW_APPLICATION_UPDATE ZW_ADD_NODE_TO_NETWORK ZW_REMOVE_NODE_FROM_NETWORK ZW_CREATE_NEW_PRIMARY ZW_CONTROLLER_CHANGE ZW_SET_LEARN_MODE ZW_ASSIGN_SUC_RETURN_ROUTE ZW_REQUEST_NETWORK_UPDATE ZW_SET_SUC_NODE_ID ZW_DELETE_SUC_RETURN_ROUTE ZW_GET_SUC_NODE_ID ZW_SEND_SUC_ID ZW_EXPLORE_REQUEST_INCLUSION ZW_REQUEST_NODE_INFO ZW_REMOVE_FAILED_NODE_ID ZW_IS_FAILED_NODE ZW_REPLACE_FAILED_NODE UNKNOWN_66 UNKNOWN_67 UNKNOWN_78 GET_ROUTING_TABLE_LINE LOCK_ROUTE_RESPONSE 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 UNKNOWN_d4 UNKNOWN_ef ZME_FREQ_CHANGE ZME_BOOTLOADER_FLASH ZME_CAPABILITIES
2018-06-25 08:08:10 ctrlCaps PRIMARY
2018-06-27 18:13:24 homeId HomeId:xxxxxxx CtrlNodeIdHex:01
2018-06-15 20:18:49 neighborList_01 Licht.Diele Licht.ElternBad ZWave_SWITCH_BINARY_8 UNKNOWN_9 Licht.Kino
2018-06-15 20:19:00 neighborList_02 empty
2018-06-15 20:15:55 nodeList ZWDongle_1 Licht.Diele Licht.ElternBad ZWave_SWITCH_BINARY_8 UNKNOWN_9 ZWave_SWITCH_BINARY_10 ZWave_SWITCH_BINARY_11 Licht.Kino Multisensor
2018-06-25 08:08:10 random b550163bd9aefb8b2841b64d679211620febc6b4a9460e399073b7e183cdbba2
2018-06-25 08:08:10 state Initialized
2018-06-25 08:08:10 sucNodeId no
2018-06-26 23:00:15 version Z-Wave 4.05 STATIC_CONTROLLER
SendStack:
Attributes:
devStateIcon disconnected:message_attention@FF9100 Initialized:it_wifi@0CFB0C
group CUL
homeId xxxxxx
icon cul_868
neighborListPos 42.5,20
Multisensor
Internals:
CHANGED
DEF d6543407 13
IMAGE /fhem/deviceimages/zwave/ZC10-17115891
IODev ZWDongle_1
LASTInputDev ZWDongle_1
MSGCNT 28166
NAME Multisensor
NR 1380
STATE 2 UV,30000 Lux,29.9 C,29 %
TYPE ZWave
ZWDongle_1_MSGCNT 28166
ZWDongle_1_RAWMSG 0004000d0531051b0102
ZWDongle_1_TIME 2018-06-27 18:55:19
ZWaveSubDevice no
cmdsPending 0
homeId xxxxxx
isWakeUp
lastMsgSent 1530047038.1891
nodeIdHex 0d
READINGS:
2018-06-03 11:34:00 CO2-level 27.9 ppm
2018-06-15 13:26:36 SEND_DATA failed:00
2018-06-27 16:46:49 alarm HomeSecurity: Tampering - product covering removed, arg 0000
2018-06-14 13:21:07 basicSet 0
2018-06-27 18:55:18 battery 100 %
2018-06-27 18:55:18 batteryPercent 100
2018-06-27 18:55:18 batteryState ok
2018-06-15 13:25:53 configBatteryReportingThreshold 10
2018-06-15 13:25:55 configCommandOptions BasicSet
2018-06-15 13:25:55 configCurrentPowerMode USBPowerSleepingModeAfterRePower0
2018-06-26 23:03:20 configEnableDisableLockConfiguration Enable
2018-06-26 23:03:30 configEnableDisableToSendAReportOn48 2
2018-06-15 13:26:03 configEnableMotionSensor Disabled
2018-06-15 13:26:04 configGetTheOutOfLimitStateOfThe61 0
2018-06-15 13:26:07 configGroup1Interval 300
2018-06-15 13:26:10 configGroup1Reports 241
2018-06-15 13:26:10 configGroup2Interval 300
2018-06-15 13:26:11 configGroup2Reports 241
2018-06-15 13:26:12 configGroup3Interval 300
2018-06-15 13:26:13 configGroup3Reports 241
2018-06-15 13:26:14 configHumidityCalibration 0
2018-06-15 13:26:16 configHumidityReportingThreshold 1
2018-06-15 13:26:17 configLowBattery 20
2018-06-15 13:26:18 configLowTempAlarm Disabled
2018-06-15 13:26:21 configLuminanceCalibration 0
2018-06-26 23:03:58 configLuminanceReportingThreshold 1
2018-06-15 13:26:23 configOnTime 240
2018-06-16 08:02:20 configReportOnlyOnThresholds Disabled
2018-06-15 13:26:26 configSetTheLowerLimitValueOf50 1
2018-06-15 13:26:27 configSetTheLowerLimitValueOf56 4
2018-06-15 13:26:28 configSetTheLowerLimitValueOfHumidity52 50
2018-06-15 13:26:31 configSetTheLowerLimitValueOfLighting54 100
2018-06-15 13:26:33 configSetTheRecoverLimitValueOf57 5121
2018-06-15 13:26:36 configSetTheRecoverLimitValueOf58 5
2018-06-15 11:13:34 configSetTheRecoverLimitValueOf59 10
2018-06-14 20:46:20 configSetTheRecoverLimitValueOf60 2
2018-06-15 13:26:41 configSetTheUpperLimitValueOf49 71681
2018-06-15 13:26:42 configSetTheUpperLimitValueOf55 8
2018-06-15 13:26:43 configSetTheUpperLimitValueOfHumidity51 60
2018-06-15 13:26:44 configSetTheUpperLimitValueOfLighting53 1000
2018-06-15 13:26:46 configTemperatureCalibration 1
2018-06-15 21:37:08 configTemperatureReportingThreshold 1
2018-06-15 13:26:48 configTemperatureScale Celsius
2018-06-15 13:26:50 configUVReportingThreshold 2
2018-06-15 13:26:52 configUltravioletCalibration 0
2018-06-15 13:26:53 configWakeUp10MinutesOnPowerOn Disable
2018-06-27 18:55:18 humidity 29 %
2018-06-27 18:55:18 luminance 30000 Lux
2018-05-22 16:22:23 model Aeotec ZW100 MultiSensor 6
2018-05-22 16:22:23 modelConfig aeotec/zw100.xml
2018-05-22 16:22:23 modelId 0086-0002-0064
2018-05-22 16:35:02 neighborList Licht.Diele Licht.ElternBad ZWave_SWITCH_BINARY_8 ZWave_SWITCH_BINARY_10 Licht.Kino
2018-06-15 20:22:22 neighborUpdate done
2018-05-22 19:06:14 powerlvl current 0 remain 0
2018-06-26 23:01:42 powerlvlTest node 0 status 0 frameAck 0
2018-06-26 23:02:57 state configEnableDisableLockConfiguration Enable
2018-06-27 18:55:17 temperature 29.9 C
2018-06-26 23:03:58 timeToAck 0.209
2018-06-26 23:03:58 transmit OK
2018-06-27 18:55:19 ultraviolet 2 UV
2018-06-26 23:01:29 version Lib 3 Prot 4.05 App 1.7 HW 100 FWCounter 0
Attributes:
IODev ZWDongle_1
WNMI_delay 2
classes ZWAVEPLUS_INFO VERSION MANUFACTURER_SPECIFIC ASSOCIATION_GRP_INFO ASSOCIATION POWERLEVEL ALARM BATTERY SENSOR_BINARY SENSOR_MULTILEVEL CONFIGURATION FIRMWARE_UPDATE_MD DEVICE_RESET_LOCALLY MARK
event-on-change-reading ultraviolet:1,luminance:1,humidity:1,temperature:1
room 00_Wetter,ZWave
stateFormat ultraviolet,luminance,temperature,humidity
vclasses ALARM:3 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BATTERY:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:2 SENSOR_BINARY:1 VERSION:2 ZWAVEPLUS_INFO:2
Board: BananaPiPro
Date: 27.06.2018 18:58:59
CPU temperature: 42.6 °C
CPU frequency: 1008 MHz
CPU model name: ARMv7 Processor rev 4 (v7l)
BogoMIPS: 2015.49
System up time: 75 days, 02 hours, 46 minutes
FHEM up time: 12 days, 03 hours, 24 minutes
Load average: 0.15 0.27 0.20
RAM: Total: 970.39 MB, Used: 355.64 MB, 36.65 %, Free: 614.75 MB
swap: n/a
AC-Versorgung Info: ac: present / online, voltage: 5.266 V, current: 275 mA, 1.4 W
USB-Versorgung Info: usb: absent / offline, voltage: 0 V, current: 0 mA, 0 W
Batterie-Versorgung Info: battery: absent / offline, voltage: 0 V, current: 0 mA, 0 W, capacity: 0 %
Ethernet: RX: 2414.80 MB, TX: 3333.51 MB, Total: 5748.31 MB
Filesystem /boot: Total: 0 MB, Used: 0 MB, 0 %, Available: 0 MB at /boot (not available)
Root: Total: 15749 MB, Used: 2405 MB, 17 %, Available: 12545 MB at /
SSD: Total: 105681 MB, Used: 94609 MB, 90 %, Available: 10560 MB at /media/ssd
Nur um es klarzustellen: mir reicht sowas wie "RPi v3, Debian Stretch, ZWave.me USB"
Hallo zusammen. Ich hatte in der letzten Zeit mehrmals täglich das Problem. Ich bin nun auf folgendem Stand zurückgegangen:
10_ZWave.pm 15445 2017-11-18 10:29:25Z rudolfkoenig
00_ZWDongle.pm 15538 2017-12-01 21:07:41Z rudolfkoenig
bis jetzt läuft das stabil seit 2 Tagen. Meine Vermutung: das Zusammenspiel mit dem USB Modul cdc_acm bzw. Timing ?
Danke fuer den Hinweis. Die wenigen Aenderungen in 10_ZWDongle.pm sind aus dieser Hinsicht irrelevant. In 00_ZWDongle gibt es eine relevante Aenderung: falls man bei der Definition keine Baudrate definiert hat, dann wird @115200 gesetzt. Das wurde zwar vorher auch versucht, aber wegen Tippfehler war es wirkungslos. Falls die Baudrate gesetzt ist, dann wird auch handshake, stopbits, usw auf "sinnvolle" Werte gesetzt.
@laserrichi: kannst du bitte deine ZWDongle Definition zeigen?
Falls sie @115200 enthaelt, dann besteht fuer dieses Problem kein Unterschied zwischen dem "alten" und dem aktuellen Stand beider Dateien. Falls kein @115200 enthalten ist, und die alte Version das Problem loest, dann wird durchs Aendern der Parameter der seriellen Schnittstelle ein Schlafmodus aktiviert. In diesem Fall werde ich das "Zwangssetzen" der Baudrate ausbauen.
ich habe das so definiert: /dev/ttyACM0@115200
probiert hatte ich auch schon das ganze mit /dev/serial/by-id/usb-0658_0200-if00@115200
d.h. wenn ich das jetz richtig verstehe, sollte ich mit der neuen Version einmal die Baudrate weglassen ?
Zitatd.h. wenn ich das jetz richtig verstehe, sollte ich mit der neuen Version einmal die Baudrate weglassen ?
Nein, das heisst, dass zwischen der alten und neuen Version aus Sicht dieses Problems kein Unterschied besteht.
Die Neue packt @115200 dazu, wenn sie nicht vorhanden ist, die Alte nicht.
Wir muessen wohl weiter suchen.
Zitat von: rudolfkoenig am 27 Juni 2018, 08:22:29
Ja, bitte OS und Hardware Version mitteilen, wie ich das zwei Beitraege vorher geschrieben habe.
Meine Konfig:
RPi 3, Raspbian Strech, Razberry zwave.me
PS: Problem tritt noch immer auf.
update: mit den alten Modulen von 2017 wie ich oben geschrieben habe, läuft es bisher stabil.
Ich rufe per at stündlich ein "get ZWDongle_1 homeId" auf, hilft auch, ist aber nicht "schön"
zack, jetzt ist es wieder aufgetreten, aber mit den alten modulversionen läuft es reproduzierbar definitiv länger bis das Problem wieder auftritt.
ich hatte ein ähnlich gelagertes Problem letztens. -> https://forum.fhem.de/index.php/topic,89063.msg815621.html#msg815621
Was ich da nicht geschrieben hatte, dass das Senden in der Tat noch ging
Grund war, das der user fhem nicht mehr in der Gruppe dialout war oder sich die Gruppe geändert hatte. Warum ist mir bisher unklar.
ich werde den Verdacht nicht los das es ein timing Thema ist.
Mit den Modulen von 2017 läufts min. 1 Woche stabil, und die 2018er machen die Probleme.
Nachdem zwave nicht sauber funktionierte, hatte ich die Alarmanlage lange nicht mehr scharf geschaltet. Da jetzt das ganze wieder funktioniert mit den alten Modulen, hab ich sie auch wieder aktiviert.
Zur Kontrolle scharf/unscharf benutze ich am Türreader den Buzzer der mittels ESPEasys on/off geschaltet wird. Je nach morsecode weis ich ob alles geklappt hat.
Auch da habe ich gemerkt, das es nicht mehr so geschmeidig läuft und manch piepsen ewig lange dauert.
mach das mit sehr kurzen intervallen:
set TuerBuzzer on ;sleep 0.1 ;set TuerBuzzer off ;sleep 0.2 ;set TuerBuzzer on ;sleep 0.1 ;set TuerBuzzer off
kann aber durchaus ein anderes Thema sein da es über wlan läuft. Zufall oder Gemeinsamkeit ?
ZitatMit den Modulen von 2017 läufts min. 1 Woche stabil, und die 2018er machen die Probleme.
Wie ich es frueher geschrieben habe, glaube ich nicht an dieser Theorie.
Zitatset TuerBuzzer on ;sleep 0.1 ;set TuerBuzzer off ;sleep 0.2 ;set TuerBuzzer on ;sleep 0.1 ;set TuerBuzzer off
Sowas mit Funk zu realisieren schreit nach "ich will Probleme haben". Falls einer der Signale nicht quittiert wird, dann wird sie wiederholt, parallel dazu laeuft aber schon der naechste Befehl.
Direkte ZWave Nachrichten laufen im 0.01s Bereich, aber bei mehrfachen Routing / schlechte Funkverbindung wurden schon Werte in Sekundenbereich beobachtet. Siehe auch das timeToAck Reading bei den ZWave Geraeten.
Zitat von: Bartimaus am 06 Juli 2018, 22:58:26
Ich rufe per at stündlich ein "get ZWDongle_1 homeId" auf, hilft auch, ist aber nicht "schön"
das mach ich jetzt auch und seit dem ist das Verhalten nicht mehr aufgetaucht...
Zitat von: gotocu am 12 Juli 2018, 12:50:58
das mach ich jetzt auch und seit dem ist das Verhalten nicht mehr aufgetaucht...
Muß meine Aussage nun nach zwei Wochen leider relativieren. Das Verhalten (FHEM spielt tot) tritt zwar weniger häufig auf, jedoch ist das get homeId nicht der Stein der Weisen. Läuft FHEM zu lange ohne Neustart (also mehr als 3 Tage) dann tritt oben beschriebene Verhalten wieder auf. Eigenartigerweise betrifft es nun auch meinen Nachbarn mit seiner FHEM Installation - er hat bis vor kurzem noch keine Probleme damit gehabt.
Ich hoffe es findet sich bald die Lösung für unser Problem.
Ich habe den gleichen Effekt und auch schon vor Wochen ein extra Thema aufgemacht (https://forum.fhem.de/index.php?topic=88585.msg820029#msg820029 (https://forum.fhem.de/index.php?topic=88585.msg820029#msg820029)).
Vielleicht kan man irgendwie zusammenwirken.
Peter
Hallo Peter, ich hab deinen Beitrag auch gelesen. Ich kann nur sagen das ich mit den Modulen von Dezember 2017 keine Probleme mehr habe. Vieleicht kannst du das bei dir auch einmal verifizieren und die alten Module verwenden und ob bei Dir dann die Timeouts weg sind.
@laserrichi:
Ich will ja nichts unversucht lassen !
Kannst du mir genau sagen, um welche Module es sich dabei handelt ? Was müsste ich sonst noch beachten, um zu diesem alten Zustand zurück zu kehren ?
Danke im Voraus.
Peter
ich habe die beiden Dateien hier mal angehängt, ist vieleicht einfacher. Die kopierst du in dein FHEM Verzeichnis (linux rechte und gruppen beachten).
wenn du Fhem neu startest sollten sich die module mit "version ZW" so darstellen:
10_ZWave.pm 15445 2017-11-18 10:29:25Z rudolfkoenig
00_ZWDongle.pm 15538 2017-12-01 21:07:41Z rudolfkoenig
Zitat von: gotocu am 20 Juli 2018, 10:31:29
Muß meine Aussage nun nach zwei Wochen leider relativieren. Das Verhalten (FHEM spielt tot) tritt zwar weniger häufig auf, jedoch ist das get homeId nicht der Stein der Weisen. Läuft FHEM zu lange ohne Neustart (also mehr als 3 Tage) dann tritt oben beschriebene Verhalten wieder auf. Eigenartigerweise betrifft es nun auch meinen Nachbarn mit seiner FHEM Installation - er hat bis vor kurzem noch keine Probleme damit gehabt.
Ich hoffe es findet sich bald die Lösung für unser Problem.
Also mein Banana läuft seit 100 Tagen ohne Neustart, FHEM seit ca. 30 Tagen ohne Neustart. Das Problem ist bei mir nicht mehr aufgetreten (dank "at")
@laserrichi:
Danke für die Module; ich habe es "der Vollständigkeit halber" probiert, aber ohne Erfolg.
Ich bin insofern etwas weiter (siehe das andere Thema), als ich mir inzwischen ziemlich sicher bin, dass ein 'at..'-Befehl nur eine scheinbare Lösung ist.
Dieser 'Totzustand' tritt auf jeden Fall ein, er wird aber sofort beendet, wenn ein FHEM-Befehl (also beispielsweise 'at..') raus geht. Ich habe jetzt einen 'at..' - Befehl im Minutenabstand. Demzufolge - und das ist im Logfile nachweisbar - wird der 'Totzustand' eben auch 'umgehend' wieder beendet und ist demzufolge u.U. garnicht bemerkbar.
Da der ZWay-Server aber problemlos läuft - und zwar ohne 'Totzustand' - versuche ich jetzt die Controlerinitialisierung beim ZWay-Server zu untersuchen. Weiteres siehe: (https://forum.fhem.de/index.php?topic=88585.msg820029#msg820029). (http://(https://forum.fhem.de/index.php?topic=88585.msg820029#msg820029).)
Peter
Was mir dabei einfällt: usb-auto-standby?
@wernie ich wüsste jetzt nicht wie man bei dem usb to serial powersave ein bzw. ausschalten kann. Bei HDD oder WiFI ist das ja alles kein thema.
Habe es einmal gecheckt:
cat /sys/bus/usb/devices/1-1.3/power/control (die device id 1-1.3 ist natürlich nur bei mir so)
da steht ON und auch nicht auto, ist also somit ausgeschlossen.
@Peter das ist jetzt schade, hätte uns vermutlich ein stück weiter gebracht.
Habe mir auch schon die Änderungen der Dateien angesehen, und muss hier Rudolf zustimmen, da würde ich auch nicht dran glauben, das einzige was mir dabei ins Auge gestochen ist, die Erweiterung aus dem thread:
https://forum.fhem.de/index.php/topic,79893
Ich habe Dongle Firmware 5.07 SDK 6.51 (jedenfalls unter 6.7)
Vieleicht gibt es eine gemeinsamkeit eines speziellen Device typs, der das ganze vieleicht auslöst.
Ich habe z.b. folgendes im Einsatz:
FIBARO System FGK101 Door Opening Sensor
FIBARO System FGMS001 Motion Sensor
Aeotec ZW096 Smart Switch 6
FIBARO System FGSD002 Smoke Sensor
D-Link Corporation DCH-Z120 PIR/Motion 3 in 1 sensor
Popp KFOB-C Remote Control
D-Link Corporation DCH-Z510 Siren
FIBARO System FGPB101 Button
Philio Technology Corporation PH-PAT02.eu Flood Multisensor 3in1
Auffällig war meist bei Türöffnung das dies im Fhem angekommen ist, aber wenn ich wieder geschlossen habe, war es bereits tot. Kann natürlich zufall sein, da auch hier die warscheinlichkeit höher ist aufgrund der menge an devices.
Jetzt wird es immer verrückter, ich habe heute apt-get update und upgrade durchgeführt.
Nach reboot hat einmal tür auf/zu funktioniert. nach gut 1-2 Stunden reagierte es schon nicht mehr. Wohlgemerkt mit den PM Modulen von 2017 die bei mir jetzt lange funktioniert hatten.
Ich klammere mich jetzt wieder an das Timing Thema fest "Strohhalm lässt grüßen"
oder vieleicht liegt es am Treiber cdc_acm selbst ?
daraufhin gefrustet habe ich wieder den Versuch gestartet meinen UZB1 die neueste Firmware 5.27 zu verpassen. Nach unzähligen gescheiterten versuchen mit zwave.me z-way-server hat endlich das beta image "razberry-2.3.8-wifi_stretch.img.zip" funktioniert und der Stick meldet sich jetzt auch in Fhem mit version Z-Wave 4.61. Vieleicht hilft das ja.
wenn nicht, kann es sein das vieleicht irgend etwas anderes im Linux auf den Stick zugreift ? Wie kann man das rausfinden was alles darauf zugreift ?
Ich kann zwar keine Lösung bieten, bin/war aber auch betroffen.
Raspi 2, Jessie, UZB1. Der UZB1 übrigens über Verlängerung/ohne Hub angeschlossen.
Ich mache regelmäßig Updates von OS, fhem.
Meine Beobachtungen:
Tritt ohne festes Muster auf, kürzeste Zeit war 3 Stunden. Hat aber auch schon mal einen Monat durchgehalten.
Ein "Shutdown -r" behob das Problem nicht. Wenn schon dann Raspi stromlos machen.
Ein "reopen" alleine ist merkwürdigerweise dagegen völlig ausreichend.
Ich habe meinen Workaround Anfang Februar implementiert.
Der Workaround:
ich frage bei zwei Greenwave Zwischensteckern minütlich den Status ab (get swbstatus). Die Dinger melden ja bei manueller Betätigung des Tasters den Status sowieso nicht zurück.
Sollte nach drei Versuchen keine positive Rückmeldung kommen, würde ein reopen des Dongles ausgeführt.
Bei zwei Steckern deshalb: Die beiden sind an unterschiedlichen Orten. Das jemand beide gleichzeitig rauszieht ist eher unwahrscheinlich.
Ich hatte den Workaround natürlich auch getestet. Es wurde bisher nicht ein Mal ein reopen ausgeführt (was zusätzlich eine Push Nachricht bringen würde)
Vielleicht noch ein Grund warum die meisten das Problem nicht haben/auffällt:
Ich bin eher der "Sensor-Typ", 10 Fensterkontakten und drei Rauchmeldern stehen drei Zwischenstecker gegenüber. Und diese werden auch ganz selten geschaltet.
Ob es da einen Zusammenhang gibt weiß ich nicht:
Das hat bei mir im August 2016 während eines Urlaubs angefangen. Daher auch der Hinweis, dass ein Reboot per OS nichts bringt.
Dann noch mal ca. drei Monate später.
Zu dem Zeitpunkt waren noch die ersten zwei verbauten Fenster-Sensoren mit Verschlüsselung inkludiert. Bei beiden Sensoren waren danach immer die Batterien leer!
Ich die beiden dann noch mal neu ohne Verschlüsselung inkludiert. Danach war erst mal eine ganze Weile Ruhe.
Moin,
weil das Problem immer seltener aufgetreten war, hatte ich das "at" auf ein 2h Intervall gesetzt.
Nachdem das Problem dann vorgestern wieder aufgetreten ist, habe ich wieder das 1h-Intervall genommen.
Aber gestern hat selbst das nicht mehr ausgereicht. (Ich merke das, wenn die Rollos nicht mehr runtergehen, weil der Multisensor > 5Lux meldet).
Hat noch jemand weiter geforscht oder einen Lösungsansatz gefunden ?
Ich muss dazu sagen, ich habe diese Woche ein neues ZWave-Device (Neo Coolcam Wallplug) hinzugefügt..... (dieses funktioniert allerdings tadellos)
wie ich oben schon schrieb, macht mal update auf den UZB1 auf Version 5.27. Das war bei mir die Lösung scheinbar. wenn auch nicht genau reproduzierbar.
Hallo,
ich bin ein völliger Anfänger was das Thema FHEM betrifft, möchte aber trotzdem in dem Zusammenhang meine Beobachtungen posten.
Ich habe den Effekt auch, allerdings relativ selten. FHEM läuft mit einem ZME_UZB1 - die Readings sagen Vers:5 Rev:5, Z-Wave 4.05 STATIC_CONTROLLER - auf einem PC unter opensuse Linux. Auf der Maschine laufen noch einige virtuelle Maschinen. Die Effekte sind Juni 2017 das erste Mal aufgetreten oder zumindest bemerkt worden. Ich habe noch einen potentiellen Ausfall Ende April entdeckt, bin mir aber da nicht sicher ob es um das gleiche Problem geht.
Ich behebe das mit einem 'get ZWDongle nodeList' alle 24h. Darauf bin ich nur per Zufall gestoßen, ich wollte einfach mal die List sehen und plötzlich ging es wieder. Meine erste Vermutung war, dass ich einfach Quatsch in meine Konfiguration gebaut habe, allerdings läuft alles auch mal tagelang ohne Probleme, auch mit vielen Tests.
Meine aktuelle Vermutung ist, dass es sich um Timing Probleme handelt.
Grund: Ein längerer Ausfall hing zusammen mit dem 'Absturz' des Dongle hinter meinen 'Server Schrank'. Die Antenne lag also zwischen Rechnern, WLAN Sender, DSL Modem, Powerlan etc.. Es traten vermehrt Wiederholungen/NoACK auf, Telegramme haben sich überholt, ..., irgendwann war Schluss. Ein anderer Ausfall war zeitgleich mit einer Häufung von DSL Abbrüchen in deren Umfang der Rechner und die virtuellen Maschinen auf neue IP Adressen warteten und bei Erhalt alle möglichen Aktivitäten starteten. Der Rechner lief also unter hoher Last und hat möglicherweise Telegramme verschluckt. Es traten vermehrt Wiederholungen/NoACK auf, Telegramme haben sich überholt, ...
Seit die Antenne an einem guten Platz ist und die Netzwerkverbindung stabil ist läuft auch FHEM mit ZWave ordentlich. Den get nodelist alle 24h habe ich noch drin.
Zitat von: laserrichi am 28 September 2018, 14:23:13
wie ich oben schon schrieb, macht mal update auf den UZB1 auf Version 5.27. Das war bei mir die Lösung scheinbar. wenn auch nicht genau reproduzierbar.
wie kann ich das update durchführen?
Zitat von: laserrichi am 28 September 2018, 14:23:13
wie ich oben schon schrieb, macht mal update auf den UZB1 auf Version 5.27. Das war bei mir die Lösung scheinbar. wenn auch nicht genau reproduzierbar.
wo kann ich in fhem die Version meines Dongles einsehen und wie kann ich das Update durchführen?
die Version steht in den readings bei caps gleich als erstes. z.b. Vers:5 Rev:27
update geht nur mittels ZwaveMe
Ich habe. Nun irgendwas im Z-Wave Server mit dem Stick gemacht und jetzt läuft er in fhem gut.
jetzt zeigt er auch die Version an
Z-Wave 4.61 STATIC_CONTROLLER
gibt es eine neuere? Was sind die Unterschiede?
ZitatZ-Wave 4.61 STATIC_CONTROLLER
Das ist nur die SDK Version und nicht die Firmwareversion. Die Firmwareversion kann man dort nachsehen, wo "laserrichi" Dir schrieb.
Zitatgibt es eine neuere? Was sind die Unterschiede?
https://z-wave.me/support/uzbrazberry-firmwares/
Gruß, Christian
Da habe ich
Vers:5 Rev:25 ManufID:0115
Wisst ihr was diese Funktion Z-Wave Smart Start ist? Die kam wohl mit der 5.27
https://www.silabs.com/documents/login/white-papers/introduction_to_z-wave_smartstart_091317.pdf
FHEM kann es nicht. Mir ist auch kein anderes Programm bekannt, dass das beherrscht.
soweit ich das jetzt vernommen habe ist die Firmware Version: "5.32: Updated SDK to 6.81. Support of Z-Wave «SmartStart»" nur für den 700er Chipsatz möglich.
Aber da gibt es ja leider noch nichts. Weder einen UZB Dongle noch irgendwelche Geräte.
Zitat von: laserrichi am 10 Januar 2019, 18:56:25
soweit ich das jetzt vernommen habe ist die Firmware Version: "5.32: Updated SDK to 6.81. Support of Z-Wave «SmartStart»" nur für den 700er Chipsatz möglich.
Aber da gibt es ja leider noch nichts. Weder einen UZB Dongle noch irgendwelche Geräte.
Hast Du dazu eine Quelle/Link?
Alle in https://products.z-wavealliance.org/Search/DoAdvancedSearch?productName=&productIdentifier=&productDescription=&category=-1&manufacturer=-1®ionId=1&zwavePlusOnly=on&supportsS2=on&supportsSmartStart=on&order= gelisteten Produkte mit SmartStart-Unterstützung beruhen afaik auf 500er Chipsätzen.
Gruß, Christian
Hallo Christian,
hab ich leider keinen Link, ich habe das in einem zwave forum gelesen das die 5.32 Firmware nicht für den 500er (UZB1) ist. Die Doku war und ist ja auch mehr als spärlich, ich finde es auch selbst nicht mehr.
Hallo
Ich habe seit neusten auch das Problem das sich der ZME_UZB1 aufhängt bzw. keine Daten mehr empfängt. Wenn ich dann ein get device model mache läuft er wieder für eine gewisse Zeit.
System
Raspi 3, Stretch , ZME_UZB1 an USB Verlängerung
Lasse nun mal ein Verbose 5 mitlaufen in der Hoffnung das man dort was sieht beim nächsten hänger.
Mir ist dieses Verhalten vorher nie aufgefallen erst seit dem ich ein Fibaro Binary Sensor mit zwei Temp-Sensoren inkludiert habe, der permanent Daten schickt.
Kann dieser evtl. das Problem sein?
@laserrichi Hast du evtl ein guten Howto zum Dongel Update?
Gruß Alex
Da es mit dem beitrag nicht klappt obwohl die Vorschau ok ist. Hänge ich die Logs als Text-Datei an.
log.txt = Verbose 5 log ist zum hänger um 16:05:47
Anschließend ca. 16:20 Uhr ein get AZ_Jalousie model was mit dem Fehler "Timeout reading answer for model" quittiert wurde.
Danach sofort noch einmal ein get AZ_Jalousie model und das Model wurde angezeigt und Werte der Sensoren kommen wieder rein.
log2.txt = das weiterlaufende verbose 5 log nach dem Fehler.
Hoffe man kann etwas finden.
Gruß Alex
Zitat von: majestro84 am 25 Januar 2019, 15:49:35
Mir ist dieses Verhalten vorher nie aufgefallen erst seit dem ich ein Fibaro Binary Sensor mit zwei Temp-Sensoren inkludiert habe, der permanent Daten schickt.
Kann dieser evtl. das Problem sein?
@laserrichi Hast du evtl ein guten Howto zum Dongel Update?
Also ich habe Fibaro Fensterkontakte und pro Raum mind. einen mit Temperatursensor DS18B20, aber das kann es meiner meinung nicht sein, da sie ja nur bei Temperaturänderungen senden. Und auch erst ab einer gewissen Änderung.
Aber es ist nicht ausgeschlossen das vieleicht ein Gerät dafür sorgt das der Dongle hängt, aber das kann ich eigentlich auch dementieren, da bei mir das Problem wie von geisterhand aktuell verschwunden ist, und ich weder Geräte entfernt oder dazugenommen habe. Einzig updates im Linux und Fhem.
ein Howto für den Dongle Update habe ich leider nicht.
OK Linux und fhem sind auf aktuellen Stand nur mein ZME_uzb1 nicht der ist bei Vers:5 Rev:6.
Dann werde ich mich Mal am Wochenende dran setzten und den auf die aktuelle Firmware bringen vielleicht klappt dann alles wieder.
Hoi,
bezüglich Update:
Also man kann sich die Zwave.me Software runterladen für Windows , geht , aber teilweise braucht man mehrere Versuche und es ist sehr gewöhungsbedürftig.
Ich habe mir nun eine SDCard mit der Linux Version von Zwave.me gemacht fürn Raspi. Alte Raspis hab ich immer einen da, Karte rein, stick dran, oberfläche aufrufen und updaten. Geht idR damit gefühlt besser und klappte bisher immer bis zur letzten Version. Im Gegensatz bei der Windows Variante brauchte ich mehrfache Anläufe und manchmal ging es auch einfach nicht weiter, egal was man versucht hatte.
Ronny
Zitat von: rcmcronny am 25 Januar 2019, 22:15:46
Hoi,
bezüglich Update:
Also man kann sich die Zwave.me Software runterladen für Windows , geht , aber teilweise braucht man mehrere Versuche und es ist sehr gewöhungsbedürftig.
Ich habe mir nun eine SDCard mit der Linux Version von Zwave.me gemacht fürn Raspi. Alte Raspis hab ich immer einen da, Karte rein, stick dran, oberfläche aufrufen und updaten. Geht idR damit gefühlt besser und klappte bisher immer bis zur letzten Version. Im Gegensatz bei der Windows Variante brauchte ich mehrfache Anläufe und manchmal ging es auch einfach nicht weiter, egal was man versucht hatte.
Ronny
Danke für die Info. Werde mir morgen dann Mal meinen alten Pi bemühen den Stick upzudaten.
Hallo, es gibt eine neue Version, 5.36 und ich habe sie mal installiert.
Krikan du hast recht die höhere SDK Version geht in den 500er chipsatz rein, vermutlich war das was ich gelesen hatte nur ein z-way internes Thema, aber die kommen ja sowieso nie aus dem Beta heraus. ;D Jetzt hab ich SDK 6.81.01 und meldet sich im Fhem mit 6.02
Und ich habe eine Anleitung geschrieben wie man das durchführt
https://forum.fhem.de/index.php/topic,96563.0.html (https://forum.fhem.de/index.php/topic,96563.0.html)
Zitat von: laserrichi am 27 Januar 2019, 11:59:14
Hallo, es gibt eine neue Version, 5.36 und ich habe sie mal installiert.
Krikan du hast recht die höhere SDK Version geht in den 500er chipsatz rein, vermutlich war das was ich gelesen hatte nur ein z-way internes Thema, aber die kommen ja sowieso nie aus dem Beta heraus. ;D Jetzt hab ich SDK 6.81.01 und meldet sich im Fhem mit 6.02
Und ich habe eine Anleitung geschrieben wie man das durchführt
https://forum.fhem.de/index.php/topic,96563.0.html (https://forum.fhem.de/index.php/topic,96563.0.html)
Vielen Dank für deine HowTo.
Bin heute endlich mal dazu gekommen den Dongle upzugraden. Hat super funktioniert mit deiner Anleitung.
Jetzt hoffe ich mal das die hänger weg bleiben
Gruß Alex
Super, dann bin ich ja mal gespannt auf das Ergebnis.
Gibt's ein Changelog zu dem Zwave-Stick-Update ?
Changelog findest du zum Dongle hier.
https://z-wave.me/support/uzbrazberry-firmwares/
Nach gut 24 h Betrieb nach dem Update kein hängen bleiben mehr des Dongles. Firmware-Update scheint das Problem zu lösen
War nach dem FW Update ein Backuprestore notwendig ?
Laserrichi hatte in seinem Thread geschrieben, dass ein restore in FHEM nur bei gleichem FW Stand möglich ist.
Oder ist eine Steuerung direkt nach dem FW Upgrade via FHEM wieder möglich ?
Zitat von: DerBodo am 30 Januar 2019, 07:50:36
War nach dem FW Update ein Backuprestore notwendig ?
Laserrichi hatte in seinem Thread geschrieben, dass ein restore in FHEM nur bei gleichem FW Stand möglich ist.
Oder ist eine Steuerung direkt nach dem FW Upgrade via FHEM wieder möglich ?
Bisher funktionierte hier nach Updates alles direkt wieder wie gewohnt ohne irgendwelche restore.
Dennoch schadet ein backupCreate vorher nicht. :)
Gruß, Christian
Bei mir hat die Steuerung sofort nach dem Start des Fhem Servers funktioniert.
das Backup dient zur Sicherheit, normal sollten alle Geräte dem Stick dann noch bekannt sein, aber Backups macht man ja so ungern ;-)
Ich habe z.b. 2 Sticks mit gleicher homeId, und bin somit Backupfähig bei hardwaredefekt durch zurückspielen des Files auf den 2ten Stick.
Man kann aber auch in z-way ein Backup und restore machen, hab ich aber noch nicht probiert.
@majestro84 schön das es jetzt wohl stabil läuft, ist wirklich interessant, da wir hier ja sehr lange im dunkeln standen wo der Hund begraben liegt.
Ja hätte ich so auch nicht erwartet aber seit dem läuft es wieder ohne Probleme und Abstürze bis jetzt
Ich hab die FW des ZWave-Dongle vor einer Woche aktualisiert, seitdem keine "Ausfälle" mehr mit dem Multisensor, läuft bist jetzt perfekt
Der Fehler liegt ganz klar in der Firmware. Noch Update läuft es bei mir auch endlich wieder zuverlässig. Nochmal vielen Dank für die super Anleitung um die Firmware zu updaten.
Ich habe leider gefüllt nach dem Update des Dongles das Problem das die Fibaro Roller Shutter nicht regelmäßig ihre Position raus geben. Normal war es so das nach der Fahrt das Reading Position aktualisiert wurde das ist jetzt nicht immer mehr der Fall. Mache ich ein get Position geht es. Habt ihr auch solche Probleme? Habe schon einige Sachen ausgeschlossen so langsam fällt mir nichts mehr ein.
Gruß Alex
Zitat von: majestro84 am 25 April 2019, 10:47:52
Ich habe leider gefüllt nach dem Update des Dongles das Problem das die Fibaro Roller Shutter nicht regelmäßig ihre Position raus geben. Normal war es so das nach der Fahrt das Reading Position aktualisiert wurde das ist jetzt nicht immer mehr der Fall. Mache ich ein get Position geht es. Habt ihr auch solche Probleme? Habe schon einige Sachen ausgeschlossen so langsam fällt mir nichts mehr ein.
Gruß Alex
Meine FGRM222 haben solche Merkwürdigkeiten nicht; bin aber erst bei Firmware 5.27 und nicht bei der aktuellsten 5.32.
OK gut zu wissen. Dann werde ich mir Mal einen anderen Dongle besorgen und auf die entsprechende Firmware gehen und gucken. Oder gibt es eine Möglichkeit eines Dongle downgrades?
Ich habe bei mir nun seit ca 1 bis 2 Wochen auch das Problem, dass die Z-Wave Bewegungsmelder (Fibaro Motion Eyes) immer wieder nicht mehr empfangen werden.
Nach FHEM-Neustart oder selbst ein "set ZWDongle_0 reopen" hilft. Aber leider nicht dauerhaft. Mal funktioniert es einen Tag lang, mal werden Bewegungen nach nicht mal eine Stunde wieder nicht mehr erkannt.
Gestern hab ich extra auf einer zweiten SD-Karte ZWay installiert um dem Stick ein Firmwareupdate zu verpassen.
Fhem zeigt mir dennoch als Version des Sticks nur "Z-Wave 4.38 STATIC_CONTROLLER" an (vorher 3.99)
Unter CAPS steht "Vers:5 Rev:7".
Leider hat aber auch das Update der Firmware keine Änderung gebracht. Was kann ich noch tun? Am Z-Wave Netzwerk wurde nichts geändert.
Zitat von: swsmily am 15 September 2019, 20:49:21
Fhem zeigt mir dennoch als Version des Sticks nur "Z-Wave 4.38 STATIC_CONTROLLER" an (vorher 3.99)
Unter CAPS steht "Vers:5 Rev:7".
Firmwareversion 5.7 ist schon "leicht" alt (https://z-wave.me/support/uzbrazberry-firmwares/). Probiere mal ein update auf eine halbwegs aktuelle Version. Nach meiner Erfahrung muss man mehrere Firmwareupdates durchführen, um eine halbwegs aktuelle Version zu bekommen. Das update geht nur schrittweise und nicht automatisch auf die höchste Version.
Gruß, Christian
Zitat von: krikan am 16 September 2019, 08:19:11
Firmwareversion 5.7 ist schon "leicht" alt (https://z-wave.me/support/uzbrazberry-firmwares/). Probiere mal ein update auf eine halbwegs aktuelle Version. Nach meiner Erfahrung muss man mehrere Firmwareupdates durchführen, um eine halbwegs aktuelle Version zu bekommen. Das update geht nur schrittweise und nicht automatisch auf die höchste Version.
Gruß, Christian
Das verstehe ich nun nicht. Auf der verlinkten Seite steht nur was von 5.37.
In ZWay wurden mir nach mehreren Versuchen keine neuen Firmware-Versionen mehr angezeigt.
Du hast laut FHEM-Ausgabe 5.07 (nicht 5.7, sorry) mit SDK 6.51.09
Gruß, Christian
Also sollte ich mit zway nochmal schauen, ob es mir nun weitere Updates anzeigt? Ich konnte bei dem updaten nur 2 mal auswählen. Danach stand immer da, dass der Stick auf dem aktuellsten Stand sei.
Zitat von: swsmily am 16 September 2019, 12:30:03
Also sollte ich mit zway nochmal schauen, ob es mir nun weitere Updates anzeigt?
Wenn das aktuelle Reading CAPS weiterhin die genannte Info liefert: Ja.
Ich bekomme weiterhin nur die Meldung:
Your stick uses the latest firmware
Ich musste abwechselnd Firmware _und_ Bootloader mehrmals updaten, um auf den atuellen Stand zu kommen.
Ist aber laenger her, weiss nicht, ob das immer noch der Fall ist.
Ich hab nun die SD-Karte nochmal komplett neu aufgesetzt, ZWay neu installiert. Dennoch zeigt mir die Firmware-Update Seite nur diese Meldung " Your stick uses the latest firmware". Es wird kein Bootloaderupdate oder Firmwareupdate angezeigt.
Hab auch das Updatetool probiert, aber regelmäßig hat es Fehler gebracht. Damit versuche ich es lieber nicht weiter, nicht dass ich den Stick noch schrotte :D
Ich hatte das gleiche Problem vor kurzem. Ich glaube, man muss "all" als Code eingeben. Dann kommen weitere Updates. Grund dürfte eine inkompatibilität zu bestimmter Hardware sein. Blau oder grüner CUL? Bitte vor dem Flashen noch googeln. Z-Wave USB Stick ZMEUZB dürfte ok sein. Ich hatte kein Problem.
Ich kam nun wieder dazu nochmal zu testen. Der Tipp mit dem "all" hat sehr geholfen. Im Feld Tocken hab ich all eingegeben und es wurden mir weitere Updates angezeigt.
Laut FHEM hab ich nun Version Z-Wave 6.02 STATIC_CONTROLLER und unter caps Vers:5 Rev:36. Das sollte nun die aktuellste Version sein oder?
Ja ich habe auch die Vers:5 Rev:36
Vielen Dank an alle für die Unterstützung!
Zitat von: tux75at am 17 September 2019, 07:21:51
Ich glaube, man muss "all" als Code eingeben.
wo genau in Z-way kann/muss man das eingeben ?
In dem Feld wo man einen Token eingeben könnte