Response Timeouts mit HM 4DIS

[rainer042]

Hallo,

ich hab mir gerade einen HM 4DIS Display Wandsender zugelegt. Zunächst konnte ich den 4DIS mit zwei HM-Dimmern direkt pairen und dann hab ich ihn auch mit FHEM gepairt. Hat geklappt. Ich  konnte danach auch die Texte für den 4DIS für die 10 Steuerbaren Geräte setzen.

Das hat noch geklappt, dann fingen die Probleme an. Ich konnte plötzlich z.B. kein set <4DIS> getConfig mehr machen, weil ich immer ein Respons Timeout bekommen habe und auf Seiten von FHEM immer ca. 40 Messages nicht gesendet werden konnte. FHEM neustart ein set <4DIS> clear msgEvents hat geholfen bis zum nächsten getConfig Versuch. Dann begann wieder das gleiche Spiel.

Also habe ich erstnochmal alles 4DIS-relevaten aus FHEM rausgeworfen, den 4DIS in den Werkzustand versetzt und dann FHEM auf den aktuellsten Stand (ich glaub 22.04.2014) gebraucht und dann versucht den 4DIS neu anzulernen.

Das klappt jetzt nur noch "halb". FHEM sieht den 4DIS und erkennt dann die 20 Kanäle, die nacheinander erscheinen sollten. Hier ist aber jetzt nach dem zweiten Kanal Schluss. Der 4 DIS meint dennoch, das das Anlernen geklappt hätte, aber im LOG File sehe ich wieder ein Timeout:

Code Auswählen Erweitern


2014-04-25_07:58:57 CUL_HM_HM_PB_4DIS_WM_1EAF5D D-firmware: 1.4
2014-04-25_07:58:57 CUL_HM_HM_PB_4DIS_WM_1EAF5D D-serialNr: JEQ0704989
2014-04-25_07:58:57 CUL_HM_HM_PB_4DIS_WM_1EAF5D R-pairCentral: set_0xF11234
2014-04-25_07:58:57 CUL_HM_HM_PB_4DIS_WM_1EAF5D CMDs_pending
2014-04-25_07:58:57 CUL_HM_HM_PB_4DIS_WM_1EAF5D CMDs_pending
....
2014-04-25_08:25:56 CUL_HM_HM_PB_4DIS_WM_1EAF5D CMDs_pending
2014-04-25_08:25:56 CUL_HM_HM_PB_4DIS_WM_1EAF5D CMDs_pending
2014-04-25_08:25:56 CUL_HM_HM_PB_4DIS_WM_1EAF5D CMDs_pending
2014-04-25_08:25:57 CUL_HM_HM_PB_4DIS_WM_1EAF5D R-pairCentral: 0xF11234
2014-04-25_08:25:57 CUL_HM_HM_PB_4DIS_WM_1EAF5D R-language: German
2014-04-25_08:26:04 CUL_HM_HM_PB_4DIS_WM_1EAF5D ResndFail
2014-04-25_08:26:04 CUL_HM_HM_PB_4DIS_WM_1EAF5D CMDs_done_Errors:1
2014-04-25_08:26:04 CUL_HM_HM_PB_4DIS_WM_1EAF5D RESPONSE TIMEOUT:RegisterRead


Das kann ich beliebig oft wiederholen immer mit dem gleichen Timeout-Ergebnis.

Also hab ich gedacht am besten gleich mal bessere Logs der RAW messages mitzuliefern und daran bin ich erstmal gescheitert. Ich hab im Wiki unter http://www.fhemwiki.de/wiki/Homematic_Nachrichten_sniffen gelesen und was ich nicht weiß, ist was ich für <cul> bzw <hmlan> konkret angeben muß?

Ich betreibe FHEM auf einem RaspberryPi mit einem COC board für den Funkverkehr.

Danke für die Hilfe

Viele Grüße
Rainer

[martinp876]

FHEM neustart ein set <4DIS> clear msgEvents

sicher hätte ein set <4DIS> clear msgEvents gereicht.

FHEM sieht den 4DIS und erkennt dann die 20 Kanäle, die nacheinander erscheinen sollten. Hier ist aber jetzt nach dem zweiten Kanal Schluss.

