Autor Thema: Keine Event-Meldungen von ZWAVE-Sensoren  (Gelesen 2257 mal)

Offline laserrichi

  • Jr. Member
  • **
  • Beiträge: 85
Antw:Keine Event-Meldungen von ZWAVE-Sensoren
« Antwort #15 am: 26 Juli 2018, 18:02:58 »
Hallo Peter, ich sehe du hast auf deinem UZB1 die Vers:5 Rev:4
habe in meinen Thread gestern geschrieben das ich auf Vers:5 Rev:27   gegangen bin... bis jetzt läuft es bei mir auch mit den aktuellen modulen, vieleicht machst du auch einmal einen Firmware update auf den dongle.
Ich werde das nochmal gegenchecken da ich 2 UZB1 Dongle habe.

Der Watchdog is doch eigentlich nur im SoC (also stick) der sich selbst checkt und nach 1.05sec resettet wenn ich das richtig gelesen habe.

Offline PNinBB

  • Full Member
  • ***
  • Beiträge: 147
Antw:Keine Event-Meldungen von ZWAVE-Sensoren
« Antwort #16 am: 27 Juli 2018, 13:27:26 »
@laserrichi: Ich muss momentan mit dem Upgrade warten, da 'ZWave.me' momentan nicht vollständig auf 'Stretch' läuft; genauer: der Mongoose - Server lässt sich nicht starten. Das Problem ist bei ZWave.me bekannt, eine neue Version ist angekündigt, aber momentan ohne genauen Zeitpunkt. Deshalb schiebe ich es noch vor mir her.

Nun zum eigentlichen Problem:

1. Parameter des seriellem Interfaces:
Zitat
Auch wenn es vermutlich fuer dieses Problem nicht relevant ist: ich kenne setserial nicht, aber die angezeigten Daten sind mA nicht ausreichend. Ich empfehle stty -a < /dev/AMA0
Das habe ich während der unterschiedlichen Zustände ('tot' oder 'nicht tot') geprüft mit folgendem Ergebnis.
1. FHEM läuft:
root@PNinBBServer4 27.07.2018;08:24:23 ~ 4>stty -a < /dev/ttyAMA0
speed 115200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q;
stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 0; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread clocal -crtscts
ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke -flusho -extproc
root@PNinBBServer4 27.07.2018;08:24:40 ~ 5>
Dabei gab es keine Unterschiede zwischen 'tot' und (noch) nicht 'tot'.
2. ZWay-Server läuft:
root@PNinBBServer4 27.07.2018;10:52:48 / 48>stty -a < /dev/ttyAMA0
speed 115200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V;
discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke -flusho -extproc
root@PNinBBServer4 27.07.2018;10:52:51 / 49>
Vergleicht man beide Ausgaben, so zeigt sich folgendes Bild.
FHEM läuft:        min = 0; ignbrk -brkint -ignpar
ZWay-Server läuft: min = 1; -ignbrk -brkint ignpar
Ich habe daraufhin mittels der 'stty'-Funktion die Werte so gesetzt, dass sie bei FHEM-Betrieb genau so wie bei ZWay-Server-Betrieb sind, aber das Problem bestand weiter; gefühlt waren die Zeiträume vor dem 'tot'-Zustand größer, aber das ist nicht stabil, da der Tot-Zustand durch ein 'planmäßiges' FHEM-Kommando ja ohnehin aufgehoben wird.

2. Timeouts:
Zitat
FHEM setzt diese Timeouts in 00_ZWDongle.pm/ZWDongle_DoInit auf 100/15.

Ich habe in 00_ZWDongle.pm/ZWDongle_DoInit folgende Änderung vorgenommen und den FHEM-Server neu gestartet.
#  ZWDongle_Set($hash, $name, ("timeouts", 100, 15));  # Sec relevant
  ZWDongle_Set($hash, $name, ("timeouts", 10, 10));  # Sec relevant
