Alternative Firmware für das Raum-Sensormodul von Masifi

[Ferengi]

Da ich vor ein Paar Tagen mein erstes Sensormodul von Masifi erhalten hab (bis jetzt ist nur ein 1-Wire Temp-Sensor angeschlossen) wollte ich auch hier danke für die tolle Software sagen.
Flashen und Programmieren über ETS hat auf anhieb geklappt, und bis jetzt ist mir nix negatives aufgefallen.

[stmeyer]

Hi Waldemar,
hier, wie in der PN angekündigt, ein Bild der Messwerte des Tof-Sensors der letzten 24 Std. Der hat schon viele Ausreißer…

1293226D-7B00-4A1B-8218-7D734B6D0BD0.jpeg

[ReinerDaniel]

Hallo Waldemar,

hier mal ein kurzes Update. Alle Module mit beta und Patch laufen jetzt ohne Hänger. Ich schicke mal als Anlage ein Log mit.
Die "plötzliche" Veränderung der Werte gegen 04:00 könnte eventuell ein Reset des Moduls sein. Sonst sehe ich keine Auffälligkeiten.
Spielt aber für mich keine Rolle.
Läuft jetzt stabil und gut.

Liebe Grüße Matthias

[jgerhart]

Ich habe mal in meiner DB gekramt und für 2 Sensormodule die 0-Werte herausgesucht.
Bei beiden Modulen ist lediglich ein BME680 angeschlossen, kein 1-Wire Sensor.
Interessant ist, dass es nur beim Luftdruck keine 0-Werte gibt. Bei allen anderen schon. Es sind wirklich 0.0 Werte, da ich alle Ergebnisse als float in der DB speichere.

Sensormodul 2 ist einige Tage nach Sensormodul 1 in Betrieb gegangen.

Ach ja, die Module sind so konfiguriert, dass sie alle 5 Minuten die Werte auf den Bus senden.

Hier die 0-Werte der beiden Sensormodule jeweils mit Datum/Uhrzeit:

0-Werte BME680-1

Temperatur
2021-05-10 10:59:25
2021-05-11 03:39:44

Luftfeuchtigkeit
2021-04-29 06:33:19
2021-04-30 19:19:03
2021-05-02 17:15:01
2021-05-11 01:24:42
2021-05-11 07:49:48
2021-05-14 06:55:58
2021-05-14 11:31:04
2021-05-15 18:01:35
2021-05-26 03:59:32
2021-05-26 04:14:32

Luftdruck
n/a

VOC
2021-05-03 08:05:20
2021-05-10 18:44:36

Berechneter CO2
2021-05-12 10:20:12

0-Werte BME680-2

Temperatur
2021-05-05 18:16:14
2021-05-10 10:03:37
2021-05-10 23:43:57
2021-05-14 18:50:35
2021-05-17 19:46:02
2021-05-18 19:56:30
2021-05-23 16:48:53
2021-05-23 17:08:53
2021-05-28 18:36:19
2021-05-29 17:31:51
2021-05-29 18:01:51

Luftfeuchtigkeit
2021-05-13 03:44:51
2021-05-14 09:55:26
2021-05-29 08:36:38

Luftdruck
n/a

VOC
2021-05-05 19:51:17
2021-05-06 20:56:47
2021-05-06 21:01:47
2021-05-09 22:28:24

Berechneter CO2
2021-05-09 07:07:59
2021-05-10 12:08:41
2021-05-22 14:48:21

[Sisamiwe]

Hallo,

P.S.: Waren die Werte 0.0 oder irgendwas "ungefähr 0"?

Bei mir war es genau "0".

Bzgl des Busmonitors, ja ich meinte den Gruppenmonitor. Ich schaue mir das nochmal an. Bin aber grad nicht zu Hause.

Beste Grüße

[mumpf]

Hi,

Es gab Einträge, da kam die 0 Bus zu 5x in einer Stunde, dann wieder mehrere Stunden nicht.

