Alternative Firmware für das Raum-Sensormodul von Masifi

[mumpf]

Hallo Michael,

Ich habe keine Eile.

ich wollte Dir nur einen kurzen Status geben: Ich habe die Korrektur schon seit Samstag Abend fertig, aber am Wochenende konnte ich wegen meinem 1-Wire-Aufbau nicht richtig testen. Und ganz ungetestet möchte ich das nicht freigeben. Ich hoffe, Du kannst Dich noch bis Mittwoch Abend gedulden, denn morgen wird das wegen meiner Arbeit nichts mit testen.

Gruß, Waldemar

P.S.: Aber bei größeren Werten für "absolute Abweichung" funktioniert das schon bei Dir, oder? Wenn man von der Abweichung +-1 wegen Rundungsfehlern absieht...

[Techi]

Erst mal Hut ab, was da an Arbeit geleistet wurde. Ich habe im Entwicklungs Thread auch immer mal mitgelesen und mir das für später vorgemerkt wenn mal der Bau soweit fertig ist und ich mehr Zeit habe.
Aber jetzt mit dieser Lösung ist da ja fast alles schon fertig.

Also sorry für die nun fast schon unverschämte Frage.
Wäre es möglich zusätzlich noch ein paar ganz primitive (in meinem Fall ) 1 digitale I/O (bzw. ich bräuchte nur Input) zu bekommen.
Also keine zusätzlichen speziellen Sensoren, sondern nur das Einlesen/Ausgeben/Konfigurieren von IO Pins ?

Gruß, Walter

[mumpf]

Hallo Walter,

ist aus mehrfacher Hinsicht schwierig:

• Output wäre aus Firmwaresicht noch relativ einfach zu realisieren, ich würde pro Logikkanal eine Ausgabe auf einen Outputkanal machen, ähnlich wie beim Buzzer.
• Input ist aber timing-kritisch und bisher hab ich schlechte Erfahrungen mit Interrupts gemacht. Außerdem kommen dann sofort die Forderungen nach Zählern etc.
• Von der Hardware her (hier muss Masifi sich aber qualifiziert äußern) erfordern IO - zumindest die Inputs - aber Optokoppler, und für die ist wohl kein Platz mehr auf der Platine.

Ist zumindest nichts kurzfristiges, meine derzeitige Liste sagt: 1-Wire (Sensoren), Zeitschaltuhren, Zustandsautomaten. Jedes davon ist Arbeit für 3-6 Monate, IO käme dahinter...

Warum ich nicht so sehr für IO bin: Es gibt sehr günstige Tasterschnittstellen, die können prima IO, warum nicht die nehmen? Und es macht auch keinen Sinn, alle Funktionen in ein Gerät zu packen.

Mal sehen, was Matthias dazu sagt,
Gruß, Waldemar

[Techi]

Danke für dein schnelles Feedback.

...erfordern IO - zumindest die Inputs - aber Optokoppler, und für die ist wohl kein Platz mehr auf der Platine.

Die Hardware wäre kein Problem da ich zumindest in meinem Fall eh eine eigene Hardware verwenden muss.

Warum ich nicht so sehr für IO bin: Es gibt sehr günstige Tasterschnittstellen, die können prima IO, warum nicht die nehmen? ...

Wenn das so einfach wäre, in meinem Fall muss ich über KNX ein fertiges Modul mit 5V und 22mA versorgen, ich habe da nun schon einige "fertige" binär Eingänge zerlegt aber noch keines gefunden welches dieser Anforderung gerecht wird, entweder stehen da auf der Platine nur 3.3V zur Verfügung wo dann der Strom selbst für einen sehr effizienten Boost Converter nicht reicht, oder es gibt 5V aber dann auch nur mit ein paar mA.

Ich hätte jetzt einfach ein SAMD Board und ein KNX Interface Board von Eugen genommen und dann mit deiner Lösung da was gebastelt.

Aber nicht tragisch, ich dachte nur, ich kommen jetzt schnell und ohne viel Aufwand an eine Lösung.

[mumpf]

