Waschmaschinenüberwachung

[Hannnes]

Ich habe leider nur eine Steckdose (also nur eine Sicherung) für zwei Waschmaschinen und einen Trockner. Das das nicht ok ist, ist mir bewußt, aber so lange das nicht geändert ist, und jedes Gerät einzeln abgesichert ist, behelfe ich mir mit Homematic.
Und zwar einfach durch eine Schaltsteckdose mit Energiemessung.

Was passiert?
Beim Starten der ersten (alten) Waschmaschine (ohne Schlauheit) meldet das Haus (per Sprache/Telegram), dass eine WaMa startet. Nach 30min sagt es mir, dass ich jetzt die zweite WaMa starten kann (was ich meist durch Timern der zweiten erreiche). Warum mache ich das? Ganz einfach die Waschmaschinen heizen scheinbar nur zu Beginn. Egal bei welchem Waschprogramm. Ich habe mir alle Waschgänge lang und breit angesehen (Strom/Zeit-Diagramm).
Ist die (oder sind beide) Waschmaschine fertig bekomme ich wieder eine Meldung. Nach langer Idli-Zeit schaltet die Schaltsteckdose dann ganz ab. Was tatsächlich einiges sparen hilft. Der Standby ist hier nicht so klein.
Sollte ich (oder ein anderes Familienmitglied) was versemmeln und es wird zu viel Strom gezogen, bekommen wir wieder Meldung und die Stromzufuhr wird gekappt. Was ich nicht zeige ist, dass ich auch bei Feuchtemessung im Waschkeller die Stromzufuhr kappe.

Hier die Programme:

Der Trick, wie die Schaltzustände der Waschmaschine in eine Variable abgeleitet werden ist recht einfach. Man muss nur drauf kommen...
Es gibt eine Variable mit drei Werten: WaMaAus;WaMaAn;WaMaBeendet
Im Ruhezustand ist sie auf WaMaAus. Nur von diesem Zustand kann sie in den Zustand WaMaAn gehoben werden, und zwar durch einen deutlichen Stromanstieg. Von dort aus würde sie immer wieder in den Zustand WaMaBeendet fallen, wenn nicht rechtzeitig ein einerneutes Drehen der WaMa etwas mehr Strom ziehen würde. Man behält die Bälle quasi in der Luft, solange immer mal was bei der WaMa passiert. Ist das Waschprogramm zu Ende und der längste Zeitraum, in dem die WaMa eigentlich mal wieder was machen müsste fällt aus, fällt die Variable runter auf den Wert "WaMaBeendet".
Erst danach nach einiger Zeit, in der auch keinerlei Strom über dem Standby-Bedarf gezogen werden darf darf die Variable auf den Wert WaMaAus plumpsen. Und nur von dort kann ein neuer Zyklus wieder gestartet werden.
Ich musste, damit das sauber läuft die Schaltsteckdose etwas hysterischer einstellen:

[Ktoffel]

Hallo Hannnes, könntest du mir die Funktion und den Ursprung der Variable CCU-Status erklären. Danke dir schon mal ....

[robbi77]

Hallo Hannnes, könntest du mir die Funktion und den Ursprung der Variable CCU-Status erklären. Danke dir schon mal ....

Ich bin zwar nicht Hannes aber den Thread Tips&Tricks darfst du auch gern lesen.
viewtopic.php?f=31&t=26278#p229312

[Xel66]

... die Funktion und den Ursprung der Variable CCU-Status erklären.

Und noch was in Kurzform dazu. Dieser Workaround stammt aus dem Missverständnis und der definitiv falschen Behauptung, dass alle Programme beim Systemstart gestartet würde, und begründet sich darin, dass die Anwender die Funktionsweise und die (teils gewöhnungsbedürftige) Triggerung und Abarbeitung von Programmen nicht verinnerlicht haben. Mit dieser Variable lassen sich "unerwünschtes" oder unerwartetes Triggern von Programmen unterbinden. Leider hat sich das verselbständigt und der Workaround wird an allen möglichen und unmöglichen Stellen teils systemweit eingefügt und teilweise auch sinnloserweise (z.B. in durch Taster getriggerten Programmen, die definitv durch einen Systemstart nicht getriggert werden können).

