Neues Plugin: Frequency Counter

**Prof.Mobilux** · 08.03.2024, 12:02

Klick mal auf Restart. Dann sollte er erst einmal wieder anlaufen. Wenn er läuft, bitte mal im Verzeichnis /opt/loxberry/config/plugins/frequency_counter schauen, ob da eine Datei mit Namen "manually_stopped.cfg" (oder so ähnlich) liegt. Wenn ja, die mal löschen.

Dann sollte der Watchdog erst einmal wieder funktionieren. Wenn dann das C-Programm nach einer gewissen Laufzeit stirbt, müssen wir da nochmal weiterschauen warum das passiert.

**Janohmat** · 10.03.2024, 11:09

Ich bekomme die Durchfluss Messer nicht dicht. Habe zur Verschraubung extra gummi Dichtscheiben mitbestellt bringt aber kein zufriedenstellendes Ergebnis. Bei beiden Turbinen. Habt Ihr Teflon mit ins Gewinde eingebracht?

Das Tolle am zweiten Messer der mir nur die Wärmepumpe zählt. Ich kann ausrechnen was der Output der WP ist. Details hierzu dann wenn ich es abgebildet habe... Ich kann dann auch noch die Durchfluss Menge bzw. Spreizung auf Ertrag optimieren.

Angehängte Dateien

**Janohmat** · 10.03.2024, 20:15

Hab jetzt alles in der Garage fertig verkabelt, ist jetzt nicht mehr abgestürzt. Ich behalte es aber dennoch mit Debug Logs am Laufen.

Leider melde die Turbine welche bei mir an GPIO23 eine Frequenz, wenngleich die Turbine sich nicht dreht.
Ich hab hier in der Verkabelung schon die Turbine getauscht, es hängt also nicht an der Turbine.

Im Plugin kann ich kein Pullup/Pulldown konfigurieren.
Initialisiert du den Pin immer ohne Pullup Pulldown oder kann es sein das hier noch ein Pullup/Pulldown aktiv ist?

Zum Testen ob es daran liegt wäre natürlich Bombe wenn man dies einstellen könnte.

**Prof.Mobilux** · 10.03.2024, 22:01

Mmmhhh, ich denke wir setzen das nicht explizit. Ich weiß nicht ob die Lib pigpio da automatisch etwas macht. Ich hab den C-Code ja nur von dort übernommen. Man könnte das schon als Option mitgeben pro GPIO und einbauen. Oder halt generell erstmal ein Reset als ersten Schritt.

pigpio library

https://abyz.me.uk/rpi/pigpio/cif.html#gpioSetPullUpDown

Raspberry Pi Reg. C GPIO library and Python GPIO module and shell command utilities to control the GPIO, including SPI, I2C, and serial links.

**Janohmat** · 11.03.2024, 12:30

Ich hab leider immer noch teilweise vollkommen willkürliche Werte auf den durch Flusssensoren. Ohne das ich eine regelmäßigkeit erkennen kann. Heute hat der Restart des Plugins geholfen. Hast du es schon produktiv im Betrieb sprich mal Statistiken geschriebene?

Was man cooles machen kann wenn es geht anbei 😁

Angehängte Dateien

**Janohmat** · 11.03.2024, 17:56

Jetzt wieder. Ganz komisch. Hab gestern doch noch ne Turbine auf. Amazon bestellt um wirklich alles auszuschließen...

Angehängte Dateien

**Prof.Mobilux** · 12.03.2024, 04:12

Janohmat Habe Deine letzten Beiträge mal vom Poolmanager hier zum Frequency Counter verschoben.

**Janohmat** · 12.03.2024, 21:28

Die einzelnen Werte rechne ich alle getrennt voneinander aus damit ich diese einzeln in der Statistik und in der Visualisierung habe

Spreizung denke ich spricht für sich, Differenz Vorlauf Rücklauf
Wärmepumpe abgegebene Leistung: IF(I1 > 0;IF(I2 > 0;(I2*4186*I1/60/1000);0);0)
- Details: https://chat.openai.com/share/7d71f1...4-a7b1a81c6471
COP: IF(I1 > 0,25;IF(I2 > 0;I2/((I1-0,25));0);0)
- Mein Energiezähler misst auch die Pumpe mit 250Watt welch ich hier von I1 abziehe

**Janohmat** · 14.03.2024, 13:48

Prof.Mobilux Wo willst du für deine Plugins dediziert bug repots haben? Hier zur Diskussion oder willst du die in Github gemeldet haben?
Du erlaubst im Plugin eine refresh rate von 1-60. Das zugrundeliegende freq_count_1 verweigert aber für Werte > 300 (30) den Dienst...

Im Log vom Plugin sehe ich im Fehlerfall leider über die WebUI auch keinen Output vom zugrundeliegenden freq_couint_1
Wenn der Return Wert !=0 ist sollte das /opt/loxberry/log/plugins/frequency-counter/20240314_143104_841_freq_count_helper.log imho im lesbaren Log in der WebUI aufschlagen