verstehe ich nicht. Wieso erkennt FHEM 20 Kanäle aber es erscheinen nur 2? Wie äussert sich das?
wenn du noch einmal config drückst sollten in jedem Fall fehlende Kanäle erscheinen. Save nicht vergessen.

Der 4 DIS meint dennoch, das das Anlernen geklappt hätte, aber im LOG File sehe ich wieder ein Timeout:

ich bräuchte einmal die Rohmessages des getConfig und ein List <4dis>, wenn kommandos pending sind.
Grund könnte sein, dass das timing nicht stimmt (welchen IO device nutzt du?) oder eine Abfrage eines Registers erfolgt, welches es nicht gibt.

eiß, ist was ich für <cul> bzw <hmlan> konkret angeben muß?

HMLAN hast du nicht.
du solltest also für <cul> den Namen der COC eintragen

Ich betreibe FHEM auf einem RaspberryPi mit einem COC board für den Funkverkehr.

das könnte allerdings das Problem sein (werden die rohmessages zeigen). Ist die COC über LAN angeschlossen? da könnte das Timing instabil sein - insbesondere bei langen Abfragen wie 20-chanel eines 4Dis

Gruss Martin

[rainer042]

ich bräuchte einmal die Rohmessages des getConfig und ein List <4dis>, wenn kommandos pending sind.
Grund könnte sein, dass das timing nicht stimmt (welchen IO device nutzt du?) oder eine Abfrage eines Registers erfolgt, welches es nicht gibt. HMLAN hast du nicht.
du solltest also für <cul> den Namen der COC eintragendas könnte allerdings das Problem sein (werden die rohmessages zeigen). Ist die COC über LAN angeschlossen? da könnte das Timing instabil sein - insbesondere bei langen Abfragen wie 20-chanel eines 4Dis

Hallo Martin,

danke für die Antwort.

den Mitschnitt will ich gerne liefern. Allerdings klappt ein
attr COC logIDs all,sys nicht, weil logIDs nicht unterstützt wird:

Code Auswählen Erweitern

configfile: COC: unknown attribute logIDs. Type 'attr COC ?' for a detailed list.

Mögliche Optionen sind:

Code Auswählen Erweitern

COC: unknown attribute ?, choose one of verbose:0,1,2,3,4,5 room group comment alias eventMap userReadings do_not_notify:1,0 dummy:1,0 showtime:1,0 model:CUL,CUN sendpool addvaltrigger rfmode:SlowRF,HomeMatic,MAX hmId hmProtocolEvents:0_off,1_dump,2_dumpFull,3_dumpTrigger devStateIcon devStateStyle icon sortby toggleDevice webCmd webcmdDevice

Welche Attribute soll ich denn am besten nehmen?

Ich hab jetzt ersteinmal ein attr COC verbose 4 gemacht. Evtl hilft das ja auch schon etwas weiter. Hier das log des Pairens des 4DIS (im Werkszustand) an FHEM. Siehe angehängte Datei.

Nachdem dann das pairing abgebrochen hat habe ich am 4DIS ein "Menü Zentral->Übernehmen gemacht". dann hat er alle Buttons bis Nummer 19 erkannt, dann aber wieder einen Timeout bekommen.

Das einzige was an Konfiguration nun in fhem.cfg nach einem save config auftaucht ist das:
define CUL_HM_HM_PB_4DIS_WM_1EAF5D CUL_HM 1EAF5D
attr CUL_HM_HM_PB_4DIS_WM_1EAF5D room CUL_HM
define FileLog_CUL_HM_HM_PB_4DIS_WM_1EAF5D FileLog ./log/CUL_HM_HM_PB_4DIS_WM_1EAF5D-%Y.log CUL_HM_HM_PB_4DIS_WM_1EAF5D
attr FileLog_CUL_HM_HM_PB_4DIS_WM_1EAF5D logtype text
attr FileLog_CUL_HM_HM_PB_4DIS_WM_1EAF5D room CUL_HM

Der COC ist übrigens nicht via LAN angeschlossen, sondern eben ein kleines Board das direkt auf der Erweiterungs-PIN-Leiste des Raspberry PI sitzt. Ich betreibe noch ca. 6 weitere Homematic-Geräte am COC, die bisher gut funktinieren.

