Das Wetterstationen Forum

Verfasst: **23 Aug 2025, 16:36**

Hallo zusammen,

Habe ein GW2000 mit WS90, und versuche Daten an meinen MQTT Broker zu senden (ikobroker Adapter)
Es kommt aber nur die ID an, keine Daten

: 20250823-160854.png (29 KiB) 271 mal betrachtet

: 20250823-160851.png (23.72 KiB) 271 mal betrachtet

Hat jemand eine Idee woran das liegt? Am MQTT Broker?

Verfasst: **23 Aug 2025, 18:50**

Wenn ich raten müsste: am Format der Payload, vielleicht kann Gyvate ja mal in Erfahrung bringen, was sie sich dabei gedacht haben, diese anstatt in einen JSON String zu verpacken, so zu codieren:

Code: Alles auswählen

'PASSKEY=&stationtype=GW2000A_V3.2.6&runtime=314970&heap=75752&dateutc=2025-08-23%2016%3A46%3A10&dns_err_cnt=17&cdnflg=60&tempinf=71.96&humidityin=47&baromrelin=30.029&baromabsin=28.529&tempf=60.98&humidity=71&vpd=0.157&winddir=34&winddir_avg10m=8&windspeedmph=3.80&windgustmph=8.05&maxdailygust=14.76&solarradiation=57.14&uv=0&rainratein=0.000&eventrainin=2.839&hourlyrainin=0.000&last24hrainin=0.055&dailyrainin=0.004&weeklyrainin=2.850&monthlyrainin=4.929&yearlyrainin=36.157&temp1f=69.26&humidity1=51&temp2f=70.34&humidity2=53&temp3f=72.50&humidity3=48&temp4f=69.80&humidity4=51&temp6f=68.72&humidity6=51&temp7f=73.40&humidity7=54&temp8f=71.42&humidity8=52&soilmoisture1=54&soilad1=271&soilmoisture2=41&soilad2=223&tf_co2=62.06&humi_co2=66&pm25_co2=1.8&pm25_24h_co2=5.9&pm10_co2=2.1&pm10_24h_co2=6.1&co2=342&co2_24h=337&lightning_num=0&lightning=34&lightning_time=1755670222&wh68batt=1.88&wh40batt=1.6&wh26batt=0&batt1=0&batt2=0&batt3=0&batt4=0&batt6=0&batt7=0&batt8=0&soilbatt1=1.2&soilbatt2=1.3&wh57batt=5&co2_batt=6&freq=868M&model=GW2000A&interval=60'

Verfasst: **23 Aug 2025, 20:39**

es ist einfach der Datenstring des Ecowitt Protokolls als Payload in die MQTT Posts gepackt.
Warum bzw. warum nicht .... - eigentlich eine eher akademische Frage

Aber die Daten selbst, die Payload, müssten ja trotzdem ankommen.

Wie die Payload bei MQTT aussieht ist ja dem Publisher/Veröffentlicher überlassen, da gibt es keine Formatvorgaben. Ein bestimmtes Format mag ja dem einen oder anderen genehmer erscheinen, aber eigentlich ist das egal.
Beim Abholen der Daten muss es eben ein Programm geben, das die Payload verarbeiten kann.

M.E. liegt das angebliche Fehlen an der Payloadverarbeitung im HomeAssistant - da passt ein ggf. vorhandenes Verfahren nicht zum Inhalt.

Nur so als Beispiel - bei der weewx Belchertown Skin (Webseite) werden die Daten auch von weewx via MQTT vom weewx Server an den Host der Skin gesendet - und keinesfalls im JSON Format. Trotzdem hat der Skin-Designer dafür gesorgt, dass die übertragenen Daten (Payload) richtig angezeigt werden.

Korrektur Rechtschreibefehler und das falsche Beispiel gewählt

- weewx MQTT benutzt JSON

Verfasst: **24 Aug 2025, 08:10**

Stimmt, danke, dann werd ich das mal auseinander nehmen.

Verfasst: **24 Aug 2025, 09:55**

