LaCrosseGateway - LaCrosse, PCA301 und EC3000 über wifi mit ESP8266 ohne Arduino

[weini]

Erst mal die gute Nachricht (der Rest im nächsten Post dann ...)

Der DHT22 scheint mit dem geänderten Timing der 1.21 nun stabil zu laufen.
Auf meinem 209er LGW liefert er seit einer Woche konstant Werte.

Habe nach meinem Urlaub vor einer knappen Wochen gleich auf die 1.21 bestätigt und auch bei mir läuft der DHT22 jetzt (wieder) stabil.
Vielen Dank an alle für die tolle Unterstützung!

[HCS]

BME280 in FORCED mode, Trigger via GetTemperature (das Delay hierdurch liegt bei ca. 14ms)

Habe ich mal übernommen.

Damit liegt der BME280 bei mir recht genau ein Grad zu hoch (im Vergleich zu SHT75 und kalibriertem DS18B20) -> schon besser als vorher.
Den DS18B20 habe ich in meiner Test-Firmware mit einer Zweipunktkalibrierung versehen.

Der SHT75 hat out of the box fast exakt das Ergebnis des kalibrierten DS18B20. Die Differenz bei verschiedenen Zimmertemperaturen ist max. 0.1 °C
Und seine Feuchte ist sehr plausibel aber die muss ich noch nachmessen.

Code Auswählen Erweitern

Sensor type     Temperature  Humidity  Pressure
BME280          25.6         54        991
BMP180          24.8                   988
DHT22           24.6         63
LM75            23.0
SHT75           24.6         54
DS18B20 #1      24.5

Was auch interessant ist: der DHT22 liegt mit der Temperatur gut, aber mit der Feuchte definitiv daneben.
Ach ja, die 991 hPa des BME280 stimmen, der BMP180 irrt sich.
Von den BMP180 habe ich einige, da sind auch welche dabei, bei denen der Druck passt aber die Temperatur weiter daneben liegt.

Kommt der mit ins LaCrosseGateWay?

Kann ich noch nicht sagen. Ist kein I2C sondern Sensirion spezial Protokoll, aber auch mit Data und Clock.
Angeblich soll das parallel verträglich auf einem I2C-Bus funktonieren. Aber das muss ich erst noch ausprobieren.

[rendgeor]

Hallo,
1) benötige ich für das OLED display zwingend den MCP23008?
Oder dient dieser dazu von FHEM Seite in IO-PIns dynamisch zuzuweisen?

2) Wozu ein zweiter oder dritter RFM69?

3) Wo findet sich die Schematics zum Anschluss des Displays?

mfg,
Oliver

[PeMue]

1) benötige ich für das OLED display zwingend den MCP23008?
Oder dient dieser dazu von FHEM Seite in IO-PIns dynamisch zuzuweisen?
2) Wozu ein zweiter oder dritter RFM69?
3) Wo findet sich die Schematics zum Anschluss des Displays?

zu 1) bzw. 3) nein, das Display wird nur per SPI angeschlossen: 3,3 V, GND, SCL, SDA.
zu 2) das müsste dann der 4. bzw. 5. RFM69 sein: z.B. wenn Du verschiedene LaCrosse Sensoren hast bzw. LaCrosse Sensoren + PCA301 + EnergyCount 3000 bedienen willst.

Gruß PeMue

[rendgeor]

Hallo PeMu,
danke für deine schnelle Antwort.

D.h. es gilt weiterhin, dass man mit einem Sketch nicht verschiedene Sensoren bedienen kann?!
Warum kann der Sketch nicht zwischen den verschiedenen Protokollen toggeln?

[PeMue]

D.h. es gilt weiterhin, dass man mit einem Sketch nicht verschiedene Sensoren bedienen kann?!
Warum kann der Sketch nicht zwischen den verschiedenen Protokollen toggeln?

Bitte zwischen JeeLink (jeweils nur ein Sketch bzw. toggeln teilweise möglich, manche Sketche können aber nur RFM12B) und LaCrosseGateway (kann so gut wie alles, allerdings nur mit RFM69, da geht auch ein Display, der kann auch toggeln) unterscheiden. Ggf. siehe WIKI: http://www.fhemwiki.de/wiki/LaCrosseGateway

Gruß PeMue

[rendgeor]

