Alternative Firmware für das Raum-Sensormodul von Masifi

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

[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

[kmmt]

Hallo Waldemar,

das kann warten, schönen Urlaub

Karl

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

[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

-

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

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]

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]

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

[kmmt]

Guten Morgen,
ich wollte nochmal in Erinnerung bringen zu meinem Post vom 07.06.2022
Gruß
Karl

[mumpf]

ich wollte nochmal in Erinnerung bringen

Ja, ich verstehe, es wird ja kälter... Ich schau mir das gleich am Wochenende an.

Gruß, Waldemar

[mumpf]

Hi,

ich wollte nochmal in Erinnerung bringen zu meinem Post vom 07.06.2022

ich habe inzwischen mal nachgeschaut und einen Kommentar gefunden, dass ich nur von positiven Werten ausgehe, weil es sich ja immer um Innenräume handelt. Es ist somit kein Datentyp-Problem und ich muss nochmal den Codingteil analysieren. Ich brauche aber noch etwas, um meine 1-Wire-Testhardware wieder aufzubauen, das ist derzeit abgebaut.

Ich wollte nur sagen, dass ich das nicht vergessen habe.

Gruß, Waldemar

[Lexxs]

Hi alle zusammen,

ich wollte mich bei euch melden da ich seit geraumer Zeit folgende Problematik besitze:

Hardware/Software:

- Sensormodul v3.1
- Firmware: .knxprod: v3.8 mit dazugehörigen Firmware


Die derzeitig verwendeten Sensormodule v3.1 inkl. 1-Wire mit aktuellster Firmware, senden (keine) Temperaturmesswerte über die 1-Wire Schnittstelle...

Im Detail heißt dies, dass nur einer der drei 1-Wire DS18B20 Sensoren, die am Sensormodule angeschlossen sind (Sensormodul v3.1) Temperaturmesswerte sendet und die anderen zwei wiederum nicht.
Wird manuell die GA der nicht automatisch gesendeten Temperaturmesswerte in der ETS6 ausgelesen erhalte ich eine realistischen Wert zurück, jedoch werden diese nicht wie in der .knxprod eingestellt bei einer Temperaturdifferenz von 0,1 °C automatisch auf den KNX-Bus gesendet.

Diese Phänomen ist wiederum an einem weiterem identisch aufgebautem Sensormodul v3.1 ebenso der Fall, nur das an diesem zwei anstelle von drei 1-Wire DS18B20 Temperaturtsensoren angeschlossen sind. An diesem Modul sendet nur eins der zwei 1-Wire DS18B20 Sensoren automatisch wie eingestellt Tempertaturmesswerte. Aber auch hier wird ein korrekter Temperaturmesswert nach manuellem Auslesen auf den KNX-Bus gesendet.

Wann genau die 1-Wire Temperatursensoren nicht mehr automatisch auf den KNX-Bus senden kann ich bedauerlicherweise nicht mehr sagen, somit weiß ich ebenso nicht ob es damals durch das Firmwareupdate passiert ist oder ähnlichem.


Hatte jemand zufälligerweise die selben Probleme gehabt und könnte mir einen Tipp oder Lösungsvorschlag geben?



Gruß Lex

[mumpf]

Hi Lex,

Danke für die Meldung. Als Workaround würde ich es mit zyklisch senden versuchen.
Das andere werde ich kontrollieren und versuchen, es zu reproduzieren. Allerdings wird es die Korrektur nicht mehr für 3.8 geben. Ich werde allerdings sehr bald eine OpenKNX-Version der Sensormodul-Software herausbringen. Dort würde ich eine Korrektur machen - falls sich dieser Fehler mit der neuen Firmware reproduzieren lässt.

Gruß, Waldemar

[Lexxs]

Vielen Dank für die schneller Rückmeldung.
Ich warte auch schon sehnsüchtig auf die OpenKNX Version 😍 in der Hoffnung das es eventuell dann gar nicht mehr auftritt.
Das zyklische hatte ich mir auch bereits schon überlegt, da ich aber die Messwerte per InfluxDB logge währen das immens viele Datenpunkte die eigentlich gar nicht benötigt werden. Mir fällt aber gerade beim schreiben auf, dass ich die zyklisch gesendeten Messwerte mit einer Logik miteinander vergleichen könnte ob der Wert größer als der vorherige Wert ist. Muss schauen ob ich es schnell hinbekomme...

Gruß zurück Waldemar