Als Anhang habe ich auch schon mal das list des 4DIS devices angehängt.

Viele Grüße und vielen Dank
Rainer

[martinp876]

attr COC logIDs all,sys nicht, weil logIDs nicht unterstützt wird:

klar - daher gibt es eine Anleitung für CUL und eine für HMLAN. Du musst CUL nutzen.

Ich hab jetzt ersteinmal ein attr COC verbose 4 gemacht.

perfekt - nach Anleitung

dann hat er alle Buttons bis Nummer 19 erkannt, dann aber wieder einen Timeout bekommen.

Wie? Es sind 20 Buttons eingetragen.

Dein Log endet um 15:07:43.104. Der Fehler ist um
   protLastRcv 2014-04-25 15:11:22
   protResndFail 2 last_at:2014-04-25 15:11:12
   protSnd    165 last_at:2014-04-25 15:11:10
   protState  CMDs_done_Errors:1
aufgetreten. Den spannenden Teil hast du also nicht geliefert. Den brauche ich.

Das einzige was an Konfiguration nun in fhem.cfg nach einem save config auftaucht ist das:

das verstehe ich nicht.
Du hast explizit ein "save" gemacht - korrekt?
Die Channels sind sichtbar, alle 20. sie sind auch in FHEM angelegt und werden nicht gespeichert? Trotz save?

Der COC ist übrigens nicht via LAN angeschlossen, ...

ok - dann werde ich das timing ansehen, wenn du ein komplettes file schickst.
Gruss Martin

[rainer042]

klar - daher gibt es eine Anleitung für CUL und eine für HMLAN. Du musst CUL nutzen.perfekt - nach Anleitung
Wie? Es sind 20 Buttons eingetragen.

Dein Log endet um 15:07:43.104. Der Fehler ist um
   protLastRcv 2014-04-25 15:11:22
   protResndFail 2 last_at:2014-04-25 15:11:12
   protSnd    165 last_at:2014-04-25 15:11:10
   protState  CMDs_done_Errors:1
aufgetreten. Den spannenden Teil hast du also nicht geliefert. Den brauche ich.
das verstehe ich nicht.
Du hast explizit ein "save" gemacht - korrekt?

Ok einen Fehler gefunden. Ich hatte ein "save config" gemacht kein "save". OK nachdem ich nun ein save gemacht habe und einen FHEM Neustart sehe ich in fhem.cfg den schon geposteten Teil und am Kopf von fhem.cfg viele solche Fehler-config-Meldungen:

statefile: Please define CUL_HM_HM_PB_4DIS_WM_1EAF5D_Btn_01 first\
Please define CUL_HM_HM_PB_4DIS_WM_1EAF5D_Btn_01 first\
Please define CUL_HM_HM_PB_4DIS_WM_1EAF5D_Btn_01 first\
Please define CUL_HM_HM_PB_4DIS_WM_1EAF5D_Btn_01 first\
Please define CUL_HM_HM_PB_4DIS_WM_1EAF5D_Btn_02 first\
Please define CUL_HM_HM_PB_4DIS_WM_1EAF5D_Btn_02 first\
....
Please define CUL_HM_HM_PB_4DIS_WM_1EAF5D_Btn_19 first\
Please define CUL_HM_HM_PB_4DIS_WM_1EAF5D_Btn_19 first\
Please define CUL_HM_HM_PB_4DIS_WM_1EAF5D_Btn_19 first\
Please define CUL_HM_HM_PB_4DIS_WM_1EAF5D_Btn_20 first

Mehr aber auch jetzt nicht.

Die Channels sind sichtbar, alle 20. sie sind auch in FHEM angelegt und werden nicht gespeichert? Trotz save? ok - dann werde ich das timing ansehen, wenn du ein komplettes file schickst.
Gruss Martin

Vor dem Neustart waren die 20 Kanäle noch sichtbar in fhem, nach dem Neustart nicht mehr.

Könnte es sein das irgendetwas beim Updaten auf die aktuellste Version schief gegangen ist? Ich könnte
nochmal auf die "alte" Version von Anfang April zurück gehen und nochmal von dort von vorne Anfangen.

