Connected. Waiting for data. Belchertown

[Peter Schmelitschek]

I apologise to the Gurus who will sigh 'not this again!"

I have been working on getting WeeWx to work with Belchertown for several weeks and admit defeat. My head is spinning from days going in circles with ChatGPT on multiple related issues (TLS, MQTT over TCP yada yada).

Summary of my setup that I feel is relevant:

Local DNS record on Pi-Hole (with unbound) points broker (mqtt.dreamwoodestate.net) to the Traefik IP.

Mikrotik router has dst-nat pointing 8883 and 9011 to those ports on the Traefik VM.

There are also Input rules to allow those ports.

Cloudflare has a proxied A record for the broker, pointing to my static IP which resolves to my HomeLab domain (dreamwoodestate.net)

Traefik (in own VM) supplies Letsencrypt certificate for use by browser wanting to securely access my website with Belchertown.

MQTT broker (Mosquitto 2.0.18) is running on its own VM also.

WeeWx also has its own VM.

So far, MQTT Explorer on my LM PC can see the broker, SSYS, broker - and all the groups below broker.

WeeWx appears to be outputting MQTT data, with rows like:

DEBUG user.mqtt: data: {'dateTime': '1754316352.0', 'barometer_mbar'....

INFO weewx.restx: MQTT: Published record 2025-08-05 00:05:52 AEST (1754316352)

However, MQTT Explorer is not displaying any 'weather' messages from the WeeWx MQTT client (I think this is the way to describe it).

It is subscribed to topic=weather/loop

BTW, I have chosen port '9011' for websockets as Portainer Agent is using '9001' traditionally used around WeeWx/MQTT

weexw.log is empty - don't know if that is good or bad

Browsing to my weather data is 'working' in all respects except for the MQTT driven 2 second updates (and that strange appearance of 'current temp' at the top of graphs and reports - minor problem I'm sure).

Using '?debug=true' in browser shows 'MQTT: MQTT Connected. Subscribing.' as the last entry.

Hopefully there are sufficient clues and suitable obfuscation in the attached.

Please let me know what other info I can provide. 

[jterr...@gmail.com]

Hello,

I see one minor problem : in your weewx.conf file, the MQTT topic used by weewx to publish its data should be weather and not weather/loop :

[[MQTT]] 

   server_url = mqtts://user:pass...@mqtt.dreamwoodestate.net:8883/ 

    topic = weather

The loop subtopic will be automatically created by the mqtt extension.

Also check your mosquitto acl file to be sure that the mqtt user configured in weewx.conf is allowed to publish data on the weather topic :

user XXXXX
 topic readwrite weather/#

Finally,  some other users had similar problems because they were using a weewx MQTT extension that was not creating the loop subtopic needed by the Belchertown skin. . The extension to be used with Belchertown is this one : https://github.com/matthewwall/weewx-mqtt/tree/master

[Peter Schmelitschek]

Thank you so much for taking the time to look through the files and your suggestions.

I have modified the [[MQTT]] stanza in [StdRESTful] - I understood that the Belchertown 'mqtt_websockets_topic' should match the StdRESTful entry - is that correct?

I have been keeping them the same in my attempts so far, but I'll try both options.

Now to check out the ACL file and MQTT Explorer as well - presumably MQTT Explorer should be looking for 'weather/#' like the ACL file?

I did use the Mathew Wall MQTT extension - presumably he only has one version, and I haven't missed another one?

[Jacques Terrettaz]

II understood that the Belchertown 'mqtt_websockets_topic' should match the StdRESTful entry - is that correct?

No, it is not correct.    Should be "weather" in the StdRESTful entry and "weather/loop" in Belchertown 'mqtt_websockets_topic''

Now to check out the ACL file and MQTT Explorer as well - presumably MQTT Explorer should be looking for 'weather/#' like the ACL file?

Concerning the configuration of mosqitto, could you please show the content of the .conf file located in /etc/mosquitto/conf.d ?  This will help to understand if and how acl is configured for your broker

Concerning mqtt exolorer settings, you can simply look at "#', so that anything received and accepted  by the broker will be shown.

I did use the Mathew Wall MQTT extension - presumably he only has one version, and I haven't missed another one?

OK, it is the one to use.

--
You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/Gq6uNw_Cxss/unsubscribe.
To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/953199b0-3fa1-4739-95a2-882fa0e27707n%40googlegroups.com.

[Peter Schmelitschek]

I have recreated both ACL and myconfig.conf files from scratch using NANO because Mosquitto complains of unexpected character at the start of files.

However, with that done, I still get this at Mosquitto restart:

Loading config file /etc/mosquitto/conf.d/myconfig.conf

Error: Unknown configuration variable "#"

Error found at /etc/mosquitto/conf.d/myconfig.conf:1

Error found at /etc/mosquitto/mosquitto.conf:18

This is possibly the root cause of my MQTT problems - I have been commenting out the ACL file previously to get WeeWx to appear at this stage.

Right now I'm seeing "Failed connecting to the weather station"

On Tuesday, 5 August 2025 at 16:50:32 UTC+10 jterr...@gmail.com wrote:

[Jacques Terrettaz]

You have possibly a comment line (starting with "#") in the first line of  myconfig.conf.  Try to remove it and any other comment line.

Here is for exemple the content of my own myconfig.conf file :

listener 1883

listener 8083

protocol websockets

allow_anonymous false

password_file /etc/mosquitto/passwd

acl_file /etc/mosquitto/acl

[Peter Schmelitschek]

This is my 'myconfig.conf' - based on Pat O'Brien's example.

I'll try it with the comments removed.

[Peter Schmelitschek]

myconfig.conf:

persistence false

allow_anonymous false
password_file /etc/mosquitto/passwd
acl_file /etc/mosquitto/acl

# Insecure mqtt to localhost and secure mwtt
listener 1883
listener 8883
cafile /etc/letsencrypt/live/mqtt.dreamwoodestate.net/chain.pem
certfile /etc/letsencrypt/live/mqtt.dreamwoodestate.net/cert.pem
keyfile /etc/letsencrypt/live/mqtt.dreamwoodestate.net/privkey.pem
protocol mqtt

# websockets
listener 9011
protocol websockets

[Peter Schmelitschek]

Mosquitto appears to be starting Ok now:

Aug 05 11:29:23 mosquitto-t7820 systemd[1]: Stopping mosquitto.service - Mosquitto MQTT Broker...
Aug 05 11:29:24 mosquitto-t7820 mosquitto[9334]: 1754393364: mosquitto version 2.0.18 terminating
Aug 05 11:29:24 mosquitto-t7820 systemd[1]: mosquitto.service: Deactivated successfully.
Aug 05 11:29:24 mosquitto-t7820 systemd[1]: Stopped mosquitto.service - Mosquitto MQTT Broker.
Aug 05 11:29:24 mosquitto-t7820 systemd[1]: Starting mosquitto.service - Mosquitto MQTT Broker...
Aug 05 11:29:24 mosquitto-t7820 mosquitto[9386]: 1754393364: Loading config file /etc/mosquitto/conf.d/myconfig.conf
Aug 05 11:29:24 mosquitto-t7820 mosquitto[9386]: 1754393364: mosquitto version 2.0.18 starting
Aug 05 11:29:24 mosquitto-t7820 mosquitto[9386]: 1754393364: Config loaded from /etc/mosquitto/mosquitto.conf.
Aug 05 11:29:24 mosquitto-t7820 mosquitto[9386]: 1754393364: Opening ipv4 listen socket on port 1883.
Aug 05 11:29:24 mosquitto-t7820 mosquitto[9386]: 1754393364: Opening ipv6 listen socket on port 1883.
Aug 05 11:29:24 mosquitto-t7820 mosquitto[9386]: 1754393364: Opening ipv4 listen socket on port 8883.
Aug 05 11:29:24 mosquitto-t7820 mosquitto[9386]: 1754393364: Opening ipv6 listen socket on port 8883.
Aug 05 11:29:24 mosquitto-t7820 mosquitto[9386]: 1754393364: Opening websockets listen socket on port 9011.
Aug 05 11:29:24 mosquitto-t7820 mosquitto[9386]: 1754393364: mosquitto version 2.0.18 running

I don't understand why MQTT broker only shows 'itself' (mqtt.dreamwoodestate.net) but no clients below.

Also, with ?debug=true on my browser, the last line now shows 'MQTT: 2025-08-05T21:27:36+10:00: Cannot connect to MQTT broker'

On Tuesday, 5 August 2025 at 18:37:56 UTC+10 Jacques Terrettaz wrote:

[Peter Schmelitschek]

Replies are getting out of order.

myconfig.conf - running without comments:

persistence false

allow_anonymous false
password_file /etc/mosquitto/passwd
acl_file /etc/mosquitto/acl

listener 1883
listener 8883
cafile /etc/letsencrypt/live/mqtt.dreamwoodestate.net/chain.pem
certfile /etc/letsencrypt/live/mqtt.dreamwoodestate.net/cert.pem
keyfile /etc/letsencrypt/live/mqtt.dreamwoodestate.net/privkey.pem
protocol mqtt

listener 9011
protocol websockets

On Tuesday, 5 August 2025 at 18:37:56 UTC+10 Jacques Terrettaz wrote:

[Peter Schmelitschek]

This seems to be the issue (from using ?debug=true in browser):

MQTT: Connecting to MQTT Websockets: mqtt.dreamwoodestate.net 9011 (SSL Enabled)
belchertown.js?1754396118:1579 MQTT: 2025-08-05T22:19:59+10:00: Cannot connect to MQTT broker

[Peter Schmelitschek]

Any ideas on solving this issue (from the browser's explorer)?

paho-mqtt.min.js:37 Mixed Content: The page at 'https://dreamwoodinternational.com/weewx/belchertown/?debug=true' was loaded over HTTPS, but attempted to connect to the insecure WebSocket endpoint 'ws://mqtt.dreamwoodestate.net:9011/mqtt'. This request has been blocked; this endpoint must be available over WSS.
(anonymous) @ paho-mqtt.min.js:37

[Jacques Terrettaz]

Your belchertown.js file (https://dreamwoodinternational.com/weewx/belchertown/js/belchertown.js) is explicitly trying  to connect to the MQTT broker with SSL disabled.

See it in line 1523 of belchertown.js :

            belchertown_debug("MQTT: Connecting to MQTT Websockets: mqtt.dreamwoodestate.net 9011 (SSL Disabled)");

        var useSSL = false;

        client = new Paho.Client("mqtt.dreamwoodestate.net", 9011, mqttclient);

So double check that you have not conflicting configuration in the Belchertown configuration about the use of SSL with MQTT, and verify that the https://dreamwoodinternational.com/weewx/belchertown/js/belchertown.js file is synchronized with the one generated by the skin in your weewx VM. The belchertown skin is updating the js file every time a new data record has been received by weewx.

-- 
You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/Gq6uNw_Cxss/unsubscribe.
To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/weewx-user/8e9656f2-23b7-47ec-8b1d-cbfe1083ae39n%40googlegroups.com.

[Peter Schmelitschek]

With mqtt_websockets_ssl = 1 in the [[[Extras]]] of [[Belchertown]] in weewx.conf, I get 'Failed connecting to the weather station' from the browser using https.
I can see the belchertown.js has updated as you pointed out, so now it's:

belchertown_debug("MQTT: Connecting to MQTT Websockets: mqtt.dreamwoodestate.net 9011 (SSL Enabled)");
        var useSSL = true;

        client = new Paho.Client("mqtt.dreamwoodestate.net", 9011, mqttclient);

BTW, ChatGPT told me last week that I should add a "/" in between the 9011 and mqttclient in the client = line.

I removed that "/" earlier tonight thinking the advice was wrong - but it dowsn't seem to improve the situation either way.

Right now the browser shows this error from F12:

paho-mqtt.min.js:37 WebSocket connection to 'wss://mqtt.dreamwoodestate.net:9011/mqtt' failed:
d._doConnect @ paho-mqtt.min.js:37

[Peter Schmelitschek]

After a refresh, the error becomes:

paho-mqtt.min.js:37 WebSocket connection to 'wss://mqtt.dreamwoodestate.net:9011/mqtt' failed:
d._doConnect @ paho-mqtt.min.js:37

d.connect @ paho-mqtt.min.js:31
Client.connect @ paho-mqtt.min.js:70
connect @ belchertown.js?1754408117:1543
(anonymous) @ belchertown/:171
l @ jquery.min.js:2
c @ jquery.min.js:2

[Peter Schmelitschek]

Having a look at my Traefik fileConfig.yaml (dynamic), what I've ended up with from ChatGPT looks dodgy:

In http Routers, there are these 2 entries:

 mqtt-router:
      entryPoints:
        - mqtt-ws
      rule: "Host(`mqtt.dreamwoodestate.net`)"
      service: mqtt-ws-svc
      tls: true

    mqtt_ws:
      rule: "Host(`mqtt.dreamwoodestate.net`)"
      entryPoints:
        - mqtt-ws
      tls:
        certResolver: cloudflare
      service: mqtt_ws_service 

Then in Services:

 mqtt-broker:
      loadBalancer:
        servers:
          - url: "http://192.168.88.67:9011"

    mqtt-ws-svc:
      loadBalancer:
        servers:
          - url: "http://192.168.88.67:9011"

Which do you suggest should be removed as there is clearly duplication wrt port 9011 for websockets.

[Jacques Terrettaz]

Sorry,  I don't know anything about Traefik and its configuration.

To view this discussion visit https://groups.google.com/d/msgid/weewx-user/e14a0b63-8d35-41d4-a0f7-4ccda3b15074n%40googlegroups.com.

[Peter Schmelitschek]

Ok thanks anyway.

I'll try some combinations later - now 02:00 here

[vince]

Your setup is very complicated - Traefik, Cloudflare, Portainer, etc. etc. etc. plus trying to get weewx/mosquitto working to begin with.

FWIW, my working  LAN only setup is at https://github.com/vinceskahan/weewx-odds-and-ends/blob/master/weewx-belchertown-websockets.txt if you want to take a look at settings that used to work here.  I'm LAN-only, no proxies, ssl disabled, user/pass disabled so it's the simplest setup that should work LAN-only.

My hazy recollection is that you also need to be consistent between http/https, and ssl enabled/disabled, but with all the complicated things you're trying to align, wow.....

I would suggest you start over, step by step, doing one thing at a time as you build up the complexity....

• get everything working LAN-only 'without' SSL
• then get it working LAN-only with SSL
• then get it working proxied without SSL
• then lastly get it working proxied with SSL
  

or....

• LAN-only without SSL
  
• proxied without SSL
  
• proxied with SSL
  

Or the like.  Tiny steps.  Minimize moving parts.  Build up to the (to me) messy setup you're trying to build.

[Peter Schmelitschek]

Thanks Vince.

Good idea.

[Mark Fraser]

Vince,

I've just started following this thread as I'm also having MQTT issues.

My old installation of Weewx 4.10.2 on Buster is running OK and MQTT is working. I've had to create a new installation on a different Pi running Bookworm and Weewx 5.1.0 as the USB stick is failing and going through the same process that worked previously isn't working.

All I get when running

mosquitto_sub -d -t weather/# -h 192.168.2.108
on a different device is:

Client mosqsub|15572-weather sending CONNECT
Client mosqsub|15572-weather received CONNACK (0)
Client mosqsub|15572-weather sending SUBSCRIBE (Mid: 1, Topic: weather/#, QoS: 0)
Client mosqsub|15572-weather received SUBACK
Subscribed (mid: 1): 0
Client mosqsub|15572-weather sending PINGREQ
Client mosqsub|15572-weather received PINGRESP
Client mosqsub|15572-weather sending PINGREQ
Client mosqsub|15572-weather received PINGRESP
Client mosqsub|15572-weather sending PINGREQ
Client mosqsub|15572-weather received PINGRESP
Client mosqsub|15572-weather sending PINGREQ
Client mosqsub|15572-weather received PINGRESP
Client mosqsub|15572-weather sending PINGREQ
Client mosqsub|15572-weather received PINGRESP
Client mosqsub|15572-weather sending PINGREQ
Client mosqsub|15572-weather received PINGRESP
Client mosqsub|15572-weather sending PINGREQ
Client mosqsub|15572-weather received PINGRESP

In the message below the URL doesn't work, have you renamed your github repo?

https://github.com/vinceskahan/weewx/blob/main/weewx-odds-and-ends/weewx-belchertown-websockets.txt

[vince]

Yep I reoroganized everything into categories. Just start at my name and you will see a pinned repo called weewx. It’s in the list of stuff in there

[Mark Fraser]

I managed to fix my issue and was it my own mistake. I'd commented out the restful_services line trying to fix something else which of course meant that user.mqtt.MQTT would never run!