Alternative Firmware für das Raum-Sensormodul von Masifi

[ReinerDaniel]

Hallo Waldemar,

habe jetzt vier Module mit Watchdog ausgestattet und logge die Werte. Vielleicht kann man anhand eines kurzen Ausfalls erkennen, wenn der Watchdog aktiv war.
Werde berichten, was ich zu beobachten habe.
Viele liebe Grüße und geruhsame und gesunde Osterferien.
Matthias

[mumpf]

Hi allerseits,

hier mal eine Vorab-Info: Ab der Applikations-Version 3.0 und höher wird es nur noch eine knxprod geben und nicht mehr 4 Stück mit 10, 20, 40 und 80 Kanälen. Natürlich wird die eine knxprod 80 Kanäle enthalten. Folgende Gründe machen das möglich (und erforderlich):

• Ich habe mich durch den Long-Frame-Support durchgekämpft und der funktioniert jetzt. Eine 80-Kanal-Programmierung dauert jetzt so lange wie früher 20 Kanäle.
• Ich habe erste positive Tests mit partieller Programmierung machen können. Wenn man nur ein paar Parameter ändert (was beim austesten von Logiken häufig passiert), dauert die Programmierung weniger als 15 Sekunden.
• Das Verwalten der verschiedenen Update-Pfade von 4 alten Applikationen auf 4 neue Applikationen ist ehrlich gesagt die Hölle... und verstanden haben es die meisten auch nicht. Nur eine knxprod macht das wesentlich einfacher
• Die ETS kann damit auch nicht besonders gut umgehen, dass ich verschiedene Applikationen für verschieden viele Kanäle mache
• Für mich was die lange Programmierzeit überhaupt erst der Grund, warum ich unterschiedlich große Applikationen eingeführt habe. Da die Zeit jetzt drastisch gesunken ist, entfällt der Grund.

In Zukunft wird man das erste Mal vollständig übertragen müssen, und falls man keine Schnittstelle mit long frame support hat, dauert das dann halt. Weitere Übertragungen können dann über partielle Programmierung erfolgen. Das geht in den meisten Fällen rasend schnell. Manchmal passt die ETS die interne Speicherstruktur an, dann wird wieder vollständig übertragen, aber das entscheidet die ETS selbst und man merkt es dann an der langen Übertragung.

Das nur zur Vorab-Info, für mich ist das eine große Arbeitsersparnis und für euch wird das Handling einfacher. Und das Programmieren wird schneller, also haben alle was davon. Kleiner Wehrmutstropfen bei der Sache: Ich wollte eigentlich schon Ende März mit einer v3.0 beta rauskommen (Mit 1-Wire-Unterstützung), das verzögert sich bis nach Ostern, also ca. 1 Woche bis 10 Tage.

Gruß, Waldemar

[mumpf]

Alles klar. Normalerweise lasse ich Änderungen erst eine Zeit lang bei mir laufen, aber da ein Watchdog ja Hänger eher verschleiert, bringt das nicht wirklich was. Ich bin ja eher daran interessiert, keinen Watchdog zu brauchen.

Um Missverständnisse zu vermeiden: Der Watchdog ist getestet und funktioniert, es gibt nur keinen Langzeittest, den wirst Du machen dürfen....

Ich habe derzeit auch noch keine Möglichkeit eingebaut, um festzustellen, ob bzw. wie häufig der Watchdog zugeschlagen hat. Allerdings plane ich, das mal im Diagnosemodul abfragbar zu machen.

Gruß, Waldemar

[ReinerDaniel]

Man bist Du schnell Waldemar; werde ich sobald ich dazu komme installieren und dann berichten.
Liebe Grüße
Matthias

[mumpf]

Hi allerseits,

soeben habe ich das Firmware-Release 2.5 freigegeben. Das enthält keine neue knxprod, kann also einfach auf das Sensormodul aufgespielt werden. Ihr braucht knx, knx-logic und knx-sensor, es schadet aber nichts, wenn knx-common auch geholt wird. Es sind nur kleine Korrekturen, manche aber mit großer Wirkung:

• Man kann jetzt einen Watchdog aktivieren. Der Vorgang ist ist in knx-dev-setup.pdf bzw. knx-update-setup.pdf beschrieben (beide im doc-Folder zu finden). In der Applikationsbeschreibung habe ich auch was zum Watchdog und zu seinen Vor- und Nachteilen geschrieben. Empfehlen würde ich den Watchdog derzeit beim SCD30, zumindest solange, bis ich die Ursache für die sporadischen "Hänger" gefunden habe.
• Es ist jetzt auch der Long-Frame-Support eingebaut. War eigentlich für 3.0 geplant, aber das ist so viel schneller, dass ich es euch nicht vorenthalten wollte. Man kann die komplette Applikation jetzt 2-3 mal schneller übertragen, das ist schon deutlich zu merken. Natürlich muss die Programmierschnittstelle das auch unterstützen und auch alle LK, die auf dem "Programmierweg" liegen. Ihr müsst dafür nichts tun, die ETS erkennt das automatisch und programmiert so schnell es geht.
• Ein kleiner Bug in der Logik ist auch noch beseitigt: Wenn man das "Blink-Modul" bei einem Logikausgang verwendet hat, wurden zu viele Eingangs-Trigger durchgereicht. Hat bisher noch keiner gemerkt (ich vorher auch nicht) und ist auch keine Elementare Funktion der Logik, ist aber jetzt korrigiert.

Wegen Long-Frame-Support kann ich das Update nur empfehlen, zumindest wenn man das Modul immer wieder mal programmiert. Watchdog würde ich nur machen, wenn man den SCD30 nutzt oder wenn man gelegentliche Hänger hat (die dann aber unbedingt hier melden). Wegen der Logikkorrektur alleine würde ich jetzt kein Update machen, sondern auf die nächste (größere) Version warten, bei der man dann auch den Watchdog in der Applikation einstellen können wird.

Gruß, Waldemar

[st400]

Die Platinen für das Außengehäuse hatte ich bisher nicht auf dem Schirm. Habe mal bei Matthias angefragt 😉.

[mumpf]

Hi Stefan,

Du kennst schon dieses Modul von Masifi? 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=1612101#post1612101

Mit den passenden Gehäuse? 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=1543849#post1543849

Ich hab das hier liegen, sieht sehr gut aus. Allerdings muss man sich für den VL53L1X noch was mit dem Deckel überlegen. Ich will versuchen den so zu kalibrieren, dass er durch einen Mikroskop-Objektträger von ca. 0.5mm Dicke möglichst ohne Verluste hindurch messen kann. Wenn das klappt, dann muss man sehen, wie man den Deckel präparieren kann, so dann das mit dem Objektträger kombiniert werden kann. Und dann wäre das Ganze sogar wasserdicht.

Aber das ist noch alles Zukunftsmusik, die naheliegenden Sachen sind:

• Watchdog, um einen Bugfix für den SCD30 zu liefern
• 1-Wire-Release
• OPT300x (Helligkeit) für den Außensensor
• VL53L1X (Entfernung) für Tanks/Zisternen
• Sicherlich noch haufenweise Bugfixes für 1-Wire

Gruß, Waldemar

[st400]

hi Waldemar,

das mit dem Watchdog ist natürlich elegant, wenn das direkt die Hardware mitbringt. Jetzt überlege ich ob man somit auch einen deadlock loggen bzw. auf dem Bus schreiben könnte. Man müsste also beim PowerOn (oder später) feststellen können ob es ein Kaltstart war oder per Watchdog initiiert.

Ja genau ich will mit dem Ultraschallsensor Entfernungen messen. Konkret geht es um den Füllstand einer Zisterne. Das sollte ja auch mit dem VL53L1X gut machbar sein. Wäre dann wohl eher die Frage ob die Hardware (sowohl Sensor als auch Modul) mit den Temperaturen und Feuchtigkeit dauerhaft klarkommt.

Dass das nur ein Hobby ist ist klar und ich würde nie verlangen das dieses und jenes implementiert wird. Finde es ja generell super das du deine Arbeit hier teilst 👍 und kann sicher nur erahnen wie viel Zeit in solch ein Projekt fließt. Wenn ich einen neuen Sensor nutzen wollen würde, würde ich auch versuchen das selbst zu implementieren (oder es zumindest versuchen 😉).
Was die Elektronik angeht, da geht es mir wie dir. Da fühle ich mich in der Softwarewelt wohler, allerdings (zumindest noch) nicht in der Mikrocontrollerprogrammierung 😀.

VG Stefan

[mumpf]

Hi Stefan,

glücklicherweise hat der SAMD21 schon einen Watchdog eingebaut. Man muss den nur korrekt parametrieren und verwenden. Im Prinzip ist das ein nachtriggerbares Zeitglied (im KNX würde man das "Treppenlicht mit Verlängerung" nennen). Man sagt dem Zeitglied z.B. nach 15 Sekunden machst Du ein Reset. Dann schaltest Du es ein und verlängerst so oft Du kannst (bei mir üblicherweise alle 5 Mikrosekunden und falls es mal länger dauert, dann so 10 Millisekunden). Dann läuft das so vor sich hin, bis mal der Prozessor hängt, warum auch immer. Dann wird die Verlängerung nicht mehr angesprochen, die 15 Sekunden vergehen und ein Reset kommt. Der Prozessor startet neu und macht all die Sachen, die sonst auch beim Neustart kommen (also bei PowerOn, nach dem Programmieren, nach einen "Gerät neustarten" oder nach dem Drücken der Reset-Taste). Im Rahmen dieser Initialisierung wird wieder das Zeitglied auf 15 Sekunden gesetzt, gestartet und andauernd verlängert...

