HomeMatic & RaspberryMatic: Duty Cycle, eine schlummernde GEFAHR und was man tun kann
Man könnte den Duty Cycle als eine schlummernde Gefahr im Hintergrund einer HomeMatic Umgebung bezeichnen. Es gibt verschiedene Auslöser des Problemes und man sollte aus meiner Sicht den Duty Cycle überwachen und bei einem kritischer Wert eine Info aufs Handy versenden. In den meisten Installationen wird es aufgrund der Anzahl der eingesetzten Aktoren oder der Anzahl von Programmen wahrscheinlich nie zu einem Problem kommen. Aber schon ein defekter Aktor oder ein Firmware Update kann es Auslösen. Ich beschreibe in diesem Artikel was Duty Cycle bedeutet, wie man ihn überwachen und melden kann. Weiter zeige ich ein paar Gefahren auf, die zum Problem mit Duty Cycle führen können. Natürlich führe ich auch ein paar Möglichkeiten auf, um den Duty Cycle im Zaum zu halten.
Übertrieben? Ich finde nicht, denn wenn der Duty Cycle mal bei 100% angekommen ist, steht eure komplette Hausautomation, egal ob auf der CCU2 oder RaspberryMatic für eine Stunde still. Das ist auch durch einen Neustart nicht zu beheben und besonders kritisch, wenn ihr mit HomeMatic eine Alarmanlage realisiert habt. Der gesamte Funkverkehr zwischen Zentrale und allen Aktoren ist für eine Stunde lahmgelegt.
Was bedeutet Duty Cycle? (Quelle eQ-3)
Der Duty Cycle beschreibt eine gesetzlich geregelte Begrenzung der Sendezeit von Geräten im 868 MHz Bereich. Das Ziel dieser Regelung ist es, die Funktion aller im 868 MHz Bereich arbeitenden Geräte zu gewährleisten.
In dem von uns genutzten Frequenzbereich 868 MHz beträgt die maximale Sendezeit eines jeden Gerätes 1 % einer Stunde (36 Sekunden in einer Stunde). Die Geräte dürfen bei Erreichung des 1 %- Limits nicht mehr senden, bis diese zeitliche Begrenzung vorüber ist.)
Im normalen Betrieb wird der Duty Cycle in der Regel nicht erreicht. Dieses kann jedoch in Einzelfällen, bei der Inbetriebnahme oder Erstinstallation eines Systems durch vermehrte und funkintensive Anlernprozesse, der Fall sein. Dies tritt beispielsweise beim Einstellen und Testen des Erfassungsbereiches von angelernten Bewegungsmeldern auf. Eine Überschreitung des Duty Cycle Limits kann sich durch eine temporär fehlende Funktion äußern.
Das geschilderte Verhalten ist darauf zurückzuführen, dass im 868 MHz Bereich keine Dauersender zulässig sind (maximale Sendezeit 36 Sekunden/Std) und daher werden beim Erreichen dieses Limits alle weiteren Sendevorgänge unterbunden. Nehmen Sie eine kurze Funktionsprüfung des Gerätes vor (z.B. durch Entnehmen und Wiedereinsetzen der Batterien). Sollte das Gerät danach noch nicht wieder einsatzbereit sein, ist dies auf die Überschreitung des Duty Cycles zurückzuführen und die Funktion des Gerätes ist nach einer Stunde wieder hergestellt.
Lösungsansatz
Wie kann man die oben beschriebenen Probleme und Auswirkungen durch einen zu hohen Duty Cycle verhindern?
Als Erstes müssen wir eine Möglichkeit finden, den Duty Cycle auszuwerten. Leider bietet weder die Hardware noch die Firmware von HomeMatic diese Funktion von Hause aus. Wenn wir den aktuellen Wert des Duty Cycle kennen, möchte ich eine automatische Alarmierung auf mein Handy bekommen, um über bevorstehende Probleme bzw. einen definierten Schwellwert informiert zu werden.
UPDATE:
Seit der RaspberryMatic Version 2.31.25.20180428 ist es möglich die Duty Cycle Werte direkt innerhalb von RaspberryMatic auszuwerten. Ohne das hier vorgestellte Skript. Diese Lösung funktioniert nicht auf der CCU2 oder CCU3. Hier findet ihr detaillerte Informationen dazu.
Abschließend zeige ich dann sowohl ein paar mögliche Ursachen für einen hohen Duty Cycle auf, sowie diverse Möglichkeiten das Problem in den Griff zu bekommen.
Auswertung des aktuellen Duty Cycles
Auf der Suche nach einer Möglichkeit den Duty Cycle auszuwerten bin ich HomeMatic-Forum auf ein Script von Alchy gestoßen. Es gibt dieses Script in zwei Varianten. Zum einen mit dem Einsatz eines TCL-Scriptes.
TCl = (Aussprache englisch tickle oder auch als Abkürzung für Tool command language) ist eine Open-Source-Skriptsprache.
TCL-Skripte müssen per SSH oder FTP auf die CCU oder Raspberry übertragen werden, um diese dann über ein HomeMatic-Skript innerhalb eines HomeMatic Programmes aufzurufen.
Da dieser Artikel auch Anwender ansprechen soll, die damit nicht so vertraut sind, verwende ich die einfachere Version eines HomeMatic-Skriptes. Im Ergebnis sind beide Varianten gleichwertig. Sollte Interesse an der TCL Variante bestehen, schreibt mit bitte einfach eine Mail.
Script und Systemvariablen einrichten
Ich habe das entsprechende Script von Alchy im HomeMatic-Forum gefunden (Danke dafür). Ich verwende dieses Script bei mir auch, habe aber die weitere Verarbeitung angepasst bzw. erweitert.
Nachfolgend beschreibe ich, wie ihr das Ganze in eurem HomeMatic System einbinden könnt.
Voraussetzung CUx-Daemon
Da das Script in einem sehr kurzen Zeit-Intervall aufgerufen wird, empfehle ich das AddOn CUx-Daemon (CUxD) zu verwenden. Es ist die deutlich bessere Methode um Systembefehle aufzurufen. Weil die Methode über „system.exec“ bei so etwas sehr schnell zu Problemen führt. Wie ihr das AddOn CUxD installiert und ein virtuelles Gerät einrichten könnt, habe ich im Artikel „AddOn CUx-Daemon (CUxD) – system.exec ersetzen“ beschrieben. Keine Sorge, das ist recht einfach.
Script zum Auslesen Duty Cycle von allen Interfaces
Ich habe mich entschieden hier das Script einzufügen welches alle Interface in eurer HomeMatic Installation anzeigt und auswertet. Damit ist gemeint, dass neben der HomeMatic Zentrale (CCU2 oder RaspberryMatic) auch die vorhandenen LAN-Gateways ausgewertet werden. Egal ob ihr nur eine CCU2 betreibt oder zusätzlich LAN-Gateways, ist egal. Das Script funktioniert in jedem Fall.
! DutyCycle aller Interface mit HM Script und CUxD.exec auslesen und in Systemvariablen speichern
! und Verbindungsstatus auslesen und in Systemvariablen speichern
! v0.5 (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:2001/ 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");
}
}
Am besten führt ihr das Script erst einmal unter „Script testen“ aus. Dazu müsst ihr in der WebUI die folgende Funktion aufrufen:
Startseite > Programme und Verknüpfungen > Programme
Am unteren Bildschirmrand findet ihr den Button „Script testen“. Diesen bitte klicken und das Script in das obere Fenster einfügen. Dabei die vorhandene Zeile „Hallo Welt“ löschen bzw. überschreiben. Wenn ihr das Script eingefügt habt, bitte „Ausführen“ klicken. (siehe Screenshot)
Erklärung der Ausgabe
In der ersten Zeile findet ihr die Seriennummern der gefundenen Interface und den aktuellen Duty Cycle. Bei mir ist die erste Seriennummer mein LAN-Gateway mit einem Duty Cycle von 6 und die Zweite meine HomeMatic Zentrale mit RaspberryMatic mit einem Duty Cycle von 12.)
In den nächsten vier Zeilen findet ihr die Namen der Systemvariablen (VariableDC1, VariableDC2, VariableCON1 und VariableCON2), welche angelegt werden müssen, um die entsprechenden Werte zu speichern. Neben dem Wert des jeweiligen Duty Cycles wird ebenfalls der Verbindungsstatus ausgewertet und gespeichert.
Systemvariablen anlegen und im Script anpassen
„Script testen“ bitte mit „Schließen“ verlassen.
Wenn ihr die Namen der Variablen so lassen wollt, reicht es die benötigten Systemvariablen anzulegen. Ich habe bei meiner Installation die Namen der Variablen angepasst und die Namen der Gateways eingefügt.
Dazu müsst ihr zuerst über das WebUI Menü: Startseite > Einstellungen > Systemvariable und der Funktion „Neu“ die entsprechenden Variablen mit dem notwendigen Typ anlegen:
Für den Duty Cycle eine Variable vom Typ „Zahl“ mit den Werten 0 bzw. 100 anlegen.
Für den Verbindungsstatus eine Variable vom Typ „Logikwert“ mit den entsprechenden Eintragungen.
Bei Verwendung von weiteren Interfaces (LAN-Gateway) analog die weiteren Variablen anlegen.
Programm erstellen
Nun müsst ihr ein Programm erstellen, welches das oben aufgeführte Script zyklisch durchführt. Dabei solltet ihr es beim Zyklus nicht übertreiben. Es reicht vollkommen aus wenn das Programm alle 5-15 Minuten ausgeführt wird. Die CCU aktualisiert den Wert auch nicht alle paar Sekunden.
Wenn ihr die Variablen wie im Ursprungs-Script vorhanden, behalten wollt, dann könnt ihr ohne Änderung speichern.
Habt ihr die Variablen jedoch verändert, dann müsst ihr diese in den beiden folgenden Zeilen im Script anpassen bevor ihr speichert.
Ab diesem Zeitpunkt läuft das Programm in dem definierten Zyklus und füllt die angelegten Systemvariablen.
Systemvariablen anzeigen und auswerten
Nachdem wir nun die Werte des Duty Cycles regelmäßig ermitteln, müssen wir eine Möglichkeit schaffen, diese zum einen anzuzeigen, zum anderen zu sammeln, um später einen Trend zu erkennen. Des Weiteren sollte eine Überwachung der Werte mittels Programm erfolgen, um Warnmeldungen aufs Handy zu senden, wenn ein Schwellwert überschritten wird.
Als Erstes lasse ich mir die Werte der Systemvariablen auf dem WebUI Startbildschirm anzeigen:
Automatische Alarmierung bei Schwellwerten
Um mich rechtzeitig informieren zu lassen wenn der Duty Cycle ungewöhnlich stark ansteigt, habe ich für mich einen Schwellwert von 50% festgelegt- Wird dieser erreicht oder überschritten, sende ich mir eine PUSH Nachricht über Telegram auf mein Handy. Wie das über den CUx-Daemon geht, findet ihr hier.
Hier findet ihr das entsprechende Programm:
Sinnvolle Zusatzfunktion
In dem oben beschriebenen Script wird auch der Verbindungstatus der diversen Interface überprüft und in eine Variable geschrieben. Daher können wir dies auch nutzen uns per PUSH Nachricht über Verbindungsprobleme informieren zu lassen.
Weitergehende Analyse des Duty Cycles
Mit den bisher vorgestellten Möglichkeiten können wir den Duty Cycle im Auge behalten bzw. werden informiert wenn er ungewöhnlich stark ansteigt.
Hier möchte ich euch noch eine Möglichkeit vorstellen, den Duty Cycle im Bedarfsfalle genauer zu analysieren, um einen Grund zu finden, warum er ansteigt.
Dazu müsst ihr als erstes die beiden definierten Systemvariablen mit den Werten für den Duty Cycle auf „protokoliert“ setzen. Dadurch werden die Werte für den Duty Cycle im Zyklus der Programm Durchführung in das Systemprotokoll geschrieben.
ACHTUNG: Bei einem Zyklus von 5 bis 15 Minuten werden sehr viele Sätze in das Systemprotokoll geschrieben. Daher solltet ihr das Systemprotokoll regelmäßig löschen, nachdem ihr die Daten zur Auswertung exportiert habt.
Auszug aus Systemprotokoll mit gesetztem Filter „DC_“
Wenn ihr die Daten aus HomeMatic exportiert, könnt ihr im Excel entsprechende Grafiken erstellen, welche den Verlauf des Duty Cycles im Laufe eines Tages darstellt. Nachfolgend ein Beispiel:
Man kann dann sehr einfach feststellen wo Spitzen im Duty Cycle existieren und dann nach der Ursache forschen, um entsprechende Maßnahmen zu ergreifen. Was das konkret bedeutet, versuche ich im nachfolgenden Absatz zu beschrieben.
Was ist zu tun um einen erhöhten Duty Cycle zu vermeiden
Wie bereits am Anfang dieses Artikel beschrieben ist der Duty Cycle eine sehr wichtige Komponente für den Funkverkehr innerhalb einer HomeMatic Installation. Die wichtigste Aussage ist, unnötigen Funkverkehr zu vermeiden. Das ist grundsätzlich schon eine sinnvolle Idee, aber in Bezug auf den zur Verfügung stehenden Funkverkehr von gerade einmal 36 Sekunden in einer Stunde, ist das fast schon existenziell für unsere Hausautomation.
Zur Wiederholung: Wenn die 100% erreicht sind, geht eine Stunde lang nichts mehr in eurer Installation!
Funkverkehr reduzieren durch die Nutzung von Systemvariablen
Wenn man verstärkt mit Systemvariablen arbeitet, um beispielsweise den Status einer Lampe auszuwerten, verhindert das sehr viel unnötigen „teuren“ Funkverkehr. Der Status wir beim Anschalten der Lampe auf AN und beim Ausschalten der Lampe auf AUS gesetzt werden. Danach kann ich beliebig oft den Status der Systemvariablen abfragen, ohne eine Funkbefehl zu generieren. Diese Abfragen sind „billige“ Befehle, weil sie keinen Funkverkehr generieren und auch sonst die CCU nicht besonders fordern.
Funkverkehr reduzieren durch deaktivieren von Bewegungsmeldern
Ich habe in meiner Installation eine Vielzahl von verschiedenen Bewegungsmeldern. Wenn viel Bewegung im Haus ist, wird durch die Bewegungsmelder auch viel Funkverkehr generiert. Dort wo bei Anwesenheit nicht unmittelbar eine Aktion durch einen Bewegungsmelder ausgelöst wird, macht es durchaus Sinn ihn zu deaktivieren. Leider geht das nur mit den HomeMatic IP Bewegungsmelder und dem IP Präsenzmelder. Die HomeMatic Bewegungsmelder können leider nicht deaktiviert werden.
Funkstörungen vermeiden
Es ist relativ einfach in einem Programm viele Befehle zur gleichen Zeit abzuschicken. Wenn ich in einem Programm mehrere Befehle an verschiedene Aktoren gleichzeitig sende, kommt es des Öfteren zu Kommunikationsproblemen. Das führt dann zu verstärktem Funkverkehr, um die Befehle an den Aktor zu senden bzw. die für BidCoS übliche Bidirektionale Kommunikation die Status-Rückmeldung des Aktors. Eine Vielzahl dieser Probleme lassen sich einfach vermeiden, indem man die Befehle ein wenig entzerrt. Das heißt wenn ich mehrere Befehle in einem Programm an viele Aktoren senden will, dann am besten um 1 bis 2 Sekunden zeitversetzt.
Direkte Verknüpfungen verwenden
Über eine direkte Verknüpfung bzw. eine virtuelle Fernbedienung können sehr umfangreiche Programme nicht nur deutlich schneller ausgeführt werden können, sondern auch in hohem Maße Funkverkehr reduziert werden. Die Einrichtung ist sicherlich deutlich aufwendiger, aber der Aufwand lohnt sich auf jeden Fall. Die Aktoren kommunizieren direkt miteinander, ohne CCU2 zu belasten. Ja es funktioniert sogar wenn die CCU nicht verfügbar ist. Als Beispiel führe ich hier mal ein Programm auf, welches über eine Fernbedienung alle Lampen im Haus ausschalten soll. Da kommt mit den Rückmeldungen eine Vielzahl von Funkverkehr zustande.
Programme in Abhängigkeit vom Duty Cycle ausführen
Da wir ja durch die in diesem Artikel beschriebene Auswertung des Duty Cycle eine neue Systemvariable erstellt haben, sind wir auch in der Lage diesen Wert in Programmen als Durchführungsbedingung abzufragen. So wäre es beispielweise möglich bei Überschreitung des Schwellwertes Programme wie die Status Überprüfung von Licht oder Rollläden auszusetzen bis der Duty Cycle wieder gesunken ist. Aktuell habe ich bei mir ein entsprechendes Beispiel. Waschmaschine und Trockner hängen an einer Schaltsteckdose mit Leistungsmessung. Damit kann ich über einen MP3 Gong eine entsprechende Information ausgeben, wenn eine dieser beiden Maschinen fertig ist. Beim Trockner wiederholt sich diese Ansage aufgrund des Knitterschutzes eine Stunde lang alle 2 Minuten. Als wir mal außer Haus waren, hat diese vermeintlich kleine Aktion hat meinen Duty Cycle sehr schnell auf über 90% gesteigert. Ursache: Meldung von Steckdose an Zentrale. Von dort an MP3 Gong im Minutentakt. Ich habe daraufhin im entsprechenden Programm eine Abfrage des Duty Cycles eingebaut und wenn der über 50% liegt, wird diese Aktion nicht mehr ausgeführt. Eine weitere Option wäre gewesen das Programm bei Abwesenheit nicht zu starten.
LAN-Gateway
Die effektivste Möglichkeit den Duty Cycle zu reduzieren ist natürlich die Installation eines LAN-Gateways. Das hat zum einen den Vorteil, dass es bei großen Objekten oder schwierigen Funk-Bedingungen zu deutlich weniger Kommunikationsproblemen kommt. Ein noch viel wichtiger Faktor in Bezug auf den Duty Cycle ist jedoch die Tatsache, dass die Aktoren so auf die CCU und ein oder maximal drei LAN-Gateways aufgeteilt werden können. Somit kann der Funkverkehr der CCU reduziert und auf ein LAN-Gateway übertragen werden. Ich habe das bei mir auch gemacht und so die Duty Cycles beider Interface auf ungefähr den gleichen Wert gebracht. Das kann man dynamisch jederzeit verändern und die Auswirkungen prüfen.
https://technikkram.net/wp-content/uploads/2019/05/technikkram_transparent.png00Wernerhttps://technikkram.net/wp-content/uploads/2019/05/technikkram_transparent.pngWerner2017-08-21 07:52:592018-04-29 21:55:40HomeMatic & RaspberryMatic: Duty Cycle, eine schlummernde GEFAHR und was man tun kann
34Kommentare
Tobias sagte:
Bei mir schmeisst das Programm als Duty Cycle immer nur 1.0 aus. Muss ich die IP Adresse der CCU anpassen?
ein wirklich sehr toller Bericht. Aber einige Fragen habe ich da noch. Im Text steht das … über eine Direkte Verknüpfungen bzw. eine virtuelle Fernbedienung …. der Funkverkehr drastisch reduziert werden kann und das diese auch ohne CCU funktionieren. Das verstehe ich nicht ganz. Ok, bei einer „echten“ Direkten Verknüpfungen kann ich das nachvollziehen, da die Aktoren sich direkt ohne CCU unterhalten. Aber bei einer virtuellen Fernbedienung dürfte das schalten von z. B. mehreren Aktoren doch nicht mehr funktionieren wenn die CCU nicht verfügbar ist, oder? Ich „schalte“ den virt. Taster ja über ein Programm, dazu muss die CCU doch laufen. Und wie wird denn über eine virtuelle Fernbedienung der Funkverkehr reduziert? Die CCU muss doch auch hierüber die entsprechenden Aktoren anfunken damit diese reagieren. Ich selber nutze seit kurzem 2 virtuelle Taster in der CCU um 9 Rollladen-Aktoren zu öffnen und zu schließen (über die linke und rechte oberen Taster bei einem HM-6-Fach-Taster). Funktioniert auch Einwandfrei. Vorher habe ich das über ein Programm realisiert das jeden Aktor zeitverzögert um 2 Sekunden geschaltet hat. Hier kam es ab und zu vor, das ein Rollladen nicht hoch oder runter gefahren ist (Kommunikationsstörung). Daher habe ich mich für die virtuellen Taster der CCU entschieden. Ein weiterer Vorteil, so hatte ich das immer gedacht, wäre die Verringerung des Funkverkehrs. Im Homematic-Forum hatte ich das Thema auch schon mal angesprochen, da wird aber erklärt, das durch Nutzung der virt. Taster in der CCU sogar noch ein Befehl mehr gesendet wird und dadurch der Duty Cycle eher noch steigt als singt.
Was ist denn jetzt richtig bzw. gibt es irgendeine Doku die das genau erklärt (direkte Verknüpfung / virtuelle Taster)?
Da ich auch noch weitere (mehrere) Rollläden, Lichter etc. über Taster und Programmen schalte, wollte ich eigentlich alle Programme durch virtuelle Taster „ablösen“. Wenn es außer dem Vorteil das alle Quellen gleichzeitig geschaltet werden keine weiteren Vorteile gibt (reduzierung des Feunkverkehr, lauffähig auch ohne CCU), könnte ich mir das ja sparen.
nochmal eine Info an alle die Probleme mit dem Script haben.
Ich habe das Script so wie es im Artikel angegeben ist, heute nochmal kopiert und getestet. Es funktioniert. Natürlich müssen dazu auch die Voraussetzungen im CuxD erfüllt sein (CuxD installieren und Gerät wie beschrieben anlegen). Zusätzlich müssen natürlich auch die definierten Variablen im System und dem Skript übereinstimmen.
Die letzte geschlossene Klammer ist nicht unbedingt erforderlich, führt jedoch nicht zu einem Fehler. (Mehrfach getestet, mit und ohne Klammer).
Aus der Kommunaktion und Fehleranalyse mit Anwendern ist abzuleiten, das sehr viele der Probleme (Skript läuft nicht) aus den oben beschriebenen Gründne zustande kommen.
Eine weitere Fehlerquelle ist das Kopieren des Skripts selbst. Um das auszuschalten, hänge ich das Skript hier noch einmal in einer anderen Form wie im Artikel an (Inhalt identisch).
! DutyCycle aller Interface mit HM Script und CUxD.exec auslesen und in Systemvariablen speichern
! und Verbindungsstatus auslesen und in Systemvariablen speichern
! v0.5 (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:2001/ 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“);
}
}
Grüße Werner
Bei Problemen bitte eine Mail schreiben. Die Erfahrung zeigt, das es danach funktioniert. Danke
Hallo Werner,
erstmal vielen Dank für die tollen Beiträge, die mir schon oft weitergeholfen haben.
Hatte gerade auch das Problem das vom Duty Cycle Script nichts ausgegeben wurde. Lag bei mir aber daran dass ich CUxD nur installiert hatte. Den CUxDaemon hatte ich nicht angelegt. Nachdem der Gerätetyp „(28) System“ im CUxD definiert war, wie in deiner Beschreibung erwähnt, läuft Duty Cycle wie es soll.
Vielen dank für das tolle Skript und den Beitrag. Ich habe damit einen Verursacher gefunden, der in meinem System für Chaos sorgt. Was mich total irritiert (falls du das hier pauschal beantworten kannst und willst). Ich habe auch ein LAN-Gateway wie im Skript. An all meinen Fenstern sind Fensterkontakte, die ihren Status nach dem Öffnen an das HM Display mit den LED melden. Und obwohl nicht einer der Kontakte am LAN-Gateway angemeldet ist sondern alle über die CCU2 laufen erhöht sich die Wert bei der Variable, welche den Zustand des DutyCycle für das Gateway festhält. Ich habe das mehrfach getestet und es ist kein Irrtum. Kann das sein? Habe ich was falsch verstanden? Danke!
Hi, wie fast du mit dem Script den direkten Verursacher herausgefunden? Bei mir geht der Dutycycle hoch bis 99%. Wie kann ich den Verursacher einfach finden?
Hallo, auch bei mir liefert das Programm keine Ergebnisse.
Ich habe etwas getestet und in jeder Zeile ein WriteLine eingefügt. Es zeigt sich, dass das Programm beim ersten Aufruf des DOM.GetObject ohne Fehlermeldung aussteigt.
In den CUX Einstellungen des Addons sehe ich bei mir den RPC Port eingestellt auf 8701 anstelle von 2001. Aber auch nach ändern des Ports bleibt es dabei, das Script will ab da nicht weiter…
Was muss im CUX oder wo auch immer noch eingestellt werden, damit der Dom.Getobject aufgerufen werden kann?
Hallo Christian,
in den bisherigen Fällen wo es nicht funktionierte, hat es entweder an einem Kopierfehler beim Script oder an den Systemvariablen gelegen.
Ich habe dir gerade eine Mail geschickt, mit einer detailierten Beschreibung zur Fehlersuche und den Script-Code als TXT-File.
Viel Erfolg und Gruss
Werner
Hallo Werner, danke für den sehr interessanten Beitrag.
Leider bleibt bei meinem RaspberryMatic (aktuelles Image) mit dem Script die Ausgabe auch leer.
(Das vorgegebene „Hello World “ liefert aber eine Ausgabe.)
Hallo Diwa,
ich habe es jetzt bei mir nochmals komplett von vorne aufgesetzt und ich kann aktuell die Probleme nicht nachvollziehen.
Morgen sende ich dir mal eine Mail mit ein paar Punkten mit der Bitte um Beantwortung, um das Problem zu analysieren und zu beheben.
Grüße Werner
vielen Dank für die ausführliche Beschreibung per Email.
Das Script funktioniert jetzt bei mir wie es soll.
Ich beschäftige mich erst seit ein paar Tagen mit HomeMatic. Die Ursache für das Nicht-Funktionieren lag nicht an dem Script, sondern daran, dass mir einfach noch vieles Hintergrundwissen fehlt.
Vielen Dank für die kompetente Unterstützung!
Diwa
Error 1 at row 7 col 83 near ^Â
integer i = 0;
boolean conn = false;
dom.GetObject(„CUxD.CUX2801003:1.CMD_SET
Parse following code failed:
! DutyCycle aller Interface mit HM Script und CUxD.exec auslesen und in Systemvariablen speichernÂ
! und Verbindungsstatus auslesen und in Systemvariablen speichern
Hallo Sven,
ich habe es jetzt bei mir nochmals komplett von vorne aufgesetzt und ich kann aktuell die Probleme nicht nachvollziehen.
Morgen sende ich dir mal eine Mail mit ein paar Punkten mit der Bitte um Beantwortung, um das Problem zu analysieren und zu beheben.
Grüße Werner
Guten Abend, ich habe nun auch einmal das Skript getestet aber wie auch bei Jens bleibt das untere Feld leer.
Habt Ihr dafür schon eine Lösung gefunden?
P.S: Sehr schöne Erklärungen auf Deiner Seite. Macht Spaß zu lesen ;-)
Raspberry Pi3 mit der V.2.29.22.20170902.
Hallo,
ich habe es jetzt bei mir nochmals komplett von vorne aufgesetzt und ich kann aktuell die Probleme nicht nachvollziehen.
Morgen sende ich dir mal eine Mail mit ein paar Punkten mit der Bitte um Beantwortung, um das Problem zu analysieren und zu beheben.
Grüße Werner
Hallo Björn,
ich habe es jetzt bei mir nochmals komplett von vorne aufgesetzt und ich kann aktuell die Probleme nicht nachvollziehen.
Morgen sende ich dir mal eine Mail mit ein paar Punkten mit der Bitte um Beantwortung, um das Problem zu analysieren und zu beheben.
Grüße Werner
Hallo, was kann das sein wenn bei mir unter Script testen nichts angezeigt wird?
Ich habe das Script kopiert und eingefügt.
Nutzen tu ich RaspberryMatic in der neuesten Version.
Gruss
Hallo Jens,
ich habe gerade nochmal das Script aus dem Beitrag kopiert und ausgeführt. Ich nutze ebenfalls RaspberryMatic und es funktioniert wie beschrieben.
Schreib mir eine Mail mit Screenshots. Vielleicht können wir dann gemeinsam die Ursache finden.
Werner
Hallo Jens,
ich habe es jetzt bei mir nochmals komplett von vorne aufgesetzt und ich kann aktuell die Probleme nicht nachvollziehen.
Morgen sende ich dir mal eine Mail mit ein paar Punkten mit der Bitte um Beantwortung, um das Problem zu analysieren und zu beheben.
Grüße Werner
So es gibt gute News, danke an Werner für den tollen Support.
Durch löschen und neu anlegen der Variablen in der CCU hat sich das Problem gelöst. Funktioniert jetzt. Klasse Sache.
Danke für den hilfreichen Beitrag.
Da ich durch meine BW den Dutycycle nicht in den Griff bekam, liegt er nun bei max 10 Prozent, egal was ich zuhause anstelle. Ok, wenn ich Geräre umkonfiguriere oder anlerne, kann er schon mal auf 100 Prozent steigen. Das ist aber meines erachtens aber systembedingt, weil die CCU dann viele Daten senden muß.
Bei mir schmeisst das Programm als Duty Cycle immer nur 1.0 aus. Muss ich die IP Adresse der CCU anpassen?
Moinsens,
ein wirklich sehr toller Bericht. Aber einige Fragen habe ich da noch. Im Text steht das … über eine Direkte Verknüpfungen bzw. eine virtuelle Fernbedienung …. der Funkverkehr drastisch reduziert werden kann und das diese auch ohne CCU funktionieren. Das verstehe ich nicht ganz. Ok, bei einer „echten“ Direkten Verknüpfungen kann ich das nachvollziehen, da die Aktoren sich direkt ohne CCU unterhalten. Aber bei einer virtuellen Fernbedienung dürfte das schalten von z. B. mehreren Aktoren doch nicht mehr funktionieren wenn die CCU nicht verfügbar ist, oder? Ich „schalte“ den virt. Taster ja über ein Programm, dazu muss die CCU doch laufen. Und wie wird denn über eine virtuelle Fernbedienung der Funkverkehr reduziert? Die CCU muss doch auch hierüber die entsprechenden Aktoren anfunken damit diese reagieren. Ich selber nutze seit kurzem 2 virtuelle Taster in der CCU um 9 Rollladen-Aktoren zu öffnen und zu schließen (über die linke und rechte oberen Taster bei einem HM-6-Fach-Taster). Funktioniert auch Einwandfrei. Vorher habe ich das über ein Programm realisiert das jeden Aktor zeitverzögert um 2 Sekunden geschaltet hat. Hier kam es ab und zu vor, das ein Rollladen nicht hoch oder runter gefahren ist (Kommunikationsstörung). Daher habe ich mich für die virtuellen Taster der CCU entschieden. Ein weiterer Vorteil, so hatte ich das immer gedacht, wäre die Verringerung des Funkverkehrs. Im Homematic-Forum hatte ich das Thema auch schon mal angesprochen, da wird aber erklärt, das durch Nutzung der virt. Taster in der CCU sogar noch ein Befehl mehr gesendet wird und dadurch der Duty Cycle eher noch steigt als singt.
Was ist denn jetzt richtig bzw. gibt es irgendeine Doku die das genau erklärt (direkte Verknüpfung / virtuelle Taster)?
Da ich auch noch weitere (mehrere) Rollläden, Lichter etc. über Taster und Programmen schalte, wollte ich eigentlich alle Programme durch virtuelle Taster „ablösen“. Wenn es außer dem Vorteil das alle Quellen gleichzeitig geschaltet werden keine weiteren Vorteile gibt (reduzierung des Feunkverkehr, lauffähig auch ohne CCU), könnte ich mir das ja sparen.
Schönen Gruß
Frank
Hallo Zusammen,
nochmal eine Info an alle die Probleme mit dem Script haben.
Ich habe das Script so wie es im Artikel angegeben ist, heute nochmal kopiert und getestet. Es funktioniert. Natürlich müssen dazu auch die Voraussetzungen im CuxD erfüllt sein (CuxD installieren und Gerät wie beschrieben anlegen). Zusätzlich müssen natürlich auch die definierten Variablen im System und dem Skript übereinstimmen.
Die letzte geschlossene Klammer ist nicht unbedingt erforderlich, führt jedoch nicht zu einem Fehler. (Mehrfach getestet, mit und ohne Klammer).
Aus der Kommunaktion und Fehleranalyse mit Anwendern ist abzuleiten, das sehr viele der Probleme (Skript läuft nicht) aus den oben beschriebenen Gründne zustande kommen.
Eine weitere Fehlerquelle ist das Kopieren des Skripts selbst. Um das auszuschalten, hänge ich das Skript hier noch einmal in einer anderen Form wie im Artikel an (Inhalt identisch).
! DutyCycle aller Interface mit HM Script und CUxD.exec auslesen und in Systemvariablen speichern
! und Verbindungsstatus auslesen und in Systemvariablen speichern
! v0.5 (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:2001/ 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“);
}
}
Grüße Werner
Bei Problemen bitte eine Mail schreiben. Die Erfahrung zeigt, das es danach funktioniert. Danke
Hallo Werner,
erstmal vielen Dank für die tollen Beiträge, die mir schon oft weitergeholfen haben.
Hatte gerade auch das Problem das vom Duty Cycle Script nichts ausgegeben wurde. Lag bei mir aber daran dass ich CUxD nur installiert hatte. Den CUxDaemon hatte ich nicht angelegt. Nachdem der Gerätetyp „(28) System“ im CUxD definiert war, wie in deiner Beschreibung erwähnt, läuft Duty Cycle wie es soll.
Gruß Gernot
Man sollte halt
Guten Morgen Gernot,
vielen Dank für deine anerkennenden Worte und prima dass das Skript bei dir funktioniert.
Gruss und ein schönes Osterfest
Werner
Vielen dank für das tolle Skript und den Beitrag. Ich habe damit einen Verursacher gefunden, der in meinem System für Chaos sorgt. Was mich total irritiert (falls du das hier pauschal beantworten kannst und willst). Ich habe auch ein LAN-Gateway wie im Skript. An all meinen Fenstern sind Fensterkontakte, die ihren Status nach dem Öffnen an das HM Display mit den LED melden. Und obwohl nicht einer der Kontakte am LAN-Gateway angemeldet ist sondern alle über die CCU2 laufen erhöht sich die Wert bei der Variable, welche den Zustand des DutyCycle für das Gateway festhält. Ich habe das mehrfach getestet und es ist kein Irrtum. Kann das sein? Habe ich was falsch verstanden? Danke!
Hi, wie fast du mit dem Script den direkten Verursacher herausgefunden? Bei mir geht der Dutycycle hoch bis 99%. Wie kann ich den Verursacher einfach finden?
Gruß
Heiko
Hallo, auch bei mir liefert das Programm keine Ergebnisse.
Ich habe etwas getestet und in jeder Zeile ein WriteLine eingefügt. Es zeigt sich, dass das Programm beim ersten Aufruf des DOM.GetObject ohne Fehlermeldung aussteigt.
In den CUX Einstellungen des Addons sehe ich bei mir den RPC Port eingestellt auf 8701 anstelle von 2001. Aber auch nach ändern des Ports bleibt es dabei, das Script will ab da nicht weiter…
Was muss im CUX oder wo auch immer noch eingestellt werden, damit der Dom.Getobject aufgerufen werden kann?
…Zeile 10 im Code
Hallo,
leider funktioniert das Skript leider bei mir auch nicht, das Feld bleibt leer.
Könntet ihr das funktionierende Skript bitte nochmal posten.
vielen Dank
Hallo Christian,
in den bisherigen Fällen wo es nicht funktionierte, hat es entweder an einem Kopierfehler beim Script oder an den Systemvariablen gelegen.
Ich habe dir gerade eine Mail geschickt, mit einer detailierten Beschreibung zur Fehlersuche und den Script-Code als TXT-File.
Viel Erfolg und Gruss
Werner
Hallo Sven,
bei mir tritt das gleiche Problem auf (RaspiMatic aktuelles Image)
Geht das Script jetzt bei Dir?
Viele Grüße
Frank
Hallo Frank
Wenn ich nachher wieder Zuhause bin schicke ich dir die Mail die Sven geholfen hat.
Werner
Lieben Dank – freue mich auf Deine Email!
Hallo Werner, danke für den sehr interessanten Beitrag.
Leider bleibt bei meinem RaspberryMatic (aktuelles Image) mit dem Script die Ausgabe auch leer.
(Das vorgegebene „Hello World “ liefert aber eine Ausgabe.)
Hallo Diwa,
ich habe es jetzt bei mir nochmals komplett von vorne aufgesetzt und ich kann aktuell die Probleme nicht nachvollziehen.
Morgen sende ich dir mal eine Mail mit ein paar Punkten mit der Bitte um Beantwortung, um das Problem zu analysieren und zu beheben.
Grüße Werner
Hallo Werner,
vielen Dank für die ausführliche Beschreibung per Email.
Das Script funktioniert jetzt bei mir wie es soll.
Ich beschäftige mich erst seit ein paar Tagen mit HomeMatic. Die Ursache für das Nicht-Funktionieren lag nicht an dem Script, sondern daran, dass mir einfach noch vieles Hintergrundwissen fehlt.
Vielen Dank für die kompetente Unterstützung!
Diwa
Error 1 at row 7 col 83 near ^Â
integer i = 0;
boolean conn = false;
dom.GetObject(„CUxD.CUX2801003:1.CMD_SET
Parse following code failed:
! DutyCycle aller Interface mit HM Script und CUxD.exec auslesen und in Systemvariablen speichernÂ
! und Verbindungsstatus auslesen und in Systemvariablen speichern
Die o.g. Fehlermeldung erscheint bei mir bei der Fehlerprüfung während der Programmerstellung. Was mache ich falsch?
Hallo Sven,
ich habe es jetzt bei mir nochmals komplett von vorne aufgesetzt und ich kann aktuell die Probleme nicht nachvollziehen.
Morgen sende ich dir mal eine Mail mit ein paar Punkten mit der Bitte um Beantwortung, um das Problem zu analysieren und zu beheben.
Grüße Werner
Hallo Sven,
bei mir tritt das gleiche Problem auf (RaspiMatic aktuelles Image)
Geht das Script jetzt bei Dir?
Viele Grüße
Frank
Ja. Werner hatte mir eine Mail geschickt und damit klappte es dann.
Danke an der Stelle noch mal für den tollen Support.
Das PDF mit der Anleitung kann ich hier leider nicht posten.
Der Code ist aber der folgende:
——
! DutyCycle aller Interface mit HM Script und CUxD.exec auslesen und in Systemvariablen speichern
! und Verbindungsstatus auslesen und in Systemvariablen speichern
! v0.5 (c) by alchy
string listeDC = „DC_HMWLGW1;DC_LANGW;DC_Raspberry“; !Namen der Systemvariablen TYP Zahl, wo DutyCycle gespeichert werden soll ; separiert
string listeCON = „I DC_HMWLGW1_Connect;I DC_LANGW_Connect;I DC_Raspberry_Connect“; !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:4.CMD_SETS“).State(„echo ‚load tclrpc.so; puts [xmlrpc http://127.0.0.1:2001/ listBidcosInterfaces ]’|tclsh „);
dom.GetObject(„CUxD.CUX2801001:4.CMD_QUERY_RET“).State(1);
srueck = dom.GetObject(„CUxD.CUX2801001:4.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“);
}
}
Hi, habe das gleiche Problem. Gibt es ein Update zu dem Standard Script?
Guten Abend, ich habe nun auch einmal das Skript getestet aber wie auch bei Jens bleibt das untere Feld leer.
Habt Ihr dafür schon eine Lösung gefunden?
P.S: Sehr schöne Erklärungen auf Deiner Seite. Macht Spaß zu lesen ;-)
Raspberry Pi3 mit der V.2.29.22.20170902.
Hallo,
bei mir bleibt es auch leer…
Hallo,
ich habe es jetzt bei mir nochmals komplett von vorne aufgesetzt und ich kann aktuell die Probleme nicht nachvollziehen.
Morgen sende ich dir mal eine Mail mit ein paar Punkten mit der Bitte um Beantwortung, um das Problem zu analysieren und zu beheben.
Grüße Werner
Hallo Björn,
ich habe es jetzt bei mir nochmals komplett von vorne aufgesetzt und ich kann aktuell die Probleme nicht nachvollziehen.
Morgen sende ich dir mal eine Mail mit ein paar Punkten mit der Bitte um Beantwortung, um das Problem zu analysieren und zu beheben.
Grüße Werner
Hallo, was kann das sein wenn bei mir unter Script testen nichts angezeigt wird?
Ich habe das Script kopiert und eingefügt.
Nutzen tu ich RaspberryMatic in der neuesten Version.
Gruss
Hallo Jens,
ich habe gerade nochmal das Script aus dem Beitrag kopiert und ausgeführt. Ich nutze ebenfalls RaspberryMatic und es funktioniert wie beschrieben.
Schreib mir eine Mail mit Screenshots. Vielleicht können wir dann gemeinsam die Ursache finden.
Werner
Hallo Jens,
ich habe es jetzt bei mir nochmals komplett von vorne aufgesetzt und ich kann aktuell die Probleme nicht nachvollziehen.
Morgen sende ich dir mal eine Mail mit ein paar Punkten mit der Bitte um Beantwortung, um das Problem zu analysieren und zu beheben.
Grüße Werner
Hi, ich habe leider keine Mail erhalten.
So es gibt gute News, danke an Werner für den tollen Support.
Durch löschen und neu anlegen der Variablen in der CCU hat sich das Problem gelöst. Funktioniert jetzt. Klasse Sache.
Danke für den hilfreichen Beitrag.
Da ich durch meine BW den Dutycycle nicht in den Griff bekam, liegt er nun bei max 10 Prozent, egal was ich zuhause anstelle. Ok, wenn ich Geräre umkonfiguriere oder anlerne, kann er schon mal auf 100 Prozent steigen. Das ist aber meines erachtens aber systembedingt, weil die CCU dann viele Daten senden muß.
Hi, danke für das tolle script. Es erscheint mir allerdings als sei die letzte geschweifte Klammer zuviel weshalb der Parser nicht durchläuft.