Overload

[volschin]

Mit den Updates von gestern hatte ich jetzt erstmals einen Overload. Ich habe die beiden HM-Dateien wieder auf den Stand vom Samstag zurückgedreht.

[chipmunk]

Ich hatte gestern nach dem Update auch sofort ein Overload, obwohl ich nur einen neuen Actor angelernt habe, sonst waren nur zwei Temperatursensoren aktiv, mit denen ich noch nie ein Overloadproblem hatte.

Chipmunk

[mgernoth]

Hallo,

HM-CFG-LAN: Update auf Firmware 0.964
HM-CFG-USB: Update auf Firmware 0.967, update hmland auf aktuellen git-Head (git pull && make)

Alte Firmwareversionen senden kein Load-Byte in der Antwort auf 'K'.

Gruss
  Michael

[volschin]

Danke für den Hinweis. Meine Firmware war auf 0.967, aber mein hmland auf Stand 12/2014.

Ich fände es schön, wenn so eine Änderung mit Abhängigkeit zu externen Komponenten als Change in der CHANGED Datei auftaucht, dann wird es im Screen angezeigt und man hat die Möglichkeit zu reagieren.

Das macht auch zum jetzigen Zeitpunkt noch Sinn. 
Viele updaten in größeren Abständen und werden davon auch eher überrascht werden.

[chipmunk]

Ich habe die aktuelle FW-Version des HM-CFG-USB und auch den HMLAND aktualisiert und noch ein Update des FHEM gemacht, bekomme aber immer noch sofort nach dem Start ein overload. Bis zur vorletzten Version war alles in Ordnung. Da ich noch nicht im Echtbetrieb bin, habe ich eigentlich keine Sendelast.

Chipmunk

[FunkOdyssey]

Ich schließe mich dem an. Git-Repo ist aktuell.
Und mit dem heutigen FHEM-Update kamen diese Overload-Hinweise.

[stromer-12]

Nach dem update vom hmland diesen auch neu gestartet?

[martinp876]

hm - meiner läuft einwandfrei
geändert ist nur die Berechnung - das ist ein Anzeigewert.
Könnt ihr einmal loggen, was passiert?
ich habe 0.964 - muss auch einmal einen update machen... vielleicht kommen in der neuen Version jetzt andere Werte?

[FunkOdyssey]

Ja. Ich hatte hmland natürlich neu gestartet. Anders kann ich auch kein Git-Pull machen.

Die Fehler sind durch das FHEM-Update aufgetaucht. Hmland habe ich daraufhin nur aktualisiert, weil hier im Thread so etwas ähnliches erwähnt wurde.

[volschin]

Also bei mir hat der git pull und ein anschließender RasPi Neustart das Problem gelöst.

[mgernoth]

Hi Martin,

hm - meiner läuft einwandfrei
geändert ist nur die Berechnung - das ist ein Anzeigewert.

Overload kommt durch autoreadreg wenn das Load-Byte nicht vorhanden ist, da dann 0% als Load angenommen wird...

Gruss
  Michael

[martinp876]

Muss ich mir ansehen. Overload sollte nur durch den status gesetzt werden, egal was die berechnung sagt.
Autoreadreg ist eine hintergrundaktion welche das senden stopt, wenn 40% erreicht sind.
Ah, da haben wir es. Wenn die load nicht angezeigt wird sendet fhem bis zum overload. Das werde ich kontrolieren, da fehlt noch etwas.

[franky08]

Wollte mich auch gerade melden. Heute mal ein update gemacht (das erste seit 5 Monaten) beide HM-CFG-Lan auf Firmware 0.964 gebracht und der HMLAN1 macht jetzt auch ständig einen Overload, aber Martin ist ja drann.

VG
Frank

[martinp876]

habe es geprüft. im Prinzip funktioniert es.
- mit dem keepalive wird alle 25sec die load vom IO gelesen.
- die Bremse steht auf 40% default - wenn also die Load (internal msgLoadCurrent) den Wert überschreitet werden die automatischen readings unterbrochen.

Lücke ist also, wenn in den 25 sec die Load von 39% auf 100 ansteigt. Das sieht FHEM nicht, da eben nur alle 25sec nachgesehen wird.

setzt einmal attr wdTimer auf 5. Dann sollte es nicht mehr passieren, es wird alle 5sec gepollt. Das ist kaum zeit, in overload zu kommen.

ich habe auch FW 0.964 - und es klappt.

[franky08]

Hallo Martin, dachte mir gestern schon so etwas und habe gestern Abend wdTimer vom betroffenen HMLAN schon auf 5 gestellt. Bis jetzt hat es keinen Overload mehr gegeben. Darauf gekommen bin ich durch den zweiten HMLAN, der stand schon seit der Inbetriebnahme auf wdTimer 5 und hatte nie einen Overload.

VG
Frank