Alternative Firmware für das Raum-Sensormodul von Masifi

[stmeyer]

Hi,
bezugnehmend auf die Diskussion hier: https://knx-user-forum.de/forum/%C3%...13#post1646813

Ich habe nun eine Glättung von P=12 eingetragen und folgendes Ergebnis. Durch die Mittelung schwankt der Wert deutlich weniger, aber das Ergebnis ist erkennbar niedriger, wie wenn ich mir die Kurve anschaue und gefühlsmässig im Kopf glätte. Ich habe mir aber ehrlich gesagt, Deine Doku noch nicht wirklich angeschaut, vielleichtgeht der Effekt daraus hervor...

Viele Grüße
Stefan

Bildschirmfoto vom 2021-04-23 09-10-37.png

[stmeyer]

Jetzt habe ich doch mal in die Doku geschaut und ich habe auch mal mit der angegebenen Formel nachgerechnet. Da sieht das Ergebnis wie von mir erwartet aus...

Edit: Vielleicht kommt der Offset in der vorigen Post auch vom Neustart des Moduls (nach neuprogrammieren)... Ich habe nun nochmal mit Glättungsfaktor 36 programmiert und in 2 Std. oder so nehme ich die Glättung nochmal raus. Ich poste dann wieder die Kurve...

Bildschirmfoto vom 2021-04-23 11-05-35.png

[mumpf]

Hi Stefan,

da muss ich wohl nochmal ran . Soll natürlich nicht so sein. Wie gesagt, der Sensor ist der erste, der so schön gestreut Daten liefert, da kann ich auch besser testen. Vorher war die Funktion einfach da und ich hab sie von über all her aufgerufen.

Ich hoffe, es ist nichts dringendes, ich muss mich erstmal um den SCD30 kümmern...

Gruß, Waldemar

[stmeyer]

Hi,
anbei ein weiteres Diagramm. Zeitlicher Verlauf: die ersten 3-4 Std. P=1, dann 18 Std. P=12, 6Std. P=36 und der Rest wieder P=1

Man sieht schon, dass das Niveau nach einem Neustart etwas schwankt aber durch die Glättung etwas verringert wird. Und nein, ist nicht dringend, lass Dir Zeit, bis Du darauf Lust hast.
Mich würde viel mehr interessieren, wie gut die Messergebnisse sind, wenn sich der Füllstand verändert. Das kann ich so aber nicht testen, die Zisterne hat 22000l, da muss es schon ne Weile regnen, bis sich da was tut...

Viele Grüße
Stefan

Bildschirmfoto vom 2021-04-24 08-09-21.png

[st400]

Hallo,
mittlerweile sind auch bei mir die Module von Matthias angekommen (auch danke hierfür). Nutzen möchte ich diese gerne mit der Software von Waldemar.

Habe VS Code nach der Anleitung installiert und eingerichtet. Anschließend habe ich versucht die direkt per USB zu flashen (erfolglos). Erst später habe ich dann gelesen das hierzu die KNX Verbindung benötigt wird. Danach klappte auch das flashen 👍.

Jetzt habe ich noch 2 Fragen:
1.
Leider hat das Sensormodul keine Sensorwerte geliefert. Habe dann das KO Sensorfehler abgefragt. Da kam der Wert "00 00 | 0 pulses" zurück. Ich habe dann Testweise bei Logik 1 als Operation UND eingetragen (vor war Operation aus) und anschließend wurden Sensorwerte gesendet. Aber vielleicht lag das Problem auch woanders?

2.
Das Sensormodul habe ich in der ETS für einen anderen Raum kopiert. Beim Programmieren der phy. Adresse wurde ich allerdings nicht dazu aufgefordert die Prog. Taste zu drücken. Es wurde einfach direkt programmiert. Beim programmieren der Applikation bekomme ich allerdings folgenden Fehler:
Das Gerät ist von einem anderen Hersteller als das Applikationsprogramm. Habe ich hier irgend etwas falsch gemacht? Oder muss man beim Flashen noch etwas beachten damit die ID nicht doppelt ist?

Ansonsten kann ich schon mal sagen das die Applikation besser ist als von manch anderen KNX Geräten 👍.

Gruß Stefan

[mumpf]

Hallo Stefan,

dass die KNX-Verbindung fürs Programmieren nötig ist, werde ich noch in die setup-Anleitung aufnehmen, danke für den Vorschlag.

zu 1.: Sensorfehler funktioniert noch nicht. Es ist gar nicht so einfach, aus einer Fehlersituation heraus ein KO passend zu versorgen. ABER: Die Logik hat garantiert nichts mit dem Senden der Sensorwerte zu tun, das sind komplett getrennte Entwicklungszweige. Ich vermute, dass beim ersten mal programmieren irgendwas nicht korrekt gelaufen ist. Nach dem erneuten Programmieren (mit der Logik) hat es dann geklappt.