Hi, wie gesagt, die Hardwareseite musst Du mit Masifi klären. Und natürlich kann ich Dir helfen, dass wir eine Firmware stricken, die genau Deinen Bedürfnissen genügt, das ist häufig wesentlich weniger Aufwand als ein generischer (und normalerweise zeitkritischer) Input in einer Firmware.

Sprich mich einfach darauf an, wenn es soweit ist.

Gruß, Waldemar

[fsl]

Ich benutze Windows 10 unter VMWare Fusion auf aktuellem MacOS und habe die Anleitung hier befolgt. Bis zum Kommando

code Sensormodul.code-workspace

hat auch alles funktioniert. Auf dieses Kommando hin, habe ich folgende Ausgabe in der Konsole erhalten:

PS Microsoft.PowerShell.Core\FileSystem::\\vmware-host\Shared Folders\Dokumente\PlatformIO\Projects\knx-sensor> code Sensormodul.code-workspace
"\\vmware-host\Shared Folders\Dokumente\PlatformIO\Projects\knx-sensor"
CMD.EXE wurde mit dem oben angegebenen Pfad als aktuellem Verzeichnis gestartet.
UNC-Pfade werden nicht unterstützt.
Stattdessen wird das Windows-Verzeichnis als aktuelles Verzeichnis gesetzt.

Passiert ist dann lediglich, dass ein neues Tab "Sensormodul.code-workspace" geöffnet wurde, das aber vollkommen leer war. Eine neue Instanz (neues Fenster?) habe ich nicht gesehen.

Hat jemand eine Idee, wie ich hier weiterkomme? Ich bestehe im Übrigen nicht darauf, selbst zu kompilieren.

[mumpf]

Hi,

ich habe das extra auf einer frischen Win10-Instanz getestet... allerdings nur mit den Standard-Pfaden. Und die fangen unter Windows nunmal mit "C:\Users\<username>" an.

Du kannst unter Windows auch einfach das Verzeichnis knx-sensor auf dem Desktop öffnen und dann einen doppelclick auf Sensormodul.code-workspace machen.
Aber wie das dann weiter läuft oder nicht kann ich nicht so einfach sagen.

Ich kann Dir eine Firmware bauen, aber ich hab bisher immer direkt den Upload auf das Device verwendet. Ich hab ehrlich gesagt keine Ahnung, wie man das getrennt macht (also bei mir bauen und dann bei Dir ein Upload). Da bräuchte ich also Tipps von der Community, wie man das macht. Ich hätte auch kein Problem, eine fertige Firmware zu veröffentlichen, bei der knxprod sieht das aber anders aus - deswegen hab ich mir ja die mühe gemacht, eine Bauanleitung zu machen.

Gruß, Waldemar

[fsl]

Du kannst unter Windows auch einfach das Verzeichnis knx-sensor auf dem Desktop öffnen und dann einen doppelclick auf Sensormodul.code-workspace machen.
Aber wie das dann weiter läuft oder nicht kann ich nicht so einfach sagen.

Das hat funktioniert. Leider hängt der Build dann mit:

UnicodeDecodeError: 'charmap' codec can't decode byte 0x81 in position 185: character maps to <undefined>

Vielleicht könntest Du auf GitHub die Binaries zur Verfügung stellen und dann schaue ich mal, wie ich es drauf bekomme.

Wegen der knxprod schauen wir dann mal weiter. Das ist ja ein anderes Prozedere.

[mumpf]

Hi,

Du hast offensichtlich noch ein Encoding-Problem: Ich bin mir recht sicher, dass ich alles in UTF8 gespeiechert habe, das scheint aber so nicht bei Dir anzukommen - was ich verwunderlich finde. Weißt Du, um welche Datei es geht? Dann würde ich nochmal schauen, ob ich da vielleicht nicht versehentlich doch die Windows-Codepage eingestellt habe.

Ansonsten habe ich das binary gefunden, ich werde es heute Abend auf github bereitstellen, gleich mit allen bisher angefallenen Korrekturen.

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

[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

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

[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

[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