FOSHKplugin

Für Geräte von froggit
fankyy
Offline
Beiträge: 21
Registriert: 01 Mär 2022, 05:19
Hat sich bedankt: 8 mal
Danksagung erhalten: 3 mal

Re: FOSHKplugin

#141

Beitrag von fankyy »

Benutze FOSHKplugin noch nicht lange, ist wirklich eine feine Sache, aber habe seit der Einrichtung immer noch einige Fragen:

Ich hatte mit der Einrichtung der Ports ziemlich Probleme und wohl zufällig immer bereits belegte Ports verwendet, FOSHKplugin meldete keine Fehler im log, aber weewx/python meldete bereits verwendeter Port etc. Nach einer Neuinstallation von FOSHKplugin habe ich die Portnummern nochmals gewechselt, bzw. einfach FOSHKplugin wählen lassen, es funktioniert nun (wieder) soweit. Das Installationsskript meldete dann: "Ports are 8081, 8082". Entsprechend definiert in der weewx config habe ich 8082, so wie er auch in der foshkplugin.conf definiert ist. Auf 8081 kann ich via Browser noch die Werte der vorherigen config (?) sehen, aktualisiert sich jedoch nicht mehr (wo die ganzen Sensordaten aufgelistet werden inkl. PASSKEY). Auf 8082 erscheint via Browser nur noch

Code: Alles auswählen

{"errcode":"0","errmsg":"ok","UTC_offset":"-18000"}
In welchem Fall erscheint die Sensordaten-Auflistung und in welchem Fall errcode..? Oder ist der eine Port der Input für die Konsolendaten und der andere der Output von FOSHKplugin?

Frage 2:
Die Standardeinstellung des Auslese, bzw. Sendeintervalls der Konsole von FOSHKplugin ist ja bei 30 Sekunden. Für den WH65 habe ich gedacht, lege ich passend 16 Sekunden fest. Allerdings gehen, im Vergleich zur weewx Instanz mit SDR-Empfänger, immer mal wieder ein paar Böen verloren, nicht viele aber doch merklich (Vergleichsgrafik kann ich bei Interesse posten). Nun wollte ich das Intervall auf 8 Sekunden festlegen, jedoch aktualisierte sich die Seite mit den Werten (PASSKEY etc.) immer noch alle 16 Sekunden. Jedoch sollte sich dabei doch mindestens der Zeitstempel alle 8 Sekunden aktualisieren, selbst wenn die WH65 nicht öfter als alle 16s liefert? Habe noch versucht, die Konsole via FOSHKplugin neu zu starten, dies schlug allerdings fehl (hatte es in der config enabled und FOSHKplugin neu gestartet). Die Konsole ist eine WS2902 (bzw. Ventus W830). Wird ein schnelleres Intervall ev. nur von einem GW1000 und den TFT-Display Konsolen unterstützt?

Seitens weewx nutze ich den interceptor driver, reporting interval 60s, hardware (in weewx.conf)
Benutzeravatar
Gyvate
Offline
Beiträge: 2479
Registriert: 10 Aug 2021, 23:41
Wohnort: Saarbrücken
Hat sich bedankt: 12 mal
Danksagung erhalten: 375 mal
Kontaktdaten:

Re: FOSHKplugin

#142

Beitrag von Gyvate »

fankyy hat geschrieben: 01 Mär 2022, 10:54 .....

Frage 2:
Die Standardeinstellung des Auslese, bzw. Sendeintervalls der Konsole von FOSHKplugin ist ja bei 30 Sekunden. Für den WH65 habe ich gedacht, lege ich passend 16 Sekunden fest. Allerdings gehen, im Vergleich zur weewx Instanz mit SDR-Empfänger, immer mal wieder ein paar Böen verloren, nicht viele aber doch merklich (Vergleichsgrafik kann ich bei Interesse posten). Nun wollte ich das Intervall auf 8 Sekunden festlegen, jedoch aktualisierte sich die Seite mit den Werten (PASSKEY etc.) immer noch alle 16 Sekunden. Jedoch sollte sich dabei doch mindestens der Zeitstempel alle 8 Sekunden aktualisieren, selbst wenn die WH65 nicht öfter als alle 16s liefert? Habe noch versucht, die Konsole via FOSHKplugin neu zu starten, dies schlug allerdings fehl (hatte es in der config enabled und FOSHKplugin neu gestartet). Die Konsole ist eine WS2902 (bzw. Ventus W830). Wird ein schnelleres Intervall ev. nur von einem GW1000 und den TFT-Display Konsolen unterstützt?

