FHEM reagiert nach einer weile nicht mehr auf Z-Wave Sensoren

Begonnen von laserrichi, 15 Mai 2018, 11:27:19

Vorheriges Thema - Nächstes Thema

laserrichi

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.
RaspberryPi 4 Bullseye,Homematic,Z-Wave,Rademacher Duofern,Signalduino,Fritz7590,ESPEasy,Tasmota,Robonect,Kameras,1-Wire,Modbus,Solar,Maranz,VU+,ulanzi tc001 mit awtrix light

fritzhugo123

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.

krikan

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

laserrichi

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.
RaspberryPi 4 Bullseye,Homematic,Z-Wave,Rademacher Duofern,Signalduino,Fritz7590,ESPEasy,Tasmota,Robonect,Kameras,1-Wire,Modbus,Solar,Maranz,VU+,ulanzi tc001 mit awtrix light

krikan

Kannst Du bitte schreiben, welche alten Modulversionen Du jetzt einsetzt?
Ausgabe von
version ZW
Danke.

fritzhugo123

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.

krikan

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?

laserrichi

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
RaspberryPi 4 Bullseye,Homematic,Z-Wave,Rademacher Duofern,Signalduino,Fritz7590,ESPEasy,Tasmota,Robonect,Kameras,1-Wire,Modbus,Solar,Maranz,VU+,ulanzi tc001 mit awtrix light

fritzhugo123

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.

krikan

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?

fritzhugo123

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.

krikan

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?

fritzhugo123

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

fritzhugo123

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.

Wernieman

Nur mal so als Idee ... wie ist der "Stromsparmodus" im USB-Bereich eingestellt?
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

laserrichi

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


RaspberryPi 4 Bullseye,Homematic,Z-Wave,Rademacher Duofern,Signalduino,Fritz7590,ESPEasy,Tasmota,Robonect,Kameras,1-Wire,Modbus,Solar,Maranz,VU+,ulanzi tc001 mit awtrix light

laserrichi

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.
RaspberryPi 4 Bullseye,Homematic,Z-Wave,Rademacher Duofern,Signalduino,Fritz7590,ESPEasy,Tasmota,Robonect,Kameras,1-Wire,Modbus,Solar,Maranz,VU+,ulanzi tc001 mit awtrix light

gotocu

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!

rudolfkoenig

Damit wir das Problem lokalisieren koennen: Kann bitte jeder mit dem Problem die genaue Hardware und OS Version nennen?

laserrichi

#19
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


RaspberryPi 4 Bullseye,Homematic,Z-Wave,Rademacher Duofern,Signalduino,Fritz7590,ESPEasy,Tasmota,Robonect,Kameras,1-Wire,Modbus,Solar,Maranz,VU+,ulanzi tc001 mit awtrix light

Bartimaus

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.

LG
B.


FHEM@Intel-J4105@Debian-LXC, CUL1101,FS20,IT,DS18B20,DS2413(Heizungslogger),DS2423(Stromlogger)Homematic,HM-LAN,ZWave,MiniCULs,Shelly

rudolfkoenig

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.

Bartimaus

#22
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

LG
B.


FHEM@Intel-J4105@Debian-LXC, CUL1101,FS20,IT,DS18B20,DS2413(Heizungslogger),DS2423(Stromlogger)Homematic,HM-LAN,ZWave,MiniCULs,Shelly

rudolfkoenig

Nur um es klarzustellen: mir reicht sowas wie "RPi v3, Debian Stretch, ZWave.me USB"

laserrichi

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 ?
RaspberryPi 4 Bullseye,Homematic,Z-Wave,Rademacher Duofern,Signalduino,Fritz7590,ESPEasy,Tasmota,Robonect,Kameras,1-Wire,Modbus,Solar,Maranz,VU+,ulanzi tc001 mit awtrix light

rudolfkoenig

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.

laserrichi

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 ?
RaspberryPi 4 Bullseye,Homematic,Z-Wave,Rademacher Duofern,Signalduino,Fritz7590,ESPEasy,Tasmota,Robonect,Kameras,1-Wire,Modbus,Solar,Maranz,VU+,ulanzi tc001 mit awtrix light

rudolfkoenig

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.

