David, You don't need to specify a username/password to receive data if you have sett up your broker as Pat detailed in his post <https://obrienlabs.net/how-to-setup-your-own-mqtt-broker/>. The weewx.conf stanzas in the file I attached in my earlier post are working fine at https://wx.kutzenco.com. One minor change is that I changed the subscription to "weather/loop" instead of "weather/#". It works with #, but I think best practice is to only subscribe to loop.
Here are some things to look at: 1. Did you set up a password for Mosquitto? It is done as follows: *sudo mosquitto_passwd -c /etc/mosquitto/passwd <your username>* Note that the username is just for Mosquitto. It doesn't need to be a linux account name. 1. Did you set up an acl file (*/etc/mosquitto/acl)*? It should contain: *# Allow anonymous access to the systopic read $SYS/# # Allow anonymous to read weathertopic read weather/#* *# weewx readwrite to the loopuser <your username from above>topic weather/#* 2. Does your Mosquitto myconfig.conf (*/etc/mosquitto/conf.d/myconfig.conf) *file contain the following? It should have: *persistence falseallow_anonymous truepassword_file /etc/mosquitto/passwdacl_file /etc/mosquitto/acllistener 1883protocol mqtt* *# websocketslistener 9001protocol websocket * I am far from an expert on this, but if you post copies of those files. I will look at them in addition to the weewx.conf stanzas you already published, ans see if I can spot a reason for it not working for you. (I probably won't get a chance to look until tomorrow). phil On Thursday, October 11, 2018 at 5:13:23 PM UTC-4, Colin Larsen wrote: > > 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] <javascript:>> 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] <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.