Gyvate hat geschrieben: 23 Aug 2025, 20:39 es ist einfach der Datenstring des Ecowitt Protokolls als Payload in die MQTT Posts gepackt.
Warum bzw. warum nicht .... - eigentlich eine eher akademische Frage

Keine akademische Frage, eher eine Frage dessen, was ist "Best Practice".

Gyvate hat geschrieben: 23 Aug 2025, 20:39 Wie die Payload bei MQTT aussieht ist ja dem Publisher/Veröffentlicher überlassen, da gibt es keine Formatvorgaben. Ein bestimmtes Format mag ja dem einen oder anderen genehmer erscheinen, aber eigentlich ist das egal.
Beim Abholen der Daten muss es eben ein Programm geben, das die Payload verarbeiten kann.

Und da ist ein Format wie JSON nicht nur praktisch, sondern auch sehr verbreitet.

Gyvate hat geschrieben: 23 Aug 2025, 20:39 M.E. liegt das angebliche Fehlen an der Payloadverarbeitung im HomeAssistant - da passt ein ggf. vorhandenes Verfahren nicht zum Inhalt.

Wäre die payload von ecowitt in JSON, könnte man das in HA ohne Weiteres durch eine einfache Konfiguration lösen. Muss man erst aus einen Datenstring die einzelnen key/value Paare herausparsen, ist das schon aufwändiger.

Gyvate hat geschrieben: 23 Aug 2025, 20:39

Nur so als Beispiel - bei der weewx Belchertown Skin (Webseite) werden die Daten auch von weewx via MQTT vom weewx Server an den Host der Skin gesendet - und keinesfalls im JSON Format. Trotzdem hat der Skin-Designer dafür gesorgt, dass die übertragenen Daten (Payload) richtig angezeigt werden.

Sehr gutes Beispiel, nur stimmen wir beide wahrscheinlich nicht darin überein, warum das ein gutes Beispiel ist!

WeeWX MQTT (die am Meisten genutzte Extension, um aus LOOP-Daten MQTT Daten zu erzeugen) codiert die LOOP Daten als JSON.

Und hier ein Snippet aus dem JS-Code von Belchertown, Preisfrage: was erwartet Belchertown als Format der payload?

Code: Alles auswählen

var mqtt_payload = "";
// New message from mqtt, process it
function onMessageArrived(message) {
    belchertown_debug("MQTT: " + message.payloadString);
    update_current_wx(message.payloadString);
    mqtt_payload = jQuery.parseJSON(message.payloadString);
}

Richtig: Das ist KEINESFALLS etwas anderes, als JSON.

Aber da wir gerade bei MQTT und WeeWX sind: WeeWX-MQTTSubscribe wäre in der Lage, so konfiguriert zu werden, dass es das ecowitt-payload-Format entschlüsseln kann und als LOOP Daten bereitstellt, die man wiederum mit WeeWX-MQTT als JSON-formatierte Strings per MQTT publishen kann, wie man möchte.

Deshalb wäre die Antwort von ecowitt, was sie sich dabei gedacht haben, interessant. Ich glaube aber, dass sie sich nicht mehr Gedacht haben als: "Wir schicken einfach unser bisher verwendetes Format auch per MQTT raus". Es ist ja nicht weiter schwierig zu parsen, aber angesichts der Tatsache, dass man JSON-codierte MQTT-payloads durchaus als quasi-Standard bezeichnen kann, könnte man sich durchaus überlegen, das zumindest als Option anzubieten. Als Hersteller hat man dadurch den Vorteil, das die Geräte von den allermeisten anderen Systemen direkt verstanden werden. Und das wiederum ist für viele potentielle Käufer interessant.

Verfasst: **24 Aug 2025, 11:04**

mitschke hat geschrieben: 24 Aug 2025, 09:55 Es ist ja nicht weiter schwierig zu parsen, aber (1) angesichts der Tatsache, dass man JSON-codierte MQTT-payloads durchaus als quasi-Standard bezeichnen kann, könnte man sich durchaus überlegen, das zumindest als Option anzubieten. Als Hersteller hat man dadurch den Vorteil, das die Geräte von den allermeisten anderen Systemen direkt verstanden werden. (2) Und das wiederum ist für viele potentielle Käufer interessant.

