Nach Update kein FHT Empfang per CUL mehr

[swifty]

Hallo,

ich habe im Juni FHEM aktualisieren müssen, es lief alles wie es sollte, nur halt Yahoo wetter nicht mehr. Nach dem Update bekomme ich allerdings nur ein einziges FHT Telelegram (nach dem Start von FHEM) dann ist ruhe. Jetzt fängt die Heizsaison an, da wäre die Steuerung ja wieder schön.

Was hab ich genau gemacht:

• FHEM Update
• Da kein FHT Empfang ein CUL Update
• Foren durchstöbert und den RFmode ergänzt.
• Nochmal ein UPdate

Es ist ein Windows system, das sollte je eigentlich kein Unterschied darstellen, ganz sicher bin ich nicht.


Die Config des CUL:

Code Auswählen Erweitern

define CUL CUL com5@9600 1234
attr CUL model CUL
attr CUL rfmode SlowRF


Das List ergebnis:

Code Auswählen Erweitern

Internals:
   CMDS       BbCFiAZNkGMKUYRTVWXefmLltux
   CUL_MSGCNT 2
   CUL_TIME   2016-10-07 10:30:31
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        com5@9600 1234
   DeviceName com5@9600
   FHTID      1234
   NAME       CUL
   NR         7
   PARTIAL
   RAWMSG     T555A00BA0007
   RSSI       -70.5
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.66 CUL868
   initString X21
   Matchlist:
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04....(1|5|9).a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
   Readings:
     2016-10-07 10:30:05   cmds             B b C F i A Z N k G M K U Y R T V W X e f m L l t u x
     2016-10-07 10:27:18   raw             No answer
     2016-10-07 10:30:31   state           Initialized
   Softbuffer:
Attributes:
   model      CUL
   rfmode     SlowRF


Im Logfile kommt das hier:

Code Auswählen Erweitern

2016.10.07 10:30:05 3: Opening CUL device com5
2016.10.07 10:30:05 3: Setting CUL serial parameters to 9600,8,N,1
2016.10.07 10:30:05 3: CUL: Possible commands: BbCFiAZNkGMKUYRTVWXefmLltux
2016.10.07 10:30:05 3: CUL device opened


Allerdings hatte ich vor dem 2. Update auch noch das hier, komt aber nicht mehr, keine Ahnung ob das zusammen hängt

Code Auswählen Erweitern

2016.10.02 06:40:00 3: PROPLANTA: set wetter_P update
2016.10.02 06:40:00 1: PERL WARNING: Error in PurgeComm at ./FHEM/DevIo.pm line 471.
Unzul�ssige Funktion.

2016.10.02 06:40:00 1: PERL WARNING: Error in GetCommTimeouts at ./FHEM/DevIo.pm line 471.
Error closing Read Event handle 1812 for \\.\com5
Das Handle ist ung�ltig.

Error closing Write Event handle 1808 for \\.\com5
Das Handle ist ung�ltig.

2016.10.02 06:40:00 1: ERROR: Select error -1 (10038), error count= 0
Select error -1 (10038)
2016.10.02 06:40:08 1: PERL WARNING: Error in PurgeComm at fhem.pl line 0.
Das Handle ist ung�ltig.

2016.10.02 06:40:08 1: PERL WARNING: Error in GetCommTimeouts at fhem.pl line 0.
Error Closing handle 1816 for \\.\com5
Das Handle ist ung�ltig.

Error closing Read Event handle 1812 for \\.\com5
Das Handle ist ung�ltig.

Error closing Write Event handle 1808 for \\.\com5
Das Handle ist ung�ltig.

2016.10.02 06:40:21 1: starting in console mode
2016.10.02 06:40:21 1: Including fhem.cfg
2016.10.02 06:40:21 3: Opening CUL device com5
2016.10.02 06:40:21 3: Setting CUL serial parameters to 9600,8,N,1
2016.10.02 06:40:21 3: CUL: Possible commands: BbCFiAZNkGMKUYRTVWXefmLltux
2016.10.02 06:40:21 3: CUL device opened


Wie gesagt, nach jdem FHEM neustart kommt ein einziges Telegramm, dann hängt sich irgend etwas auf. Wäre toll, wenn mir jemand helfen kann.

Gruß
swifty

[rudolfkoenig]

Ich fuerchte die Anzahl der Windows Experten in diesem Forum ist niedrig, ich bin auch keins, versuche trotzdem mein Bestes.

