Alternative Firmware für das Raum-Sensormodul von Masifi

[jgerhart]

Hallo Waldemar,
ich bin auch dafür, die Temperatur ohne die genannten Offsets auszugeben.
Wenn die Kalibrierungswerte noch in den Sensor geschrieben werden, um so besser, da die relative Luftfeuchtigkeit dann korrekt angepasst wird.
Bei meinem BME680 habe ich bei Temp und Hum mit 3.6 bisher keine 0 oder negativen Werte gesehen.
Ich verwende für die Datenspeicherung jetzt eine Influx-DB. Im Gegensatz zur MariaDB, die ich vorher genutzt habe, muss man die Datenfelder nicht definieren und es ist sogar eine grafische Auswertung dabei, d.h. ich kann damit auf Grafana verzichten. Über Node Red lese ich die KNX-Werte und speichere sie in der DB.
Gruß,
Jens

[mumpf]

Hi jgerhart et all,

ausgehend von Deinem Post im Hardware-Thread (https://knx-user-forum.de/forum/öffentlicher-bereich/knx-eib-forum/diy-do-it-yourself/1479195-raum-sensormodul-hw-thread-für-temp-hum-pres-voc-co2-1-wire-buzzer?p=1690779#post1690779) und ausgelöst durch die Suche nach 0-Werten bin ich über eine Coding-Stelle beim BME280 und BME680 gestolpert, die mir jetzt peinlich ist, die aber derzeit so in der Firmware ist:

        // hardware calibration  BME280
        return readTemperature() - 2.0f;

        // hardware calibration BME680
        return Bsec::temperature - 3.5f;

Das ist noch aus der Anfangszeit, als ich keine Kalibrierung in der Firmware hatte und versucht hatte, die beiden Sensoren auf einen Referenzwert zu bringen, um die Linearität bei Erwärmung/Abkühlung zu untersuchen.

Somit gibt der BME280 derzeit 2K und der BME680 3.5K weniger als gemessen aus. Ich würde das gerne aus der Firmware entfernen, da ja die Kalibrierung jetzt in der Applikation möglich ist. Ferner würde ich die Kalibrierungswerte gerne in den Sensor schreiben, da dann Luftfeuchte und Luftdruck korrekter berechnet werden.

Warum ich das hier erwähne: Mit der nächsten Firmware würden sich die gemessenen Temp-, Hum- und Pressure-Werte nochmal deutlich ändern (aber korrekter sein). Je nachdem, welche Steuerung/Regelung ihr in Abhängigkeit von den Werten implementiert habt, müsste man da nochmal ran. z.B. indem man bei der Kalibrierung in der Applikation entgegensteuert.

Ich bin fest der Meinung, dass das "richtiger" wäre, aber falls jetzt alle sagen, "nee, auf keinen Fall", dann kann ich das natürlich auch sein lassen. Ist leider blöd gelaufen, ich hab das Coding einfach schon lange nicht mehr angefasst und deswegen komplett vergessen.

Gruß, Waldemar

[mumpf]

Danke erstmal für das Feedback.

Ich habe inzwischen aber selber gemerkt, dass irgendwo intern doch noch ein 0-Wert existiert. Beim Taupunkt gibt es Ausreißer ins Negative. Und da der Taupunkt aus Temp und Hum berechnet wird, war wohl einer von beiden negativ. Ich beobachte/suche weiter...

Du kannst übrigens die 3.6 auf die anderen Geräte spielen. Die ETS-Applikation ist Upgrade-Fähig (sprich: Parameter und GA bleiben erhalten). Besser als vorher ist es auf jeden Fall.

Gruß, Waldemar

[jgerhart]

Also bei mir sind seit dem Update auf 3.6 am 27.09. keine 0-Werte mehr aufgetaucht. 👍
Zwei andere Module mit Version 3.1 melden weiterhin alle 1-2 Tage sporadische 0-Werte.

[mumpf]

Hi,

kurzes Update über einen wichtigen Test, den ich heute gemacht habe: Meine Applikation lässt sich auch in die ETS 6 importieren. Ich hab zwar noch keinen Programmierversuch unternommen, aber da hab ich keine Befürchtungen.

Achtung: Auf unbestimmte Zeit ist noch eine ETS >= 5.6 erforderlich, um die knxprod zu erzeugen. Wobei eine Demo reicht. Also falls ihr ein upgrade auf die 6 macht, bitte nicht die Setup-Datei von der ETS5 löschen. Und man kann ja beide auf dem gleichen Rechner installiert haben.

Gruß, Waldemar

[mumpf]

Mal sehen, ob die 0-Werte jetzt weg sind...

Das ist ein erster Versuch, ich hoffe, dass es hilft.

Ich habe jetzt erstmal meinen SCD41 mit BME680 in der Küche aufgehängt, zusammen mit Buzzer und RGB-LED (Stromampel für PV-Nutzung, Buzzer für akustisches Feedback von gesperrten Aktionen). Bastle gerade an der Datenaufzeichnung und einer passenden Grafana Darstellung der Messwerte, will damit einen Algorithmus für den Dunstabzug entwickeln, der nicht nur von dem Stromverbrauch des Kochfelds, sondern auch von der Dampf/Geruch abhängt, den das Kochen verursacht.

Ich denke, in dem Zusammenhang werden dann auch 0-Werte auffallen, falls sie auftreten und ich hab mal eine etwas komplexere Testumgebung.

Wollte damit nur kundtun, dass ich auch selber das konsumiere, was ich euch "antue", so dass auch mir nach und nach Fehler auffallen dürften, die ich noch korrigieren muss.

Gruß, Waldemar

[jgerhart]

Hallo Waldemar,
vielen Dank für die neue Beta. Ich habe die neue Firmware und ETS-Applikation 3.6 jetzt im Einsatz mit SCD41 und BME680. Mal sehen, ob die 0-Werte jetzt weg sind...
Gruß
Jens

[mumpf]

Hi allerseits,

wie versprochen habe ich soeben eine Beta v3.6 freigegeben. Folgende kleine Ergänzungen sind gegenüber der 3.3 hinzugekommen:

• Bugfix: Die ETS-Applikation hatte für Logikeingänge die Einstellungen zum "Zyklisch lesen" und "Startwert vorbelegen" nicht mehr angezeigt.
• Feature: Wenn man eine RGB-LED als Signalgeber benutzt, kann es passieren, dass man die einzelnen Farbanschlüsse der LED nicht mit den gleichen Lötpads verbindet wie in meiner Testumgebung. Das Ergebnis wäre dann, dass ein in der Logik eingestelltes "rot" vielleicht "grün" oder "blau" leuchtet, bei Mischfarben wird es noch unübersichtlicher.
  Jetzt kann man bei den Experteneinstellungen für die RGB-LED angeben, welche Farbanschlüsse mit welchen Lötpad verbunden sind, dann kommen auch die Farben korrekt raus.
• Ich habe in dieser Version einen ersten Versuch unternommen, sporadisch gesendete 0-Werte bei Sensoren (vor allem BME680) zu verhindern. Es wäre schön, wenn ihr mal bei Gelegenheit schauen könntet, ob das erfolgreich war. Langzeittest steht bei mir noch aus.
• Der Versionssprung von 3.3 auf 3.6 ist der Versionierung der ETS geschuldet, es sind wirklich nur kleine Änderungen enthalten.

Ich würde empfehlen, das Update einzuspielen, INCLUSIVE der ETS-Applikation, sonst passen ETS und Firmware womöglich nicht zusammen. Ich weise mal wieder darauf hin, dass meine ETS-Applikationen updatefähig sind. Wie das geht, ist in der Anleitung beschrieben.

Gruß, Waldemar

[mumpf]

Hi Mat,

sorry, sollte kein Vorwurf sein, falls das so ankam. Ich freue mich ja, wenn ich Platinen gleich testfertig bekomme. Ich will nur erreichen, dass ein "violett" bei mir in der Logik auch als violett rauskommt . Ich teste aber gerade das Mapping in der Software, war nicht so viel Aufwand. Und da ich ja bereits einen Fehler in der ETS-Applikation hatte und somit sowieso eine neue Applikation bauen muss, kann ich auch einen weiteren Parameter hinzufügen.

Ich wollte auch nicht, dass Du was am HW-Layout änderst, das mit dem Aufdruck kannst Du Dir überlegen. Aber eigentlich ist es nicht nötig, ich werde es wie gesagt in der Doku beschreiben und in der ETS-Applikation ein Mapping zulassen.

Gruß, Waldemar

[Masifi]

Das stört mich jetzt nicht, da jeder die LEDs eh selber anschließen muss und das kann man dann machen wie man will.
Du hast ja eine Platine RGB LED bekommen, die Ausgänge dort heißen wenn ich mich nicht irre eh nur LED1 bis LED3. Daher habe ich wahrscheinlich nur die LED falsch herum bestückt
Im HW Layout kann ich hier eh nichts ändern, außer den Bestückdruck mit R G B erweitern.

[mumpf]

Das mit den Logiken sieht gut aus, es war wirklich nur ein Fehler in der Applikation.

Ich habe aber festgestellt, dass beim LED-Treiber (von Mat für mich netterweise gleich mit LED ausgeliefert, damit ich sofort testen kann) die LED anders verlötet hat, als bei dem ersten Gerät vor 2 Jahren (mann, ist das schon lange her). Grün ist zwar noch grün, aber rot und blau sind vertauscht. Ist blöd, wenn ich in der ETS eine Farbauswahl per Dialog erlaube und die Farben dann gar nicht stimmen.

Hier gäbe es die Hardware-Lösung (genaue Anleitung, an welchen Pin welches LED-Beinchen angelötet werden muss, damit die Farben stimmen) oder entsprechend die Software-Lösung, bei der man in der Applikation sagt, welcher Pin welches LED-Beinchen bekommen hat. Ich schau mir mal die Software-Lösung an...

Gruß, Waldemar

[mumpf]

So, den Fehler hab ich schon mal gefunden. War ein Seiteneffekt der Implementierung von Benutzerformeln. Ich werde jetzt trotzdem noch am Wochenende einige Logiken bauen, um zu checken, ob sonst alles korrekt ist.

Spätestens Sonntag Abend gibt es eine neue Version, hier ist vor allem die Applikation wichtig.

Gruß, Waldemar

[mumpf]

Hi allerseits,

hier schon mal der erste grobe Fehler: Ich habe mich so sehr auf die Sensoren und 1-Wire konzentriert, dass ich die Logik vernachlässigt habe. In der Beta-3.3 kann man leider in der Applikation die Logikeingänge nicht mehr parametrisieren. Ich such mal den Bug...

Also: Für alle, die Logiken nutzen, ist die Beta-3.3 noch nicht zu empfehlen.

Gruß, Waldemar

[jgerhart]

Hab gerade nachgeschaut. Heute Nachmittag hatte ich einen 0°C Wert von einem BME680 (Beta 3.1). Alle Glättungen sind mit "1" konfiguriert, d.h. Glättung ausgeschaltet?

[mumpf]

Hi, ich wusste, dass das kommt.

Die Ursache habe ich nicht gefunden, aber ich habe einen generischen Filter für inkorrekte Werte gebaut. Dieser verhindert, dass falsche Werte auf den Bus gesendet werden. Falsch sind alle Werte, die entstehen, wenn z.B. der Sensor mit einer Fehlermeldung antwortet oder noch nicht initialisiert ist. Bei 1-W wird das schon intensiv genutzt, beim SCD41 hab ich es auch eingebaut, für die alten Sensoren noch nicht. Das mach ich auf jeden Fall als nächstes für den BME680 und die anderen Sensoren und hoffe, dass es hilft.

Nur nochmal zur Erinnerung für mich: Das passiert doch nur, wenn man die "Glättung" einschaltet, oder?

Gruß, Waldemar