Nach Update auf 3.73.9.20240130 Probleme mit Duty Cycle

[MrR]

So ganz nachvollziehen kann ich auch nicht, dass in zwei Protokolldateien nur drei Programmausführungen verzeichnet sein sollen. Noch dazu, wenn eines davon ein zyklisches Programm ist, mit dem Messwerte intern protokolliert werden, die alle paar Minuten aktualisiert werden. Heißt für mich, dass das Protokoll mit irgendwas geflutet wird, so dass relevante Ereignisse hinten rausgeschoben werden (habe ich bei Experimenten auch schon mal geschafft). Also muss man sich die Protokolle mal im Klartext anschauen, um einen Hinweis auf die Ursache zu bekommen.

Gruß Xel66

also ich hab kurz nach deinem Post auf alles loggen eingestellt. Habe es jetzt nochmal ausgeführt und das kam jetzt dabei raus:

Feb 5 19:59:01 ccu3-webui local0.info ReGaHss: Info: Program ID = 55786 'prgEnergyCounter_55767_00085BE997DFA7:7', rule's trigger flags = 6 [SetState():iseDOMPrg.cpp:524]
Feb 5 19:59:44 ccu3-webui local0.info ReGaHss: Info: Program ID = 2197 'prgEnergyCounter_2182_0001D3C99C8BDE:6', rule's trigger flags = 6 [SetState():iseDOMPrg.cpp:524]
Feb 5 20:00:23 ccu3-webui local0.info ReGaHss: Info: Program ID = 2942 'prgEnergyCounter_2784_00067BE98F0A17:7', rule's trigger flags = 6 [SetState():iseDOMPrg.cpp:524]
Feb 5 20:00:52 ccu3-webui local0.info ReGaHss: Info: Program ID = 66554 'prgEnergyCounter_66535_00085D87C91456:7', rule's trigger flags = 6 [SetState():iseDOMPrg.cpp:524]

Was sagt mir das jetzt ?
es gibt nur einen Aktor, der die Einspeisung des Balkonkraftwerks misst. Alle anderen Zähler sind auf den Aktoren (BSM,pSM,FSM) deaktiviert. Brauch ich nicht.

[Xel66]

Das ist wirklich alles aus zwei Logdateien? Kann ich mir einfach nicht vorstellen. Ich sehe, Du hast vier Aktoren mit Messfunktion, deren interne Programme durch die Datenübermittlung getriggert werden. Soweit normal. Bei füllt ein solcher Aufruf 440 Zeilen für eine Stunde Logzeit. Allerdings laufen bei mir auch so einige Programme und mein Duty Cycle liegt derzeit gerade bei 15%. Es ist auch niemand zu Hause. Wenn ich nachher nach Hause komme, wird er sich bei unter 30% (bei meinem System durch vermehrten Einsatz von HmIP mittlerweile Normalwert) einpendeln. Früher (mit überwiegend klassischer Aktorik) war mein DC einstellig.

Gruß Xel66

[MrR]

Das ist wirklich alles aus zwei Logdateien? Kann ich mir einfach nicht vorstellen. Ich sehe, Du hast vier Aktoren mit Messfunktion, deren interne Programme durch die Datenübermittlung getriggert werden. Soweit normal. Bei füllt ein solcher Aufruf 440 Zeilen für eine Stunde Logzeit. Allerdings laufen bei mir auch so einige Programme und mein Duty Cycle liegt derzeit gerade bei 15%. Es ist auch niemand zu Hause. Wenn ich nachher nach Hause komme, wird er sich bei unter 30% (bei meinem System durch vermehrten Einsatz von HmIP mittlerweile Normalwert) einpendeln. Früher (mit überwiegend klassischer Aktorik) war mein DC einstellig.

Gruß Xel66

Also das Log in den Einstellungen läuft auf -alles loggen- seit deinem Post. Das Script habe ich in -script testen- eingefügt und ausgeführt, richtig?. Es gibt ca acht Geräte ( Fsm, Bsm und Psm) im System. Bei allen bis auf einem habe ich das Messen auf - nicht aktiv und nicht benutz - gesetzt.
Wenn ich die messages datei öffne, ist der einzige wirklich auffällige Fehler mein alter Broken Pipe....

[jp112sdl]

Die optisch eleganteste Variante, um erstmal herauszufinden, an welches Gerät hier die CCU am meisten sendet, ist aus meiner Sicht natürlich der >>>AskSinAnalyzer<<< oder >>>AskSinAnalyzer XS<<<.
Ist beides nicht zur Hand, kämen Boardmittel zum Einsatz.

Zuerst in der Zentralenwartung die Option "Homematic Funk" auf "Alles loggen" stellen.
Danach die Zentrale neustarten.

Eine Weile warten, bis der DC wieder unnormal angestiegen ist.

Anschließend per SSH auf der Zentrale einloggen und nach allen TX Meldungen des multimacd suchen, z.B. mit sowas wie

Code: Alles auswählen

grep MacCon /var/log/messages | grep -e 'HMIP CMD=1D' -e 'LLMAC TX'

Das ergibt sowas wie

Code: Alles auswählen

