Duty Cycle CCU2 & CCU3 mit HM Script auslesen und speichern

[Skodi]

Hier das Abbild vom Script testen

[alchy]

Dann stimmt das Script.
Ich glaube nicht, das die Zeile aus der hmserver.log den aktuellen DutyCycle ausgibt.


Alchy

[HMside]

Der DC wird im hmserver.log nur einmal beim Start angezeigt. Sofern HmIP Updates laufen ist man nach dem Start fix bei 40% dazu kommt der normale traffic. Also ggf. mal die Update Files löschen und Neustarten.

[Familienvater]

Hi,

ich werfe jetzt einfach mal pauschal und wertlos ein:
der HmServer ist das "Ding", was HmIP macht, HmIP nutzt theoretisch/praktisch? zwei unterschiedliche Frequenzen (868,3 Mhz und 869,525 MHz), evtl. sogar mit unterschiedlichen gesetzlichen Vorgaben, was die max. Sendedauer angeht (was auch immer für "Hokusokusinformationen" auf der 2. Frequenz gesendet werden...).
Naiv könnte man sagen, mit all den "bekannten" Techniken fragen wir explizit den rfd nach seiner Interface-Liste (der rfd macht aber nur eine Frequenz, und da auch nur klassisches HM), naiv deshalb, weil man jetzt ja behaupten könnte, HmIP ist ja was anderes, also eigene 36 Sekunden. Zumindest was die gemeinsam mit HM-genutzte Frequenz angeht ist es aber (sinnvollerweise) eine gemeinsame Betrachtung der Sendezeit, sonst würde bei einem HmIP-OTA-Firmwareupdate nicht der DC beim rfd steigen, und die "Antenne" sendet auf 868,3 Mhz, egal was es letztendlich für Daten sind.

Es könnte aber durchaus sein, das im HmServer-Log der DutyCycle der 2. Frequenz auftaucht, ich habe auch ehrlich gesagt noch nie probiert, ob der HmIP-Schnittstellenprozess auf Port 2010 die listBidcosInterfaces -Methode unterstützt, oder ob die nicht implementiert ist (ist ja schließlich auch kein BidCos-Interface), vielleicht hat also sogar alles seine Richtigkeit.

Der Familienvater

[alchy]

ob der HmIP-Schnittstellenprozess auf Port 2010 die listBidcosInterfaces -Methode unterstützt

Er unterstützt. Meine Scripte geben auch dort einen DutyCycle aus.

[EDIT]
Allerdings laufen die beiden sogar dann fast ausschließlich parallel, wenn man ein Update von IP Komponenten durchführt. (siehe Anhang)


Alchy

[Skodi]

Habe einen kleinen Erfolg erzielt.Habe das Script das die Komunikation prüft und das Meldungen löscht gelöscht und siehe da der Duty Cycle bleibt derzeit bei 73%. Script war von christian-luetgens Seite und hat eigentlich immer funktioniert. Ausser Aktöre habe ich ja nichts mehr. Kann man festellen wie oft ein Aktor sendet? Wird das irgendwo hinterlegt?

[shartelt]

73 ist aber immer noch viel zu hoch!

[klassisch]

Kann man festellen wie oft ein Aktor sendet? Wird das irgendwo hinterlegt?

-> Einstellungen -> Systemsteuerung -> Zentralen Wartung -> BidCos-RF auf alles Loggen stellen
Ob man dabei auch einen amoklaufenden Sender identifizieren kann, weiss ich nicht.

[alchy]

Habe oben mal einen Chart angehangen, um meine damaligen Tests zu verifizieren.

Alchy

[mabudie]

Ich habe das Skript ohne CuxD laufen.
Eigentlich hatte ich im Log in etwa diese Ausgabe erwartet:

Mar 6 14:32:19 homematic-raspi user.debug script: [DUTY_CYCLE 3] by_Alchy

Stattdessen steht im Log aber "nur":

Mar 6 14:32:19 homematic-raspi user.debug script: [DUTY_CYCLE 3

Meiner Meinung nach wird die Ausgabe verfälscht, weil im grep der \n mitgenommen wird.

Das sieht man auch bei Skript testen. Auch hier werden immer mit der Variablen Zeilenumbrüche eingefügt:
Fehler:

Ausgabe:
DUTY_CYCLE 3

DUTY_CYCLE 3
ins Fehlerprotokoll eingetragen
DutyCycle von 3.000000 ermittelt und in Systemvariable eingetragen

Jemand eine Idee, wie das Skript anzupassen wäre, damit der Eintrag ins Log sauber funktioniert. Oder tritt das Problem nur bei mir auf?!