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 <kutze...@gmail.com> 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:* weewx...@googlegroups.com <weewx...@googlegroups.com> *On >>>> Behalf Of *Philip Kutzenco >>>> *Sent:* Monday, October 8, 2018 3:32 PM >>>> *To:* weewx-user <weewx...@googlegroups.com> >>>> *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 >>>> weewx-user+...@googlegroups.com. >>>> 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 > weewx-user+unsubscr...@googlegroups.com. > 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 weewx-user+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
