Duty Cycle CCU2 & CCU3 mit HM Script auslesen und speichern

Problemlösungen und Hinweise von allgemeinem Interesse zur Haussteuerung mit HomeMatic

Moderator: Co-Administratoren

alchy
Beiträge: 7928
Registriert: 24.02.2011, 01:34

Duty Cycle CCU2 & CCU3 mit HM Script auslesen und speichern

Beitrag von alchy » 19.01.2017, 17:10

Der DutyCycle (Auslastung möglicher Sendezeit) stellt auf vielen Systemen ein Problem dar.
Es kommt zu Kommunikationsmeldungen usw. weil die CCU nicht mehr in der Lage ist zu senden, wenn die gesetzliche maximale Sendezeit verbraten ist.
Leider ist dies für den Anwender nicht ersichtlich, da der Hersteller eine Anzeige desselben nicht für nötig hält.
Damit beschäftigt sich dieser Thread.

1. Möglichkeit - per TCL Script
Bekanntermaßen kann man ja mittels TCL Script usw. den DutyCycle auslesen. >> H I E R <<
Bei Fragen dazu, bitte den Thread benutzen.

2. Möglichkeit in CUxD integriertes TCL -Script seit August 2017 v.1.11
Seit der Version 1.1 bietet >>CUxD<< ebenso die Möglichkeit den DutyCycle auszulesen.
Bei Fragen dazu, bitte den Thread benutzen.

3. Möglichkeit - direkt per HM-Script - und das soll das eigentliche Thema dieses Threads sein.

Diesem Thema habe ich mich gewidmet, da es viele User gab, die mit dem Dateihandling oder anderen Interna auf der CCU so Ihre Probleme haben.
ALso entsanden im Januar 2016 die ersten Scripte.

Mittlerweile habe ich schon 3 unterschiedliche Versionen hier gepostet, eine 4. wäre kein Problem, wenn mir jemand helfen würde.
a: HM-Script mit Nutzung CUxD.exec für nur CCU2 oder CCU3 Benutzer
b: HM-Script mit Nutzung CUxD.exec für CCU2 oder CCU3 und zusätzlicher Gateways
c: HM-Script ohne Verwendung CUxD.exec, sondern ohne Addon direkt mit system.exec für nur CCU2 oder CCU3 Benutzer
d: IN PLANUNG: Version b ohne Verwendung CUxD.exec, sondern ohne Addon direkt mit system.exec

scrollt dahin, wo ihr denkt. :mrgreen:

Neue Versionen nur mit aktueller Firmware lauffähig. Bei Problemen bitte melden.
Alle Scripte geben etwas auf dem Bildschirm aus. Funktioniert bei älteren FW Ständen das Script nicht, dann in den Scripten den Post ändern:
Aus
http://127.0.0.1:32001
wird
http://127.0.0.1:2001
und damit probieren.


a: HM-Script mit Nutzung CUxD.exec für nur CCU2 oder CCU3 bzw. RaspberryMatic usw. Benutzer

Es werden keine Scriptvariablen verwendet, es ist jedoch nötig das Addon >>CUxD<< zu installieren und darin ein
(28)System Gerät mit der Funktion exec zu installieren >Anleitung<

Zum Speichern des Wertes in einer Systemvariablen, einfach jedes Vorkommen im Script von: Status_DutyCycle ersetzen mit dem Namen der Systemvariablen Typ Zahl, welche Ihr vorher angelegt habt.

Ein Ausführen des Scriptes unter Script testen bzw. im Executer sollte die Zahl ausgeben
Wenn dem so ist, kann das Script in ein zyklisch ausgeführtes Programm eingefügt werden.

Wenn es funktioniert, können die WriteLine Zeile auskommentiert werden indem ein Ausrufezeichen davor gesetzt wird.