gotocu

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.

laserrichi

update: mit den alten Modulen von 2017 wie ich oben geschrieben habe, läuft es bisher stabil.
RaspberryPi 4 Bullseye,Homematic,Z-Wave,Rademacher Duofern,Signalduino,Fritz7590,ESPEasy,Tasmota,Robonect,Kameras,1-Wire,Modbus,Solar,Maranz,VU+,ulanzi tc001 mit awtrix light

Bartimaus

Ich rufe per at stündlich ein "get ZWDongle_1 homeId" auf, hilft auch, ist aber nicht "schön"
LG
B.


FHEM@Intel-J4105@Debian-LXC, CUL1101,FS20,IT,DS18B20,DS2413(Heizungslogger),DS2423(Stromlogger)Homematic,HM-LAN,ZWave,MiniCULs,Shelly

laserrichi

zack, jetzt ist es wieder aufgetreten, aber mit den alten modulversionen läuft es reproduzierbar definitiv länger bis das Problem wieder auftritt.
RaspberryPi 4 Bullseye,Homematic,Z-Wave,Rademacher Duofern,Signalduino,Fritz7590,ESPEasy,Tasmota,Robonect,Kameras,1-Wire,Modbus,Solar,Maranz,VU+,ulanzi tc001 mit awtrix light

Firefield

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.
Gigabyte GB-BACE-3150, 8GB RAM, 120GB SSD, Proxmox mit FHEM-VM und DB-VM| (ab und an aktuelles) FHEM mit ConfigDB+LogDB. MariaDB + phpmyadmin. | Zwave.me USB dongle, Jeelink, HM, BTLE und HUEbridge.

laserrichi

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 ?
RaspberryPi 4 Bullseye,Homematic,Z-Wave,Rademacher Duofern,Signalduino,Fritz7590,ESPEasy,Tasmota,Robonect,Kameras,1-Wire,Modbus,Solar,Maranz,VU+,ulanzi tc001 mit awtrix light

rudolfkoenig

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.

gotocu

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...

gotocu

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.

PNinBB

Ich habe den gleichen Effekt und auch schon vor Wochen ein extra Thema aufgemacht (https://forum.fhem.de/index.php?topic=88585.msg820029#msg820029).
Vielleicht kan man irgendwie zusammenwirken.
Peter
Raspi 4B + RaZberry2 (Deb 10), FritzBox 7490;
AEOTec: KeyFobGen5: 1x;
Danfoss: Living Connect 2.51: 3x;
Fibaro: FGK: 10x: 3x; FGBS: 001: 8x, 222: 1x; FGMS001: 2x; FGR: 222: 3x, 223: 2x; FGRGBWM-441: 1x; FGBS: 222: 2x, 223: 2x,224: 1x;
Philio: PAN06-1A: 3x;

laserrichi

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.
RaspberryPi 4 Bullseye,Homematic,Z-Wave,Rademacher Duofern,Signalduino,Fritz7590,ESPEasy,Tasmota,Robonect,Kameras,1-Wire,Modbus,Solar,Maranz,VU+,ulanzi tc001 mit awtrix light

PNinBB

@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
Raspi 4B + RaZberry2 (Deb 10), FritzBox 7490;
AEOTec: KeyFobGen5: 1x;
Danfoss: Living Connect 2.51: 3x;
Fibaro: FGK: 10x: 3x; FGBS: 001: 8x, 222: 1x; FGMS001: 2x; FGR: 222: 3x, 223: 2x; FGRGBWM-441: 1x; FGBS: 222: 2x, 223: 2x,224: 1x;
Philio: PAN06-1A: 3x;

laserrichi

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
RaspberryPi 4 Bullseye,Homematic,Z-Wave,Rademacher Duofern,Signalduino,Fritz7590,ESPEasy,Tasmota,Robonect,Kameras,1-Wire,Modbus,Solar,Maranz,VU+,ulanzi tc001 mit awtrix light

Bartimaus

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")
LG
B.


FHEM@Intel-J4105@Debian-LXC, CUL1101,FS20,IT,DS18B20,DS2413(Heizungslogger),DS2423(Stromlogger)Homematic,HM-LAN,ZWave,MiniCULs,Shelly

PNinBB

@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).
Peter
Raspi 4B + RaZberry2 (Deb 10), FritzBox 7490;
AEOTec: KeyFobGen5: 1x;
Danfoss: Living Connect 2.51: 3x;
Fibaro: FGK: 10x: 3x; FGBS: 001: 8x, 222: 1x; FGMS001: 2x; FGR: 222: 3x, 223: 2x; FGRGBWM-441: 1x; FGBS: 222: 2x, 223: 2x,224: 1x;
Philio: PAN06-1A: 3x;

