Alternative Firmware für das Raum-Sensormodul von Masifi

[mumpf]

In der ETS kann ich auswählen, dass der Ausgang einer Logik das Gerät neu startet. Das geht sowohl bei EIN als auch bei AUS. Die Applikationsbeschreibung sagt, es geht nur bei AUS. Der Test hat gezeigt, es geht auch nur bei AUS (zumindest bei meinem Kurztest)

Danke fürs Feedback. Ich bin mir nicht sicher, ob ich nicht was "kaputtgebastelt" habe, aber ich habe eben sowohl in der Anleitung wie in der Firmware geschaut, das ist komplett symmetrisch beschrieben und implementiert: Zurücksetzen kann man bei EIN und bei AUS.

Da ich diese Funktion auch bei mir gerade für meine Klimaanlagen adaptiere, werde ich das somit auch mal testen. Aber an sich ging das schon, das hatte ich zumindest schon mal getestet.

Ich habe versucht die Logik des Modules zu nutzen, dass ich neu starten will. Das hat (wieder in meinem Schnelltest) nicht geklappt. Von einem anderen Modul aus schon. Ich probiere das nach dem Urlaub nochmal.

Ich hab mal ins Coding geschaut. Kann sein, dass sich ein Device nicht selber resetten kann, weil es sich mit dem Zielgerät über PA verbinden muss (das ist was anderes als Gruppenkommunikation) und dann bin ich mir nicht mehr sicher, was da im Stack passiert (ist dann ja eine Point-To-Point-Verbindung von PA x.x.x nach x.x.x, das könnte zu Problemen führen). Das hab ich bisher nicht getestet.
Aber ich kann natürlich vorher die PA vergleichen und wenn es die "eigene" PA ist, direkt einen Neustart der Prozessors antriggern. Ich setze das mal auf meine Liste.

Ich würde vorschlagen, wir reden nach Deinem bzw. nach meinem Urlaub, so Ende August wieder, dann weiß ich auch wieder mehr.

Gruß, Waldemar

[Sisamiwe]

JA! Die Funktion, auf die ich am meisten stolz bin, weil sie sonst keiner bietet... Du kannst über einen Logikkanal ein Reset (das gleiche, was die ETS macht) an irgendeine PA schicken, also auch an die eigene.

Danke. Ich habe das gerade mal probiert. Dazu folgende Rückmeldung:

• In der ETS kann ich auswählen, dass der Ausgang einer Logik das Gerät neu startet. Das geht sowohl bei EIN als auch bei AUS. Die Applikationsbeschreibung sagt, es geht nur bei AUS. Der Test hat gezeigt, es geht auch nur bei AUS (zumindest bei meinem Kurztest)
• Ich habe versucht die Logik des Modules zu nutzen, dass ich neu starten will. Das hat (wieder in meinem Schnelltest) nicht geklappt. Von einem anderen Modul aus schon. Ich probiere das nach dem Urlaub nochmal.

Die Frage ist eher, wie Du feststellst, dass über längere Zeit der gleiche Wert gesendet wird. Es kann ja auch zufällig korrekt sein. Ich bin aber recht sicher, dass das auch klappen würde, wahrscheinlich nicht mit einem Logikkanal, sondern eher mit 3-4. Ich könnte Dir gerne dabei helfen, das sollten wir aber online machen, da das auch stark vom Signalverlauf abhängt.

Ich habe das jetzt mal quick-and-dirty mit shNG gemacht. Wenn der Wert sich innerhalb einer Stunde nicht ändert (und das ist bei 0,01K höchst unwahrscheinlich), wird das Modul zurückgesetzt. Das geht sicher mit den Logiken innerhalb des Modules.