(1) mit welchen Zahlen ist denn diese Behauptung (zur Tatsache wird die erst, wenn dazu ein tragfähiger Beleg vorliegt) untermauert ? Ich sage mal, dass das zunächst eine subjektive Wahrnehmung ist.

Meines Wissens gibt es keine wirklich aktuellen, umfassenden Zahlen, die exakt belegen, wie häufig JSON bei MQTT zum Einsatz kommt. Also, es gibt keine belastbare, öffentlich zugängliche Studie, die den JSON-Anteil in MQTT-Payloads als Prozentzahl ausweist. Die großen, seriösen Surveys (Eclipse Foundation, HiveMQ) messen vor allem Protokolle (MQTT vs. HTTP etc.) und Tooling—nicht die konkreten Nutzdatenformate in MQTT-Nachrichten.

(2) Hast Du dazu einen belastbaren Business-Plan ? Oder sind die "vielen" potentiellen Käufer gesamtumsatzbezogen im Grunde nur einige wenige technophile Enthusiasten ? Wenn es dazu einen einigermassen verlässlich erwartbaren ROI gibt, wird sich Fine Offset der Investition nicht verschliessen. Zur Zeit ist man auch in China wegen der wirtschaftlich gar nicht so vorteilhaften Situation eher zurückhaltend mit dem Einsatz von Personalressourcen.

Einmal abgesehen davon, dass auch Daten im JSON-Format einem Parsing unterzogen werden müssen, da der Aufbau (Reihenfolge, Benennung etc.) ebenfalls nicht "standardisiert" ist (was wahrscheinlich auch bei der Vielfalt an unterschiedlichen Daten gar nicht möglich ist).

Verfasst: **24 Aug 2025, 11:17**

Da muss ich aber mitschke schon recht geben: MQTT und JSON sind wie Bruder und Schwester. Natürlich kann man in MQTT alles mögliche senden, aber wenn es ein offenes Protokoll sein soll, geht nur JSON. Und das nicht nur bei Wetterstationen.

Verfasst: **24 Aug 2025, 11:18**

mitschke hat geschrieben: 24 Aug 2025, 09:55
Gyvate hat geschrieben: 23 Aug 2025, 20:39 es ist einfach der Datenstring des Ecowitt Protokolls als Payload in die MQTT Posts gepackt.
Warum bzw. warum nicht .... - eigentlich eine eher akademische Frage
Keine akademische Frage, eher eine Frage dessen, was ist "Best Practice".

also in ITIL-Terminologie würde man das eher "Good Practice" nennen.

Gyvate hat geschrieben: 23 Aug 2025, 20:39 Wie die Payload bei MQTT aussieht ist ja dem Publisher/Veröffentlicher überlassen, da gibt es keine Formatvorgaben. Ein bestimmtes Format mag ja dem einen oder anderen genehmer erscheinen, aber eigentlich ist das egal.
Beim Abholen der Daten muss es eben ein Programm geben, das die Payload verarbeiten kann.
Und da ist ein Format wie JSON nicht nur praktisch, sondern auch sehr verbreitet.

wie denn ? Zahlen ?

Gyvate hat geschrieben: 23 Aug 2025, 20:39 M.E. liegt das angebliche Fehlen an der Payloadverarbeitung im HomeAssistant - da passt ein ggf. vorhandenes Verfahren nicht zum Inhalt.

Gyvate hat geschrieben: 23 Aug 2025, 20:39 Nur so als Beispiel - bei der weewx Belchertown Skin (Webseite) werden die Daten auch von weewx via MQTT vom weewx Server an den Host der Skin gesendet - und keinesfalls im JSON Format. Trotzdem hat der Skin-Designer dafür gesorgt, dass die übertragenen Daten (Payload) richtig angezeigt werden.
Sehr gutes Beispiel, nur stimmen wir beide wahrscheinlich nicht darin überein, warum das ein gutes Beispiel ist!