zu 2.: Warum die ETS Dich nicht zum drücken des Programmierknopfes auffordert, kann ich Dir leider nicht sagen, bei mir tut sie das . Bist Du sicher, dass Du nach dem Kopieren nicht versehentlich eine existierende PA dem Gerät gegeben hast? Dann hätte die ETS nämlich ein anderes Gerät programmiert und dann wäre auch die Fehlermeldung passend (das fremde Gerät wäre ja mit meiner Applikation programmiert worden).

Ich würde zur Sicherheit einfach so vorgehen, wie man es früher machen musste (auch wenn es nicht mehr notwendig sein sollte): Du drückst die Prog-Taste, programmierst dann NUR die PA auf das Gerät, anschließend programmierst Du die Applikation drauf und dann klappt das.

Ansonsten wünsche ich Dir viel Spaß beim Ausprobieren.

Gruß, Waldemar

[st400]

hi Waldemar,

zu 2: Ja die ETS lässt ja auf normalen Weg keine doppelten Adressen zu (ich wüsste zumindest nicht wie). Ich habe mal deinen Tip probiert und das Sensormodul in den Programmiermodus versetzt. Anschließend die physik. Adresse programmiert. Jetzt kommt die Meldung das mehr als ein Gerät im Programmiermodus ist. Darauf hin habe ich das Sensormodul entfernt, getestet ob auf einer nicht belegten Adresse ein Gerät antwortet. Das war nicht der Fall. Anschließend physik. Adresse programmiert und danach die Geräteinfo abgefragt. Es meldet sich mein IP Interface. Das ist also im Dauerprogrammiermodus. Ich weiss zwar nicht warum das IP Interface so reagiert. Du hattest aber zumindest den richtigen Riecher, danke.

Jetzt muss ich nur noch rausfinden wie ich das IP Interface überrede den Programmiermodus zu verlassen.

Gruß Stefan

[Sisamiwe]

Jetzt muss ich nur noch rausfinden wie ich das IP Interface überrede den Programmiermodus zu verlassen.

Hast Du auch den knxd am auf einem Rechner im Netzwerk laufen?

Der kann auch dazu führen, dass "mehr als ein Gerät im Programmiermodus ist".

[st400]

Hast Du auch den knxd am auf einem Rechner im Netzwerk laufen?

Der kann auch dazu führen, dass "mehr als ein Gerät im Programmiermodus ist".

Nein den habe ich aktuell nicht laufen. Will den aber mal ausprobieren. Wenn der allerdings öfters Probleme macht, vielleicht lieber nicht.

Ich habe jetzt mal den Stecker vom IP Interface gezogen und wieder angesteckt und siehe da, es ist nicht mehr im Programmiermodus. Jetzt konnte ich auch das Sensormodul erfolgreich programmieren 👍.

[stmeyer]

Hi Stefan,

da muss ich wohl nochmal ran . …

Hi Waldemar,
mir ist noch was eingefallen, vielleicht passt das in Dein Konzept:
Die Entfernungsmessung wird ja vermutlich hauptsächlich zur Füllstandsmessung genutzt. Wäre es möglich in der Applikation ein zusätzliches KO einzuführen, das den Füllstand in Litern (schwankt dann wahrscheinlich sehr) und m^3 ausgibt?
Dazu braucht man dann natürlich noch die Grundfläche des Tanks, die man dann in der Applikation oder direkt im Quellcode vor dem Kompilieren eintragen könnte…

Dies soll jetzt aber kein Drängeln sein irgendwas an der Firmware bzgl. des ToF-Sensors zu machen. Ich bin mit dem jetzigen Zustand schon ganz zufrieden und kann die Umrechnung einfach über NodeRed machen. Ich finde es halt super, wenn möglichst viel in Knx gemacht wird und die Hütte nicht von zusätzlichen Diensten (die nach mir vermutlich niemand mehr pflegt/betreibt) abhängig ist.

Viele Grüße
Stefan

[starwarsfan]

Dazu braucht man dann natürlich noch die Grundfläche des Tanks, die man dann in der Applikation oder direkt im Quellcode vor dem Kompilieren eintragen könnte…

Und wieviele Tanks haben eine Quader-Form, bei der das dann auch passt? Eher wenige vermutlich. Meine Zisterne jedenfalls nicht...

[stmeyer]

Und wieviele Tanks haben eine Quader-Form...

