AHT15 ...mögliche robuste Alternative zum SHT21/31 ?

Entwicklung und Bau von Hardware aller Art, die im HM-Umfeld eingesetzt werden kann

Moderator: Co-Administratoren

rih
Beiträge: 114
Registriert: 09.05.2019, 23:04
System: keine Zentrale (nur Pairing, FHEM etc.)
Wohnort: Nürtingen
Hat sich bedankt: 17 Mal
Danksagung erhalten: 10 Mal

Re: AHT15 ...mögliche robuste Alternative zum SHT21/31

Beitrag von rih » 16.10.2021, 16:00

Neue Erkenntnis: ich habe Tom's Sensorklasse AHTxx.h wieder gegen Jerome's Aht1x.h getauscht. Sonst wurde weder an der Hardware noch an der Software irgendetwas geändert.
Ergebnis: der Luftfeuchtigkeitswert verhält sich wieder normal ohne große Sprünge und abnormal hohe Werte. Irgendetwas haut wohl leider in der AHTxx.h mit der Initialisierung oder Kalibrierung noch nicht hin.
Ich werde gegen später noch einen Plot nachreichen, auf welchem man das geänderte Verhalten (vorher / nachher) des AHT15 sieht. Ich hoffe, dass es in dieser Konfig eine Weile ohne Hänger läuft.
Zuletzt geändert von rih am 16.10.2021, 18:44, insgesamt 1-mal geändert.
Viele Grüße,
Hans

TomMajor
Beiträge: 1619
Registriert: 30.08.2017, 23:25
Hat sich bedankt: 151 Mal
Danksagung erhalten: 327 Mal
Kontaktdaten:

Re: AHT15 ...mögliche robuste Alternative zum SHT21/31

Beitrag von TomMajor » 16.10.2021, 16:30

Also zu deiner Frage gestern, die AHT15-Feuchte in meinem 3h Run stimmte ziemlich gut mit der BME überein, aber ich habe nur den Log etwas gebrowst und nicht jeden Wert einzeln angeschaut. ich glaube nicht das ein 1min Intervall daran etwas ändern würde. Mir fehlt momentan ein bisschen die Zeit mich intensiver mit dem AHT15 auseinanderzusetzen, zu viele andere Projekte..
ich wollte nur "schnell" den AHT15 Support für den HB-UNI-Sensor1 aktivieren und das Problem mit dem Lock bei BME280 Parallelbetrieb lösen falls möglich.
ich habe aber vor für den Winter ein HB-UNI-Sensor1 Außen PCB Redesign zu machen wo der SHT31 und der AHT15 ihren Platz bekommen sollen.
Viele Grüße,
Tom

rih
Beiträge: 114
Registriert: 09.05.2019, 23:04
System: keine Zentrale (nur Pairing, FHEM etc.)
Wohnort: Nürtingen
Hat sich bedankt: 17 Mal
Danksagung erhalten: 10 Mal

Re: AHT15 ...mögliche robuste Alternative zum SHT21/31

Beitrag von rih » 16.10.2021, 18:29

Leider kann ich den versprochenen Plot nicht nachreichen, da der AHT15 mit der Aht1x.h nur ca. 40 min lief und man daher nicht viel sieht.

Das Problem mit der gestörten Kommunikation des AHT15 auf dem I2C-Bus besteht leider nicht nur in Verbindung mit dem BME280, sondern meiner Erfahrung nach mit jedem anderen x-beliebigen Teilnehmer. Mit dem BME280 ist es halt am ausgeprägtesten, warum auch immer.

Schade, der Ansatz mit dem Softreset war vielversprechend. Bin jetzt vorerst wieder auf den BME280 zurück gegangen. Vielleicht findet sich ja noch eine Lösung des Problems.
Viele Grüße,
Hans

TomMajor
Beiträge: 1619
Registriert: 30.08.2017, 23:25
Hat sich bedankt: 151 Mal
Danksagung erhalten: 327 Mal
Kontaktdaten:

Re: AHT15 ...mögliche robuste Alternative zum SHT21/31

Beitrag von TomMajor » 16.10.2021, 23:30

du meinst trotz setWireTimeout() hängt es irgendwann?
Bei mir was es wie geschrieben nach 3h immer noch ok im Gegensatz zu ohne setWireTimeout() wo es nach wenigen Minuten vorbei war - Deswegen dache ich das könnte eine Lösung sein.

Eine weitere Lösung wäre den (oder alle) I2C Sensoren per Portpin abzuschalten wie es Jerome für den BME gemacht hat.

Noch eine weitere Lösung wäre den AHT15 alleine :mrgreen: an einen 2. I2C-Bus zu hängen - da es beim mega328 nur einen in Hardware gibt müsste der zweite Bus per SW gemacht werden - I2C Bit-Banging - wenn der Platz im Flash dafür reicht, je nach Sketch.
Viele Grüße,
Tom

rih
Beiträge: 114
Registriert: 09.05.2019, 23:04
System: keine Zentrale (nur Pairing, FHEM etc.)
Wohnort: Nürtingen
Hat sich bedankt: 17 Mal
Danksagung erhalten: 10 Mal

Re: AHT15 ...mögliche robuste Alternative zum SHT21/31

Beitrag von rih » 17.10.2021, 11:41

TomMajor hat geschrieben:
16.10.2021, 23:30
du meinst trotz setWireTimeout() hängt es irgendwann?
Nein, nein. Mit deiner Sensorklasse läuft es durch. Nur der Luftfeuchtigkeitswert passte halt nicht.

