CUxD Strom loggen funktioniert nur zum Teil

[Gut-Drauf]

Hallo,
ich hatte in letzter Zeit einige Probleme (Duty Cycle, Updates, usw.) Habe einiges geschaft zu beheben, aber leider ist ein Phänomen geblieben, was ich mir aber auch nicht erklären kann bzw. den Fehler nicht finde. Ich habe einen Selbstbau-Stromzähler und logge dessen drei Kanäle. Das klappte auch in der Vergangenheit gut, auch das Anzeigen der drei Stromeingänge L1, L2 und L3. Der Zähler ändert auch in der Geräteansicht seine Werte, aber diese werden in CUxD nur teilweise gelistet. Es ist immer nur der Wert von L3. L1 und L2 werden irgendwie nicht erfasst. Ich habe jetzt mal ein paar Bilder gemacht. Vielleicht habt ihr für mich noch einen Ansatz. Habe auch schon andere Scripte probiert, aber es immer nur L3 der als Wert erscheint.

strom-2.PNG (19.69 KiB) 883 mal betrachtet

strom-6.PNG (11.71 KiB) 883 mal betrachtet

Aufgefallen ist es mir, weil in CUxD-Chart plötzlich manche Wert nicht mehr weitergeschrieben wurden. Andere funktionieren einwandfrei.

[Baxxy]

Alle 3 Kanäle senden / aktualisieren exakt zur gleichen Zeit.
Dabei verschluckt das System gerne mal was, speziell wenn es um Programm-Triggerungen geht.

A: Versuch's mal mit allen 3en in einem Programm aber nur "bei Aktualisierung"

B: Aufteilen in 3 Programme und den Wert jeweils nur bei >= 0.0 "bei Aktualisierung"

C: Script anpassen so das nur ein Kanal als Trigger "bei Aktualisierung" reicht und trotzdem alle 3 Kanäle geloggt werden.

D: Selbstbau Stromzähler modifizieren so das alle 3 Werten nacheinander gesendet werden

[MichaelN]

Alle 3 Kanäle senden / aktualisieren exakt zur gleichen Zeit.
Dabei verschluckt das System gerne mal was, speziell wenn es um Programm-Triggerungen geht.

Und hier wird ja gleich 6* getriggert...ob die Verzögerung des Skript um 1 Sekunde dabei hilfreich ist oder das Problem weiter verstärkt?

[Baxxy]

Gute Frage...

Ob jetzt wirklich 6x getriggert wird kann ich gerade auch nicht sagen. Da müsste ich mal ein Testsetup erstellen und mir das "Logik-Alles-Loggen" Protokoll reinziehen.

Definitiv Quatsch ist aber hier die Doppelung aus "bei Änderung" / "bei Aktualisierung".

[rentier-s]

ob die Verzögerung des Skript um 1 Sekunde dabei hilfreich ist oder das Problem weiter verstärkt?

Mit Verzögerung von Skripten habe ich durchwegs schlechte Erfahrungen gemacht.

Auf mein "zeige alles mögliche an" Display im Flur prasseln haufenweise Trigger ein. Allein wenn mein Online-Wetter Skript die aktuellen Werte in die CCU schiebt, wird das Programm bis zu 4x gleichzeitig aufgerufen.

Damit sich das Skript nicht zu Tode rennt, verwende ich (mal wieder ) die virtuelle Fernbedienung.

Code: Alles auswählen

Wenn...
    virtuelleFernbedienung_TasteDisplay bei Tastendruck kurz
  Dann
    Skript sofort
Sonst, Wenn...
    Temperatur < 100°, bei Aktualisierung
    Wind > 0, bei Aktualisierung
    Fenster Offen >= 0, bei Aktualisierung
    ... ... ...
  Dann
  (X laufende Verzögerungen abbrechen)
    virtuelleFernbedienung_TasteDisplay verzögert um 2 Sek Tastendruck kurz

[Baxxy]

Ja, kann man auch machen.
Wobei man dann im "Logger-Script" die Datenpunkte einzeln abrufen muss da $src$ ja die Virt. Taste ist. Und ggf. die Werte gegen .LastValue() auf Änderung prüfen damit nicht übermäßig geloggt wird.

Option E fiel mir auch noch ein.
Da der Selbstbau-Sensor vermutlich BidCos spricht könnte man das Logging auch direkt über einen Eintrag im CUxD-Setup machen. CUxD lauscht ja am RPC und braucht zum Loggen von HM kein Programm.

[rentier-s]

Wobei man dann im "Logger-Script" die Datenpunkte einzeln abrufen muss da $src$ ja die Virt. Taste ist. Und ggf. die Werte gegen .LastValue() auf Änderung prüfen damit nicht übermäßig geloggt wird.

Das stimmt. Wobei $src$ und LastValue() auch nicht wirklich verlässlich sind, wenn man das Skript verzögert ausführt. Es könnte zum Beispiel zuerst durch eine Änderung eines Datenpunkts und innerhalb der einen Sekunde durch Aktualisierung (mit unverändertem Wert) eines anderen getriggert werden, dann würde das eigentlich gewünschte Ereignis verschluckt.

Ich hole mir dazu im Skript die im Programm als Trigger verwendeten Datenpunkte und prüfe, ob der Timestamp nicht älter als 2 Sekunden ist. Dann weiß ich den oder die Auslöser und kann ggf. drauf reagieren.

Langer Rede kurzer Sinn: in dem Fall hier würde ich die Verzögerung unbedingt raus nehmen, da anzunehmen ist, dass die drei Werte innerhalb einer Sekunde übertragen werden, und somit nur der dritte übrig bleibt.

Unabhängig davon verstehe ich den Ablauf des Skripts irgendwie nicht, vielleicht muss auch meine Brille nur mal wieder geputzt werden.
Wenn Value() gleich String "true" oder gleich String "false", dann Value().ToInteger*30 loggen.

[Baxxy]

Soweit ich mich erinnere kann CUxD-Highcharts kein Bool darstellen, darum wird in Integer gewandelt.
Die 30 sind eher Willkür, ich hatte damals "0" für falsch und "10" für true.
Bin aber lange weg von Highcharts.

[uwe111]

Soweit ich mich erinnere kann CUxD-Highcharts kein Bool darstellen, darum wird in Integer gewandelt.

Ab CUxD Version 2.9 werden Boolean Werte (True/False) automatisch als (1/0) im CUxD Devicelog geloggt. (s. CUxD Changelog)
Somit sollte auch eine Darstellung in CUxD-HighCharts möglich sein.

Viele Grüße

Uwe

[rentier-s]

Soweit ich mich erinnere kann CUxD-Highcharts kein Bool darstellen, darum wird in Integer gewandelt.

Geht zwar jetzt immer weiter weg vom Thema, aber es wird ja nicht auf Boolean geprüft, sondern String.

if (dp.Value() == "true" | dp.Value() == "false")

Hab's grad extra nochmal ausprobiert.

Code: Alles auswählen

var val = dom.GetObject("anwesend.Svenja").Value();
WriteLine(val);
if (val == "false") {
WriteLine("bin da");
}
if (val == false) {
WriteLine("bin immer noch da");
}

ergibt

Code: Alles auswählen

false
bin immer noch da

Hat HM Skript eigentlich überhaupt eine Typenprüfung wie === in C? Ansonsten müsste man wohl etwas in der Art dp.Value().ToString()=="true" machen