Ergebnis: keine positiven Auswirkungen.

3. API - Timeouts:
Zitat
Wuesste gerne, was mit old und cur gemeint ist.
Wie schon erwähnt bezieht sich dies sicherlich auf die alten (old) und momentanen (cur(rent)) Werte.
Dass diese beim Starten des ZWay - Servers ausgelesen und neu gesetzt werden, verrät das Log.
[2018-07-27 10:46:25.496] [I] [zway] Job 0x06 (Set Serial API timeouts): Old timeouts are: ACK timeout 100 ms and Byte timeout 100 ms
[2018-07-27 10:46:25.496] [D] [zway] SETDATA controller.data.oldSerialAPIAckTimeout10ms = 10 (0x0000000a)
[2018-07-27 10:46:25.496] [D] [zway] SETDATA controller.data.oldSerialAPIByteTimeout10ms = 10 (0x0000000a)
[2018-07-27 10:46:25.496] [D] [zway] SETDATA controller.data.curSerialAPIAckTimeout10ms = 10 (0x0000000a)
[2018-07-27 10:46:25.496] [D] [zway] SETDATA controller.data.curSerialAPIByteTimeout10ms = 10 (0x0000000a)
[2018-07-27 10:46:25.496] [D] [zway] Job 0x06 (Set Serial API timeouts): success
[2018-07-27 10:46:25.496] [I] [zway] Removing job: Set Serial API timeouts

Da wurden also die von mir (siehe oben) vorgenommenen Änderungen ausgelesen und wieder gesetzt. Bei den gestrigen Werten waren es die Original-FHEM-Werte.
Fazit: ich konnte einiges "aussortieren", aber das 'unerwünschte' Verhalten erweist sich als sehr 'stabil' !!
Ich werde als nächstes etwas mit den 'Timeouts' experimentieren und mich auch noch mehr um 'Watchdog' kümmern.
Peter
« Letzte Änderung: 28 Juli 2018, 08:46:28 von PNinBB »
Raspberry Pi 3B mit RaZberry2 (Debian Stretch) als FHEM-Server, FritzBox 7490;
AEOTec: Key Fob Gen5: 1x;
Danfoss: Living Connect 2.51: 3x;
Fibaro: FGRM222: 1 x, FGRM223: 1 x, FGMS001: 2x, FGK-101: 3x, FGBS-001: 8x, FGRGBWM-441: 1x;
Philio: In Wall Dual Relay PAN06-1A: 3x.

Offline krikan

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 6049
Antw:Keine Event-Meldungen von ZWAVE-Sensoren
« Antwort #17 am: 29 Juli 2018, 19:41:56 »
In https://www.silabs.com/documents/login/user-guides/INS12350-Serial-API-Host-Appl.-Prg.-Guide.pdf im Abschnit 7.13 gibt es kurze Hinweise zu WATCHDOG_START und WATCHDOG_STOP.

Die Funktionen liefern keine Rückgabewerte. Der Timeout in FHEM ist also "normal".

Offline PNinBB

  • Full Member
  • ***
  • Beiträge: 147
Antw:Keine Event-Meldungen von ZWAVE-Sensoren
« Antwort #18 am: 31 Juli 2018, 19:55:24 »
@krikan: Danke für den Hinweis.
Ich habe etwas mit Watchdog experimentiert, aber ohne Erfolg, mir ist noch zu viel unklar an dieser Stelle.
Ich will noch der Spur nachgehen, dass es am Raspi 3 zwei, wohl z.T. unterschiedliche UART's gibt.
Aber erst einmal steht Urlaub an und vielleicht habe ich bei einem Glas italienischen Wein eine "Eingebung"!
Peter
« Letzte Änderung: 31 Juli 2018, 20:32:06 von PNinBB »
Raspberry Pi 3B mit RaZberry2 (Debian Stretch) als FHEM-Server, FritzBox 7490;
AEOTec: Key Fob Gen5: 1x;
Danfoss: Living Connect 2.51: 3x;
Fibaro: FGRM222: 1 x, FGRM223: 1 x, FGMS001: 2x, FGK-101: 3x, FGBS-001: 8x, FGRGBWM-441: 1x;
Philio: In Wall Dual Relay PAN06-1A: 3x.

