Alternative Firmware für das Raum-Sensormodul von Masifi

[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

[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

[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]

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

[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

[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]

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

[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

[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 allerseits,

mal wieder kurzer Zwischenstand:

• Beim BME280 wird der Temperaturoffset jetzt im Sensor berechnet, das funktioniert.
• Beim BME680 hab ich das auch versucht, danach verhält sich der Sensor sehr seltsam (eine Änderung um ca. 5-8 K - also einfaches anfassen) dauert ca. 15 Minuten (!), sonst eher so 1-2 Minuten. Ich werde diese Änderung wieder ausbauen.
• Beim SCD41 hat das ja schon von Anfang an funktioniert.
• Beim SCD30 will ich auch gleich die benutzte Library auf die neueste Version bringen, in der Hoffnung, dass so die Hänger, die bei dem Sensor (als einzigem) passieren, dann verschwinden. Deswegen hier noch kein Zwischenergebnis.
• Der SHT3x unterstützt das nicht, somit wird weiterhin in Software kompensiert.

Ich lasse das jetzt mal bis zum WE laufen und beobachte weiter und würde dann nochmal ein Update rausbringen (noch ohne SCD30), wenn es keine Probleme gibt.

Gruß, Waldemar

P.S.: Der SCD41 hatte bisher noch keine Hänger, toi toi toi. Alleine das spricht für ihn (statt dem SCD30).

[mumpf]

Hi,

wollte hier eine Erkenntnis teilen, die mich die letzten 3 Tage rumtesten gekostet hat:

Wenn man den BME680 (und es geht nur um diesen) wechseln möchte (also z.B. weil der alte Kaputt ist oder weil man 2 Sensormodule hat und sich entscheidet, dass doch das 2. Sensormodul den BME680 bekommen soll), dann MUSS man VORHER die Kalibrierungsdaten löschen. Ich hab immer gedacht, dass das auch hinterher geht, aber das klappt nicht.

Was heißt VORHER Kalibrierungsdaten löschen?

• Solange noch der ALTE Sensor drauf ist, in der Applikation unter Zusatzfunktionen->Kalibrierungsdaten löschen den Wert 17 oder 23 auswählen
• Es ist egal, welcher Wert, es muss nur der andere als der Ausgewählte sein
• Programmieren drücken
• Wenn im Gruppenmonitor der erste Temperaturwert gesendet wurde, das Modul vom Bus nehmen und den neuen BME680 anbringen
• Modul wieder an den KNX bringen und zur Sicherheit nochmal Kalibrierungsdaten löschen (hat bei mir aber auch ohne geklappt)

Falls ein Wechsel ohne Löschen von Kalibrierungsdaten erfolgt ist, können folgende Symptome auftreten:

• An sich sieht alles gut aus und der Sensor liefert auch Werte
• Allerdings kommen intern neue Werte nicht alle 5 Sekunden, sondern eher alle 30-300 Sekunden
• Die Messkurven sehen sehr "geglättet" aus, es gibt keine raschen Temperaturschwankung

Um das dann zu beheben muss das Sensormodul komplett neu mit der Firmware über USB programmiert werden, dann normal mit der ETS (PA+Applikation) programmiert werden. Und natürlich dann schon mit dem neuen BME680...

Warum erkenne ich das erst jetzt:

• Ich habe recht viele Module, aber selbst dann entscheidet man sich normalerweise für eine Konfiguration eines Moduls und belässt diese dann wie sie ist.
• Ich muss zu Testzwecken manchmal die Sensorkonfiguration ändern und neue Kombinationen ausprobieren
• Dabei ist mir die seltsam "glatten" Temperaturkurven aufgefallen
• Normalerweise sollte das bei euch nicht auftreten, aber falls einer doch wechseln will, dann besser wie oben beschrieben.

Warum passiert so was nicht bei gekauften Geräten von Herstellern:

• Da kann man normalerweise keine Sensoren einsetzen, wechseln oder konfigurieren.
• Meist heißt es da: Sensor kaputt -> Gerät kaputt
• Falls doch ein Sensorwechsel durch den Service vorgenommen wird, macht der auch die Kalibrierung

Hintergrund:

• Der BME680 kalibriert sich quasi dauernd im laufenden Betrieb selbst.
• Die Kalibrierungsdaten gehen bei jedem Neustart verloren
• Man kann den Sensor aber nach Kalibrierungsdaten fragen und diese dann im nichtflüchtigen Speicher speichern.
• Das Sensormodul macht genau dies, wobei es nur neue Kalibrierungsdaten speichert, wenn sich diese im Vergleich zu alten geändert haben
• Beim Neustart des Moduls werden die Kalibrierungsdaten wieder in den Sensor geschrieben und so ist er quasi auf dem Stand vor dem Neustart
• Was genau in den Kalibrierungsdaten steht, kann ich nicht sagen, es ist nur ein ca. 400 Byte großer Bytestream
• Scheinbar vertragen sich die Kalibrierungsdaten verschiedener BME680 nicht
• Werden also beim Neustart die Kalibrierungsdaten eines "alten" BME680 in einen "neuen" BME680 geladen, kommt es zu dem komischen Verhalten
• Warum allerdings "Kalibrierungsdaten löschen" nicht ausreicht, um das zu beheben, sondern eine Neuprogrammierung per USB notwendig ist, kann ich nicht sagen und verstehe ich auch nicht.

Ist sicherlich ein in der Praxis selten auftretender Fall, aber falls ihr nach einem Sensorwechsel irgendwie merkt, dass der Sensor irgendwie träge misst, dann einfach alles komplett neu programmieren und es geht wieder alles.

Gruß, Waldemar

Vergesst das, was ich oben geschrieben habe. Nach 2 weiteren Tagen "rumsuchen" weiß ich immer noch keinen Grund, warum der BME680 so träge in seinem Verhalten wird. Es ist ja nicht so, dass er nicht funktioniert... Das oben beschriebene Verfahren klappte für 2 Sensoren, für einen 3. und 4. dann nicht mehr.

Ich habe jetzt die neueste Version der Bosch-BME-Library versuchsweise eingebunden, mit den aktuellsten Parametersets zur Initialisierung des BME680, der erste Versuch sieht gut aus. Jetzt folgen einige intensive Tests. Das ist auch der Grund, warum die nächste Beta frühestens kommendes Wochenende kommt.

Gruß, Waldemar

[mumpf]

Hi,

ich bin letztens von einem Freund gefragt worden, ob er mal zuschauen könnte, wenn ich eine Logik mit meinem Logikmodul entwickele, da er als visueller Mensch dabei eher lernt als durch reines Doku-Lesen, außerdem kann er dann Fragen stellen, wenn er was nicht versteht.

In diesem Zusammenhang wollte ich mal hier in die Runde Fragen (zumindest diejenigen, die meine Firmware verwenden): Hättet ihr denn Interesse an einem 1-2 Stündigen "Workshop", bei dem ich mal online zeige, wie ich bei Logikentwicklung vorgehe? Ich hätte da 1 oder 2 Beispiele, die nicht komplett 0815 sind und sich gut zeigen lassen. Wäre abends mal eine Online-Session. Keine Hochglanz-Demo, sondern von 0 angefangen und so lange iterativ die Logik entwickeln, bis sie läuft. Dann kann man auch gut sehen, wie man die ETS zum testen verwenden kann.

Die beiden Beispiele, die mir vorschweben (weil sie klein genug sind, um die Übersicht zu behalten und kompliziert genug, um mal das einfache UND-ODER-NICHT von Logiken zu verlassen):

1. Spiegelheizung im Bad (nur einschalten, wenn der Spiegel wirklich beschlägt)
2. Fensterkontakte: Aus 2 Kontakten (offen/zu; gekippt/nicht gekippt) die Werte 1=geschlossen; 2=gekippt; 3=offen bekommen

Schreibt doch mal hier, ob Interesse besteht, je nach Feedback kann ich ja mal was aufsetzen.

Gruß, Waldemar

[stmeyer]

Hi Waldemar,
ich habe da auf jeden Fall Interesse und wäre auch gerne bei so einem workshop dabei.

Viele Grüße
Stefan

PS: Schaust Du Dir bei Gelegenheit auch nochmal Deine Glättungsfunktion in der Firmware an bzw. die Ausreißer bei dem TOF-Sensor?

[Masifi]

Ich bin auch dabei

Dafür das wir schon soo lange zusammenarbeiten, habe ich dein Logikmodul bis jetzt nur sehr einfach genutzt. Über etwas UND und ODER bin ich noch nicht hinausgekommen

[jeff25]

Hi Waldemar,

wäre auch sehr gerne dabei.

gruß
robert