Hallo PeMu,
ja, meine Fragen beziehen sich nur auf den LaCrosse Gateway.
Der RFM69 kann ja auch mit den PCA301 und den LaCross Temperatursensoren (z.B. TX35DTH) sprechen.

1) Daher nochmals präziser gefragt:
Brauche ich mehrere RFM69 Module damit ich parallel die Temperaturwerte empfangen & gleichzeitig die Steckdosen schalten kann?
Oder warum sonst sollten 3-5 Module betrieben werden?

2) Kann der Gateway auch empfangene Werte zwischenspeichern (falls FHEM nicht läuft)?

3) Kann der Gateway auch Werte im Display anzeigen OHNE dass der FHEM das Kommando dazu schickt?

danke im Vorraus,
Oliver

[HCS]

1) Daher nochmals präziser gefragt:
Brauche ich mehrere RFM69 Module damit ich parallel die Temperaturwerte empfangen & gleichzeitig die Steckdosen schalten kann?

Ja. LaCrosse und PCA301 sind unterschiedliche Protokolle und unterschiedliche HF-Übertragung -> zwei RFM69

2) Kann der Gateway auch empfangene Werte zwischenspeichern (falls FHEM nicht läuft)?

Nein.

3) Kann der Gateway auch Werte im Display anzeigen OHNE dass der FHEM das Kommando dazu schickt?

Wenn man die MCP23008-Erweiterung dran hat, kann man damit das Display vor Ort steuern, ohne nur von FHEM aus.
Es kann aber nur die Werte von seinem eigenen Sensor (BME280, BMP180, DHT22, ...) anzeigen, keine Werte, die es von Sensoren (LaCrosse, ...) empfangen hat.

[juergs]

Alle drei RFMs haben ja eigene Puffer, so dass keine Austastzeiten der einzenlen Protokolle entstehen.
Sozusagen asynchron ... ansonsten bestünde die Gefahr, dass Protokolle verloren gingen je nach
Dauer der Abfrage bzw. Protokollumschaltung+ Initialisierung bei nur einem RFM.

Anbei meine Messungen mit allen drei Sensortypen im Vergleich.
Kurz vor 8:00 Uhr habe ich meinen Rollagen geöffnet.
Hier hat der DS18B20 (ohne Hülse), weil näher zum Fenster schön empfindlich reagiert.
Von den Absolutwerten scheinen alle drei Sensortypen ganz gut beisammen zu liegen.
Allerdings habe ich auch nicht auf 0.1 Grad genau kalibriert. 
Ich bin Batteriemäßig jetzt von 3V auf um die 4.1 Volt Lithium Accu (18650) ausgewichen.
Der DHT läuft ohne Probleme und etwas mehr RSSI ist dabei auch noch herausgesprungen.
Mal schauen, wie sich die Langzeit-Stabilität sich entwickelt.

Vielen Dank für Eure Anregungen.

Grüße,
Jürgen

[SusisStrolch]

So - nochmal ein letzte wüstes Bild...
Messumgebung:
  5x DS18B20 im Metallgehäuse, auf Kühlkörper getaped, ESPEasy, 0.01° Auflösung (12 bit)
  LGW.BME280: ohne direkte thermische Kopplung am gleichen Kühlkörper (systembedingt 0.1°C Auflösung)
  ESPEasy.BME280: ohne direkte thermische Kopplung am gleichen Kühlkörper, 0.01° Auflösung (20bit)
  ESPEasy.DHT22: ohne direkte thermische Kopplung am gleichen Kühlkörper, 0.01° Auflösung (16bit)
  Delta-T wurde anhand des Mittelwert von vier DS18B20 gebildet.

Alle Messewerte sind "raw", d.h. ohne Kalibrierungsfaktor oder -offset.

DS18B20
Die Werte liegen eigentlich im +/1 Bit Zählfehlerbereich - bis auf den kleinen Ausreiser vom Sensor DA - der hat einen konstanten Offset von ca. 3x LSB.
Bei der Extremwert-Bestimmung (Eiswasser, kochendes Wasse bei 1013hPa) lagen die DS' im Mittel bei ~0,3° / 100,2° - eigentlich ein akzeptabler Wert um in diesem Falle ohne große Kalibrierung zu arbeiten.

BME280
Die beiden Sensoren liegen nur ~0.2°C auseinander - ausreichend genau für den Hausgebrauch.
Die Differenz zum DS liegt bei 0.4 - 0.6° - was eigentlich ein akzeptabler Wert ist.
Deutlich sichtbar ist die geringe Reaktionszeit bedingt durch die Bauform und Masse. Dies bedeutet wiederum, das die Bauart und -form des Shields selbst Einfluss auf die Temperaturdifferenz hat.

