trotz attr autoReadReg 0_off immer noch getConfig im Log

[Trebxson]

Hallo liebe Gemeinde,

ich versuche Overloads in den Griff zu bekommen, erkenne aus dem Log z.B.

Code Auswählen Erweitern

2015.02.16 18:22:12.514 3: CUL_HM set CUL_HM_HM_CC_RT_DN_123ABC_Clima getConfig

Ich habe nun für alle Geräte nacheinander 5_readMissing dann 8_stateOnly und inzwischen 0_off gesetzt (war vorher 4_reqStatus), also z.B.

Code Auswählen Erweitern

attr CUL_HM_HM_CC_RT_DN_123ABC autoReadReg 0_off

Dennoch taucht getConfig im Log auf und treibt damit vermutlich den Load nach oben.

Ist ein Neustart von FHEM oder ein reread erforderlich? Mir scheint als fehlt da noch etwas. (Ich bin gerade nur per Fernwartung drin, daher würde ich ungern unkontrolliert einen Neustart ausführen.)
Setzen auf einen Kanal wird laut Doku nicht empfohlen und von FHEM auch wie erwartet abgewiesen.

Vielen Dank und viele Grüße,
Robert

[frank]

schau bei hminfo protoEvents. da wird angezeigt, ob autoreadreg noch arbeit hat. ausserdem kannst du wahrscheinlich erkennen, wo viele messages gesendet wurden. vielleicht zu viele burst aktionen?

[Trebxson]

Du meinst autoReadReg legt getConfig-Aufgaben in die Warteschlange, welche unabhängig von der Einstellungsänderung zu Ende gearbeitet werden? Macht Sinn. Laut Log sind seit 30 min auch keine weiteren getConfig-Anforderungen gesendet worden. Scheint also als war ich zu ungeduldig. msgLoadEst hat sich seit dem auch entspannt.

Hintergrund: Ich habe eine Perl-Funktion mit den eingehenden measured-temp zu einem Notify verbunden, welches dann alle 30 min valveMaxPos bei Bedarf setzt (um bessere Heizlinien hinzubekommen (hier ist eine Solar- mit einer Gasanlage gekoppelt, welche bei Sonnenuntergang für kalte Räume sorgt und 2 h später die Bude vollkommen überhitzt ist)).
valveMaxPos-Funktion + Auto-getConfig + ein paar Mal desired-temp (oder anderes) manuell setzen reichten dabei schon um einen Overload zu erzeugen. msgLoadEst, die STATEs usw. fange ich in der Funktion ab um ein sauberes Senden hinzubekommen und und und... wie auch immer. Das hat schon viel geholfen. Vielen Dank!

Code Auswählen Erweitern

protoEvents done:
    name                      :State           |CmdPend   |Snd       |Resnd     #CmdDel    |ResndFail |Nack      |IOerr
    CUL_HM_HM_CC_RT_DN_2E1234 : done           | -        |2444:     |28:       #13        |8:        | -        | -
    CUL_HM_HM_CC_RT_DN_2E2345 : done           | -        |2106:     |78:       #117       |18:       | -        | -
    CUL_HM_HM_CC_RT_DN_2E3456 : done           | -        |1345:     |39:       #12        |8:        | -        | -
    CUL_HM_HM_CC_RT_DN_2E4567 : done           | -        |889:      |9:        #7         |3:        | -        | -
    CUL_HM_HM_CC_RT_DN_2E5678 : done           | -        |2406:     |103:      #79        |25:       | -        | -
    CUL_HM_HM_CC_RT_DN_2E6789 : done           | -        |3130:     |104:      #108       |27:       | -        | -
    CUL_HM_HM_CC_RT_DN_2E789A : done           | -        |2988:     |160:      #107       |26:       | -        | -
    CUL_HM_HM_CC_RT_DN_2E89AB : done           | -        |2175:     |49:       #40        |10:       | -        | -
================================================================================================================
    sum                       0                |0         |17483     |570       #483       |125       |0         |0

    CUL_HM queue length:4

    requests pending
    ----------------
    autoReadReg          :
        recent           : none
    status request       :
    autoReadReg wakeup   :
    status request wakeup:
    autoReadTest         :

    IODevs:HmUsb:opened pending=0 condition:ok
            msgLoadEst: 1hour:30% 10min steps: 2/5/3/7/4/5

[frank]

valveMaxPos ist ja bestimmt ein register vom rt. wenn du das veränderst, fehlt fhem natürlich die info, ob das register auch gesetzt wurde. da macht autoreadreg eigentlich sinn. um die sendelast durch autoreadreg besser zu verteilen sollte dir folgendes attribut vom hmlan helfen.

hmMsgLowLimit
max messages level of HMLAN allowed for low-level message queue to be executed. Above this level processing will be postponed.
HMLAN will allow a max of messages per hour, it will block sending otherwise. After about 90% messages the low-priority queue (currently only CUL_HM autoReadReg) will be delayed until the condition is cleared.
hmMsgLowLimit allowes to reduce this level further.
Note that HMLAN transmitt-level calculation is based on some estimations and has some tolerance.

