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

[PeMue]

Hallo HCS,

UniversalSensor
Das LGW kann nun das UniversalSensor-Protokoll verarbeiten, das angelehnt an LaCrosse:
- Luftdruck
mit CRC16 abgesichert empfangen und an das LaCrosse-Modul weiterreichen kann.

eine Frage zur Luftdruckkorrektur. Bei Sensoren, die direkt vom LGW empfangen werden, kann eine barometrische Höhenkorrektur (z.B. als Parameter 240v) mitgegeben werden.

Ist diese Korrektur für den Universalsensor auch aktiv? Oder muss man das mit einem UserReading selbst erledigen?

Danke + Gruß

Peter

[HCS]

Hallo HCS,
eine Frage zur Luftdruckkorrektur. Bei Sensoren, die direkt vom LGW empfangen werden, kann eine barometrische Höhenkorrektur (z.B. als Parameter 240v) mitgegeben werden.

Ist diese Korrektur für den Universalsensor auch aktiv? Oder muss man das mit einem UserReading selbst erledigen?

Das LaCrosseGateway-device und auch das LaCrosse-device geben den Luftdruck genau so weiter und aus, wie es vom Sensor gesendet wird.
Das LGW kann man konfigurieren, dass es den Luftdruck für eine bestimmte Höhe normalisiert (setup page)
Im hdgucken-Sketch kann man den #define ALTITUDE vor dem compilieren auf die richtige Höhe anpassen, dann sendet er es auch auf diese Höhe normalisiert.

[PeMue]

Im hdgucken-Sketch kann man den #define ALTITUDE vor dem compilieren auf die richtige Höhe anpassen, dann sendet er es auch auf diese Höhe normalisiert.

Aber dann braucht man für jede unterschiedliche Höhe einen eigenen Sketch. Meine Idee war, dass der Sensor den gemessenen Druck (nicht normalisiert) weitergibt und in FHEM das Normalisieren passiert. Wenn es mit dem LGW nicht geht, dann halt per userReading.

Das LGW kann man konfigurieren, dass es den Luftdruck für eine bestimmte Höhe normalisiert (setup page).

Wozu ist dann der Parameter h (z.B. 220h)? Überschreibt der dann den Wert der setup page? Oder ist das der Wert aus der setup page? Werden mit dem Parameter alle Drücke von Sensoren normalisiert? Oder nur, diejenigen die direkt vom LGW kommen?
Sorry die blöden Fragen, aber ich habe den Zusammenhang in den beiden FHEM Modulen noch nicht so ganz verstanden 

Danke + Gruß

Peter

[HCS]

Aber dann braucht man für jede unterschiedliche Höhe einen eigenen Sketch.

Ja, wenn er nicht in der Lage ist, per Konfiguration eine Höhe zu bekommen.

Meine Idee war, dass der Sensor den gemessenen Druck (nicht normalisiert) weitergibt und in FHEM das Normalisieren passiert. Wenn es mit dem LGW nicht geht, dann halt per userReading.

Bisher arbeitet das alles genau umgekehrt. Der Sensor normalisiert.
Wenn er das nicht macht, dann wird wohl ein UserReading erforderlich.

Wozu ist dann der Parameter h (z.B. 220h)? Überschreibt der dann den Wert der setup page? Oder ist das der Wert aus der setup page? Werden mit dem Parameter alle Drücke von Sensoren normalisiert? Oder nur, diejenigen die direkt vom LGW kommen?

Die 220h stammen noch aus JeeLink-Zeiten, der JeeLink-Sketch hat ja keine Konfiguration, also muss man ihm seine Höhe mitteilen.

Da das LGW eine Konfigurations-Seite hat, hat es dann einen Konfiguration für die Höhe bekommen, dass man es ihm nicht immer per 220h schicken muss. 220h macht aber nichts weiter als das, was man auf der LGW-Setup-Page setzt, aus der Ferne zu setzen.

Beim LGW hat mal also die Wahl, ob man die Höhe im LGW konfiguriert oder ob man sie von FHEM aus schicken will.

Wenn der hdgucken-Sensor auf einem ESP8266 läuft, könnte man ihm natürlich ein webif spendieren, um solche Dinge einzustellen.

[PeMue]

Hallo HCS,

Die 220h stammen noch aus JeeLink-Zeiten, der JeeLink-Sketch hat ja keine Konfiguration, also muss man ihm seine Höhe mitteilen.

d.h. FHEM teilt dem JeeLink mit, auf welcher Höhe er ist und der Sensor normalisiert? Das ist dann wohl auch das, was beim LGW auf der Konfigurationsseite passiert.
Also genau andersherum, als ich gedacht habe 

Naja, aber ein UserReading ist ja auch nicht so schwer zu erstellen.

Es macht ja wirklich keinen Sinn, dass mein Universalsensor denkt, er ist auf 53 m Höhe, dabei ist er ich 187 m höher 

Gruß PeMue

Gruß PeMue

[hdgucken]

Hallo Peter,

Es macht ja wirklich keinen Sinn, dass mein Universalsensor denkt, er ist auf 53 m Höhe, dabei ist er ich 187 m höher 