Offline krikan

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 6049
Antw:Keine Event-Meldungen von ZWAVE-Sensoren
« Antwort #19 am: 03 August 2018, 19:49:22 »
Glas italienischen Wein eine "Eingebung"!
Schönen Urlaub und "Zum Wohl". Mir fiel gerade beim fränkischen Bier ein:
Wir hatten das Thema WATCHDOG_START und zwave.me Controller schon einmal: https://forum.fhem.de/index.php/topic,64973.msg569091.html#msg569091 ff.
Blöderweise nicht mit positivem Ausgang.  :( Vielleicht lohnt es sich aber dennoch noch einmal zu testen.
Gruß, Christian

Offline laserrichi

  • Jr. Member
  • **
  • Beiträge: 85
Antw:Keine Event-Meldungen von ZWAVE-Sensoren
« Antwort #20 am: 03 August 2018, 23:20:41 »
Also ich hab ja jetzt eine weile auf dem UZB1  die Firmware 5.27.... und seitdem keinen einzigen Ausfall mehr.

Die Glaskugel und gegenproben sagen mir das wohl die Firmware einen Teil zu dem Problem beiträgt.

Apropo Fränkisches Bier :-) Hier in der wahren Hauptstadt der Biere mit (leider) nur noch 9 Brauereien (11 wenn man die Mälzerei eigene Brauerei und das Biermuseum rechnet) , und im Landkreis um die 70.... (80er jahre noch 90),   ihr versteht das ich da wenig Zeit für Zwave habe :-)
Die göttliche Eingebung für den Fehler bei soviel Verkostung ist mit der Überhopfung auch nicht mehr möglich :-)

Wenn der Urlauber aus dem Urlaub zurück ist und sich der Wein in Firmware 5.27 wandelt, wissen wir sicher mehr.
Wünsche schon mal schönen kühlen Urlaub :-)

Apropo UART dazu gibt es für den Raspi eine doku, habe bei mir die UARTs auch gedreht da ich auf dem GPIO einen Homematic draufstecken habe. Das hat aber normal keine Auswirkung auf USB.

Offline PNinBB

  • Full Member
  • ***
  • Beiträge: 147
