HomeMatic-Forum / FHZ-Forum

Hmm dann bin ich etwas überfragt.
Aber das Gerät ist ohnehin nicht wirklich verlässlich.
Oder hast du noch was am Code angepasst?
Ich hab’s ja damals irgendwann aufgeben (siehe ersten Beitrag des Threads)

jp112sdl hat geschrieben: ↑

03.11.2019, 22:29

Hmm dann bin ich etwas überfragt.
Aber das Gerät ist ohnehin nicht wirklich verlässlich.
Oder hast du noch was am Code angepasst?
Ich hab’s ja damals irgendwann aufgeben (siehe ersten Beitrag des Threads)

Ich habe einen BME680 Sensor über pmatic ohne Funkanbindung als Innenraumsensor seit ca. 2 Jahren in Benutzung. Nun will ich einen BE680 Funkaußensensor dazufügen.

Am Code geändert hatte ich bisher nur die Device Properties:

// define all device properties
const struct DeviceInfo PROGMEM devinfo = {
{0xf1, 0xd1, 0x01}, // Device ID
"JPIAQ0001", // Device Serial
{0xf1, 0xd1}, // Device Model Indoor
0x10, // Firmware Version
as::DeviceType::THSensor, // Device Type
{0x01, 0x00} // Info Bytes
};

und die Abtastrate:

uint32_t delay () {
return seconds2ticks(max(this->device().getList0().updIntervall(), 240));
}

Zwei BME280 basierte HM-WDS40-TH-I Asksinpp Sensoren ließen sich problemlos in meine Raspberrymatic einbinden.

VG

Ewald

Ich meine, die Messwerte vom BME680 sind nicht plausibel. Die werden dir nix nützen... deshalb liegt das Projekt auch auf Eis.

Hallo Jerome,

nun hab ich endlich die Ursache des Fehlers gefunden: Mein Fehler: Die Device ID war nur 9 stellig. Nach der Korrektur auf 10 Zeichen läuft alles wie erwartet. Der Sensor funktioniert . Nun kann ich mir die Messroutinen anschauen und werde berichten, wenn ich was Brauchbares gefunden habe.

Gruß

Ewald

Ja cool. Berichte mal!

Hallo Jerome,

nach einigem Suchen bin ich auf die vermutliche Ursache der sprunghaften Gaswiderstands- und IAQ-Werte gestoßen:

Das Bitmapping für das Auslesen des Gaswiderstandregister in der referenzierten Library 'ClosedCube_BME680' ist m.E. falsch. In 'ClosedCube_BME680.cpp' steht, meiner Ansicht nach falsch, in Zeile 119 - 133:

uint32_t ClosedCube_BME680::readGasResistance() {
typedef union {
uint8_t raw;
union {
uint8_t range : 2;
uint8_t lsb : 6;
};
} gas_lsb_t;

gas_lsb_t gas_lsb;

uint8_t gas_msb = readByte(0x2A);
gas_lsb.raw = readByte(0x2B);

uint16_t gas_raw = gas_msb << 8 | gas_lsb.lsb;

Richtig ist m.E. entsprechend des Datenblatts BME60 Kapitel 5.2 'Memory Map', Seite 25, Register Name gas_r_lsb und gas_r_lsb:

uint32_t ClosedCube_BME680::readGasResistance() {
typedef union {
uint8_t raw;
union {
uint8_t range : 4;
uint8_t heat_stab_r: 1;
uint8_t gas_valid_r: 1;
uint8_t lsb : 2;
};
} gas_lsb_t;

gas_lsb_t gas_lsb;

uint8_t gas_msb = readByte(0x2A);
gas_lsb.raw = readByte(0x2B);

uint16_t gas_raw = ((uint16_t)gas_msb) << 2 | (uint16_t)gas_lsb.lsb;

Die Validierung dieser Änderung läuft noch. Erste Ergebnisse zeigen keine Sprünge der Messwerte mehr.

Gruß

Ewald

Da ist noch ein Fehler drin:
das innere Element darf kein Union sein, sondern eine Struct.

Schön, dass hier noch Bewegung drin ist.
Bin gespannt auf die weiteren Ergebnisse

Hallo Zusammen,

unten die ersten IAQ Messwerte nach der Korrektur. Der IAQ Verlauf nach der Korrektur entspricht meinen Erwartungen. GAS_UPPER_LIMIT ist manuell auf 170kOhm gesetzt. Der Sensor läuft seit ca. 4 Wochen und misst alle 4 Minuten. Das initiale "Einbrennen" des Sensors ist weitgehend abgeschlossen.
Um die weitere Alterung des Sensors zu berücksichtigen, ist mein Vorschlag, ein Infinite Impulse Response (IIR) Filter für GAS_UPPER_LIMIT und GAS_LOWER_LIMIT einzuführen, das den oberen und unteren Grenzwert automatisch nachführt.

Der unterste Graph zeigt den sprunghaften Verlauf des IAQ vor der Korrektur.

Gruß

Ewald

FUEL4EP hat geschrieben: ↑

27.12.2019, 12:07

Um die weitere Alterung des Sensors zu berücksichtigen, ist mein Vorschlag, ein Infinite Impulse Response (IIR) Filter für GAS_UPPER_LIMIT und GAS_LOWER_LIMIT einzuführen, das den oberen und unteren Grenzwert automatisch nachführt.

Meinst du als Einstellmöglichkeit über die WebUI?