Deswegen habe ich auch geschrieben, dass man die Grundfläche eingeben soll und nicht Länge und Breite oder Durchmesser, etc. Natürlich klappt das nicht, wenn man eine „liegende tonnenförmige“ Zisterne hat, aber die Anwender können dann immer noch die Füllhöhe nutzen damit rechnen.
Aber nahezu alles was gemauert/gegossen ist wäre wie vorgeschlagen umsetzbar.

Viele Grüße
Stefan

[mumpf]

Hi Stefan,

ich wollte ja schon immer mal ein Mathe-Modul für die Logik machen. Aber wie das immer so ist, das dauert alles viel länger als gedacht. Es ist sehr anspruchsvoll, in der ETS eine passende Oberfläche für Formeln anzubieten. Das wird somit noch dauern.

Deswegen gibt es bald die "kleine" Lösung:

Die Idee kommt von meinem 1-Wire-Modul und heißt "Kundenspezifische Funktionen", das werde ich auch für die Logik ermöglichen.

Es gibt jetzt schon die Möglichkeit, am Ausgang einer Logik den Wert von Eingang 1 oder Eingang 2 senden zu lassen. In Zukunft wird man zwischen die Eingänge und den Ausgang auch eine von ca. 30 Kundenfunktionen schalten können, die im Coding hinterlegt wird. Diese Funktion muss natürlich vom User implementiert werden, bekommt dann den Wert von Eingang 1 und Eingang 2 als Parameter und man kann da dann machen, was immer man will (auch das Modul zum Absturz bringen). Wenn Du dann also den Ausgang vom Entfernungssensor auf Eingang 1 der Logik legst, kannst Du Dir so eine Umrechnungsfunktion bauen. Eingang 2 kannst Du (musst Du aber nicht) auch noch für die Temperatur nutzen, um Deine Umrechnung in Liter z.B. noch abhängig von der Wärmeausdehnung abhängig zu machen.

Ein weiteres (breites) Anwendungsfeld sind natürlich irgendwelche expliziten Konvertierungen von einem bestimmten DPT zu einem anderen. Diese passieren derzeit im Logikmodul nur generisch und treffen vielleicht nicht genau das, was man erwartet. Dafür wird es dann auch ein paar bereits implementierte Beispiele geben.

Der Nachteil ist natürlich auch klar, wenn Du die Funktion ändern willst, geht das mit diesem Ansatz nicht in der ETS, sondern nur in der Firmware, man muss die dann neu bauen und auf das Modul spielen, aber das ist eben das, was ich kurzfristig unterstützen kann. Außerdem gehe ich davon aus, dass man nicht beliebig viele solcher Funktionen braucht, die 30 die ich aufrufbar machen will sollten da wirklich die Obergrenze sein. Aber auch da kann man drüber reden, technisch werden wohl bis zu 255 gehen.

Und dann kann man ja noch das Forum dazu nutzen, um sich über Funktionen auszutauschen und über sinnvolle Verbesserungen zu diskutieren.

In gewisser Weise ist es auch ein Vorteil, die Firmware selber bauen zu können, denn so können auch kundenspezifische Erweiterungen gemacht werden, ohne dafür gleich Anpassungen in der ETS machen zu müssen. Im Profi-Bereich (also für die Hersteller) heißt so was womöglich gleich eine erneute Zertifizierung, weitere Kosten, neue Applikationsbeschreibung, Schulung vom Support und vieles mehr, so dass es dann nicht gemacht wird.

Das nur mal so aus Ausblick, wann das genau zeitlich kommt, kann ich noch nicht sagen. Aber wohl noch dieses Jahr . Ich bin derzeit noch komplett mit Lösen von Fehlern beschäftigt. Und - den Zeitaufwand sollte man nicht vernachlässigen - ich mach das ja für mich, muss also auch noch meine Module passend einbauen und parametrisieren.

Gruß, Waldemar

P.S.: Es gibt auch noch einen technischen Grund, warum ich das nicht im Sensormodul machen kann: Ich habe keine weiteren KO mehr frei und neue KO würden alles inkompatibel machen, was ich bisher erreicht habe. Und die abstrakte Formel im Logikmodul kann man auch für viele andere Sachen nutzen.

[stmeyer]

Hi Waldemar,
wunderbar, das wäre, zumindest für mich, die nahezu perfekte Lösung.

Viele Grüße
Stefan

[mumpf]

Hi Stefan,

das wäre, zumindest für mich, die nahezu perfekte Lösung.

damit hast Du Dich, zumindest für mich, als nahezu perfekter Tester für diese Lösung qualifiziert. Ich melde mich, wenn es soweit ist.

Gruß, Waldemar