Das log-File ist jetzt dabei bis und inkls. der letzten Meldung um 2014.04.25 15:11:22.021

Viele Grüße
Rainer

[rainer042]

Hallo Martin,

ich hab jetzt wirklich erst nochmal mit einer älteren Version (backup) angefangen. Zumindest habe ich jetzt den 4Dis mit allen Buttons in FHEM sichtbar. Das hat jetzt geklappt.

Was immer noch mal wieder schief geht sind Timeouts bei Register setzen oder beim getConfig. Da bin ich noch am experimentieren. Eine Theorie ist, das ich mit 20 Kommandos auf der telnet-Schnittstelle um Register-Parameter für Dimmer zu setzen evtl zu viel auf einmal mache und das dann die Geräte aus dem Tritt bring. Ich experimentiere hier noch mal etwas.

Wenn ich dann nochmal was nachvollziehbares habe melde ich mich noch einmal.

Danke erstmal für Deine Hilfe
Rainer

[martinp876]

Hallo Rainer,

also save ist notwendig.
Die Meldungen "please define" beziehen sich darauf, dass die Entity nicht im cfg ist, aber readings im statefile vorhanden sind. Das save hat also nicht funktioniert oder wurde nicht ausgeführt.

Vor dem Neustart waren die 20 Kanäle noch sichtbar in fhem, nach dem Neustart nicht mehr.
Könnte es sein das irgendetwas beim Updaten auf die aktuellste Version schief gegangen ist?

wenn die Kanäle in FHEM sichtbar sind und du ein save machst müssen die gespeichert werden.
Ich habe es mit der aktuellen Version simuliert - es klappt. testen kann ich mangels Device nicht.
Du kannst nach einem Save und vordem Neustart dein fhem.cfg kontrollieren - da sollten alle Buttons zu sehen sein (nein - MÜSSEN).

Das log-File ist jetzt dabei bis und inkls. der letzten Meldung um 2014.04.25 15:11:22.021

prima.
Ich sehe, dass das pairen beim ersten Mal funktioniert hat - auch die Channles sollten schon angelegt worden sein. Nur das Lesen der Konfig hat das Device nach dem 3. Kanal abgebrochen.

Dann hast du noch einmal gepairt - das kannst du , ist aber nicht notwendig. Du hättest nur "config" drücken müssen. (ggf ein getConfig vorher absetzen).
Beim 2. mal ist noch einmal gepairt worden und es sind alle Kanäle gelesen worden bis Nr. 20. Dann hast du noch einmal config gedrückt, aber es war nichts mehr zu Lesen - mit dem Fehler werden bei Config devices die messages gelöscht.
Grund schient ein Delay in FHEM gewesen zu  sein - das ACK kam 150ms zu spät. Konnte man jetzt suchen, wer schuld war...

Was kann der User tun
Option 1) in HMInfo ein configcheck machen. Bei allen Kanälen, denen etwas fehlt ein getConfig machen (hier ist es nur Channel 20). Das sollte funktionieren - bei nur einem Kanal ist das sehr kurz und schnell
Option 2) autoReadReg auf 5 setzen (im Device - mache ich bei jedem). Das fehlende Register sollte bemerkt werden und es wird ein getConfig aufgerufen. Dauert aber bis zu 30min, da es im Hintergrund läuft. Beim nächsten config drücken ist dann alles da.

Ausserdem solltest du HMInfo:
- autoarchive einschalten (siehe Wiki) => Es wird immer das letzte erfolgreiche peer/register lesen in ein File gespeichert.
- im Config nach dem Laden ein loadConfig einbauen. (siehe Wiki) => alle Register, die nicht im statefile vorhanden sind, aber im archive, werden geladen.

mit einer älteren Version (backup) angefangen. Zumindest habe ich jetzt den 4Dis mit allen Buttons in FHEM sichtbar. Das hat jetzt geklappt.

sollte auch mit der Aktuellen... sonst verstehe ich es nicht.

Eine Theorie ist, das ich mit 20 Kommandos auf der telnet-Schnittstelle um Register-Parameter für Dimmer zu setzen evtl zu viel auf einmal mache und das dann die Geräte aus dem Tritt bring.

