[voerst gelöst] I2C Sensoren "hängen" sich auf (BMP180, SHT21, TSL2561)

Begonnen von Thomas41587, 02 Mai 2018, 12:23:03

Vorheriges Thema - Nächstes Thema

Thomas41587

Hallo zusammen,

ich habe an einem Rspberry Pi 3 über einen I2C Multiplexer (TCA9548A) eine Platine angeschlossen, mit diversen Sensoren (BMP180, SHT21, 3x TSL2561), die ich über FHEM abfrage. Leider kommt es dabei immer mal wieder vor, dass sich eines der devices aufhängt. D.h. in FHEM sieht man als state nicht mehr den jeweiligen Wert, sondern "defined".
Für den TSL2561 habe ich den workaround gefunden, FHEM neuzustarten und die Sensoren kurz spannungslos zu machen.
Für den SHT21 reicht es aus, das IODev auf einen anderen Bus umzustellen (-> "error") und zurück zu stellen (geht wieder alles)
Bei dem BMP180 hilft leider nur device löschen udn neu anlegen, was sehr nervig ist.
Woran liegt das? Was kann ich tun um das Problem zu vermeiden?

Was mir noch aufgefallen ist: Bei dem BMP180 "fehlen" die Werte für Calibration Data, wenn das device wieder mal bei "defined" hängt (zu sehen über "list <gerätename>".

Beta-User

Das klingt mir sehr nach einer Frage, die speziell für den PI ist. Vielleicht wäre die Frage dann im entsprechenden Forenbereich besser aufgehoben?

Eigentlich laufen die BMP180 nach meiner Erfahrung (kommt aber von MySensors) recht stabil; hast du evtl. ein Problem in der Spannungsversorgung?

Käme evtl. das Zwischenschalten eines Microcontrollers in Frage? Dann könntest du durch einfaches "Abstöpseln" bzw. evtl. auch durch einen Neustart z.B. des Arduinos einen Reset erreichen, ohne jedes mal an der config rumbasteln zu müssen. Stichwort z.B. KeyValueProtocol, damit kannst du auch die ganze Auswertelogik auf den MC auslagern (im Unterschied zu Firmata).

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Thomas41587

Ich bin mir an dieser Stelle leider nicht ganz sicher, ob es tatsächlich ein problem des PIs ist. Was ich definitiv sicher sagen kann: Der Sensor an sich funktioniert, wenn ich über ein Shell-Script versuche Werte vom Sesnor auszlesen, funktioniert es. Für mich sieht es eher danach aus, dass das device an sich einen hänger hat.
Spannungsversorgung kann ich eigentlich ausschließen, hier habe ich mir extra ein 5A 3.3V Netzteil besorgt (soll letztendlich ca. 10 dieser Sensorplatinen versorgen).
Ein Microcontroller zwischendrin wäre ja auch "nur" ein workaround, oder? Mir wäre es an der Stelle deutlich lieber, wenn das Problem in FHEM direkt gelöst wird. Nur weiß ich nicht, wo ich da anfangen soll. Es würde ja prinzipiell schon reichen, wenn man über FHEM eine reinititalisierung o.ä. machen könnte. Also einfach die gleiche Aktion, die beim Anlegen eines devices durchgeführt wird. Weil das behebt das Problem ja auf jeden Fall immer. Nur weiß ich nicht wie/wo ich das anstoßen kann.

Beta-User

Wenn du unter "Device" nicht das physikalische Gerät an sich verstehst, sondern das "FHEM"-Gerät, könnte es ein Problem der entsprechenden Module sein, du solltest den Thread dann ggf. dahin verschieben. 51_I2C_BMP180.pm gehört z.B. nach "Einplatinencomputer".

Die Einbindung z.B. mit einem Arduino und KeyValueProtocol ist m.E. kein wirklicher workaround, sondern eine grundsätzlich andere Vorgehensweise, jedenfalls, wenn man die eigentliche Ansprache/Auswertung der Sensoren dem Arduino überläßt.

Ansonsten könnte ein "defmod" die Art restart sein, nach der du suchst.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Thomas41587

...so einfach kanns gehen  ;D
defmod war genau das, was ich brauche! Hat soeben mit 2 der hängenden devices funktioniert.
Mit "device" meine ich hier tatsächlich das virtuelle Gerät in FHEM selbst. Das reelle Gerät hängt sich nicht auf (kann per Bash Skript o.ä. immernoch angesprochen werden).
Ich beobachte das ganze die nächsten Tage mal und wende mich dann ggfs. mit einem neuen Thread direkt im anderen Unterforum nochmal an die Community.
Vielen Dank für die schnelle und sehr gute Hilfe! :)

