Alternative Firmware für das Raum-Sensormodul von Masifi

[jgerhart]

Hallo Waldemar,
super, da bin ich gerne der Beta-Tester für das nächste Release!
Gruß,
Jens

[mumpf]

Hi Jens,

ich habe nochmal nachgeschaut. Als Standardfunktion macht das beim derzeitigen Aufbau der Formelfunktionen in der Logik keinen Sinn, da man den Dämpfungsfaktor dann nicht als Parameter übergeben könnte. Und so etwas mit einem konstanten Wert als Standardfunktion zu implementieren macht einfach keinen Sinn.

Aber als Benutzerfunktion wird es gehen, dann immer noch mit einem fest programmierten Dämpfungsfaktor, aber dann eben vom Benutzer angelegt und damit für jeden Benutzer individuell. Frag doch hier nochmal nach, wenn das nächste Beta-Release fertig ist und Du es nutzt, dann kann ich dazu was schreiben und das als Beispiel nehmen, um das Anlagen von Benutzerfunktionen zu beschreiben (obwohl das natürlich auch in der Applikationsbeschreibung enthalten ist).

Gruß, Waldemar

[mumpf]

Hi Jens,

Dann könnte man sich Glättungen von anderen Sensoren auf dem Bus über externe Logiken sparen und das in deiner Applikation erledigen.

so hätte ich es am liebsten gemacht. Allerdings hatte ich bisher in der Logik noch keine Formeln, deswegen war das bisher nicht möglich.

Beim nächsten update der Beta-Firmware wird es eine erste (sehr elementare) Formelfunktion in der Logik geben. Die kann zwar noch kein Glätten, aber man wird Benutzerformeln im Coding spendieren können, damit ist das dann realisierbar.

Und da ich sowieso noch einen Bug suche und deswegen auch kein Release machen kann, schaue ich mal, ob ich die Glättung nicht bei den Standardfunktionen aufnehmen kann - so als Beispiel, was alles als Benutzerfunktionen gehen könnte.

Insofern kommt Dein Vorschlag zur richtigen Zeit...

Gruß, Waldemar

[jgerhart]

Hallo Waldemar,
die Glättungs-Option finde ich wirklich prima. Deshalb meine Frage: Wäre es möglich die Glättung auch mit in die Logik aufzunehmen? Dann könnte man sich Glättungen von anderen Sensoren auf dem Bus über externe Logiken sparen und das in deiner Applikation erledigen. Logik-Kanäle sind ja wirklich genug da :-)
Viele Grüße
Jens

[mumpf]

Hi Jens,

ich habe eben mal geschaut. Bei mir kommt auch 1 raus, obwohl es nach VOC-Wert eigentlich 2 sein müsste. Ich muss das wohl nochmal debuggen, komme aber erst am Wochenende dazu. Danke für den Hinweis, ist mir vorher nicht aufgefallen.

Ich melde mich, wenn ich genaueres weiß.

Gruß, Waldemar

[jgerhart]

Hallo Waldemar,

ich habe deine aktuelle beta Firmware auf ein Sensormodul mit einem BME680 geladen und jetzt eine gute Woche in Betrieb. Die Kalibrierung ist mit 100% auch schon seit einigen Tagen abgeschlossen.
So wie ich das verstanden habe, ist der VOC-Maximalwert 500, den es auch tatsächlich einmal gab. Die Luftqualität bleibt aber ständig auf 1 und ändert sich nicht:

Screenshot 2021-05-12 142533.png
Viele Grüße
Jens

[mumpf]

Hi Matthias und auch alle anderen,

das passt zu den Erwartungen. In der ersten Version vom Watchdog habe ich noch Fehler gefunden. Zwar hat der grundsätzlich gegen Hänger des Prozessors geholfen, aber ich habe erst vor kurzem festgestellt, dass beim SCD30 der Sensor selber hängt und den gesamten Sensorbus (I2C) blockiert. Somit hat der Reset des Prozessors beim ersten Watchdog gar nicht geholfen.