Aber NICHT übertreiben mit der zyklischen Abfrage - die CCU aktualisiert den Cycle auch nicht alle paar Sekunden.
Alle 5-10 Minuten ist mehr als ausreichend, besser noch, man nimmt statt dem Scheduler einen passenden Hardwaredatenpunkt als Trigger.

Code: Alles auswählen

! DutyCycle CCU mit HM Script und CUxD.exec (c) by Alchy v 0.3
dom.GetObject("CUxD.CUX2801001:1.CMD_SETS").State("echo 'load tclrpc.so; puts [xmlrpc http://127.0.0.1:32001/ listBidcosInterfaces ]'|tclsh |grep -o 'DUTY_CYCLE.[0-9]*.'");
dom.GetObject("CUxD.CUX2801001:1.CMD_QUERY_RET").State(1);
if (!dom.GetObject("CUxD.CUX2801001:1.CMD_RETS").State() == ""){
if (dom.GetObject(ID_SYSTEM_VARIABLES).Get("Status_DutyCycle")){dom.GetObject(ID_SYSTEM_VARIABLES).Get("Status_DutyCycle").State((dom.GetObject("CUxD.CUX2801001:1.CMD_RETS").State().StrValueByIndex(" ",1)).ToFloat());} 
WriteLine((dom.GetObject("CUxD.CUX2801001:1.CMD_RETS").State().StrValueByIndex(" ",1)).ToFloat()); }else{WriteLine("Abfrage nicht erfolgreich");}Version a 


b: HM-Script mit Nutzung CUxD.exec für CCU2/3/RaspberryMatic usw. und zusätzlicher Gateways

Da sich verschiedene User mit der Bitte um Integration der Gateways gemeldet haben, hier auch
noch eine Version für alle enthaltenen Interfaces.
Besitzer von "NUR" CCU2 - können diese zwar auch nehmen, aber das erste Script aus Unterpunkt a ist ausreichend.

Das Script einfach mal so ausführen, wie gepostet. :wink:
Auf dem Bildschirm wird dann die Reihenfolge der Seriennummern und deren DutyCycle angezeigt.

Code: Alles auswählen

