Temperatur und Luftdruck liefern plötzlich falsche Werte

[André K.]

Hallo zusammen,

gestern habe ich meine Wetterstation außen montiert und über Nacht hat sich plötzlich ein neues Problem aufgetan: Von einer Sekunde auf die nächste Sprung auf -38,43°C und 1200,000 hPa. Hier mal der Ausschnitt aus dem Log:

2020-04-24 23:58:54 Temperature       937
2020-04-24 23:58:54 Pressure       968953
2020-04-24 23:58:55 Temperature       943
2020-04-24 23:58:55 Pressure       968977
2020-04-24 23:58:56 Temperature       937
2020-04-24 23:58:56 Pressure       968992
2020-04-24 23:58:57 Temperature     -3843
2020-04-24 23:58:57 Pressure      1200000
2020-04-24 23:59:00 Pressure      1091263
2020-04-24 23:59:01 Pressure      1200000
2020-04-24 23:59:07 Pressure       224248
2020-04-24 23:59:08 Pressure      1200000

Zum Glück kein Einfrieren des gesamten Stapels, so daß durch einen Reset via Brick-Viewer das Problem erstmal behoben werden konnte.

Ich bin mir ziemlich sicher, daß ich in den letzten Tagen hier mal einen Thread gefunden hatte, bei dem jemand exakt das gleiche Problem hatte. Ich hab jetzt fast ne Stunde lang mit unterschiedlichen Stichwörtern die Suche traktiert aber ich finde ihn einfach nicht wieder.

Kann mir jemand auf die Sprünge helfen?

[duaw]

Hallo!

Ja, ganz, ganz, ganz sporadisch passiert das bei mir auch an einer Mess-Stelle: -38,43°C. Masterbrick 2.1, Temperature-Bricklet alt (und mehr), aktuelle SW. Das ist aussen, per Powerline angebunden.

Ich habe bisher kein Muster erkannt. Ich lasse mich informieren und resette dann 😉 . Ist etwas unbefriedigend.   

Gruß, Uwe

[André K.]

Hallo Uwe,

danke für die Rückmeldung!

Das passt, bei mir ist es auch das "alte" Temp-Bricklet. Hast Du das Barometer-Bricklet ebenfalls im Einsatz? Und wie oft ist bei Dir "ganz, ganz, ganz, sporadisch"? 

Ich werde mal weiter beobachten und mir auch mal einen cron-Job einrichten der mich benachrichtigt bei zu hohen Sprüngen der Temperatur …

André

[duaw]

Hallo, André,

ich habe im überdachten Aussenbereich (!) einen Stapel mit Temp / Bar / Hum / Dual Relay  / PoE (ich meine, das läuft stabil) zum Regeln der Luftzufuhr / Messen. Und dann in einer Hütte wieder via Powerline zur Überwinterung Hum / 2x Temp (unten, oben) / Hum mit Ethernet (nicht PoE) und Steckernetzteil. Ich meine, das ist der Kandidat. 

Sporadisch: Dieses Jahr noch nicht. Letztes Jahr im Sommer ? 1 mal ? Davor länger nicht ? Ich glaube sogar, ich musste den Stapel stromlos machen, weiss das aber nicht mehr genau. 

So selten, dass ich es nicht genau weiß, aber so häufig, dass ich die Überwinterung noch nicht Node-RED bzw. openHAB anvertraue. Hatte auch immer mal Powerline-Probleme (und die SW läuft auf einem Rechner im Haus!), da zweifle ich an der Zuverlässigkeit. Werde die Überwinterung vor Ort steuern (mit Backup ... )

Gruß, Uwe

 

[André K.]

Hallo Uwe,

nochmals danke!

Also mit ein bis zwei mal im Jahr könnte ich leben … tatsächlich ist es jetzt über Nacht wieder zwei mal aufgetreten, nachdem es davor den ganzen Tag über stabil war. Ein mal um kurz nach 23 Uhr, da hab ich es zufällig bemerkt und gleich reagiert, und dann wieder um 5:23 Uhr.

Und das Barometer ist auch zwischendurch mal in der Form betroffen daß nur ein einzelner Ausreißer kommt und danach dann wieder normale Werte, wie ich gerade an meiner min/max Auswertung sehe — *seufz*

André

[rtrbt]

Moin André,

Versuch mal das Temperature Bricklet im langsamen I²C-Modus zu betreiben. Eventuell hast du auf deinem Dach Störstrahlung. Bei den alten Temperature/Barometer Bricklets hängen die Sensoren am selben I²C-Bus, es wäre also möglich, dass eine Störung des Temperature Bricklets das Barometer Bricklet mitreißt. Das würde sich auch mit deinem Log decken.

