Hi 

 

I am trying to set up MQTT on the Belchertown skin, and just can't get it 
to work, but think I am very nearly there.  Like Philip Kutzenco, I am 
using Digital Ocean to host my MQTT broker, with my own domain name, and 
have followed Pat's guide to set up the MQTT broker with SSL using Let's 
Encrypt.   MQTT all seems to be working, as per Pat's guide.  My weather 
website (ashteadweather.com hosted at 1&1 with SSL certificate) says 
"Connected.  Waiting for data", which sounds promising, but it just stays 
at that message.  I copied the weewx.conf settings format for MQTT and the 
skin.conf format for Belchertown skin, as suggested by Philip Kutzenco, as 
per below:

 

 

 

weewx.conf:

 

 

[[MQTT]]

        server_url = mqtt://xxxx:[email protected]:8883/

        topic = weather

        unit_system = METRIC

        aggregation = aggregate

        binding = archive,loop

        log_success = False

        log_failure = True

        [[tls]]

           tls_version = tlsv1

           ca_certs = /etc/ssl/certs/ca-certificates.crt

 

 

 

Belchertown:

 # MQTT Defaults

    mqtt_enabled = 1

    mqtt_host = mqttdh.uk

    mqtt_port = 9001

    mqtt_ssl = 1

    mqtt_topic = "weather/#"

    disconnect_live_website_visitor = 0

 
Syslog does give any clues as to what is going wrong - no errors reported, 
for example.  Any suggestions from those that have got a similar set up.  I 
must be doing something basic wrong.  For example, do I need to put any 
certificates to follow the line   "ca_certs = 
/etc/ssl/certs/ca-certificates.crt" in weewx.conf?  Or is it something to 
with needing user names and passwords on publishing/subscribing perhaps?

Many Thanks 

David.

