Ankündigung

Einklappen
Keine Ankündigung bisher.

Alternative Firmware für das Raum-Sensormodul von Masifi

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • mumpf
    antwortet
    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:
    Code:
    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

    Einen Kommentar schreiben:


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

    Einen Kommentar schreiben:


  • mumpf
    antwortet
    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

    Einen Kommentar schreiben:


  • Sisamiwe
    antwortet
    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ß!

    Einen Kommentar schreiben:


  • mumpf
    antwortet
    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

    Einen Kommentar schreiben:


  • wegwerf
    antwortet
    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
    Code:
    adafruit/Adafruit Unified Sensor @ ^1.1.4

    Einen Kommentar schreiben:


  • mumpf
    antwortet
    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:

    Code:
    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

    Einen Kommentar schreiben:


  • wegwerf
    antwortet
    Sorry hat leider nicht geholfen, immernoch der selbe Fehler:

    Code:
    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.

    Einen Kommentar schreiben:


  • mumpf
    antwortet
    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:

    Code:
      adafruit/Adafruit Unified Sensor @ ^1.1.4
    Das sollte dann so aussehen:
    Code:
    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

    Einen Kommentar schreiben:


  • wegwerf
    antwortet
    Hallo Waldemar,
    irgendwie sehe ich wohl den Wald vor lauter Bäumen nicht. Welche librarys brauche ich zum kompilieren des Beta branches? Beim kompilieren stoppt es immer mit dem Fehler das die SGP30 Header fehlen. Release läuft durch.

    Einen Kommentar schreiben:


  • mumpf
    antwortet
    Hi ihr beiden,

    danke für die Rückmeldung. Wobei ich das nicht versehe, eigentlich haben 1-Wire-Modul und Sensormodul nichts miteinander zu tun. Ich muss mal schauen, komme aber frühestens kommendes Wochenende dazu.

    Gruß, Waldemar

    Einen Kommentar schreiben:


  • Lexxs
    antwortet
    Zitat von jgerhart Beitrag anzeigen
    Gerade ist mir noch was aufgefallen, und zwar wird bei der Luftqualität des BME680 0 ausgegeben, wenn ein 1-Wire Temperatursensor DS18B20 aktiv ist. Wenn ich 1-Wire deaktiviere, geht die Luftqualität wieder auf 1. 1-Wire Device-Suche ist jeweils ausgeschaltet. Ich muss dazusagen, dass der DS18B20 mit hoher Wahrscheinlichkeit ein Fake ist und viel zu hohe Temperaturen anzeigt...
    Da ist mir jgerhart zuvor gekommen , dass wollte ich gerade auch melden.

    Einen Kommentar schreiben:


  • jgerhart
    antwortet
    Gerade ist mir noch was aufgefallen, und zwar wird bei der Luftqualität des BME680 0 ausgegeben, wenn ein 1-Wire Temperatursensor DS18B20 aktiv ist. Wenn ich 1-Wire deaktiviere, geht die Luftqualität wieder auf 1. 1-Wire Device-Suche ist jeweils ausgeschaltet. Ich muss dazusagen, dass der DS18B20 mit hoher Wahrscheinlichkeit ein Fake ist und viel zu hohe Temperaturen anzeigt...

    1-Wire mit DS18B20 aktiviert:
    1w DS12b20 aktiviert.png
    1-Wire deaktiviert:
    1w deaktiviert.png

    Einen Kommentar schreiben:


  • jgerhart
    antwortet
    👍

    Einen Kommentar schreiben:


  • mumpf
    antwortet
    Hi Jens,

    Zitat von jgerhart Beitrag anzeigen
    Die Luftqualität bleibt aber ständig auf 1 und ändert sich nicht
    auch diesen Fehler habe ich gefunden und gefixt. Passierte immer, wenn der CO2-Wert berechnet ist (also grundsätzlich bei VOC-Sensoren). Der Fix wird in der nächsten Beta enthalten sein. In Anbetracht der Tatsache, dass die nächste Beta fast fertig ist, werde ich mir sparen, für diesen Fix noch ein Zwischenrelease zu machen .

    Gruß, Waldemar

    Einen Kommentar schreiben:

Lädt...
X