denke ich nicht. In deinem Fall war es ein einfaches Delay - das kann vorkommen, kann ich nicht verhindern Irgend ein task in FHEM (oder ausserhalb, oder in summe) hat das ack um 170ms verzögert - da hört das Device nicht mehr zu, mehr als ~80ms delay mag es einfach nicht.
FHEM ist mit single-tasking nicht aufgestellt, so etwas zu 100% zu stemmen.
Ein HMLAN hätte hier weniger Probleme, da die ACKs aus der Dose kommen, nicht von FHEM. Das ist um Welten präziser.

Gruss Martin

[rainer042]

sollte auch mit der Aktuellen... sonst verstehe ich es nicht.denke ich nicht. In deinem Fall war es ein einfaches Delay - das kann vorkommen, kann ich nicht verhindern Irgend ein task in FHEM (oder ausserhalb, oder in summe) hat das ack um 170ms verzögert - da hört das Device nicht mehr zu, mehr als ~80ms delay mag es einfach nicht.
FHEM ist mit single-tasking nicht aufgestellt, so etwas zu 100% zu stemmen.
Ein HMLAN hätte hier weniger Probleme, da die ACKs aus der Dose kommen, nicht von FHEM. Das ist um Welten präziser.
Gruss Martin

Hallo Martin, vielen Dank für die Analyse.

Es klappt übrigens mit der aktuellen FHEM Version. Ich hatten ein älteres Backup wieder eingespielt mit älterer FHEM Version, weil ich ja vermutete das mein FHEM Update das ich vorgestern gemacht hatte irgendwie schief gelaufen war und seltsame Fehler verursacht hat. Nach dem Rückspielen des Backups hab ich dann wieder ein FHEM Update gemacht und dann erneut probiert. Das hat dann ja auch was geändert, indem plötzlich das 4DIS Pairen und lernen der Kanäle wieder auf Anhieb geklappt haben.

Deine anderen Tips werde ich mir mal ansehen und versuchen sie umzusetzen.

Wegen des verspäteten ACK: Generell ist der RaspberryPi natürlich eine nicht super leistungsstarke Hardware mit lahmer SD-Karte als Platte. Da ist es schon denkbar, das ein Prozess nicht immer schnell genug die CPU erhält um zeitkritische Aufgaben zu erfüllen. Hängt eben davon ab was sonst gerade auf dem System passiert.  Auf meinem Raspberry  läuft auch noch meine Wetter-Anwendung, die alle 5min Daten aus einer Station ausliest (z.T. auch in Perl geschrieben). 

Evtl würden meine Probleme also auf einer anderen Hardware gar nicht erst vorkommen...

Viele Grüße
Rainer

[martinp876]

Evtl würden meine Probleme also auf einer anderen Hardware gar nicht erst vorkommen...

Korrekt.
FHEM hat auf keine Platfrom ein garantiertes Timing. Es läuft aber recht gut.
1) HMLAN ist besser
2) USB ist noch etwas schneller
3) deine Platformperformance ist wichtig
4) Processe  auf der Platform könnten Probleme machen

[rainer042]

Ich hab mal mit HMInfo herumgespielt, aber die Doku im Wiki gibt für mich zu wenig her um zu kapieren wie es funktionieren soll. Ich hab einfach mal minimalistisch aber laut Syntax-Beschreibung zumindest erlaubt ein

Code Auswählen Erweitern

define HM HMinfo

und

Code Auswählen Erweitern

set HM archConfig

ziemlich am Beginn von fhem.cfg eingetragen. Nach kurzer Zeit nach einem fhem Neustart sehe ich dann die Fehlermeldung

Timeout for HMinfo_archConfigExec reached, terminated process 25536

Mein eigentliches Problem ist aber das im Gunde weiß gar nicht weiß wann durch das set archConfig etwas passieren sollte? Einmalig ein automatisiertes Backup beim Start, wenn das set archConfig gelesen wird? Irgendwann zu einem bestimmten Zeitpunkt?

Muß/darf set archConfig global in fhem.cfg erscheinen oder für jedes Gerät einzeln?

