On 26 Jul 2025, at 03:24, vince <[email protected]> wrote:
update - looks like the gw1200 doesn't support MQTT. No MQTT
option in the customized servers menus in WSView Plus or in the web
gui directly. Sigh.
On Friday, July 25, 2025 at 4:08:30 PM UTC-7 vince wrote:
James can you share how you set the gateway to post to MQTT ? I
can check the gw1200 for similar settings and try to duplicate
your setup….
On Friday, July 25, 2025 at 3:33:00 PM UTC-7 [email protected]
wrote:
I would have tried ‘type=keyword’ with keyword_deliimter of
‘=‘ (the default) and keyword_separator of ‘&’.
If this didn’t work and I was bored and daring, I would try
writing my own parser,
https://github.com/bellrichm/WeeWX-MQTTSubscribe/wiki/Handling-different-MQTT-message-formats.
But seriously, if the keyword_separator of ‘&’ doesn’t work,
let me know. If Ecowitt has their own MQTT format I might be
interested in baking it into the base MQTTSubscribe code
(guessing that more people will be looking to use it).
rich
On Friday, 25 July 2025 at 16:56:08 UTC-4 James Pattinson wrote:
Hi Vince,
Ah, I get it - I think we are doing two slightly
different things. I think you are subscribing to the
published output of the other WeeWx rather than the
EcoWitt gateway - so your data is already in JSON format.
As shown in my first post. the GW3000 doesn't publish
it's payload in JSON format, it's separated like URL, So
I have a simple script running externally to WeeWx which
converts it from:
PASSKEY=xxx&stationtype=GW3000A_V1.0.9&runtime=20638&heap=68388&dateutc=2025-07-25%2020%3A54%3A42&dns_err_cnt=0&cdnflg=1&tempinf=71.42&humidityin=68&baromrelin=30.129&baromabsin=29.441&tempf=62.06&humidity=90&vpd=0.056&winddir=216&windspeedmph=0.00&windgustmph=0.00&maxdailygust=5.82&solarradiation=0.02&uv=0&rainratein=0.000&eventrainin=0.000&hourlyrainin=0.000&dailyrainin=0.020&weeklyrainin=0.020&monthlyrainin=0.020&yearlyrainin=0.020&wh65batt=0&freq=868M&model=GW3000A&interval=60
to
{"PASSKEY": "xxx", "stationtype": "GW3000A_V1.0.9",
"runtime": "20646", "heap": "68388", "dateutc":
"2025-07-25 20:54:50", "dns_err_cnt": "0", "cdnflg":
"1", "tempinf": "71.42", "humidityin": "68",
"baromrelin": "30.129", "baromabsin": "29.441", "tempf":
"62.06", "humidity": "90", "vpd": "0.056", "winddir":
"216", "windspeedmph": "0.00", "windgustmph": "0.00",
"maxdailygust": "5.82", "solarradiation": "0.02", "uv":
"0", "rainratein": "0.000", "eventrainin": "0.000",
"hourlyrainin": "0.000", "dailyrainin": "0.020",
"weeklyrainin": "0.020", "monthlyrainin": "0.020",
"yearlyrainin": "0.020", "wh65batt": "0", "freq":
"868M", "model": "GW3000A", "interval": "60"}
Then MQTTSubscribe is happy :)
Cheers
James
On Friday, 25 July 2025 at 21:39:41 UTC+1 vince wrote:
Nope - just use MQTTSubscribe when I want to listen,
and MQTT when I want to publish. Apply a sensor_map
on the subscribe side to map the elements you want
into the weewx db as desired.
Here's some excerpts from my vp2 (main) instance
that subscribes to a few things from ecowitt/loop
# dial back some logging a bit for when we set debug=1
[Logging]
[[loggers]]
[[[user.MQTTSubscribe]]]
level = INFO
[MQTTSubscribeService]
enable = true
host = 192.168.1.171
port = 1883
keepalive = 60
username = None
password = None
binding = loop
[[message_callback]]
type = json
[[topics]]
unit_system = US
ignore_start_time = True
ignore_end_time = True
#----- example data ----
# {"dateTime": 1703364600.0, "usUnits":
1.0, "inTemp_F": 64.03999999999998, "outTemp_F":
40.01600000000001, "inHumidity": 51.0,
"outHumidity": 99.0, "pressure_inHg": 29.9502976554
16673, "relbarometer": 1025.7333333333336,
"extraTemp1_F": 67.46000000000002, "extraTemp2_F":
70.34000000000002, "extraTemp3_F":
70.87999999999998, "extraTemp4_F": 70.112,
"extraTemp5_F": 50.
888000000000005, "extraHumid1": 46.53333333333333,
"extraHumid2": 40.0, "extraHumid3": 43.0,
"extraHumid4": 46.0, "extraHumid5":
88.33333333333333, "soilMoist1_centibar": 40.0,
"wh32_batt": 0
.0, "wh31_ch1_batt": 0.0, "wh31_ch2_batt": 0.0,
"wh31_ch3_batt": 0.0, "wh31_ch4_batt": 0.0,
"wh31_ch5_batt": 0.0, "wh51_ch1_batt": 1.5,
"wh32_sig": 4.0, "wh31_ch1_sig": 4.0, "wh31_ch2_sig": 4
.0, "wh31_ch3_sig": 4.0, "wh31_ch4_sig": 4.0,
"wh31_ch5_sig": 4.0, "wh51_ch1_sig": 4.0,
"altimeter_inHg": 30.35012374517868,
"barometer_inHg": 30.363289630598434,
"cloudbase_foot": 423.695175
8301455, "dewpoint_F": 39.75774122634734,
"heatindex_F": 39.14293333333334, "humidex_F":
40.01600000000001, "inDewpoint_F":
45.54133535588047, "maxSolarRad_Wpm2":
228.29873036475112, "rainRat
e_inch_per_hour": 0.0, "interval_minute": 5.0}
# we subscribe to ecowitt/loop from a second
weewx instance for that
[[[ecowitt/loop]]]
# items we map to weewx schema elements
[[[[outTemp_F]]]]
name = extraTemp1
units = degree_F
[[[[extraTemp5_F]]]]
name = extraTemp5
units = degree_F
# the rest of the items we ignore,
uncertain if this is needed or not
# if so - I likely missed ignoring some elements
plus/minus which sensors
# we've added or deleted from the initial setup
[[[[dateTime]]]]
ignore = True
[[[[usUnits]]]]
ignore = True
[[[[inTemp_F]]]]
ignore = True
[[[[inHumidity]]]]
ignore = True
[[[[outHumidity]]]]
ignore = True
[[[[pressure_inHg]]]]
ignore = True
[[[[relbarometer]]]]
ignore = True
[[[[extraTemp1_F]]]]
ignore = True
[[[[extraTemp2_F]]]]
ignore = True
[[[[extraTemp3_F]]]]
ignore = True
[[[[extraTemp4_F]]]]
ignore = True
[[[[extraHumid1]]]]
ignore = True
[[[[extraHumid2]]]]
ignore = True
[[[[extraHumid3]]]]
ignore = True
[[[[extraHumid4]]]]
ignore = True
[[[[soilMoist1_centibar]]]]
ignore = True
[[[[wh26_sig]]]]
ignore = True
[[[[wh65_sig]]]]
ignore = True
[[[[wh31_ch1_sig]]]]
ignore = True
[[[[wh31_ch2_sig]]]]
ignore = True
[[[[wh31_ch3_sig]]]]
ignore = True
[[[[wh31_ch4_sig]]]]
ignore = True
[[[[wh31_ch5_sig]]]]
ignore = True
[[[[wh51_ch1_sig]]]]
ignore = True
[[[[altimeter_inHg]]]]
ignore = True
[[[[barometer_inHg]]]]
ignore = True
[[[[cloudbase_foot]]]]
ignore = True
[[[[dewpoint_F]]]]
ignore = True
[[[[heatindex_F]]]]
ignore = True
[[[[humidex_F]]]]
ignore = True
[[[[inDewpoint_F]]]]
ignore = True
[[[[maxSolarRad_Wpm2]]]]
ignore = True
[[[[rainRate_inch_per_hour]]]]
ignore = True
[[[[interval_minute]]]]
ignore = True
On Friday, July 25, 2025 at 1:15:15 PM UTC-7 James
Pattinson wrote:
Hi Vince,
Did you have to do any customisation at all? I
am using MQTTSubscribe and it is now working,
but I had to write an external python script to
subscribe to the Ecowitt topic, parse the
payload and re-publish it in JSON format to
another topic, which WeeWx then subscribes to.
Before I did that it was trying to convert the
whole string (including &s) to a value, even in
'individual' mode.
Cheers
James
On Friday, 25 July 2025 at 17:07:21 UTC+1 vince
wrote:
Yes. You still will need the ecowitt gateway
to publish to a MQTT broker in the middle.
I just run a little docker container on my
LAN for that.
In my case I have two weewx instances that
both publish to MQTT as ecowitt/loop and
vp2/loop (via Matthew's MQTT extension, to
later feed influxdb), but the VP2 weewx
instance subscribes to the ecowitt data (via
Rich's MQTTSubscribe as a service) to add
data to a few extraTempNNN elements so that
I can show data from both in my main skin.
Rich's MQTTSubscribe works great. I didn't
know until now that it can be run as a
driver. Very cool.
On Friday, July 25, 2025 at 7:17:20 AM UTC-7
Steeple Ian wrote:
@Michael
I have not looked at MQTT in any depth
before so forgive me if my question is
naive. Using WeeWX-MQTTSubcribe with the
Ecowitt MQTT protocol, is there still a
requirement for a-man-in-the middle server?
Thanks,
Ian
On Friday, July 25, 2025 at 2:33:52 PM
UTC+1 [email protected] wrote:
Take a look into
https://github.com/bellrichm/WeeWX-MQTTSubscribe
James Pattinson schrieb am Freitag,
25. Juli 2025 um 13:57:21 UTC+2:
Hi All!
I am setting up a WeeWx system
in a remote location where they
do have WiFi but nowhere to
actually install the software.
Since I have WeeWx running
elsewhere, I'd like to be able
to feed into a new instance of
WeeWx under my control.
I am used to using Davis stuff,
but as these guys are on a
budget, we went for EcoWitt. We
have a WS69 with LCD display,
and a GW3000.
This is my first time using a
GW3000, and I was quite happy to
see that it supports MQTT so it
can push data out in almost real
time (down to 8 seconds). I have
this working and I can see the
updates coming into my MQTT
server, albeit in a weird HTTP
POST style:
PASSKEY=xxx&stationtype=GW3000A_V1.0.9&runtime=1124&heap=68736&dateutc=2025-07-25%2011%3A50%3A12&dns_err_cnt=0&cdnflg=1&tempinf=74.12&humidityin=56&baromrelin=29.483&baromabsin=29.483&tempf=72.86&humidity=55&vpd=0.367&winddir=294&windspeedmph=0.00&windgustmph=0.00&maxdailygust=0.00&solarradiation=4.96&uv=0&rainratein=0.000&eventrainin=0.000&hourlyrainin=0.000&dailyrainin=0.000&weeklyrainin=0.000&monthlyrainin=0.000&yearlyrainin=0.000&wh65batt=0&freq=868M&model=GW3000A&interval=60
If there was a way of having
this MQTT message feed directly
into the LOOP of WeeWx, it would
make my life SO much easier, as
I can have the GW3000 publish
this out to an external MQTT
server and connect WeeWx to the
same server. Has anyone got a
WeeWx driver to do this?
Without this, I think I am
looking at the GW1000 API
polling driver, which appears to
have become unmaintained quite
recently. For that to work I'd
need to arrange things such that
WeeWx can connect to the GW3000
over the Internet, which might
be challenging without a VPN.
Plan B is to tell them they need
to buy a Pi or something and do
it all locally, but I would
really like to be able to get
some semi real-time push method
doing for this use case.
Any other ideas would be
appreciated!
Cheers
James
--
You received this message because you are subscribed to the Google
Groups "weewx-user" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/weewx-user/a78a4fbf-706f-4e1c-bc0e-81bc76047dd1n%40googlegroups.com
<https://groups.google.com/d/msgid/weewx-user/a78a4fbf-706f-4e1c-bc0e-81bc76047dd1n%40googlegroups.com?utm_medium=email&utm_source=footer>.