! DutyCycle aller Interface mit HM Script und CUxD.exec auslesen und in Systemvariablen speichern 
! und Verbindungsstatus auslesen und in Systemvariablen speichern
! v0.6 (c) by alchy
string listeDC = "VariableDC1;VariableDC2;VariableDC3"; !Namen der Systemvariablen TYP Zahl, wo DutyCycle gespeichert werden soll ; separiert
string listeCON = "VariableCON1;VariableCON2;VariableCON3"; !Namen der Systemvariablen TYP Logik / Alarm wo Connectionstatus gespeichert werden soll ; separiert
! ++++++++++++ DONT TOUCH ++++++++++++++++
string index;string slist;string srueck;string connect;string adress;string cycle; 
integer i = 0;
boolean conn = false;
dom.GetObject("CUxD.CUX2801001:1.CMD_SETS").State("echo 'load tclrpc.so; puts [xmlrpc http://127.0.0.1:32001/ listBidcosInterfaces ]'|tclsh ");
dom.GetObject("CUxD.CUX2801001:1.CMD_QUERY_RET").State(1);
srueck = dom.GetObject("CUxD.CUX2801001:1.CMD_RETS").State();
!srueck = srueck.Substr(2, srueck.Length()-3);
foreach(index, srueck.Split("ADDRESS")) {
if (index.Find("DRESS")>-1) { adress = index.StrValueByIndex(" ",1); slist = slist #"serial="#adress;}
if (index.Find("CONNECTED")>-1) { connect = index.StrValueByIndex(" ",3); if (connect == "1") { conn = true; }else{ conn = false;} slist = slist #" verbunden="#conn;}
if (index.Find("DUTY_CYCLE")>-1) { cycle  = index.StrValueByIndex(" ",5); slist = slist #" DutyCycle="#cycle #";";}
}
WriteLine("-- AUSWERTUNG --");
WriteLine(slist);
WriteLine("-- SPEICHERUNG --");
foreach(index, slist.Split(";")) {
i = i+1;
adress = index.StrValueByIndex(" ",0).StrValueByIndex("=",1);
conn =  index.StrValueByIndex(" ",1).StrValueByIndex("=",1);
cycle = index.StrValueByIndex(" ",2).StrValueByIndex("=",1);
string dcname = listeDC.StrValueByIndex(";",i-1);
string conname = listeCON.StrValueByIndex(";",i-1);
if ( (dom.GetObject(ID_SYSTEM_VARIABLES)).Get(dcname)) { (dom.GetObject(ID_SYSTEM_VARIABLES)).Get(dcname).State(cycle.ToFloat()); 
WriteLine(i#". Wert: "#cycle #" vom Gerät: "#adress #" wurde in "#i#". Variable: " #dcname #" gespeichert");
}else{ 
WriteLine("Systemvariable: "#dcname #" für Wert: " #cycle #" vom Gerät: "#adress #" nicht vorhanden");}
if ( (dom.GetObject(ID_SYSTEM_VARIABLES)).Get(conname)) { (dom.GetObject(ID_SYSTEM_VARIABLES)).Get(conname).State(conn); 
WriteLine(i#"Connectionstatus: "#conn #" vom Gerät: "#adress #" wurde in "#i#". Variable: " #conname #" gespeichert");
}else{ 
WriteLine("Systemvariable: "#conname #" für Connectionstatus: " #conn #" vom Gerät: "#adress #" nicht vorhanden");}
}
WriteLine("ENDE");
}
}

c: HM-Script ohne Verwendung CUxD.exec, sondern ohne Addon direkt mit system.exec für nur CCU2/3 oder RaspberryMatic usw. Benutzer

Dank der Hilfe von BadenPower :!: :!: bei der Zusammenstellung des cmd ist es mir gelungen, die Abfrage des DutyCycle auch für User zu verwirklichen, die kein CUxD auf der CCU verwenden wollen bzw. können.
Durch einen Fehler im Script, war eine erste Version unter älteren Firmwareversionen nicht lauffähig. Dies ist aber mittlerweile gefixt, zumindest lt. meinen Tests.

Die folgende Version schreibt immer den DutyCycle ins >> Fehlerprotokoll << und kann auch zusätzlich den Wert in eine Zahlenvariable schreiben.
In der Zeile string sysvar = "Status_DutyCycle"; wird der Name eingetragen, der vorher als Zahl angelegten Systemvariable.
Solange boolean debug = true; ist, erfolgt eine Bildschirmausgabe auch im Fall keines Fehlers.
Aber egal ob true oder false, eventueller Fehler werden immer auf dem Bildschirm ausgegeben.

Ist eigentlich selbsterklärend, probiert es aus.

Code: Alles auswählen

! DutyCycle CCU2 mit HM Script und system.exec in Systemvariable und Fehlerprotokoll
! v 0.7 (c) by Alchy
string sysvar = "Status_DutyCycle"; ! Name der als Zahl angelegten Systemvariable, wo ermittelter DutyCycle gespeichert werden soll 
boolean debug = true;
! Finger weg 
string stdout;string stderr;boolean Return;
string cmd = "/bin/sh -c '" # 'echo "load tclrpc.so; puts [xmlrpc http://127.0.0.1:32001/ listBidcosInterfaces ]" |tclsh |grep -o "DUTY_CYCLE.[0-9]*."' # "'";
if(true){
  Return = system.Exec(cmd,&stdout,&stderr);
  if (debug){WriteLine("Fehler: "); WriteLine(stderr); WriteLine("Ausgabe: "); WriteLine(stdout);}
if (stderr){ WriteLine("Fehler bei Abfrage");}else{
string sout;string serr; system.Exec("logger -t script -p user.debug [DutyCycle "#stdout.StrValueByIndex(" ",1).ToString()#"] by_Alchy", &sout, &serr);
if (debug){WriteLine("DutyCycle ["#stdout.StrValueByIndex(" ",1).ToString()#"] by_Alchy"#" ins Fehlerprotokoll eingetragen");}
if (dom.GetObject(ID_SYSTEM_VARIABLES).Get(sysvar)){dom.GetObject(ID_SYSTEM_VARIABLES).Get(sysvar).State(stdout.StrValueByIndex(" ",1).ToFloat()); 
if (debug){WriteLine("DutyCycle von " #stdout.StrValueByIndex(" ",1).ToFloat()# " ermittelt und in Systemvariable eingetragen");}
}else{WriteLine("Systemvariable nicht vorhanden zum eintragen");}
}}

Ansonsten gilt bei allen Versionen das was ich oben schrieb. :!:
Übertreibt es nicht beim Intervall des Ausführungsprogramm. Es hilft nichts den DutyCycle alle paar Sekunden abzufragen. 10min oder ähnliches ist völlig ausreichend. Wer einen passenden Hardwaetrigger hat, kann natürlich diesen benutzen, statt dem Scheduler.

Gedankengänge:
- grundsätzlich benötigt die letzte Version noch nicht mal eine Systemvariable - wahrschenlich werde ich ads Schreiben in das Fehlerprotokoll in alle Versionen integrieren.
Mir ist aufgefallen, das der DutyCycle sehr oft Probleme bei den Usern verursacht. Ich oder auch viele andere hätten manchmal eben auch gern das >> Fehlerprotokoll << um bei der Fehleranalyse um helfen zu können. Warum also nicht den DutyCycle da mit rein schreiben (nebenbei, sozusagen)
Also, der ermittelte DutyCycle wird mit dieser Version immer ins Fehlerprotokoll geschrieben. (sofern er denn auch ermittelt wurde). :wink:
Wenn also ein User den DutyCycle nicht in Systemvariable speichern will, braucht er auch die Systemvariable nicht anzulegen. Dann einfach das Script so nehmen.


Alchy
Zuletzt geändert von alchy am 22.01.2019, 08:35, insgesamt 15-mal geändert.
Grund: Version a - neue Version mit Zusatzausgabe wenn Abfrage nicht erfolgreich

.................... Full
Ignoranz ist die Summe aller Maßnahmen die man ergreift, um bestehende Tatsachen nicht sehen zu müssen.

© Sandra Pulsfort (*1974)

Lies bitte die Logik von WebUI Programmen und die Tipps und Tricks für Anfänger.

Wichtig auch CUxD ersetzt System.exec. Die HM Script Doku (Downloadart Skripte) hilft auch weiter.
Zum Testen von Scripten den >> HomeMatic Script Executor << von Anli benutzen.

Benutzeravatar
Homoran
Beiträge: 8608
Registriert: 02.07.2013, 15:29
Wohnort: Köln

Re: Duty Cycle CCU2 mit HM Script auslesen und speichern

Beitrag von Homoran » 19.01.2017, 19:01

alchy hat geschrieben: habe ich habe schnell mal etwas zusammengeschrieben für die CCU2
...und das klappt? wäre ja jetzt eigentlich Majestätsbeleidigung :duckundwech:

Super, dass das auch ohne TCL-Script klappt. (Das bei mir schon läuft)
Da ich im Moment nicht parallel arbeiten möchte die Frage:
müsste ich das TCL SKript auf der CCU wieder löschen oder reicht es mein "DC_Auslesen" Programm zu deaktivieren?
Ich hätte allein deshalb gerne eine Version für (mehrere) HM-CFG-LAN weil ich von einem mit dem TCL-Script keine Antwort bekomme.

Gruß
Rainer
Alle meine Hinweise sind auf eigene Gefahr umzusetzen. Immer einen Fachmann zu Rate ziehen!

alchy
Beiträge: 7928
Registriert: 24.02.2011, 01:34

Re: Duty Cycle CCU2 mit HM Script auslesen und speichern

Beitrag von alchy » 19.01.2017, 20:02

Homoran hat geschrieben:
alchy hat geschrieben:ich habe schnell mal etwas zusammengeschrieben für die CCU2
...und das klappt? wäre ja jetzt eigentlich Majestätsbeleidigung :duckundwech:
Probier es doch einfach aus. Ich weiß es nicht, bei mir klappt es. :P
Nehmen in den Executer / Script testen kopieren und auf Ausführen klicken.
Majestätsbeleidigung ist das nicht - ich wollte nur denjenigen eine Alternative bieten, die sich nicht so auskennen, oder Angst haben Dateien hin und her zu kopieren usw. Ich setze ja selber das TCL Script ein.
Homoran hat geschrieben: Da ich im Moment nicht parallel arbeiten möchte die Frage:
müsste ich das TCL SKript auf der CCU wieder löschen oder reicht es mein "DC_Auslesen" Programm zu deaktivieren?
Du musst gar nichts. Ich habe zum Test auch mein Script parallel zum TCL Script laufen lassen. spielt doch keine Rolle.
Speichern würde ich natürlich in eine andere Variable.
status_dutycycle.jpg
Status_DutyCycle_CCU wird durch das TCL Script, Status_DutyCycle durch mein Miniscript gefüllt.
Wenn du willst, brauchst du nur das Programm zu deaktivieren, was das tcl File aufruft. Die Datei selber spielt keine Rolle.

Wenn du mehr willst müsstest du mir mal die Ausgabe von dem Script posten:

Code: Alles auswählen

dom.GetObject("CUxD.CUX2801001:1.CMD_SETS").State("echo 'load tclrpc.so; puts [xmlrpc http://127.0.0.1:2001/ listBidcosInterfaces ]'|tclsh");
dom.GetObject("CUxD.CUX2801001:1.CMD_QUERY_RET").State(1);
WriteLine( (dom.GetObject("CUxD.CUX2801001:1.CMD_RETS").State()) );
Am liebsten wäre mir die JSON Ausgabe vom Executer, aber Script testen geht auch.

Alchy

.................... Full
Ignoranz ist die Summe aller Maßnahmen die man ergreift, um bestehende Tatsachen nicht sehen zu müssen.

© Sandra Pulsfort (*1974)

Lies bitte die Logik von WebUI Programmen und die Tipps und Tricks für Anfänger.

Wichtig auch CUxD ersetzt System.exec. Die HM Script Doku (Downloadart Skripte) hilft auch weiter.
Zum Testen von Scripten den >> HomeMatic Script Executor << von Anli benutzen.

Benutzeravatar
Homoran
Beiträge: 8608
Registriert: 02.07.2013, 15:29
Wohnort: Köln

Re: Duty Cycle CCU2 mit HM Script auslesen und speichern

Beitrag von Homoran » 19.01.2017, 20:17

Hallo Alchy,
schreib nicht soviel, ich schaff das nicht mehr alles zu lesen und zu verstehen. :?
alchy hat geschrieben:Am liebsten wäre mir die JSON Ausgabe vom Executer, aber Script testen geht auch.
Eine der leichteren Übungen:

Code: Alles auswählen

{
  "sessionId": "",
  "httpUserAgent": "",
  "STDOUT": "\{ADDRESS JEQ0706845 CONNECTED 1 DEFAULT 0 DESCRIPTION \{} DUTY_CYCLE 0 FIRMWARE_VERSION 964 TYPE \{Lan Interface}} \{ADDRESS JEQ0707936 CONNECTED 1 DEFAULT 0 DESCRIPTION \{} DUTY_CYCLE 0 FIRMWARE_VERSION 961 TYPE \{Lan Interface}} \{ADDRESS MEQ1888457 CONNECTED 1 DEFAULT 1 DESCRIPTION \{} DUTY_CYCLE 0 FIRMWARE_VERSION \{} TYPE CCU2}\n\r\n"
}
Der findet tatsächlich YAHM und meine beiden Adapter.
hiermit bekomme ich nie Werte in die Sysvar:

Code: Alles auswählen

dom.GetObject("CUxD.CUX2801002:4.CMD_EXEC").State("tclsh /usr/local/dutyccu.tcl JEQ0707936 DC_Groundplane");
alchy hat geschrieben:Wenn du mehr willst
mehr = Komparativ; Mehr als???

Danke
Rainer
Alle meine Hinweise sind auf eigene Gefahr umzusetzen. Immer einen Fachmann zu Rate ziehen!

Benutzeravatar
JRiemann
Beiträge: 3828
Registriert: 12.11.2015, 21:05
Wohnort: Aurich

Re: Duty Cycle CCU2 mit HM Script auslesen und speichern

Beitrag von JRiemann » 19.01.2017, 20:26

alchy hat geschrieben:Wenn wer eine Version benötigt mit dem Gateways usw, möge er sich melden.
Hallo!
Probeweise läuft bei mir jetzt Deine Version und parallel die TCL Version. Funktioniert super!
Eine Version für das LAN-Gateway HM-LGW-O-TW-W-EU wäre schön!
Oder noch besser eine Version in der nur die Seriennummer der betreffenden Geräte eingetragen werden muss.
Vielen Dank für Deine Mühe!
Jörg
Zuletzt geändert von JRiemann am 19.01.2017, 21:08, insgesamt 1-mal geändert.
Viele Grüße!
Jörg

alchy
Beiträge: 7928
Registriert: 24.02.2011, 01:34

Re: Duty Cycle CCU2 mit HM Script auslesen und speichern

Beitrag von alchy » 19.01.2017, 20:30

@ Homoran
Schade, da steht kein DutyCycle drin. Ich gehe ja nicht von aus, das der bei allen Adaptern incl. CCU 0 bei dir ist.
Welche FW Version läuft da bei dir auf der CCU?
Außerdem steht die CCU am Ende - also wird dir mit meinem obigen Script die 0 vom Lan Interface JEQ0706845 ausgegeben.


@JRiemann
Da ich keine weiteren Interface habe, brauche ich halt Input. je mehr, je besser.
Einfach die Ausgabe des kleinen Scripts posten, dann tütele ich auch noch die Lanadapter mit rein.

Alchy

.................... Full
Ignoranz ist die Summe aller Maßnahmen die man ergreift, um bestehende Tatsachen nicht sehen zu müssen.

© Sandra Pulsfort (*1974)

Lies bitte die Logik von WebUI Programmen und die Tipps und Tricks für Anfänger.

Wichtig auch CUxD ersetzt System.exec. Die HM Script Doku (Downloadart Skripte) hilft auch weiter.
Zum Testen von Scripten den >> HomeMatic Script Executor << von Anli benutzen.

Benutzeravatar
Homoran
Beiträge: 8608
Registriert: 02.07.2013, 15:29
Wohnort: Köln

Re: Duty Cycle CCU2 mit HM Script auslesen und speichern

Beitrag von Homoran » 19.01.2017, 20:34

alchy hat geschrieben:Schade, da steht kein DutyCycle drin. Ich gehe ja nicht von aus, das der bei allen Adaptern incl. CCU 0 bei dir ist.
Doch, im Moment schon, wobei CCU bei mir YAHM ist.
HM-YAHM_Load.jpg
Gruß
Rainer,
der versucht ein wenig traffic zu provozieren.

EDIT:
4x das ePaperdisplay gedrückt:

Code: Alles auswählen

{
  "sessionId": "",
  "httpUserAgent": "",
  "STDOUT": "\{ADDRESS JEQ0706845 CONNECTED 1 DEFAULT 0 DESCRIPTION \{} DUTY_CYCLE 0 FIRMWARE_VERSION 964 TYPE \{Lan Interface}} \{ADDRESS JEQ0707936 CONNECTED 1 DEFAULT 0 DESCRIPTION \{} DUTY_CYCLE 0 FIRMWARE_VERSION 961 TYPE \{Lan Interface}} \{ADDRESS MEQ1888457 CONNECTED 1 DEFAULT 1 DESCRIPTION \{} DUTY_CYCLE 10 FIRMWARE_VERSION \{} TYPE CCU2}\n\r\n"
}
Alle meine Hinweise sind auf eigene Gefahr umzusetzen. Immer einen Fachmann zu Rate ziehen!

Benutzeravatar
JRiemann
Beiträge: 3828
Registriert: 12.11.2015, 21:05
Wohnort: Aurich

Re: Duty Cycle CCU2 mit HM Script auslesen und speichern

Beitrag von JRiemann » 19.01.2017, 20:37

Danke! Ich kann allerdings nur die Ausgabe aus "Skript testen" posten...
alchy hat geschrieben:Einfach die Ausgabe des kleinen Scripts posten, dann tütele ich auch noch die Lanadapter mit rein.
Alchy

Code: Alles auswählen

{ADDRESS NEQ0218559 CONNECTED 1 DEFAULT 0 DESCRIPTION {} DUTY_CYCLE 1 FIRMWARE_VERSION 1.4.1 TYPE HMLGW2} {ADDRESS NEQ0231005 CONNECTED 1 DEFAULT 1 DESCRIPTION CCU2-Coprocessor DUTY_CYCLE 2 FIRMWARE_VERSION 1.4.1 TYPE CCU2}
Viele Grüße!
Jörg

Benutzeravatar
Homoran
Beiträge: 8608
Registriert: 02.07.2013, 15:29
Wohnort: Köln

Re: Duty Cycle CCU2 mit HM Script auslesen und speichern

Beitrag von Homoran » 19.01.2017, 20:50

So, ich nochmal ;-)
HM-YAHM_DC.jpg
und das json dazu:

Code: Alles auswählen

{
  "sessionId": "",
  "httpUserAgent": "",
  "STDOUT": "\{ADDRESS JEQ0706845 CONNECTED 1 DEFAULT 0 DESCRIPTION \{} DUTY_CYCLE 2 FIRMWARE_VERSION 964 TYPE \{Lan Interface}} \{ADDRESS JEQ0707936 CONNECTED 1 DEFAULT 0 DESCRIPTION \{} DUTY_CYCLE 0 FIRMWARE_VERSION 961 TYPE \{Lan Interface}} \{ADDRESS MEQ1888457 CONNECTED 1 DEFAULT 1 DESCRIPTION \{} DUTY_CYCLE 14 FIRMWARE_VERSION \{} TYPE CCU2}\n\r\n"
}
Das Sorgenkind im Keller bekomme ich so auf die Schnelle nicht belastet. Da hängt nicht viel dran, aber eben die Messsteckdosen von Waschmaschine und Trockner, die ziemlich viel Traffic produzieren(siehe heute Mittag die Spülmaschine).

Gruß
Rainer
Alle meine Hinweise sind auf eigene Gefahr umzusetzen. Immer einen Fachmann zu Rate ziehen!

Benutzeravatar
JRiemann
Beiträge: 3828
Registriert: 12.11.2015, 21:05
Wohnort: Aurich

Re: Duty Cycle CCU2 mit HM Script auslesen und speichern

Beitrag von JRiemann » 19.01.2017, 22:03

@ Alchy
Neue Statusmeldung: Ich habe das Skript jetzt einige Zeit unter Yahm getestet. Dabei ist mir aufgefallen das nicht der DC der CCU (Raspi3 mit HM-MOD-RPI-PCB) sondern der DC des Funk-LAN-Gateway HM-LGW-O-TW-W-EU ausgewertet wird. Der HM-MOD-RPI-PCB ist aber im System als "CCU" konfiguriert.
Viele Grüße!
Jörg

Antworten

Zurück zu „HomeMatic Tipps & Tricks - keine Fragen!“