Alternative Firmware für das Raum-Sensormodul von Masifi

[mumpf]

Hi,

Ich habe auch mal ne Zeit lang mit VMWare Workstation (allerdings unter Windows) gearbeitet, das mit den COM-Ports ist immer wieder ein Problem gewesen, deswegen bin ich dann nativ auf den Hostrechner umgestiegen. Was ich aus der Zeit noch weiß: Wenn Du beim SAMD 2 mal auf die Reset-Taste drückst, kommst Du in den Emergency-Bootloader, der macht einen anderen COM-Port auf. Und der - warum auch immer - hat dann immer für das Flashen mit VMWare (allerdings aus PlatformIO heraus) funktioniert.

Ansonsten kann ich zu Apple-Infrastruktur leider nicht viel beitragen. Hast Du schon mal geschaut, ob es PlatformIO für Apple gibt? Und es dann damit nativ versucht? Für die Firmware könnte das klappen, für das bauen der Applikation nicht. Allerdings sollte die Kommandozeilenversion von MultiplyChannels auf ner Win10-VM funktionieren. Ist dann eben nicht so in PlatformIO integriert, wie ich es nutze...

Und noch was: Arduino-IDE verwendet zu Flashen auch nur ein Tool (ich weiß nicht welches). Wenn Du also die Arduino-IDE bei Dir laufen lassen kannst und eine Firmware von da aus hochgeladen bekommst, dann solltest Du mal versuchen herauszufinden, wie die das machen. Und dann die entsprechende Kommandozeile selber absetzen.

Gruß, Waldemar

[fsl]

Versuche, das Binary direkt zu flashen, komme aber trotzdem auf keinen grünen Zweig. Ich habe es mit dem "Bossa"-Tool probiert, das wohl auch von platformio benutzt wird. Leider kann ich die Mac-Version nicht in einem aktuellen macOS installieren (ist wohl zu alt) und unter Windows 10 per VMWare (jeweils aktuell) kann Bossa sich dann nicht auf den virtuellen COM-Port für den SAMD21 verbinden. Arduino geht natürlich auch nicht, weil ich ja nicht den Quellcode benutze.

Kennt jemand noch ein Programm, mit dem ich per CLI (gerne unter macOS) direkt das Binary flashen kann?

[mumpf]

Hi,

ich wollte nur sagen, dass jetzt die neueste Firmware-Version 1.0.2 auf github ist. Bei Luftdruck wird auch der Offset korrekt berücksichtigt.

Gruß, Waldemar

[mumpf]

Hi Michael,

tauschen der Applikation geht nur, wenn sie passend versioniert ist und die Applikation dafür intern vorbereitet ist. Was alles dafür nötig ist, hat mich fast 2 Monate der Entwicklung gekostet, aber ich bin mir ziemlich sicher, dass ich hinbekommen habe. Da ich aber immer gleich 4 Versionen "verbrate" (für 10, 20, 40 und 80 Kanäle je eine), ist das etwas aufwändiger zu verwalten. Grundsätzlich will ich schon updatefähige Korrekturen, allerdings nicht bei jedem kleinen Fehler eine. Insofern bin ich durchaus für's Sammeln. Mir ist klar, dass am Anfang noch einige Fehler aufkommen werden. Ich werde über Ostern wohl noch 15-20 solcher Module bei mir verbauen und dann einen Produktivtest machen, dann werden wahrscheinlich auch noch ein paar Kleinigkeiten auffallen.

Dann bleibt es dabei: Ich korrigiere die Firmware und die Applikation, aber mache noch keine neue Applikationsversion. Die neue Version gibt es dann, wenn es sich "lohnt", also nach vielen kleinen Korrekturen oder einem groben Schnitzer, bei dem es einfach keinen Workaround gibt.

Gruß, Waldemar

[Sisamiwe]

Aber wenn Du 970 hast, dann willst Du auch um mehr als +10 korrigieren... Und diese Grenze liegt nicht an der Firmware sondern an der Applikation. Ist eigentlich kein Problem, die Grenze zu erhöhen auf z.B. +-50, die Frage ist nur, wie wichtig Dir Deine bisherigen Parameter sind. Wenn Du nochmal neu parametrisieren magst, ist das kein Problem, dann baust Du eine neue Applikation, löscht das bisherige Gerät aus Deinem Projekt und aus dem Katalog und importierst anschließend die neue knxprod.