[André K.]

Ich bin bei meiner Suche auch schon über den Tipp gestolpert, aber bringt der mir überhaupt was wenn ich ausschließlich mit Callbacks arbeite (und nicht mit get_temperature())?

(Ich ärgere mich gerade, daß ich nicht einfach zwei neue Bricklets der aktuellen Generation gekauft habe. Die alten lagen seit 2014 hier rum, da hatte ich das Projekt schon mal durchziehen wollen aber wie das im Leben so ist, manchmal kommt was dazwischen. Deshalb lagen die so lange im Karton herum.)

[rtrbt]

Das ist unabhängig davon ob du Callbacks oder Getter benutzt. In beiden Fällen muss der Master Brick mit dem Sensor kommunizieren.

[André K.]

Ah, gut zu wissen!

Ich baue das gleich heute Nachmittag noch in meinen Gateway-Daemon ein und werde berichten.

Drei Fragen noch, für mich (und sicher auch einige andere) zum Verständnis:

• Wirkt sich das auch negativ auf die Geschwindigkeit anderer Bricklets aus? Das schnellste was ich eingerichtet habe sind 200ms Callback für das IO16.
• Muß ich damit rechnen, daß das Flag durch einen Connect vom Brick-Viewer zurückgesetzt wird, oder durch einen Aufruf des Temperatur-Tabs?
• Ergänzt ihr das mit der reduzierten Geschwindigkeit auch noch beim Barometer Bricklet, wenn es für die Temperatur hilft und ich lieb darum bitte?  

André

[rtrbt]

47 minutes ago, André K. said:

Wirkt sich das auch negativ auf die Geschwindigkeit anderer Bricklets aus? Das schnellste was ich eingerichtet habe sind 200ms Callback für das IO16.

Nein, das Temperatur Bricklet setzt die Geschwindigkeit nur vor seiner Abfrage kurz runter und danach wieder hoch.

50 minutes ago, André K. said:

Muß ich damit rechnen, daß das Flag durch einen Connect vom Brick-Viewer zurückgesetzt wird, oder durch einen Aufruf des Temperatur-Tabs?

Nein, nur durch einen Reset des Bricklets.

51 minutes ago, André K. said:

Ergänzt ihr das mit der reduzierten Geschwindigkeit auch noch beim Barometer Bricklet, wenn es für die Temperatur hilft und ich lieb darum bitte?  

Unter der Prämisse, dass es nur das Temperature Bricklet ist, das den Bus lahmlegt sollte das nicht notwendig sein. Falls das Barometer das auch hinbekommt, kann man sich das natürlich nochmal ansehen.

[duaw]

Hallo!

Schwups, es ist wieder passiert. Eben 6:42 Uhr. Beobachtung: (Habe noch keine Regel) Reset aus dem Brickviewer, kurz die 10°, dann wieder -38,4; noch ein Reset, dann dann ok ... 

Es war der Aufbau mit dem Barometer / Humidity / Dual Relay / PoE, aber es gab keinen Schaltvorgang im Garten. EMI dort?. 

Da ist noch openHAB mit dem alten TF-Binding im Einsatz. Parallel wechsle ich langsam auf Node-RED/MQTT, noch mit periodischer 30sec-Abfrage. Mit MQTT kann ich auch den i2c-Modus setzen. 

Gruß, Uwe

 

[rtrbt]

Hast du an dem Aufbau auch ein Temperature Bricklet oder ist das die Temperatur, die du vom Barometer Bricklet bekommst? Das könnte ja eventuell die These zu Grabe tragen, dass nur das Temperature Bricklet die Probleme verursacht.

Eigenwerbung: Mit den neuen openHAB-Bindings (siehe den Beta-Thread) kannst du den I²C Modus auch setzen

[duaw]

Ich habe Temperature / Humidity / Barometer / Dual Relay und nehme die Temperatur aus ... Temperature. Das Bricklet zeigte -38,43°C. 

Dual Relay schaltet die Luftzufuhr ins Haus zwischen "lang" und "kurz" . Habe da ein Eltako 1393097 dazwischen, weil das Schalten via Dual Relay nur so zuverlässig ging. Beim Ausfall der Temperatur vorhin wurde aber nicht geschaltet.

