You'll also need to supply the username and password to "receive" the MQTT data (in skin.conf or Belchertown) but that is not yet supported as far as I know.
Colin On Fri, 12 Oct 2018, 07:59 , <[email protected]> wrote: > 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]> 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]. >>> 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. > -- 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.