Seitens weewx nutze ich den interceptor driver, reporting interval 60s, hardware (in weewx.conf)
Das wird nicht sehr helfen, jedenfalls nicht bei einer WS2320E, WH2910 oder HP2551 Konsole. Die sind schon zu schwach auf der Brust, um das 16 Sekunden-Intervall einzuhalten. Das liegt daran, dass WiFi-Modem und andere Funktionalitäten nur von einem gemeinsam benutzten Prozessor verrichtet werden.
Bei einem GW1x00/GW2000 ist das anders, da es dort einen eigenen WiFi-SoC gibt.
Du wirst zwar die Zahl runtersetzen können, aber in der Realität wird es insbesondere bei der HP2551 Konsole (Froggit HP1000SE Pro) wohl nicht mehr als 20 Sekunden real werden. Eine WS2320E schafft die 16 Sekunden gerade noch, hat ja auch nur eine begrenzte Anzahl an Sensoren zu übertragen. Und, wie gesagt, die GWyx00 Konsolen schaffen es auch, aber für die ist mit weewx der GW1000 API Treiber wesentlich besser als der Interceptor-Treiber, da man beim GW1000 API Treiber das Polling der Konsole erhöhen (die Sekunden erniedrigen) kann. So dass im Loop auch die "Zwischendaten*" ankommen. Im Akkumulator (weewx.conf) kann man dann für den Sensor eintragen, was in die Datenbank kommt (last, avg, max).
(*bzgl. Archivierungsintervall)
Ecowitt WS2320E,HP2553,HP3501,GW2001,GW1100, GW1000,WH2650,WN1910,WN1980, Meteobridge RPi4B-2GB/(16)32GB SLC 3165, Weewx 4.5.1/4.10.2, CumulusMX 3.28.4 b3282, Barani MeteoShield Pro, MetSpecRad02, Personal Weather Tablet(PWT) - http://meshka.eu
Benutzeravatar
olicat
Offline
Beiträge: 2003
Registriert: 07 Dez 2020, 20:33
Wohnort: Hohen Neuendorf
Hat sich bedankt: 26 mal
Danksagung erhalten: 412 mal
Kontaktdaten:

Re: FOSHKplugin

#143

Beitrag von olicat »

Hi!
Ports are 8081, 8082". Entsprechend definiert in der weewx config habe ich 8082,
Ich fuerchte, da fehlt noch etwas Grundverstaendnis ueber die Arbeitsweise von FOSHKplugin bzw. die Kommunikation ueber das Netzwerk insgesamt. Ich muss das wohl nochmal klarer dokumentieren. Aber vielleicht suchtest Du ueber FOSHKplugin auch einfach nur einen freien Port fuer weewx?

Also:
Die Wetterstation sendet an ein frei definierbares Ziel (custm server) die Wetterdaten. Dabei wird die Zieladresse, der Zielport und auch der Pfad festgelegt. Einstellen kann man dies entweder ueber eine der Ecowitt-Apps (WS View, WSView Plus, ...) oder diese Konfiguration durch FOSHKplugin remote erledigen lassen.
Diese Konfiguration durch FOSHKplugin erfolgt durch Bejahen der entsprechenden Abfrage "do you want to write settings into the weather station? (Y/N)" innerhalb der Konfigurationsroutine generic-FOSHKplugin-install.sh.

Damit erhaelt dann FOSHKplugin die Daten der Station und kann diese beliebig weiterleiten.
Ab diesem Moment solltest Du also ueber einen Webrowser per http://ipaddress:port/status&minmax die eingehenden Werte der Station sehen koennen.
ipaddress ist dabei die Adresse des Hosts, auf dem FOSHKplugin installiert wurde und port der Port, der automatisch als freier und somit nutzbarer Port fuer die TCP/IP-Kommunikation durch das Installationsscript gefunden wurde.
Im Config-File nennt sich dieser Port LBH_PORT.

Ist das soweit gegeben, koennen die eingehenden Daten aber auch an andere Ziele weitergegeben werden. Dazu sind entsprechende Forwards zu definieren, die wiederum selbst eine Adresse, einen Port und ggf. einen Pfad (naemlich des Zielsystems) erfordern.
Willst Du also an eine weewx-Instanz die Daten senden, musst Du einen Forward einrichten, der ungefaehr so aussieht:

Code: Alles auswählen

[Forward-36]
FWD_URL = http://192.168.15.237:8080/
FWD_TYPE = EW
FWD_CMT = fuer lokale weewx-Installation
FWD_ENABLE = True
Wobei die Adresse in der FWD_URL dem Zielhost entsprechen muss (also dem System, auf dem weewx laeuft) und der dort mit dem Doppelpunkt abgetrennte Port dem Port, den Du als Eingangsport im weewx definiert hast.
Laufen FOSHKplugin und weewx auf EINEM Rechner kann dieser Port nicht identisch sein - jede Applikation benoetigt die exklusive Bindung eines TCP/IP-Ports.
Du findest den Eingangs-Port fuer weewx in der /etc/weewx/weewx.conf im Bereich [Interceptor] als port = xxxx - wobei als default (meine ich) der Port 8080 definiert ist.