HmIP Geräte:
Feb  5 21:42:07 ccu2 user.debug multimac: MacController::OnDownstreamFrame(#52 HMIP CMD=1D  03 00 10 00 2E 4A 26 11 45 06 C0 02 E3 00)
(Zentrale / Sender: 0x4A2611; Empfänger / Gerät: 0x4506C0)

BidCos Geräte:
Feb  5 21:42:18 ccu2 user.debug multimac: MacController::OnDownstreamFrame(#255 LLMAC TX @18775ms [10k,NoCCA] 02 80 02 2C 10 E8 4D 0E 72 00)
(Zentrale / Sender: 0x2C10E8; Empfänger / Gerät: 0x4D0E72)

Es sollte hier nun auffallen, welche Empfänger/Geräte besonders häufig auftauchen!

Um zu wissen, welches Gerät welche Adresse im System besitzt, kann man sich mit dem Skript behelfen:

Code: Alles auswählen

string stdout;
string stderr;
string sDevId;
string data;
string metaData;
WriteLine("Adresse\t\tSeriennummer\t\tName");
foreach(sDevId, root.Devices().EnumUsedIDs()) {
  var dev= dom.GetObject(sDevId);
  if ( true == dev.ReadyConfig() ) {
    metaData = dev.MetaData("DEVDESC");
    foreach (data, metaData.Split(",")) {
      if (data.Substr(0,10) == "RF_ADDRESS") {
        data = data.Replace("RF_ADDRESS:","");
        if (data != "0") {
	   string ser = dev.Address();
	   string cmd = "printf '000000%X' "#data#" | tail -c 6 | sed 's/.\{2\}/& /g'";
	   system.Exec(cmd, &stdout, &stderr);
           WriteLine(stdout#"\t"#ser#"\t"#dev.Name());
        }
      }
    }
  }
}

[MrR]

Die optisch eleganteste Variante, um erstmal herauszufinden, an welches Gerät hier die CCU am meisten sendet, ist aus meiner Sicht natürlich der >>>AskSinAnalyzer<<< oder >>>AskSinAnalyzer XS<<<.
Ist beides nicht zur Hand, kämen Boardmittel zum Einsatz.

merci... habs überprüft... es steht zwar nirgends -Zentrale / Sender- bzw Empfänger/ Gerätdabei, es wiederholt sich zumindest nichts auffälliges.. die letzten Ziffern/Buchstaben ändern sich.... kein Eintrag der oft aufeinander folgt... heißt da ist soweit alles ok??

[jp112sdl]

es steht zwar nirgends -Zentrale / Sender- bzw Empfänger/ Gerätdabei,

Das war auch nur von mir als Zusatz reingeschrieben, um zu verdeutlichen welche Bytes interessant sind.
Und das sind eben die Bytes, die den Empfänger adressieren.

[hm4jojo]

Hallo Zusammen!

Hmm... ich mache gleiche Beobachtungen mit meinem System.
Seit Jahren mache ich immer Update RaspberryMatic und Duty Cycle dümpelt immer um 20%!
Auch bei vorausgegangen Firemwareupdate von Geräten hatte ich nur während dem Firmewareupdate hohe Duty Cycle.
Einmal auch eine hohe Duty Cycle wegen Fehler im Script!
Aber ansonsten kaum Probleme.

Jetzt mit Update auf 3.73.9.20240130 fallem mir die hohe Duty Cycle Werte auf.

DC Analyzer habe ich nicht.
Gibt eine preiswerte brauchbare Analyzer zum kaufen?

VG

PS: Oder hat jemand einen >>>AskSinAnalyzer<<< oder >>>AskSinAnalyzer XS<<< abzugeben/preiswert zu verkaufen?

[Xel66]

Liest man immer wieder, aber in fast allen Fällen waren die Programmierungen oder Geräteeinstellungen die eigentliche Ursache. In den Restfällen haben die Anwender aufgegeben und/oder irgendwelche Resets vollzogen.

Diese Phänomene wären auch bei einem normalen Reboot zutage getreten, weil bei diesem Vorgang Gerätestatus mit Defaultwerten beschrieben werden. Diese können in der Kombination mit anderen Werten irgendwelche Konstellationen ergeben, die die Programmierung veranlasst das zu tun, was programmiert ist.

Gruß Xel66

[MrR]

bei normalen reboots (selbst mit Rasp.matic) ist mir das noch NIE !!! passiert, dass der Duty durch die Decke ging.

[NickHM]

Hallo

wenn jemand behauptet, dass es an der aktuellen RaspiMatic Version liegt oder / und mit der originalen eq-3 Version ohnehin der DC besser ist, dann verstehe ich nicht warum die User nicht einfach und rel. schnell auf die alte Version oder die eq-3 Version zurück gehen.

Ist der DC dann wieder niedrig, ist der User glücklich und kann entscheiden, ob er nach einem nochmaligen Update auf die aktuelle Version und dann ggf. erhöhtem DC durch sammeln der Log Files zur Fehlersuche beitragen möchte.

Ich lese jetzt 3 Seiten Vermutungen zu einem nicht bewiesenen Fehler in er aktuellen Version, ohne das einer der Betroffenen mal den Test mit der letzten Version machen würde.