Ich bastle gerade an der neuen OpenKNX-Firmware für das Sensormodul, auch für das externe. Da der KNX-Stack (speziell die UART-Implementierung) hier wesentlich robuster ist, verspreche ich mir auch geringere Timing-Probleme für den 1-Wire-Bus. Wenn das fertig ist, würde ich mich freuen, wenn ich Dich als Tester gewinnen könnte. Allerdings ist die neue Firmware inkompatibel, Du müsstest dann neu parametrieren...

Wie gesagt, das Verhalten der FW 3.8 ist an der Stelle deutlich stabiler, da das Modul selbst nicht abstützt. Es sendet fleißig weiter, aber eben den gleichen Wert.
Ich bin auf die OpenKNX Version gespannt und teste gern.

Danke Dir!

[mumpf]

Kann ich irgendwie eine SW-Reset von außen ohne ETS (automatisiert) auslösen?

JA! Die Funktion, auf die ich am meisten stolz bin, weil sie sonst keiner bietet... Du kannst über einen Logikkanal ein Reset (das gleiche, was die ETS macht) an irgendeine PA schicken, also auch an die eigene.

Die Frage ist eher, wie Du feststellst, dass über längere Zeit der gleiche Wert gesendet wird. Es kann ja auch zufällig korrekt sein. Ich bin aber recht sicher, dass das auch klappen würde, wahrscheinlich nicht mit einem Logikkanal, sondern eher mit 3-4. Ich könnte Dir gerne dabei helfen, das sollten wir aber online machen, da das auch stark vom Signalverlauf abhängt.

Ich bastle gerade an der neuen OpenKNX-Firmware für das Sensormodul, auch für das externe. Da der KNX-Stack (speziell die UART-Implementierung) hier wesentlich robuster ist, verspreche ich mir auch geringere Timing-Probleme für den 1-Wire-Bus. Wenn das fertig ist, würde ich mich freuen, wenn ich Dich als Tester gewinnen könnte. Allerdings ist die neue Firmware inkompatibel, Du müsstest dann neu parametrieren...

Gruß, Waldemar

[Sisamiwe]

mumpf

Hallo Waldemar,
ich laboriere immer noch mit dem Außenmodul mit angeschlossenen SHT31 und aktiviertem 1wire mit 2xDS18B20.

In der FW-Version < 3.8 kam es immer mal wieder vor, dass das ganze Modul ausgestiegen ist und nur mit Trennung vom Bus wieder lauffähig gemacht werden konnte.

In FW 3.8 hat sich das Verhalten verändert: Das Modul stützt nicht mehr komplett ab, aber es kommt in unregelmäßigen Abständen vor, dass immer die gleichen Werte auf den Bus gesendet werden. Mit einem "Gerät zurücksetzen" (SW Reset) kommen dann sofort wieder aktuelle Werte.

Könntest Du für künftiges Release hier noch nocheinmal im Code schauen?
Kann ich irgendwie eine SW-Reset von außen ohne ETS (automatisiert) auslösen?

Danke und beste Grüße
MIchael

[mumpf]

Hi mike,

danke für den ausführlichen Bericht, auch wenn ich glaube, dass Du ein anderes Problem beschreibst. Es gibt ein sporadisches (wenn auch sporadisch häufiges) Problem beim partiellen Programmieren, wenn nur GA geschrieben werden (also keine Parameter). Dann gibt es auch einen solchen Hänger.

Letztendlich habe ich - da mein Wissen um den KNX-Stack und die dortige Flash-Behandlung begrenzt ist - im OpenKNX-Projekt daran mitgearbeitet, dass wir meinen Fork von knx-Stack loswerden und wieder auf dem selben Stand sind wie der knx-Stack von thesing. Dort ist das Flash-Handling neu (und hoffentlich schneller) und die TPUART-Implementierung wesentlich weiter als in meinem Fork. Ich hatte jetzt schon länger keine solchen Hänger mehr und meine Buslast ist zumindest nicht gering .

Insofern muss ich euch um Geduld bitten, es wird besser, ich brauche nur Zeit... im alten Stack werde ich das nicht mehr korrigieren.