WeeWX MQTT (die am Meisten genutzte Extension, um aus LOOP-Daten MQTT Daten zu erzeugen) codiert die LOOP Daten als JSON.

Und hier ein Snippet aus dem JS-Code von Belchertown, Preisfrage: was erwartet Belchertown als Format der payload?
Code: Alles auswählen
var mqtt_payload = "";
// New message from mqtt, process it
function onMessageArrived(message) {
    belchertown_debug("MQTT: " + message.payloadString);
    update_current_wx(message.payloadString);
    mqtt_payload = jQuery.parseJSON(message.payloadString);
}

da hätte ich wohl genauer hinschauen müssen

Verfasst: **24 Aug 2025, 11:33**

Ich verdiene mein Geld unter anderem damit, IT Systeme miteinander zu vernetzen und wenn ich jedes Mal auf eine Studie warten müsste, die mir mit wissenschaftlicher Methodik am Markt vorbei analysiert, wäre ich kein Nettozahler im Sozialsystem meines Heimatstaats.

Wie auch immer, wer selbst eine anekdotische Evidenz dafür anzuführt (weewx und Belchertown) um zu untermauern, JSON zu verwenden wäre nicht üblich, im Gegenzug aber Studien einzufordert, wenn ihm das eigene Beispiel so spektakulär um die Ohren fliegt, nötigt mir dann doch ein Schmunzeln ab.

Es bleibt die Frage: was haben sie sich dabei gedacht? Es wäre interessant zu wissen. Nur, weil mir dazu noch kein wirklich guter Grund dazu einfällt, heißt das nicht, dass es keinen solchen gibt.

Verfasst: **24 Aug 2025, 11:49**

Hi!

Als moeglicher Ausweg fuer die, die mit der aktuellen MQTT-Implementierung seitens Ecowitt nicht gluecklich sind, kaeme evtl. die MQTT-Loesung von FOSHKplugin in Frage:

Code: Alles auswählen

