[gelöst] Homematic Devices und aggregierte Werte

[Sany]

du kannst ja mal zum ergiebigen Testen das DOIF kopieren und die Pumpe ersetzt Du durch ne übrige Lampe. Dann deaktivierst Du das "PumpenDOIF" solange du am testen bist.

obwohl sie manuell eingeschaltet wurde.

ich hatte ja schon mal gefragt, wer da was wann schaltet. Um evtl. ein andere Lösung zu bauen sollte das bekannt sein. Bisher kann ich Dir nur helfen, das das DOIF richtig arbeitet, nicht aber bei der Logik des ganzen.
Also wenn Du Zeit hast versuch die Aufgabenstellung ausführlich zu schildern.

Danke für die Liste der Schalter. Ich hatte kurz die Befürchtung, dass da noch "unter-Module" sein könnten wie bei Homematic-Thermostaten oder der Schaltsteckdose mit Leistungsmessung. Die hätten bei der AggregationsRegex vielleicht auch noch mitgemischt.

Bin mal gespannt auf die neueste Version. Vielleicht dann mal wieder ein list vom DOIF und den Eventmonitor dazu. Sonst wirds unübersichtlich.

Gruß

[holle75]

Sany!

das hier (hab jetzt auch gleich die != eingebaut)

Code Auswählen Erweitern