DHT22
Die Abweichung des DHT22 ist mit ~0.3° aktzeptabel. Allerdings sieht man bei deltaT und Absolutwerten, dass die 16bit anscheinend nicht durchgereicht werden - im Diagram ist ein 0.1°C Rauschen sichtbar.

Ich gehe mittlerweile davon aus, dass die extremen Abweichungen (>2°) der BME's von der direkten Umgebung der Sensoren (genauer: der Plazierung bzw. der Beschaltung) abhängig sind - nicht jedoch von der Grundgenauigkeit.

[HCS]

Der DHT22 liegt bei mir von der Temperatur auch sehr gut, aber rH stimmt nicht.

Der BME280 (FORCED mode) liegt konstant fast genau 1°C zu hoch und er wird durch nichts erwärmt.

Der SHT75 reagiert auf geringe Temperaturänderungen (0.5°C) extrem schnell, der (Metall-)DS18B20 braucht da teils 5 Minuten oder mehr, bis er bei der Temperatur angekommen ist. Aber dann decken sie sich wieder tadellos und dauerhaft.

Der LM75 liegt deutlich zu tief. Zwischen LM75 und dem BME280 beträgt die Differenz immerhin 2°C. Aber der LM75 kann eh nur 0.5°C-Schritte.

Aktuell bin ich recht sicher, dass der SHT75 stimmt (sowohl Feuchte als auch Temperatur) und der DS18B20 auch.

Es kann ja durchaus sein, dass bei es den BMEs gut und schlecht kalibrierte gibt. Bei den BMP180 habe ich das auch schon mal ermittelt (vor längerer Zeit). 6 Stück vermessen und einer lag deutlich daneben.
Das Ergebnis sah so aus:

Code Auswählen Erweitern

#1: 22,2 / 1020 hPa
#2: 22,2 / 1022 hPa
#3: 22,5 / 1019 hPa
#4: 22,2 / 1021 hPa
#5: 22,7 / 1022 hPa
#6: 24,2 / 1022 hPa

[Hagenuck1]

@HCS da ich gerade im Platinen Thread gelesen habe, dass du in der 1.22 drei Modi, unter anderem einen LAN Modus einbauen wolltest und man das WLAN dann ja nicht mehr bräuchte habe ich da ne kleine Idee.

Ich weiß nicht, ob du den Amazon DASH Button Thread hier schon mitbekommen hast. Hier gibt es für 5€ nen IO Button, der per WLAN angebunden wird. Ich hatte als ich es gesehen habe direkt die Idee, ob das nicht mit dem LGW, der per LAN angeschlossen ist, kombinieren kann. Der LGW wurde dann einen WLAN Accesspoint öffnen und hier einfach die DHCP Requests abfangen, die die Buttons senden ins Internet mussten die laut aktuellem Stand gar nicht kommen und man könnte sich somit noch nen zusätzliches Endgerät (OpenWRT Router z.B.) sparen, das durchgehend laufen müsste. Justme1968 ist da auch ganz aktiv am mit entwickeln/ testen momentan.


Gesendet von iPhone mit Tapatalk

[oli82]

Mal eine Frage zum Bestücken des BME280.
Auf der Platine des Gateway ist ein Punkt aufgedruckt, der eigentlich mit dem Punkt auf der Unterseite des BME übereinstimmen müsste.
Leider bekomme ich keine Daten des Sensors. Ist dort ein Fehler in der Library des Bauteils? Ich Frage nur, da das Bild im Wiki dann nicht stimmt.

Der BME280 sollte ja nach dem I2C und Sensorscan beim Start des LGW aufgeführt werden oder irre ich mich da?

[PeMue]

Auf der Platine des Gateway ist ein Punkt aufgedruckt, der eigentlich mit dem Punkt auf der Unterseite des BME übereinstimmen müsste.

Nein, das ist der Punkt, der rechts oben auf dem Gehäuse eingraviert ist (nicht mit der Bohrung unten verwechseln), siehe Bild.

Gruß PeMue

[oli82]

Schande über mein Haupt!
Ich habe einen BME280 bestellt und einen BMP280 geliefert bekommen.
Da kann das nicht funktionieren