Antw:Keine Event-Meldungen von ZWAVE-Sensoren
« Antwort #21 am: 28 August 2018, 08:26:11 »
Wenn man 365 Tage Urlaub im Jahr hat, dann kann man den Sommerurlaub schon mal etwas verlängern, vor allem bei Italien als Ziel !!
Nun aber zum Ernst des FHEM-Lebens.
Ich habe nach der Rückkehr weiter gesucht, um in der Sache voran zu kommen.
Mein Verdacht lag bei der Interruptbehandlung. Dazu habe ich die Systemeinträge unter '/proc/interrupts' ausgewertet - und siehe da: Wenn der "Totzustand" eintritt, werden vom System keine Interrupts von dieser Quelle (uart) mehr registriert.
Erst ein ausgehendes FHEM-Kommando (beispielsweise 'get ZWAVE homeId') hebt diesen Zustand wieder auf. Erst danach werden wieder Signale von Sensoren angenommen und verarbeitet.
Ich habe dann einen kleinen Monitor in Perl gebaut, der den Zeitpunkt ermittelt hat, wo es keine Interrupts mehr gab (zumindest so ungefähr!).
Ein manueller Vergleich mit dem FHEM-Logfile zeigte eine Übereinstimmung der Art, dass während dieses Zeitraums ACK für einen Befehl fehlten und der Befehl erneut gesendet wurde.
Nun wollte ich diese Routine in FHEM einbinden und die entsprechenden Ergebnisse des Monitors in den FHEM-Logfile einbauen, um eine klarere Aussage zu bekommen.
Zu diesem Zeitpunkt ist mein System abgestorben: vermutlich wegen eines Fehlers im Stromversorgungsmodul ist der Raspi 3 und auch die Speicherkarte zerstört worden. Deshalb gibt es auch die Logdateien nicht mehr !
Nun habe ich mit einem neuen Raspi 3B+ das System völlig neu aufgebaut. Dies schien mir schon vorher als ein Ausweg, da ich vor Monaten das 'Jessie' zu 'Stretch' migriert habe; und dies mit allerhand "Stolperstellen" !
Nun bin ich kurz vor der Wiederinbetriebnahme von FHEM und werde sehen (und berichten).
Eine Frage noch an die "Auch-Betroffenen": welche OS-Version, welchen Kernel, welchen ZWAVE-Modul und welche Firmware-Version nutzt ihr !
Raspberry Pi 3B mit RaZberry2 (Debian Stretch) als FHEM-Server, FritzBox 7490;
AEOTec: Key Fob Gen5: 1x;
Danfoss: Living Connect 2.51: 3x;
Fibaro: FGRM222: 1 x, FGRM223: 1 x, FGMS001: 2x, FGK-101: 3x, FGBS-001: 8x, FGRGBWM-441: 1x;
Philio: In Wall Dual Relay PAN06-1A: 3x.

Offline laserrichi

  • Jr. Member
  • **
  • Beiträge: 85
Antw:Keine Event-Meldungen von ZWAVE-Sensoren
« Antwort #22 am: 29 August 2018, 20:40:13 »
ok die Interrupts hab ich mir bisher noch nicht weiter angesehen. Wie ich in meinen anderen Thread schon schrieb, hab ich auf dem UZB1 stick jetzt Version 5.27 aufgespielt. Seitdem ist das Problem bei mir nicht mehr aufgetreten. Stretch und RASPI3 sind bei mir auf neuesten Stand.

Wie prüfst du das mit den IRQs ?  das der Counter nicht weiter hochzählt für die Cpu ?

Offline PNinBB

  • Full Member
  • ***
  • Beiträge: 147
Antw:Keine Event-Meldungen von ZWAVE-Sensoren
« Antwort #23 am: 22 September 2018, 20:23:48 »
Der vermutlich "Hitzetod" meines Raspi 3B hat mich doch ziemlich zurückgeworfen. Den neuen werde ich nun mit kleinen Ventilatoren ausstatten; aber das ist nicht das Problem.
Ich habe also "Stretch" und "FHEM" neu aufgesetzt und dies hat so seine Zeit benötigt.
Das hier angemerkte Verhalten ist nun auch im neuen System unverändert.
Nach "einiger" Zeit - präziser kann ich es momentan nicht angeben - reagiert FHEM nicht mehr auf Signale von den Sensoren. Erst wenn ein FHEM-Befehl "raus" geht, reagiert das System wieder auf eingehende SIgnale von den Sensoren. Momentan behelfe ich mich nach jeder Minute mit  'get ZWAVE homeId'; aber befriedigend ist dies nicht.

@laserrichi:
Ich benutze das Systemkommando:
cat /proc/interrupts | grep uartund es liefert:
87:     477100          0          0          0  ARMCTRL-level  89 Edge      uart-pl011Aber das ist ja nur bedingt aussagekräftig, da ja durchaus und völlig normal eine gewisse Zeit keine Interrupts von diesem Interface kommen können.

Ich habe in der Zwischenzeit auch viel über Interruptbehandlung in Debain gelesen, aber keinen Anhaltspunkt gefunden.