Ok, das sieht zumindest so aus, dass ich es hinbekomme, das im Debugger nach "endlicher" Zeit nachzuvollziehen. Ich kann nichts kurzfristiges versprechen, aber ich verfolge das mal.

allerdings wurde bis dahin kein anderer Wert selbstständig gesendet.

Das ist so... ich schreibe intern jeden neuen Wert ins KO, damit man bei einem Lesetelegramm immer den aktuellen Messwert bekommt. Gesendet wird der Wert aber nur anhand der eingestellten Bedingungen. Deswegen verstehe ich auch nicht, wieso eine 0 gesendet werden könnte. Aber wie gesagt, ich werde das verfolgen.

Wenn ich den Busverkehr im ETS Busmonitor anschaue, stimmen die DPT der KOs nicht.

Hmm, ich hoffe, Du meinst den Gruppenmonitor. Mit dem Busmonitor arbeite ich kaum, deswegen kann ich da nicht so viel dazu sagen.
Um die Richtigen DPT im Gruppenmonitor zu bekommen, stelle ich den DPT sowohl an der GA wie auch am KO ein. Das liegt daran, dass ich nicht genau weiß, welchen der beiden die ETS für den Gruppenmonitor nutzt. Das hat aber nichts mit dem Sensormodul zu tun, die ETS-Applikation hält sich da an die Vorgaben der ETS.

Für das Sensormodul (also die KO der Standardsensoren) sollten die DPT aber stimmen, zumindest habe ich die Defaults korrekt gesetzt. Beim Logikmodul geht das logischerweise nicht, da kann ich nur den DPT Hauptdatentyp setzen und nicht den Untertyp.

Gruß, Waldemar

P.S.: Waren die Werte 0.0 oder irgendwas "ungefähr 0"?

[Sisamiwe]

Hallo,

könnt ihr mir sagen, wie oft das passiert? Wie lange muss ich das mit einem Debugger laufen lassen, damit das passiert? Stunden? Tage? Wochen?

Lt den Aufzeichnungen sollte es si h im Bereich von Tagen bewegen. Es gab Einträge, da kam die 0 Bus zu 5x in einer Stunde, dann wieder mehrere Stunden nicht.


Waldemar, du hattest gefragt, wann danach mit "Werte anfordern" richtige Werte kamen. Ich denke, dass ich die Werte mehr als 10s nach dem Empfang der 0 angefordert habe, allerdings wurde bis dahin kein anderer Wert selbstständig gesendet. Besser kann ich es im Moment nicht sagen.


Noch was.....
Wenn ich den Busverkehr im ETS Busmonitor anschaue, stimmen die DPT der KOs nicht. Sind die DPTs in der Nachricht kodiert, oder wo stelle ich die ein?
Den Gruppenadressen have ich das richtige DPT zugewiesen.

Beste Grüße

[mumpf]

HI,

0-Werte habe ich auch ab und zu.

könnt ihr mir sagen, wie oft das passiert? Wie lange muss ich das mit einem Debugger laufen lassen, damit das passiert? Stunden? Tage? Wochen?

Hier ist der Filter für die 0 (genauer: -0,01 bis 0,01 werden rausgefiltert):
Null-Filter-Bild-1.PNG

Null-Filter-Bild-2.PNG

Null-Filter-Bild-3.PNG

Der Sensorausgang wird mit dem Eingang der Logik verbunden, der Logikausgang ist dann der gefilterte Messwert.

Gruß, Waldemar

[jgerhart]

Hallo Waldemar,

0-Werte habe ich auch ab und zu. Ich schreibe momentan alle Werte in eine Datenbank, da fällt das dann auf. Ich hatte das aber auf meine unzureichenden Node-Red Kenntnisse geschoben, da ich darüber die Werte sammle und in die DB übertrage.
Wenn es eine Möglichkeit gibt, 0-Werte auszufiltern, würde ich die gerne kennen.

Viele Grüße
Jens

[mumpf]

Hi Michael,