BeregnungDOIF_PumpeCisterna DOIF ([$SELF:aktivierteBeregnungSchalter] > 0 or [?$SELF:manu] eq "on") \
(set PozzoHauptOben_PUMPE_Cisterna on) \
DOELSEIF ([$SELF:aktivierteBeregnungSchalter] == 0) \
(set PozzoHauptOben_PUMPE_Cisterna off) \
DOELSEIF  ([PozzoHauptOben_PUMPE_Cisterna:"^on$"] and [?$SELF:cmd] != 1 and [?$SELF:cmd] != 5) \
(set $SELF manu on) \
DOELSEIF  ([PozzoHauptOben_PUMPE_Cisterna:"^off$"] and [?$SELF:cmd] != 2 and [?$SELF:cmd] != 5) \
(set $SELF manu off) \
DOELSEIF ([05:30] and [?AnwesenheitHaupt:statStateDaypresent] eq "00:00:00" and [?PozzoHauptOben_PUMPE_Cisterna] eq "off") \
(set PozzoHauptOben_PUMPE_Cisterna on-for-timer 10) \
DOELSEIF ([17:30] and [?$SELF:cmd] == 5) \
()
attr BeregnungDOIF_PumpeCisterna DOIF_Readings aktivierteBeregnungSchalter:[#"^BEREGNUNG_SCHALTER_":state:"^on$"]
attr BeregnungDOIF_PumpeCisterna readingList manu
attr BeregnungDOIF_PumpeCisterna room System


mit dem event log beim Einschalten

Code Auswählen Erweitern

2021-03-21 18:54:06.704 HM485 BEREGNUNG_SCHALTER_Zitronen_12_7_MEQ0064131_14 set_on
2021-03-21 18:54:06.765 DOIF BeregnungDOIF_PumpeCisterna cmd_nr: 1
2021-03-21 18:54:06.765 DOIF BeregnungDOIF_PumpeCisterna cmd: 1
2021-03-21 18:54:06.765 DOIF BeregnungDOIF_PumpeCisterna cmd_event: BeregnungDOIF_PumpeCisterna
2021-03-21 18:54:06.765 DOIF BeregnungDOIF_PumpeCisterna cmd_1
2021-03-21 18:54:06.782 HM485 BEREGNUNG_SCHALTER_Zitronen_12_7_MEQ0064131_14 working: off
2021-03-21 18:54:06.782 HM485 BEREGNUNG_SCHALTER_Zitronen_12_7_MEQ0064131_14 on
2021-03-21 18:54:06.808 HM485 PozzoHauptOben_PUMPE_Cisterna set_on
2021-03-21 18:54:06.849 HM485 PozzoHauptOben_PUMPE_Cisterna on
2021-03-21 18:54:06.849 HM485 PozzoHauptOben_PUMPE_Cisterna working: off

macht das und sieht so aus, wie ich mir das ursprünglich mal gedacht (und mit dem wait auch in unhübsch getan) hatte.

Dein Trick das Wirrwarr auf ein DOIF Reading zu legen hat geholfen.

jetzt fühlt es sich auch nicht mehr nach Pfusch an

... und ich möchte nie mehr nach "off"s suchen müssen, bitte.

Die alte Idee war:

- meine Zisternen-Pumpe wird entweder manuell oder durch Anwesenheit/Abwesenheit automatisch an oder ausgeschaltet
- wenn durch Abwesenheit oder manuell ausgeschaltet, muß sie trotzdem wenn die Beregnung läuft angehen
- danach soll sie wieder den selben Zustand annehmen (bleibt an wenn vorher an oder aus wenn vorher aus)

EDIT: falls das hier mal jemand nachvollziehen möchte. Ich habe das kleine "Extra" vergessen zu erklären
- cmd_5 schaltet bei Abwesenheit die Pumpe für 10 Sekunden an um ein verrockern zu vermeiden (sonst kann es dir passieren, dass der Dichtungsring, resp Eisenoxid im Wasser an der Welle nach Wochen der Nichtbenutzung die Pumpe blockiert)
- cmd_6 ist für einen Statuswechsel zu cmd_5 damit cmd_5 täglich ausgeführt wird

ich muß jetzt die Tage mal alle Varianten durchprobieren. Aber wenn das Anschalten Beregner -> Beregnung sauber läuft (und der Rest auf dem Testsystem mit Dummies auch) bin ich guter Dinge.

vielen Dank an dich! für deine Zeit

Gruß!
H.

[Sany]

na das freut mich. Nur bei dem working bist Du ziemlich resistent, was die Beratung angeht . Thorsten hat es doch erklärt: Der Taster ist nur zwischen "set_on" und "on" "working", meldet das aber erst mit "on", also kommt da IMMER  "working off" -> also kann es auch, NUR FÜR DIE TASTER!!, weg! Macht es einfach leserlicher.
Bei der Pumpe musst Du Dir halt überlegen, ob Du das nutzen möchtest, ich unterstelle mal, wenn die Pumpe per on-for-timer eingeschaltet wird ist working on. Das kann man sich zu nutze machen.

Aber jetzt teste mal, ob alles wie gewünscht läuft, dann kann da ja ein Haken dran

Viel Erfolg!

Sany

noch eine Frage: WIE wird die Pumpe manuell geschaltet? Am Aktor? Über die fhem-Oberfäche? Ein "Sender" der den Aktor bedient? Ich will nur wissen, wie das DOIF mitbekommt, dass die Pumpe manuell geschaltet wurde. Und die Pumpe kann auch laufen, wenn nichts beregnet wird (ist quasi unter Strom, aber fördert nix)

[holle75]

Nee, nicht Beratungsresistent, aber immer unwillig, wenn ich keine Notwendigkeit sehe

(oder deinen Punkt nicht 100%tig verstehe?)

Ich will einfach nicht bei geschätzt 150 Devices da jetzt ein event-on-change-reading hinbasteln. Auch wenns nur die Taster sind, oder auch wenns nur die switches wären. Und auch nicht nur bei den 9 Devices für das DOIF jetzt weil ichs dann vergesse und irgendwann wieder dumme Fragen stelle weil was nicht funktioniert.

Das "working" ist ja nicht das Problem wie sich rausgestellt hat (und ich hätte zwischendurch meinen A.... drauf verwettet, einfach weil mir nix mehr eingefallen ist). Und die paar working Events (lass es 200 am Tag sein ... wie oft schaltest du einen Taster/Schalter?) bei abertausenden anderen Events über den Tag machen mMn den Kohl nicht fett.

Wenn ichs nicht kapier, gerne verdeutlichen. Ich weiß deine Detektivarbeit sehr zu schätzen, da wird auch der Rest Sinn machen können.

Die Pumpe wird über DOIF´s oder manuell auf der Weboberfläche oder ftui gesteuert -> HMW Aktor -> "unter Strom gesetzt" wird ein (mechanischer) Druckmesser, der dann bei Abfall im Leitungsystem final die Pumpe anschaltet (und auch abschalten würde wenn kein Bezug). Die Beregner sind über Ventile (wieder HMW 12-7, aber über 24V AC versorgt) angesteuert.

Edit: ach so, du meintest wegen meinem "nie wieder offs suchen müssen" das mit dem working? Hab das schon kapiert, das stand jetzt eher als Synonym für die ganze Affäre.

[Sany]

aber immer unwillig, wenn ich keine Notwendigkeit sehe

(oder deinen Punkt nicht 100%tig verstehe?)

wenn Du Muße hast, lies mal hier:
https://forum.fhem.de/index.php/topic,117075.msg1114300.html#msg1114300

Da ist nicht jeder Beitrag relevant, aber so ein paar grundlegende Infos kann man daraus ableiten. Ich habe dort auch meine Erfahrungen geschildert.
Kurz: jeder unnötige event bedeutet Last fürs System, je weniger desto besser für alles. Es war wohl mal so, dass praktisch jeder Event, der von irgendeinem Device gefeuert wurde, alle anderen Devices irgendwie "angetriggert" hat. Das wurde besser durch NOTIFYDEV, also eine Liste in jedem Device, von welchem "Sender" Events überhaupt in Betracht gezogen werden. Haben aber wohl nicht alle Module. Das blöde ist, wenn das System mal an Belasungsgrenzen stößt kommen eigenartige Dinge dabei raus, die man nirgends zuordnen kann (bei mir z.B. dauernde "Hänger" von kurzer Dauer. Damit kannst Du Dinge, die von Zeiten im Sekundenbereich abhängen (Zähler z.B.) vergessen. Meiner Meinung nach ist es eigentlich immer wichtig bei neuen "Dingen" in fhem, also z.B. ein DOIF, von allen Beteiligten erst mal per Eventmonitor mitzuplotten: was liefert das Device eigentlich und wie oft, was brauche ich davon, was nicht (-> event-on-xx) und dann die Logik überlegen und dann Schritt-für-Schritt das DOIF entwickeln. Dabei immer den Eventmonitor der beteiligten Device und des DOIF offen haben. Auch ein tail aufs Logfiel von fhem offenbart manchen Fehler direkt nach klicken auf modify. Und spätestens beim dritten DOELSEIF über DOIF-Perl nachdenken (ok, das scheint ein Steckenpferd von mir zu sein). Und generell: All das was ich hier so von mir gebe ist nur meine Meinung und wird zum Großteil auf Erfahrung und ausprobieren gestützt. Und auf keinen Fall kann es vollständig sein (ich weiß ja nicht alles) und es kann sogar sein, dass es falsch ist.
So, das war genug OT, würde mich für dich freuen, wenn morgen die Beregnung in all seinen Varianten läuft!

Gruß

[holle75]

Natürlich hast du Recht. Das Prinzip ist richtig.

Ich bin noch an dem Punkt wo ich abwäge, wie aufwendig oder nebeneffektbelastet die Einschränkung im Verhältnis zum Nutzen ist. Oder wieviele Events ich tatsächlich mit wie viel Problemen die damit entstehen nicht passieren lasse.

Das wären jetzt in dem speziellen Fall 150 Zeilen in der cfg für geschätzt 100-200 Events am Tag. Allerdings wären diese 150 Zeilen im Ergebnis zu 99% problemfrei.

Bei Devices die gesprächsfreudig sind habe ich auch schon eine Woche gesessen um all die Auswirkungen in den Griff zu bekommen. Da lohnt es sich dann aber auch, weil es um tausende von events am Tag geht.

bin komplett bei dir, aber ab und zu einfach ein bißchen faul

es sei mir gegönnt.

Nochmals Danke und ich berichte falls das Ganze doch nicht funktionieren will ...

lieb Gruß
H.

[holle75]

noch ein kurzer Abschlussbericht. Ohne ein kleines

wait 0:2:2:2:0:0

verhaspelt sich das DOIF noch immer (aber nur noch "ab und zu"). Das macht nach Sanys Erklärung mit dem zeitlichen Versatz Trigger/Abfrage auch Sinn.

Auch ein event-on-change-reading auf state der beteilgten HMW Devices führte nicht zur Lösung (das set_on gibts ja trotzdem im state -> trigger)