Die Konfiguration von FOSHKplugin war - gerade hinsichtlich der einzugebenden Portnummern - bisher offenbar zu wenig erklaert.
Daher habe ich jetzt fuer die naechste (!) public-Beta (noch im internen Test und nicht verfuegbar) das Installationsscript massiv veraendert - ich hoffe durch die zusaetzlichen textuellen Hilfestellungen wird es nun fuer die Nutzer besser verstaendlich.
Beispiel:

Code: Alles auswählen

+++ FOSHKplugin +++ (4/6)

The weather station must know to which destination it should send the data.
For this purpose, in addition to specifying the IP address of the host (just
done), also a TCP port must be specified on which FOSHKplugin listens for
incoming data from the weather stations.
A free and thus usable port should be found automatically by this installation
routine.
ENTER accepts the specified value in square brackets.

http port on local system - accept with ENTER [freierPort]: _
Dabei habe ich auch die missverstaendliche Anzeige "The port is xxxx" (die eigentlich nur den gerade auf Verfuegbarkeit getesteten Port ausgibt) auf "port $xxxx is already in use" geaendert.
Der tatsaechlich genutzte und in die Konfigurationsdatei foshkplugin.conf geschriebene Port wird bei der Abfrage

Code: Alles auswählen

+++ FOSHKplugin ### http port on local system [yyyy]:
in den eckigen Klammern angezeigt.
Wobei - siehe oben - dieser Port ausschliesslich den Port angibt, ueber den FOSHKplugin von der Wetterstation oder vom Nutzer ueber das Webinterface erreicht werden kann. Mit weewx hat dieser Port also rein nichts zu tun.
In welchem Fall erscheint die Sensordaten-Auflistung und in welchem Fall errcode..?
Dies ist die Rueckmeldung an einen per http/POST sendenden Host (eigentlich die Wetterstation), das die Daten erfolgreich empfangen wurden.
Mich ueberrascht etwas, das Du diese im Webbrowser siehst - denn der Webbrowser macht seine Anfragen eigentlich ueber http/GET.

FOSHKplugin nutzt einen TCP/IP-Port sowohl fuer den Empfang der Wetterstationsdaten (sowohl GET als auch POST) als auch zur Anzeige der Werte ueber das http-Interface (ausschliesslich GET).

Zu Deiner 2. Frage faellt mir momentan nicht so richtig was ein. Ich meine, da hat es mit einer der letzten Firmware-Versionen (WIFI-Firmware) eine Verschlechterung seitens Ecowitt gegeben.
Seither werden die festgelegten Sendeintervalle nicht mehr von den EasyWeather-Stationen geschafft.
Ich halte es fuer einen Fehler in der Firmware. Bisher hat Ecowitt das aber noch nicht eingesehen - man argumentiert da noch mit Anzahl der Sensoren und der generellen Schwachbruestigkeit der verwendeten MCU. Ich glaube, die Firmware wartet da immer noch auf eine Sendung eines angeschlossenen Sensors, obwohl der verfuegbare letzte Wert gesendet werden koennte.
Ich hoffe, das bessert sich wieder - aber zumindest mit den GW1x00-Konsolen laesst sich aktuell noch ein verlaesslicher Intervall (eingetragener Wert + 1 Sekunde - was eigentlich auch ein Bug ist) einstellen.

Wenn Du magst kann ich Dir gern meine interne Beta schicken. Dann kannst Du pruefen, ob der Installationsprozess nun etwas besser nachvollziehbar ist. Damit kann man auch nachtraeglich noch die Installation aendern, ohne nochmal alle Werte neu eingeben zu muessen.

Oliver
fankyy
Offline
Beiträge: 21
Registriert: 01 Mär 2022, 05:19
Hat sich bedankt: 8 mal
Danksagung erhalten: 3 mal

Re: FOSHKplugin

#144

Beitrag von fankyy »