Ich glaube, ich habe jetzt die Ursache für die Sprünge bzw. hohen Werte der Luftfeuchtigkeit gefunden.
Im Gegensazt zu Jérôme's Sensorklasse nimmst du in deiner Klasse den Luftfeuchtigkeitswert mal 10, vermutlich wegen der Kommastelle. In Verbindung mit FHEM bzw. dem Modul HMConfig_AskSinPPCustom.pm ergibt sich dann aber ein falscher Wert. Z.B. wird aus 669 im Arduino-Monitor der Wert 159% in FHEM. Warum das so ist, habe ich nicht weiter untersucht. Eventuell habe ich auch eine zu alte HMConfig_AskSinPPCustom.pm.
Nehme ich den Faktor 10 in deiner Klasse raus, dann passt es. Analoge plausible Werte im Monitor und FHEM ohne Sprünge. Halt ohne Kommastelle.

Seit einer Stunde läuft das volle Programm an I2C-Sensoren, inkl. AHT15 und BME280. :D
Viele Grüße,
Hans

TomMajor
Beiträge: 1619
Registriert: 30.08.2017, 23:25
Hat sich bedankt: 151 Mal
Danksagung erhalten: 327 Mal
Kontaktdaten:

Re: AHT15 ...mögliche robuste Alternative zum SHT21/31

Beitrag von TomMajor » 17.10.2021, 11:52

ok, dann besteht also immer noch Hoffnung dass setWireTimeout() auch bei dir das Problem löst. :)

ja genau, die x10 sind für die Kommastelle im HB-UNI-Sensor1.

Bei Fhem und dem HB-UNI-Sen-WEA wird mit Faktor 1 gearbeitet
https://github.com/pa-pa/AskSinPP/blob/ ... om.pm#L692

aber z.B. beim HB-UNI-Sensor-THPD-BME280 auch mit Faktor 10
https://github.com/pa-pa/AskSinPP/blob/ ... om.pm#L780
Viele Grüße,
Tom

jp112sdl
Beiträge: 9823
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 619 Mal
Danksagung erhalten: 1471 Mal
Kontaktdaten:

Re: AHT15 ...mögliche robuste Alternative zum SHT21/31

Beitrag von jp112sdl » 17.10.2021, 12:02

Hab das jetzt hier nicht im Detail weiter verfolgt.
Aber zusammenfassend: Reicht es in der sensors/Aht1x.h auch aus, nach dem >>>Wire.begin();<<<
einfach noch ein Wire.setWireTimeout(25000, true); zu machen?

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

TomMajor
Beiträge: 1619
Registriert: 30.08.2017, 23:25
Hat sich bedankt: 151 Mal
Danksagung erhalten: 327 Mal
Kontaktdaten:

Re: AHT15 ...mögliche robuste Alternative zum SHT21/31

Beitrag von TomMajor » 17.10.2021, 12:16

jp112sdl hat geschrieben:
17.10.2021, 12:02
Hab das jetzt hier nicht im Detail weiter verfolgt.
Aber zusammenfassend: Reicht es in der sensors/Aht1x.h auch aus, nach dem >>>Wire.begin();<<<
einfach noch ein Wire.setWireTimeout(25000, true); zu machen?
Genau, Jerome.
In der von mir verwendeten Lib von enjoyneering war diese Methode drin, aber mit false als 2. Param. Den auf true setzen hat bei mir das AHT/BME Lock Problem gelöst da dann die Arduino Wire Lib bei ACK Problemen ein Re-Init der I2C on-Chip HW macht.
Viele Grüße,
Tom

jp112sdl
Beiträge: 9823
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 619 Mal
Danksagung erhalten: 1471 Mal
Kontaktdaten:

Re: AHT15 ...mögliche robuste Alternative zum SHT21/31

Beitrag von jp112sdl » 17.10.2021, 12:19

TomMajor hat geschrieben:
17.10.2021, 12:16
da dann die Arduino Wire Lib bei ACK Problemen ein Re-Init der I2C on-Chip HW macht.
Besten Dank, dann füge ich das mal auch mit hinzu.

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

rih
Beiträge: 114
Registriert: 09.05.2019, 23:04
System: keine Zentrale (nur Pairing, FHEM etc.)
Wohnort: Nürtingen
Hat sich bedankt: 17 Mal
Danksagung erhalten: 10 Mal

Re: AHT15 ...mögliche robuste Alternative zum SHT21/31

Beitrag von rih » 17.10.2021, 13:55

Also ich kann mittlerweile bestätigen, dass die Probleme in Verbindung mit dem AHT15 beseitigt sind. Genauer gesagt, ist nicht das Problem beseitigt, wohl aber die Auswirkung. :)
Einen kleinen Schönheitsfehler gibt es noch in Verbindung mit FHEM: wenn es zur Kollision auf dem Bus kommt, dann sind die Werte des BMxxx kurzzeitig auf 0 bis der Softreset erfolgt. Wenn FHEM gerade dann eine Abfrage macht, habe ich eben 0-Werte in der Anzeige stehen. Bei minütlicher Abfrage kann es daher bis zu 1 Minute dauern, bis die Anzeige wieder passt. Aber das ist eher eine FHEM-Geschichte.
Viele Grüße,
Hans

Antworten

Zurück zu „Hardwareentwicklung und Selbstbau von Aktoren und Sensoren“