Programm löst nicht aus

[MichaelN]

Ich sehe es ähnlich wie Xel66, da die durchschnittliche und die minimal Helligkeit in kurzen zeitlichen Abstand hinter einander her laufen.

Das ständige raus und rein Fahren solltest du mit einer ordentlichen Hysterese abfangen.

Aber ja, erstmal ist es nicht einzusehen, warum das Programm nicht arbeitet.

[hmpatman]

Ich sehe es ähnlich wie Xel66, da die durchschnittliche und die minimal Helligkeit in kurzen zeitlichen Abstand hinter einander her laufen.

Siehe meinen ersten Verlauf, dort ist es anders. Aber egal.

Aber ja, erstmal ist es nicht einzusehen, warum das Programm nicht arbeitet.

Darauf würde ich mich gerne konzentrieren, weil mein Vertrauen in Trigger heftig erschüttert ist. Ich mach mir Sorgen, dass mein Trigger auf starken Wind (auch) nicht geht und das hätte unter Umständen teure Folgen.
Bin ein wenig ratlos wie ich herausfinden soll (außer duch sehr viel probieren) warum das nicht geht, weil ich im Blindflug unterwegs bin. Debuggen ist ziemlich schwierig.

Grüße,
Patrick

[Black]

Es gibt Möglichkeiten zu debuggen:

ich teste auch jedes Programm auf die Kombinationen aller Trigger und die richtige Auslösung. DU kannst natürlich zum Testen für Starken Wind die Wetterstation in den Abgasstrahl einer Strahlturbine hängen, ok, eventuell funktional, aber praktisch vllt bischen Shice, alternativ der Rega das Event: STarker WInd unterschieben und dann gucken:
reagiert das Programm
reagiert das Programm richtig.

Das Unterschieben von Events sieht die WebUI standartmäßig allerdings nicht vor
dies geht:
1. mit Scripten (hier nach Rega Event suchen) dokumentiert Hier Kapitel 5.1 Seite 26
2. mit entsprechenden Programmen (beispielsweise dem SDV) beschrieben hier: Tutorial Programme testen / debuggen mit dem SDV

Black

[MichaelN]

Also mit HmIP-SLO und folgendem Programm habe ich getestet:

Hier das Diagramm dazu:

Ereignisse:

ALso prinzipiell funktioniert es wie erwartet. ABER: man sieht mehrfach, das das Programm kurz nacheinander getriggert wurde (um 11:38 und 11:46).
Ob das dann immer zum gewünschten Ergebniss führt kommt dann aufs Timing an. I

Ich würde getrennte Programme anlegen, in dem es immer nur einen Trigger für das gleiche Gerät gibt.

[Xel66]

Nur zur Erklärung, aber grundsätzlich sehe ich nicht, warum ich sowas wie mein Programm nicht machen "darf".

Wenn beide Datenpunkte vom gleichen Sensor kommen, werden auch beide bei der zyklischen Datenübermittlung zum gleichen Zeitpunkt gesetzt. Mehrere Werte als Triggers (eines Sensors) scheint die CCU innerhalb eines Programms nicht zu mögen (eine Trigger-, eine Prüfbedingung aber schon). Ob die Schwellwerte nun unterschiedlich überschritten werden, ist völlig unabhängig davon. Das Diagramm ist dabei nicht hilfreich, weil es die Aktualisierungszeitpunkte nicht auflöst. Vor ewigen Zeiten hatten wir das schon mal im Zusammenhang mit mehreren Werten einer Wetterstation. Aber wenn Du meinst, dass es nicht daran liegt?! OK, nicht mein Problem.

Ich arbeite in solchen Fällen, in denen eine Hysterese nicht möglich oder zielführend ist, mit Zeitsperren. Nach einem Reinfahrbefehl ist das Rausfahren für eine gewisse Zeit gesperrt (in meinem Fall wende ich das in der Steuerung für die (De)Aktivierung der Heizung an "warmen" Tagen während der Heizperiode an). Auch der Initialbefehl muss bei mir über zwei Sendezyklen anstehen (erstmalige Aktion verzögert um 7 Minuten), damit nicht ein kurzfristiges einmaliges Anstehen des Schwellwertes die Aktion auslöst. Zum Sperren nutze ich CUxD-Timer (kann man aber auch mit einer temporär gesetzten Systemvariable machen).

Gruß Xel66

[hmpatman]

ALso prinzipiell funktioniert es wie erwartet. ABER: man sieht mehrfach, das das Programm kurz nacheinander getriggert wurde (um 11:38 und 11:46).
Ob das dann immer zum gewünschten Ergebniss führt kommt dann aufs Timing an. I