Beim Systemstart findet eine Bedingungsprüfung der in Programmen angelegten Verknüpfungen statt und wenn solche eine Prüfung ein WAHR ergibt, wird das zugehörige DANN abgearbeitet (oder ein angelegtes SONST, wenn keine Bedingung ein WAHR ergibt). Das führt z.B. sinnvollerweise dazu, dass z.B. ein Rollladen, der laut Programmierung nachts geschlossen sein soll, bei einem Reboot nachts eben auch runterläuft. Das System stellt sich eigentlich so hin, wie es in der Programmierung durch den Nutzer vorgesehen ist. Leider überblicken aber viele Anwender ihr Tun nicht und wundern sich dann über solche unerwarteten Aktionen, obwohl sie selbst es so definiert haben. Infolgedessen werden dann Programme mit diesem Workaround totgelegt.

Gruß Xel66

[jp112sdl]

Das System stellt sich eigentlich so hin, wie es in der Programmierung durch den Nutzer vorgesehen ist. Leider überblicken aber viele Anwender ihr Tun nicht und wundern sich dann über solche unerwarteten Aktionen, obwohl sie selbst es so definiert haben.

Dann solltest du der Vollständigkeit halber in deiner allgemeinen Erklärung auch erwähnen, welche Werte "nicht abfragbare" Geräte in der Bedingungsprüfung beim Reboot haben.

Der normale Anwender geht nicht davon aus, dass beim Reboot z.B. die Temperatur-Werte von Temperatursensoren einen Standard-Wert annehmen, genau so auch Zustände von Kontakten (Schließer-, Fenster-, etc), bis sie das erste Mal wieder einen Wert senden.

Und eben dann ist beim Reboot eine Bedingung oft "false positive", weil halt von der Logik-Engine nicht unterbunden wird, Bedingungen bei Zuständen zu prüfen, die nicht valide sind!

[Sven_A]

...auch sinnloserweise (z.B. in durch Taster getriggerten Programmen, die definitv durch einen Systemstart nicht getriggert werden können)....

Da hast du schon recht. Aber es stört auch nicht. Better safe than sorry.

[Xel66]

Aber es stört auch nicht.

Doch, es stört, weil es auch gewünschte Funktionen unterbindet und ein globaler Einsatz ist daher sinnfrei. Der Hersteller hat das System vermutlich nicht ohne Grund so angelegt. Eben dass das System nach einem Reboot in einem Zustand steht, wie es die durch den Anwender angelegte Prorammierung für den angegebenen Zeitpunkt vorgesehen hat. Wenn etwas nicht so läuft, wie vorgesehen, dann ist die Umsetzung durch den Anwender sch.... (...lecht) umgesetzt.

Beispiel: Ich habe ein Backup aus dem Sommer und spiele das im Winter wieder ein (wie wahrscheinlich das ist, sei mal dahingestellt). Bei einem Start im Winter, der ggf. die Außentemperatur abfragt und das System in den Heizbetrieb stellt und vice versa), wäre doch wahrlich zielführend. Legt man solche Funktionalitäten flach, muss man sein System manuell korrigieren. Genau so kann man auch die Rollladen- oder Lichtsteuerung mit der Zeit- oder Tag/Nachtsteuerung betrachten. Man macht also das im Nachgang manuell, was vorher das System von ganz allein gemacht hat. Und ich vermute mal, genau die von mir dargelegte Sichtweise war die Intension des Herstellers, diese Funktionalität genau so anzulegen.

Better safe than sorry.

Die Sicherheit des Systems wird dabei keinesfalls erhöht (und ja, ich kenne auch die Beispiele, dass eine Keymatic wegen schlechter Programmierung beim Systemstart die Tür öffnet). Eher im Gegenteil. Und wenn Programme durch einen Systemstart getriggert werden, geschieht das auch dadurch, dass Aktoren abgefragt werden oder Sensoren ihren Status erstmalig übermitteln. Dann wäre auch eine zustandsorientierte Reaktion des Programms auch zielführend. Und ein globaler Einsatz des Workarounds (gerade wie in dem Beispiel mit dem Taster als Trigger eines Programms) zeigt eigentlich, dass der Anwender sein System nicht durchschaut hat und nicht nachvollziehen kann, wie es arbeitet. Dabei ist gerade das im WebUI-Handbuch allgemeinverständlich (wenn auch nicht ganz fehlerfrei) dokumentiert. Muss man nur mal lesen. Aber diesbezüglich bin ich der einsame Rufer in der Wüst. Und wenn der Duty Cycle durch die Decke geht, dann liegt das u.a. auch daran, dass viele Aktoren ohne Prüfung ihres aktuellen Schaltzustandes angesteuert werden und deren folgende (teils unveränderte) Statusrückmeldung dann wieder andere Programme triggert.

Gruß Xel66

[Sven_A]