Wernieman

- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

laserrichi

#44
@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.

RaspberryPi 4 Bullseye,Homematic,Z-Wave,Rademacher Duofern,Signalduino,Fritz7590,ESPEasy,Tasmota,Robonect,Kameras,1-Wire,Modbus,Solar,Maranz,VU+,ulanzi tc001 mit awtrix light

laserrichi

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 ?


RaspberryPi 4 Bullseye,Homematic,Z-Wave,Rademacher Duofern,Signalduino,Fritz7590,ESPEasy,Tasmota,Robonect,Kameras,1-Wire,Modbus,Solar,Maranz,VU+,ulanzi tc001 mit awtrix light

Buwe

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.

Bartimaus

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)
LG
B.


FHEM@Intel-J4105@Debian-LXC, CUL1101,FS20,IT,DS18B20,DS2413(Heizungslogger),DS2423(Stromlogger)Homematic,HM-LAN,ZWave,MiniCULs,Shelly

laserrichi

#48
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.
RaspberryPi 4 Bullseye,Homematic,Z-Wave,Rademacher Duofern,Signalduino,Fritz7590,ESPEasy,Tasmota,Robonect,Kameras,1-Wire,Modbus,Solar,Maranz,VU+,ulanzi tc001 mit awtrix light

thewolfman

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.

flipse

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?

flipse

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?

laserrichi

die Version steht in den readings bei caps gleich als erstes. z.b. Vers:5 Rev:27
update geht nur mittels ZwaveMe
RaspberryPi 4 Bullseye,Homematic,Z-Wave,Rademacher Duofern,Signalduino,Fritz7590,ESPEasy,Tasmota,Robonect,Kameras,1-Wire,Modbus,Solar,Maranz,VU+,ulanzi tc001 mit awtrix light

flipse

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?

krikan

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

flipse

#55
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

krikan


laserrichi

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.
RaspberryPi 4 Bullseye,Homematic,Z-Wave,Rademacher Duofern,Signalduino,Fritz7590,ESPEasy,Tasmota,Robonect,Kameras,1-Wire,Modbus,Solar,Maranz,VU+,ulanzi tc001 mit awtrix light

krikan

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&regionId=1&zwavePlusOnly=on&supportsS2=on&supportsSmartStart=on&order= gelisteten Produkte mit SmartStart-Unterstützung beruhen afaik auf 500er Chipsätzen.

Gruß, Christian

laserrichi

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.






RaspberryPi 4 Bullseye,Homematic,Z-Wave,Rademacher Duofern,Signalduino,Fritz7590,ESPEasy,Tasmota,Robonect,Kameras,1-Wire,Modbus,Solar,Maranz,VU+,ulanzi tc001 mit awtrix light

majestro84

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
Server: Fujitsu ESPRIMO Q920 - aktuellen FHEM-Docker Image:Z-Wave (RollerShutter,DoorWindow,Socket,PIR,....) | ENIGMA2 | EGPM2LAN | BLE-Tag(PRESENCE) | HUE | alexa-fhem | Shelly | MQTT2
1.Pi-Zero:Viessmann(optolink) mit 89_VCONTROL300.pm
2.Pi3 Dongle Server: Zigbee2MQTT(CC1352P-2), Z-Wave(UZB1), BT

majestro84

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
Server: Fujitsu ESPRIMO Q920 - aktuellen FHEM-Docker Image:Z-Wave (RollerShutter,DoorWindow,Socket,PIR,....) | ENIGMA2 | EGPM2LAN | BLE-Tag(PRESENCE) | HUE | alexa-fhem | Shelly | MQTT2
1.Pi-Zero:Viessmann(optolink) mit 89_VCONTROL300.pm
2.Pi3 Dongle Server: Zigbee2MQTT(CC1352P-2), Z-Wave(UZB1), BT

