Guten Abend,
tut mir leid, wenn ich hier so eine lapidare Frage stelle, aber ich finde zu dem Thema einfach keine Antwort.
Gibt es eine Möglichkeit zu sehen was an die HM-CC-RT-DNs gesendet werden soll?
Wenn protCmdPend seit einiger Zeit auf 221 CMDs_pending steht (Zahl für jeden HM-CC-RT-DN anders, immer hoch), und dabei protSnd + protResnd variiert - heißt das ggf. da hängt ein CMD fest?
---
langer Sinn
Der Großteil meiner HM-CC-RT-DNs hängen seit 2 Tagen aus meiner Sicht unbegründet im STATE CMDs_pending. Sie scheinen hier und da noch zu senden (so scheint es), ich bekomme sie mit viel Mühe (+ hier und da burstXmit oder shutdown restart) auch in den STATE CMDs_done (einige laufen stattdessen in MISSING ACK). Einmal im STATE CMDs_done laufen die HM-CC-RT-DNs jedoch schnell wieder voll.
Wenn ich Funktionen und Co. abschalte, welche aus meiner Sicht die einzige Last erzeugen, bleibt das Problem dennoch bestehen.
Das Problem lässt sich kaum auf spezielle HM-CC-RT-DNs eingrenzen. Einige sind im selben Raum wie hmusb, andere drei Räume weiter.
Auffällig ist, die immer hohe Zahl xxx CMDs_pending sowie, dass protCondBurst in der Zeit off ist, in CMDs_done-Zeiten on ist.
Andere Theorie:
Bei der Original Homematic Konfigurator-Software blieb die Konfiguration auch manchmal stecken, wenn man z.B. an den Temperaturlisten schraubte (alle 7 Werte für 7 Tage mit einmal änderte), einige Ranges nicht einhielt (die die JS-Engine nicht abfing). Der HM-CC-RT-DN schien dann einfach nicht zu antworten, den Befehl zu ignorieren. Man musste die Software neu laden und die Werte in kleineren Gruppen ändern.
Vielen Dank und Gruß
Robert
Sehe gerade... (... (http://forum.fhem.de/index.php/topic,14738.msg95844.html#msg95844))
> protCondBurst ist ein 'empirisch' ermittelter Wert. wird immer beim Senden ermittelt und ist zur Info.
> R_burstRx ist der Wert aus dem Device gelesen.
> FHEM verknüpft die werte nicht.
D.h. protCondBurst wird off, wenn "bursten" nicht funktioniert hat.
ZitatGibt es eine Möglichkeit zu sehen was an die HM-CC-RT-DNs gesendet werden soll?
list <dev>
ZitatWenn protCmdPend seit einiger Zeit auf 221 CMDs_pending steht (Zahl für jeden HM-CC-RT-DN anders, immer hoch), und dabei protSnd + protResnd variiert - heißt das ggf. da hängt ein CMD fest?
oder es werden genau so viele nachgeschoben, wie abgearbeitet. mache set clear msgevents.
ZitatSie scheinen hier und da noch zu senden (so scheint es)
warum auch nicht? der sendet autark alle 2,5 min. cmds_pending bedeutet ja nicht, dass das device keine befehle abarbeitet.
set clear msgevents hilft in der Tat von Zeit zu Zeit.
list <dev> ist schon sehr hilfreich wobei ich nun erstmal lernen muss was mir die dort gelisteten CMDs in HEX-Form sagen wollen.
Ich habe momentan eine Verknüpfung zu dem desired-Problem (http://forum.fhem.de/index.php/topic,34250.0.html) in Verdacht daher werde ich heute versuchen zunächst dieses Problem ausfindig zu machen. Denn solange ich desired-temp nicht anpasse, laufen keine CMDs auf.
Das Setzen einer tempList lässt reproduzierbar mindestens ein CMD verharren.
- set CUL_HM_HM_CC_RT_DN_1A2B3C_Clima tempListWed 08:00 18.0 09:00 20.0 15:00 18.0 17:00 20.0 21:00 20.0 24:00 18.0 (war vorher 08:00 18.0 09:00 20.0 15:00 18.0 17:00 20.0 21:00 18.0 24:00 18.0, R_tempList_State war verified)
- 1 CMDs_pending (~halbe Stunde gewartet)
++A0013084571A2B3C00050000000007
++A0013084571A2B3C00088450
++A0013084571A2B3C0006
Ein anderes Mal verharrten 3 CMDs bei gleichem Stack??
Nachdem Absetzen weiterer unabhängiger CMDs (regSet valveMaxPos) wächst CMDs_pending an, wird abgebaut, verharrt schließlich bei 4 CMDs_pending (~20 min gewartet).
++A0013084571A2B3C00050000000007
++A0013084571A2B3C00088450
++A0013084571A2B3C0006
++A0013084571A2B3C00050000000007
++A0013084571A2B3C04080C408450
++A0013084571A2B3C0006
set ... desired-temp 21.5 dazu (kam nicht an) und wir haben 5 CMDs_pending.
++A0013084572E90E700050000000007
++A0013084572E90E700088450
++A0013084572E90E70006
++A0013084572E90E700050000000007
++A0013084572E90E704080C408450
++A0013084572E90E70006
++A0113084572E90E786042B
Fazit: Ist einmal ein CMD verklemmt, verklemmen bald (nicht alle aber) einige weitere.
Sollte ich das Setzen per tempListWed (sicherlich auch die anderen Tage) verifizieren oder ist das Problem ggf. schon genügend bekannt / ggf. irgendwo Abhilfe notiert?
Habe hier HM-CC-RT-DNs mit Firmware 1.3 als auch 1.4 (in diesem Fall war es ein 1.3er Kandidat).
kA... zunächst ging nicht einmal mehr das Einladen per set hm tempList -f CUL_HM_HM_CC_RT_DN_1A2BB3C restore tempListTmpl/normal/O3_Kinderzimmer.tempList - es blieben CMDs in der selben Art und Weise hängen. Nach dem getConfig lagen wieder die alten Werte drin.
Nach etwas hin und her und Tests mit anderen Räumen - wo es zunächst auch nicht ging - gehts nun plötzlich in allen Räumen und allen Kombinationen/Variationen und das sogar äußerst zügig.
Im Homematic Konfiguration gab es z.B. wiederholt Probleme, wenn man alle 7 Möglichkeiten für mindestens einen Tag ausreizte wobei die Tage Mo-Fr jeweils von Mo und Sa-So jeweils von Sa geerbt waren - oder wenn man in Mo-Fr z.B. 17 Uhr von 20 auf 19 als auch Sa-So 17 Uhr von 20 auf 19 (selbe Uhrzeit) änderte.
Beide Fälle trafen jedoch vor und nach dem Hin und Her nicht zu (ich besetze nur 6 Möglichkeiten und änderte gezielt nur einen Wert). Es ergibt keinen Sinn und raubt mir nur den Verstand... Morgen werde ich nochmal gezielt nach nicht gesetzten Listen suchen und versuchen das Problem einzugrenzen oder als Ghostrider abstempeln...
Prinzipiell werden beim rt die cmds gesendet, wenn der rt sich meldet... alle 2,5min.
Wenn das nicht passiert sendet der rt nichts oder es ist ein bug im code, dass der stack klemmt.
Natuerlich kann es auch transmission fehler geben.
Mit hminfo kannst du verfolgen wie oft gesendet wurde... oder ob nichts passiert. Sollte man eigentlich selbstaendig koennen.
Schaltet man die regelmaessigen messages ab ist natuerlich schluss
> Mit hminfo kannst du verfolgen wie oft gesendet wurde
Für ein einzelnes CMD oder nur für den gesamten Stack? Btw. wären (einschaltbare?) Timestamps pro CMD sinnvoll (wann diese erzeugt wurden).
> Schaltet man die regelmaessigen messages ab ist natuerlich schluss
Du meinst clear msgEvents?
Konnte schon jemand das fehlerhafte Verhalten bei der Annahme der tempList - ob durch Homematic Konfigurator oder FHEM - bestätigen oder sehe ich Schaum?
Mir fiel noch ein dass der Homematic Konfgurator sich manchmal dann aufhing, wenn man tempList und übrige Werte zur selben Zeit änderte.
ZitatFür ein einzelnes CMD oder nur für den gesamten Stack?
für das system, nicht einzelne kommandos.
ZitatBtw. wären (einschaltbare?) Timestamps pro CMD sinnvoll (wann diese erzeugt wurden).
sehe ich nicht. man kann sich auch zu tode loggen.
wenn du loggen willst gibt es die Möglichkeit logging einzuschalten. da hast du dann timestamps.
Zitat
Du meinst clear msgEvents?
nein. ein "wakeup device" ist empfangsbereit wenn es aufwacht. Dann beginnt FHEM zu senden (wenn etwas da ist). schaltet man die messages ab (geht beim TC-IT) könnte es schwierig werden. Wenn FHEM nicht mehr weiss, wann das device aufwacht klappt es nicht mehr. Ist aber ein exotischer Fall... wir hatten es einmal für VDs gelöst.
Zitat
Konnte schon jemand das fehlerhafte Verhalten bei der Annahme der tempList - ob durch Homematic Konfigurator oder FHEM - bestätigen oder sehe ich Schaum?
ich kenne den Fall nicht wirklich... es gibt m.e. noch einen ungeklärten Threat in diese Richtung.
Bei mir klappt es einwandfrei. Generell kann es immer wieder zu Störungen der Übertragung kommen. Ist man am konfigurieren sollte man die (hoffentlich) bekannten Mechanismen nutzen, das Ergebnis zu prüfen, zu sichern, zu verifizieren. Ebenso die Übertragung.
templisten sind keine Ausnahme - hier stehen sogar besonders gute Mechanismen zu Verfügung, das Ergebnis sicherzustellen.
FHEM/CUL_HM stellt ein begrenzt gesichertes Verfahren zur Übertragung und Überwachung zu Verfügung. Der Operator ist verpflichtet ein paar Prüfungen vorzunehmen.
ZitatMir fiel noch ein dass der Homematic Konfgurator sich manchmal dann aufhing, wenn man tempList und übrige Werte zur selben Zeit änderte.
kenne ich nicht.
Ein guter Hinweis von dir ist, eine warnung in HMInfo aufzunehmen, wenn der command-stack zu groß wird... werde einmal etwas ausdenken. Es ist in jedem Fall einen Hinweis wert. Aktuell ist es mit protoEvents schon sichtbar (m.E. eine unverzichtbare Abfrage für einen Operator beim Konfigurieren)
Vielen Dank für die Unterstützung :)
> wenn du loggen willst gibt es die Möglichkeit logging einzuschalten. da hast du dann timestamps.
How to?
>> Homematic Konfigurator
> kenne ich nicht.
Den Konfigurator oder die temporären Probleme mit diesem?
Das Problem war heute relativ kritisch. Zwischen dem letzten > kA... ... Nach etwas hin und her ... gehts nun plötzlich und heute Abend alles ohne Probleme. Alle Geräte problemlos seit 4 Tagen CMDs_done (es werden regelmäßig tempList und sehr oft valveMaxPos angepasst).
Heute dann sank die Temperatur im Ki-Zi unter 15°C (daher kritisch). Kein HM-CC-RT-DN reagierte mehr auf die gewöhnlichen Anpassungen. Zwar empfingen die HM-CC-RT-DNs Anweisungen zur desired-temp, ignorierten jedoch getConfig, regSet valveMaxPos.
(Als wenn der HM-CC-RT-DN Registeränderungen allg. ablehnt / auf Änderungen nicht reagiert? Im Boost-Modus lassen sich auch manchmal nur schwer Register ändern - da vermutlich weil er runterzählt und damit mit sich selbst zu sehr beschäftigt ist?)
clear msgEvents schien zunächst zu helfen. CMDs klemmten jedoch dann sehr bald erneut. Nach Neustart hmland endlich fingen sich die HM-CC-RT-DNs relativ schnell wieder (brauchte nicht mal mehr ein zweites clear msgEvents, lediglich zwei getConfigs für zwei der acht HM-CC-RT-DNs).
Ich habe mal ein paar Dateien angehangen. Hoffe deren Dateiname erklärt die Herkunft genügend.
Ggf. wäre es sinnvoll zu wissen, welche Infos ich in einem erneuten solchen Fall sammeln kann um letztendlich zu ermitteln ob
A) die Art und Weise meiner Anwendung Zustände erzeugt, welche zu special sind (und wen ja, welche damit ich diese ggf. umschiffen kann)
B) hier ein generelles Problem vorliegt
Das einzige was ich registrieren kann ist, dass (u.a. Kind zu dem Zeitpunkt zwei gepeerte HM-CC-RT-DNs auf 18°C + manuell gestellt hatte ;) und) nach einem reread FHEM aufgrund einer ungünstig platzierten notify die tempLists aller HM-CC-RT-DNs schrieb.
Seit dem schaukelten sich in fast allen HM-CC-RT-DNs CMDs fest. Zunächst hängt 1 CMD fest, danach getConfig-CMDs wovon viele abgearbeitet werden, aber einige hängen bleiben.
mach doch mal anständige logs
http://forum.fhem.de/index.php/topic,16563.0.html (http://forum.fhem.de/index.php/topic,16563.0.html)
wie dein System aussieht hab ich noch nicht wirklich begriffen,
soviele resends wie du hast, würde ich vermuten, dass du ein timing problem hast.
Ich hänge mir das mal hier rein. Da gerade zufällig per Google drüber gestolpert.
- http://forum.fhem.de/index.php?topic=14738.760;wap2
Hinterher Logs zu haben, denk ich mir auch immer, ja. Vor einigen Tagen hatte ich das Logaufkommen als Ursache für MISSING ACKs in Verdacht - daher leider reduziert. Ohnehin verstehe ich den HMLAN-Traffic noch sehr wenig.
Hier läuft ein hmusb über hmland zusammen mit FHEM in einer Windows-Kiste AMD Phenom II X4 955, 4GB RAM, SSD (sobald ich FHEM-Land sehe ;) ist kurzfristig der Umzug auf eine NUC-Kiste oder vlt. auch Tablet oder dergleichen geplant).
Am hmusb hängen 8 HM-CC-RT-DN. In der Ecke liegen zwei Fensterkontakte (ungenutzt da Fensteroffenfunktion der HM-CC-RT-DNs gut genug funktionieren).
Ende 2014 hatte ich mir die Komponenten angeschafft. Ich habe mir jedoch von der Homematic-Software zu viel erhofft. Das Erhoffte habe ich mir inzwischen dazu gefehmt+geperlt.
Grundproblem ist, dass die Vorlauftemperatur schwankt. Alle 2h, Sonnenuntergang, Nachts 2 Uhr plötzlich +4 Grad (ja, inzwischen kenne ich die Pappnasen). Daher passe ich in einer Perlfunktion die valveMaxPos nach Bedarf an und treibe damit wohl die HM-CC-RT-DNs sowie die FHEMseitige Unterstützung an Grenzen.
- Registerschreiben setzt wohl desired-temp manchmal zurück
- ggf. EEPROM-Problem (http://forum.fhem.de/index.php?topic=34434.new;topicseen#new)
- boost kann nicht mehr von Haus aus genutzt werden - (Habe heute die 5. Lösung angesetzt um valveMaxPos wieder zu öffnen, wenn boost gedrückt. Allerdings reagiert der HM-CC-RT-DN im Boost-Modus komisch (empfängt manchmal nicht), valveMaxPos wird zudem erst angewandt wenn Boost aus und wieder an...)
Letzter Akt ist das Schreiben der tempList nach dem Umstellen von "ich bin unterwegs|zuHause|auto"-Buttons mit vorsichtig eingebrachter Anwesenheitserkennung über die Devicelist meines Routers (WLAN-Geräte RSSI).
Da sich aber tempListen so schlecht schreiben lassen, stehe ich auf dem Schlauch ;)
Wenn alles nix hilft gehe ich auf manual und setz die desired-temp so, dass measured nach ausgehandeltem Plan stimmt. Momentan läuft es jedoch gut und man lernt nebenbei etwas Perl ;)
> Da sich aber tempListen so schlecht schreiben lassen, stehe ich auf dem Schlauch ;)
Ich hatte in beide Fällen festgestellt, dass sich das Problem aufhebt, wenn bei allen HM-CC-RT-DN die CMDs gelöscht werden + hmland neugestartet wird. Ich vermute bald, dass ich der hmusb/hmland irgendwo verhakt.
> über die Devicelist meines Routers (WLAN-Geräte RSSI)
lan-ping meldet seit Einrichtung und einiger Ausführung nur noch "STATE active" und so recht wusste ich nicht ob dies ein weiterer Kandidat ist, welcher FHEM ggf. blockiert.