Ich habe noch openHAB 2.4 am Laufen mit dem alten Binding von Theo. Habe irgendwie Angst vor der Migration ... solange das "Beta", die Doku unvollständig ist und der Einarbeitungsaufwand irgendwie nicht überschaubar erscheint. Never touch a running system . Und wie gesagt: Node-RED ist ganz nett! (mit oH ist es aber einfacher, gut aussehende Resultate zu erzielen ...) 

------

Eher ein Thema für einen neuen Thread: Wo liegen die Nachteile / Vorteile oH-nativ vs. oH-MQTT ? In Node-RED kommt ja alles via MQTT an (Für jeden Stapel mit eigener IP-Adresse starte ich einen eigenen Service.) Das ginge ja auch in oH. Mir gefällt Deine MQTT-Lösung sehr gut! Warum sollte ich das TF-oH-Bindung benutzen? 

(Noch 'ne Frage, definitiv etwas off-topic: Noch rufe ich in Node-RED MQTT request auf. Das ist nicht zeitkritisch. Regelmäßig kommt auch {"temperature": "{\"temperature\": null, \"_ERROR\": \"Did not receive response for function 1 in time (call of get_temperature of temperature_bricklet aK1)\"}"} Das ignoriere ich. Dann kommt wieder {"temperature": 1556} .  Die Verbindung via BrickV steht. Woran kann das liegen? Irgendwo ein zu aggressives Timing im MQTT-service-API? Stapel ist im Aussenbereich via Powerline angeschlossen. )

Gruß, Uwe

bearbeitet April 28, 2020 at 08:36 von duaw

[André K.]

Ich gebe auch mal nen kurzen Zwischenbericht: zum ersten Mal ist es über Nacht stabil durchgelaufen, was das angeht bin ich vorsichtig optimistisch ;)

Aber: hab im Barometer-Log schon wieder einen Ausreißer nach unten gesehen … wie befürchtet ist also nicht nur das Temperature-Bricklet betroffen.

Immerhin ist bisher kein reset notwendig gewesen.

André

[rtrbt]

Moin,

@André K.

Teste mal die angehangene Firmware für das Barometer Bricklet. Ich habe das Verhalten vom Temperature Bricklet, wenn man es auf slow konfiguriert hat, nachgebaut. Das heißt, du musst nichts konfigurieren, aber wenn das Barometer Bricklet die selben Probleme hat, sollten sie mit dieser Firmware weg sein.

@duaw

Ich bin mir nicht ganz sicher, wie Theos Binding mit den Bricklets arbeitet (also ob es z.B. manchmal explizit resettet). Du kannst aber testen, ob die langsamere I²C-Geschwindigkeit bei dir hilft, indem du periodisch (z.B. alle 5 Minuten) mit MQTT oder einen Python-Script die set_i2c_mode-Funktion benutzt um den langsamen Modus zu erzwingen.

Die angehangene Firmware für das Barometer Bricklet kannst du auch testen, falls du damit auch Probleme hast. Dafür musst du nichts am Setup ändern.

2 hours ago, duaw said:

Wo liegen die Nachteile / Vorteile oH-nativ vs. oH-MQTT ?

Der Hauptvorteil an den openHAB-Bindings ist, dass sie dir viel Arbeit abnehmen, weil sie z.B. Messwerte direkt in Items legen, ohne dass du etwas konfigurieren musst. Brick(let)-Konfiguration geht direkt über die PaperUI und wird automatisch angewandt, wenn du z.B. den Stapel ziehst und neu ansteckst oder die Verbindung zum Brick Daemon mal weg war. Theoretisch musst du, wenn du das neue Binding benutzt nie eine Textdatei anfassen.

Mit den MQTT-Bindings hast du andererseits die volle Kontrolle über die Bricks/Bricklets, musst dich dafür aber selbst um die Robustheit kümmern.

Zu deinem Timeout-Problem: Die Meldung kommt von den MQTT-Bindings. Der Timeout (der übrigens eigentlich konfigurierbar sein sollte, habe ich mir mal auf die TODO-Liste gesetzt) sollte auf den standardmäßigen 2,5 Sekunden stehen. Das ist etwas unerwartet, dass bei deinem Aufbau (da ist jetzt nichts Traffic-intensives dabei) regelmäßig Timeouts kommen (was heißt übrigens regelmäßig? Einmal pro Minute/Stunde/Tag?) aber an sich kann es schon passieren, dass mal ein Paket verloren geht.

barometer-bricklet-slow-i2c.bin

[André K.]

Vielen Dank! Sobald ich daheim bin teste ich das.