jetzt, wo ich das hier gelesen habe, fällt mir ein, daß ich das mal kommunizieren wollte, mit der Höhe 
Meine Builds und Sketches sind alle auf 53m "eingestellt, Berliner Umland halt 
Vielleicht könnte man das per serieller Konsole lösen oder aber viel schöner Webinterface. Mal schauen, ob ich da zeitnah was machen kann.

Gruß Thomas

[PeMue]

Hallo Thomas,

Meine Builds und Sketches sind alle auf 53m "eingestellt, Berliner Umland halt 

habe ich gesehen und auf 0 m (universal, Korrektur in FHEM) bzw. 240 m compiliert. Ich muss mal testen, was besser ist.

Vielleicht könnte man das per serieller Konsole lösen oder aber viel schöner Webinterface. Mal schauen, ob ich da zeitnah was machen kann.

Mir wäre die Variante über die serielle Konsole lieber, das ist universeller und das könnte ggf. auch ein Atmega644 bzw. STM31F103x.
Etwa in dem Stil wie beim Jeelink:

Code Auswählen Erweitern

220h<cr><lf> über die serielle Schnittstelle schicken und der Sensor liefert

Code Auswählen Erweitern

altitude set to 220 m  ...
zurück  Alle anderen Kommandos werden ignoriert.

Gruß Peter

[HCS]

Code Auswählen Erweitern

220h<cr><lf> über die serielle Schnittstelle schicken und der Sensor liefert

Code Auswählen Erweitern

altitude set to 220 m  ...

... und speichert die Höhe im EEPROM ab, dann muss man sie nur ein mal setzen und es ist für immer gut.

[hdgucken]

Hallo Peter, Hallo HCS,

Mir wäre die Variante über die serielle Konsole lieber, das ist universeller und das könnte ggf. auch ein Atmega644 bzw. STM31F103x.
Etwa in dem Stil wie beim Jeelink:

Code Auswählen Erweitern

220h<cr><lf> über die serielle Schnittstelle schicken und der Sensor liefert

Code Auswählen Erweitern

altitude set to 220 m  ...
zurück  Alle anderen Kommandos werden ignoriert.

... und speichert die Höhe im EEPROM ab, dann muss man sie nur ein mal setzen und es ist für immer gut.

Super Ideen ! Ich werde mich mal darum kümmern, kämpfe aber im Moment mit der STM32 Arduino Implementierung
Meine V2.2 läuft inzwischen, bis auf den RFM69, aber die I2C Implementierung scheint ja richtig verbugt zu sein,
gefällt mir noch nicht ganz, mal sehen, ob ich da was machen kann 
Die SSD1306 Arduino Lib und die BH1750 Lib musste ich noch mal geringfügig anpassen, laufen aber jetzt 
Hab bei der ganzen Umstellung auf den STM32 auch noch ein paar kleine Fehler in der V2.2 gefunden,
wenn ich es schaffe, stelle ich die korrigierte Version heute Abend noch zur Verfügung 

Bis später ...

Edit:habe die Fehler im Projekt Universalsensor (ESP8266) auf Github korrigiert !

[PeMue]

Hallo Thomas,

weiterer Vorschlag (damit Dir nicht langweilig wird  ):
Die ID könnte auch per serieller Schnittstelle konfigurierbar sein (bzw. auch ins EEPROM geschrieben werden).

Danke + Gruß

Peter

[hdgucken]

Hallo Peter,

weiterer Vorschlag (damit Dir nicht langweilig wird  ):
Die ID könnte auch per serieller Schnittstelle konfigurierbar sein (bzw. auch ins EEPROM geschrieben werden).

stimmt, ist notiert 

[Wzut]

@HCS, nachdem ich ewig nichts mehr bei mir ändern musste habe ich mir heute das aktuelle LaCrosseGateway.zip vom SVN geholt.
Meine Arduino IDE 1.8.5 meckert an drei Stellen unter Linux die Groß / Kleinschreibung an :

Code Auswählen Erweitern

RFM.h = spi.h -> SPI.h
TcpServer.h = WiFiclient.h & WiFiserver.h  -> WiFiClient.h & WiFiServer.h

[HCS]

Meine Arduino IDE 1.8.5 meckert an drei Stellen unter Linux die Groß / Kleinschreibung an

Korrigiert und eingecheckt

[sinus61]

Ich habe mir auch mal ein Gateway zusammengelötet in der minimal Ausstattung mit Nodemcu und einem rfm. Und dann die ws1600 vom Jeelink umgehangen, das funktioniert auch sehr gut. Allerdings hab ich jetzt bei der ws1600 die beiden zusätzlichen Readings pressure und gas1 , die auch im Abstand von 5-10 Sekunden aktualisiert werden. Woher kommen die denn jetzt?

In Fhem

Code Auswählen Erweitern


RAWMSG
OK WS 26 1 3 241 255 0 124 255 255 255 255 0 0 0 34 133 234 254 148 32


Und im log

Code Auswählen Erweitern


15:59:10: OK WS 26 1 255 255 255 0 124 255 255 255 255 255 255 0 34 133 234 254 148 32 [A6 81 20 7C 42]


[HCS]

Allerdings hab ich jetzt bei der ws1600 die beiden zusätzlichen Readings pressure und gas1 , die auch im Abstand von 5-10 Sekunden aktualisiert werden.

Ja, das sollte nicht sein. Muss ich mal erforschen, wie das entsteht, habe sie bei mir auch gerade gesehen.