LoxBerry-Plugin: FOSHKplugin - Wettergateway Froggit DP1500 / Ecowitt GW1000 anbinden

[olicat]

Hi!

Was denkst Du darüber? Gibt es irgendwo eine Format-Beschreibung, wie das FOSHK-Plugin die Daten erwartet?

Ich wuerde eine eigene Wetterstation auf jeden Fall mit einer Echtzeit-Ausgabefunktion ausstatten. Fuer mich waere da das Ecowitt-Format das Mittel der Wahl.
Denn damit werden so ziemlich alle denkbaren Sensoren unterstuetzt und es erschliessen sich Welten zur Weiterverarbeitung und Visualisierung.

Schau mal auf meiner Wetter-Seite im Menue, welche Software und Dienste damit angesteuert werden koennen. WeeWX waere natuerlich auch dabei. Neben WeeWX unterstuetzt auch jede "andere" angesagte Wetter-Software das Ecowitt-Format - CMX, PWSDashboard, WeatherDisplay, MeteoTemplate, WSWin, etc. Auch andere Smarthome-Systeme wie HA, Nodered, Homeseer etc kommen am Ecowitt-Format nicht vorbei.

Bei Einsatz von FOSHKplugin kann dieses Format dann auch an unzaehlige Wetterdienste (Awekas, WC, WU, WOW, AmbientWeather, Ecowitt etc.) oder weiterverarbeitende Software (InfluxDB/Grafana, CSV, Webserver, etc) verschickt werden.

Das Ecowitt-Format ist meines Wissens noch nicht offiziell beschrieben. Es gibt jedoch etliche reverse-engineered-Texte dazu.
Grundsaetzlich erfolgt der Versand der Daten an ein Ziel per http/POST ueber key=value-Kombinationen. Die Keys sind mehr oder weniger selbsterklaerend.
Eine gute Anlaufstelle mit Beispielen dazu ist mein EAR-Service. Da gibt es auchentsprechende Beispiele.

Es gibt aktuell eigentlich nur zwei weit unterstuetzte Protokolle: Weather Underground (WU) und Ecowitt.
Beide werden von FOSHKplugin unterstuetzt.
Allerdings hat WU deutliche Einschraenkungen hinsichtlich unterstuetzter Sensoren und ggf. Batteriewerten. Und wird schon seit Jahren nicht mehr erweitert.

Daher: Nimm das Ecowitt-Protokoll.
Ich helfe dabei gern!

Oliver

[Prof.Mobilux]

Das sieht doch perfekt aus! Hatte schon befürchtet, man müsste die Native API irgendwie simulieren (auf dem Ecowitt Sevrer gibt es dazu ein PDF). HTTP Post ist ja superleicht umzusetzen. Danke auch für den Link zum Beispiel - das hilft mir weiter. Hier habe ich auch noch einiges gefunden:

ecowitt_http_gateway/index.php at master · iz0qwm/ecowitt_http_gateway · GitHub
pyecowitt/pyecowitt/ecowitt.py at master · garbled1/pyecowitt · GitHub

Dann werde ich dazu mal ein Plugin bauen, was die Daten unserer Wetterstation entsprechend im Ecowitt Format an das FOSHK Plugin weitersendet. Ab da stehen dann ja alle Wege offen.

[hallansen]

Hi!


Ich wuerde da einen anderen Ansatz verfolgen: TAGFILE.
Mit einem TAGFILE-Forward kannst Du beliebige Textdateien mit Werten der Konsole ausfuellen.
Siehe hier.

Hallo,

ich habe jetzt mal dazu erste Versuche unternommen und die Sachen konfiguriert.
Ziel war, die output.txt erstmal lokal zu speichern.
Ich bekomme aber immer die Fehlermeldung im *.log "28.08.2024 15:10:14.886 <ERROR> FWD-29: save to /opt/FOSHKplugin/ : no input file specified"
Was läuft da falsch bzw. was wird da nicht gefunden?

Gruß Robby

[hallansen]

Hallo,