laserrichi

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.
RaspberryPi 4 Bullseye,Homematic,Z-Wave,Rademacher Duofern,Signalduino,Fritz7590,ESPEasy,Tasmota,Robonect,Kameras,1-Wire,Modbus,Solar,Maranz,VU+,ulanzi tc001 mit awtrix light

majestro84

#63
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.
Server: Fujitsu ESPRIMO Q920 - aktuellen FHEM-Docker Image:Z-Wave (RollerShutter,DoorWindow,Socket,PIR,....) | ENIGMA2 | EGPM2LAN | BLE-Tag(PRESENCE) | HUE | alexa-fhem | Shelly | MQTT2
1.Pi-Zero:Viessmann(optolink) mit 89_VCONTROL300.pm
2.Pi3 Dongle Server: Zigbee2MQTT(CC1352P-2), Z-Wave(UZB1), BT

rcmcronny

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

majestro84

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.
Server: Fujitsu ESPRIMO Q920 - aktuellen FHEM-Docker Image:Z-Wave (RollerShutter,DoorWindow,Socket,PIR,....) | ENIGMA2 | EGPM2LAN | BLE-Tag(PRESENCE) | HUE | alexa-fhem | Shelly | MQTT2
1.Pi-Zero:Viessmann(optolink) mit 89_VCONTROL300.pm
2.Pi3 Dongle Server: Zigbee2MQTT(CC1352P-2), Z-Wave(UZB1), BT

laserrichi

#66
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
RaspberryPi 4 Bullseye,Homematic,Z-Wave,Rademacher Duofern,Signalduino,Fritz7590,ESPEasy,Tasmota,Robonect,Kameras,1-Wire,Modbus,Solar,Maranz,VU+,ulanzi tc001 mit awtrix light

majestro84

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

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
Server: Fujitsu ESPRIMO Q920 - aktuellen FHEM-Docker Image:Z-Wave (RollerShutter,DoorWindow,Socket,PIR,....) | ENIGMA2 | EGPM2LAN | BLE-Tag(PRESENCE) | HUE | alexa-fhem | Shelly | MQTT2
1.Pi-Zero:Viessmann(optolink) mit 89_VCONTROL300.pm
2.Pi3 Dongle Server: Zigbee2MQTT(CC1352P-2), Z-Wave(UZB1), BT

laserrichi

Super, dann bin ich ja mal gespannt auf das Ergebnis.
RaspberryPi 4 Bullseye,Homematic,Z-Wave,Rademacher Duofern,Signalduino,Fritz7590,ESPEasy,Tasmota,Robonect,Kameras,1-Wire,Modbus,Solar,Maranz,VU+,ulanzi tc001 mit awtrix light

Bartimaus

LG
B.


FHEM@Intel-J4105@Debian-LXC, CUL1101,FS20,IT,DS18B20,DS2413(Heizungslogger),DS2423(Stromlogger)Homematic,HM-LAN,ZWave,MiniCULs,Shelly

majestro84

Server: Fujitsu ESPRIMO Q920 - aktuellen FHEM-Docker Image:Z-Wave (RollerShutter,DoorWindow,Socket,PIR,....) | ENIGMA2 | EGPM2LAN | BLE-Tag(PRESENCE) | HUE | alexa-fhem | Shelly | MQTT2
1.Pi-Zero:Viessmann(optolink) mit 89_VCONTROL300.pm
2.Pi3 Dongle Server: Zigbee2MQTT(CC1352P-2), Z-Wave(UZB1), BT

majestro84

#71
Nach gut 24 h Betrieb nach dem Update kein hängen bleiben mehr des Dongles. Firmware-Update scheint das Problem zu lösen
Server: Fujitsu ESPRIMO Q920 - aktuellen FHEM-Docker Image:Z-Wave (RollerShutter,DoorWindow,Socket,PIR,....) | ENIGMA2 | EGPM2LAN | BLE-Tag(PRESENCE) | HUE | alexa-fhem | Shelly | MQTT2
1.Pi-Zero:Viessmann(optolink) mit 89_VCONTROL300.pm
2.Pi3 Dongle Server: Zigbee2MQTT(CC1352P-2), Z-Wave(UZB1), BT