Ich habe gerade auf einem Windows 7 VM FHEM mit einem CUL gestartet, und scheint zu laufen, hat automatisch diverse Geraete, unter anderem FHT's angelegt, und meldet auch regelmaessig Werte. Also es gibt kein prinzipielles Problem mit einem aktuellen CUL, FHEM und Windows 7. Ein update der CUL Firmware war eigentlich nicht notwendig, an der FHT Anbindung hat sich seit mehreren Jahren nichts geaendert.
Was ich gemerkt habe: das Entfernen eines CULs kriegt FHEM unter Windows nicht mit, auch das Einstecken nicht. Ein "set CUL reopen" funktioniert auch nicht wirklich. Nach einem Neustart von FHEM bekommt man in einer Endlosschleife die Meldung: "das System kann die angegebene Datei nicht finden". Erst wenn ich FHEM stoppe, das USB Geraet entferne und danach wieder einstecke, und danach FHEM wieser starte, funktioniert wieder alles reibungslos. FHEM@Linux Benutzer muessen auf solche Reihenfolgen nicht acht nehmen, und die Fehlerbehandlung ist da auch robuster.

Die Fehlermeldungen zeigen, dass FHEM nicht mehr auf das CUL zugreifen konnte, ob das jetzt an Hardware- (CUL abgesteckt) oder Software-Problemen (wie USB-Treiber) lag, kann ich nicht sagen.
Wenn die im Internet nach den Fehlermeldungen suche, dann wird als eine moegliche Ursache der Zugriff von mehreren Programmen auf das gleiche COM Geraet aufgefuehrt. Da manche FHEM Module einen zweiten Prozess starten, halte ich diese Ursache nicht fuer ganz ausgeschlossen. Verwendest du solche Module? Tauchen diese Fehlermeldungen auch im aktuellen Log auf? Ich habe dich so verstanden, dass das nur vor dem update der Fall war. Wenn ja, dann sind erstmal die Meldungen irrelevant: ich halte es fuer ausgeschlossen, dass die Meldungen laengerfristig einen "Schaden" im CUL verursacht haben, so dass es jetzt nur eine FHT-Meldung durchlaesst.

[swifty]

Hallo,

danke für die Hilfe so weit. Das aktuelle Log zeigt keine Probleme mehr, es sieht also alles gut aus. Komisch, dass es jahrelang lief. Mit USB gibt es bisher keine Probleme, zumal der Rechner jede Nacht neu gestartet wird.
Sollte niemand ein Geistesblitzt haben und das ganze vermutlich kein grundsätzliches Problem ist, wird das wohl die Umzugspläne auf einen Pi verstärken.

Gruß
swifty.

[Pfriemler]

Am Rande: bei mir hat sich, an einem Tag den ich nicht in Zusammenhang mit Updates bringen kann (aber ich kann es nicht ausschließen) der einzige FHT, seit langem störungsfrei, aus dem Sendebetrieb verabschiedet, einzig fehlerhafte actuator-Meldungen wurden regelmäßig generiert. Ein Neupairen mit geändertem Code, Stacklöschen im CUL und einige Stunden haben den FHT wieder ins System gehievt, trotzdem brauchte es noch zwei Tage bis die Readings komplett waren. So fragil ist die Kommunikation noch nie gewesen. Ich habe mir auch schon die Frage gestellt, ob da irgendwas geändert wurde. ... Vielleicht an einer ganz anderen Stelle, die nur mittelbar Einfluss hat...

geht nich gips nich

[swifty]

Interessanter Hinweis.
Mit geändertem Code wird weiterhin nur ein Telegramm empfangen. Versucht man dem CUL eine Rawmassage zu entlocken hängt fhem komplett, es wird noch ein leeres Fenster ausgegeben das wars dann. Leider bleibt das perl Fenster unter Windows aktiv, die Tasküberwachung merkt dann nichts 
Der Pi ist bestellt.

Bei mir war nach dem Update die unter anderem die DevIo.pm geändert. Ich tue mich mit Perl immer noch wahnsinnig schwer, ich habe nicht ernsthaft versucht etwas zu debuggen.

Wie kann man im CUL den Stack löschen? Löscht der sich beim abstecken selbst?

swifty

[Pfriemler]

Ich dachte nur, Dein eigentliches Problem (keine Meldungen vom FHT mehr) könnte auch mit meinem zusammenhängen.
Über Verbindungsprobleme und was man machen kann gibt's mW einen Wiki-Artikel. Am CUL kann man mit set und get T0x FHT-ID ne Menge machen, u.a. Caches und Device-IDs auslesen und löschen.

geht nich gips nich

[Chris76FiSi]

Hallo zusammen,