@rudolfkoenig:
Wo und Wie hängt sich denn der ZWave-Modul in die Interruptbehandlung von Debian ein ?
Bemerkenswert ist auch das folgende Verhalten: wenn während des "Todzustandes" ein Sensorsignal ausgelöst wird und eben bei FHEM nicht ankommt, dann kommt es entsprechend verzögert, wenn FHEM wieder reagiert; es liegt also auf der RaZberry-Seite irgendwo auf einem Stack.
Und noch eine Beobachtung: im zeitlichen Umfeld des Beginns des "Todzustandes" gibt es im FHEM-Log einige Einträge mit fehlenden ACK. Was passiert eigentlich, wenn ein Sensorsignal in solche eine Wiederholungs- bzw. Wartephase fällt ?

Auf jeden Fall ein Danke an "Ideenspender".
Peter
Raspberry Pi 3B mit RaZberry2 (Debian Stretch) als FHEM-Server, FritzBox 7490;
AEOTec: Key Fob Gen5: 1x;
Danfoss: Living Connect 2.51: 3x;
Fibaro: FGRM222: 1 x, FGRM223: 1 x, FGMS001: 2x, FGK-101: 3x, FGBS-001: 8x, FGRGBWM-441: 1x;
Philio: In Wall Dual Relay PAN06-1A: 3x.

Offline laserrichi

  • Jr. Member
  • **
  • Beiträge: 85
Antw:Keine Event-Meldungen von ZWAVE-Sensoren
« Antwort #24 am: 22 September 2018, 20:43:07 »
Hallo Peter,

sicher das es uart ist ?  Den der UZB1  benutzt soweit ich weis eigentlich dwc_otg

habe gerade mal ausprobiert ob hier bei zwave signalen etwas hochzählt, da hat bei mir der uart nichts gezählt wenn ein sensor was gesendet hat sondern der irq für dwc_otg ging höher.

Bei mir sind die Probleme momentan nicht mehr vorhanden. Hat wohl doch eventuell etwas mit dem Update auf dem Stick zu tun.

Offline tomspatz

  • Sr. Member
  • ****
  • Beiträge: 505
Antw:Keine Event-Meldungen von ZWAVE-Sensoren
« Antwort #25 am: 22 September 2018, 20:47:59 »
@PNinBB

Hast du denn auch etwas was automatisch von fhem gesteuert wird.
Nur so als Idee, wenn fhem auf ZWave immer nur lauscht (Sensoren etc.) und NIE selbst etwas ins ZWave Netz schickt. ???

LG
Tom

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 19169
Antw:Keine Event-Meldungen von ZWAVE-Sensoren
« Antwort #26 am: 23 September 2018, 11:26:58 »
Zitat
Wo und Wie hängt sich denn der ZWave-Modul in die Interruptbehandlung von Debian ein ?
Indirekt ueber select, diese Funktion blockiert solange, bis bei einem der registrierten Filedescriptoren was passiert, oder das spezifizierte Timeout eingetreten ist. Ueber Filedescriptoren werden nicht nur Dateien, sondern auch USB-Geraete oder Netzwerkverbindungen angesprochen. Wie vom Interrupt zum select-Benachrichtigung kommt, das is Sache des Kernels, und erstens ist das kompliziert, zweitens bin ich nicht auf dem aktuellen Stand.

Unter Windows funktioniert select nur fuer Geraete, die per TCP angebunden sind (da Microsoft den TCP-Kode vom BSD gekl^H^H^H^Huebernommen hat), USB-Geraete werden in FHEM@Windows gepollt.

Offline PNinBB

  • Full Member
  • ***
  • Beiträge: 147
