HomeMatic-Forum / FHZ-Forum

Hi @ all!

Bin nun auch wieder schlauer geworden nachdem ich mich nun schon Wochenlang mit einem Programm herumquäle und schon lange die Zeitsteuerung in Verdacht hatte bin ich nun dem Problem auf die schliche gekommen.
Und zwar habe ich für meine Wärmepumpe schon länger ein Programm um sie zu deaktivieren! (Spart die Umwälzpumpenenergie)
Das hat auch immer gut funktioniert.
Ich wollte dann nur zu den Unterschiedlichen Jahreszeiten unterschiedliche Aktionen haben.
Dazu habe ich mir eine Systemvariable vom Typ Logik angelegt mit Sommer und Winter. Und diese wurde mit einen Zeitprogramm im April und im September geändert.
Und hier hat sich mein grober Fehler eingeschlichen.
Das Programm hat denke ich jetzt immer im ersten absatz gewartet bis "Winter" eintrifft was aber erst am 20 Septermber erfüllt ist und hat alles nachfolgende nicht ausgeführt !!

Jetzt habe ich die Systemvariable vom Typ Logik auf Werteliste geändert und siehe da es funktioniert!
Vielleicht kann ich mit meiner Erkenntiss hier einigen helfen.

Die einzige frage die sich mir nur stellt.

It's a Bug or it's a feature????

Also: Systemvariable Typ Logik muss erfüllt sein damit ein Programm weiterarbeitet?
Systemvariable Typ Werteliste muss nicht erfüllt sein damit ein Programm weiterarbeitet?

Oder sehe ich das falsch?

Hallo zusammen,

ich habe gerade ein recht merkwüdiges Verhalten der "nur prüfen" Funktion festgestellt, die das Programm trotzdem zu triggern scheint. Aber vielleicht habe ich einen Denkfehler. Es geht um die Steuerung einer Schaltsteckdose, welche eine Zisternenpumpe einschaltet bei Wasseranforderung, aber nur wenn genügend Wasser in der Zisterne vorhanden ist.

Die Logik ist wie folgt:
Sobald die Variable Gardena einschaltet (getriggert vom manuellen Einschalten einer anderen Schaltsteckdose wo die Waschmaschine und Trockner dran hängen):
bekomme ich regelmäßig alle 3 Minuten eine Pushnachricht. D.h. der erste Zweig wird offensichtlich ausgeführt. Da die Variable Waschen konstant bleibt (per logging geprüft) und auch die anderen 3 Variablen in dem Logikblock darunter ihren Zustand nicht ändern (per Logging geprüft und auch nicht erwartet), bleibt nur die Alarmvariable als Auslöser. Diese ändert sich nicht und steht auch auf "nur prüfen" , sie loggt aber regelmäßig alle 3 Minuten den selben Zustand:
Nun muss man wissen, dass ich mir den Wasserstand von einem Füllstandsmesser der Zisterne, welcher einen 0-5V Analogausgang hat, mit folgendem "Trick" über einen Temperatursensor hole

https://www.stall.biz/project/einfache- ... logeingang

Dieser sendet ca. alle 3 Minuten einen neuen Wert, welcher dann mit 2 Macros (genau wie im Link) in einen Wasserstand umgerechnet werden. Bei jedem Empfang wird die Alarm-Variable dann genäß des des Wasserstandes (mit Hysterese) aktualisiert:
Da die analogen Werte etwas schwanken, wird faktisch mit jedem Messwert ein neuer Wasserstand berechnet und damit auch jedes mal neu die Alarm-Variable auf "genug Wasser" gesetzt. Das erklärt das Logging. Die Alarmvariable ändert sich inhaltlich nicht, aber offenbar triggert das irgendwie den ersten Zweig im obigen Programm, jedesmal wenn die Variable neu geschrieben wird, obwohl sie auf "nur prüfen" steht. Das zeigt zumindest das Log:
Sehr komisch. Auf jeden Fall, wenn ich die Abfrage der Alarmvariable auf "bei Änderung" stelle
dann hören die Benachrichtigungen sofort auf und es bleibt nur das Loggen der Alarmvariable. Irgendwie komisch.
Ich dachte, dass "nur prüfen" nie aktiv das Programm triggern kann, egal was mit der "nur prüfen" Variable passiert. Hier tut es das aber offensichtlich. Hat das schon mal jemand in ähnlicher Weise festgestellt?Oder habe ich da irgend etwas überlesen oder falsch verstanden?
Alle beteiligten Variablen sind übrigens vom Type Logikwert.