Damit läuft das Modul (mit 400kHz I2C) stabil.

Und 1-Wire? Also mit dem DS18B20? Das passt dann ins Bild (dass es an den langen I2C-Leitungen liegt). Es freut mich, wenn das klappt, aber für alle:

Das verlängern vom I2C-Bus ist "at your own risk". Der ist eigentlich dafür nicht gemacht. Wir sind im DIY-Forum, und ich bin froh darüber, wenn wir uns hier über solche Versuche austauschen, aber es ist leider so: Nur weil es bei einem klappt, muss es nicht bei einem anderen auch klappen. Gegen ausprobieren spricht aber nichts.

Des Test mit 100kHz habe ich nicht gemacht. Ich wollte im Standard bleibe, so dass spätere Firmwareupdates einfach möglich sind.

Das ist sogar ein bisschen schade... Denn das hätte gezeigt, ob man den Bus durch geringere Frequenzen länger gestalten kann. Und nur so für die Zukunft: Natürlich hätte ich Dich nicht hängen lassen: Wenn Du rausfindest, dass es mit 100 kHz geht, dann hätte ich eben bei den Einstellungen in der ETS-App was eingebaut, um wählen zu können.

Wie geschrieben, das Modul sendet sporadisch eine 0; fordert man die Werte direkt danach an, kommt die "richtige" Temp.

Das verstehe ich nicht. Wie schnell ist "direkt danach"? Innerhalb von 10 Sekunden? Sonst wurde wieder ein neuer Wert ins KO geschrieben, es wird aber nicht jeder Wert gesendet.

Nutzt Du vielleicht die "Glättung"? Da gab es mal einen Fehler mit sporadischen 0-Werten, allerdings dachte ich, dass der raus ist...

Also für die Nullen habe ich noch keine gute Erklärung geschweige denn Lösung, aber ich könnte Dir eine Kleine Logik verraten, mit der man die 0-Werte ausfiltern kann. Allerdings klappt das nur, wenn die erwarteten Werte alle ungleich 0 sind. Oder sagen wir es so: Die 0 würde ausgefiltert werden, egal ob sie wirklich gemessen wurde oder nur falsch gesendet wurde. Wenn Du so was willst, sag Bescheid.

Gruß, Waldemar

[Sisamiwe]

Hallo Waldemar,

• funktioniert der "lange" I2C-Bus ohne 1-Wire
• mit 1-Wire gibt es hänger

Das ist richtig.

Mittlerweile habe ich kürzere I2C Busse getestet. Beide sind nun nur noch 1,5m lang. Damit läuft das Modul (mit 400kHz I2C) stabil. Erreicht habe ich das durch Verlängerung des KNX. Das Modul ist nun physikalisch schlechter erreichbar, aber ok.

Des Test mit 100kHz habe ich nicht gemacht. Ich wollte im Standard bleibe, so dass spätere Firmwareupdates einfach möglich sind.


Zu dem anderen Thema:

Kommt die 0 bei 1-Wire oder bei den anderen Sensoren?

Das kommt von SHT30 bzw. BME280/BME680

Hast Du derzeit den Watchdog an?

Watchdog ist aus.

Wie geschrieben, das Modul sendet sporadisch eine 0; fordert man die Werte direkt danach an, kommt die "richtige" Temp.


Beste Grüße
Michael

[mumpf]

Hi Michael,

so wie ich Dich verstehe

• funktioniert der "lange" I2C-Bus ohne 1-Wire
• mit 1-Wire gibt es hänger

Es wäre natürlich immer noch interessant zu verstehen, ob kurzer I2C-Bus und 1-Wire gehen bzw. langsamer (100kHz) aber langer I2C-Bus und 1-Wire gehen.