DerBodo

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 ?

krikan

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

majestro84

Bei mir hat die Steuerung sofort nach dem Start des Fhem Servers funktioniert.
Server: Fujitsu ESPRIMO Q920 - aktuellen FHEM-Docker Image:Z-Wave (RollerShutter,DoorWindow,Socket,PIR,....) | ENIGMA2 | EGPM2LAN | BLE-Tag(PRESENCE) | HUE | alexa-fhem | Shelly | MQTT2
1.Pi-Zero:Viessmann(optolink) mit 89_VCONTROL300.pm
2.Pi3 Dongle Server: Zigbee2MQTT(CC1352P-2), Z-Wave(UZB1), BT

laserrichi

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.

RaspberryPi 4 Bullseye,Homematic,Z-Wave,Rademacher Duofern,Signalduino,Fritz7590,ESPEasy,Tasmota,Robonect,Kameras,1-Wire,Modbus,Solar,Maranz,VU+,ulanzi tc001 mit awtrix light

majestro84

Ja hätte ich so auch nicht erwartet aber seit dem läuft es wieder ohne Probleme und Abstürze bis jetzt
Server: Fujitsu ESPRIMO Q920 - aktuellen FHEM-Docker Image:Z-Wave (RollerShutter,DoorWindow,Socket,PIR,....) | ENIGMA2 | EGPM2LAN | BLE-Tag(PRESENCE) | HUE | alexa-fhem | Shelly | MQTT2
1.Pi-Zero:Viessmann(optolink) mit 89_VCONTROL300.pm
2.Pi3 Dongle Server: Zigbee2MQTT(CC1352P-2), Z-Wave(UZB1), BT

Bartimaus

Ich hab die FW des ZWave-Dongle vor einer Woche aktualisiert, seitdem keine "Ausfälle" mehr mit dem Multisensor, läuft bist jetzt perfekt
LG
B.


FHEM@Intel-J4105@Debian-LXC, CUL1101,FS20,IT,DS18B20,DS2413(Heizungslogger),DS2423(Stromlogger)Homematic,HM-LAN,ZWave,MiniCULs,Shelly

knoller

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.

majestro84

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
Server: Fujitsu ESPRIMO Q920 - aktuellen FHEM-Docker Image:Z-Wave (RollerShutter,DoorWindow,Socket,PIR,....) | ENIGMA2 | EGPM2LAN | BLE-Tag(PRESENCE) | HUE | alexa-fhem | Shelly | MQTT2
1.Pi-Zero:Viessmann(optolink) mit 89_VCONTROL300.pm
2.Pi3 Dongle Server: Zigbee2MQTT(CC1352P-2), Z-Wave(UZB1), BT

krikan

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.

majestro84

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?
Server: Fujitsu ESPRIMO Q920 - aktuellen FHEM-Docker Image:Z-Wave (RollerShutter,DoorWindow,Socket,PIR,....) | ENIGMA2 | EGPM2LAN | BLE-Tag(PRESENCE) | HUE | alexa-fhem | Shelly | MQTT2
1.Pi-Zero:Viessmann(optolink) mit 89_VCONTROL300.pm
2.Pi3 Dongle Server: Zigbee2MQTT(CC1352P-2), Z-Wave(UZB1), BT

swsmily

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.

krikan

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

swsmily

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.

krikan

Du hast laut FHEM-Ausgabe 5.07  (nicht 5.7, sorry) mit SDK 6.51.09

Gruß, Christian

swsmily

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.



krikan

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.

swsmily

Ich bekomme weiterhin nur die Meldung:
Your stick uses the latest firmware

rudolfkoenig

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.

swsmily

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

tux75at

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.

swsmily

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?


laserrichi

RaspberryPi 4 Bullseye,Homematic,Z-Wave,Rademacher Duofern,Signalduino,Fritz7590,ESPEasy,Tasmota,Robonect,Kameras,1-Wire,Modbus,Solar,Maranz,VU+,ulanzi tc001 mit awtrix light

swsmily


sz_wolfi

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 ?

swsmily