Fehlende Datenpunkte mit CUxD-Highcharts

[Bembi]

Was mir aufgefallen ist, dass dies bei Sensoren passiert, welche Datenpunkte gleichzeitig senden.

Du benutzt $src$ in Deinem Script und schreibst den Datenpunkt mittels $src$ wieder weg. Folglich schreibst Du nur den Wert weg, welcher als Trigger das Script ausgelöst.

Ich habe das so gemacht, dass ich aus der $src$ Variable das Gerät heraus filtere und anschließend alle interessanten Werte nochmals auslese und mit LOGIT wegschreibe.

[forstner-m]

Kannst du vielleicht ein Beispiel hier einstellen. Danke!

[Bembi]

Kannst du vielleicht ein Beispiel hier einstellen. Danke!

Code: Alles auswählen

!* 14.05.2024 ***** TH Status Write BiCos ************************             

var source;
var channel;
var logch;

real HAct;
real TAct;

string chnName;
string dstName;
string strRes;

source = dom.GetObject("$src$");

   channel = dom.GetObject(source.Channel());
   chnName = channel.Name().Substr(3,4);
   dstName = "TM " # chnName;

   TAct = channel.DPByHssDP("TEMPERATURE").Value();
   HAct = channel.DPByHssDP("HUMIDITY").Value();

   dom.GetObject(dstName # " Temp").State(TAct);
   dom.GetObject(dstName # " Humi").State(HAct);


   dstName = "CUX TM " # chnName;	

   logch = dom.GetObject(dstName # " Temp");	
   strRes = dstName # " Temp;" # TAct.ToString(1);
   logch.DPByHssDP("LOGIT").State(strRes);

   strRes = dstName # " Humi;" # HAct.ToString(1);
   logch.DPByHssDP("LOGIT").State(strRes);

[forstner-m]

Hallo Bembi,

mit deinem Programm kann man Highcharts füttern. Vielen Dank!

Mein Programm mit der Zeitverzögerung läuft auch. Warum man aber eine Zeitverzögerung braucht, ist mir unklar.

Schöne Grüße
Michael

[Bembi]

Warum man aber eine Zeitverzögerung braucht, ist mir unklar.

Na wenn in einem Datenpaket zwei Werte kommen, ist nur einer dieser beiden Werte der Trigger. Und Dein Script nimmt den Trigger und schreibt diesen Wert weg, der zweite Wert geht verloren.

Mit der Zeitverzögerung hast Du zwei Trigger. Dein Programm schreibt also für jeden Trigger den auslösenden Wert weg.

[Baxxy]

Na wenn in einem Datenpaket zwei Werte kommen, ist nur einer dieser beiden Werte der Trigger. Und Dein Script nimmt den Trigger und schreibt diesen Wert weg, der zweite Wert geht verloren.

Die These hatte ich ja auch schon aufgestellt.
Die hinkt aber etwas denn nach meinen Tests wird korrekterweise 2x getriggert und jeweils beide Trigger (Temp/Hum) entsprechen dann $src$ und werden hier auf dem Testsystem bisher "Aussetzerfrei" ins SYSLOG geloggt.

Ich konnte also weiterhin nicht bestimmen wer/wie/was/wo verschluckt.

[Bembi]

Die These hatte ich ja auch schon aufgestellt.
Die hinkt aber etwas denn nach meinen Tests wird korrekterweise 2x getriggert und jeweils beide Trigger (Temp/Hum) entsprechen dann $src$ und werden hier auf dem Testsystem bisher "Aussetzerfrei" ins SYSLOG geloggt.

Ich konnte also weiterhin nicht bestimmen wer/wie/was/wo verschluckt.

Also ich hatte meine Scripte nach meiner Erinnerung aus einem ähnlichen Grund eben so wie beschrieben umgebaut. Ist aber lange her. Und weil es funktionierte auch nicht mehr verändert. Deswegen habe ich auch nie weiter geforscht, ob das gerätespezifisch war.

Wenn allerdings 2 Mal nahezu zeitgleich getriggert wird, wäre noch die Frage offen, wie sich die Variable $src$ verhält. In Deinem Script wird sie zweimal benutzt. Es wäre demnach mal einen Test wert, die Variable $src$ erst einmal an eine Scriptvariable zu übergeben und dann mit der Scriptvariable weiterzuarbeiten. Und dann sehen, ob der Effekt immer noch auftritt.

Die Variable $src$ sollte nach meinem Gefühl Script spezifisch sein. Wenn die CCU die Variable aber global behandelt, könnte sie während des Ablaufs des Scripts quasi vom zweiten Trigger überschrieben werden.

Ich hab das nie geprüft, bei mir ist das eher eine Angewohnheit aus anderen Programmiersprachen, wo es explizit eine Variablenübergabe "by Value" oder "by Referenz" gibt, in andern Worten, ob ein Wert oder ein Pointer übergeben wird. Übergibt man die Variable aber sofort an eine Script-spezifische Variable, dann erzwingt man damit quasi eine Übergabe eines Wertes, und die CCU kann anschließend damit machen, was sie will.

[forstner-m]

Folgendes kann mit dem Thema was zu tun haben oder nicht:
Wenn man in einem Programm im Bereich Aktivität zwei Befehlen an CUxD schickt, wird nur einer ausgeführt. Sobald man bei einem Befehl eine Verzögerung einstellt, funktionieren beide. Bei den Befehlen handelt es sich um http-Kommandos an unterschiedliche Geräte. Daher war meine Vermutung, dass CUxD gleichzeitige Befehle nicht verarbeiten kann.

[Baxxy]

kann mit dem Thema was zu tun haben oder nicht

Das "Problem" ist ja das die Logikschicht der Zentrale über ihre Schnittstellen diese "Befehle" an CUxD übergibt.
Es kann also "bei der Sendung der Befehle" an CUxD hängen oder aber beim Empfang der Sendungen durch CUxD.

Erschwerend kommt hinzu das das Verhalten schwer zu reproduzieren ist (mal geht's, mal nicht).
Ich hab mir das mal auf meinem Testzettel notiert, mal gucken ob ich, wenn die Tage wieder kürzer werden, was rausfinde.

Und, sorry Uwe, aber das muss jetzt mal sein...
CUxD sollte eigentlich auch mit der Zeit gehen und diesen Umweg über WebUI-Programme (POSTIT/LOGIT) abschaffen und direkt als XMLRPC-Klient an den Schnittstellen lauschen.
Für den Anfang würde ja eine reiner "Listener" reichen der die Events einfach mitliest, parst und an den entsprechenden Stellen nutzt.
Ich glaube wir hatten "vor Jahren" schon mal drüber geredet.

[uwe111]

Und, sorry Uwe, aber das muss jetzt mal sein...
CUxD sollte eigentlich auch mit der Zeit gehen und diesen Umweg über WebUI-Programme (POSTIT/LOGIT) abschaffen und direkt als XMLRPC-Klient an den Schnittstellen lauschen.

Ja, da bin ich zeitlich leider noch nicht zu gekommen...

Viele Grüße

Uwe