OpenKNX-Sensormodul release

[mumpf]

Ok, ich habe am Luftdruck was geändert. Eigentlich nur den Faktor für den DPT geändert, ich hatte vorher hPa gesendet, obwohl der DPT ein Pa erwartet. Aber ich habe nur mit zyklisch senden und nicht mit abs. Abweichung getestet. Ich versuch das Nachzustellen, Du könntest als Workaround erstmal auf abs. Abweichung verzichten.

unten im Dropdown die neue Version gewählt. Dabei hat die ETS alle GA-Zuordnungen gekillt

Genau, wenn Du in der Dropdown eine Version auswählst, legst Du ein neues Gerät mit genau dieser Version an. Alles (GA und Parameter) wird entfernt.

ich nehme an, das wäre das korrekte Vorgehen?

Ja, steht auch so in meiner Anleitung im Wiki. Punkt 3, sogar mit Bild

Also wirklich 100% Buslast nur durch diese Meldungen.

In Fällen, bei den Parametrisierung zur hohen Buslast führt, reicht Reset+PROG-Taste 10 sek. lang halten, bis die Prog-LED blinkt.

Außerdem dann in der ETS ein komplett neues Gerät angelegt, händisch (auch ohne Konfigurationstransfer zur Sicherheit) alle Einstellungen übernommen und wieder aufs Gerät übertragen -> gleiches Fehlerbild.

Ist nett, dass Du das so intensiv testest, aber weder Config-Transfer noch Update der ETS verursachen solche Fehler. Ich versuche ja alles, damit man nicht die Geräte neu anlegen muss, denn mit vielen Definitionen macht das dann wirklich keinen Spaß mehr...

Wenn ich sonst noch was beisteuern kann gerne melden

Wäre interessant, ob es reicht, abs. Abweichung auf 0 zu setzen.

Gruß, Waldemar

[Alloc]

Ok, ich habe am Luftdruck was geändert. Eigentlich nur den Faktor für den DPT geändert

Hat mir auch keine Ruhe gelassen und mal spaßeshalber in den Code geschaut. Ich sehe bisher auch noch nicht wirklich, warum sich das nun so merkwürdig verhält. Müsste ja eigentlich bedeuten, dass lDiff >= lAbsolute ist. Ich nehme an die Werte, die man in der ETS einstellt werden 1:1 so im Parameterspeicher landen? Dann dürfte lDiff ja nie größer als die 10 sein, die ich eingestellt hab.

Genau, wenn Du in der Dropdown eine Version auswählst, legst Du ein neues Gerät mit genau dieser Version an. Alles (GA und Parameter) wird entfernt.

Gibt halt so wenige Geräte, die man wirklich mal aktualisiert im KNX (zumindest ging das mir bisher so). Mit OpenKNX lernt man dann tatsächlich mal noch was

Ja, steht auch so in meiner Anleitung im Wiki. Punkt 3, sogar mit Bild

An das neue Wiki muss ich mich erst noch gewöhnen. Hatte nur mal schnell Tante Google befragt nach "OpenKNX Update", da tauchte das noch nicht auf, nur ein alter Thread hier im Forum wo ihr generell über Firmware-Updates diskutiert habt. Aber wie gesagt, so hab ich was gelernt und schlimm ists ja auch nicht.

In Fällen, bei den Parametrisierung zur hohen Buslast führt, reicht Reset+PROG-Taste 10 sek. lang halten, bis die Prog-LED blinkt.

Hatte ich später auch ein paar mal genutzt, und gerade eben auch wieder - sparte mir das abnehmen von der Decke und mit Progger verbinden, also schon viel angenehmer

Ist nett, dass Du das so intensiv testest, aber weder Config-Transfer noch Update der ETS verursachen solche Fehler. Ich versuche ja alles, damit man nicht die Geräte neu anlegen muss, denn mit vielen Definitionen macht das dann wirklich keinen Spaß mehr...

Ich weiß, und das ist auch top! Aber bei komplett wirren Fehlerbildern will ich sicher gehen, dass nicht irgendwo noch was hakt. Intern könnte die ETS ja AFAIK auch gerade nicht sichtbare Optionen noch mit Werten belegt haben etc. Will halt erstmal ausschließen, dass es potenziell ein Anwenderfehler ist


Hab jetzt gerade nochmal durchgetestet, es liegt wohl wirklich an der absoluten Abweichung. Nur zyklisches Senden funktioniert wohl einwandfrei (hätte mich auf Grund der Codestruktur auch sonst noch mehr gewundert, sonst hätten ja alle Sensoren betroffen sein "müssen" und auch nicht erst seit dem Update).

