[weewx-user] Re: weewx-opensprinkler weather skin

[tomnykds]

>
> So, I was able to port the OpenSprinkler weather server to python as a cgi 
> script.  It isn't ready for public consumption, but does cover most of the 
> capabilities of the original.  It queries Open Weather Map and Dark Sky 
> using my private keys for each, as well as pulling in a weewx generated web 
> page with the last 2 days rain, so that part would have to be figured out.  
> It does require a local web server at this point.  I wasn't able to (didn't 
> try too hard) to get a python web server to simply serve the cgi results 
> internally verses running the same code via cgi mechanisms.  The scale from 
> the two sources are averaged for now.  If anyone is interested I can 
> package in some form or another.
>

Chris 

-- 
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.

[weewx-user] Re: weewx-opensprinkler weather skin

[gjr80]

I meant to reply a while back but was sidetracked.

I have looked into using data from the Australian Bureau of Meteorology in 
the past and have decided not to due to some (seemingly) fairly tight 
copyright controls/conditions on their publicly accessible products. Refer 
to their copyright page . The 
BoM's default terms of use permit personal use but do not permit 
distribution. They do have provision for Creative Commons and Public Access 
Licenced data but I am yet to find too much data of interest that includes 
the CC or PAL. I am no copyright lawyer nor have I contacted BoM but given 
the apparent restrictions on their products I have steered clear of their 
use on my site.

Gary

On Thursday, 4 October 2018 07:55:56 UTC+10, mwall wrote:
>
> On Wednesday, October 3, 2018 at 5:45:55 PM UTC-4, Peter Hardy wrote:
>>
>> There could also be some value in trying to bring BoM support in to 
>> weewx-forecast. I'm not going to commit to that until I've actually done it 
>> though. ;)
>>
>
> i am happy to add other forecasting services to the weewx-forecast 
> extension.  my only requirement is that they provide a free service.
>
> it is pretty interesting to compare the various forecasting services.  and 
> comparing forecasts from a single service over time is also informative. 
>  for example, here is a sample set of wind, temperature, and precipitation 
> forecast comparisons between weather underground and us national weather 
> service, between different forecasts from nws over time, and between 
> different forecasts from wu over time:
>
> http://sailing.mit.edu/weather/forecast.html
>
> of course, if your local weather tends to be sunny all the time then its 
> not quite so much fun :)
>
> m
>

-- 
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.

Re: [weewx-user] XML Data Import

[gjr80]

Hi Bastian,

Sorry this has taken longer than I planned, a few issues I had to solve 
plus I wanted to have some basic documentation done before release.

You will find my XML file parse driver on GitHub here 
. The readme has basic install 
instructions, there is more detail in the wiki 
. Key in getting the driver 
to work are properly defining the sensor maps that define what XML elements 
are mapped to what WeeWX fields. There are also maps required to define 
what units are used in the various XML elements. The sensor maps basically 
use an XPath specification, this is a little more complex than I would have 
liked but unfortunately necessary to keep the driver generic enough to 
handle almost and XML structure. I have tried to explain XPath specs (well 
all you need to know to use the driver) in the wiki User's Guide 
.

If you do use the driver and have any questions/issues please do not 
hesitate to email me or post her.

Gary

On Friday, 28 September 2018 05:32:26 UTC+10, wett...@gmail.com wrote:
>
> Hello Gary,
> the XML file are supplied from a Hardware controller. The Controller and 
> the Weewx Server are in the same local Network.
>
> Best Regards
> Bastian
>
>
> On Thursday, September 27, 2018 at 3:22:11 PM UTC+2, gjr80 wrote:
>>
>> Bastian,
>>
>> Just out of interest how will the machine running WeeWX access the xml 
>> file? Will it be as via the normal filesystem or share or over a 
>> network/internet to a web server or similar?
>>
>> Gary
>>
>> On Thursday, 27 September 2018 03:21:28 UTC+10, wett...@gmail.com wrote:
>>>
>>> Dear Gary,
>>> o yes i still looking for a XML driver.
>>> This are very good news!
>>>
>>> Many Thanks!
>>> Bastian
>>>
>>>
>>>
>>> On Monday, September 24, 2018 at 4:54:25 AM UTC+2, gjr80 wrote:

 Hi,

 If you are still looking for an XML driver let me know. I have put 
 together a WeeWX driver that should do what you want. Still testing it but 
 it is almost ready for someone else to test it further.

 Gary

 On Tuesday, 4 September 2018 02:52:23 UTC+10, wett...@gmail.com wrote:
>
> Dear Liz,
> the current issue is the import of the "realtime" XML data to Weewx.
> The Hardware Controller from Weatherstation  does provide all Sensor 
> data as XML File via Ethernet.
>
> This means i "need" a driver for data import. Function: Weewx does 
> read the XML File 1/min.
> "That's all"
> I do not have found any solution about this.
>
> For better imagination i have attached the Controller XML File
>
> Can anybody send me a sample how can i do that?
>
> Many Thanks!
>
> On Sunday, September 2, 2018 at 6:14:15 AM UTC+2, Liz wrote:
>>
>> On Wed, 29 Aug 2018 10:59:22 -0700 (PDT) 
>> wett...@gmail.com wrote: 
>>
>> > Hello Thomas, 
>> > many thanks for your message. 
>> > 
>> > Yes, i will import the XML file of a piece of Hardware but 
>> "watch"is 
>> > not required . The import in a fix intervall (1x per Min) is 
>> perfect. 
>> > I am not a Py Guy and a litte bit helpless how can i sove the XML 
>> > import. 
>> > 
>> > Can anybody help me? 
>> > 
>> > Thanks! 
>>
>>
>> I am not able to understand what you are trying to do, and so cannot 
>> even think about what you want to do, and how to help. 
>>
>> Can you write out a more complete explanation of your situation, and 
>> where you are stuck? 
>>
>> Liz 
>>
>

-- 
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.

[weewx-user] Re: WMR300 - intermittent and partial loss of loop data

[Ruben Navarro Huedo]

Hello Cameron:

I tried disconnecting and connecting again with no effect... the only 
solution was reboot the raspberry.
Now i am using a rasp zero w and i have only one usb port.
I am using last stable raspbian kernel: Linux meteo 4.14.70+ #1144 Tue Sep 
18 17:20:50 BST 2018 armv6l GNU/Linux

If it stops receiving again i will try with 4.4... kernel.

Thank's 

El martes, 9 de octubre de 2018, 14:33:06 (UTC+2), Cameron D escribió:
>
> OK, this is not the symptom that this thread applies to - it might be more 
> relevant to the hanging thread - I'll explain why at the end.
>
> The logs are demonstrating total loss of data - this is similar to the 
> previous problem, where the data stops, and my driver update detects this 
> and resends the initialisation command.
> Where this is different is the restart command seems to have no effect. 
> The wmr300 console resolutely stops sending data.
> Even restarting weewx is not enough to make it wake up.
>
> There are 3 possibilities I can think of.
>
>1. hardware fault in USB
>2. kernel driver fault in USB code
>3. WMR300 USB code is very touchy and liable to deadlock - which I 
>discovered when trying to modify the code. It gets upset if both sides try 
>to read or write at the same time.
>
> for point 3, I have tried to put lots of workarounds to try to ensure it 
> does not happen, but there might be hardware timing differences between 
> systems causing problems on one setup and not another.
> for point 2, this gets back to the kernel version differences.  Maybe this 
> is how my experimental driver responds to the same problem that locks up 
> under libusb0. Which kernel is this happening on?
> for point 1 - not a lot I can do there, wait to see if other people 
> replicate it.
>
> The next steps would be:
>
>- try the other kernel
>- try another USB port, if available
>- when it happens next time, see what happens if you simply unplug the 
>USB for a few seconds. This will reset the WMR300 console comms, it should 
>also reset the kernel.driver code.
>
> Cameron.
>
>
> On Tuesday, 9 October 2018 05:58:39 UTC+10, Ruben Navarro Huedo wrote:
>>
>> raspberry did not hung... only stopped receibing data from wmr300.
>>
>>
>>

-- 
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.

[weewx-user] Re: Connect Froggit WH3000SE weatherstation to weewx

[Bernd Mohr]

Hello Wolfgang,

for now, my Froggit WH3000se Wifi Weather Station is up and running with 
weewx :-)

I spent a lot of time to read a lot of Google Groups and other Forums. It 
seems like that there must be a solution for this kind of Wifi PWS.
By the way, our PWS is sold under different brands like this:

Froggit WH3000SE

Fine Offset WH2909

Ventus 830

Ambient Weather WS2902 a


i think all these brands and models are the equal Station type ;-) 


if you are just interested using weewx with your PWS, give me a sign here. 

Spoiler: You have to use the interceptor Driver and you have to reroute 
your iptables to weewx server. This is the only existing solution for my 
understanding. 


if you prefer, we can go on in german language ;-) 


Kind regards,


Bernd 

-- 
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.

