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: 10752
Registriert: 24.02.2011, 01:34
System: CCU
Hat sich bedankt: 65 Mal
Danksagung erhalten: 672 Mal

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 entstanden 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.
für system.exec und LanGateways, denn ich habe keine.


Übersicht:
  • Version a: HM-Script mit Nutzung CUxD.exec für nur CCU2 oder CCU3 oder Rhaspberrymatic Benutzer - also OHNE LanGateway !
  • Version b: HM-Script mit Nutzung CUxD.exec für CCU2 oder CCU3 oder Rhaspberrymatic Benutzer und zusätzlicher Gateways
  • Version c: HM-Script ohne Verwendung CUxD.exec, sondern ohne Addon direkt mit system.exec für nur CCU2 oder CCU3 oder Rhaspberrymatic Benutzer
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 - bei Problemen bitte Ausgabe posten.

Wichtig: Scripte lesen den DutyCycle des BidCos-RF Interface aus. Wer kein solches besitzt, oder auch den IP DutyCycle sehen möchte (der nicht unterschiedlich zum RF ist) muss im Script nur das IP Interface HmIP-RF eintragen. :wink:

Neu in v1.0
- Eintrag DutyCycle ins Fehlerprotokoll jetzt auch bei Version a zusätzlich zur Version c - hatte gelesen, das ich mir das mal vorgenommen hatte :roll:
- bei allen 3 Scripten sollte auch die Diskussion über CCU2 oder CCU3 und welchen Port Geschichte sein.
Mein Dank gilt wieder mal BadenPower, der mir unaufgefordert geholfen hat, damit ich euch helfen kann.

@BadenPower
das Schlimme ist, das ich in anderen Scripten schon diese Mehode verwende. :oops:

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

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.
Außerdem trägt die Version ab der 1.0 den DutyCycle auch in das Fehlerprotokoll ein!

Wenn dem so ist, kann das Script in ein zyklisch ausgeführtes Programm eingefügt werden.

Aber NICHT übertreiben mit der zyklischen Abfrage - die CCU aktualisiert den Cycle auch nicht alle paar Sekunden.

Code: Alles auswählen

! DutyCycle mit HM Script und CUxD.exec für Fehlerprotokoll und optional Systemvariable
! v 1.0 by Alchy 
dom.GetObject("CUxD.CUX2801001:1.CMD_SETS").State('echo "load tclrpc.so; puts [xmlrpc ' # interfaces.Get("BidCos-RF").InterfaceUrl() # ' 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() == ""){
dom.GetObject("CUxD.CUX2801001:1.SYSLOG").State("[DutyCycle "#(dom.GetObject("CUxD.CUX2801001:1.CMD_RETS").State().StrValueByIndex(" ",1))#"] a DutyCycle mit HM Script und CUxD.exec v 1.0 by Alchy");
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 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 Version a ist da ausreichend.

Das Script einfach mal so ausführen, wie gepostet. :wink:
Auf dem Bildschirm wird dann die Reihenfolge der Seriennummern und deren DutyCycle angezeigt. Die Seriennummern müsst Ihr selber checken. Achtung beim Hinzufügen neuer LanGateways ändert sich die Reihenfolge der Ausgaben !!
Neue Version 1.2 mit Eintragen des Ergebnis im Fehlerprotokoll.

Code: Alles auswählen

! DutyCycle aller Interface mit HM Script und CUxD.exec auslesen im Fehlerprotokoll und optional in Systemvariablen speichern 
! und Verbindungsstatus auslesen und optional in Systemvariablen speichern
! v1.2 (c) by alchy B
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 ' # interfaces.Get("BidCos-RF").InterfaceUrl() # ' listBidcosInterfaces ]" |tclsh ');
dom.GetObject("CUxD.CUX2801001:1.CMD_QUERY_RET").State(1);
srueck = dom.GetObject("CUxD.CUX2801001:1.CMD_RETS").State();
WriteLine(srueck);
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_DATAPOINTS)).Get("CUxD.CUX2801001:1.CMD_EXEC")) { (dom.GetObject(ID_DATAPOINTS)).Get("CUxD.CUX2801001:1.CMD_EXEC").State("logger -t AlchyScript -p user.debug [DutyCycle: "#cycle #" vom Geraet: "#adress #"]"); WriteLine(i#". Wert: "#cycle #" vom Gerät: "#adress #" wurde in Fehlerprotokoll gespeichert");
} else {string stdout;string stderr; system.Exec("logger -t AlchyScriptSE -p user.debug [DutyCycle: "#cycle #" vom Geraet: "#adress #"]", &stdout, &stderr);WriteLine(i#". Wert: "#cycle #" vom Gerät: "#adress #" wurde in Fehlerprotokoll gespeichert SE");}
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");
}
}

Version 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 mit HM Script und system.exec in Systemvariable und Fehlerprotokoll
! v 1.0 (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;integer Return;
string cmd = "/bin/sh -c '" # 'echo "load tclrpc.so; puts [xmlrpc ' # interfaces.Get("BidCos-RF").InterfaceUrl() # ' 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()#"] c DutyCycle mit HM Script und system.exec v 1.0 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 Version a & c noch nicht mal eine Systemvariable - wahrscheinlich werde ich das 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 Version a & c 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 08.04.2020, 19:44, insgesamt 19-mal geändert.

Blacklist................... almost 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: 8613
Registriert: 02.07.2013, 15:29
Wohnort: Köln
Danksagung erhalten: 4 Mal

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: 10752
Registriert: 24.02.2011, 01:34
System: CCU
Hat sich bedankt: 65 Mal
Danksagung erhalten: 672 Mal

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

Blacklist................... almost 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: 8613
Registriert: 02.07.2013, 15:29
Wohnort: Köln
Danksagung erhalten: 4 Mal

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: 3903
Registriert: 12.11.2015, 21:05
Wohnort: Aurich
Danksagung erhalten: 3 Mal

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: 10752
Registriert: 24.02.2011, 01:34
System: CCU
Hat sich bedankt: 65 Mal
Danksagung erhalten: 672 Mal

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

Blacklist................... almost 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: 8613
Registriert: 02.07.2013, 15:29
Wohnort: Köln
Danksagung erhalten: 4 Mal

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: 3903
Registriert: 12.11.2015, 21:05
Wohnort: Aurich
Danksagung erhalten: 3 Mal

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: 8613
Registriert: 02.07.2013, 15:29
Wohnort: Köln
Danksagung erhalten: 4 Mal

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: 3903
Registriert: 12.11.2015, 21:05
Wohnort: Aurich
Danksagung erhalten: 3 Mal

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!“