Vielleicht noch zum aktuellen Stand der Portierung vom Sensormodul auf OpenKNX:
- Logik läuft
- BME280 läuft
- BME680 läuft noch nicht
- SCD40 hab ich schon mal Werte gesehen
- alle anderen Sensoren noch nicht getestet
- 1-Wire ist compilierbar, noch nichts getestet

Deswegen macht auch kein Beta-Test Sinn, ich muss alle Sensoren wenigstens selber mal am Laufen haben. Ich werde schon noch so um die 2 Monate brauchen, sorry.

Gruß, Waldemar

-

[mike]

ich bin heute wieder über einen Hänger beim Programmieren gestolpert...

Ich hatte das auch schon mal beobachtet und näher Analysiert. Der "Hänger" ist ein Absturz (Hard-Fault). Danach ist ein Reset oder Neustart erforderlich. Was man programmiert ist völlig egal. Es kommt auf das Timing und die Buslast an.

Leider finde ich den Trace von dem Fall nicht mehr. Daher hier als "Erzählung":
Vom Bus kommen Daten die in den Flash geschrieben werden sollen (das Gerät wird gerade programmiert). Beim Empfang der Daten wird mit dem Schreiben des Flashes begonnen. Das dauert lange (ich glaube das waren so um die 70ms). Wenn nun während der Zeit keine weiteren Pakete vom Bus kommen passiert nichts.
Kommen jedoch Pakete, dann werden die vom Arduino-Serial in den 64Byte-Input-Buffer geschrieben.
(Minor) Problem Nr1.: Die Pakete können nicht bestätigt werden (KNX.loop() läuft ja nicht). Ist ein Paket für uns bestimmt, dann wird das der TPUART nicht mitgeteilt und diese Bestätigt daher nicht am Bus. Es kommt zu Paketwiederholungen.
Problem Nr2.: Der Puffer füllt sich. Irgendwann ist er voll. Jetzt wird nur noch das letzte Byte ausgetauscht. Im Puffer steht ab jetzt Müll.

Das Flashen ist vorbei und KNX.loop() beginnt die Daten aus dem Puffer auszuwerten. War ein Paket für uns, dann sagt er der TP-UART jetzt (und damit viel zu spät bzw. völlig aus dem zeitlichen Kontext) das das Paket bestätigt werden soll. Die TP-UART empfängt aber gerade vielleicht ein anderes Paket, das dadurch Bestätigt wird, obwohl es nicht für uns ist.
Jetzt gibt es auch wieder Platz im Puffer und Daten vom Bus können nachrücken. Das ist immer noch Müll, da wir uns gerade irgendwo mitten in einem Paket befinden können.
Das Paket am Anfang des Puffers sieht aber gut aus und wird intern verarbeitet. Daduch vergeht evtl. auch wieder Zeit in der der Puffer erneut am Limit anschlagen kann.

Im Endeffekt steht im Puffer jetzt Müll. Der Müll besteht aus Fragmenten valider TPUART-Messages.

Jetzt endlich kommt KNX.loop() an den Müll. Wenn wir Glück haben, dann wird das per CRC erkannt. Aber manchmal ist der CRC auch bei Müll korrekt und die Daten werden weiterverarbeitet. Dort oder evtl. auch vor der CRC-Kontrolle passiert nun irgendwo der Hard-Fault. Wenn ich herausbekommen hätte wo das ist, dann hätte ich das gefixt. Leider passiert das aber nicht so oft, als das man das leicht analysieren könnte.

Allerdings ist mit https://github.com/thelsing/knx/pull/184 das Problem dahingehend abgemildert, das der Buffer-Overrun erkannt wird und die Daten verworfen werden.

[kmmt]

Hallo Waldemar,

das kann warten, schönen Urlaub

Karl

[doenke]

Hallo Waldemar,