Ich glaube der Sensor hat einen Treffer, also sendet falsche Werte. Der Luftdruck weicht am weitesten ab. Die Temp ist auch fast 2K unter dem Durchschnitt der anderen Sensoren im Raum. Habe das auch mit einem einfachen Beispiel-Sketch nochmal geprüft. Da kommen die gleichen Werte. Du kannst einen größeren Offset-Bereich mal auf die ToDo-Liste nehmen, aber aktuell ist es nicht nötig. Ich korrigiere erstmal über shNG und schau mal, ob der es wirklich ein Offset ist. Ich schlage vor, den Test noch etwas weiter zu fahren und das Update der Applikation später zu machen. Kann man in der ETS die Applikation nicht auch einfach tauschen? Werden immer die KOs gelsöcht? Bin mir nicht sicher.

Gruß
Michael

[mumpf]

Hi,

Schaust Du für sicherheitshalber auch die anderen Offsets an?

Hab ich schon, wie gesagt, lag nicht daran, dass er nicht berücksichtigt wurde, sondern dass er als vorher durch 100 geteilt wurde. Da nur +-10 für den Offset erlaubt sind, konntest nur nur um -0.1 bis 0.1 mBar korrigieren. Bei den anderen Einheiten wird nicht geteilt, deswegen gehen die schon vorher (und immer noch).

Aber wenn Du 970 hast, dann willst Du auch um mehr als +10 korrigieren... Und diese Grenze liegt nicht an der Firmware sondern an der Applikation. Ist eigentlich kein Problem, die Grenze zu erhöhen auf z.B. +-50, die Frage ist nur, wie wichtig Dir Deine bisherigen Parameter sind. Wenn Du nochmal neu parametrisieren magst, ist das kein Problem, dann baust Du eine neue Applikation, löscht das bisherige Gerät aus Deinem Projekt und aus dem Katalog und importierst anschließend die neue knxprod.

Wenn Du eine neue updatefähige Version haben willst, dann brauche ich dafür Zeit bis zum Wochenende. Das macht schon etwas mehr arbeit. Andererseits hätten wir dann auch gleich alle Texte richtig und ich wüsste, dass das Update auch bei anderen wirklich klappt.

Die Entscheidung überlass ich Dir, ich mach mich ans Testen. Ich sehe zu, dass es noch heute Nacht in Github ist, ich schreib hier rein, wenn ich es hochgeladen habe.

Gruß, Waldemar

[Sisamiwe]

mumpf

Danke.
Schaust Du für sicherheitshalber auch die anderen Offsets an?

Mein BME680 meldet einen Luftdruck von 970. Das stimmt nun wirklich nicht.

[mumpf]

So,

den Fehler hab ich schon mal gefunden! Bei der letzten Korrektur mit Luftdruck (das warst doch auch Du, nicht wahr ) bin ich ja von Pascal auf Millibar gegangen, dazu musste ich die Werte durch 100 teilen. Dummerweise hab ich das auch für den Offset gemacht - da der aber schon als Millibar eingegeben wird, passt das dann nicht mehr.

Ich teste das Ganze nochmal durch und lade dann die Firmware wieder hoch. Es ist wieder nur die Firmware, nicht die Applikation betroffen.

Bis zur nächsten Korrektur,
Gruß, Waldemar

[mumpf]

Hi,

es kann alles sein, auch wenn es mich ärgern würde. Aber wenn Du das beobachtet hast, dann wirst Du schon recht haben. Ich schaue mal. Schon wieder Luftdruck... habe ich offensichtlich zu wenig getestet. Wobei - ich war mit den 1010 mBar hier zufrieden .

Melde mich, sobald ich was gefunden habe.

Gruß, Waldemar

P.S.: Warum denkst Du, dass der BME680 falsche Daten liefert? Falls Du VOC/Co2-Äquivalenz meinst, kann es sein, dass die gespeicherten Kalibierungswerte gelöscht werden müssen. Das erkennt man am besten daran, dass nach einem Neustart für VOC 0 gesendet wird (normal fängt er mit 25 an). Wie man löscht, steht in der Applikationsbeschreibung (Standardsensoren->Zusatzfunktionen->Kalibrierungsdaten löschen).

[Sisamiwe]

mumpf

Hallo Waldemar,
Update auf Firmware 1.1 auf meinem Sensor V1 habe ich problemlos durchgeführt.

Da mein BME680 scheinbar falsche Daten liefert, habe ich mir die ETS Parameter dafür nochmal angeschaut.
Kann es sein, dass der in der ETS einstellbare Offset für Luftdruck nicht appliziert wird? Egal was ich einstelle, der gesendete Wert bleibt gleich.

Beste Grüße

[mumpf]

Hi,

falls jemand es mit der "precompiled Version" auf github versuchen wollte: Ich habe die dummerweise nur für die Boardversion v3 gebaut, die aber noch keiner haben kann. Die läuft auf den v1 und v2 Boards - wenn überhaupt - nur bedingt, da einige Pins nicht stimmen. Habe heute morgen das Release korrigiert und alle 3 Firmware-Versionen hochgeladen.

Gruß, Waldemar

[mumpf]

Hi Thomas,