Auch die optionalen Parameter  -a  (evtl "all devices" oder "auto" ?) und -file sind leider nicht näher erläutert im Wiki.

Gibts evtl irgendwo mehr Doku wo man sich schlauer machen? Ohne steh ich im Moment nämlich noch etwas auf dem Schlauch....

Viele Dank im Voraus
Rainer

[frank]

Gibts evtl irgendwo mehr Doku wo man sich schlauer machen?

http://fhem.de/commandref.html#HMinfo

[rainer042]

Danke für den Hinweis,

konfiguriert habe ich jetzt

define HM HMinfo
set HM archConfig -a


sollte laut Doku eine Sicherung aller Geräte machen, die eine geänderte Config haben.

Beim Start von FHEM sehe ich folgende Fehlermeldung:
Undefined subroutine &main::CUL_HM_peersValid called at ./FHEM/98_HMinfo.pm line 1478, <$fh> line 14.

Im Logfile sehe ich wieder einen Timeout for HMinfo_archConfigExec reached, terminated process 27532

Eine neu angelegte Datei mit config-Daten kann ich leider nirgends finden.

Ich habe anstelle von archConfig auch mal saveConfig versucht (ohne Parameter). Das Ergebnis war das gleiche.

Weiß jemand was ich falsch mache?

Danke
Rainer

[frank]

vielleicht die position in der fhem.cfg ändern.

gruss frank

[martinp876]

hm - darauf bin ich noch nicht gekommen, ein Archive schon waehrend der bootphase zu starten. konnte sein, dass es zu schwierigkeiten kommt.

Generell solltest du mit allen Kommandos im fhem.cfg vorsichtig sein. Die werden ausgefuehrt, waehrend das system noch nicht alle Tassen im Schrank (entities und attribute eingerichtet) hat.
-> mach das mal besser nicht. Und mache es nur mit Kommandos, deren Auswirkungen du genau kennst.

Wenn du kommandos beim/nach dem restart ausfuehren willst, mache das nachdem FHEM initialisiert ist. Baue ein notify, das ein config-file nach dem Init startet.

Das Kommando Archive nach dem Booten auszufuehren macht wenig Sinn - da sind ja keine neuen Register gelesen. Man sollte es machen, wenn man einige getConfig o.ae. gemacht hat.

Besser ist, dass Attribut autoArchive zu setzen. Das speichert die Config immer in das File, wenn ein getConfig erfolgreich war. Das Kommando brauchst du dann nur noch in ausnahmefaellen - wenn du einmal wieder aufwaschen willst.
Commandos werden im Commandref spezifiziert, nicht in Wiki  - auch die Option -a. Wiki ist m.E. nicht dazu gedacht, das Komamndref zu wiederholen sondern den User auf Zusammenhaenge aufmerksam zu machen.

Gruss Martin

p.s.

Undefined subroutine &main::CUL_HM_peersValid called at ./FHEM/98_HMinfo.pm line 1478, <$fh> line 14.

Ein archive zu machen bevor es ueberhaupt ein HM-device gibt ist mutig - was willst du sichern? Noch nichts da.

[rainer042]

Ich war davon nicht davon ausgegangen, das schon beim lesen der Config notwendige Aktionen direkt ausgeführt werden. Ich hatte gedacht, das die Config erst einmal fertig gelesen wird, um eben etwas zu haben auf/für dem entsprechende Aktionen gestartet werden können.

Wenn man weiß das es anders herum ist, isses gut, aber man muß es eben wissen. Inzwischen habe ich eine regSave.cfg -Datei die sich im Laufe der Zeit weiter füllen sollte.

Ich fände es gut hilfreich wenn solche Informationen ihren Weg ins Wiki finden würden, das würde den Einstieg in die Nutzung von HMinfo wirklich erleichtern.

Die Idee mit dem notify ist natürlich gut. Klar ist mir aber noch nicht genau woraus das Command dann bestehen muß. Die relevante config sieht so aus:

define HM HMinfo
attr HM autoArchive
attr HM autoUpdate 00:10


Das notify so?

define initdone notify INITIALIZED set HM archConfig

Grüße
Rainer