Ich würde getrennte Programme anlegen, in dem es immer nur einen Trigger für das gleiche Gerät gibt.

Danke für die Versuche! Ich hab bei mir mal den "average" Wert durch "highest" ersetzt und siehe da es triggert. Dürfte also tatsächlich von irgendeinem Timing abhängen, obwohl die Werte ja an sich immer zum gleichen Logik-Ergebnis führen müssten. So wie ich das sehe, dürfte bei es aber noch immer einen Unterschied zwischen deinem Versuch und meinem Programm geben, weil meines auf einen Wert überhaupt nicht triggert, oder hab ich was übersehen?

Wie auch immer, ich werde mein Programm mal auf "aktualisieren" vom einen Wert und "prüfen" beim anderen umstellen. Wenn ich zwei Programme mache, besteht die Gefahr, dass ich die Werte nicht bei beiden konsistent habe (ich kenne mich ...). Das sollte das Problem umschiffen. Außerdem schau ich mir alle anderen Programme und deren Trigger durch. Wer weiß ... notfalls gibt's noch die Option die Programme auf ein System extern zur CCU zu migrieren und nur mehr zeitkritische Dinge (Lichtsteuerung) zu belassen.

Danke auch @Black für die Hinweise zum Testen, das beschleunigt einige Versuche!

Grüße,
Patrick

[Baxxy]

Ich habe nochmal ein (auf das Thema bezogenes) Testprogramm aufgesetzt.
Es sollen (bei Aktualisierung) IST/SOLL/HUM von einem HmIP-STHD per Logger (CUxD-SYSLOG) ins Systemlog geschrieben werden.

Das erste Script ist der Logger:

Code: Alles auswählen

