HomeMatic-Forum / FHZ-Forum

Mit CUxD und Scripten kann man ja per LOGIT + EXEC 28 gezielt einen Datenpunkt auf Aktualisierung prüfen und dann per Vergleich Value() <> LastValue() nur dann loggen, wenn sich der Wert geändert hat. Das funktioniert soweit problemlos bei mir.

Nun möchte ich aber gerne alle Datenpunkte eines, mehrerer oder aller meine Devices nur dann loggen, wenn sich der Wert des Datenpunktes auch tatsächlich geändert hat. Natürlich kann ich jetzt jeden einzelnen Datenpunkt aller Devices per Script in eine WENN-Bedingung einfügen und dann per Script-Auslösung auf Änderung hin überprüfen, aber: GEHT DAS AUCH ELEGANTER bzw. EINFACHER???

Man kann zwar in CUxD per LOGIT:<Seriennummer des Devices> alle Kanäle eines Devices automatisch mitloggen lassen, aber eben nicht gezielt nur dann, wenn sich der Datenpunkt auch tatsächlich geändert hat.

Eine Sache noch: welche Befehle bewirken eigentlich eine Erhöhung des Duty-Cycles? Jede Nutzung von dom.GetObject() ?

loggt erstmal alle Datenpunkte von unterstützten Geräten.
Das muss aber i.d.R. wirklich nicht sein, macht es aber sehr einfach.
egal
Warum also willst du beim Loggen schon separieren? Muss ja einen Grund haben.

Wenn man nur bestimmte, geänderte Datenpunkte bestimmter Geräte loggen will, dann: Workaround zum Nachdenken:
Man könnte einmalig alle Kanäle die man gerne loggen möchte, in einen Favoriten schieben.
dann sucht man sich einen geeigneten Trigger und durchforstet die Kanäle auf Änderung und loggt sie dann entsprechend der Vorgaben.

ODER

Handelt es sich um eine halbwegs überschaubare Anzahl von Datenpunkten, ist es durchaus machbar ein Programm mit all diesen Datenpunkten verodert zusammenzuklickern und im Dann
dann mittels einem Script denjeweiligen Auslöser zu ermitteln und zu loggen - im Link ist es in eine Variable oder Datei, kann aber genau so gut auf CUxD umgeschrieben werden.

ODER
...

Nudge hat geschrieben: welche Befehle bewirken eigentlich eine Erhöhung des Duty-Cycles? Jede Nutzung von dom.GetObject() ?

Um Himmels Willen nein. Woher kommt denn diese Erkenntnis / Befürchtung?
Der DutyCycle ist das "Maß der möglichen Funkzeitauslastung"
Sofern ich nicht die CCU oder einen Kanal dazu bringe zu funken, oder aufzuwachen usw. (egal ob per Script, oder Programm oder....)
interessiert das den DutyCycle überhaupt nicht.

Natürlich kann ich auch per Script Fehler machen. Da wäre z.B. die AKTIVE Abfrage eines Datenpunktwertes mittels .State() statt Benutzung .Value() (was bekanntermaßen den letzten der CCU bekannten Wert ausgibt)
Oder auch das Schalten eines Datenpunktes, obwohl dieser z.B. schon in dem Zustand ist, wo er hin soll. usw.
Per Script genau so,wie in einem Programm.

Alchy

alchy hat geschrieben: Warum also willst du beim Loggen schon separieren? Muss ja einen Grund haben.

Ich habe zunächst LOGIT=: benutzt. Das erzeugt aber auch eine Menge Müll, den ich nicht brauche. Daher bin ich dazu übergegangen, alle Devices zu loggen (bei mir 17 Stück). Dann wird mir täglich ein Logfile von 4,5 MB erzeugt, daß ich via CUxD-Highchart auswerte. Bereits nach 1-2 Wochen merkt man aber natürlich Verzögerungen beim Laden etc. Möchte nicht wissen, wie das nach einigen Monaten etc. aussieht.
Hab mir dann die Daten im Logfile angesehen: viele Datenpunkte ändern sich garnicht und werden redundant gelogged. Das verschwendet irrsinnig viel Platz!

Nudge hat geschrieben: welche Befehle bewirken eigentlich eine Erhöhung des Duty-Cycles? Jede Nutzung von dom.GetObject() ?

Um Himmels Willen nein. Woher kommt denn diese Erkenntnis / Befürchtung?

Mir war bisher nicht zu 100% klar, wann ein Datenpunkt vom Device angefragt wird und wann nicht. Also: Value() holt den letzen Wert aus der CCU, State() direkt (neu) vom Device.
Danke für die Info!

Deine anderen Vorschläge schaue ich mir nachher mal an. Vielleicht fällt mir dann was dazu ein. Dachte halt, daß man irgendwie die LOGIT-Daten vor dem Loggen noch via Value() <> LastValue() auf Redundanz prüfen kann. Würde sehr viel Datenmüll vermeiden.

Hallo Nudge,

eine Alternative wäre noch der Einsatz von CCU Historian, da kannst Du frei konfigurieren wie die Daten beim loggen gefiltert werden.
Das Ergebnis geht in eine Datenbank mit der Du dann später auch noch viele Möglichkeiten der Datenselektierung hast.

Nachteil:
CCU Historian sollte man besser auf einem separaten System (z.B. Raspi) installieren, da die CCu dafür zu schwach ist.

Grüße
Roland

RolandF hat geschrieben:Hallo Nudge,

eine Alternative wäre noch der Einsatz von CCU Historian, da kannst Du frei konfigurieren wie die Daten beim loggen gefiltert werden.
Das Ergebnis geht in eine Datenbank mit der Du dann später auch noch viele Möglichkeiten der Datenselektierung hast.

Hab ich vor ein paar Wochen schon einmal erfolgreich getestet. Mir hat aber CUxD-Highcharts wegen der Charts besser gefallen.