Gelöst: Zeitgesteuerter Aufruf einer Fubktion in myutils.pm (Reglerbaustein)

[Kulli]

Hallo

Anfängerfrage bzgl. MyUtils.pm:
Ich beabsichtige einen größeren Codeblock zur Steuerung meiner Solaranlagenfussbodenheizung zu schreiben.
Der Codeblock (Oder eine Funktion daraus) muss regelmässig aufgerufen werden.

Mir fällt da als erstes ein AT ein der die Funktion aufruft, aber gibt es andere, perlinterne Funktionen mit der man das besser machen sollte?
Die Funktion muss alle 30Sekunden einmal laufen...

LG
Uwe

[bartman121]

Hallo Uwe,

du schreibst hier etwas von Reglerbaustein für eine Heizung.

Ich kenne deinen Code natürlich nicht, aber es gibt ein gut funktionierendes PID-Modul (https://wiki.fhem.de/wiki/PID20_-_Der_PID-Regler) ....

Mit den richtigen Einstellung kann der pid halt alles sein was du brauchst....

Aber vermutlich hängt hinten dran noch deutlich mehr Steuerkram, den man aber sicher außerhalb der eigentlichen Regelung "abfackeln" kann.

Es gibt natürlich viele Methoden, selbst ein cronjob auf os-eben der dann den Befehl an fhem gibt.

Viele Grüße

Andreas

[Beta-User]

Falls es mit PID20 nicht getan ist, klingt das für mich eher danach, als solltest du direkt ein eigenes Modul für deine Anforderungen schreiben und dann direkt mit InternalTimer() arbeiten.
Hat dann den Vorteil, dass du leichter (de-) aktivieren könntest und/oder z.B. im Sommer die Timer auch großzügiger setzen.

Falls du einen "Rahmen" für so ein "Timer"-Modul suchst, könnte ggf. RandomTimer relativ einfach sein (ist aber gepackaged).

[Kulli]

ähm, ja... *überfordert*

Also:
Ich habe 3,6m² Solarfäche auf dem Dach.
Das Ganze ist als Drainback ausgeführt und als Einkreislösung.
Auf der Verbraucherseite gibt es einen 150L Wassertank und eine Fussbodenheizung (Dreikreis, hydraulisch eingestellt, fix)
Bei uns scheint so 4-5h am Tag die Sonne, 300tage lang (ps: Kanaren)

Ein Pumpe bewegt das Wasser, ein 3Wegeventil bestimmt ob FBh oder Speicher das Wasser bekommt.
Aktuell ermittele ich die Arbeitspunkte wie maxTemp im Panel, Lichtstärke, dT bei verschiedenen Lichtstärken, dT beim Speicher usw.

Jetzt wird es tricky, weil:
Von 9:30 bis 12:00 haben wir fast immer Sonne, aber der Lichteinfall ist nicht perfekt. dT über Panel so ca 8Kelvin. Das ist perfekt für den Fussboden, wenn der Vorlauf nicht heisser als 35°C werden soll.
Bei >35°C schalte ich aktuell um auf Wasserspeicher, und zwar so lange bis das dT Panel zu klein wird, dann wieder zurück auf Fussboden usw...

Einen PID brauche ich nicht da ich ohnehin nur umschalte und nicht viel regeln kann (ich habe zwar eine regelbare Pumpo von grundfoss verbaut und kann sie auch per PWM regeln, aber das ist etwas für den Winter 2023 )

Naja, die erste Idee war das Ganze mit eine Menge an notify's zu erschlagen, aber das führt dazu das die Funktion "Solaranlage" in xx Teile zerlegt wird und ich in einem jahr nicht mehr weiß wo was wie das denn noch mal funktionierte.
Daher kam mir die idee, das Ganze dann doch in einer myutils.pm runter zu schreiben.

Wenn ich das richtig verstanden habe, ist die myutils.pm nicht ganz frei von dem fhem und muss bestimmten Regeln folgen, oder?
Das wäre schon ok. Ich will in erster Linie das gleiche machen was ein notify auch machen würde.
Aber ich möchte das in Summe als Funktionen schreiben die ich dann aufrufen kann und alles soll in EINEM Codefenster stehen

Hmm, wie soll ich das besser beschreiben?
Wäre fhem eine SPS, würde ich das als Schrittkette programmieren
Ich muss zB von einem Betriebszustand wie FBh heizen zu Speicher heizen eine Einschwingzeit von ca 15Min abwarten, bis die Temperaturen wieder zuverlässig den richtigen Wert anzeigen.
Gleichzeitig kann die Sonne verschwinden und die Schrittbedingung ist nicht mehr gültig, also wieder zurück auf Start usw...
Also wäre das eine Schrittkette, so müsste ich Sie regelmässig abarbeiten...

Also meine stümperhafte Lösung würde dann so aussehen:
Ein AT ruft alle 30 Sekunden eine Funktion "Heizung" aus meiner myutils auf. "Heizung runft dann je nach zustand Funktionen aus der myutils auf:" Schritt1, Schritt2, Schritt3" usw.
Die Transitionslogik steckt dann vermutlich in "Heizung"

Vielleicht denke ich aber auch viel zu kompliziert und das lässt sich viel simpler umsetzen...

[Beta-User]

Hmm, aber nachts alle 30 Sekunden diese Funktion aufzurufen ist doch völlig unnötig, es muss erst angefangen werden, wenn die Sonne aufgegangen ist...

Vermutlich wäre es aber so oder so das beste, das ganze möglichst auf einen Microcontroller auszulagern und dann in FHEM nur noch die Überwachung zu machen. Dann kannst du ggf. auch die PWM-Pumpe von da aus ansteuern. Für die Temp des Kollektors einen NTC, den Rest per DS18B20.

[Kulli]

Ganz genau:-)
Alles schon fertig. Habe mir eine Platine mir 6 DS1820, PWM Eingang und PWM Ausgang für die pumpe, 2 Relais für Pumpe und 3Wegeventil gebaut.
Davon sind nun 3 Platinen verteil und messen zusammen:
T1= Temp Speicher oben
T2= Temp Speicher unten
T3= VL verbraucher
T4= RL Verbraucher
T5= Paneleintritt
T6= Panelaustritt
T7= Fussbodentemp Raum1 (Temp unterhalb der Fliesen, 6cm vom Heizungsrohr entfernt
T8= FBh Temp Raum2
Helligkeitssensor neben dem Panel draussen

Das muss ich jetzt nur noch kurz verknubbeln und fertig...

[Beta-User]

Dir ist aber klar, dass DS18x20 nur bis 85°C genau sind, und max. 125°C anzeigen werden? Für den Kollektorausgang ist das m.E. nicht passend...
(Ich bastel' grade auch gedanklich an der Heizung rum, allerdings kommt die Kollektortemp hofentlich auch der autonomen Steuerung).

[Kulli]

Ich hoffe nicht dass das panel mehr als 85°C raushaut.
Die Pumpe schafft 2l/min, und pumpt das Wasser (Wenn Speicher aktiv ist) in 15 min einmal um.
Das hängt daran, das ich im Drainbackspeicher ca 12-15kg Wasser als Vorlage drin habe.

Wenn die FBh aktiv ist, dauert es viel länger, ca 50L mehr Wasser sind zu bewegen.

Also ich werde erst mal mit einem AT anfangen und gucken wo sich das hin entwickelt.

Gerne wäre ich bereit mein Setup hier zu teilen (Platinenlayout, Arduinoprogramm, fhem setup, wenn Interesse besteht.

LG
Uwe

[Sany]

Moin,

Vielleicht denke ich aber auch viel zu kompliziert und das lässt sich viel simpler umsetzen...

ich bin mir nicht sicher, ob Dein Ansatz, irgendetwas alle 30 sec aufzurufen, der richtige ist. fhem arbeitet Event-gesteuert, d.h. irgendwas passiert, darauf wird reagiert. z.B. Schalter ein/aus oder irgendwelche Werte werden über/unterschritten. Dafür gibts notify.
Natürlich kann man auch zeitlich steuern, dafür dann ein at

Aber fhem wäre nicht fhem wenn es nicht auch Möglichkeiten gäbe, das so zu machen, wie Du es Dir vorstellst:

Naja, die erste Idee war das Ganze mit eine Menge an notify's zu erschlagen, aber das führt dazu das die Funktion "Solaranlage" in xx Teile zerlegt wird und ich in einem jahr nicht mehr weiß wo was wie das denn noch mal funktionierte.
Daher kam mir die idee, das Ganze dann doch in einer myutils.pm runter zu schreiben.

Aber ich möchte das in Summe als Funktionen schreiben die ich dann aufrufen kann und alles soll in EINEM Codefenster stehen

Da würde ich Dir DOIF in der perl-Version (DOIF-perl) ans Herz legen: https://wiki.fhem.de/wiki/DOIF/Perl-Modus

Solltest Du DOIF im fhem-Modus schon kennen, dann ist nur die [Device:Reading] Schreibweise wichtig, vergiss ansonsten alles zu DOIF, was Attribute und Zweige und Zustände des DOIF angeht. Das ist im Perl-Modus anders, sprich Du musst Dich selbst drum kümmern, bist dadurch aber auch vollkommen frei.
Das Wiki ist sehr umfangreich, aber gut. Wichtig ist das Verständnis, wie Devices/Readings das DOIF triggern oder eben nur als Abfrage dienen. Alles andere ist weitestgehend Perl, so wie Du es auch in der myUtils schreiben würdest.
Allerdings kannst Du alles zu deiner Solargeschichte tatsächlich in einem DOIF unterbringen, sogar mit entprechender UI für Anzeige oder Eingaben.
(Im Prinzip könntest Du sogar das komplette fhem (also die Logik, nicht die Devices) in einem DOIF-perl unterbringen, aber das wäre dann auch wieder unübersichtlich.)

Schau Dir das mal in Ruhe an. Bin mir sicher, dass Du damit zum Ziel kommst.


Viel Erfolg!


Sany

[MadMax-FHEM]

Da würde ich Dir DOIF in der perl-Version (DOIF-perl) ans Herz legen: https://wiki.fhem.de/wiki/DOIF/Perl-Modus

Solltest Du DOIF im fhem-Modus schon kennen, dann ist nur die [Device:Reading] Schreibweise wichtig, vergiss ansonsten alles zu DOIF, was Attribute und Zweige und Zustände des DOIF angeht. Das ist im Perl-Modus anders, sprich Du musst Dich selbst drum kümmern, bist dadurch aber auch vollkommen frei.

Wo ist dann der (große) Unterschied zu einem notify (auch das kann auf mehr als EIN Ereignis triggern) und dann eine Sub in myUtils -> auch ganz normales Perl...

Gruß, Joachim

[Sany]

Wo ist dann der (große) Unterschied zu einem notify (auch das kann auf mehr als EIN Ereignis triggern) und dann eine Sub in myUtils -> auch ganz normales Perl...

Kulli wollte das:
und alles soll in EINEM Codefenster stehen

auch das kann auf mehr als EIN Ereignis triggern

und ab da würde ich mal sagen wirds dann richtig unübersichtlich mit EINEM notify. Das schöne ist ja, jeder darf das machen wie er will. Ich mache das eben mit DOIF-perl, weshalb ich hier vorgeschlagen habe.


Gruß


Sany

[MadMax-FHEM]

Kulli wollte das:
und alles soll in EINEM Codefenster stehen
und ab da würde ich mal sagen wirds dann richtig unübersichtlich mit EINEM notify.

Nicht unübersichtlicher als in einem Perl-DOIF?
Und ich lagere das ja auch in eine Sub aus (und man kann ja auch ein Sub-File pro Funktionalität machen)...

Das schöne ist ja, jeder darf das machen wie er will. Ich mache das eben mit DOIF-perl, weshalb ich hier vorgeschlagen habe.

Ja klar

Wollte eben nur anmerken, dass das auch ohne DOIF und mit notify geht...
...und wenn schon DOIF Perl, warum nicht einfach notify und Perl.

Mir erschließt sich spät. da wirklich nicht der große Unterschied/Vorteil.

Aber klar: meine Sicht der Dinge

Entscheiden muss nat. jeder selber, wollte eben nur aufzeigen, dass es durchaus mit notify geht...

Gruß, Joachim

[betateilchen]

Leute, könnt Ihr nicht erstmal versuchen zu verstehen, was der Fragesteller eigentlich haben/machen möchte, bevor Ihr Euch hier tagelang darüber auslasst, wie ihr euch das eigentlich vorstellt?

Einfach unglaublich, wie hier in viele Threads immer wieder an der eigentlich Frage vorbei diskutiert wird. Von immer der gleichen Handvoll Leute...

Nein, dafür gibt es jetzt kein Popcorn. Das ist mir einfach zu schade für sowas.

[Kulli]

Hi
Nach verschiedenen Versuchen implementiere ich es tatsächlich auf klassischem Weg per notify und at.
Also ich hatte NUR danach gefragt ob es in der myutils so etwas wie ein at gibt, oder so was wie ein nicht blockierendes Sleep.
Ist jetzt aber auch egal. Aber wenn jemand eine Antwort auf DIESE Frage hat, her damit

Vom Gedankengang bin ich immer vom Sensor zum Aktor gegangen, was nicht zum Ziel führt. Wenn man es dann vom Aktor zu den Sensoren denkt, ist es viel einfacher,
weil ich nur zwei AKtoren habe, aber viele Sensoren!

In fhem kann ich den at benutzen um zu warten, man muss dann nur die Vorbedingungen setzen, warten und als letzten Befehl im at den neuen Mode setzen, fertig.

LG
Uwe

[Beta-User]

dann direkt mit InternalTimer() arbeiten.

Geht auch in einer klassischen myUtils-Datei.

[Kulli]

Hallo
Also: Die ganze Anlage läuft soweit eigentlich nun ganz gut! Ich habe einen at um den Regler regelmässig aufzurufen. Alles andere läuft über weitere notifies.
Die Pumpe wird per Arduino geschaltet bzw per PWM dann geregelt. Kommunikation über RS485.

Allerdings:
Manchmal, wenn das Waser schon heiß ist und die Pumpe wieder schaltet, kavitiert sie. Der Vordruck ist aufgrund fehlender Bauhöhe nicht so groß!

Deshalb wollte ich eine Überwachung bauen. Folgende Idee habe ich:
Dummy um Pumpe ein und Auszuschalten (per Relais)
Dummy um Sollwert vorzugeben (0 - 100%)
Druck im System wird gemessen in mBar

Wenn die Pumpe Eingeschaltet wird, wird der Anlagendruck in einem Userreading gespeichert (Startdruck)
Wird der Sollwert von 0 auf irgendwas > 30% gesetzt, starte ich einen at(in 30Sekunden) der einen notify auslöst.
Dieser prüft
aktuellen_Druck < Startdruck+100mbar? {
  Setze Sollwert auf 0
}

Der Heizungsregler wird den Wert wieder hochsetzen, sobald er ausgeführt wird.
Die Pumpe wird also mehrfach angefahren, bis sie durchläuft und nicht mehr kavitiert.

Das sollte eigentlich funktionieren, hört sich aber irgendwie nicht rund an:
- Eigentlich wäre eine Fahrweise nach Rampe besser, aber wie soll man das in fhem umsetzen ohne fhem zu blocken?
- Eigentlich müsste man die Pumpe dauerhaft auf Funktion prüfen.

Hat wer eine bessere Idee als meine? Wäre für Tipps sehr dankbar!