da bin ich nochmal.
Ich probiere hier nun wegen eigentlich einer Kleinigkeit schon den 2.Tag in Folge an der Taggeschichte.
Ja, ich gebe zu, ich bin keine Programmierleuchte aber so kompliziert kann das ja nicht sein.
Ich habe mich an die Anleitung gehalten aber irgendetwas mache ich hier wohl noch komplett verkehrt
Ich bekomme immer wieder den Fehler "no input file specified", wie schon geschrieben.

Ich bitte darum mir doch mal die 2 Dateien, also die Template + config -Datei als Beispiel zu senden + der Eintrag in die foshkplugin.conf für die zuätzliche Ausgabe.
Mir würde die Ausgabe ins opt/FOHSKplugin Verzeichnis als outfile.txt schon reichen.
Mich interessiert erstmal nur der lightning_num Parameter, der als data20 Wert ausgegeben werden soll.
Den habe ich nun seit heute, da der Blitzsensor eingetroffen ist.

Wenns nicht klappt, dann muss ich halt das Projekt zu den Akten legen.......

[olicat]

Ich probiere hier nun wegen eigentlich einer Kleinigkeit schon den 2.Tag in Folge an der Taggeschichte.

Ich muss mich wirklich entschuldigen.
Ich hatte im obigen Beitrag eine Zeile unterschlagen, ohne die es aber nicht klappen kann.
Es fehlte ein [Tagfile] am Anfang der tag-definition.conf.
Sorry!

Ich habe es oben korrigiert.
Anbei ein ZIP mit der hier getesteten Konfiguration.

Verzeih bitte,

Oliver

[hallansen]

Herzlichen Dank, jetzt passt alles!

Eine letzte Frage wäre noch, ob es auch möglich ist, einen auszugebenden Wert noch um einen Wert zu multiplizieren.
In meinem Falle wäre das 100.
Es sind ja schon ein paar Commands hinterlegt aber das fehlt noch, glaube ich.
Meteohub hat sich da im Import auch total affig, da es die Werte als 100stel Werte erwartet, um die Dezimalstellen abbilden zu können.
Auf der anderen Seite eröffnet aber Meteohub ganz viele Welten, die ich eben nicht missen möchte und bereits ausgiebig nutze.
Wenn es nicht gehen sollte, hätte ich aber noch eine andere Alternative, das umzurechnen.

Trotzdem nochmal vielen Dank für dieses Plugin und die Arbeit, die dahintersteckt.
Schon alleine die lückenlose Dokumentation zum Plugin ist ja schon eine riesen Aufwand - aber Hut ab!!

[olicat]

Hi!

Eine letzte Frage wäre noch, ob es auch möglich ist, einen auszugebenden Wert noch um einen Wert zu multiplizieren.
In meinem Falle wäre das 100.

Schau bitte nochmal in die Doku zu TAGFILE.
Das Kommando eval ist extra dafuer da, auch simple Berechnungen ausfuehren zu koennen.

Angenommen, Dein tag fuer die Innentemperatur sieht so aus:

data12 [[@tempinf]]

und der Wert von tempinf soll mit 100 multipliziert werden, dann sollte der Tag

data12 [[@[eval(@tempinf,*,100)]]]

aussehen.

BTW:
Ich freue mich uebrigens gerade wie Bolle, dass diese Funktion tatsaechlich "gebraucht wird" und zum Einsatz kommt.
TAGFILE ist ein nur ganz, ganz kleiner Teil von FOSHKplugin. Kaum jemand nutzt ihn. Dabei steckt (neben ganz viel Arbeit) auch sehr viel Potential darin.
Bei der Entwicklung sass ich manchmal wirklich da und ueberlegte, was - womoeglich - noch sinnvoll sein koennte.
Das eval-Kommando ist etwas, das ich anfangs nicht auf dem Schirm hatte und was folglich erst spaeter als Resultat solcher Ueberlegungen hinzu kam.

Gruss, Oliver

[hallansen]

Hallo,

und wieder vielen Dank für die Hilfe!
Das hat hingehauen!.

