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

[Omega-5]

Es hat mir (oder mich?) in den Fingern gejuckt. 
Mal geschaut welche Bauteile schon in den Eagle Libs sind und wie groß der Platzbedarf wohl ist. Natürlich kann man auch einige Module auf die Unterseite packen und unter das Dev-Kit. Aber jetzt habe ich wenigstens schon mal eine Vorstellung wie groß das Gehäuse sein muss.

Gruß Friedrich

[HCS]

Es hat mir (oder mich?) in den Fingern gejuckt. 

Cool. Jetzt kannst Du mit PeMue absprechen, wer sie machen will...
Um die Themen etwas zu kanalisieren, schlage ich vor, einen eigenen "Hardware" Thread für die Platine aufzumachen, am besten von demjenigen, der sie designen will, dass er Beitrag #1 ändern kann.
Ich habe eine Reihe Ideen/Punkte dafür, die würde ich dann dort posten.

Würde derjenige, der das Design macht, auch Produktion und Verteilung organisieren?

[PeMue]

Cool. Jetzt kannst Du mit PeMue absprechen, wer sie machen will...

Hallo Friedrich,

sollen wir knobeln? Wenn das Layout nicht zeitkritisch ist, kann ich es machen. Aber ich lasse Dir gerne den Vortritt 

Gruß PeMue

[Wzut]

Ich werde noch den beliebten DHT22 und den BME280 mit autosense implementieren

D.h. ich kann das Thema LM75 vorläufig zur Seite legen ?
if (HCS_Antwort eq "ja") { OK; }
else
{
da der LM75 drei Address Pins hat: Soll eine bestimmte Adresse fix vorgegeben werden     oder eine mini Suche über die möglichen acht Adressen statt finden ?   
}

[HCS]

D.h. ich kann das Thema LM75 vorläufig zur Seite legen ?

Eigentlich brauchst Du nichts machen, ich habe in einem anderen System (meiner Heizungssteuerung) eine Reihe LM75 laufen, die Routinen sind somit vorhanden und die Dinger kenne ich mehr als mir lieb ist.
Bin übrigens (aufgrund der Erfahrung aus diesem System) kein besonderer LM75 Fan.
Die liegen teils auch bis zu zwei Grad daneben, musste für alle Temperaturen Offsets konfigurierbar machen.

Ich habe wohl noch einige LM75 ganz unten in der Kiste vergraben, wenn DHT22 und BME280 durch sind, baue ich den vielleicht noch ein, und dann ist gut.
Auf I2C kann ich mich eher mit sowas anfreunden.
Muss jetzt sowieso erst mal die InternalSensors umarangieren ...

Der DHT22 und der BME280 laufen aber schon mal generell.

[Doublefant]

meine Erfahrungen:
Hardware: Huzzah Dev Board+ CP2104 USB Bridge + RMF12

- Teile zusammengelötet
- mit dem nodemcu-flasher deine Software Version 1.07 aufgespielt
- neu gestartet und mit dem Accesspoint verbunden
- über die Setup IP Page meine Netzwerkdaten eingegeben (static IP)
- Werte werden über die serielle Schnittstelle ausgegeben
- in Fhem definiert
- mit einem LaCrosse gepairt
- funktioniert 

Tolles Teil und problemlos einzurichten, DANKE!

Der RFM69 ist leider noch nicht angekommen, ich denke aber der wird dann auch am Board laufen.
Blöderweise bin ich bei der Bauteilbestellung noch vom DS1820 ausgegangen, somit habe ich jetzt noch keinen Sensor direkt dran hängen.
Ich werde mir einen passenden Sensor nachbestellen.

Bitte zur Bestätigung ob ich das richtig verstanden habe:
-Im Moment wird nur der BMP180 unterstützt
-DHT22 und BME280 sind in der Testphase
-DS1820 und LM75 werden erst einmal nicht unterstützt

Allerdings verstehe ich noch nicht worin der use-case eines Luftdrucksensors Indoor besteht, außer nice to have.

Die Idee mit dem Sub-Prozessor über RS232 finde ich ein nettes Feature. Für mich würde sich damit die Möglichkeit bieten eigene Hardware einzubinden ohne sich mit Raspbian und Fhem Protokollen/Datenübergabe/Einbindung einlesen zu müssen.