Dass es auf der 1-Wire-Seite (also am Sensor) liegt, glaube ich nicht. Da hätte es keine Werte vom DS18B20 gegeben, aber keine Hänger. Vielleicht noch zur Info: Auch 1-Wire ist über den I2C angeschlossen, das Modul hat einen 1-W zu I2C-Chip verbaut. Durch die Art der Abfrage bei 1-Wire muss aber viel häufiger mit dem 1-W-zu-I2C-Chip kommuniziert werden als zu reinen I2C-Sensoren. Dadurch wird der gesamte I2C-Bus mehr beansprucht und somit kann es eher zu Kommunikationsproblemen kommen. Deswegen wäre auch der Test mit den 100 kHz sinnvoll. Sollte das klappen, könnte ich in der ETS-Applikation noch einen Schalter einbauen, so was wie "Langer I2C-Bus", der die Kommunikation auf 100 kHz runterschaltet. Bei 1-Wire sind da aber dann nur noch Sensoren möglich, keine iButtons bzw. IO-Bausteine (beide laufen sowieso in der Beta noch nicht zufriedenstellend).

Mir ist noch eingefallen, dass Du statt die Software zu patchen für 100 kHz auch einfach den IAQCore als VOC-Sensor einschalten könntest (auch wenn Du ihn nicht dran hast). Intern gibt es zwar dann einige Fehlermeldungen, dass der Sensor nicht da ist, aber der I2C-Bus wird auf 100 kHz gesetzt, weil dieser Sensor nicht mehr kann.

Des weiteren habe ich bei der Analyse der historischen Daten der Sensormodule festgestellt, dass in unregelmäßigen Abständen als TempWert eine "0" gesendet wird.

Kommt die 0 bei 1-Wire oder bei den anderen Sensoren?
Hast Du derzeit den Watchdog an?

Ich bräuchte die Info, um es etwas einzugrenzen.
Gruß, Waldemar

[Sisamiwe]

Im nächsten Schritt werde ich mal einen anderen DS18B20 verwenden, nur um sicher zu gehen, dass der alte kein Fake ist und die Probleme auslöst.

Das hat keine Besserung gebraucht. Das Modul steigt aus.

Ich habe nun den I2C mal temporär verkürzt und 1w wieder aktiviert.

[Sisamiwe]

mumpf


Hallo Waldemar,

für den ersten Test habe ich in der ETS 1w deaktiviert, sonst aber keine Veränderung vorgenommen.
Mit diesen Einstellungen läuft das Modul nun knapp 48h ohne Fehler / Ausfall. Das scheint also zu funktionieren.

Es deutet somit auf den 1w bzw. auf die Kombination von 1w und extremer I2C Länge.
Im nächsten Schritt werde ich mal einen anderen DS18B20 verwenden, nur um sicher zu gehen, dass der alte kein Fake ist und die Probleme auslöst.

Ich werde berichten.


Des weiteren habe ich bei der Analyse der historischen Daten der Sensormodule festgestellt, dass in unregelmäßigen Abständen als TempWert eine "0" gesendet wird.
Fordert man die Werte an, kommt aber der richtige Wert. Bislang konnte ich das nicht mit einem speziellen Sensortyp oder Event korrelieren. Die Module laufen mit der aktuellen Beta oder mit dem letzten Release. Ist Dir das auch schon mal passiert?

[Sisamiwe]

Hallo,

danke für die schnelle Rückmeldung. Masifi mumpf

Ich probiere

• Betrieb ohne 1-Wire (es reicht das Kästchen in der ETS zu deaktivieren, intern wird dann 1-Wire nicht mehr abgefragt) und schauen, ob es dann immer noch Hänger gibt -> Wenn ja, liegt es am I2C, wenn nein, am 1-Wire

• Wenn I2C: Versuche mal, zumindest zeitweise, die beiden Sensoren am I2C mit einer kürzeren Leitung zu betreiben. Wenn irgend möglich, verlängere den KNX-Bus und verkürze den I2C-Bus. Vor allen der 5m-Ast macht mir Sorgen. Zumindest könnte man durch weitere Tests rausfinden, ob es daran liegt.

• Du kannst in knx-common, Datei SensorVL53L1X.cpp, an der Stelle:

aus und berichte.