Beta-User

Gerne geschehen.

Trotzdem soltest du den Thread m.E. ins passende Unterforum verschieben, und vielleicht ein [vorläufig gelöst] im Thread-Titel anfügen.

Du arbeitest aber nicht zufällig parallel mit den FHEM-Modulen und Bash-Scripten, um auf diese reellen Geräte anzusprechen, sondern das mit dem Bash-Zugriff machst du erst, wenn in FHEM nichts mehr geht? Sonst könnte hier die Ursache für die Probleme der Module liegen...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Thomas41587

Wie kann ich den Thread verschieben? Finde hier keine passende Option dafür. Oder kann das nur ein Moderator?
Ja, das bash script ist nur zum testen, wenn mal wieder nichts geht. Anonsten greift ausschließlich FHEM auf die Sensoren zu.

Beta-User

Verschieben und Titel ändern kann jeder Thread-Ersteller selbst:

Der Knopf zum Verschieben ist unten links unter dem ersten Thread.

Zum Titel ändern: ersten Beitrag editieren.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

klausw

Die Module sind nur bedingt darauf ausgelegt die Bausteine automatisch wieder zu initialisieren.
Die Physikalischen Module (RPII2C, FRM) können das jeweilige logische Modul neu initialisieren.
Beim FRM wird das glaube ich auch gemacht, wenn die Verbindung neu aufgebaut wird.
Beim RPII2C ist es nicht vorgesehen. Die Bausteine werden direkt lokal angeschlossen und sollten fest verdrahtet sein.

Wie funktioniert denn der I2C Multiplexer denn?
Werden die einzelnen Slave Busse nacheinander geschaltet?
Kann das während eines Kommunikationsvorganges passieren?
Ich habe im Moment keine Idee wie ich aufgehängte Devices erkennen und neu initialisieren könnte.
Ideen sind willkommen
RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

Thomas41587

Also wenn ich das richtig verstehe, "kümmert" sich der Raspberry Pi selbst darum, dass der Multiplexer richtig eingebunden ist. Sobald der Multiplexer am Bus ist und man den Pi neustartet, bekommt man automatisch zusätzliche 8 I2C busse (in meinem Fall 3 - 10, abfragbar über i2detect -y 3, 4, ... 10). Wenn ich mich richtig erinnere wurde dafür extra ein Kernel-Modul hinzugefügt, um das zu ermöglichen.
Unabhängig davon wird der Multiplexer offenbar so angesprochen, dass man vor dem eigentlichen Datenverkehr mit einem Slave ein Byte mit dem gewünschten Output schickt. Der nachfolgende Datenverkehr geht dann an den entsprechenden Bus:
"Using it is fairly straight-forward: the multiplexer itself is on I2C address 0x70 (but can be adjusted from 0x70 to 0x77) and you simply write a single byte with the desired multiplexed output number to that port, and bam - any future I2C packets will get sent to that port. In theory, you could have 8 of these multiplexers on each of 0x70-0x77 addresses in order to control 64 of the same-I2C-addressed-part."

Ich als Benutzer erkenne ein aufgehängtes Gerät daran, dass es als Status "defined" hat. Bei dem BMP180 sind zusätzlichen die Calibration data Werte weg. Außerdem ist auch der Wert <bus-name>SENDSTAT weg.