object dp = dom.GetObject("$src$");
if (dp) {
dom.GetObject("CUxD.CUX2801001:1.SYSLOG").State((dom.GetObject((dp.Channel()))).Address() #"."# dp.HssType() #";"#dp.Value());
}

Das zweite Script nur ein Separator für die Übersichtlichkeit:

Code: Alles auswählen

dom.GetObject("CUxD.CUX2801001:1.SYSLOG").State("000E9A498E8514:1.---------------------------------");

Zusätzlich ist Kanal:1 des HmIP-STHD protokolliert.

Die meiste Zeit sieht das Protokoll korrekt so aus:

Code: Alles auswählen

Jun 28 01:41:25 Test-CCU-RMatic-Pi4B-V2 daemon.info cuxd[833]: CUX2801001:1 000E9A498E8514:1.SET_POINT_TEMPERATURE;17.000000
Jun 28 01:41:25 Test-CCU-RMatic-Pi4B-V2 daemon.info cuxd[833]: CUX2801001:1 000E9A498E8514:1.HUMIDITY;49
Jun 28 01:41:25 Test-CCU-RMatic-Pi4B-V2 daemon.info cuxd[833]: CUX2801001:1 000E9A498E8514:1.ACTUAL_TEMPERATURE;25.300000
Jun 28 01:41:26 Test-CCU-RMatic-Pi4B-V2 daemon.info cuxd[833]: CUX2801001:1 000E9A498E8514:1.---------------------------------

Aber es gibt auch "Aussetzer" wo Einträge fehlen.
Logfile:

Code: Alles auswählen

Jun 27 18:45:31 Test-CCU-RMatic-Pi4B-V2 daemon.info cuxd[833]: CUX2801001:1 000E9A498E8514:1.HUMIDITY;49
Jun 27 18:45:31 Test-CCU-RMatic-Pi4B-V2 daemon.info cuxd[833]: CUX2801001:1 000E9A498E8514:1.ACTUAL_TEMPERATURE;26.500000
Jun 27 18:45:32 Test-CCU-RMatic-Pi4B-V2 daemon.info cuxd[833]: CUX2801001:1 000E9A498E8514:1.---------------------------------

Systemprotokoll:

Code: Alles auswählen

Solltemperatur 21.00°C, Boost-Dauer 0, Urlaubsmodus nicht aktiv, Rel. Luftfeuchte 49, unbekannte Meldung (QUICK_VETO_TIME) 0, Frostschutz nicht aktiv, Modus für Solltemperatur 0, Wert Ist-Temperatur: Normal, Solltemperatur nicht geändert, Aktives Profil 1, Fenster geschlossen, Wert Rel. Luftfeuchte: Normal, Kühlen, Ist-Temperatur 26.50, Boost-Funktion

Logfile:

Code: Alles auswählen

Jun 28 03:25:30 Test-CCU-RMatic-Pi4B-V2 daemon.info cuxd[833]: CUX2801001:1 000E9A498E8514:1.SET_POINT_TEMPERATURE;17.000000
Jun 28 03:25:30 Test-CCU-RMatic-Pi4B-V2 daemon.info cuxd[833]: CUX2801001:1 000E9A498E8514:1.ACTUAL_TEMPERATURE;24.800000
Jun 28 03:25:31 Test-CCU-RMatic-Pi4B-V2 daemon.info cuxd[833]: CUX2801001:1 000E9A498E8514:1.---------------------------------

Systemprotokoll:

Code: Alles auswählen

Solltemperatur 17.00°C, Boost-Dauer 0, Urlaubsmodus nicht aktiv, Rel. Luftfeuchte 51, unbekannte Meldung (QUICK_VETO_TIME) 0, Frostschutz nicht aktiv, Modus für Solltemperatur 0, Wert Ist-Temperatur: Normal, Solltemperatur nicht geändert, Aktives Profil 1, Fenster geschlossen, Wert Rel. Luftfeuchte: Normal, Kühlen, Ist-Temperatur 24.80, Boost-Funktion

Logfile:

Code: Alles auswählen

Jun 28 05:09:46 Test-CCU-RMatic-Pi4B-V2 daemon.info cuxd[833]: CUX2801001:1 000E9A498E8514:1.SET_POINT_TEMPERATURE;17.000000
Jun 28 05:09:46 Test-CCU-RMatic-Pi4B-V2 daemon.info cuxd[833]: CUX2801001:1 000E9A498E8514:1.ACTUAL_TEMPERATURE;24.500000
Jun 28 05:09:47 Test-CCU-RMatic-Pi4B-V2 daemon.info cuxd[833]: CUX2801001:1 000E9A498E8514:1.---------------------------------

Systemprotokoll:

Code: Alles auswählen

Solltemperatur 17.00°C, Boost-Dauer 0, Urlaubsmodus nicht aktiv, Rel. Luftfeuchte 52, unbekannte Meldung (QUICK_VETO_TIME) 0, Frostschutz nicht aktiv, Modus für Solltemperatur 0, Wert Ist-Temperatur: Normal, Solltemperatur nicht geändert, Aktives Profil 1, Fenster geschlossen, Wert Rel. Luftfeuchte: Normal, Kühlen, Ist-Temperatur 24.50, Boost-Funktion

Logfile:

Code: Alles auswählen

Jun 28 10:22:02 Test-CCU-RMatic-Pi4B-V2 daemon.info cuxd[833]: CUX2801001:1 000E9A498E8514:1.SET_POINT_TEMPERATURE;17.000000
Jun 28 10:22:02 Test-CCU-RMatic-Pi4B-V2 daemon.info cuxd[833]: CUX2801001:1 000E9A498E8514:1.ACTUAL_TEMPERATURE;25.600000
Jun 28 10:22:03 Test-CCU-RMatic-Pi4B-V2 daemon.info cuxd[833]: CUX2801001:1 000E9A498E8514:1.---------------------------------

Systemprotokoll:

Code: Alles auswählen

Solltemperatur 17.00°C, Boost-Dauer 0, Urlaubsmodus nicht aktiv, Rel. Luftfeuchte 51, unbekannte Meldung (QUICK_VETO_TIME) 0, Frostschutz nicht aktiv, Modus für Solltemperatur 0, Wert Ist-Temperatur: Normal, Solltemperatur nicht geändert, Aktives Profil 1, Fenster geschlossen, Wert Rel. Luftfeuchte: Normal, Kühlen, Ist-Temperatur 25.60, Boost-Funktion

Man sieht hier schön das selbst "bei Aktualisierung" ab und zu ein Wert "verschluckt" wird.

Grüße
Baxxy

[MichaelN]

Und wenn Du 2 der 3 Trigger auf "prüfen" stellst, gibt es keine Aussetzer mehr?

[Baxxy]

Gute Frage.
Nur wie soll ich das testen?
"nur prüfen" wird ja nicht als Trigger behandelt und somit kann man das nicht über $src$ loggen.
Ich stell's aber testweise mal um, und gucke was bei rauskommt.

Grüße
Baxxy

[MichaelN]

Einfach alle 3 Datenpunkte ausgeben? Wenn die nicht mit dem Protokoll überein stimmen, wäre das ein Indiz.