Gyvate hat geschrieben: 01 Mär 2022, 11:05 Du wirst zwar die Zahl runtersetzen können, aber in der Realität wird es insbesondere bei der HP2551 Konsole (Froggit HP1000SE Pro) wohl nicht mehr als 20 Sekunden real werden. Eine WS2320E schafft die 16 Sekunden gerade noch, hat ja auch nur eine begrenzte Anzahl an Sensoren zu übertragen. Und, wie gesagt, die GWyx00 Konsolen schaffen es auch, aber für die ist mit weewx der GW1000 API Treiber wesentlich besser als der Interceptor-Treiber, da man beim GW1000 API Treiber das Polling der Konsole erhöhen (die Sekunden erniedrigen) kann. So dass im Loop auch die "Zwischendaten*" ankommen. Im Akkumulator (weewx.conf) kann man dann für den Sensor eintragen, was in die Datenbank kommt (last, avg, max).
(*bzgl. Archivierungsintervall)
Gut zu wissen, dann pollt der Interceptor Treiber also gar nicht die Zwischendaten? Jedoch in Kombination mit dem FOSHKplugin, sollten die Zwischendaten ankommen? Oder sollte ich auch mit dem FOSHKplugin besser den GW1000 Treiber verwenden? Wie genau sehen die empfohlenen Einträge für last, avg, max in der weewx.conf aus?

olicat hat geschrieben: 01 Mär 2022, 12:10 Hi!
Ports are 8081, 8082". Entsprechend definiert in der weewx config habe ich 8082,
Ich fuerchte, da fehlt noch etwas Grundverstaendnis ueber die Arbeitsweise von FOSHKplugin bzw. die Kommunikation ueber das Netzwerk insgesamt. Ich muss das wohl nochmal klarer dokumentieren. Aber vielleicht suchtest Du ueber FOSHKplugin auch einfach nur einen freien Port fuer weewx?

Also:
[...]

Wenn Du magst kann ich Dir gern meine interne Beta schicken.
Vielen Dank Oliver, für die gute und ausführliche Erklärung! Ich dachte schon, dass das irgendwie so funktionieren muss, aber mir fehlte irgendwie ein Puzzleteil im Verständnis.

Dann habe ich, mit dem Eintrag des selben Ports für weewx also nur die Daten, welche die Konsole an diesen Port sendet, direkt empfangen und ggf. FOSHKplugin dadurch blockiert, vermutlich. Bezüglich der http/POST Meldung auf diesem Port: Habe direkt den Chromium Browser auf dem Raspberry, auf welchem das FOSHKplugin als auch weewx laufen, verwendet. Ev. macht das einen Unterschied, oder aber ich hatte mit dieser config einfach ziemlich viel durcheinander gebracht.

Habe es jetzt richtig eingetragen, LBH Port ist weiterhin 8082 und den Forward so:

Code: Alles auswählen

[Forward]
FWD_ENABLE = True
FWD_CMT = weewx
FWD_URL = 192.168.1.112:8083
FWD_INTERVAL = 8
FWD_IGNORE =
FWD_TYPE = EW
FWD_SID =
FWD_PWD =
FWD_STATUS = True
FWD_MQTTCYCLE = 0
FWD_EXEC =
FOSHKplugin neu gestartet, weewx conf angepasst auf 8083:

Code: Alles auswählen

    device_type = ecowitt-client
    port = 8083
    address = 192.168.1.112
Weewx gestoppt, gestartet. Aber es tat sich nichts in weewx. Allerdings auch keine Fehlermeldung bzgl. Portbelegung durch andere Anwendungen im log, also sollte der ja frei sein für den Forward. Fehlt da noch irgendwas? Mit Abruf über den Browser, die übliche errcode Meldung auf diesem (8083) Port (die Meldung, wenn ich dich richtig verstanden habe, eigentlich für die Wetterstation/GW gedacht sein sollte?) Und auf 8082 die Auflistung der Sensordaten von FOSHKplugin.

Habe nun FOSHKplugin gestoppt, und lasse weewx provisorisch wieder auf 8082 lauschen. Würde sehr gerne die neue Beta mit dem angepassten Installationsprozess testen.

Idee für Weiterentwicklung: wenn man während des Installationsprozesses direkt einen Forward für die gängigsten Wettersoftwares (WsWin, Weewx, Cumulus, ...) einrichten/auswählen könnte, bzw. nur noch IP & Port eingeben müsste, ggf. Intervall, wäre natürlich sehr komfortabel. Falls sich der Forward aber bei keiner dieser Anwendungen unterscheiden würde, bzw. es keine optimalen defaults gibt (für intervall etc.), einfach die Möglichkeit eines ersten allgemeinen Forwards ins Setup integrieren.