Also ich werde die Tagfile-Geschichte weiter ausbauen. Habe ja nun bissel Blut geleckt und steige ganz gut durch.
Nächstes kleine Projekt soll eine Art Statusseite vom GW1100 werden, die vom Layout her zu meiner Homepage paßt.

Dann trage ich mich noch mit dem Gedanken, den WH46 anzuschaffen, den man für "nur" 135€ inkl. Versand erstehen kann.
Diese Daten dann über Tagfile in mein bestehendes Wetterstationssystem einzubinden und anschließend grafisch aufbereiten zu können, wäre schon eine schöne Spielwiese.
Allerdings grüble ich noch über die Sinnhaftigkeit der Daten des WH46 und das er eigentlich für drinnen gedacht ist.
Ich könnte ihn auch in meine Wetterhütte nach außen verfrachten aber da weiß ich nicht, wie es mit Verschmutzung usw. aussieht....

O.K., das gehört hier vielleicht nicht her, deshalb die Frage, ob jemand einen Tip für ein gescheites Forum hat, wo über dieses Thema diskutiert wird.

Grüße von der Webcam Beucha, Robby

[olicat]

https://www.wetterstationsforum.info/viewforum.php?f=21

[hallansen]

O.K., danke!
Dann werde ich mich mal etwas hineinlesen.

Ach und wenn man weiß wie´s geht, geht´s dann eben fix:

https://webcam-beucha.de/meteohub/gw1100status.html

[Prof.Mobilux]

olicat Das Plugin forwarded ja die ganzen Werte, die ich per Ecowitt-Protokoll einliefere, auch an MQTT. Wir erfassen mit der LoxBerry-Wetterstation einen Wert, den Ecowitt nicht kann: die Dämmerung in %. Wir haben einen normalen Lux-Sensor und zusätzlich für den Dämmerungsbereich eine empfindliche Photodiode, die bei absoluter Dämmerung 100% ausgibt. Kann ich da einfach ein Key/Value-Paar erfinden (z.B. "lb_twilight=100") und das Plugin forwarded den Wert weiter an MQTT? Alle anderen Wetterdienste kennen den Wert ja nicht und müssten ihn einfach ignorieren, oder?

[olicat]

Hi!

Wie genau berechnet ihr denn den Daemmerungswert? Anhand des Analogwerts der Spannung?
Ansonsten werden ALLE im Ecowitt-Format entgegengenommenen key/value-Paare weitergereicht (nur eben ggf. nicht automatisch umgerechnet). Man kann sich da also einen Namen fuer den Key ausdenken.

Oliver

[Prof.Mobilux]

Perfekt. Umrechnung würde ich dann selbst machen - ich muss ja eh ein Plugin für die Wetterstation bauen, die dann die Werte an Dich weiterreicht. Der Luxsensor (VEML7700) übermittelt Werte ganz normal in "Lux", er ist mir aber im Dämmerungsbereich zu ungenau. Deswegen haben wir zusätzlich eine Photodiode, die aber nur eine Spannung abhängig der Helligkeit ausgibt. Die rechne ich um in Bezug auf die Gesamtspannung (3.3V). Ich bekomme also einen Wert "0-100%" Dämmerung, wobei 100% = absolute Dunkelheit. So die Idee.

[olicat]

Hi!

Die neue Version v0.0.10 Beta 240921 ist auf dem Server als loxberry-FOSHKplugin-0.0.10Beta.zip verfügbar.

Seit der letzten öffentlichen Beta hat sich Einiges getan. Siehe dazu auch das Changelog der generic-Version.

Die wichtigsten Änderungen gegenüber der Vorgängerversion sind die Unterstützung der Ecowitt IoT-Geräte (WFC01, AC1100) und die nun 16 möglichen Bodenfeuchtesensoren am GW2000. Man kann jetzt also am GW2000 mit neuester Firmware 16 WH51 betreiben (aktuell NUR am GW2000). Und die Bewässerung via WittFlow- und WittSwitch-Geräten auch über Loxone steuern (mit allen IoT-fähigen Konsolen).