Zum Abschluss noch ein Hinweis:
Bei mir sendet die Gateway alle paar Sekunden einen Statusbericht über die Serielle Schnittstelle.
Der gleiche Bericht wird auch in Fhem über Wifi übertragen.
Da dort sehr viele Informationen drin stecken wird der Event Monitor und das Logfile meiner Meinung nach sehr zugespamt.
Ich Tippe aber darauf, dass es zum Debugging während der Entwicklung in der Beta-Phase extra so gewollt ist?

[Billy]

Allerdings verstehe ich noch nicht worin der use-case eines Luftdrucksensors Indoor besteht, außer nice to have.

Das ist der normale use-case.
Dem Luftdruck ist es wurscht ob er innen oder außen gemessen wird.
Deshalb wird bei den meisten Wetterstationen der Luftdruck innen im Empfangsteil gemessen.

Gruß Billy

[habeIchVergessen]

UDP-Mulitcast

habe ein Test fertig und bin etwas erstaunt, das ein HTTP-Response ca. 200 - 500 ms benötigt. Ein UDP-Multicast benötigt lediglich 1,001 ms.
Im Sketch noch die WiFi-Einstellungen vornehmen.

Empfang der Pakete kann mit tcpdump getestet werden (alle 5s 2 Pakete).

Code Auswählen Erweitern


tcpdump -i <interface> -n dst port 12345


HTTP-GET via telnet

Code Auswählen Erweitern


GET / HTTP/1.1



HTTP-POST via telnet

Code Auswählen Erweitern


POST /config HTTP/1.1
Content-length:6
Content-type:application/x-http-form-urlencoded

p1=abc


[HCS]

Der RFM69 ist leider noch nicht angekommen, ich denke aber der wird dann auch am Board laufen.

Ja, läuft.

Bitte zur Bestätigung ob ich das richtig verstanden habe:
-Im Moment wird nur der BMP180 unterstützt
-DHT22 und BME280 sind in der Testphase
-DS1820 und LM75 werden erst einmal nicht unterstützt

Der BMP180 wird aktuell unterstützt. Er misst Luftdruck und Temperature
DHT22 und BME280 werden in der V1.08 (wohl nächste Woche) verfügbar werden.
Der LM75 wird vermutich irgendwann auch noch implementiert (aber ohne Garantie) und der DS1820 wohl eher nicht.

Man kann, wenn es dann so weit fertig ist, folgendes messen (je nach Bestückung):
BMP180: Druck und Temperatur
BME280:  Druck, Temperatur und Feuchte
DHT22: Temperatur und Feuchte
BMP180 + DHT22:  Druck, Temperatur und Feuchte

Bei mir sendet die Gateway alle paar Sekunden einen Statusbericht über die Serielle Schnittstelle.
Der gleiche Bericht wird auch in Fhem über Wifi übertragen.
Da dort sehr viele Informationen drin stecken wird der Event Monitor und das Logfile meiner Meinung nach sehr zugespamt.
Ich Tippe aber darauf, dass es zum Debugging während der Entwicklung in der Beta-Phase extra so gewollt ist?

Du meinst die "OK VALUE ..." Daten?
Das ist ein Feature. Das LGW sendet periodisch seine Statusdaten an FHEM.
Auf der Setup-Page kann man das einstellen, ob und wie oft. Das setting ist "KV-Interval"
10 bedeutet alle 10 Sekunden die Informationen übermitteln. Mit "off" kann man es abschalten.
Wenn Autocreate aktiv ist, sollte eigentlich automatisch ein KeyValueProtocol device in FHEM angelegt werden, in das die Daten reinlaufen, und dort kann man die Events ja dann mit event-on-change-reading usw. bremsen.
Ich logge z.B. FramesPerMinute und RSSI, um zu sehen, ob das LGW noch ordentlicht Sensoren empfängt und ausreichend wlan Empfang hat. Siehe Beispiel LGW.png.
Man kann damit auch sehr gut verschieden Standorte für das LGW austesten oder schauen, ob es bestimmte Zeiten gibt, zu denen der Empfang durch irgend etwas gestört wird, ...

Generell: das LGW sendet alle Daten, die es über wifi an FHEM zustellt, auch auf die serielle Schnittstelle. Somit kann man das LGW auch (alternativ, gleichzeitig macht keinen Sinn) anstatt über wifi so wie einen JeeLink an FHEM betreiben. Dazu kann man über die initCommands des jeeLink device in FHEM das wifi im LGW mit dem Command "0w" abschalten.

[HCS]

habe ein Test fertig und bin etwas erstaunt, das ein HTTP-Response ca. 200 - 500 ms benötigt. Ein UDP-Multicast benötigt lediglich 1,001 ms.
Im Sketch noch die WiFi-Einstellungen vornehmen.