Ja, ecowitt pfuscht, was ihre Konsolen und den Ecowitt Wetterdaten-Cloud Service betrifft, schon ziemlich. Wenn ich das gewusst hätte, hätte ich die Firmware der Konsole bei der Einrichtung damals nicht aktualisiert. Auch, dass nur 1 von 4 16s Böenwert pro Minute an ecowitt hochgeladen wird, bzw. es keinen Zwischenspeicher für diese 4 Böenwerte in den Konsolen gibt, ist etwas mau. Ansonsten machen sie ja einiges richtig.
Benutzeravatar
Gyvate
Offline
Beiträge: 2479
Registriert: 10 Aug 2021, 23:41
Wohnort: Saarbrücken
Hat sich bedankt: 12 mal
Danksagung erhalten: 375 mal
Kontaktdaten:

Re: FOSHKplugin

#145

Beitrag von Gyvate »

fankyy hat geschrieben: 01 Mär 2022, 15:43
Gyvate hat geschrieben: 01 Mär 2022, 11:05 Du wirst zwar die Zahl runtersetzen können, aber in der Realität wird es insbesondere bei der HP2551 Konsole (Froggit HP1000SE Pro) wohl nicht mehr als 20 Sekunden real werden. Eine WS2320E schafft die 16 Sekunden gerade noch, hat ja auch nur eine begrenzte Anzahl an Sensoren zu übertragen. Und, wie gesagt, die GWyx00 Konsolen schaffen es auch, aber für die ist mit weewx der GW1000 API Treiber wesentlich besser als der Interceptor-Treiber, da man beim GW1000 API Treiber das Polling der Konsole erhöhen (die Sekunden erniedrigen) kann. So dass im Loop auch die "Zwischendaten*" ankommen. Im Akkumulator (weewx.conf) kann man dann für den Sensor eintragen, was in die Datenbank kommt (last, avg, max).
(*bzgl. Archivierungsintervall)
Gut zu wissen, dann pollt der Interceptor Treiber also gar nicht die Zwischendaten? Jedoch in Kombination mit dem FOSHKplugin, sollten die Zwischendaten ankommen? Oder sollte ich auch mit dem FOSHKplugin besser den GW1000 Treiber verwenden? Wie genau sehen die empfohlenen Einträge für last, avg, max in der weewx.conf aus?
Der Interceptor Treiber kann doch nur empfangen, was gesendet wird 8-) . Er arbeitet doch im mode = listen. D.h. schaut nach, was ankommt. Wenn die Konsole nur alle x Sekunden etwas Neues schickt, kann er auch nur alle x Sekunden etwas Neues empfangen (bzw. überhaupt etwas empfangen). Selbst wenn er in mode = sniff liefe, würde das auch nichts ändern. Er kann ja nichts von der Konsole anfordern, sondern muss sich dem begnügen, was die Konsole liefert.

Und FOSHKplugin ist ja "nur" ein man-in-the-middle, das reichert ja die Daten, von Berechnungen mal abgesehen, nicht an. Meines Wissens hat es keine Akkumulator-Funktionen sondern ist ein reiner "Broker" = Weiterverteiler mit möglicher Formatumsetzung und Protokollierung. (Natürlich werden auch zusätzliche Daten berechnet wie z.B. Sonnenscheindauer, aber es werden keine zusätzlichen "Zwischendaten", wie Du das nennst, erhoben).
Auch FOSHKplugin ist ja so etwas wie ein "Interceptor".

Ganz anders beim GW1x00/GW2000, wo die Konsole zum Versenden der jeweils aktuellen Werte aufgefordert werden kann (request, poll, pull). Sofern Du nicht schon einen hast, kannst Du Dir ja einen GW1x00 besorgen und parallel betreiben. Dann kann weewx alle x Sekunden Daten anfordern, wobei natürlich auch der GW1x00 nur liefern kann, was die Sensoren in ihrem Sendeintervall liefern bzw. geliefert haben.
Zuletzt geändert von Gyvate am 01 Mär 2022, 16:22, insgesamt 4-mal geändert.
Ecowitt WS2320E,HP2553,HP3501,GW2001,GW1100, GW1000,WH2650,WN1910,WN1980, Meteobridge RPi4B-2GB/(16)32GB SLC 3165, Weewx 4.5.1/4.10.2, CumulusMX 3.28.4 b3282, Barani MeteoShield Pro, MetSpecRad02, Personal Weather Tablet(PWT) - http://meshka.eu
Benutzeravatar
olicat
Offline
Beiträge: 2003
Registriert: 07 Dez 2020, 20:33
Wohnort: Hohen Neuendorf
Hat sich bedankt: 26 mal
Danksagung erhalten: 412 mal
Kontaktdaten:

Re: FOSHKplugin

#146

Beitrag von olicat »

Hi!

Erstmal nur kurz - bin in Eile:
FWD_URL = 192.168.1.112:8083
Da fehlt ein http:// vor der Adresse.