Dort sieht man nämlich nur:

**Janohmat** · 14.03.2024, 14:09

Weitere Frage aber losgelöst vom vorherigen. Besteht die Möglichkeit diese Logeinträge irgendwie auszublenden, loszuwerden?

Das Check Watchdog wird ja jede Minute gerufen.
Damit spült es mir mögliche Fehler vom freq_count_1 innerhalb von einer Stunde aus den logs weil eben jeder CheckWatchdog ein neues Logfile erzeugt.

**Janohmat** · 24.03.2024, 21:10

Ich hatte zwischenzeitlich die Parameter Validierung in der Loxone auf meine beiden Durchflussmesser aktiviert und war erstaunt wie oft das Plugin hier die schon beschriebenene willkürlichen Werte wiedergibt. (Jedes mal eine Mail und ne Push Beanchrichtigung)

Daraus resultieren habe ich mir den C Code heute vorgenommen und nochmals Änderungen gemacht.

Die pigpio Library hat eine Watchdog Funktion welche man auf einem GPIO aktivieren kann. Diese Nutze ich jetzt um die Werte auf 0 zu setzen.
Kommt für 1 Sekunde keine Flanke wird die Callback Methode dennoch gerufen und löscht damit zuverlässig die Werte.

Der Rest aus den zwei Threads (main und pigpio) war dann wohl doch nicht die sauberste Lösung (hüstel) 😉

Prof.Mobilux PR kommt dann morgen wenn es sich die Nacht über ruhig verhält.

Soll ich den oben beschriebenen Fehler auch gleich mit korrigieren?

Jan

**Janohmat** · 30.03.2024, 07:03

Das Problem ist auch mit thread locking nicht sauber gelöst.
Es hängt wohl auch am Überlauf des unsigned int 32... Aber die Fehler treten auch zwischendurch auf.
Sehr viel seltener, aber sie treten auf.

Prof.Mobilux
Ich bin leider mit dem rest der hier den Output von dem C Progrämmchen interpretiert nicht wirklich bewandert.
Ich würde gerne Outputs ins Log schreiben um zu sehen welche Werte zu den komischen Berechnungen geführt haben.
Der gesamte output wird ja von etwas anderem direkt gelesen.

Meinst du man könnte den Code der den Output interpretiert so anpassen das er nur dann den Output liest wenn JSON auftritt, und alles andere nativ ins Log schiebt?
Wäre ja auf Basis der {} relativ einfach erkennbar.

Wenn das möglich wäre müsste man noch parallel dafür sorgen das der Watchdog die Logs nicht immer flutet. (Siehe mein Kommentar weiter oben)

Dann wäre die interpretation woher es kommt wesentlich einfacher.
(Würde auch die Möglichen Fehler die beim Programmstart auftreten können im Log sauber persistieren)

Aktueller Stand immer hier: https://github.com/JanFellner/LoxBer...quency-Counter
ich werde aber erst dann wieder einen PR stellen wenn es bei mir über längere Zeit >24h nicht aufgetreten ist.

So sieht es aktuell aus. Ganz links sieht man wie die Pumpe normal arbeitet, alles danach sind dann willkürliche Spikes im "Ruhezustand"

**Prof.Mobilux** · 31.03.2024, 06:51

Mmmhhh, komisch. Ich muss mich da noch einmal reindenken... Wird ein paar Tage dauern - aktuell sind "reale" Projekte angesagt ;-) Ich denke spätestens in 4 Wochen wird mein Pool ausgewintert, dann habe ich reale Testmöglicheiten.

**Janohmat** · 06.04.2024, 06:45

Seit meinen letzten Änderungen sehe ich diese Spikes nur noch auf einer der beiden Turbinen. Es also echt Thread save zu machen brachte eine deutliche Verbesserung. Möglicherweise tritt dieses Problem auch nur auf wenn man zwei Turbinen hat und jemand mit einer sieht es gar nicht.
Zum Thema der Spikes auf der zweiten Turbine vermute ich jetzt mal dass Sie mit 3.3V doch nicht stabil läuft und wenn das Propellerrad sich sehr langsam dreht (Wasser steht im ausgeschalteten Zustand ja aufgrund Thermischer Effekte nicht still). Ich sehe diese Effekte nur im abgeschaltet Zustand.
Prof.Mobilux ich mach nachher nen neuen PR da ich es deutlich verbessert sehe.
Ich verdrahte dann mal um auf 5V mit Spannungsteiler.
Keep you posted.

**Prof.Mobilux** · 08.04.2024, 05:42

Ich habe aus Janohmat's Ergänzungen die 0.3.0 veröffentlicht: https://wiki.loxberry.de/plugins/fre...-counter/start

Änderungen in diesem Release:

(Mostly) Fixes occasional spikes / ghost measurements (Thanks to @JanFellner)
Adjusting permissions due to security reasons