Du bist Lustig.
Ich hatte ganz klar dein Beispiel mit dem Taster zitiert und DARAUF geantwortet. Und eben DA stört die Abfrage nicht (vorausgesetzt die "Rücksetzzeit" ist so kurz das dass System nicht ewig blockiert). Sie nützt nichts, stört aber auch nicht wirklich. So what, leben und leben lassen.
Und ja, ich bin auch bei dir das viele das System nicht verstanden haben.

Aber da du dein Beispiel jetzt gedreht hast: WENN ich im Winter ein Backup vom Sommer einspiele hab ich andere Probleme als eine Systemvariable die nicht umgeschrieben wird. Da wird man schon irgendwo von Hand eingreifen müssen.
Mal davon abgesehen das beim Systemstart sowieso noch keine neue Außentemperatur vorliegt, das System die Variable also auch nicht umstellen kann. Wenn nach ~5 Minuten die erste Sendung eintrifft passt das noch immer.

Gruß,
Sven

[Baxxy]

Wenn etwas nicht so läuft, wie vorgesehen, dann ist die Umsetzung durch den Anwender sch.... (...lecht) umgesetzt.

Gründsätzlich gebe ich dir recht. Die korrekte Umsetzung setzt aber das Wissen voraus das, wie von Jérôme erwähnt...

beim Reboot z.B. die Temperatur-Werte von Temperatursensoren einen Standard-Wert annehmen, genau so auch Zustände von Kontakten (Schließer-, Fenster-, etc), bis sie das erste Mal wieder einen Wert senden

Und daran hapert's häufig.
Ich setze bei Tastendrücken, bestimmten Zeitmodulen und SysVars als Programm Trigger die "CCU-Status"-SysVar nicht ein.
Bei Aktorstatus oder Sensorwerten (wenn es notwendig ist) schon.

Bei Sensorwerten insbesondere dann wenn man auf einen Wert < x triggert. Ist ja bei Systemstart quasi immer der Fall da alle Werte auf "0" stehen.
Ja, das könnte man mit einer Zusatzbedingung à la

Code: Alles auswählen

WENN Temp-Außen <10°C bei Änderung
UND
Temp-Außen <> 0°C nur prüfen

abfangen, der Effekt ist aber annähernd der selbe wie bei der CCU-Status"-SysVar.
Auch wenn es vielleicht nicht das Beste Beispiel ist, ohne die zusätzliche Bedingung würde das DANN ausgelöst obwohl die Temperatur bei Zentralen-Neustart real 12°C auf Balkonien war.

[Xel66]

Bei Sensorwerten insbesondere dann wenn man auf einen Wert < x triggert. Ist ja bei Systemstart quasi immer der Fall da alle Werte auf "0" stehen.

Das hängt vermutlich mit zusätzlichen Triggern im Programm zusammen, die eine Bedingungsprüfung antriggern und dann bei diesem Startwert <X°C ein WAHR setzen. In einem reinen Programm mit der Temperatur als einzigem Trigger ("bei Änderung" oder "bei Aktualisierung") sollte das nach meinen Beobachtungen nicht der Fall sein, da das initiale Setzen der Temperatur kein Trigger sein dürfte (vergleichbar mit dem Setzen per .Variable()). Allerdings kann man eine Prüfung auf "bei Änderung" nicht sauber abfangen, da in dem Falle ja vermutlich eine Prüfung mit .LastValuer() stattfindet. Und dieses ist ja dann bei der ersten Übermittlung für die Prüfung auf "bei Änderung" ein WAHR. Diese Kombinationen sind natürlich für einen Einsteiger schwer zu überblicken. Dort mag so ein Workaround auch zielführend sein. Allerdings sehe ich hier im Forum häufig Screenshots von Programmen, bei denen der Einsatz des Workarounds so wirklich gar keinen Sinn macht. Und darum gebe ich hier den einsamen Rufer in der Wüste gegen den fragwürdigen globalen Einsatz des Workarounds.

Und dass eine häufige Verwendung eines Status keine negativen Auswirkungen hat, möchte ich so nicht unterschreiben. Man hat hier erstens einen systemweiten single point of failure. Und wie oft im System eine Systemvariable, Wert oder Status eingesetzt werden kann, ist nicht wirklich dokumentiert. Ich bin aber schon über Dinge gestolpert, bei der die Verwendung eines Status als Trigger nicht mehr nach einer bestimmten Anzahl in Programmen nicht mehr funktioniert hat (vermutlich, weil zu viele Bedingungsprüfungen gleichzeitig angestoßen wurde). Bei mir war das ein TFK an der Haustür, den ich mehrfach für Abfragen als Trigger oder einfach nur als Bedingungsabfrage verwenden wollte.

Gruß Xel66