Wenn noch weitere Infos oder Daten gebraucht werden, einfach bescheid sagen. Ich kann auch gerne Sachen testen.
Ziel wäre letztendlich, dass alle Geräte (am Ende ca 10 Sensorboxen mit je 5 Sensoren) zuverlässig funktionieren und sich nicht mehr aufhängen. Aktuell habe ich nur 1 Sensorbox dran hängen und befürchte, dass das Problem schlimmer wird, je voller der Bus wird.

klausw

Ok, verstehe.
Wenn der Baustein mehrere Busse emuliert kann es natürlich passieren, das 2 Von den Sensoren zugleich zugreifen wollen.
Die Frage ist, was dann passiert. Das Modul RPII2C sendet die Anfrage einfach raus. Eine Belegterkennung ist nicht eingebaut (und vermutlich auch nicht im KernelTreiber vorhanden).
Normalerweise gibt es einen I2C und der ist immer verfügbar.


Wie lang sind denn die I2C Leitungen?
Die 10 Sensorboxen stapelst du vermutlich nicht übereinander.
I2C ist für Kommunikation auf Geräteebene (eher Platinenebene) vorgesehen.
Längere Kabel machen das Ganze instabil.

Eventuell kannst du den Fehlerfall forcieren indem du sehr kurze Aktualisierungsintervalle bei allen Sensoren einstellst.
Ein Verbose 5 wäre dann auch hilfreich (aber dazu muss sich der Fehler gut reproduzieren lassen, sonst gibt es ein riesen Logfile)
RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

Thomas41587

Erst mal Danke für die ausführliche Antwort!
Ja es ist richtig, dass ich meine Sensorboxen nicht direkt neben dem Raspberry Pi stapeln werde  ;D geplant ist eine mittlere Leitungslänge von ca 15m. Meine Testbox hängt aktuell an einem 25m CAT5 LAN-Kabel. Aus anderen Foren hatte ich zur Länge des I2C Busses einige Posts gefunden, in denen von >100m die Rede war.
Seit dem letzten "defmod" läuft bisher alles stabil (mittlerweile fast 2 Wochen ohne dass ein Sensor aussteigt. Ich muss aber auch gestehen, dass ich 10 Tage im Urlaub war und daher auch kein einziges Kabel bewegt wurde. Kann es eventuell sein, dass die Module in FHEM sehr allergisch darauf reagieren, wenn es kurze Leitungsunterbrechungen gibt (Stichwort Wackelkontakt)?
Aktualisierungsintervall habe ich schon auf dem kleinsten Wert (da die Sensorwerte für die Haus-Steuerung weiter verwendet werden).
Ich werde mal schauen, was passiert, wenn ich den Wackelkontakt provoziere und dann einen Log hier anhängen. Vielleicht kommt man damit dann weiter.

klausw

eventuell kann es auch ein Bug sein:
klick
da bin ich immer noch nicht zum überprüfen gekommen
RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

jensb

Bei größeren Leitungslängen hilft es oft den Bustakt zu verringern, um die Übertragungssicherheit zu erhöhen. Ob das allerdings auch gut ist, wenn man mehrere Devices über einen Multiplexer anspricht, weiß ich nicht. Einen Versuch ist vielleicht trotzdem wert. Details gibt es z.B. hier.

FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

Otharon

Hallo zusammen, hier noch ein paar Überlegungen zum I2C-Bus.
Auch ich habe eine längere Teststrecke I2C Bus laufen.
Da der I2C mit nur 3,3V Gleichspannung läuft ist der erste Tip: Adern für +3,3V und vor allem! 0V doppeln! Die Module brauchen eine stabile Spannungsversorgung. Die Leistung des Netzteils spielt kaum eine Rolle. Wenn nach Leitungsverlust auf 20m nur noch 2 - 2,5V rauskommen  ist das eher suboptimal. Auch die Masseleitung muss ausreichend dimensioniert sein. In der CAT-Leitung sind ja 4 Adernpaare zur Verfügung. Die sollten auch ausgenutzt werden.
Die beiden Datenleitungen auf keinen Fall doppeln!
Dann die Verseilung: VCC sollte mit mit SDA verseilt sein, 0V mit SDL.
Viel Erfolg beim weiter testen.