das passt für mich prima, danke für die Antwort. War jetzt auch eher als "Finde den Weg zum Fehler" gedacht, als das ich ein Problem habe, welches dringend gelöst werden muss.
Ich bin auf den OpenKNX Stack gespannt.

Schönen Urlaub noch!

Grüße,
Sönke

[mumpf]

Hallo ihr beiden,

ich bin noch 2 Wochen im Urlaub, kann dann erst schauen.

kmmt Da hab ich wohl intern einen falschen Datentyp genommen, das bekomme ich hin.

doenke Da das selten passiert, würde ich dich gerne auf die bald kommende OpenKNX Version vertrösten. Wobei wir hier eher von 2 Monaten als 2 Wochen reden... Die Lösung erfordert nämlich den Austausch vom KNX Stack, und genau das ist bei OpenKNX bereits passiert. Im alten Stack ist das nicht mit vertretbarem Aufwand zu lösen. Als Workaround bis dahin kann ich nur komplette App programmieren empfehlen, zumindest wenn nur GA geändert wurden.

Gruß, Waldemar
PS: Sorry, habe 1W wirklich nicht mit negativen zahlen getestet.

[kmmt]

Guten Morgen,

ich lese hier schon eine ganze Zeit mit.
Ich habe mir 2 WP-Module Ver 3.1 aufgebaut, SW Ver. 3.8, Gerätetyp §006A, Fingerprint 4077, Firmware(3)8.0, WP-Sensor-One Wire-Logik V3.8,
One Wire läuft zeigt mir aber bei Minustemperaturen einen Wert von 32xxx an. Auch im ETS-Gruppenmonitor.

Gruß
Karl

[doenke]

Hi Waldemar,

ich bin heute wieder über einen Hänger beim Programmieren gestolpert...


Ich habe einen inaktiven Eingang aktiviert (DPT 9 mit Wertintervall), den Logiktyp von ODER auf UND geändert und partiell programmiert. Das hat funktioniert.
Dann ist mir aufgefallen, dass ich das neue KO noch nicht verknüpft hatte. Das war fix erledigt und ich habe erneut partiell programmiert. Dabei ist das Modul dann hängen geblieben.

Schreib doch mal, falls Du einen Gruppenmonitor-Mitschnitt von so einem Fall hast oder nähere Infos, wie man das reproduzieren könnte, wir können dann auch gerne eine Online-Session machen und ich schaue mal, ob ich direkt was erkenne (bei einem reproduzierbaren Fall).

Ich habe von beidem ein Gruppenmonitor Log.
Hilft Dir ein Gruppenmonitor-Log um das Problem einzukreisen? Oder klingt das ganz verdächtig nach dem bekannten Fall?
Darf ich Dir das Log per PM schicken? Natürlich können wir auch per Skype oder Teams oder so drauf schauen, falls das effektiver ist.

Nachdem ich das Modul resettet hatte, war dann auch ein partielles Programmieren erfolgreich.
Reproduzieren ist also leider nicht...


Beste Grüße und vielen Dank schonmal,
Sönke

[sk73]

Da ich bei einer Messtechnikfirma arbeite könnte ich jetzt ganz viel zu dem Aufwand schreiben den wir betreiben um temperaturen genau zu messen, aber in der Praxis ist das alles für die Katz.
Die Temperature in einem Raum ändert sich schon mit der Messhöhe da die wärmer Luft leichter ist und hochsteigt.
Über dunklen Flächen bei Sonneneinstrahlung ist es Wärmer. ...
Es gibt viel zu viele Einflussfaktoren die eine korrekte Messung immer nur unter Nennung der Randbedinungen möglich macht. DIE Temperatur in einem Raum/Körper gibt es nicht.

Wichtig ist dass du deinen Sensor so positionierts, dass er die für dein empfinden mit verantwortlichen Einflüsse mitbekommt und du dann eine angenehme Solltemperatur wählst. Was dabei auf der Anzeige steht ist aus meiner Sicht unerheblich.