Ich habe bisher noch nie manuell eine neue FW eingespielt, das geht aber hoffentlich auch einfach durch die Ethernet-Extension (und ein VPN) hindurch via Brick-Viewer, oder?

André 

[photron]

15 minutes ago, André K. said:

das geht aber hoffentlich auch einfach durch die Ethernet-Extension (und ein VPN) hindurch via Brick-Viewer, oder?

Ja.

[André K.]

So, neue Firmware ist geflasht. Ist das korrekt daß die Versionsnummer dieselbe geblieben ist?

Temperatur ist auch den ganzen Tag über unauffällig geblieben — so langsam nähern wir uns einem Zustand, daß ich die Daten ruhigen Gewissens wieder in meine Homepage einblenden kann.  

Und an der Stelle mal schon mal danke und Hut Ab für das durchdachte Gesamtdesign. Daß ich von hier aus per VPN die FW flashen kann und nicht mit nem Notebook auf dem Dach rumkraxeln muß ist schon cool. 😎

André

[duaw]

Am 28.4.2020 um 13:26 schrieb rtrbt:

Zu deinem Timeout-Problem: Die Meldung kommt von den MQTT-Bindings. Der Timeout (der übrigens eigentlich konfigurierbar sein sollte, habe ich mir mal auf die TODO-Liste gesetzt) sollte auf den standardmäßigen 2,5 Sekunden stehen. Das ist etwas unerwartet, dass bei deinem Aufbau (da ist jetzt nichts Traffic-intensives dabei) regelmäßig Timeouts kommen (was heißt übrigens regelmäßig? Einmal pro Minute/Stunde/Tag?) aber an sich kann es schon passieren, dass mal ein Paket verloren geht.

Mit schöner Regelmäßigkeit – alles 30 sec wird gepollt – kommt: 

mosquitto_sub -t tinkerforge/response/temperature_bricklet/ziB/get_temperature -h 192.168.1.18
{"temperature": "{\"temperature\": null, \"_ERROR\": \"Did not receive response for function 1 in time (call of get_temperature of temperature_bricklet ziB)\"}"}
{"temperature": 1756}
{"temperature": "{\"temperature\": null, \"_ERROR\": \"Did not receive response for function 1 in time (call of get_temperature of temperature_bricklet ziB)\"}"}
{"temperature": "{\"temperature\": null, \"_ERROR\": \"Did not receive response for function 1 in time (call of get_temperature of temperature_bricklet ziB)\"}"}
{"temperature": "{\"temperature\": null, \"_ERROR\": \"Did not receive response for function 1 in time (call of get_temperature of temperature_bricklet ziB)\"}"}
{"temperature": "{\"temperature\": null, \"_ERROR\": \"Did not receive response for function 1 in time (call of get_temperature of temperature_bricklet ziB)\"}"}
{"temperature": 1756}
{"temperature": "{\"temperature\": null, \"_ERROR\": \"Did not receive response for function 1 in time (call of get_temperature of temperature_bricklet ziB)\"}"}
{"temperature": "{\"temperature\": null, \"_ERROR\": \"Did not receive response for function 1 in time (call of get_temperature of temperature_bricklet ziB)\"}"}
{"temperature": "{\"temperature\": null, \"_ERROR\": \"Did not receive response for function 1 in time (call of get_temperature of temperature_bricklet ziB)\"}"}

Erst ein Timeout, dann der Wert, dann 3x Timeout ... 30 sec Pause … dann Timeout, dann der Wert, dann 3x Timeout.

Hmmm. Muss noch mal checken, ob da Node-RED mehrere Abfragen feuert ... 

Gruß, Uwe

[rtrbt]

Hm das sieht wirklich seltsam aus. Eventuell kratzt du genau am Timeout, auch wenn mir unklar ist, warum das 2,5 Sekunden dauern sollte. Du kannst mal versuchen, die MQTT-Bindings mit --ipcon-timeout 10000 zu starten, eventuell hilft das.

[duaw]

Nein, --ipcon-timeout 10000 hat nicht geholfen. Das dauert auch weniger als 2,5 Sekunden ... 

Nein, das Problem liegt vielmehr ganz woanders: Ich habe mehrere Stapel mit Ethernet-Extensions im Einsatz. Ich lasse also für jede IP-Adresse eine Instanz des MQTT-API-Binding laufen. Muss ich ja, da ich dem Binding genau EINEN ipcon-host nennen kann. Also:

tinkerforge_mqtt  mit der Zeile ExecStart=/usr/bin/python /usr/local/bin/tinkerforge_mqtt --broker-host 192.168.1.18 --ipcon-host 192.168.1.111 
tinkerforge_mqtt_112 mit der Zeile ExecStart=/usr/bin/python /usr/local/bin/tinkerforge_mqtt --broker-host 192.168.1.18 --ipcon-host 192.168.1.112 
...
tinkerforge_mqtt_115 mit der Zeile ExecStart=/usr/bin/python /usr/local/bin/tinkerforge_mqtt --broker-host 192.168.1.18 --ipcon-host 192.168.1.115  

In Node-RED requeste ich per MQTT tinkerforge/request/temperature_bricklet/aK1/get_temperature . Das Bricklet ist am Stapel mit der IP 192.168.1.111

ALLE 5 laufenden services erhalten die Nachricht, fühlen sich dann also angesprochen, aber nur einem service gelingt es, die Temperatur zu liefern (dem, der an ipcon-host 111 horcht), die 4 anderen versuchen es und geben dann auf.

Es kommt also 1 mal die Temperatur und 4 mal die Fehlermeldung. 

Hmmm ... Möglichkeiten:  

• Ich werde versuchen, das mit dem --global-topic-prefix-Parameter irgendwie hinzubasteln. Da steht in der Doku Der Präfix kann beispielsweise verwendet werden, um mehrere Binding-Instanzen, die mit dem selben Broker verbunden sind, zu trennen. Dann muss ich selbst drum kümmern ... 

Alternativ:   

1. tinkerforge_mqtt "wird Multi-ipcon-host"-fähig und bekommt beim Aufruf eine Liste von --ipcon-hosts (Nein.) 
2. tinkerforge_mqtt findet heraus, dass das Bricklet vom gewünschten Typ mit der UID nicht da ist und ignoriert den Aufruf (Eher unwahrscheinlich)
3. tinkerforge_mqtt hat eine Option, mit der auf die "Antwort" verzichtet wird. (Warum nicht. Ich kann/muss mich eh' drum kümmern. Ob sie nun nicht gekommen ist oder als Nachricht, dass sie nicht kam ist mir egal)
4. die IP-Adresse wird Bestandteil von payload oder topic  

Gruß, Uwe

bearbeitet May 1, 2020 at 13:26 von duaw

[André K.]

Mal eine kleine Rückmeldung meinerseits …

Seitdem ich den langsamen Modus für das Temp-Bricklet drin habe und die Spezial-Firmware im Barometer-Bricklet sind jetzt keine Probleme mehr aufgetreten. Ich werde weiter beobachten und bin aber erstmal vorsichtig optimistisch

André

[rtrbt]

Moin,

Ich habe die Firmware-Anpassungen fürs Barometer Bricklet noch etwas robuster gemacht und in das nächste Firmware-Release eingebaut, die 2.0.3 sollte jetzt verfügbar sein. Das Default ist aber wieder der schnelle Modus. D.h. du musst den langsamen Modus jetzt explizit mit set_i2c_mode aktivieren, so wie es beim Temp-Bricklet auch funktioniert. Welche Sprache benutzt du? Dann erstelle ich dir dafür die Bindings neu, damit du die Funktion benutzen kannst.

@duaw Ah das erklärt das Problem. Für genau deinen Fall ist der global-topic-prefix-Parameter da.

Die Alternativen sind alle schwierig, 1. und 4. könnte man nur zusammen fahren (sonst müssten die MQTT-Bindings routen, das ist ein Krampf) 2. ist unschön, wenn man am Einrichten des ganzen ist, weil man dann nicht mitbekommt, dass die UID falsch ist, 3. macht ein riesiges Fass auf, weil man dann allgemeine Message-Filter bauen müsste. Da ist es einfacher für dich als Anwender alle Messages mit "_ERROR"-Key zu ignorieren. Das würde auch das "Fern-Debuggen" erschweren, wenn jemand Probleme damit hat.

[André K.]

vor 8 Minuten schrieb rtrbt:

Welche Sprache benutzt du? Dann erstelle ich dir dafür die Bindings neu, damit du die Funktion benutzen kannst.

Sehr cool, das heißt, das FW-Update müsste normal im Brick Viewer erscheinen und kann einfach drüber gebügelt werden?

Ich benutze ganz klassisch die C/C++-Bindings

André

[rtrbt]

Jupp, der Brick Viewer sollte schon fleißig Update-Meldungen erzeugen. Die Bindings sind angehangen.

tinkerforge_c_bindings_2_1_28_barometer_i2c.zip