danke für den Tipp mit der Version am DeviceObject, das hab ich gleich umgesetzt und das kommt dann mit dem nächsten Firmware-Update.

Meine Versionsausgabe behalte ich zusätzlich, ich will sowieso ein Diagnoseobjekt haben, dass eine Art CLI darstellt und auf einfache Befehle passende Antworten schickt, da ist die Version ein guter Test, dass es funktioniert.

Gruß, Waldemar

[thesing]

mumpf Die Version der Firmware kannst du einfach am DeviceObject setzen. Die Version bekommt man, wenn man sich von die Gerätinformationen anzeigen lässt. Im ApplicationObject gibt es auch noch eine Version.

[mumpf]

Hi,

habe soeben die aktuellste Version auf github veröffentlicht. Diesmal auch mit einer fertig gebauten Firmware. Zu finden im knx-sensor Projekt. Die knxprod muss man sich aber weiterhin selber bauen.

Aktuelle Änderungen:

• Luftdruck wird jetzt als mBar gesendet, aber immer noch mit DPT 9.006
• Die Applikationsbeschreibung ist entsprechend (mBar) aktualisiert
• Am Anfang schicken alle Sensoren ihre Werte. Bisher konnte es passieren, dass auch mal ein uninitialisierter Wert (z.B. 0°C) gesendet wurde. Sollte nicht mehr passieren. Falls doch, bitte melden.
• Das Errorhandling (Fehlerobjekt über KO 11) ist derzeit deaktiviert, intern konnte das zu einem "Hänger" führen. Wird zukünftig wieder aktiviert, wenn ich weiß, was genau die Ursache ist.
• Die Firmware ist ab sofort versioniert. Aktuelle Version ist 1.0.1. Man kann an das Diagnoseobjekt KO12 ein "v" schicken und bekommt dann über KO12 eine Antwort "VERS 1.0.1". Dazu muss man allerdings das S- und das Ü-Flag am KO12 setzen.

Diese neue Firmware erfordert KEIN Update der Applikation in der ETS. Man muss nur die Firmware compilieren (oder die fertige nutzen), auf das Sensormodul laden und anschließend einfach über die ETS neu programmieren.

Gruß, Waldemar

[mumpf]

HI,

nochmal die finale Analyse zu diesem Problem:

Ich denke, dass es die Absolute Abweichung ist:

Es geht etwas über "Rundungsfehler" hinaus, es ist die Zahlengenauigkeit von DPT9 bei großen Zahlen. Kann man auch in der ETS testen. Wenn man
100000 Pa (also DPT9.006) im Gruppenmonitor schreiben lässt, wird 100024,32 gesendet. Dieser Wert wird für jeden weiteren Wert bis 100065 gesendet, bei 100066 dann plötzlich 100106,24. Auch wenn man weiter runter geht, bekommt man bis 99984 noch immer 100024,32 gesendet.

Anders gesagt, die Genauigkeit von DPT9.006 für so große Zahlen liegt bei ungefähr 80, ich bekomme also nur bei einer Differenz von 80 einen neuen Wert auf den Bus.
Ich habe mich bisher immer gefreut, dass ich einen Luftdruck gesendet bekomme und der sah auch vernünftig aus, wie sehr er schwankt, habe ich nie beachtet. Letztendlich ist DPT9.006 für die Ausgabe von normalem Luftdruck in Pascal nicht geeignet.

Ich sehe 2 Möglichkeiten. Die eine wäre, DPT14.058 für Druck in Pascal zu nehmen. Der Wert ist dann in der doppelten Genauigkeit und somit genau genug für den Luftdruck. Allerdings würde damit die Schnittstelle inkompatibel geändert und man müsste mit der Firmware auch eine neue Applikation erstellen und alles neu parametrieren.

Der andere Weg ist das Senden vom Luftdruck in Millibar (mBar), da reicht DPT9 noch gut aus. Für eine Visu wäre das auch ein geeigneter Wert, die Frage ist, wie der Wert sonst noch konsumiert werden soll. Für mBar gibt es keinen DPT, ich würde somit weiter als Pa senden (mBar ist Pa / 100). Dafür würde die Schnittstelle und die Applikation so bleiben können wie sie ist und ich müsste nur die Firmware austauschen. In einer zukünftigen Applikationsversion würde ich dann den Text für das KO in "Luftdruck in mBar" anpassen.

Langer Rede kurzer Sinn: Ich würde die Variante mit mBar machen, wenn es nicht jemanden gibt, der ausdrücklich DPT14.058 braucht.

Leider brauche ich für die Anpassung noch 1-2 Tage, ist - wie ich schon sagte - mehr als ein Rundungsfehler... Deswegen gib es heute Abend auch leider keine neue Firmware-Version.

Gruß, Waldemar