Man könnte jetzt vermutlich die Alarmvariable in Abhängigkeit ihres eigenen Zustandes nur dann schreiben wenn sich wirklich etwas ändert, um das Phänomen zu unterdrücken, aber komisch ist es schon und ein etwas komische gefühl stellt sich ein, was denn sonst noch so an anderer "nur prüfen" Logik ungewollt reagieren könnte......

Gruß
Thomas.

Hallo Thomas,
Mir sind mehrere Sachen aufgefallen.
Im oberen Programm hast Du im oberen Bereich zwar ein nur prüfen, im unteren Abschnitt aber ein auf Änderung der Alarmvariablen. Daduch kann also sehr wohl der obere Teil bei Änderung der Variablen ausgeführt werden. Ist Dir die Abarbeitungslogik nicht klar?
Eine Änderung selbst kann ich als Ursache allerdings nicht wirklich erkennen.
Ist die Alarmvariable denn wirklich vom Typ Logik oder ist eine der Variablen evtl. vom Typ Alarm?
Hast Du nach Erstellung der Programme evtl. noch irgendwas an den Variablendefinitionen geändert?
Danb solltest Du die Programme löschen und nochmal neu anlegen. Dies könnte auch die Lösung für ansonsten unerklärliches Verhalten sein. Schon gemacht?
Im Niedigwasser-Programm triggerst Du unten übrigens korrekt auf Änderung, oben jedoch auf Aktualisierung. Das sollte ebenfalls auf Änderung. Oder aus welchem Grund verwendest Du dort Aktualisierung?

Gruß Sammy

Hallo Sammy,

Danke für die schnelle Antwort. Da hatte ich Tomaten auf den Augen. Vollkommen richtig. Eine Variable muss im ganzen Programm konsequent auf nur prüfen stehen, ansonsten würde die Änderung das Programm vom oben triggern, egal wo die Variable auf Änderung geprüft wird. Ich habe jetzt das ganze System mal neu gebootet. Seit dem scheint der Effekt verschwunden zu sein und die Variable loggt auch nicht mehr alle 3 Minuten. Also mal wieder das gute alte "jeder Boot tut gut" . Im zweiten Programm hast Du natürlich auch Recht, muss auf Änderung stehen. Da hatte ich erst eine andere Logik und dann beim Umbau vergessen es zu ändern.

Viele Grüße
Thomas.

Ich habe da auch noch ein etwas allgemeineres Thema...

Hardware: CCU3, hauptsächlich homemtic ip wired Komponenten + einige Funk

Ich habe nun ein gutes halbes Jahr an meiner CCU gearbeitet und natürlich immer neue Funktionen etc. integriert.
Nachdem mir die Übersicht abhanden gekommen ist habe ich mir die Mühe gemacht und meine Programme umbenannt und dabei folgende Ordnung verwendet:
z.B.
000 - Systemprogramme

010 - Anwesenheit
020 - Servicemeldungen (push)
030 - Historian (offline)

200 - Beschattung

211 - Beschattungsprogram Nr.1 Schlafzimmer
212 - Beschattungsprogram Nr.2 Schlafzimmer
221 - Beschattungsprogramm Nr.1 Bad
231 - Beschattungsprogramm Nr.1 Kinderzimmer
241 - Beschattungsprogramm Nr.1 Wohnzimmer
251 - Beschattungsprogramm Nr.1 Küche

konkretes Benennungsbeispiel: 221_1R2 - Bad Lüften

Soo...seit diesem Aufwand habe ich ... nennen wir es "Auffälligkeiten"...