[willisurf]

es liegt wohl wirklich an der absoluten Abweichung

Wenn der Luftdruck jetzt mit Pa einen Wertebereich bis 100000 hat, ist eine Differenz von 10 auch wirklich sehr (viel zu) wenig und kann aufgrund von Messwertschwankungen durchaus zu viel zu häufigem Senden führen.
Bei der Temperatur würde ja auch niemand bereits bei 0,002 °K Abweichung senden.

[Alloc]

Stimmt, und da ist das Buslog auch nicht hilfreich. Auf dem Bus haben wir ja einen Float mit 11 Bit Mantisse. Der Exponent war bei den Werten 2^13 = 8192, also hat man auf dem Bus eine minimale Schrittweite von 81,92. Das heißt intern (bei der Rechnung mit Float32) kann der Wert im Bereich von rund 81 Pa schwanken, ohne dass das auf der Busseite ersichtlich wird. Somit deutlich größer als die 10 die ich eingestellt hatte.

Leider lässt die aktuelle ETS-App hier nur Werte von 0 bis 80 Pa für die absolute Abweichung zu. Ich habe jetzt mal dieses Maximum eingestellt, und zumindest in den ersten zwei Minuten nur die Nachricht nach dem Boot des Sensors erhalten

Bin erstmal außer Haus, melde mich später nochmal ob das so geblieben ist.


PS: Da müsste dann wohl nicht nur der Eingabewertebereich in der ETS angepasst werden (also eher Richtung 0 - 100 hPa, also 0 - 10000 Pa) sondern auch eher eben das Feld genau so umgestellt, dass man gar nicht mehr Pa eingibt. Sonst wird es immer mal wieder passieren, dass jemand Werte < 80 eingibt und dann "komisches" Verhalten meldet. Eventuell reicht einfach Eingabe in hPa (und dann in der FW eben wieder *100 - bzw /0.01, ist ja immer ein Teiler), Wobei selbst 1 hPa als Abweichung natürlich schon knapp bemessen wäre.

[mumpf]

An das neue Wiki muss ich mich erst noch gewöhnen.

Stand auch so schon im alten Wiki .

Hab jetzt gerade nochmal durchgetestet, es liegt wohl wirklich an der absoluten Abweichung.

Danke, das hätte ich selber merken können. Sorry dass ich das nicht nachgetestet habe. Ich glaube, dass hier die Auflösung vom DPT9 eine Rolle spielt. Anders gesagt:

                    float lDiff = abs(lValue - cData->lastSentValue);

Das ist komplett richtig gedacht, aber beim senden wird

            float lValue = (float)knx.getGroupObject(iKoNumber).value(getDPT(iDpt));
            knx.getGroupObject(iKoNumber).objectWritten();
            cData->lastSentValue = lValue;​

lastSentValue letztendlich zu dem zuletzt gesendeten Wert. DPT9 ist aber eine 2-Byte-Fließkommazahl, float ist eine 4-Byte-Fließkommazahl. Und wir wissen jetzt schon, dass DPT9 bei großen Zahlen sehr ungenau wird, Pa gegenüber dem früheren hPa um den Faktor 100 größer ist und damit ein Wert von 10 so ziemlich sicher durch Auflösungsungenauigkeit "verschwindet".

Ich würde ja sagen, mach aus der 10 eine 1000 und alles ist gut, aber leider ist die absolute Abweichung derzeit künstlich auf 80 eingeschränkt (erschien mir bei hPa sinnvoll).

Ich werde also sowie so eine Änderung machen müssen. Was denkt ihr ist sinnvoller:

• Nur den Wertebereich anpassen: 200-8000 (ich glaube beim MIN 2 hPa kommen diese Probleme nicht) und mehr als 80 hPa wird der Wert nicht abweichen. Hier ist der Nachteil, dass so was wie 250 und 280 wahrscheinlich intern den gleichen Effekt geben, weil 30 Unterschied noch unter die Auflösungsschwelle fallen. Man kann also viel feiner einstellen als das, was technisch ausgewertet werden kann - finde ich irgendwie blöd.
• Ich interpretiere das aktuelle Feld wieder als hPa, nehme intern * 100 und lasse nur das Senden auf Pa.

Und ich mache noch eine Senderatenbeschränkung rein (nicht öfter als 1x pro Sekunde senden), dann für alle Sensoren, damit solche Probleme den Bus nicht mehr zumüllen können.

Wird aber noch etwas dauern, bis dahin musst Du bitte ohne Abs. Abweichung auskommen.

Gruß, Waldemar