{
   "PASSKEY":"000102030405060708090A0B0C0D0E0F",
   "stationtype":"GW2000A_V3.2.6",
   "runtime":1024598,
   "dailyboot":0,
   "heap":132564,
   "dateutc":"2025-08-24+09:45:51",
   "loxtime":525267951,
   "tempinc":21.7,
   "humidityin":46,
   "baromrelhpa":1018.18,
   "baromabshpa":1012.09,
   "tempc":17.2,
   "humidity":60,
   "vpd":0.79,
   "winddir":349,
   "winddir_avg10m":56,
   "windspeedkmh":5.76,
   "windgustkmh":7.92,
   "maxdailygustkmh":18.72,
   "solarradiation":626.99,
   "uv":3,
   "rainratemm":0.0,
   "eventrainmm":0.99,
   "hourlyrainmm":0.0,
   "last24hrainmm":1.3,
   "dailyrainmm":0.0,
   "weeklyrainmm":1.3,
   "monthlyrainmm":6.1,
   "yearlyrainmm":203.5,
   "totalrainmm":203.5,
   "rrain_piezomm":0.0,
   "erain_piezomm":3.61,
   "hrain_piezomm":0.0,
   "last24hrain_piezomm":3.61,
   "drain_piezomm":0.61,
   "wrain_piezomm":6.4,
   "mrain_piezomm":30.0,
   "yrain_piezomm":536.7,
   "srain_piezo":0,
   "ws90cap_volt":5.4,
   "ws90_ver":156,
   "temp1c":16.9,
   "humidity1":63,
   "temp2c":23.4,
   "humidity2":43,
   "temp3c":19.1,
   "humidity3":58,
   "temp4c":18.5,
   "humidity4":57,
   "temp5c":17.7,
   "humidity5":62,
   "temp6c":17.6,
   "humidity6":61,
   "temp7c":20.1,
   "humidity7":48,
   "temp8c":15.2,
   "soilmoisture1":35,
   "soilad1":195,
   "soilmoisture2":5,
   "soilad2":82,
   "soilmoisture3":22,
   "soilad3":152,
   "soilmoisture4":21,
   "soilad4":150,
   "soilmoisture5":5,
   "soilad5":90,
   "soilmoisture6":92,
   "soilad6":394,
   "soilmoisture7":20,
   "soilad7":144,
   "soilmoisture8":9,
   "soilad8":69,
   "soilmoisture10":8,
   "soilad10":99,
   "soilmoisture11":23,
   "soilad11":153,
   "pm25_ch1":9.0,
   "pm25_avg_24h_ch1":10.1,
   "tc_co2":23.1,
   "humi_co2":45,
   "pm25_co2":0.9,
   "pm25_24h_co2":2.9,
   "pm10_co2":0.9,
   "pm10_24h_co2":4.0,
   "co2":324,
   "co2_24h":500,
   "lightning_num":0,
   "lightning":34,
   "lightning_time":1755963831,
   "lightning_loxtime":525203031,
   "leak_ch1":0,
   "leak_ch2":0,
   "leak_ch3":0,
   "leak_ch4":0,
   "tf_ch1c":16.2,
   "tf_ch2c":16.4,
   "tf_ch3c":16.4,
   "tf_ch4c":15.4,
   "tf_ch5c":21.5,
   "leafwetness_ch1":0,
   "air_ch1":619,
   "thi_ch1":0,
   "ldsheat_ch1":50,
   "wh65batt":0,
   "wh40batt":1.6,
   "batt1":0,
   "batt2":0,
   "batt3":0,
   "batt4":0,
   "batt5":0,
   "batt6":0,
   "batt7":0,
   "batt8":0,
   "soilbatt1":1.7,
   "soilbatt2":1.5,
   "soilbatt3":1.7,
   "soilbatt4":1.8,
   "soilbatt5":1.6,
   "soilbatt6":1.7,
   "soilbatt7":1.7,
   "soilbatt8":1.7,
   "pm25batt1":3,
   "wh57batt":5,
   "leakbatt1":4,
   "leakbatt2":5,
   "leakbatt3":2,
   "leakbatt4":2,
   "tf_batt1":1.4,
   "tf_batt2":1.4,
   "tf_batt3":1.54,
   "tf_batt4":1.4,
   "tf_batt5":1.36,
   "co2_batt":6,
   "leaf_batt1":1.54,
   "wh90batt":3.28,
   "soilbatt10":1.3,
   "soilbatt11":1.6,
   "ldsbatt1":3.0,
   "freq":"868M",
   "model":"GW2000A",
   "interval":30,
   "isintvl":30,
   "isintvl10":30,
   "dewptc":9.4,
   "windchillc":17.2,
   "feelslikec":17.2,
   "heatindexc":16.6,
   "pm25_AQI_ch1":38,
   "pm25_AQIlvl_ch1":1,
   "pm25_AQI_avg_24h_ch1":42,
   "pm25_AQIlvl_avg_24h_ch1":1,
   "co2lvl":1,
   "pm25_AQI_co2":4,
   "pm25_AQIlvl_co2":1,
   "pm25_AQI_24h_co2":12,
   "pm25_AQIlvl_24h_co2":1,
   "pm10_AQI_co2":1,
   "pm10_AQIlvl_co2":1,
   "pm10_AQI_24h_co2":4,
   "pm10_AQIlvl_24h_co2":1,
   "windspdkmh_avg10m":4.18,
   "windgustkmh_max10m":14.0,
   "windrunkm":31.64,
   "brightness":79439.6,
   "cloudm":1027.0,
   "sunhours":2.46,
   "sunshine":1,
   "srsum":1068.26,
   "osunhours":2.53,
   "nsunhours":2.46,
   "spread":7.8,
   "spreadin":12.1,
   "spread1":7.1,
   "spread2":13.3,
   "spread3":8.4,
   "spread4":8.7,
   "spread5":7.4,
   "spread6":7.6,
   "spread7":11.4,
   "spread_co2":12.6,
   "vpdout":0.78,
   "vpdin":1.4,
   "vpd1":0.71,
   "vpd2":1.64,
   "vpd3":0.93,
   "vpd4":0.91,
   "vpd5":0.77,
   "vpd6":0.78,
   "vpd7":1.22,
   "vpd_co2":1.55,
   "wh90sig":4,
   "wh90rssi":-77,
   "wh69sig":4,
   "wh69rssi":-75,
   "wh40sig":4,
   "wh40rssi":-71,
   "wh57sig":4,
   "wh57rssi":-74,
   "wh45sig":4,
   "wh45rssi":-43,
   "wh41sig1":4,
   "wh41rssi1":-83,
   "wh55sig1":4,
   "wh55rssi1":-63,
   "wh55sig2":4,
   "wh55rssi2":-70,
   "wh55sig3":3,
   "wh55rssi3":-35,
   "wh55sig4":4,
   "wh55rssi4":-41,
   "wh31sig1":4,
   "wh31rssi1":-77,
   "wh31sig2":4,
   "wh31rssi2":-39,
   "wh31sig3":4,
   "wh31rssi3":-68,
   "wh31sig4":4,
   "wh31rssi4":-69,
   "wh31sig5":4,
   "wh31rssi5":-78,
   "wh31sig6":4,
   "wh31rssi6":-68,
   "wh31sig7":4,
   "wh31rssi7":-58,
   "wh31sig8":4,
   "wh31rssi8":-77,
   "wh54sig1":4,
   "wh54rssi1":-44,
   "wh54sig2":"--",
   "wh54rssi2":"--",
   "wh51sig1":4,
   "wh51rssi1":-55,
   "wh51sig2":4,
   "wh51rssi2":-63,
   "wh51sig3":4,
   "wh51rssi3":-83,
   "wh51sig4":4,
   "wh51rssi4":-73,
   "wh51sig5":4,
   "wh51rssi5":-61,
   "wh51sig6":4,
   "wh51rssi6":-82,
   "wh51sig7":4,
   "wh51rssi7":-65,
   "wh51sig8":3,
   "wh51rssi8":-69,
   "wh51sig9":"--",
   "wh51rssi9":-82,
   "wh51sig10":4,
   "wh51rssi10":-66,
   "wh51sig11":4,
   "wh51rssi11":-79,
   "wh34sig1":4,
   "wh34rssi1":-71,
   "wh34sig2":4,
   "wh34rssi2":-64,
   "wh34sig3":4,
   "wh34rssi3":-81,
   "wh34sig4":4,
   "wh34rssi4":-78,
   "wh34sig5":4,
   "wh34rssi5":-58,
   "wh35sig1":4,
   "wh35rssi1":-77,
   "radcompensation":1,
   "newVersion":0,
   "upgrade":0,
   "rainFallPriority":1,
   "rainGain":1.0,
   "rstRainDay":0,
   "rstRainWeek":1,
   "rstRainYear":0,
   "piezo":1,
   "rain1_gain":0.65,
   "rain2_gain":0.8,
   "rain3_gain":0.9,
   "rain4_gain":1.0,
   "rain5_gain":1.0,
   "ptrend1":0,
   "pchange1":0.0,
   "wnowlvl":2,
   "wnowtxt":"wechselhaft",
   "ptrend3":-1,
   "pchange3":-0.1,
   "wproglvl":4,
   "wprogtxt":"gleichbleibend"
}

Ich habe das noch nicht im Kontext vom IOBroker getestet. Unter Home Assistant funktioniert das aber zufriedenstellend.

Oliver

Das Wetterstationen Forum

GW2000 MQTT Problem

GW2000 MQTT Problem

Re: GW2000 MQTT Problem

Re: GW2000 MQTT Problem

Re: GW2000 MQTT Problem

Re: GW2000 MQTT Problem

Re: GW2000 MQTT Problem

Re: GW2000 MQTT Problem

Re: GW2000 MQTT Problem

Re: GW2000 MQTT Problem

Re: GW2000 MQTT Problem