Matthias hat von mir einen Patch bekommen, den er netterweise ausprobiert, der jetzt auch den Sensor für 5 Sekunden abschaltet und dadurch neu startet. Bei mir läuft das seither ohne Ausfälle. Ich habe inzwischen auch weiter Libraries ausprobiert, die den SCD30 ansteuern, aber da gibt es keine Abhilfe - die verhindern alle nicht den Hänger vom Sensor und sind alle eher schlechter bei der Auswertung der Messwerte. Somit bleibe ich bei der bisher verwendeten Lib.

Bei meinen Tests ist noch was anderes rausgekommen (falls das jemand plant): Wird der SCD30 zusammen mit 1-Wire verwendet (was technisch möglich ist und auch von meiner Firmware angeboten wird), so schlägt der Watchdog hier innerhalb von 30 Minuten zu (manchmal auch schon nach 5 Minuten). Natürlich kann man für ein reines Sensormodul damit leben, aber es ist keine von mir empfohlene Betriebsart. Ich versuche, in Zukunft eine entsprechende Warnung in die Applikation einzubauen.

Die aktuelle Beta-Firmware hat noch nicht die neueste Version vom Watchdog eingebaut, sobald ich hier wieder eine Version habe, bei der alle Teile zusammen passen, gibt es ein Update.

Soviel zum Zwischenstand,
Gruß, Waldemar

P.S.: ReinerDaniel danke für das Feedback...

[ReinerDaniel]

Hallo Waldemar,
hier mal ein Zwischenbericht. Ich habe die beta-Version mit dem Patch für das SCD30 auf zwei Module aufgespielt. Diese laufen seither ohne Probleme. Auffälligkeiten an den Messwerten kann ich derzeit nicht entdecken. Zwei - eingebaute - Module haben noch die erste Variante des Watchdog. Davon hat läuft eines jetzt seit Wochen ohne Probleme. Eines hat sich gestern wieder aufgehangen (s. Ausdruck). Ich werde bei Gelegenheit diese beiden Module mit der beta-Version mit Patch programmieren und dann mal wieder berichten.
Ich wünsche Dir einen schönen Sonntag! Endlich scheint hier mal die Sonne; perfektes Wetter für den Muttertag.
Gruß Matthias Bildschirmfoto 2021-05-09 um 10.48.27.png

[stmeyer]

Sehr gerne,

[mumpf]

Hi Stefan,

das wäre, zumindest für mich, die nahezu perfekte Lösung.

damit hast Du Dich, zumindest für mich, als nahezu perfekter Tester für diese Lösung qualifiziert. Ich melde mich, wenn es soweit ist.

Gruß, Waldemar

[stmeyer]

Hi Waldemar,
wunderbar, das wäre, zumindest für mich, die nahezu perfekte Lösung.

Viele Grüße
Stefan

[mumpf]

Hi Stefan,

ich wollte ja schon immer mal ein Mathe-Modul für die Logik machen. Aber wie das immer so ist, das dauert alles viel länger als gedacht. Es ist sehr anspruchsvoll, in der ETS eine passende Oberfläche für Formeln anzubieten. Das wird somit noch dauern.

Deswegen gibt es bald die "kleine" Lösung:

Die Idee kommt von meinem 1-Wire-Modul und heißt "Kundenspezifische Funktionen", das werde ich auch für die Logik ermöglichen.

Es gibt jetzt schon die Möglichkeit, am Ausgang einer Logik den Wert von Eingang 1 oder Eingang 2 senden zu lassen. In Zukunft wird man zwischen die Eingänge und den Ausgang auch eine von ca. 30 Kundenfunktionen schalten können, die im Coding hinterlegt wird. Diese Funktion muss natürlich vom User implementiert werden, bekommt dann den Wert von Eingang 1 und Eingang 2 als Parameter und man kann da dann machen, was immer man will (auch das Modul zum Absturz bringen). Wenn Du dann also den Ausgang vom Entfernungssensor auf Eingang 1 der Logik legst, kannst Du Dir so eine Umrechnungsfunktion bauen. Eingang 2 kannst Du (musst Du aber nicht) auch noch für die Temperatur nutzen, um Deine Umrechnung in Liter z.B. noch abhängig von der Wärmeausdehnung abhängig zu machen.