Oliver
Benutzeravatar
olicat
Offline
Beiträge: 2003
Registriert: 07 Dez 2020, 20:33
Wohnort: Hohen Neuendorf
Hat sich bedankt: 26 mal
Danksagung erhalten: 412 mal
Kontaktdaten:

Re: FOSHKplugin

#147

Beitrag von olicat »

Hi!

Und jetzt nochmal lang ...
Idee für Weiterentwicklung: wenn man während des Installationsprozesses direkt einen Forward für die gängigsten Wettersoftwares (WsWin, Weewx, Cumulus, ...) einrichten/auswählen könnte, bzw. nur noch IP & Port eingeben müsste, ggf. Intervall, wäre natürlich sehr komfortabel. Falls sich der Forward aber bei keiner dieser Anwendungen unterscheiden würde, bzw. es keine optimalen defaults gibt (für intervall etc.), einfach die Möglichkeit eines ersten allgemeinen Forwards ins Setup integrieren.
Ich werde darueber nachdenken.
Aber die Moeglichkeiten sind so derartig vielfaeltig, das es die Optionen bei der "einfachen" Konfiguration leicht sprengen wuerde.
Ich glaube, FOSHKplugin unterstuetzt inzwischen ca. 30 Ausgangsformate/Ziele. Wenn ich da jetzt was fuer weewx basteln wuerde, wuerden andere Nutzer nach einer automatischen Konfiguration fuer WSWin oder CMX schreien.
Und wenn die auch per default unterstuetzt wuerden, haetten andere aber auch gern eine One-Klick-Konfiguration fuer APRS. Oder WU oder WC, WOW, und was der Teufel noch.
Der Aufwand waere immens. Dabei geht es ja eigentlich nur um das Kopieren einiger weniger Zeilen!
Dafuer habe ich extra jede Menge Beispiele fuer entsprechende Forwards veroeffentlicht, die einfach per copy/paste uebernommen werden koennen:

https://loxwiki.atlassian.net/wiki/spac ... OSHKplugin
bzw. auch hier:
https://loxwiki.atlassian.net/wiki/spac ... ic+version

Jede Software, die die Daten von einer Ecowitt-Station verarbeiten soll, erwartet die Daten im Ecowitt-Format auf einer bestimmten Adresse und einem definierten Port. Eventuell ist auch noch die Angabe eines Pfades noetig.
Genau diese Dinge muessen im Forward (FWD_TYPE = EW oder FWD_TYPE = RAWEW) definiert werden - Adresse, Port, Pfad. Der Intervall ist zweitranging, da im Normallfall der Intervall von der Station zu FOSHKplugin genau der ist, in dem FOSHKplugin auch an das Zielsystem sendet.
Wenn Du auf der generic-Seite zu FOSHKplugin nach CMX suchst, findest Du sofort einen passenden Forward. Gleiches betrifft weewx und auch PWSDashboard.
FOSHKplugin kann diese vom Nutzer zu erbringenden Informationen aber nicht wissen! Insofern sehe ich da kaum eine Moeglichkeit zu einer weiteren Vereinfachung.

Dazu kommt:
Ein Nutzer moechte bei der Einrichtung schnell erste Erfolgserlebnisse haben.
Da will er wohl erstmal die grundsaetzliche Funktionsfaehigkeit von FOSHKplugin pruefen und sich dann um die Forwards kuemmern. Die Installationsroutine sollte kurz und knapp und vorallem nur das eigene Programm betreffen.
Aber ich denke darueber nach, welche Hilfestellungen ich da zukuenftig noch geben kann.
Die neue interne Beta (ich schicke Dir den Link) sollte diesbezueglich auch wieder etwas besser sein. Ich bin gespannt auf Deinen Eindruck!

Und nochmal zu den Intervallen oder der intermediate-Berechnung:
FOSHKplugin nimmt im an der Wetterstation vereinbarten Intervall die Daten entgegen und sendet sie an die konfigurierten Forwards weiter.
Eine Zwischenwertberechnung erfolgt bisher nicht.
Wenn also FOSHKplugin die Daten im 20 Sekunden-Takt von der Wetterstation erhaelt und kein groesserer Intervall fuer ein Ziel definiert ist (FWD_INTERVAL), sendet FOSHKplugin diese Daten eben im 20 Sekunden-Takt an die entsprechenden Forwards weiter.
Es kommt was rein - es geht was raus.
Wenn aber bei einem Forward ein groesserer Intervall als der in der Wetterstation konfigurierte definiert ist, werden fuer diesen Forward die dazwischen liegenden Werte einfach nicht gesendet.
Da verhaelt sich FOSHKplugin also exakt so wie die Wetterstation.
Beispiel:
Die Wetterstation sendet im 20-Sekunden-Intervall, FOSHKplugin soll aber Forward-99 nur alle 60 Sekunden beliefern:

t - Eingang Daten WS
0 sende zu Forward-99
20 ignore
40 ignore
60 sende zu Forward-99

Tatsaechlich habe ich mir schon Gedanken gemacht, wie man mit den Zwischenwerten umgehen sollte. Ich wollte das ja auch Fine Offset erklaeren, wie SIE das besser in deren Stationen handhaben sollten.
Vielleicht baue ich so etwas auch irgendwann mal in FOSHKplugin ein. Aber ich hatte nie den Anspruch, eine Wettersoftware daraus zu machen. Es sollte eigentlich nur ein simpler Konverter bzw. Vervielfaeltiger sein. Und die wirklich dafuer gedachte Software (weewx, CMX, WSWin) sollte dies selbst bereits koennen - vorausgesetzt, sie erhaelt die Daten ausreichend haeufig/schnell.
Wobei ich inzwischen schon deutlich mehr Berechnungen mache, als ich mir anfangs auch nur vorstellen konnte.
;-)

Hast Du in Deinem o.a. Forward schon das http:// in die Adresse eingefuegt? Dann sollte weewx die Daten erhalten.

Oliver
fankyy
Offline
Beiträge: 21
Registriert: 01 Mär 2022, 05:19
Hat sich bedankt: 8 mal
Danksagung erhalten: 3 mal

Re: FOSHKplugin

#148

Beitrag von fankyy »

olicat hat geschrieben: 01 Mär 2022, 16:01 Hi!

Erstmal nur kurz - bin in Eile:
FWD_URL = 192.168.1.112:8083
Da fehlt ein http:// vor der Adresse.

Oliver
Oh sorry, hatte ich übersehen, nun funktionierts bestens!

Um die 10min windgust und ggf weitere, von FOSHKplugin berechnete Werte von weewx aufzuzeichnen, muss ich dies im schema file einfügen?
fankyy
Offline
Beiträge: 21
Registriert: 01 Mär 2022, 05:19
Hat sich bedankt: 8 mal
Danksagung erhalten: 3 mal

Re: FOSHKplugin

#149

Beitrag von fankyy »

Gyvate hat geschrieben: 01 Mär 2022, 15:58
Der Interceptor Treiber kann doch nur empfangen, was gesendet wird 8-) . Er arbeitet doch im mode = listen. D.h. schaut nach, was ankommt. Wenn die Konsole nur alle x Sekunden etwas Neues schickt, kann er auch nur alle x Sekunden etwas Neues empfangen (bzw. überhaupt etwas empfangen). Selbst wenn er in mode = sniff liefe, würde das auch nichts ändern. Er kann ja nichts von der Konsole anfordern, sondern muss sich dem begnügen, was die Konsole liefert.

Und FOSHKplugin ist ja "nur" ein man-in-the-middle, das reichert ja die Daten, von Berechnungen mal abgesehen, nicht an. Meines Wissens hat es keine Akkumulator-Funktionen sondern ist ein reiner "Broker" = Weiterverteiler mit möglicher Formatumsetzung und Protokollierung. (Natürlich werden auch zusätzliche Daten berechnet wie z.B. Sonnenscheindauer, aber es werden keine zusätzlichen "Zwischendaten", wie Du das nennst, erhoben).
Auch FOSHKplugin ist ja so etwas wie ein "Interceptor".

Ganz anders beim GW1x00/GW2000, wo die Konsole zum Versenden der jeweils aktuellen Werte aufgefordert werden kann (request, poll, pull). Sofern Du nicht schon einen hast, kannst Du Dir ja einen GW1x00 besorgen und parallel betreiben. Dann kann weewx alle x Sekunden Daten anfordern, wobei natürlich auch der GW1x00 nur liefern kann, was die Sensoren in ihrem Sendeintervall liefern bzw. geliefert haben.
Danke, nun wird mir das nochmals klarer. Folgende Fragen jedoch noch nicht:

- Gibts beim GW1000 driver ein listen-mode, um die Daten von FOSHKplugin zu verarbeiten?
- Akkumuliert der Interceptor driver in weewx? Bei USB-Stationen kann man ja ein polling Intervall definieren, unabhängig des Report-Intervalls, und diese werden akkumuliert.
- Kann ein GW1x00/GW2000 sowohl requests vom GW1000 driver, als als auch das übliche http/POST ziel gleichzeitig bedienen? Weil: Falls ich für eine andere Station/Standort nur einen GW und keine zusätzliche Konsole besorge (wenn letztere ohnehin nicht in der Lage sind, jedes 16s Paket weiterzuleiten), also nur einen GW und Sensoren dazu, und mir die option offen lassen halten will, weitere Wettersoftware wie WsWin gleichzeitig anzusteuern, benötige ich ja die Weiterleitung via FOSHKplugin.
-> Falls dies nicht möglich ist, würde ich ja mit einem tief eingestellten Intervall GW1000 -> FOSHKplugin besser fahren? Bzw. auch kein "Paketverlust" und mehrere Ziele gleichzeitig möglich. Zumindest, sofern weewx mit interceptor driver akkumuliert(?)
Benutzeravatar
Gyvate
Offline
Beiträge: 2479
Registriert: 10 Aug 2021, 23:41
Wohnort: Saarbrücken
Hat sich bedankt: 12 mal
Danksagung erhalten: 375 mal
Kontaktdaten:

Re: FOSHKplugin

#150

Beitrag von Gyvate »

fankyy hat geschrieben: 01 Mär 2022, 18:45 ....

Danke, nun wird mir das nochmals klarer. Folgende Fragen jedoch noch nicht:

(1)- Gibts beim GW1000 driver ein listen-mode, um die Daten von FOSHKplugin zu verarbeiten?
(2) - Akkumuliert der Interceptor driver in weewx? Bei USB-Stationen kann man ja ein polling Intervall definieren, unabhängig des Report-Intervalls, und diese werden akkumuliert.
(3) - Kann ein GW1x00/GW2000 sowohl requests vom GW1000 driver, als als auch das übliche http/POST ziel gleichzeitig bedienen? Weil: Falls ich für eine andere Station/Standort nur einen GW und keine zusätzliche Konsole besorge (wenn letztere ohnehin nicht in der Lage sind, jedes 16s Paket weiterzuleiten), also nur einen GW und Sensoren dazu, und mir die option offen lassen halten will, weitere Wettersoftware wie WsWin gleichzeitig anzusteuern, benötige ich ja die Weiterleitung via FOSHKplugin.
-> Falls dies nicht möglich ist, würde ich ja mit einem tief eingestellten Intervall GW1000 -> FOSHKplugin besser fahren? Bzw. auch kein "Paketverlust" und mehrere Ziele gleichzeitig möglich. Zumindest, sofern weewx mit interceptor driver akkumuliert(?)
1. weewx muss direkt mit dem GW1000 verbunden werden, das macht der GW1000 API Treiber.
Der GW1000 API Treiber kann sich nicht mit FOSHKplugin verbinden. FOSHKplugin ist eine Verteilersoftware für Ecowitt (Klon) Konsolen Posts. Das sind Äpfel und Birnen.

2. Der Interceptor Treiber akkumuliert nicht. Weewx akkumuliert, entweder nach den Standard-Akkumulatoren oder nach dem, was in einer zum Treiber gehörigen Akkumulator-Sektion angegeben wird. Siehe weewx Doku !

3. Ja. Die Antwort auf einen Request an die GW1x00/GW2000 Konsolen und der Custom Server Post, der auch FOSHKplugin bedient, sind zwei unabhängige Kommunikationskanäle, die gleichzeitig benutzt werden können.
(eine weewx Instanz läuft natürlich nur mit einem Treiber !! - theoretisch kannst Du zwei oder mehr weewx Instanzen auf dem selben Server mit jeweils unterschiedlichen Treibern betreiben)

weewx <----> (GW1000 API Treiber) GW1x00/GW2000
weewx <---- (Interceptor Treiber) <---- Ziel (n+1)FOSHKplugin <---- (custom server) GW1x000/GW2000, HP2551, WS2320E, WH2910 (die Konsolen sind hier ausschließlich oder !)
                                               Ziel (n+1), Ziel n <-----FOSHKplugin ---> Ziel 1, 2, 3, ...

4. weewx akkumuliert auch die vom GW1000 API Treiber empfangenen Daten, je nach Einstellung der Akkumulatoren.

weewx mit GW1000 API Treiber (und natürlich einer GW1x00/GW2000 Konsole) ist das optimale Setup, insbesondere bei Deinen Wünschen und Ansprüchen.
Zuletzt geändert von Gyvate am 01 Mär 2022, 19:18, insgesamt 4-mal geändert.
Ecowitt WS2320E,HP2553,HP3501,GW2001,GW1100, GW1000,WH2650,WN1910,WN1980, Meteobridge RPi4B-2GB/(16)32GB SLC 3165, Weewx 4.5.1/4.10.2, CumulusMX 3.28.4 b3282, Barani MeteoShield Pro, MetSpecRad02, Personal Weather Tablet(PWT) - http://meshka.eu
Antworten