P.S.: Hatte Deine Antwort nicht gesehen (war mit meiner beschäftigt), aber die Analyse gleicht sich ja . Jetzt ist nur noch die Frage: hPa-Eingabe oder 200-8000 (oder von mir aus 10000, ist aber sicher nicht nötig, so hoch zu gehen).

P.P.S.: Ich wusste schon, warum ich mich damals (entgegen dem DPT) für hPa entschieden habe .

[willisurf]

Ich würde auf 200-8000 gehen. Nicht jeder kann mit hPA etwas anfangen, Hekto ist ja doch recht veraltet.

[Alloc]

Das Argument mit Hekto hätte ich auch gebracht. Aber kann man in der ETS mehrere Wertebereiche erlauben? Du brauchst ja auch die 0 zum Abschalten? Ich hätte sonst Angabe in hPa vorgeschlagen - aber in der ETS dann wie z.B. bei Temperatur als "x 100 Pa".

PS: Ich denke nicht, dass es mehr als 1 hPa als Minimum braucht. Aktuell hab ich ja 0,8 hPa als Absolutabweichung, das hat bisher nicht einen Wert zusätzlich zum 30 Minuten-Intervall gesendet. Ist zwar dann wirklich recht empfindlich, aber eben nicht so extrem, dass der Bus damit geflutet wird. Ist aus meiner Sicht ähnlich wie bei z.B. Temperatur: Da würde ich auch nie 0,1 K als absolute Abweichung einstellen, weil es in dem Bereich schon recht leicht mal Schwankungen geben kann, sondern eben meist 0,2 K. Die Option hat man aber halt bei den meisten Sensoren dennoch und muss man dann einfach selbst entscheiden, ob man das will

[mumpf]

"x 100 Pa" ist eine gute Idee und passt auch zum Rest. Das wird es dann zwar auch für den Offset geben, aber ich denke, das ist auch noch OK.
Das mit 0 ist ein gutes Argument, ich kann nur einen Wertebereich vergeben.

Gruß, Waldemar

[mumpf]

Hab grad noch geschaut, ist sogar wichtig, dass Offset in "x 100 Pa" angegeben wird, denn da hab ich nur ein signed Byte frei und wäre sonst auf -128..127 Pa beschränkt, und das ist quasi nichts.

Da sieht man mal wieder, Änderungen an einem an sich durchdachten Konzept (selbst wenn andere das nicht gut finden) sind immer weitläufiger als man denkt.

Gruß, Waldemar

[henfri]

Hallo,

wie verwendet ihr die VOC Werte? Direkt den Sensorwert, oder die Ampel?
Kann mir jemand sagen, wie die Sensorwerte (ppm) sich in die Ampel umrechnen?

Gruß,
Hendrik

[Varone3000]

Mein Sensor Modul scheint irgendwie Tod zu sein.

Ich habe versucht ein Firmware Update auf 4.25 per KNX zu machen. Bei 70% dann abgebrochen. Erneut verbunden, dann bei 70% weitergemacht und bei 100% Erfolg gemeldet.

heute Abend ist mir dann aufgefallen , das es Abend keine 20grsd sein können.

Weder KNX seitig mehr erreichbar, noch per USB Kabel (KNX davor abgeklemmt).
Das erforderliche USB Laufwerk kommt auch nicht.
Auch den Prog Knopf 10sekunden gehalten. Kein rotes Licht. Komplett dunkel. Hat jemand ne Idee?

[willisurf]

Hat jemand ne Idee?

Versuch mal alle Schritte, die hier beschrieben sind. Bis inkl. Flash Nuke und neu programmieren.

[Varone3000]

Nabend Bernhard ,willisurf

ich werde das morgen Vormittag mal machen. Ich war bis eben draußen und hab es wie oben beschrieben versucht. Danke dir für den Link.

[mumpf]

Hi,

da Du schon der 3. bist, der so was meldet, hier die Warnung an alle: Update über KNX mit Abbruch und Fortsetzung (und nur dieser Fall) scheint sporadisch nicht korrekt zu funktionieren. Oder anders formuliert: Das Fortsetzen scheint nicht korrekt zu funktionieren.

Man kann auch die Kommandozeilenoption --no-resume nutzen, dann wird nicht fortgesetzt, sondern erneut komplett übertragen.

Wir haben noch keine Idee, warum das nicht funktioniert.

Gruß, Waldemar

[Varone3000]

Hallo Waldemar, hallo Bernhard

die Platine gibt keinen Mucks mehr von sich :-(
Hab alles aus der Anleitung von Bernhard probiert.