Alternative Firmware für das Raum-Sensormodul von Masifi

[mumpf]

Hi,

SGP30 ist gar nicht implementiert, aber es ist leider trotzdem ein Fehler drin. Ich weiß nur noch nicht, warum... Als ich damals eingecheckt habe, hat es noch funktioniert. Jetzt fehlt eine abhängige Library, ich bin mir sicher, die wurde früher automatisch nachgeladen.

Füg mal bitte in die platformio.ini in Zeile 45 folgendes ein:

  adafruit/Adafruit Unified Sensor @ ^1.1.4

Das sollte dann so aussehen:

lib_deps = 
  SPI
  Wire
  adafruit/Adafruit Unified Sensor @ ^1.1.4
  adafruit/Adafruit BME280 Library @ ^2.1.2
  adafruit/Adafruit SleepyDog Library @ ^1.4.0
  sparkfun/SparkFun SCD30 Arduino Library @ ^1.0.10
  pololu/VL53L1X @ ^1.2.1

Und wenn es dann klappt, wäre ein Feedback gut, damit ich das noch für alle korrigieren kann.

Gruß, Waldemar

[wegwerf]

Sorry hat leider nicht geholfen, immernoch der selbe Fehler:

src\Sensormodul.cpp:9:10: fatal error: SensorSGP30.h: No such file or directory

************************************************** *******************
* Looking for SensorSGP30.h dependency? Check our library registry!
*
* CLI > platformio lib search "header:SensorSGP30.h"
* Web > https://platformio.org/lib/search?query=header:SensorSGP30.h
*
************************************************** *******************

#include "SensorSGP30.h"
^~~~~~~~~~~~~~~
compilation terminated.

[mumpf]

Hi,

kann es sein, dass Du nicht alle Projekte auf den beta-branch gebracht hast, sondern nur das knx-sensor projekt? Du musst genau nach der Anleitung https://github.com/mumpf/knx-sensor/...-beta-setup.md vorgehen, es geht speziell um diesen Teil:

git clone https://github.com/mumpf/knx.git
git clone https://github.com/mumpf/knx-common.git
git clone https://github.com/mumpf/knx-logic.git
git clone https://github.com/mumpf/knx-wire.git
git clone https://github.com/mumpf/knx-sensor.git
cd knx
git checkout release
cd ..\knx-common
git checkout beta
cd ..\knx-logic
git checkout beta
cd ..\knx-wire
git checkout beta
cd ..\knx-sensor
git checkout beta
code Sensormodul.code-workspace

Nur so kann ich mir die obige Meldung erklären. Im Zweifelsfall (falls Du Dich mit git nicht so gut auskennst), alles löschen und die gesamte Anleitung nochmal durcharbeiten.

Ich habe die Anleitung komplett nachgemacht und es hat funktioniert (mit der Ergänzung in der platformio.ini im knx-sensor Projekt).

Gruß, Waldemar

[wegwerf]

Oh man, danke Waldemar für den Hinweis.
Habe tatsächlich nur das knx-sensor repository auf beta gestellt. Jetzt ist es durchgelaufen.
Auch ohne der zusätzlichen Library

adafruit/Adafruit Unified Sensor @ ^1.1.4

[mumpf]

Hi,

freut mich, dass es jetzt klappt. Allerdings verstehe ich dann nicht, warum es ohne die zusätzliche Lib bei mir nicht lief. Ich schau nochmal...

Gruß, Waldemar

[Sisamiwe]

mumpf

Hallo Waldemar,

ich habe ein Außensensormodel V1.4 mit Deiner Firmware in Betrieb genommen.
Angeschlossen sind 1x SHT30 und 1x VL53VL1X am I2C und 1x DS18B20 am 1wire. Die beiden I2C sind via YSTY 2x2x0,6 in etwa 2m bzw 5m Entfernung angeschossen. Geladen ist der Firmware 3.0 Beta.

Nach einer gewissen Zeit steigt das Modul aus und ist per KNX nicht mehr erreichbar. Nach Trennen und Wiederverbinden der KNX-Verbindung funktioniert es wieder für eine gewisse Zeit. Wenn es nicht mehr erreichbar ist, wird mit den Onboard-LEDs ein Code ausgegeben. Die Betriebs-LED (grün) geht an und die Prog-LED blinkt 5x. Danach geht die Betrieb-LED aus. Nach kurzer Zeit kommt der gleiche Code wieder.

Kannst Du eine Ferndiagnose stellen bzw. was bedeutet der LED-Fehlercode?

Danke und Gruß!

[mumpf]

Hi Michael,

ein Grund, warum es derzeit keine neuere Firmware gibt, sind gelegentliche Hänger bei 1-Wire. Deswegen vermute ich das auch in Deiner Konstellation, obwohl es bei mir noch nicht mit dem DS18B20 passiert ist. Andererseits könnte es auch an der langen I2C-Leitung liegen, dafür ist I2C nicht wirklich ausgelegt. Das 5-Fach-Blinken deutet auch auf einen Fehler auf dem I2C-Bus. Allerdings kann ich das nicht 100% sagen, da ich das Fehler-Blinken zwischenzeitlich umgebaut habe, sorry.

Was ich Dir in der Zwischenzeit anbieten kann: Ich schicke Dir einen Patch für den I2C-Bus, damit kann der Watchdog auch Probleme auf dem I2C-Bus erkennen und lösen. Damit würde es keine Hänger mehr geben... allerdings ist damit die Ursache nicht gelöst.

Du kannst noch folgendes prüfen:

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

Ich teste I2C-Devices nur lokal, also direkt angeschlossen...

Das mit dem Patch dauert (leider) noch bis zum Wochenende, sorry.

Gruß, Waldemar

[Masifi]

Sisamiwe, das Modul wurde definitiv nicht auf 2m und 5m I2c längen ausgelegt.
Eigentlich sollte der I2c nicht mehr als ein paar Zentimeter das Gehäuse verlassen.
Vorallem Wenn mumpf hier mit 400khz I2c Speed arbeitet.

Ich kann dir hier nur Raten den 5m Ast wie Waldemar beschrieben zu verkürzen und Dort den KNX zu verlängern, oder nimm einfach ein 2. Außenmodul. Dann bist du auf der sicheren Seite.

[mumpf]

Hi Michael,

noch ne Möglichkeit (auch wenn ich nicht glaube, dass das wirklich hilft):

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

uint8_t SensorVL53L1X::getI2cSpeed()
{
    return 4; // n * 100kHz
}

beim   return 4;  die 4 gegen 1 austauschen. Dann wird der I2C mit 100 kHz betrieben, das macht ihn weniger Störanfällig.

Nochmal zum Hintergrund: I2C ist für die Kommunikation innerhalb von Geräten konzipiert. Alle Geräte sind als State-Machines ausgelegt, Die Kommunikation schaltet von Zustand zu Zustand. Geht irgendwas bei der Kommunikation schief, sind die Zustandsautomaten außer Sync und der ganze Bus bleibt hängen. Somit können bereits Bitfehler auf dem I2C zu Problemen führen. Der I2C-Bus ist bei weitem nicht so robust wie der KNX-Bus, selbst der 1-Wire ist da robuster... Aber er ist erheblich schneller und wird für moderne Sensoren verwendet.

Gruß, Waldemar

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

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

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.

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

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,

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