Ein weiteres (breites) Anwendungsfeld sind natürlich irgendwelche expliziten Konvertierungen von einem bestimmten DPT zu einem anderen. Diese passieren derzeit im Logikmodul nur generisch und treffen vielleicht nicht genau das, was man erwartet. Dafür wird es dann auch ein paar bereits implementierte Beispiele geben.

Der Nachteil ist natürlich auch klar, wenn Du die Funktion ändern willst, geht das mit diesem Ansatz nicht in der ETS, sondern nur in der Firmware, man muss die dann neu bauen und auf das Modul spielen, aber das ist eben das, was ich kurzfristig unterstützen kann. Außerdem gehe ich davon aus, dass man nicht beliebig viele solcher Funktionen braucht, die 30 die ich aufrufbar machen will sollten da wirklich die Obergrenze sein. Aber auch da kann man drüber reden, technisch werden wohl bis zu 255 gehen.

Und dann kann man ja noch das Forum dazu nutzen, um sich über Funktionen auszutauschen und über sinnvolle Verbesserungen zu diskutieren.

In gewisser Weise ist es auch ein Vorteil, die Firmware selber bauen zu können, denn so können auch kundenspezifische Erweiterungen gemacht werden, ohne dafür gleich Anpassungen in der ETS machen zu müssen. Im Profi-Bereich (also für die Hersteller) heißt so was womöglich gleich eine erneute Zertifizierung, weitere Kosten, neue Applikationsbeschreibung, Schulung vom Support und vieles mehr, so dass es dann nicht gemacht wird.

Das nur mal so aus Ausblick, wann das genau zeitlich kommt, kann ich noch nicht sagen. Aber wohl noch dieses Jahr . Ich bin derzeit noch komplett mit Lösen von Fehlern beschäftigt. Und - den Zeitaufwand sollte man nicht vernachlässigen - ich mach das ja für mich, muss also auch noch meine Module passend einbauen und parametrisieren.

Gruß, Waldemar

P.S.: Es gibt auch noch einen technischen Grund, warum ich das nicht im Sensormodul machen kann: Ich habe keine weiteren KO mehr frei und neue KO würden alles inkompatibel machen, was ich bisher erreicht habe. Und die abstrakte Formel im Logikmodul kann man auch für viele andere Sachen nutzen.

[stmeyer]

Und wieviele Tanks haben eine Quader-Form...

Deswegen habe ich auch geschrieben, dass man die Grundfläche eingeben soll und nicht Länge und Breite oder Durchmesser, etc. Natürlich klappt das nicht, wenn man eine „liegende tonnenförmige“ Zisterne hat, aber die Anwender können dann immer noch die Füllhöhe nutzen damit rechnen.
Aber nahezu alles was gemauert/gegossen ist wäre wie vorgeschlagen umsetzbar.

Viele Grüße
Stefan

[starwarsfan]

Dazu braucht man dann natürlich noch die Grundfläche des Tanks, die man dann in der Applikation oder direkt im Quellcode vor dem Kompilieren eintragen könnte…

Und wieviele Tanks haben eine Quader-Form, bei der das dann auch passt? Eher wenige vermutlich. Meine Zisterne jedenfalls nicht...

[stmeyer]

Hi Stefan,

da muss ich wohl nochmal ran . …

Hi Waldemar,
mir ist noch was eingefallen, vielleicht passt das in Dein Konzept:
Die Entfernungsmessung wird ja vermutlich hauptsächlich zur Füllstandsmessung genutzt. Wäre es möglich in der Applikation ein zusätzliches KO einzuführen, das den Füllstand in Litern (schwankt dann wahrscheinlich sehr) und m^3 ausgibt?
Dazu braucht man dann natürlich noch die Grundfläche des Tanks, die man dann in der Applikation oder direkt im Quellcode vor dem Kompilieren eintragen könnte…

Dies soll jetzt aber kein Drängeln sein irgendwas an der Firmware bzgl. des ToF-Sensors zu machen. Ich bin mit dem jetzigen Zustand schon ganz zufrieden und kann die Umrechnung einfach über NodeRed machen. Ich finde es halt super, wenn möglichst viel in Knx gemacht wird und die Hütte nicht von zusätzlichen Diensten (die nach mir vermutlich niemand mehr pflegt/betreibt) abhängig ist.

Viele Grüße
Stefan