Programme die funktioniert haben funktionieren teilweise nicht mehr.
Falls mir das aufgefallen ist habe ich zum Beispiel eine Systemvariable aus dem Programm gelöscht und anschließend wieder eingefügt oder das Programm einmal per Hand ausgeführt.

Zusätzlich habe ich eine Frage zum Tipp ein Programm zu löschen und dann nochmal neu zu erstellen:
Das Programm bekommt nach der Neuerstellung von mir den identischen Namen - ist das ein Problem?
Ich habe zum Beispiel festgestellt das dieses Programm dann nicht beim ersten Speichern ausgeführt wird, zumindest laut "Status und Bedienung".

Da mein Vertrauen in das System rückläufig ist würde mir eine schnelle Antwort sehr helfen ich hoffe ich habe alles ausreichend erklärt...

Danke vorab und Gruß, Philipp

Da war mal was mit Zahlen am Anfang von Objektnamen. Das Stand sogar mal offiziell in irgendeiner Anleitung.
Ob das etwa immer noch gilt, kann ich aber nicht sagen.

Massenhaftes Arbeiten an den Strukturen sollte immer mal wieder auch manifestiert werden.
Soll heißen: dabei zwischendurch mal von der Klickibunti abmelden um die Regadom zu speichern, kann nicht schaden.

Alchy

Hallo,

Ich habe beim EQ3 Support nachgefragt...
„ Zahlen führen in Programmnamen zu keinen uns bekannten Problemen. Wichtig hierbei ist nur, dass Sie keine Programme als Vorlage verwenden. Hierbei kann es zu unerwünschten Verhalten der Programme kommen.“

Das mit den Vorlagen habe ich dann nochmal nachgefragt ob damit speichern als neues Programm gemeint ist...
„ Die Funktion "Einstellung als neues Programm speiechern" kann zu Fehlern in der ID Vergabe führen. Daher benutzen Sie dies bitte nicht.“

Das war mir nicht bewusst! Und ich finde diese Funktion eigentlich ziemlich hilfreich

Gruß, Philipp

Pihero hat geschrieben: ↑

05.06.2020, 10:04

Das war mir nicht bewusst! Und ich finde diese Funktion eigentlich ziemlich hilfreich

Meine Vermutung ist, dass ein sauberer Umgang mit der bekanntlich "empfindlichen" WebUI das A und O bei solchen Geschichten ist.
Supporter wissen natürlich, dass dies von Usern nur selten beachtet wird und raten deshalb pauschal davon ab.
Auch hier im Forum wird seit Jahren ständig gepredigt diese Funktion besser nicht zu nutzen, vermutlich aus den gleichen Gründen.

Ich selbst nutze diese Funktion seit vielen Jahren oft, gerne und immer wieder, ohne dass ich je Probleme festgestellt hätte.

Pihero hat geschrieben: ↑

05.06.2020, 10:04

„ Die Funktion "Einstellung als neues Programm speiechern" kann zu Fehlern in der ID Vergabe führen. Daher benutzen Sie dies bitte nicht.“

Ich denke mal, eQ-3 meint solche Konstellationen?

blackhole hat geschrieben: ↑

05.06.2020, 10:39

Meine Vermutung ist, dass ein sauberer Umgang mit der bekanntlich "empfindlichen" WebUI das A und O bei solchen Geschichten ist.

Der Begriff bereitet mir im Zusammenhang mit der CCU Bauchschmerzen.
Damit ist eher nicht das Einhalten von allgemeingültigen Programmierregeln gemeint (daran hält sich die CCU ja ohnehin nicht), sondern doch eher, dass man sich so verhalten soll, dass man all die Störanfälligkeiten und Unzulänglichkeiten der Firmware umschifft.
Dazu muß man aber schon mal weit eingedrungen sein und alle bösen Klippen auch kennen.

Natürlich ist es paradox, wenn es nach wie vor die Kopierfunktion gibt (die wichtig ist!) und der Hersteller selbst von der Nutzung wegen Fehleranfälligkeit abrät Was ist mit Bug-Fixing?