Natürlich gibt es auch eine neue Version der generic-Version von FOSHKplugin (die ohne LoxBerry funktioniert).

Oliver

[Houseruckiii]

Tach, vielen Dank für das plugin olicat !

Habe ein kleines Problem mit MQTT, ich verstehe nicht woher die MQTT Nachrichten mit den Topics "homeassistent" kommen!?
Loxberry FOSHKplugin v0.0.10







Das sind die 2 einzigen Forward Einträge in foshkplugin.conf:

[Forward-1]
FWD_INTERVAL =
FWD_STATUS = False
FWD_QUEUE =
FWD_EXEC =
FWD_CMT = This is a permanent comment field for notes on this forward
FWD_OPTION =
FWD_SID =
FWD_IGNORE =
FWD_TYPE =
FWD_QDIR =
FWD_ENABLE = True
FWD_MQTTCYCLE = 0
FWD_URL =
FWD_PWD =
FWD_REMAP =
FWD_WARNINT = 10

[Sunduration]
SUN_CALC = False
SUN_COEF = 0.92
SUNSHINE_HOLD = 0
SUN_MIN = 0

[Status]
dailyRebootCounter = 0
StopTime = 1727410929

[Forward]
FWD_URL = localhost:1883@WETTER-FOSHK
FWD_ENABLE = True
FWD_MQTTCYCLE = 0
FWD_PWD = XXX
FWD_WARNINT = 10
FWD_REMAP =
FWD_CMT = This is a permanent comment field for notes on this forward
FWD_EXEC =
FWD_SID = loxberry
FWD_OPTION =
FWD_IGNORE = ""
FWD_QDIR =
FWD_TYPE = MQTTMET
FWD_INTERVAL =
FWD_STATUS = True
FWD_QUEUE =

[olicat]

Hi!

Dabei handelt es sich um die Discovery-Items fuer Home Assistant.
Fuer Nutzer mit Home Assistant sind diese ungemein wichtig - denn darueber werden Zusatzinformationen fuer Icon, Einheit etc. festgelegt und die Geraete/Sensoren sind ohne jedwede Konfiguration sofort vollstaendig im Home Assistant integrierbar.

Allerdings war geplant, dass diese Items nur erzeugt werden, wenn der Nutzer dies durch Konfiguration (hass=True in den FWD_OPTIONS) explizit vorgibt.
Es ist also ein Fehler, dass diese Dinge bei Dir erzeugt werden - ich werde das aendern.

Im Moment darfst Du die einfach ignorieren - die Existenz sollte nicht weiter stoeren.

Danke fuer die Info,

Oliver

[Houseruckiii]

Hi, okee, Danke!

[Ulairi]

Hallo!

Ich benötige Hilfe....mein Elektriker hat ja die Platzierung der Loxone Wetterstation komplett verpfuscht und ich musste die von der Hausmauer im Westen wieder abmontieren. Wind und Sonnenschein wurden nicht wirklich erkannt.

Ich bin dann Anfang dieses Jahres auf dieses Plugin gestoßen und hab seitdem einen Ecowitt Wittboy am Laufen. Dieser ist aktuell einfach im Garten auf einem Holzstock montiert.
Meine bessere Hälfte möchte nun, dass die Wetterstation irgendwo hinkommt, wo sie nicht sichtbar ist. In meinem Fall kommt nur das Dach des Hauses oder der Gartenhütte in Frage. Beides sind jedoch Blechdache. Das die Temperaturmessung hier nicht funktionieren wird ist mir vollkommen klar, dies kann ich noch umgehen, indem ich für die Loxone Config den Außentemperatursensor der Wärmepumpe verwende. Mache ich auch schon seit Monaten für die Programmierung, funktioniert ohne Probleme.

Aber wie sieht es mit dem erfassen des Sonnenscheines aus? Wirkt sich da auch irgendwie das aufgehitzte Blech aus? Wird der Sonnenschein dann zu Früh angezeigt?