CumulusMX Web Tag <#EcowittReception>

[moppedhausi]

Hab es mit
$ecowittfirmwareversion = '<#EcowittFirmwareVersion>';

Ergebnis:
$ecowittfirmwareversion = '3.0.5';

[Gyvate]

nach einem Restart klapp bei mir alles:
$ecowittbatt = '<#EcowittReception>';
$test = '<#EcowittReception format=json>';
$test2 = '<#EcowittFirmwareVersion>';
$test3 = '<#GW1000FirmwareVersion>';

$ecowittbatt = 'WH40=4,WH31CH1=4,WH31CH2=4,WH31CH3=4,WH31CH4=4,WH31CH5=4,WH31CH6=4,WH31CH7=4,WH51CH1=4,WH51CH2=4,WH51CH3=4,WH51CH4=4,WH51CH5=4,WH51CH6=4,WH41CH1=4,WH41CH2=4,WH57=4,WH55CH2=4,WH34CH1=4,WH45=4,WH35CH1=4,WH90=4';
$test = '{"WH40":4,"WH31CH1":4,"WH31CH2":4,"WH31CH3":4,"WH31CH4":4,"WH31CH5":4,"WH31CH6":4,"WH31CH7":4,"WH51CH1":4,"WH51CH2":4,"WH51CH3":4,"WH51CH4":4,"WH51CH5":4,"WH51CH6":4,"WH41CH1":4,"WH41CH2":4,"WH57":4,"WH55CH2":4,"WH34CH1":4,"WH45":4,"WH35CH1":4,"WH90":4}';
$test2 = 'GW2000A_V3.0.5';
$test3 = 'GW2000A_V3.0.5';

Habe den Post im CMX Forum korrigiert.

Nun, das ist jetzt mit dem lokalen Ecowitt Gateway API Treiber.

Wenn es die Zeit ergibt, werden ich noch einen Test mit dem GW2000 als http(Ecowitt) Custom Server machen.

[Gyvate]

nebenbei bemerkt - Dir ist schon klar, das $ecowittbatt ein irreführender Name ist, da das Ergebnis von <#EcowittReception> überhaupt nichts mit Batterien zu tun hat. $ecowittsig oder $ecowittsignal wäre ein wesentlich treffenderer Name.
Programmtechnisch ist es egal, da es ja "nur" ein Variablenname ist - aber der Lesbarkeit halber ...
nur so als Randbemerkung

[olicat]

Hi!

Da die Empfangsqualitaet nicht im Ecowitt-Format definiert ist (es gibt keine entsprechenden Keys), erklaert sich auch, warum die zwar per GW1000-API als Webtag verfuegbar ist, nicht jedoch per custom server - CMX hat bei Eingang der Daten per http keine Kenntnis davon: n/a.
Die Batteriewerte sind hingegen sowohl per Ecowitt-Format als auch per GW1000-API verfuegbar.

Oliver

[Gyvate]

das dachte ich mir schon ...
vielleicht kann @Moppedhausi seine Davisdaten auch beimischen, wenn der GW2000 über das lokale API abgefragt wird.
Wahrscheinlich aber eher nicht. Die "Beimischung" geht meines Wissens nur bei der http(Ecowitt) Variante.

[Gyvate]

Fazit: geht nicht in dieser Konstellation - nur mit dem lokalen Ecowitt Gateway API.

[moppedhausi]

Hab mal testweise auf lokale Gateway Ecowitt API umgestellt.

Dann funktioniert es auch bei mir:

$ecowittreception = 'WH40=4,WH31CH1=4,WH31CH2=4,WH31CH3=4,WH31CH4=4,WH31CH5=4,WH57=4,WH34CH1=4,WH45=4,WH90=4';
$ecowittreceptionjson = '{"WH40":4,"WH31CH1":4,"WH31CH2":4,"WH31CH3":4,"WH31CH4":4,"WH31CH5":4,"WH57":4,"WH34CH1":4,"WH45":4,"WH90":4}';

[moppedhausi]

Die Batteriewerte sind hingegen sowohl per Ecowitt-Format als auch per GW1000-API verfuegbar.
Oliver

Mit welchen Web Tags kann ich diese abfragen, Oliver?

[olicat]

Hi!

Ich weiss nicht, ob es schon entsprechende Webtags im CMX gibt.
Nur wenn Mark schon die Signalqualitaet zur Verfuegung stellt, koennte er doch auch die Batteriewerte liefern.
Wenn fuer die Signalqualitaet $ecowittreception genutzt wird, wuerde ich fuer die Batteriewerte $ecowittbattery erwarten.

Ich habe eben mal in den Source geschaut - es gibt keinen Webtag fuer die Batteriewerte der Ecowitt-Sensoren. Vielleicht waere das aber einen feature request wert.
Und das wuerde eben in beiden Einlieferungsprotokollen funktionieren.

BTW:
Ich hatte mal was von einem Webtag <#BatteryLowAlarm> fuer das GWxx00 gelesen.

Oliver

[Gyvate]

so wie ich das verstehe, kann man <#BatteryLowAlarm> bei einem GW1000 API Gerät mit dem Parameter tx=n, n=Sensor ID erweitern und sollte dann im Alarmfall "1" bekommen und ansonsten "0".
Müsste man mal ausprobieren.

Das API selbst stellt ja Sensorbatteriestatus und Sensorsignalstatus bereit, und der Ecowitt Gateway Treiber von weewx wertet die auch aus/stellt die bereit.

Der erweiterte weewx Interceptor Treiber stellt auch Batteriewerte aus dem Customized Post zur Verfügung.
CMX kann das meines Wissens noch nicht so umfänglich - vielleicht eine zusätzliche Beschäftigung für Marks frisch begonnenes Rentnerleben