Re: [weewx-user] An alternative way of applying a skin - a ready made drop-in template customised for weeWX

[steepleian]

Hello Thomas,

Thanks for the advice. Job done - zip files removed and files and folders 
open for inspection.

On Tuesday, October 9, 2018 at 12:43:43 PM UTC+1, Thomas Keffer wrote:
>
> Sharp looking webpage!
>
> May I offer a suggestion? Right now, your GitHub repository is just acting 
> as a place to store a bunch of .zip files, making it very hard to see 
> what's inside them. Many people, myself included, are reluctant to download 
> unknown zip files. 
>
> Why not just store the raw files, then let GitHub do the zipping? By 
> storing the raw files, you let people see what they're getting into, as 
> well as allow them to fork the repository and offer pull requests. 
> Upgrading is also much easier. GitHub is an amazing resource --- might as 
> well take full advantage of it.
>
> As you Brits would say, cheers!
>
> -tk
>
> On Tue, Oct 9, 2018 at 1:55 AM > wrote:
>
>> I think that we can all agree that the real strengths of weeWX are what 
>> goes on 'under the hood (or the bonnet for a Brit like me)', its sheer 
>> adaptability and a huge community working out solutions together.
>>
>> I came to weeWX after years of being a Cumulus user (another excellent 
>> software) but came to a grinding halt when changing to unsupported Weather 
>> Station. It was weeWX to the rescue along with the HP1000 driver and I was 
>> back up and running. In my Cumulus days I had been an early adopter of the 
>> excellent weather34 template, designed and owned by Brian Underdown. This 
>> was originally designed for use with Cumulus as a single dashboard concept 
>> where everything is accessible from a single web page. So could I use the 
>> template with weeWX, yes by deploying the CRT extension to generate a 
>> realtime.txt file.
>>
>> Now I wanted it to do more, I am not a coder so it takes me a bit longer 
>> to discover the snippets of code that I need to make things happen and this 
>> is where this forum and others became a valuable resource for myself along 
>> with contributions and technical support from others. A big thanks here to 
>> David Marshall who has rescued me on more than one occasion.
>>
>> Recently Brian Underwood took the decision to only support the 
>> Meteobridge version of his template going forward. However, he was very 
>> happy for the other versions of the template to hosted and maintained by 
>> others. On this basis, both the weeWX and Cumulus versions live on. I am 
>> now hosting the weeWX version and actively maintaining it in the spirit of 
>> Brian's original concept. You can find it here: -
>>
>>
>> https://github.com/steepleian/weather34-Home-Weatherstation-Template-weeWX-adapted
>>
>> The latest version is now using the weeWX archive database to generate 
>> the pop-up CanvasJS charts instead of relying on Weather Underground. The 
>> setup guides are provided for general guidance only due to the multitude of 
>> ways weeWX can be setup by individual users.
>>
>> I would like to re-iterate that although Brian Underdown is very happy 
>> for this version to exist and be maintained, he offers no support 
>> whatsoever for this version. Any requests to do so will remain unanswered. 
>> Please respect Brian's wishes in this respect. Any issues should be 
>> directed to this forum.
>>
>> My own current version of the template shows additional features which 
>> may be included in future updates if there is sufficient demand. It can 
>> found here https://claydonsweather.org.uk
>>
>> When used with a smartphone or a narrow browser window, the page morphs 
>> into a slimline mobile version.
>>
>> -- 
>> 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+...@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.

Re: [weewx-user] Re: how I change what shows up in my Weewx RSS feed?

[Kevin Lloyd]

I am indeed referring to that xml file. Thank you so much, Gary! I'll
backup the tmpl file and give that a try and see what happens, and post an
update here. :)

On Mon, Oct 8, 2018 at 6:20 PM gjr80  wrote:

> Hi,
>
> When you refer to the 'RSS feed' I presume you are referring to the
> weewx_rss.xml file that appears in public_html/RSS ?
>
> You can control what appears in weewx_rss.xml through the
> skins/Standard/RSS/weewx_rss.xml.tmpl template file. `Wind: 6 km/h from
> 106°` will likely be produced by the following:
>
> $current.windSpeed from $current.windDir
>
> though it really depends on what you are picking up and tweeting from
> weewx_rss.xml. In this case the tag $current.windDir will give you a
> numeric direction with degree sign (the default format). If you change that
> to use $current.windDir.ordinal_compass instead of just $current.windDir
> you will get an ordinal direction like ESE. If you wan to include both you
> could use $current.windDir ($current.windDir.ordinal_compass) or 
> $current.windDir.ordinal_compass
> ($current.windDir) to get 106° (ESE) or ESE (106°) respectively.
>
> You might want to have a read through the Tags section
>  of the Customization Guide
>  or if you are really adventurous
> the Wind section .
>
> Any changes you do make to weewx_rss.xml.tmpl should be safe across WeeWX
> upgrades but you may wish to make a copy of your modified
> weewx_rss.xml.tmpl just in case.
>
> Gary
>
> PS. You may also want to have a look at the twitter extension
> , might save you a bit of
> double handling.
>
> --
> 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/sO7TbQlGySU/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.
>