[Trebxson]

Ich habe den Thread nicht vergessen. Tatsache ist, dass sich die Kommunikation seit autoReadReg 0_off stark (!) gebessert hat, ja sogar fast zuverlässig arbeitet. Daher wusste ich nicht so recht ob und was ich mit hmMsgLowLimit "verbessere" (welche CMDs sind das so, die nicht so wichtig sind? (...)).

> valveMaxPos ist ja bestimmt ein register vom rt. wenn du das veränderst, fehlt fhem natürlich die info, ob das register auch gesetzt wurde

Das Problem hatte ich vorher auch schon da FHEM offenbar nicht zeitnah feststellt, ob der HM-CC-RT-DN die Änderungen angenommen hat.

set CUL_HM_HM_CC_RT_DN_A1B2C3_Clima regSet valveMaxPos 25
-> FHEM zeigte ewig set_25 % obwohl HM-CC-RT-DN den Wert lange angewandt hatte (nach zig Versuchen felsenfest verifiziert)
-> erst nach manuellem getConfig wurde der richtige Wert angezeigt

Daher habe ich in meiner Perl-Funktion die Annahme des Wertes durch Prüfen einiger Voraussetzungen angenommen (msgLoadEst (HMLAN alias hmusb) < 50% + STATE (des HM-CC-RT-DN) == "CMDs_done" + valvePosition <= lastValveMaxPos (...) ).

Seit 2 Tagen jedoch wurde die Automatisierung per FHEM +/ Komponenten wieder unzuverlässig (...). Daher habe ich hmMsgLowLimit nun angewandt. Vermute aber, dass dies nur in Verbindung mit autoReadReg >0 Sinn ergibt.

[frank]

Das Problem hatte ich vorher auch schon da FHEM offenbar nicht zeitnah feststellt, ob der HM-CC-RT-DN die Änderungen angenommen hat.

nach jedem setzen, muss zum verifizieren wieder ausgelesen werden. eigentlich logisch. automatisch kann autoreadreg dieses, wie schon der name vermuten lässt?  ausserdem wird autoreadreg die sendelast versuchen zu verteilen. wenn du natürlich zusätzliche funkprobleme hast, kommt es eventuell zu wiederholungen.

-> erst nach manuellem getConfig wurde der richtige Wert angezeigt

wenn du die automatik ausschaltest, wundert mich, dass du dich wunderst, dass du es nun manuell machen musst. 

eventuell solltest du deine regel-strategie überdenken/verbessern. die thermostate sind dazu ja nicht wirklich angedacht. vielleicht reicht es ja, in abhängig der vorlauftemperatur, das register 2 mal täglich zu ändern.

[Trebxson]

Die Problematik der nicht verifizierten geschrieben Werte hatte ich sporadisch schon vor autoReadReg 0_off, so dass der Code dafür ohnehin existierte und momentan ganz guten Dienst verrichtet.

> eventuell solltest du deine regel-strategie überdenken/verbessern ... vielleicht reicht es ja, in abhängig der vorlauftemperatur, das register 2 mal täglich zu ändern.

Ja, daran habe ich auch schon gedacht. Aber eigentlich läuft es momentan ganz gut

Vielen Dank bis hier her.

[LuckyDay]

 probier doch mal das

attr msgRepeat 0

aus

[Trebxson]

+1

msgRepeat ist vermutlich default 3, wenn nicht gesetzt?

Wie ist das eigentlich. Wenn HM-CC-RT-DN seine measured-temp etc. raussendet, aber nichts erreicht - sendet es diese mit jedem Mal insg. 3 Mal?

• d.h. nicht erreichbarer HMLAN/HMUSB/FHEM bedeutet höherer Engeriebedarf
  
• mit attr CUL_HM_HM_CC_RT_DN_1A2B3C msgRepeat 3 stelle ich genau diese 3 nun HM-CC-RT-DN-seitig oder HMLAN/HMUSB/FHEM-seitig ein? (Habe zu erster Möglichkeit mal etwas bei den Fensterkontakten gelesen bzw. im Homematic Konfigurator gesehen) - d.h. das Attribut würde in erstem Fall zum Gerät übertragen und wird dann in welcher Form von diesem wiedergegeben?

[LuckyDay]

halt nicht verwechseln

das Attribut kannst du dem Device setzen und es wird kein resend mehr gemacht bei =0
also Fhem Anforderung Richtung--> Device. , es sollten dann keine resends mehr auftauchen, bzw. nach nicht erfolgreicher set Anweisung, werden die cmdpending verschwinden.
und nicht noch x mal versucht zu wiederholen.

es gibt auch das Register
z.b.   R-transmitTryMax  6 in manchen Device, das ist die andere Richtung.

[Trebxson]

Vielen Dank. Wieder etwas gelernt. Schade, dass die neuen Erkenntnisse unter einer falschen Überschrift stehen. Hoffe Google lenkt mich oder die nächsten Fragesteller beim nächsten Mal in die richtigen Bahnen