OpenKNX-RaumController release - oder: Aus dem Sensormodul wird ein RaumController

[willisurf]

Ursache ist ein GroupValueRead

Unabhängig von der sinnvollen Suche nach der Ursache, kannst Du durch ein Löschen des A-Flag an dem betreffenden Eingang verhindern, das ein GroupValueRead dort eine Aktion auslöst.
Aber das kennst Du sicher.

[tsb2001]

GroupValueRead dort eine Aktion auslöst.

Ja, das ist klar. Aber am Ende lindert es das Symptom, nicht die Ursache.

[mumpf]

Ok, das ist interessant. Ich schaue mal, was mir dazu einfällt...

Ursache ist ein GroupValueRead der Quelladresse 3.1.11 (Logikmodul bzw. Funktionsblock) auf die passende Gruppenadresse, die am Ende die Rollos wieder hochfahren lässt.

Für die Analyse solltest Du feststellen, ob es vom Logikmodul oder von den FunctionBlocks kommt. Deswegen gibt es bei den Logikkanälen die "Suspendiert" Einstellung (früher "Kanal deaktivieren (zu Testzwecken)". Damit wird ein Logikkanal komplett deaktiviert und macht gar nichts, dabei bleiben aber alle Parameter erhalten.
Suspendiere bitte die relevanten Kanäle vom Logikmodul, die den GroupValueRead auslösen könnten. Wenn es dann aufhört, dann wissen wir schon mal das Modul.

oder ist die Last des Moduls (30 Logiken und 9 Funktionsblöcke) so groß, dass der sporadisch neu startet und dann fiktiv Abfragen startet?

Würde ich ausschließen, wobei ich die Funktionsblöcke nicht entwickelt habe und kenne es nicht in der selben Tiefe wie das Logikmodul.

Trotzdem macht er mit gleicher Zeit des ungeplanten Rollofahrens auch einen "GroupValueWrite"

Hier musst Du unbedingt schauen, ob da vorher irgendein Telegramm auf dem Bus ist, der das triggern könnte.

dass sich das Modul (oder Teile davon) von selbst neu startet

Neustart gibt es nur pro Gerät, nicht pro Modul. Wie traxanos schon geschrieben hat, kannst Du über uptime oder über KO1 rausfinden, ob es einen Geräte-Neustart gab.

Ich habe nur kurz die Telegramme mitschreiben können, aber es tritt häufig auf. Mal nach 10 Sekunden, mal nach 2-8 Minuten. Ich werde mal beizeiten mitloggen und gucken, was da passiert.

Da werden wir nicht drumrum kommen, das ist aus meiner Sicht ein unerwartetes Verhalten. Zumindest beim Logikmodul habe ich sehr viel Aufwand reingesteckt, um jegliches Read und Write passend steuern zu können.

FunctionBlocks sind hier einfacher gestrickt, deswegen müssen wir erstmal wissen, ob es die Logik ist oder die FunctionBlocks sind.

Gruß, Waldemar

[mumpf]

Das zweite Modul sollte mit einem BME280 betrieben werden, doch die Temp Abweichung beträgt hier gute 5 K. Na gut, dachte ich mir, nimmst du halt einen SHT31, der soll ja nicht so extrem driften.

Die Ernüchterung kam jedoch schnell, als auch dieser gute 5 K über meinen Referenzsensoren war. Ich habe dann einen weiteren SHT31 aus einer anderen Bestellung ausprobiert - ihr könnt es euch denken - wieder 5 K drüber.

Wollte hierzu auch noch was schreiben (war vorher im Urlaub): die 3K beim BME680 sind bekannt. Ich hatte das früher mal in der Firmware kompensiert, aber es gab Beschwerden, dass ich den Sensorwert verändere. Deswegen ist das nicht mehr drin und man kann den Offset selber eingeben.
Beim SHT oder BME280 ist mir nichts bekannt (außer der üblichen Sensortoleranz von +-0.5K). Und dass es bei 2 verschiedenen Sensortypen (und damit 2 Implementierungen) um den gleichen Abstand - und so großem Abstand von 5K) abweichen soll, halte ich für sehr unwahrscheinlich. Der Grund muss irgendwas anderes sein, ich hab allerdings keine Idee, was es sein könnte.

Gruß, Waldemar

[LostWolf]

die 3K beim BME680 sind bekannt.

Um 3K zu hoher Wert?
Erklärt meine Beobachtung mit meinen BME680 Sensoren.
War schon an mir (und den Sensoren...) zweifeln, warum gerade die Sensoren so extrem zum Rest abweichen.

Aber wenn das bekannt ist, kann ich da ja getrost "-3" als Offset eintragen.
(passt dann auch der Feuchtigkeitswert noch?)

[r4id]

Der Grund muss irgendwas anderes sein, ich hab allerdings keine Idee, was es sein könnte

Kann ja eigentlich nur noch was an der Hardware sein?

[mumpf]

Ja, ich gebe den Offset an den Sensor weiter, sofern dieser das unterstützt. Die BME280/BME680 unterstützen das auf jeden Fall, beim SHT weiß ich es nicht mehr. Der SCD4x kann das auch. Eine Kompensation in der Firmware wäre auch denkbar, ist aber nicht implementiert. Ich wollte auch nicht hin und her rechnen müssen und dann mit den numerischen Problemen kämpfen.

Gruß, Waldemar

[LostWolf]

Aber interessant, dass da tatsächlich Sensoren ausgeliefert werden die einfach mal 3K zu viel messen.
Warum bessert da der Hersteller nicht nach...
(aber gut, das schweift ab)

[r4id]

Aber interessant, dass da tatsächlich Sensoren ausgeliefert werden die einfach mal 3K zu viel messen.

Naja..., ab hier (#243) gibt es ja nachweislich irgendwelche Probleme.

[mumpf]

tsb2001und bios123: Welche Versionen verwendet ihr aktuell? Wir machen ja immer wieder neue Versionen, weil wir Fehler finden - eventuell hilft einfach ein Update auf die aktuellste Version.

allerdings keine Idee, was es sein könnte.

Zwei Ideen hab ich doch noch : Schließe mal den BME280 oder den SHT31 an das Sensormodul an.

1. Programmiere das Gerät per ETS vollständig (Programmieren->Applikationsprogramm). Falls das Problem danach verschwindet, gab es einen Fehler beim partiellen Proggen und im Speicher ist beim Offset ein Wert 50 stehen geblieben.
2. Trage -50 beim Offset ein (der Wert wird als 1/10K interpretiert) und schaue, ob es jetzt nicht mehr 5K zu viel sind. Falls sich nichts ändert, wird der Offset-Wert von irgendwas anderem überschrieben. Dann hast Du ziemlich sicher eine zu alte Version und solltest ein Update machen.

Gruß, Waldemar