-- 
*Kevin Lloyd*
@kevinlovestech 
780-937-7428

-- 
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.

[weewx-user] Re: WMR300 - intermittent and partial loss of loop data

[Cameron D]

OK, this is not the symptom that this thread applies to - it might be more 
relevant to the hanging thread - I'll explain why at the end.

The logs are demonstrating total loss of data - this is similar to the 
previous problem, where the data stops, and my driver update detects this 
and resends the initialisation command.
Where this is different is the restart command seems to have no effect. The 
wmr300 console resolutely stops sending data.
Even restarting weewx is not enough to make it wake up.

There are 3 possibilities I can think of.

   1. hardware fault in USB
   2. kernel driver fault in USB code
   3. WMR300 USB code is very touchy and liable to deadlock - which I 
   discovered when trying to modify the code. It gets upset if both sides try 
   to read or write at the same time.

for point 3, I have tried to put lots of workarounds to try to ensure it 
does not happen, but there might be hardware timing differences between 
systems causing problems on one setup and not another.
for point 2, this gets back to the kernel version differences.  Maybe this 
is how my experimental driver responds to the same problem that locks up 
under libusb0. Which kernel is this happening on?
for point 1 - not a lot I can do there, wait to see if other people 
replicate it.

The next steps would be:

   - try the other kernel
   - try another USB port, if available
   - when it happens next time, see what happens if you simply unplug the 
   USB for a few seconds. This will reset the WMR300 console comms, it should 
   also reset the kernel.driver code.

Cameron.


On Tuesday, 9 October 2018 05:58:39 UTC+10, Ruben Navarro Huedo wrote:
>
> raspberry did not hung... only stopped receibing data from wmr300.
>
>
>

-- 
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.

Re: [weewx-user] Re: Belchertown Skin and MQTT With Username Not Working

[G Hammer]

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  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 , 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 :@ 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  *On
 Behalf Of *Philip Kutzenco
 *Sent:* Monday, October 8, 2018 3:32 PM
 *To:* weewx-user 
 *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 

Re: [weewx-user] Re: Belchertown Skin and MQTT With Username Not Working

[Philip Kutzenco]

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 , 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 :@ 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  *On 
>>> Behalf Of *Philip Kutzenco
>>> *Sent:* Monday, October 8, 2018 3:32 PM
>>> *To:* weewx-user 
>>> *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"  
>>> 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 

Re: [weewx-user] An alternative way of applying a skin - a ready made drop-in template customised for weeWX

[Thomas Keffer]

Sharp looking webpage!

May I offer a suggestion? Right now, your GitHub repository is just acting
as a place to store a bunch of .zip files, making it very hard to see
what's inside them. Many people, myself included, are reluctant to download
unknown zip files.

Why not just store the raw files, then let GitHub do the zipping? By
storing the raw files, you let people see what they're getting into, as
well as allow them to fork the repository and offer pull requests.
Upgrading is also much easier. GitHub is an amazing resource --- might as
well take full advantage of it.

As you Brits would say, cheers!

-tk

On Tue, Oct 9, 2018 at 1:55 AM  wrote:

> I think that we can all agree that the real strengths of weeWX are what
> goes on 'under the hood (or the bonnet for a Brit like me)', its sheer
> adaptability and a huge community working out solutions together.
>
> I came to weeWX after years of being a Cumulus user (another excellent
> software) but came to a grinding halt when changing to unsupported Weather
> Station. It was weeWX to the rescue along with the HP1000 driver and I was
> back up and running. In my Cumulus days I had been an early adopter of the
> excellent weather34 template, designed and owned by Brian Underdown. This
> was originally designed for use with Cumulus as a single dashboard concept
> where everything is accessible from a single web page. So could I use the
> template with weeWX, yes by deploying the CRT extension to generate a
> realtime.txt file.
>
> Now I wanted it to do more, I am not a coder so it takes me a bit longer
> to discover the snippets of code that I need to make things happen and this
> is where this forum and others became a valuable resource for myself along
> with contributions and technical support from others. A big thanks here to
> David Marshall who has rescued me on more than one occasion.
>
> Recently Brian Underwood took the decision to only support the Meteobridge
> version of his template going forward. However, he was very happy for the
> other versions of the template to hosted and maintained by others. On this
> basis, both the weeWX and Cumulus versions live on. I am now hosting the
> weeWX version and actively maintaining it in the spirit of Brian's original
> concept. You can find it here: -
>
>
> https://github.com/steepleian/weather34-Home-Weatherstation-Template-weeWX-adapted
>
> The latest version is now using the weeWX archive database to generate the
> pop-up CanvasJS charts instead of relying on Weather Underground. The setup
> guides are provided for general guidance only due to the multitude of ways
> weeWX can be setup by individual users.
>
> I would like to re-iterate that although Brian Underdown is very happy for
> this version to exist and be maintained, he offers no support whatsoever
> for this version. Any requests to do so will remain unanswered. Please
> respect Brian's wishes in this respect. Any issues should be directed to
> this forum.
>
> My own current version of the template shows additional features which may
> be included in future updates if there is sufficient demand. It can found
> here https://claydonsweather.org.uk
>
> When used with a smartphone or a narrow browser window, the page morphs
> into a slimline mobile version.
>
> --
> 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.
>

-- 
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.

Re: [weewx-user] Re: Belchertown Skin and MQTT With Username Not Working

[G Hammer]

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 , 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 :@ 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  *On Behalf 
>> Of *Philip Kutzenco
>> *Sent:* Monday, October 8, 2018 3:32 PM
>> *To:* weewx-user 
>> *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"  
>> 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 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.

[weewx-user] Re: Importing other data

[steepleian]

I used this to include AQI data from a close by external 
source. https://github.com/weewx/weewx/wiki/add-sensor

It works like a dream. See the popup link to to PM2.5 in the bottom right 
panel at https://claydonsweather.org.uk

On Monday, October 8, 2018 at 3:58:08 PM UTC+1, Andre Rieth wrote:
>
>
> Hello Besides weewx, I have an environmental station based on easyesp. Is 
> there a way to import the data from there and output it by graphics. In 
> addition to temperature and humidity, I also have dust particles and 
> radioactive radiation. I would be happy if it is possible. greetings André
>

-- 
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.

[weewx-user] An alternative way of applying a skin - a ready made drop-in template customised for weeWX

[steepleian]

I think that we can all agree that the real strengths of weeWX are what 
goes on 'under the hood (or the bonnet for a Brit like me)', its sheer 
adaptability and a huge community working out solutions together.

I came to weeWX after years of being a Cumulus user (another excellent 
software) but came to a grinding halt when changing to unsupported Weather 
Station. It was weeWX to the rescue along with the HP1000 driver and I was 
back up and running. In my Cumulus days I had been an early adopter of the 
excellent weather34 template, designed and owned by Brian Underdown. This 
was originally designed for use with Cumulus as a single dashboard concept 
where everything is accessible from a single web page. So could I use the 
template with weeWX, yes by deploying the CRT extension to generate a 
realtime.txt file.

Now I wanted it to do more, I am not a coder so it takes me a bit longer to 
discover the snippets of code that I need to make things happen and this is 
where this forum and others became a valuable resource for myself along 
with contributions and technical support from others. A big thanks here to 
David Marshall who has rescued me on more than one occasion.

Recently Brian Underwood took the decision to only support the Meteobridge 
version of his template going forward. However, he was very happy for the 
other versions of the template to hosted and maintained by others. On this 
basis, both the weeWX and Cumulus versions live on. I am now hosting the 
weeWX version and actively maintaining it in the spirit of Brian's original 
concept. You can find it here: -

https://github.com/steepleian/weather34-Home-Weatherstation-Template-weeWX-adapted

The latest version is now using the weeWX archive database to generate the 
pop-up CanvasJS charts instead of relying on Weather Underground. The setup 
guides are provided for general guidance only due to the multitude of ways 
weeWX can be setup by individual users.

I would like to re-iterate that although Brian Underdown is very happy for 
this version to exist and be maintained, he offers no support whatsoever 
for this version. Any requests to do so will remain unanswered. Please 
respect Brian's wishes in this respect. Any issues should be directed to 
this forum.

My own current version of the template shows additional features which may 
be included in future updates if there is sufficient demand. It can found 
here https://claydonsweather.org.uk

When used with a smartphone or a narrow browser window, the page morphs 
into a slimline mobile version.

-- 
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.