Antw:Keine Event-Meldungen von ZWAVE-Sensoren
« Antwort #27 am: 13 Oktober 2018, 20:25:12 »
Bin erst seit einigen Tagen wiederer auf der "Baustelle".
Ich habe nun auch den ZWay-Server auf meinem neu aufgesetzten System zum Laufen gebracht. Alle meine Geräte sind sicht- und nutzbar. Ich habe - auf die Schnelle - ein paar Aktionen mit "Wenn --> dann" eingerichtet, vor allem auch mit meinen Sensoren.
Alles funktioniert wie es sein soll, insbesondere gibt es keine "Verklemmungen" bzw. "Totzustände" !! So lief es etwa 3 Tage.
Wenn ich wieder auf FHEM gehe, tritt der Effekt wieder auf.
Meine Verdacht ist unverändert: es scheint aufzutreten, wenn eine Meldung von einem der Binärsensoren während eines laufenden Sendevorganges von ZWAVE (evenuell mit Wiederholungen!) übermittelt wird. Da natürlich eine solche Meldung ein asynchrones Ereignis ist, kann es solche Verklemmungen hervorrufen.
Ich bin erst einmal wieder 14 Tage unterwegs. Dann will ich mir mal die serielle Schnittstelle vorknüpfen und vor allem versuchen zu verstehen, wie die Details der Sende- und Empfangsvorgänge sind.

@Rudi:
Gibt es eventuell einige Hilfsprogramme, die man dafür nutzen könnte.
Zitat
Indirekt ueber select, diese Funktion blockiert solange, bis bei einem der registrierten Filedescriptoren was passiert, oder das spezifizierte Timeout eingetreten ist.
Und was passiert nach diesem Timeout ??

@laserrichi:
Ich benutze nicht den UZB1, sondern die ZWAVE 2 Steckkarte, welche uart nutzt. Aber auf dem Raspi3B sind zwei eingebaut. Ich habe vieles dazu gelesen und keinen Anhaltspunkt gefunden.Die neueste Firmware 2.3.7 ist installiert; alles andere ist auch aktuell. Es ist zwar in den Foren die Rede, dass es wohl noch Probleme mit ZWay unter Stretch gibt, aber eine aktualisierte Software gibt es bisher nicht.

@tomspatz:
Natürlich habe ich mehrere derartiger Befehle; die sind es ja, die den Blockadezustand wieder aufheben.

Es geht zwar momentan einigermassen zufriedenstellend mit den minütliche HomeID-Abfragen, aber eine akzeptable Lösung ist das nicht.
Für gute Ideen bin ich natürlich immer offen !!
Schönen Sonntag !
Peter


« Letzte Änderung: 13 Oktober 2018, 20:27:19 von PNinBB »
Raspberry Pi 3B mit RaZberry2 (Debian Stretch) als FHEM-Server, FritzBox 7490;
AEOTec: Key Fob Gen5: 1x;
Danfoss: Living Connect 2.51: 3x;
Fibaro: FGRM222: 1 x, FGRM223: 1 x, FGMS001: 2x, FGK-101: 3x, FGBS-001: 8x, FGRGBWM-441: 1x;
Philio: In Wall Dual Relay PAN06-1A: 3x.

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 19169
Antw:Keine Event-Meldungen von ZWAVE-Sensoren
« Antwort #28 am: 14 Oktober 2018, 10:52:22 »
Zitat
Gibt es eventuell einige Hilfsprogramme, die man dafür nutzen könnte.
- mit "strace -f -o /tmp/fhem.strace.out -p <FHEM-PID>" kann man pruefen, ob das Betriebsystem die Daten an FHEM weiterreicht. Damit ich die Ausgabe interpretieren kann, brauche ich den aktuellen FileDescriptor, das sieht man mit "list TYPE=ZWDongle FD"
- mit einem CUL + ZWCUL + monitor mode kann man pruefen, ob die Daten per Funk geliefert werden

Zitat
Und was passiert nach diesem Timeout ??
Die per InternalTimer spezifizierten Funktionen werden abgearbeitet (at/DOIF/cleanups/etc).


Zitat
Es geht zwar momentan einigermassen zufriedenstellend mit den minütliche HomeID-Abfragen, aber eine akzeptable Lösung ist das nicht.
Vielen Dank an deinem Ausdauer, ich wuerde gerne das Problem auch lieber sauber loesen.