hall martin,
1. nach fhem update und restart zeigt cul_hm im log zu jedem befehl 2 einträge.
der erste zeigt in der regel "no Arg" (ausnahme bei set inhibit).
alle cu_hm einträge bis ca 10min nach restart:
2020.08.24 08:56:53.022 3: CUL_HM set DimUP01 statusRequest noArg
2020.08.24 08:56:53.049 3: CUL_HM set DimUP01 statusRequest
2020.08.24 08:56:54.138 3: CUL_HM set Thermostat.Keller statusRequest noArg
2020.08.24 08:56:54.140 3: CUL_HM set Thermostat.Keller statusRequest
2020.08.24 08:56:54.237 3: CUL_HM set Thermostat.Bad.OG statusRequest noArg
2020.08.24 08:56:54.239 3: CUL_HM set Thermostat.Bad.OG statusRequest
2020.08.24 08:56:54.593 3: CUL_HM set DimUP01 inhibit on
2020.08.24 08:56:54.628 3: CUL_HM set DimUP01 inhibit on
2020.08.24 08:56:55.826 3: CUL_HM set DimUP01 off noArg
2020.08.24 08:56:55.844 3: CUL_HM set DimUP01 off
2020.08.24 08:56:55.867 3: CUL_HM set SwitchUP02 off noArg
2020.08.24 08:56:55.901 3: CUL_HM set SwitchUP02 off
2020.08.24 08:56:55.923 3: CUL_HM set SwitchES01_Sw off noArg
2020.08.24 08:56:55.975 3: CUL_HM set SwitchES01_Sw off
2020.08.24 08:56:56.105 3: CUL_HM set Thermostat.SZ statusRequest noArg
2020.08.24 08:56:56.106 3: CUL_HM set Thermostat.SZ statusRequest
2020.08.24 08:56:56.230 3: CUL_HM set Thermostat.GZ statusRequest noArg
2020.08.24 08:56:56.231 3: CUL_HM set Thermostat.GZ statusRequest
2020.08.24 08:56:56.282 3: CUL_HM set Thermostat.OZ statusRequest noArg
2020.08.24 08:56:56.284 3: CUL_HM set Thermostat.OZ statusRequest
2020.08.24 08:56:56.407 3: CUL_HM set Thermostat.Bad statusRequest noArg
2020.08.24 08:56:56.408 3: CUL_HM set Thermostat.Bad statusRequest
2020.08.24 08:56:56.572 3: CUL_HM set SD.AZ statusRequest noArg
2020.08.24 08:56:56.589 3: CUL_HM set SD.AZ statusRequest
2020.08.24 08:56:57.012 3: CUL_HM set Thermostat.WZ statusRequest noArg
2020.08.24 08:56:57.014 3: CUL_HM set Thermostat.WZ statusRequest
2020.08.24 08:56:57.622 3: CUL_HM set SD.SZ statusRequest noArg
2020.08.24 08:56:57.640 3: CUL_HM set SD.SZ statusRequest
2020.08.24 08:56:58.667 3: CUL_HM set SD.WZ statusRequest noArg
2020.08.24 08:56:58.684 3: CUL_HM set SD.WZ statusRequest
2020.08.24 08:56:59.823 3: CUL_HM set SwitchES01_Sw statusRequest noArg
2020.08.24 08:56:59.859 3: CUL_HM set SwitchES01_Sw statusRequest
2020.08.24 08:57:00.896 3: CUL_HM set SwitchPBU03 statusRequest noArg
2020.08.24 08:57:00.914 3: CUL_HM set SwitchPBU03 statusRequest
2020.08.24 08:57:01.964 3: CUL_HM set SwitchPBU06 statusRequest noArg
2020.08.24 08:57:01.983 3: CUL_HM set SwitchPBU06 statusRequest
2020.08.24 08:57:03.033 3: CUL_HM set SwitchUP01 statusRequest noArg
2020.08.24 08:57:03.053 3: CUL_HM set SwitchUP01 statusRequest
2020.08.24 08:57:17.189 3: CUL_HM set Thermostat.AZ statusRequest noArg
2020.08.24 08:57:17.191 3: CUL_HM set Thermostat.AZ statusRequest
2020.08.24 08:58:01.748 3: CUL_HM set Thermostat.Kueche statusRequest noArg
2020.08.24 08:58:01.752 3: CUL_HM set Thermostat.Kueche statusRequest
2020.08.24 09:01:23.645 3: CUL_HM set ActionDetector update noArg
2020.08.24 09:01:23.703 3: CUL_HM set ccu update noArg
2020.08.24 09:06:24.130 3: CUL_HM set ActionDetector update noArg
2020.08.24 09:06:24.159 3: CUL_HM set ccu update noArg
2. der actiondetector macht nach dem log alle 5min ein update, obwohl es eigentlich 10min sein sollten, da ich beim actiodetector kein attr actCycle gesetzt habe.
hat sich der default wert geändert?
oder gibt es einen zusammenhang mit meinem autoupdate bei hminfo von 5min?
3. schon etwas länger zeigen einige entities ein template missmatch nach dem start:
Device name:Thermostat.WZ
mId :0039 Model=HM-CC-TC
mode :config,wakeup,burstCond - activity:alive
protState : CMDs_done pending: none
configuration check: TmplChk
TmplChk: template mismatch
=>- tc1:template undefined
das angeblich nicht vorhandene template, wird aber nur in einigen devices als "undefined" angemeckert.
das problem besteht auch nicht nur bei diesem template.
sobald ich ein hminfo configcheck starte, um eine liste aller betroffenen devices zu bekommen, ist alles in ordnung.
der manuelle check "repariert" sofort alles.
4. wenn hminfo die "cfgState" fehler sammeln und anzeigen würde, hätte man eine schöne liste. ;)
Hallo,
Bei der Funk-Statusanzeige LED16 (HM-OU-LED16) funktioniert die Helligkeitseinstellung nicht mehr:
Nach Eingabe des Kommandos "set Statusanzeige2 ilum 3 0" erscheint die Fehlermeldung:
param 0:'(0-15)' => 3 does not match options
ilum: (0-15) (0-127)
Nach Eingabe des Kommandos "set Statusanzeige2 ilum 0 20" erscheint die Fehlermeldung:
param 1:'(0-127)' => 20 does not match options
ilum: (0-15) (0-127)
Nur die Kommandos mit den Parameterangaben ilum 0 0, ilum 15 0, ilum 0 127 und ilum 15 127 funktionieren.
Grüße
Hallo Frank,
zu 1.
das ist jetzt normal, seit Martin das Parameterparsing nach HMConfig Vorgaben eingeführt hat. Es werden in der ersten der beiden Zeilem dann die dabei automatisch ergänzten Defaults (entsprechend HMConfig Vorgaben und Parameterparsing-Code) angezeigt.
Das ist dann das, was als modifizierter Befehl tatsächlich im weiteren ausgeführt wird.
Die zweite Zeile kommt nach (erfolgreicher) Ausführung (aber bevor die Kommandos an devices gesendet werden) und entspricht unmodifiziert dem, was als Parameter in HM_Set reingegeben wurde.
zu 2.
im CUL_HM Code stehen 600 Sekunden als default Intervall für den ActionDetector. Zu hminfo Einfluss kann ich nichts sagen, aber setz doch einfach mal das hminfo Update Intervall hoch.
zu 3.
@Martin: Nur eine Idee. Eventuell sind die Listen für diese Entities (nur Devices oder auch Channels?) noch nicht aktualisiert.
zu 4.
Martin hat CUL_HM als "Fertig" beschrieben (@Martin: Vielen Dank für die viele Arbeit und schon mal für's weiter Warten!).
HMInfo nicht explizit. Du kannst hoffen. ;)
Gruß, Ansgar.
Hallo Martin,
Zitatparam 0:'(0-15)' => 3 does not match options
ilum: (0-15) (0-127)
Ich denke HMConfig Zeile 1827:
,ilum => "(0..15;1) (0..127;1)"Gruß, Ansgar.
Zitat von: noansi am 24 August 2020, 12:00:27
Hallo Frank,
zu 1.
das ist jetzt normal, seit Martin das Parameterparsing nach HMConfig Vorgaben eingeführt hat. Es werden in der ersten der beiden Zeilem dann die dabei automatisch ergänzten Defaults (entsprechend HMConfig Vorgaben und Parameterparsing-Code) angezeigt.
Das ist dann das, was als modifizierter Befehl tatsächlich im weiteren ausgeführt wird.
Die zweite Zeile kommt nach (erfolgreicher) Ausführung (aber bevor die Kommandos an devices gesendet werden) und entspricht unmodifiziert dem, was als Parameter in HM_Set reingegeben wurde.
zu 2.
im CUL_HM Code stehen 600 Sekunden als default Intervall für den ActionDetector. Zu hminfo Einfluss kann ich nichts sagen, aber setz doch einfach mal das hminfo Update Intervall hoch.
zu 3.
@Martin: Nur eine Idee. Eventuell sind die Listen für diese Entities (nur Devices oder auch Channels?) noch nicht aktualisiert.
zu 4.
Martin hat CUL_HM als "Fertig" beschrieben (@Martin: Vielen Dank für die viele Arbeit und schon mal für's weiter Warten!).
HMInfo nicht explizit. Du kannst hoffen. ;)
Gruß, Ansgar.
zu 1.
ok, danke für die erklärung.
dann wäre für die 1. meldung ein höherer verboselevel ganz sinnvoll, oder?
zu 2.
ich habe hminfo update mal auf 13min gestellt:
2020.08.24 12:13:31.155 3: CUL_HM set ActionDetector update noArg
2020.08.24 12:23:36.895 3: CUL_HM set ActionDetector update noArg
2020.08.24 12:26:31.249 3: CUL_HM set ActionDetector update noArg
2020.08.24 12:36:36.978 3: CUL_HM set ActionDetector update noArg
2020.08.24 12:39:31.338 3: CUL_HM set ActionDetector update noArg
2020.08.24 12:49:37.064 3: CUL_HM set ActionDetector update noArg
2020.08.24 12:52:31.510 3: CUL_HM set ActionDetector update noArgsieht aus, als würde der actiondetector update nur dann vom eigenen timer (10min) gestartet, wenn hminfo (13min) den actiondetector nicht schon vorher gestartet hat.
die längste zeit zwischen 2 updates ist dann der actCycle vom actiondetector.
falls hminfo zwischendurch updatet, startet der actiondetectortimer neu.
der erste update muss von hminfo getriggert worden sein.
danach immer abwechselnd vom actiondetector selber und wieder hminfo.
zu 3.
es betrifft scheinbar immer die selben entities.
zu 4.
das war zumindestens auch schon martins eigene idee.
ich wollte nur noch mal mit dem "zaunpfahl" winken. ;)
Hallo Frank,
Zitatdann wäre für die 1. meldung ein höherer verboselevel ganz sinnvoll, oder?
Im Sinne Deiner umfangreichen Supportbemühungen (Danke! Und Danke für hm.js!) würde ich eher die 2. Meldung mit höherem Level sehen, da ohne die 2. Meldung eher eine aufklärende Fehlerrückgabe zu erwarten ist.
Die erste sagt deutlicher was wirklich ausgeführt wird und der User kann seine Eingabe meist durchaus kennen und mitteilen.
zu 2. also wohl ein gewolltes Verhalten?! Zumindest entsinne ich mich daran, dass hminfo nur mit großem Intevall von Martin empfohlen ist, wegen der Rechenzeit (auf langsamer Hardware ein schlagendes Argument). Dann würde es nicht stören und hminfo bekäme trotzdem aktuelle Daten, sofern das ActionDetector Update rechtzeitig im HMInfo Code ausgelöst wird.
zu 3. HM-Devices oder HM-Channels von Devices? Oder beides?
Gruß, Ansgar.
Hallo Frank,
noch zu 2.
HMInfo führt beim Autoupdate ein CUL_HM_Set update für den ActionDetector aus, um eben aktuelle Daten zu haben, wie vermutet.
Das erklärt Deine Beobachtungen und bedeutet auch, dass damit der ActionDetetctor Timer neu gestartet wird.
Es bleibt aber dabei, dass HMInfo update alle 5 Minuten nicht das empfohlene Vorgehen sein sollte.
Gruß, Ansgar.
So, einmal für mich zur wiederholung
1) Die Logs sind Log-Level 3. Ist das bei dir eingeschaltet?
2) noArg ist eine Option eqiuvalent zu ... nichts. Wenn ein Parameter optional ist, also [(param1|param2)] kann man ihn auch weglassen. Sendest du das Kommando per script oder Funktion ist das möglich.
Bei Kommandos mit nur einem Parameter, welchen man in einer Liste darstellen kann, biete ich eine Auswahlliste an. Wenn du nun aus der Liste ein "nichts" angeben willst brauche ich einen Eintrag. Schliesslich muss alles , was per Kommando geht auch in der Liste erscheinen....
Tiefer in der SW ist nun aufgeräumt - somit erhält die Funktion für nicht angegebene, optionale parameter immer ein noArg
3) ActionCycle:
bei einem List ActioDetector sollte ein "helper->actCycle = 600" erscheinen. Das ist nicht verändert.
Sollte beim Booten ein "update" aufgerufen werden wird dieser asgeführt und der Timer auf 600 gestellt.
Kannst du prüfen, ob der timer 2-mal läuft? Eigentlich lösche ich sicherheitshalber aller ActioDetedtor timer
4) templates:
mache einmal ein
get hm templateList all
Da sind alle aktiven templates enthalten.
dann ein
get hm templateUsgG sortTemplate
5) cfgState Fehler:
HMInfo ist konfigurierbar, was das Fehler-sammeln angeht. "sumError" erlaubt dir, die Readings anzugeben, welche dich interessieren. Weiter gibst du den Wert des Readings an, welcher KEIN Fehler ist. Alles andere wird eingeblendet.
Bei mir läuft es schon.... Da der Anwender das Attribut ändern darf kann ich es nicht überschreiben. Liegt also bei euch, es nachzutragen.
p.s.: Das ist schon seit "immer" so implementiert
6) ilum
mein Fehler in der Definition (HMConfig). Es muss (0..15) (0..127) heissen. Wird behoben.
7) mit Fertig habe ich klar maintenance ausgeschlossen (also nicht beendet).
8) Verbose level zu Command indication: Es ist level 3 - welcher per default "off" ist. Sollte also passen
9) ein HMInfo Status stellt den Action detector Status dar - nacheinem Update natürlich aktuell. Daher wird durch den Update der Timer verändert.
Technisch ok, schlechte Doku . Sorry.
Neu:
a) HMinfo wird ein Attribut verbCULHM bekommen (morgen) mit welchem man alle set oder get commands loggen kann. Das einschalten je device regt mich auf. Es übersteuert das Verbose des Device
b) ich hatte den Speed-increas teilweise ausser betrieb gesetzt. Sorry auch hierfür (auch wenn es keiner realisiert).
Hallo Martin,
https://forum.fhem.de/index.php/topic,113771.msg1080393.html#msg1080393 (https://forum.fhem.de/index.php/topic,113771.msg1080393.html#msg1080393) bitte beachten. Für virtTemp wird keine DropDownListe angezeigt, weil das - von -20.0 noch nicht matched.
Zitat6) ilum
mein Fehler in der Definition (HMConfig). Es muss (0..15) (0..127) heissen. Wird behoben.
Da der Default Step auf 0.5 gewählt ist,
denke ich (0..15;1) (0..127;1) wäre richtiger. Ist erledigt.
Nebenbei virtHum mit step 0.1 macht keinen Sinn, weil der Wert direkt in ein Byte verpackt gesendet wird. Also auch dafür step 1 (HMConfig Zeile 2048), entsprechend unterstützter Auflösung.
zu 2) https://forum.fhem.de/index.php/topic,113776.0.html (https://forum.fhem.de/index.php/topic,113776.0.html) ist damit nicht gelöst.
Zitatb) ich hatte den Speed-increas teilweise ausser betrieb gesetzt. Sorry auch hierfür (auch wenn es keiner realisiert).
Du meinst das || 1, doch hab ich, und direkt wieder bei mir im Code entfernt. :)
Das hat aber kein Fehlverhalten erzeugt, von daher meinerseits zurückgestellt.
Gruß, Ansgar.
Seit den letzten Updates habe ich Probleme mit meiner HM-Dis-WM55 Funk Statusanzeige.
Im Logfile erscheinen nun folgenede Fehlermeldungen :
userCfg return value: param 3:'-color1-' => is required but missing
displayWM: (long|short|help) -lineX- -textNo1- -color1- -icon1- [-textNo2- -color2- -icon2-] [...] [-textNo6- -color6- -icon6-]
param 3:'-color1-' => is required but missing
displayWM: (long|short|help) -lineX- -textNo1- -color1- -icon1- [-textNo2- -color2- -icon2-] [...] [-textNo6- -color6- -icon6-]
param 3:'-color1-' => is required but missing
...usw.
Konfiguriert wurde das Teil entsprechend der FHEM-Wiki (HM-Dis-WM55) mit den dort beschriebenen Einträgen in der "fhemUser.cfg" und in den "99_myUtils".
Funktioniert hat alles tadellos bis zur "10_CUL_HM.pm" vom 2020-08-21. Bei den nachfolgenden Updates erschienen dann die genannten Fehlermeldungen.
Was muss ich ändern ? Oder liegt der Fehler im System ?
Zitat von: wwiesner am 25 August 2020, 09:47:12
Seit den letzten Updates habe ich Probleme mit meiner HM-Dis-WM55 Funk Statusanzeige.
Im Logfile erscheinen nun folgenede Fehlermeldungen :
userCfg return value: param 3:'-color1-' => is required but missing
displayWM: (long|short|help) -lineX- -textNo1- -color1- -icon1- [-textNo2- -color2- -icon2-] [...] [-textNo6- -color6- -icon6-]
param 3:'-color1-' => is required but missing
displayWM: (long|short|help) -lineX- -textNo1- -color1- -icon1- [-textNo2- -color2- -icon2-] [...] [-textNo6- -color6- -icon6-]
param 3:'-color1-' => is required but missing
...usw.
Was muss ich ändern ? Oder liegt der Fehler im System ?
Konfiguriert wurde das Teil entsprechend der FHEM-Wiki (HM-Dis-WM55) mit den dort beschriebenen Einträgen in der "fhemUser.cfg" und in den "99_myUtils".
Funktioniert hat alles tadellos bis zur "10_CUL_HM.pm" vom 2020-08-21. Bei den nachfolgenden Updates erschienen dann die genannten Fehlermeldungen.
Da bist Du nicht alleine. Habe ich auch schon gemeldet: https://forum.fhem.de/index.php/topic,113776.0.html (https://forum.fhem.de/index.php/topic,113776.0.html)
Zitat von: noansi am 24 August 2020, 14:34:28
zu 2. also wohl ein gewolltes Verhalten?! Zumindest entsinne ich mich daran, dass hminfo nur mit großem Intevall von Martin empfohlen ist, wegen der Rechenzeit (auf langsamer Hardware ein schlagendes Argument). Dann würde es nicht stören und hminfo bekäme trotzdem aktuelle Daten, sofern das ActionDetector Update rechtzeitig im HMInfo Code ausgelöst wird.
diese empfehlung kenne ich.
aber ebenso die "ständigen" hinweise: "warum nutzt ihr nicht die fehlererkennung von hminfo? hminfo macht das resourcenschonend und bietet alles, was man braucht"
wenn man nun die fehlererkennung nutzt (zb auch im zusammenspiel mit HMinfoTools.js ;) ), muss man natürlich einen gesunden mittelweg finden:
möglichst schnelle alarmierung vs keine fhem überlastung
zur überlastung mal meine erfahrungen: ich nutze fhem auf pi3 mit raspian lite.
anfänglich nur fhem mit jessie auf dem pi.
irgendwann upgrade auf stretch, um zusätzlich debmatic zu nutzen.
seit ein paar tagen upgrade auf buster, um zusätzlich ein headless firefox zum rendern von screenshots zu nutzen.
mit fhem, debmatic und firefox ist der pi beim ram nun noch gut nutzbar mit etwas reserve.
bei der auslastung sieht man nun auch endlich mal, dass er was tut.
ich würde sagen, dass dieser pi3 nun gut ausgelastet ist. die firefox nutzung ist allerdings noch unter strenger beobachtung.
als indikator für eine überlastung von fhem habe ich ständig 6x hm-cc-vd (die alten heizkörperventile) im blick.
da diese bei mir direkt über fhem mit virtuellen hm-cc-tc bedient werden, sehe ich sofort, wenn freezes in fhem auftreten. ohne präzises timing über fhem fallen diese ziehmlich schnell in einen "tiefschlaf" und sind frühestens nach über einer stunde erst wieder erreichbar.
im durchschnit habe ich 2-5 fehlkommunikationen von ca 200 - 600 pro tag.
diese werte sind über all die jahre ziehmlich konstant.
seitdem ich das hminfo update von 10min auf 5min reduziert habe, gab es keine negativen effekte.
sinnvolle hminfo-update-intervalle:bisher gab es ja keine trigger von hminfo auf den actiondetector.
somit hat es im schlechtesten fall bisher (actCycle_device + actCycle_actiondetector + hminfo_update) gedauert, bis eine dead-meldung von hminfo erzeugt worden ist. also zb (10min + 10min + 10min) = 30min.
für einen "normalen" sensor sicherlich akzeptabel. aber den ausfall (tiefschlaf) eines meiner heizungsventile habe ich im winter bereits vorher gespürt, also dafür eher ein zu langes interval.
von daher würde ich die aktuelle situation begrüssen, dass hminfo den actiondetector zusätzlich triggert.
dadurch würden sich nicht mehr "sinnlos" beide timer-zeiten addieren, sondern der kürzeste kommt zum tragen.
wenn man hminfo wirklich sinnvoll zur fehlererkennung nutzen möchte, hängt das kürzeste hminfo-update-interval eigentlich von der sabotage_attack_erkennung ab, finde ich. das möchte ich wirklich zeitnah erkennen können, um eventuell massnahmen zu ergreifen.
somit kann ich eigentlich 5min für ein hminfo-update-interval wämstens empfehlen.
Zitat von: martinp876 am 24 August 2020, 17:40:16
So, einmal für mich zur wiederholung
1) Die Logs sind Log-Level 3. Ist das bei dir eingeschaltet?
2) noArg ist eine Option eqiuvalent zu ... nichts. Wenn ein Parameter optional ist, also [(param1|param2)] kann man ihn auch weglassen. Sendest du das Kommando per script oder Funktion ist das möglich.
Bei Kommandos mit nur einem Parameter, welchen man in einer Liste darstellen kann, biete ich eine Auswahlliste an. Wenn du nun aus der Liste ein "nichts" angeben willst brauche ich einen Eintrag. Schliesslich muss alles , was per Kommando geht auch in der Liste erscheinen....
Tiefer in der SW ist nun aufgeräumt - somit erhält die Funktion für nicht angegebene, optionale parameter immer ein noArg
3) ActionCycle:
bei einem List ActioDetector sollte ein "helper->actCycle = 600" erscheinen. Das ist nicht verändert.
Sollte beim Booten ein "update" aufgerufen werden wird dieser asgeführt und der Timer auf 600 gestellt.
Kannst du prüfen, ob der timer 2-mal läuft? Eigentlich lösche ich sicherheitshalber aller ActioDetedtor timer
4) templates:
mache einmal ein
get hm templateList all
Da sind alle aktiven templates enthalten.
dann ein
get hm templateUsgG sortTemplate
5) cfgState Fehler:
HMInfo ist konfigurierbar, was das Fehler-sammeln angeht. "sumError" erlaubt dir, die Readings anzugeben, welche dich interessieren. Weiter gibst du den Wert des Readings an, welcher KEIN Fehler ist. Alles andere wird eingeblendet.
Bei mir läuft es schon.... Da der Anwender das Attribut ändern darf kann ich es nicht überschreiben. Liegt also bei euch, es nachzutragen.
p.s.: Das ist schon seit "immer" so implementiert
zu 1)
genau. ich habe global verbose=3, sollte default sein.
in den entities habe ich kein verbose attribut gesetzt.
den sinn habe ich nun verstanden.
ich denke trotzdem, dass bei verbose 3 ein eintrag reicht. welcher ist mir egal.
zu 2)
danke, verstanden
zu 3)
der timer vom actiondetector ist ok und im list auch vorhanden.
hminfo update triggert aber neuerdings den actiondetector und startet den timer vom actiondetector neu.
Zitat von: frank am 24 August 2020, 13:40:25
ich habe hminfo update mal auf 13min gestellt:
2020.08.24 12:13:31.155 3: CUL_HM set ActionDetector update noArg
2020.08.24 12:23:36.895 3: CUL_HM set ActionDetector update noArg
2020.08.24 12:26:31.249 3: CUL_HM set ActionDetector update noArg
2020.08.24 12:36:36.978 3: CUL_HM set ActionDetector update noArg
2020.08.24 12:39:31.338 3: CUL_HM set ActionDetector update noArg
2020.08.24 12:49:37.064 3: CUL_HM set ActionDetector update noArg
2020.08.24 12:52:31.510 3: CUL_HM set ActionDetector update noArg
sieht aus, als würde der actiondetector update nur dann vom eigenen timer (10min) gestartet, wenn hminfo (13min) den actiondetector nicht schon vorher gestartet hat.
die längste zeit zwischen 2 updates ist dann der actCycle vom actiondetector.
falls hminfo zwischendurch updatet, startet der actiondetectortimer neu.
der erste update muss von hminfo getriggert worden sein.
danach immer abwechselnd vom actiondetector selber und wieder hminfo.
gut zu erkennen, wenn man im actiondetector event-on-change abschaltet und dann zb manuell hminfo update auslöst.
dieses neue "feature" finde ich gut, wenn man hminfo autoupdate nutzt. siehe vorherigen post.
es war nur verwirrend.
zu 4)
mein template "tc1" wird unter "hminfo templateList all" angezeigt:
tc1 params:a b c d Info:hallohminfo templateUsgG sortTemplate zeigt die nutzung für 9 devices:
tc1 |Thermostat.AZ |0|auto 25 off on
tc1 |Thermostat.Bad |0|auto 25 off on
tc1 |Thermostat.Bad.OG|0|auto 15 off off
tc1 |Thermostat.GZ |0|auto 15 off off
tc1 |Thermostat.Keller|0|auto 15 off off
tc1 |Thermostat.Kueche|0|auto 25 off on
tc1 |Thermostat.OZ |0|auto 15 off off
tc1 |Thermostat.SZ |0|auto 15 off off
tc1 |Thermostat.WZ |0|auto 25 off onaber hminfo meldet nach restart für 2 devices trotzdem, dass das template undefined sei.
ein manueller "hminfo configCheck" entfernt die falschen fehler.
zu 5)
sorry, das kenne ich zwar, ist mir aber im zusammenhang mit cfgState überhaupt nicht in den sinn gekommen.
wäre trotzdem sinnvoll, wenn es per default im attribut gesetzt wäre. oder ist es das auch?
es funktioniert sogar zu gut => es werden auch alle ignored entities mit config-fehlern angezeigt.
Hallo Frank,
Zitatsomit kann ich eigentlich 5min für ein hminfo-update-interval wämstens empfehlen.
Das führt hier zwar ab vom Problemthema, aber ich habe mal apptm (meine Variante von apptime) bemüht.
set hminfo update -> max 861.13ms und mean 624.59ms über 12 update-Durchläufe (Raspberry Pi Modell B Rev.2 -> keine Rakete ;) aber für meine Zwecke schnell genug)
Das liegt bei mir also sehr deutlich über ca. 120ms Antwortzeit für HM Kommunikation. Kann also bei der Abarbeitung von Sendewarteschlangen stören, wenn es zum ungünstigen Zeitpunkt aufgerufen wird. (HM-Device schläft darüber wieder ein, Acks, die durchs System laufen, werden zu lange verzögert).
Von meiner Warte aus also keine generelle Empfehlung für kurze HMInfo Update Intervalle. Das muss jeder für sich und seine Hardwareumgebung selbst testen.
Gruß, Ansgar.
hallo ansgar,
feine info.
mein normales apptime zählt für 12x hminfo update wohl noch was anderes dazu, da count=22.
name function max count total average maxDly avgDly TS Max call param Max call
hminfo HMinfo_SetFn 313 22 2363.41 107.43 0.00 0.00 25.08. 13:34:34 HASH(hminfo); hminfo; update
gruss frank
Hallo Frank,
ich hab update im webCmd und löse es darüber aus.
Wenn Du es als "set hminfo update" oben eingibst, dann kommt es zum Seitenupdate, was wiederum die möglichen Kommandos abruft und dabei wieder HMInfo_SetFn (das liegt bei mir dann unter 1ms). Dein average ist demnach wohl verfälscht.
Das (beim Seitenupdate-/Aufruf) für CUL_HM zu beschleunigen ist Martins Hauptintention für die letzten updates, wie ich es verstanden habe. :) :) :)
Gruß, Ansgar.
PS: und da 22 != 12*2 hast Du vielleicht auch noch was anderes gemacht
Zitatich hab update im webCmd und löse es darüber aus.
genau das habe ich auch gemacht.
12x auf update geklickt, mit je ca 5s pause, kein neuladen der website.
in der webkonsole wird auch immer nur ein "hminfo update" rausgehauen.
mit 22/2=11 habe ich mich vielleicht verzählt, oder ein click hat nichts bewirkt. ;)
edit: jetzt habe ich die konsole beobachtet und noch mal 12 update mit abstand 2-3s rausgehauen:
name function max count total average maxDly avgDly TS Max call param Max call
hminfo HMinfo_SetFn 204 24 2237.10 93.21 0.00 0.00 25.08. 14:27:44 HASH(hminfo); hminfo; updatealso beim ersten mal hat wohl ein klick nicht gezündet.
aber interessant, dass bei 2-3s abstand die verzögerungen deutlich besser geworden sind. :)
in fhem.log sieht das so aus:
2020.08.25 14:27:17.581 3: CUL_HM set ActionDetector update noArg
2020.08.25 14:27:17.688 3: CUL_HM set ccu update noArg
2020.08.25 14:27:20.453 3: CUL_HM set ActionDetector update noArg
2020.08.25 14:27:20.552 3: CUL_HM set ccu update noArg
2020.08.25 14:27:23.631 3: CUL_HM set ActionDetector update noArg
2020.08.25 14:27:23.731 3: CUL_HM set ccu update noArg
2020.08.25 14:27:26.406 3: CUL_HM set ActionDetector update noArg
2020.08.25 14:27:26.504 3: CUL_HM set ccu update noArg
2020.08.25 14:27:28.773 3: CUL_HM set ActionDetector update noArg
2020.08.25 14:27:28.872 3: CUL_HM set ccu update noArg
2020.08.25 14:27:31.110 3: CUL_HM set ActionDetector update noArg
2020.08.25 14:27:31.228 3: CUL_HM set ccu update noArg
2020.08.25 14:27:33.539 3: CUL_HM set ActionDetector update noArg
2020.08.25 14:27:33.638 3: CUL_HM set ccu update noArg
2020.08.25 14:27:35.682 3: CUL_HM set ActionDetector update noArg
2020.08.25 14:27:35.781 3: CUL_HM set ccu update noArg
2020.08.25 14:27:37.969 3: CUL_HM set ActionDetector update noArg
2020.08.25 14:27:38.084 3: CUL_HM set ccu update noArg
2020.08.25 14:27:40.057 3: CUL_HM set ActionDetector update noArg
2020.08.25 14:27:40.174 3: CUL_HM set ccu update noArg
2020.08.25 14:27:42.005 3: CUL_HM set ActionDetector update noArg
2020.08.25 14:27:42.104 3: CUL_HM set ccu update noArg
2020.08.25 14:27:43.928 3: CUL_HM set ActionDetector update noArg
2020.08.25 14:27:44.046 3: CUL_HM set ccu update noArg
ich vermute, dass mein apptime dadurch noch was anderes dazu zählt.
Hallo Frank,
12x update geklickt:
HM_Info HMinfo_SetFn 728.47 12 7592.28 632.69 0.00 0.00
Liegt wohl an Reading Updates.
event-on-update-reading ERR_battery -> und das reading ist nicht vorhanden -> 1 HMinfo_SetFn für ein Klick
ergänze ich CRI__protoco, dann wird das Reading aktualisiert und dann gibt es 2 HMinfo_SetFn für ein Klick (und average sieht direkt besser aus ;) ).
Wieder was gelernt.
Noch als Ergänzung zur Vergleichbarkeit: C_sumDefined: entities:80,device:21,channel:66,virtual:9
Gruß, Ansgar.
ohne events fehlt auch die longpol rückmeldung in der webkonsole.
hier also meine reellen update zeiten:
name function max count total average maxDly avgDly TS Max call param Max call
hminfo HMinfo_SetFn 468 12 2704.01 225.33 0.00 0.00 25.08. 15:10:20 HASH(hminfo); hminfo; update
Hallo Martin,
ich kann es weder nachstellen noch testen, aber eventuell hilft in HMConfig Zeile 1934 statt:
,"HM-DIS-WM5501" =>{ displayWM =>"(long|short|help) -lineX- -textNo1- -color1- -icon1- [-textNo2- -color2- -icon2-] [...] [-textNo6- -color6- -icon6-]"
Mit
,"HM-DIS-WM5501" =>{ displayWM =>"(long|short|help) -lineX- -textNo1- (-color1-|{white}|red|orange|yellow|green|blue) (-icon1-|off|on|open|closed|error|ok|info|newMsg|serviceMsg|sigGreen|sigYellow|sigRed|ic12|ic13|{noIcon}) [-textNo2- -color2- -icon2-] [...] [-textNo6- -color6- -icon6-]"
displayWM wieder bei der e: Variante mit einfachen Mitteln flott zu bekommen.
Schade, zu einfach gedacht, siehe hier: https://forum.fhem.de/index.php/topic,113776.msg1080829.html#msg1080829 (https://forum.fhem.de/index.php/topic,113776.msg1080829.html#msg1080829)
Gruß, Ansgar.
Leider lässt sich seit dem Update auch "desired-temp" beim Thermostat HM-CC-RT-DN nicht mehr setzen.
Es kommt die (falsche) Meldung CUL_HM param ... does not match options
z.B.
set Heizung desired-temp 20.5
=> param 0:((off|-20.0..50.0;0.5)) 20.5 does not match options
Abhilfe:
1.
Ältere Version von CUL_HM (z.B. vom 15.12.2019) einspielen
2.
in der fhem.cfg verhindern, dass das fehlerhafte neue Modul wieder eingespielt wird mit
global exclude_from_update 10_CUL_HM.pm
Hallo Martin,
ZitatVerbose level zu Command indication: Es ist level 3 - welcher per default "off" ist. Sollte also passen
Der genutzte Level für set und get ist mit 3 ok, denn dazu sagt commandref
Zitat3 - ausgesendete Kommandos werden gelogged
Aber wieso meinst Du, dass level 3 per default "off" ist?
In der default fhem.cfg ist
attr global verbose 3 Und Wiki sagt
ZitatFür den Normalgebrauch wird Level 3 empfohlen
Persönlich kann ich level 3 für Normalgebrauch auch nicht nachvollziehen, aber ich denke, die Logmüllbeschwerden beziehen sich darauf.
Gruß, Ansgar.