Ich nehme lieber die 20,4 die mir der Glastaster auf ca 1,30 Höhe anzeigt als die 22,4 die an der Decke gemessen werden. Die Sensoren im Fußboden schwanken noch stärker abhängig davon ob die FBH heizt oder kühlt oder die Sonne drauf scheint.

Gruß
Stefan

[marhal]

Hallo Waldemar,

vielen Dank für deine Erklärung ! Das hilft mir dann schon weiter. Wie gesagt super Arbeit.

gruß
Marhal

[mumpf]

Hi Marco,

Meine Frage wäre jetzt wie habt ihr das gemacht das eure Messdaten passen ? Man kann ja nicht von ausgehen, das das Temperatur-Hydrometer was ich als vergleich habe, die Werte richtiger anzeigt ?

das ist die alte Frage, die es schon immer gibt. Wer sagt Dir denn, dass Dein Quecksilber-Thermometer, das draußen hängt, dir die Richtige Temperatur anzeigt? Kann keiner wissen! Du verlässt Dich darauf, dass der Hersteller das schon irgendwie geeicht haben wird. Und der verlässt sich darauf, dass das Röhrchen, in dem das Quecksilber steigt, mit der versprochenen Toleranz gefertigt wurde, dass die Quecksibler-Ausdehnung auch den entsprechenden Höhenanstieg bringt.

Langer Rede kurzer Sinn: Alle Werte sind irgendwie relativ. Die Tatsache, dass Temperaturen auf Digitalanzeigen mit 2 oder 3 Stellen hinter dem Komma angezeigt werden, bedeutet nicht, dass diese Werte genau sind.

Was haben wir gemacht? Wir verlassen uns darauf, dass die Sensoren die korrekten Werte liefern. Bei den Toleranzangaben zum BME280 steht

Neben der Messung der Luftfeuchte mit ±3% Genauigkeit und der einer Temperaturmessung von ±1.0°C Genauigkeit ...

Das bedeutet, dass Du 2 Sensoren nebeneinander legen kannst und der eine 20°C und der andere 22°C misst und beide einen "richtigen" Wert liefern!!!!
Um diesen Umstand etwas abzumildern, gibt es die Möglichkeit, das in der ETS zu "bereinigen" und einen Offset einzustellen.

Die andere Frage wäre bei der Einstellung bei der Luftfeuchte da ich die Abweichung in % angeben kann. Ich dachte das wären die Prozente

Die Offsets sind immer absolute angaben. Da man Luftfeuchte in % misst, gibst Du mit -2% an, dass ein um 2 kleinerer Wert auf den Bus geschrieben wird als vom Sensor geliefert. Bei gelieferten 50% werden also 48% gesendet und nicht 49% (was -2% von 50 wäre).

Gruß, Waldemar

[marhal]

Hallo alle zusammen,

ich habe einmal eine Frage zu der Kalibrierung der Sensoren.
Ich habe von Marfi die Hardware mit Version 3.1 und habe von mumpf die aktuelle Firmware aus dem Github installiert.
Läuft alles soweit Also großes Lob an euch beiden. Jedoch habe ich festgestellt das meine Messwerte nicht ganz passen. Bei mir ist die Temperatur und die Luftfeuchtigkeit einiges niedriger als ein Temperatur-Hydrometer was ich zum vergleich genommen habe. Aber das kann man ja alles in der ETS nach kalibrieren.

Meine Frage wäre jetzt wie habt ihr das gemacht das eure Messdaten passen ? Man kann ja nicht von ausgehen, das das Temperatur-Hydrometer was ich als vergleich habe, die Werte richtiger anzeigt ?

Die andere Frage wäre bei der Einstellung bei der Luftfeuchte da ich die Abweichung in % angeben kann. Ich dachte das wären die Prozente die er dazu rechnet aber das kommt nicht wirklich hin Könnt ihr mir da helfen und sagen wie da die Idee hinter steckt ?

Gruß
Marco