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
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.
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
- 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.
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.
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).
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