On Tuesday, 9 October 2018 12:53:40 UTC+1, G Hammer wrote:
>
> I rarely cut & paste when configuring. 
>
> I too have found that restarting any service doesn’t always produce good 
> results.  I just stop then start things. 
>
> I’ll post my config files later as an example for others. 
>
> I’m just happy to have it running in house at long last. 
>
> The public test.mosquitto.org was not real reliable.  
>
> On Tue, Oct 9, 2018 at 7:45 AM Philip Kutzenco <[email protected] 
> <javascript:>> wrote:
>
>> Mosquitto is fussy, especially about its config files. In Pat's guide, he 
>> mentions that extra spaces at the end of lines messes things up. He says 
>> Mosquitto sometimes needs to be restarted completely. I found that 
>> Mosquitto also requires a newline at the end of config files. If you start 
>> (or restart) Mosquitto and it sees something it doesn't like in a config 
>> file, it immediately exits. Starting Mosquitto again, even if you first fix 
>> any errors in the config files, causes it to fail immediately again. 
>>
>> For me, issuing a stop command first (sudo /etc/init.d/mosquitto stop) 
>> and then starting it (sudo /etc/init.d/mosquitto start) works. My theory  
>> (with no real evidence :-)) is that when Mosquitto exits badly, it leaves 
>> its pid file, or some other flag, in place. When you try to start Mosquitto 
>> again, it sees that the pid file is there and won't start. If you first 
>> issue the stop command, Mosquitto clears the pid (or some other flag) which 
>> allows it to start when issued a start command.
>>
>> I wonder if Mosquitto was unhappy about starting or restarting cleanly 
>> for you because of a leftover artifact, which cleared itself after time? 
>> Just speculation with no evidence.
>>
>> Glad you have it running, at least.
>>
>> phil
>>
>> On Tuesday, October 9, 2018 at 6:27:24 AM UTC-4, G Hammer wrote:
>>>
>>> Well, I have followed Pat's guide and reconfigured my server's mosquitto 
>>> install.
>>> Websockets is a mysterious beast.
>>> This is what I get when I open my weather webpage:
>>> 1539079347: SNI: Unknown ServerName: ftp.ghammer.net
>>> 1539079348: Socket error on client <unknown>, disconnecting.
>>> 1539079348: SNI: Unknown ServerName: ftp.ghammer.net
>>> 1539079368: SNI: Unknown ServerName: ftp.ghammer.net
>>>
>>> However, that is the server's name and the name in the SSL cert.
>>> 1539077963: Initial logging level 5
>>> 1539077963: Libwebsockets version: 2.0.3 unknown-build-hash
>>> 1539077963: IPV6 not compiled in
>>> 1539077963: libev support compiled in but disabled
>>> 1539077963: libuv support compiled in but disabled
>>> 1539077963:  Threads: 1 each 1024 fds
>>> 1539077963:  mem: platform fd map:  8192 bytes
>>> 1539077963:  Compiled with OpenSSL support
>>> 1539077963: Creating Vhost 'default' port 9001, 3 protocols
>>> 1539077963:  Using SSL mode
>>> 1539077963:  SSL ECDH curve 'prime256v1'
>>> 1539077963:  Listening on port 9001
>>> 1539077963:  mem: per-conn:          920 bytes + protocol rx buf
>>> 1539077963:  canonical_hostname = ftp.ghammer.net
>>> 1539077964: lws_protocol_init
>>>
>>> After about 15 minutes, voila!
>>> All is working with zero changes to any config.
>>> Quite puzzled, but not touching a thing.
>>>
>>> On Monday, October 8, 2018 at 5:52:39 PM UTC-4, Philip Kutzenco wrote:
>>>>
>>>> The answer to that question is no. I've attached a file with sanitized 
>>>> excerpts of my weewx.conf file showing the stanzas related to:
>>>>
>>>> 1. MQTT (publishing) - which specifies a username and password but not 
>>>> websocket (port 8883 - SSL not websocket)
>>>> 2. Belchertown Highcharts
>>>> 3. Belchertown (subscribing) - which specifies websockets but no 
>>>> username/password (port 9001 - SSL and websocket)
>>>>
>>>> You'll need to check with Pat, but I expect he saw no reason to lock 
>>>> down the subscriptions with username/password when programming his skin, 
>>>> only locking down the publishing (which is done by MWall's MQTT 
>>>> extension). 
>>>> I think the rationale is you don't care who sees the output (after all, 
>>>> it's being published on an open web site), but you don't want any 
>>>> unauthorized uploading of data which you'll be outputting and displaying 
>>>> to 
>>>> others.
>>>>
>>>> So, if the MQTT broker requires a username/password for subscribing 
>>>> over websockets, I don't know if the skin provides for that. I assume 
>>>> you've tried to prepend <username>:<password>@ to the host name in the 
>>>> Belchertown Extras stanza without success.
>>>>
>>>> Hopefully Pat can weigh in here.
>>>>
>>>> phil
>>>>
>>>>
>>>> On Monday, October 8, 2018 at 4:54:41 PM UTC-4, G Hammer wrote:
>>>>>
>>>>> Do you connect the client (skin) via websockets or any other way using 
>>>>> a username and password?
>>>>>
>>>>> That is the question.
>>>>>
>>>>>  
>>>>>
>>>>> *From:* [email protected] <[email protected]> *On 
>>>>> Behalf Of *Philip Kutzenco
>>>>> *Sent:* Monday, October 8, 2018 3:32 PM
>>>>> *To:* weewx-user <[email protected]>
>>>>> *Subject:* [weewx-user] Re: Belchertown Skin and MQTT With Username 
>>>>> Not Working
>>>>>
>>>>>  
>>>>>
>>>>> I have it working on my own externally hosted Mosquitto server (on 
>>>>> Digital Ocean). My Mosquiutto MQTT broker is set up requiring a username 
>>>>> and password for publishing. Additionally it has TLS/SSL implemented 
>>>>> (with 
>>>>> Let's Encrypt certificates). It allows subscribing anonymously and also 
>>>>> runs Websockets so that it can feedthe Belchertown skin. I used Pat's 
>>>>> MQTT 
>>>>> "tutorial" <https://obrienlabs.net/how-to-setup-your-own-mqtt-broker/> 
>>>>> to do this. My website is https://wx.kutzenco.com.
>>>>>
>>>>>  
>>>>>
>>>>> phil
>>>>>
>>>>>
>>>>> On Monday, October 8, 2018 at 10:21:50 AM UTC-4, G Hammer wrote:
>>>>>
>>>>>  
>>>>>
>>>>> Does anyone have the Belchertown skin working with MQTT using a server 
>>>>> that requires a username and password such as CloudMQTT?
>>>>>
>>>>>  
>>>>>
>>>>> I have tried several different ways of configuring the skin and it 
>>>>> fails to connect or it shows 'Connecting to weather station real time 
>>>>> data' 
>>>>> forever without connecting.
>>>>>
>>>>> The data is being sent to the server fine and I have subscribed to it 
>>>>> using client software (see below).
>>>>>
>>>>>  
>>>>>
>>>>> Thanks for any input, I'm at a loss here.
>>>>>
>>>>>  
>>>>>
>>>>> [image: Image removed by sender. wxmqtt.png]
>>>>>
>>>>>  
>>>>>
>>>>> -- 
>>>>> 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/5Qn_6oZjLP4/unsubscribe.
>>>>> To unsubscribe from this group and all its topics, send an email to 
>>>>> [email protected].
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>> -- 
>> 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/5Qn_6oZjLP4/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> [email protected] <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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].
For more options, visit https://groups.google.com/d/optout.

Reply via email to