CCU3 - unzuverlässige Programmausführung
Moderator: Co-Administratoren
CCU3 - unzuverlässige Programmausführung
Hallo liebes Forum,
seit einiger Zeit plagt mich die Unzuverlässigkeit bei der Ausführung von Programmen, primär geht es um 2 Programme für die Rollladensteuerung:
Automatische Steuerung bei Helligkeit Automatische Steuerung zu festgelegter Uhrzeit Leider ist es so, dass beide Programme nicht immer ausgeführt werden, wenn ich zb Abends dann das Programm deaktiviere und wieder aktiviere, dann läuft sofort alles los. Morgens genauso.
Ich habe schon einen nächtlichen Reboot der CCU eingebaut, das bringt aber leider auch keinen Erfolg.
Die Aktoren für die Rollladen sind Luftlinie 2m von der CCU entfernt und es gibt auch keine Meldungen über die fehlende Konnektivität oder ähnliches.
hat jemand einen Tipp / Idee wo ich noch ansetzen könnte?
Danke und schönen Sonntag!
seit einiger Zeit plagt mich die Unzuverlässigkeit bei der Ausführung von Programmen, primär geht es um 2 Programme für die Rollladensteuerung:
Automatische Steuerung bei Helligkeit Automatische Steuerung zu festgelegter Uhrzeit Leider ist es so, dass beide Programme nicht immer ausgeführt werden, wenn ich zb Abends dann das Programm deaktiviere und wieder aktiviere, dann läuft sofort alles los. Morgens genauso.
Ich habe schon einen nächtlichen Reboot der CCU eingebaut, das bringt aber leider auch keinen Erfolg.
Die Aktoren für die Rollladen sind Luftlinie 2m von der CCU entfernt und es gibt auch keine Meldungen über die fehlende Konnektivität oder ähnliches.
hat jemand einen Tipp / Idee wo ich noch ansetzen könnte?
Danke und schönen Sonntag!
- Henke
- Beiträge: 1524
- Registriert: 27.06.2022, 20:51
- System: CCU
- Hat sich bedankt: 141 Mal
- Danksagung erhalten: 306 Mal
Re: CCU3 - unzuverlässige Programmausführung
Verzögerungen rein setzen. Nicht sofort, sonder Verzögert um 1 Sekunde, 2 Sekunden, etc.
Auf Dauer waren mir die CCU Programme und Scripts zu buggy und daher bin ich komplett auf NodeRed umgestiegen.
Auf Dauer waren mir die CCU Programme und Scripts zu buggy und daher bin ich komplett auf NodeRed umgestiegen.
Re: CCU3 - unzuverlässige Programmausführung
Danke, hab ich mal gemacht.
NodeRed steht noch auf dem Fahrplan, aber bisher noch nicht zu gekommen es umzusetzen
-
- Beiträge: 12928
- Registriert: 16.01.2009, 18:48
- Wohnort: Steingaden
- Hat sich bedankt: 1604 Mal
- Danksagung erhalten: 222 Mal
Re: CCU3 - unzuverlässige Programmausführung
auf dauer sind solche programme immer buggy ( wie schon gesagt ) - ein fenster - ein program .. erspart eine menge ärger und die ccu ist auch nicht wirklich begeistert von solche "befehlsschlangen" ... was zum teil auch für größer logische verknüpfungen gilt ----- ( das ist aber meine meinung - deshalb sammelt auch hier die ccu nur daten , den rest macht iobroker. )
-------
!!! der download der handbüchern auf den seiten von eq3 und das lesen der tips und tricks kann das hm-leben sehr erleichtern - das nutzen der suche nach schlagworten ebenso !!!
wer schreibfehler findet darf sie behalten.
!!! der download der handbüchern auf den seiten von eq3 und das lesen der tips und tricks kann das hm-leben sehr erleichtern - das nutzen der suche nach schlagworten ebenso !!!
wer schreibfehler findet darf sie behalten.
-
- Beiträge: 3034
- Registriert: 28.01.2016, 18:06
- System: CCU
- Wohnort: Hürth
- Hat sich bedankt: 16 Mal
- Danksagung erhalten: 274 Mal
Re: CCU3 - unzuverlässige Programmausführung
Hi,
meine Erfahrung zeigt, dass es in der Regel an den Programmen selbst liegt, die die Regeln der CCU Logik nicht beachten.
Es gibt wohl vereinzelt mal kaputt editierte Programme, dass ist aber eher die Ausnahme.
Ich habe derzeit etwa 250 Zentralenprogramme, die teilweise durchaus deutlich komplexer sind und die funktionieren alle so, wie erwartet.
Unzuverlässig ist die CCU in meinen Augen daher bei der Programmausführung in keinster Weise.
Gruß
Gerti
meine Erfahrung zeigt, dass es in der Regel an den Programmen selbst liegt, die die Regeln der CCU Logik nicht beachten.
Es gibt wohl vereinzelt mal kaputt editierte Programme, dass ist aber eher die Ausnahme.
Ich habe derzeit etwa 250 Zentralenprogramme, die teilweise durchaus deutlich komplexer sind und die funktionieren alle so, wie erwartet.
Unzuverlässig ist die CCU in meinen Augen daher bei der Programmausführung in keinster Weise.
Gruß
Gerti
-
- Beiträge: 9678
- Registriert: 27.04.2020, 10:34
- System: CCU
- Hat sich bedankt: 700 Mal
- Danksagung erhalten: 1626 Mal
Re: CCU3 - unzuverlässige Programmausführung
Was sind das für Aktoren?
Ich würde sogar jeweils 5 Sekunden mehr nehmen.
Aber wenn es keine komm Störungen gibt, dann sollten die Rollos auch laufen.
Laufen die Programme überhaupt? Debugging Tips siehe Signatur.
Ich würde sogar jeweils 5 Sekunden mehr nehmen.
Aber wenn es keine komm Störungen gibt, dann sollten die Rollos auch laufen.
Laufen die Programme überhaupt? Debugging Tips siehe Signatur.
Natürlich nicht. Das ist reiner Aktionismus.
Klar, durch das aktivieren wird zwangsweise das Programm ausgeführt.
Las dich nicht verunsichern. Bei mir läuft eine wesentlich komplexere rollo Steuerung seit über 2 Jahren. Mit Node Red erhöhst du nur den Komplexitätsgrad.
LG, Michael.
Wenn du eine App zur Bedienung brauchst, dann hast du kein Smarthome.
Wettervorhersage über AccuWeather oder OpenWeatherMap+++ Rollladensteuerung 2.0 +++ JSON-API-Ausgaben auswerten +++ undokumentierte Skript-Befehle und Debugging-Tipps +++
Wenn du eine App zur Bedienung brauchst, dann hast du kein Smarthome.
Wettervorhersage über AccuWeather oder OpenWeatherMap+++ Rollladensteuerung 2.0 +++ JSON-API-Ausgaben auswerten +++ undokumentierte Skript-Befehle und Debugging-Tipps +++
-
- Beiträge: 14164
- Registriert: 08.05.2013, 23:33
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Nordwürttemberg
- Hat sich bedankt: 585 Mal
- Danksagung erhalten: 1500 Mal
Re: CCU3 - unzuverlässige Programmausführung
Buggy wird es nur, wenn der Anwender die dokumentierte Art und Weise der Programmtriggerung und -abarbeitung ignoriert. Ansonsten kann man mit der Logik unter Beachtung der "Eigenheiten des Systems" auch komplexeste Steuerungen abbilden. Voraussetzung ist allerdings der Wille, sich das mal einzuverleiben. Und ich behaupte mal, für die meisten der Automatisierungswünsche sind solche aufgeblasenen Lösungen wie eine weitere Logikebene und komplexe Installationen unnötig. Aber jeder wie er will. Bei mir laufen über 300 Programme, die alle das tun, was beabsichtigt ist.
BTT: Funk ist ein shares medium und gerade Rollladenaktoren sind öfter mal sehr geschwätzig (übermitteln ihre aktuelle Behanghöhe an die CCU bevor sie loslaufen etc.). Da ist ein gleichzeitiges Ansteuern eher kontraproduktiv, da hier sich die Befehle und Quittierungen durch die Aktoren gegenseitig überlagern können. Hier hilft eben nur die mehrmals angeführte zeitliche Entzerrung. Wobei zu beachten ist, dass sich die Verzögerungen immer auf den Auslösezeitpunkt beziehen. Also 1s, 2s, 3s etc. verzögern. Dieses Handling sollten IP-Aktoren wegen ihres listen before talk eigentlich selbst auf die Reihe bekommen. Aber warum soll man das System nicht dabei durch die Staffelung unterstützen. Die zweite Bedingung zum Runterfahren um 22:00 Uhr mit einer Bedingung "größer 20 Lux" finde ich etwas merkwürdig, wenn vorher schon bei kleiner 15 Lux ausgelöst werden soll. Ich würde dort nach meiner Logik "kleiner..." definieren, wenn ich spätestens 22:00 Uhr runterfahren will. Ansonsten sehe ich in den Programmen nichts, was beim Triggern Probleme bereiten könnte. Wobei ich nicht die Helligkeit als Trigger/Bedingung bewerten kann, da ich die örtlichen Gegebenheiten nicht kenne.
Gruß Xel66
BTT: Funk ist ein shares medium und gerade Rollladenaktoren sind öfter mal sehr geschwätzig (übermitteln ihre aktuelle Behanghöhe an die CCU bevor sie loslaufen etc.). Da ist ein gleichzeitiges Ansteuern eher kontraproduktiv, da hier sich die Befehle und Quittierungen durch die Aktoren gegenseitig überlagern können. Hier hilft eben nur die mehrmals angeführte zeitliche Entzerrung. Wobei zu beachten ist, dass sich die Verzögerungen immer auf den Auslösezeitpunkt beziehen. Also 1s, 2s, 3s etc. verzögern. Dieses Handling sollten IP-Aktoren wegen ihres listen before talk eigentlich selbst auf die Reihe bekommen. Aber warum soll man das System nicht dabei durch die Staffelung unterstützen. Die zweite Bedingung zum Runterfahren um 22:00 Uhr mit einer Bedingung "größer 20 Lux" finde ich etwas merkwürdig, wenn vorher schon bei kleiner 15 Lux ausgelöst werden soll. Ich würde dort nach meiner Logik "kleiner..." definieren, wenn ich spätestens 22:00 Uhr runterfahren will. Ansonsten sehe ich in den Programmen nichts, was beim Triggern Probleme bereiten könnte. Wobei ich nicht die Helligkeit als Trigger/Bedingung bewerten kann, da ich die örtlichen Gegebenheiten nicht kenne.
Gruß Xel66
-------------------------------------------------------------------------------------------
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch
Re: CCU3 - unzuverlässige Programmausführung
Danke an alle fürs Feedback, ich werde die Verzögerungen mal ausprobieren
Re: CCU3 - unzuverlässige Programmausführung
Wenn es im Sommer um 22:00 Uhr noch hell ist soll automatisch heruntergefahren werden, man könnte natürlich den Helligkeitsfilter komplett entfernen aber ist historisch gewachsenXel66 hat geschrieben: ↑29.01.2023, 10:29Die zweite Bedingung zum Runterfahren um 22:00 Uhr mit einer Bedingung "größer 20 Lux" finde ich etwas merkwürdig, wenn vorher schon bei kleiner 15 Lux ausgelöst werden soll. Ich würde dort nach meiner Logik "kleiner..." definieren, wenn ich spätestens 22:00 Uhr runterfahren will.
Wobei ich mich nun erinnere: wenn man zb im Winter ein Rollo oben lässt und es ist 22 Uhr würde das automatisch herunterfahren, deshalb der Filter mit Prüfung auf die Helligkeit
-
- Beiträge: 3621
- Registriert: 14.07.2019, 20:49
- System: CCU
- Hat sich bedankt: 847 Mal
- Danksagung erhalten: 542 Mal
Re: CCU3 - unzuverlässige Programmausführung
Du fährst runter, wenn es entweder zwischen 15 und 23 Uhr dunkel ist oder um 22 Uhr hell??! Für mich widerspricht sich das erstmal.
Wenn ich das richtig verstehe, dann willst Du runterfahren, wenn es nachmittags bis Abends dunkel wird und auf jeden Fall um 22 Uhr?? Das hast Du so aber nicht programmiert!
Wenn Dein Lichtsensor um 22 Uhr, warum auch immer, <20 Lux und vor 23 Uhr noch >15 Lux meldet, fährt nix runter.
Es wäre jetzt mal wichtig zu wissen, wie hoch der Lux-Wert ist, wenn die Aktoren nicht fahren, es aber nach Deiner Meinung müßten. Meine These: der Sensor meldet >15 (bis 23 Uhr) bzw. <20 Lux (um 22 Uhr).
Mich würden auch mal die genauen Zeitmoduleinstellungen für 15 bis 23 Uhr interessieren (Screenshot).
Die Programme funktionieren (bei groben Fehlern) entweder gar nicht oder zuverlässig. Wenn eines nicht das macht, was es soll, dann liegt es meistens an den Eingangsbedingungen und / oder der Programmierung, die in Kombination zu anderen Ergebnissen führt, als man sich das vorgestellt hat. Dein Programm ist abhängig von zwei Helligkeitsschwellen und die aktuellen Lichtwerte könnten anders sein, als Du denkst.
Formuliere mal bitte, was genau Du erreichen willst (nicht beschreiben, was Du programmiert hast)! Dann wird (hoffentlich) auch klarer, wie die Bedingung aussehen muss.