Ich verstehe die Problematik an sich noch gar nicht. Mein LGW empfängt (siehe Hardcopy im vorhergehenden Beitrag) ca. 100 SensorFrames pro Minute und die werden gebündelt einmal pro Sekunde über den datenport 81, auf dem das JeeLink device sitzt, zugestellt (push) und zwar alle.
Wo liegt das konkrete Problem?

Und bei mir geht übrigens ein http get auf die Status-Seite des LGW auch deutlich schneller, so im Bereich 50-60 ms, siehe Anhang.

[HCS]

Das ist der normale use-case.
Dem Luftdruck ist es wurscht ob er innen oder außen gemessen wird.
Deshalb wird bei den meisten Wetterstationen der Luftdruck innen im Empfangsteil gemessen.

Genauso ist es. Das war schon beim "SuperJee" der Grund, warum ich dort den BMP180 implementiert habe. Man hat alle Daten der Wetterstation in FHEM außer dem Luftdruck, weil der nicht vom Außensensor gemessen und gesendet wird, sondern von der Anzeigeeinheit, die man im Haus an der Wand hängen hat.
Und irgendwie will man ja wissen, dass gerade ein Sturmtief naht. 

[Doublefant]

Uhhh sorry 
Wenn man keine Ahnung hat, einfach mal die Klappe halten...

Naja, immerhin habe ich was gelernt, der Luftdruck wird in der Basisstation gemessen und nicht im Außensensor

Genau, ich meinte die "OK VALUE..." Daten.
Achso, ich kann das Intervall einstellen, sehr gut, muss ich gleich mal probieren. Das muss ich im Eifer bei der Einrichtung übersehen haben.
Das KeyValueProtokoll wurde automatisch angelegt und wird auch schön mit Daten gefüttert.

[HCS]

Wenn man keine Ahnung hat, einfach mal die Klappe halten...

Nö, ist schon OK, wenn man fragt.

[HCS]

V 1.08

Sensoren
Es werden nun folgende Sesoren unterstützt:
BME280, BMP180, DHT22 und LM75

Die Sensorphalanx arbeitet so:
Alle Sensoren werden automatisch erkannt, wenn sie vorhanden sind.
Sie werden in folgender Reihenfolge verwendet:
Wenn ein BME280 vorhanden ist, wird dieser verwendet und sonst nichts, da man dann bereits Temperatur, Feuchte und Druck hat.
Ist kein BME280 vorhanden, wird geschaut, ob ein BMP180 vorhanden ist. Falls ja, haben wir Druck und Temperatur.
Dann wird geschaut, ob ein DHT22 vorhanden ist. Wenn ja, wird er zusätzlich verwendet, aber vom BMP180 dann nur noch der Druck.
Temperatur und Feuchte vom DHT22, dass dieses Wertepaar von einem Sensor stammt.
Wenn kein BMP180 und kein BME180 da ist, sondern nur ein DHT22, dann hat man Temperatur und Feuchte.
Wenn nichts Vernünftiges vorhanden ist (also keiner der bisher genannten Sensoren), wird, falls vorhanden, der LM75 verwendet.

Daraus ergeben sich folgende Sensor-Varianten (andere ergeben keinen Sinn):
BME280
-> Temperatur, Feuchte und Druck

BMP180:
-> Temperatur und Druck

BMP180 + DHT22:
-> Temperatur, Feuchte und Druck

DHT22
-> Temperatur und Feuchte

LM75
-> Temperatur

Schaltplan
An Beitrag #1 hänge ich die aktualisierte Schaltung an.
LaCrosseGateway-CircuitDiagram-DevBoard-Minimum.png = Minimalausbau mit einem RFM
LaCrosseGateway-CircuitDiagram-DevBoard-Full.png = Alle Sensoren, die möglich sind

Hier noch ein Bild (LaCrosseGateway-SensorPhalanx.png) von einem voll ausgebauten LGW auf breadboard.
Da beginnt man dann von einer Platine zu schwärmen 
Und klar, ihr habt es schon erkannt, habe es ja oben erläutert, das macht keinen Sinn mit allen vier Sensoren drauf, außer man muss es entwickeln und testen ... 

[PeMue]

Hallo HCS,

ich habe mal hier http://forum.fhem.de/index.php/topic,45594.0.html die Ideensammlung zur Platine gestartet ...

Gruß PeMue