Zur Hardware: Ich bin da ein totaler "Versager", da musst Du Dich an Matthias wenden, er schätzt das alles ab (Stromverbrauch, parallele Nutzung mit anderen Sensoren, Größe (damit es noch in die Unterputzdose passt) usw. Falls es um Entfernungsmessung/Füllstandsmessung geht, werden wir sehr bald (lief schon mal kurz testweise bei mir) den VL53L1X unterstützen, der kann Entfernungen bis 4 m (in dunkler Umgebung) messen, macht das aber per Laserstrahl. Oder gibt es einen anderen Grund für Ultraschall?

Ich habe die Sensoren in der Firmware eher nach den Messwerten klassifiziert, also

• Temperatur
• Luftfeuchte
• Luftdruck
• VOC
• CO2
• Helligkeit
• Entfernung

Da das bei mir bitweise verwaltet wird und es erst 7 Klassen sind, hätte ich noch eine Klasse frei... Aber Ultraschallsensoren sind - soviel ich weiß - alle für Entfernungsmessungen gedacht, wäre also keine neue Klasse.

Achja, dann ist es noch so, dass ich das als Hobby mache und bereits eine lange Liste von Verbesserungen habe, die noch notwendig sind, damit das in meinem Haus laufen kann, insofern reiße ich mich auch nicht um die Implementierung von weiteren Sensoren... Aber wenn es einen guten Grund gibt, kann man zumindest drüber reden.

Gruß, Waldemar

[st400]

hi mumpf,

wie funktioniert das denn eigentlich mit dem Neustart, wenn die Firmware im Deadlock festhängt? Geht das per Interrupt o.ä.? Ich habe leider von Mikrocontroller keine Ahnung, finde das Thema aber super spannend.

Was mich auch interessieren würde: wäre auch die Anbindung eines Ultraschallsensors wie z.B. der HC-SR04 denkbar?

PS: Super Arbeit die du da mit der Firmware umgesetzt hast.
VG Stefan

[mumpf]

Hi Matthias (und nicht Reiner - sorry, Dein Username hat mich in die Irre geführt),

das Blinken alle 2 Sekunden ist normal. Ich hatte Dich erstmal so verstanden, dass diese LED dauerhaft an geblieben ist. Das wäre was neues gewesen.

Wie gesagt, ich mach mich an die Ursachensuche, aber das wird dauern. Bei Deinem Setup wird aber auch der Watchdog helfen. Und wie gesagt, Du kannst auch mal checken, ob ein tägliches Zurücksetzen des Moduls helfen würde. Das einzige, was bei Dir auffällig ist, ist die Häufigkeit der Ausfälle: Meine Hänger passierten eher nach Wochen, nicht nach Tagen.

Gruß, Waldemar

[ReinerDaniel]

Hallo Waldemar,
vielen Dank für Deine lange email. Ist natürlich völlig in Ordnung; keine Eile.
Ich habe noch mehr Module fertig und wollte das Modul auch einfach einmal tauschen; nicht das es eine kalte Lötstelle oder so ist.
Würde dann ein anderes Modul genauso parametrieren und mal abwarten, was passiert.

> Matthias: Ja, ich meine die gelbe LED am SCD30. Diese blinkt alle 2 sec. Heißt für mich, die Platine bekommt Strom und misst auch, oder?
Das langsame Aufblinken alle zwei sec. ist doch normal bei der SCD30, oder?
Gruß Matthias

[mumpf]

Oh,

das wäre ein Symptom, dass ich noch nie gesehen habe! Die Sensor-LED ist ja für den Messvorgang selbst vorgesehen, die kontrolliere ich natürlich nicht. Und ich kann mir auch nicht vorstellen, warum das passiert. Insofern wäre das eine wichtige Info!

Gruß, Waldemar

[Masifi]

Die gelbe LED am SCD30 leuchtet.

mumpf ich denke er meint die gelbe LED die bei jedem Messvorgang am SCD30 leuchtet und nicht die LED auf dem Sensormodul.
ReinerDaniel Sehe ich das mit der LED richtig? leuchtet diese LED wirklich dauerhaft, oder blinkt sie alle 2sek?

[mumpf]

Hallo Reiner,

ok, SCD30 alleine hat bei mir keine Probleme gemacht. Die Hänger, die ich hatte, waren nur in Verbindung mit dem BME680. Allerding muss ich gestehen, dass ich im letzten halben Jahr mich so sehr auf 1-Wire konzentriert habe, dass ich die Sensoren etwas aus dem Fokus verloren habe. Ich kann Dir eine kurzfristige Lösung anbieten, die langfristige wird - wie der Name schon sagt - länger dauern.

• kurzfristig: Ich werde einen Watchdog implementieren. Das ist eine Schaltung, die Prozessorintern feststellt, dass er sich aufgehängt hat und dann den Prozessor neu startet. Ich habe das schon mal ausprobiert, es funktioniert auch, nur kann man damit nicht debuggen. Außerdem bekommt man mit einem Watchdog genau solche Hänger nicht mehr mit, wodurch meine Tests ja nicht aussagekräftig wären. Deswegen ist der Watchdog nicht in der Firmware drin, aber für "Enduser" macht der durchaus Sinn.
• langfristig: Ich werde ein Testmodul wieder mit dem SCD30 konfigurieren und schauen, ob bzw. wann der Fehler bei mir auftaucht, muss mir aber vorher überlegen, wie ich solche sporadischen Fehler überhaupt analysieren kann, wenn sie nach 2 Tagen (oder 2 Wochen oder 2 Jahren) auftauchen. Denn wenn sich das Modul aufgehängt hat, komme ich ja auch nicht mehr dran. Ich habe da Ideen, die erfordern aber noch einige Programmierarbeit (Ringpufferspeicher im EEPROM und passendes Logging mit "möglichst selten in EEPROM schreiben").

Für den Watchdog werde ich noch ca. 1 Woche brauchen, ich muss das alte Coding nochmal ausgraben und an die aktuelle Firmware anpassen. Es wird eine neue Compiler-Option geben, um den Watchdog einzuschalten. In einer zukünftigen ETS-Applikation kann ich mir auch vorstellen, dass ich das von da aus schaltbar mache, aber auch die ETS-Applikationen machen viel Arbeit, ist somit nichts für kurzfristige Lösungen.

Nochmal eine allgemeine Anmerkung zum Watchdog: Für reine Sensoren sind Watchdogs eine gute Lösung, um Hänger zu vermeiden. Ein solcher Neutstart geht schnell und der Sensor liefert wieder seine Werte. Das Einzige, was auffällt: Nach dem Neustart kommt ein Messwert außer der Reihe, also z.B. schon nach 2 Minuten und erst dann wieder alle 5 Minuten. Halte ich gegenüber einem Hänger (also keine Werte) für vertretbar.

Wenn man Logiken nutzt, muss man diese so aufbauen, dass sie stabil gegenüber einem Neustart sind, der ja jederzeit vorkommen kann. Keiner will mitten in der Nacht vom Buzzer geweckt werden. Das Logikmodul erlaubt sehr viele "Startup-Einstellungen", um das möglichst feingranular steuern zu können. Allerdings muss man das auch machen! Wenn man also Logiken macht und den Watchdog benutzt, muss man die Logiken nicht nur auf Funktion, sondern auch auf Neustartverhalten testen. Der komfortabelste Weg hier ist in der ETS "Gerät zurücksetzen". Man kann diesen Befehl aber auch über eine Logik auslösen und z.B. auf eine Taste legen. So kann man in der Testphase jederzeit spontan das Gerät zurücksetzen und sehen, ob es Seiteneffekte bei Neustart gibt.

Das was der allgemeine Teil... für Dich, Reiner, heißt das:

• Ich muss Dich bitten, auf die Watchdog-Lösung zu warten. Ich rechne mit ca. 1 Woche (also grob Ostern).
• Du könntest als Workaround versuchen, das Modul per Zeitschaltuhr 1 mal nachts zurückzusetzen und so neu zu starten. Alles notwendige liefert das Modul selbst (Stichworte: Zeitschaltuhr, Ausgang sendet "Gerät zurücksetzen", PA vom Modul selbst). Falls Du nicht weißt wie, frag nochmal.
• Ich werde unabhängig davon (aber erst nach dem 1-Wire-Release) eine Analysemöglichkeit für sporadische Fehler schaffen, um solchen Hängern in Zukunft hoffentlich besser auf die Schliche kommen zu können.

Hoffe, dass ist soweit ok für Dich,

Gruß, Waldemar

P.S.: Das mit der gelben LED ist ein guter Tipp, die kontrolliere ich! Ich muss mal schauen, wann ich die überhaupt einschalte und wann aus, der Fehler muss ja dazwischen passiert sein!