auch ich habe seit ein paar Tagen mit meinem CUL, wenn ich nach einem FHEM Update und einem 'shutdown restart' FHEM neu starte. Bislang war es ja so, dass mein FHT CUL anstandslos weiterlief und somit der Sync mit den FHT Devices bestehen blieb. Mittlerweile ist es leider so, dass mit dem FHEM Neustart wohl auch der CUL neu startet, was zum Verlust des Syncs führt. Aufgefallen ist mir das zuerst, nachdem  immer wieder einzelne FHT8V in den Notbetrieb (Valve 30%) gingen und sich nach ca. 1-2 Stunden mit einem Piepsen wieder "gefangen" haben.
Soeben habe ich es nochmal nachgestellt mit dem Blick auf die Runtime meines CUL. Nach einem FHEM Neustart fängt die Runtime des CUL wieder von Null an. Evtl. hat ja jemand eine Idee.

VG, Chris

[Pfriemler]

Ah ... Neustarts hatte ich in letzter Zeit leider öfter machen müssen, vielleicht war das schon der Auslöser.

Nach einem FHEM Neustart fängt die Runtime des CUL wieder von Null an.

Eigentlich wäre das alles kein Problem. Wichtig ist dass der CUL nicht vor der Zeit sendet. Im Empfang läuft er doch dauernd und sollte daher auch (von Funk-Kollisionen mit anderen Geräten abgesehen) sich problemlos auf den Senderhytmus des FHT nach dem ersten empfangenen Telegramm einstellen und dann auch erfolgreich senden können. Der FHT bekommt von dem Neustart normalerweise nix mit und sendet seine Daten doch selbständig an die Zentrale, oder habe ich das falsch verstanden?

Die FHT8V lernen den Senderhythmus vom FHT beim SYNC oder beim Intitialisieren mit einem neuen Code. Der FHT ist m.W. auch der einzige, der an die Stellantriebe sendet (der CUL schneidet die Telegramme, die den erforderlichen Ventilstellgrad beinhalten, ja munter mit, diese Telegramme wurden immer empfangen). Wenn die auf Notbetrieb gehen, dann liegt das Problem am FHT.

Haben wir vielleicht ein verspätetes Jahr-2000-Problem (also im Ernst irgendeine kalenderabhängige Fehlfunktion), weil das jetzt auftritt? Geplante Obsoleszenz?
Nein, quatsch, mein resynchronisierter FHT läuft ja jetzt seit Tagen ...

[Chris76FiSi]

Hi,
da habe ich mich wohl irreführend ausgedrückt. Ich habe keinen FHT80b im Einsatz. Meine Stellmotoren FHT8V sind direkt mit dem CUL gepairt.
Nach einem FHEM Neustart (shutdown restart) verlieren die FHT8V Stellmotoren den Sync zum CUL.

Da ich nur sechs FHT8V habe, ist das nicht ganz so schlimm. Ich führe nach einem FHEM Neustart jeweils einen "Batteriewechsel" durch (Batt. raus, Taste länger drücken, damit sich die Restspannung abbaut, Batt. wieder rein, Stellmotor macht auf und wieder zu, dann erfolgt wieder der Sync).
Ist halt nur nervig, wenn man sein FHEM möglichst aktuell halten möchte

[rudolfkoenig]

@Chris76FiSi: Dein Problem hat nichts mit dem Urspruenglichen zu tun, und Thread-Entfuehrung ist eine schwere Straftat. Bitte demnaechst eine separate Diskussion anfangen.

- Eigentlich sollte ein FHEM Neustart nicht zu einem culfw-Neustart fuehren, der Uptime meines CULs ist immer wieder mehr als ein Jahr. culfw startet neu, wenn das CUL vom Strom getrennt wird, oder wenn man absichtlich "set CUL raw B00" absetzt. Letzteres schliesse ich mal aus, und wenn bei dir FHEM-Neustart nicht mit dem Power-Knopf verbunden ist, dann Ersteres auch. Bitte ueberpruefe, wie es bei Dir dazu kommen kann, und Problem beheben.

- Das FHT8v Code in culfw stammt von mir (wobei ich Ideen Anderer implementiert habe), im Einsatz hatte ich das aber nie. Da das Timing der Signale an die FHT8v's wichtig ist (muss alle 115+x Sekunden innerhalb von 1s stattfinden), ist es klar, dass ein culfw Neustart zum Verbindungsabbruch fuehrt. Als Workaround kann man das FHT-Sync Befehl (2c) senden, dabei wird, wie bei dem original FHT80b, von 120 runtergezaehlt, und einmal pro Sekunde der Abstand bis 0 gesendet. Einen dieser Signale wird jeder FHT8v empfangen, und synchronisiert sich dadurch, der Batteriewechsel entfaellt.
Frag mich bitte nach dem "wie sende ich Sync aus FHEM" erst, nachdem du das lange erfolglos Recherchiert hast, da ich es auch nicht mehr genau weiss.

[Chris76FiSi]

Mea Culpa - wollte niemanden entführen