from:"Les Niles"

Re: [weewx-user] safety of wind instruments on metal pole on roof?

2022-01-17 Thread Les Niles

What about using a fiberglass pole instead?  The wires to the instruments could 
still potentially attract lightning, but probably wouldn’t carry enough current 
to start a fire — might blow out the weather station electronics, but not burn 
down the house.  Max-gain Systems  sells fiberglass rods 
and tubes in various lengths and diameters.  

  -Les



> On 17 Jan 2022, at 12:03, morr...@gmail.com  wrote:
> 
> Not strictly weewx related, but:
> 
> Any safety concerns with mounting my wind speed and direction instruments on 
> a 1.25" galvanized steel pole, 6 feet above the roof line? 
> 
> I currently have a prototype anemometer about 20 feet in the air. It's well 
> away from our house so solar powered, which is proving a challenge.
> 
> We get a bit of lightning here, but there are tall trees near our house, and 
> I've never heard of a direct hit in the neighborhood.
> 
> Thanks for any experience/anecdotes.
> 
> -- 
> 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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/e7a23b4f-51af-4513-a31f-af9e64e4f527n%40googlegroups.com
>  
> .

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/D99852A4-B115-4924-82FB-A3AE73DCA3FB%402pi.org.

Re: [weewx-user] When did the blast wave of the eruption "hit" your station?

2022-01-17 Thread Les Niles

I think you’re looking at the wrong time period. The initial, direct wave arrived at the U.S. west coast — about 8400 Km from Tonga — around 4:00am Pacific time on Jan 15. It should take 3-1/2 to 4 hours to travel the additional 4600 Km to your location. That, plus the 4 hour time difference, would put it at around 12:00 noon your time on Jan 15, not Jan 16. The long path wave should’ve arrived at your location something like 13-14 hours later, or shortly after midnight on Jan 16. The second trip around the Earth of the initial wave would be something like 32-36 hours after the first arrival, or 20:00-24:00 your time on Jan 16. What you’ve plotted here misses all of those.
-Les

On 17 Jan 2022, at 11:58, morr...@gmail.com wrote:Not sure I am really seeing it here in maritime Canada. We're about 13000 km from Tonga.Attached is a gnuplot command file and its output is:

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/52D74246-A0DA-4F09-8CE2-8C146E76DE84%402pi.org.
The pressure pulse should have arrived about 12:00 local time. There is a little pressure increase at about 12:10.Use the command file to read from weewx database:rm barometer.png; sqlite3 weewx.sdb "select datetime, barometer from archive where datetime > 164232 and datetime < 1642384200 order by dateTime;" | gnuplot barometer.gnupand modify as needed for your own location.

barometer.gnup
Description: Binary data

Re: [weewx-user] Fog detection?

2021-09-03 Thread Les Niles

Parameters like that can predict that fog is likely, but to actually identify 
fog you need to observe that the visibility is less than 1 km. (Visibility 
between 1 and 5 km is haze or mist.) The automated weather observation systems 
commonly installed at airports and other locations include a visibility sensor 
that measures how much light is scattered in a small volume of air. The 
principle is pretty simple but I haven’t seen any low-cost consumer version. 

  -Les


> On Sep 3, 2021, at 6:06 AM, František Slimařík  wrote:
> 
> Hi,
> 
> just like I mentioned in the start, it will not be so easy to predict fog. In 
> case of my location I had following conditions this morning between 5-6AM and 
> no fog was visible. Just condensation on the cars etc.
> 
> Temperature between 6-7°C
> Humidity 97%
> no wind
> no solar radiation
> also difference between temperature and dew point was just 0,4°C
> 
> Dne pátek 3. září 2021 v 13:51:16 UTC+2 uživatel mihec napsal:
>> I'm using Weather Display with one of my stations and use the built in 
>> function to set the fog/haze conditions. It works very good.
>> Fog conditions:
>> * T < 10°C
>> * 95% >= humidity
>> * low wind or no wind
>> * solar radiation low
>> 
>> Haze:
>> * T < 13°C
>> * 94% >= humidity
>> * low wind, low solar
>> 
>> I might have slightly adapted humidity threshold, I don't remember.
>> 
>> 
>> sreda, 01. september 2021 ob 00:29:22 UTC+2 je oseba storm...@gmail.com 
>> napisala:
>>> In general, the possibility of fog developing is when the dewpoint spread 
>>> is less then  5 degrees F.
>>> 
 On Tuesday, August 31, 2021 at 6:02:58 PM UTC-4 n0...@n0nb.us wrote:
 * On 2021 31 Aug 14:35 -0500, František Slimařík wrote: 
 > 
 > Hi all, 
 > 
 > I got question for hardcore meteorologists here. Is it possible to 
 > detect 
 > fog based on classic meassured values like temperature, humidity, 
 > preasure, 
 > etc? 
 > Logically I would say fog appears when dew point equals current 
 > temeperature but I guess it will not be so easy. Fogs didn't appear here 
 > this year in my locality so I am waiting for autumn to start with 
 > observations. 
 
 I'm certainly no meteorologist! 
 
 It seems we've had more foggy mornings this summer than in years past. 
 Humidity has certainly been high with only a handful of stretches with 
 more than a day below 50% relative humidity. 
 
 Many times it seems as though warm air over cooler moist ground is 
 necessary for its formation. I don't think this is a temperature 
 inversion, as such, but they also seem to sometimes be quite localized 
 and are related to some interesting effects. 
 
 I along with other radio amateurs and possibly Greg find the effects of 
 these weather phenomena on VHF and UHF radio propagation interesting. 
 
 - Nate 
 
 -- 
 "The optimist proclaims that we live in the best of all 
 possible worlds. The pessimist fears this is true." 
 Web: https://www.n0nb.us 
 Projects: https://github.com/N0NB 
 GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 
 
> 
> -- 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/909cb30b-7281-4d27-99eb-59b0f3dfb41dn%40googlegroups.com.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/9F5E54C4-1CE2-434C-AAC0-95474D4E9A34%402pi.org.

Re: [weewx-user] Belchertown MQTT Issues

2021-07-25 Thread Les Niles

Ah, ok thanks. I’m running the web server unencrypted as well, for the same 
reason.  

  -Les


> On Jul 25, 2021, at 4:14 AM, Karen K  wrote:
> 
> ln77 schrieb am Sonntag, 25. Juli 2021 um 03:35:38 UTC+2:
>> I don’t see the point of SSL on the websockets connection from the browser. 
>> The data is all public, there’s nothing sensitive sent by the client, and if 
>> someone spoofs the mqtt broker, who really cares?
> 
> The web browser cares. If it receives the website by HTTPS (SSL encrypted), 
> then it refuses to connect to an unencrypted websockets server.
>  
>>  
> 
> -- 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/08aa26d4-d986-4916-9c82-4c895c8b8fddn%40googlegroups.com.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/4C1AF58F-A4E6-413C-9724-01F248E382B0%402pi.org.

Re: [weewx-user] Belchertown MQTT Issues

2021-07-24 Thread Les Niles

I don’t see the point of SSL on the websockets connection from the browser. The 
data is all public, there’s nothing sensitive sent by the client, and if 
someone spoofs the mqtt broker, who really cares?

Neither do I see much need for ssl on the weewx-to-broker connection when 
they’re running on the same machine, or even on an internal network. I can 
imagine scenarios where not using ssl allows a vulnerability, but I think the 
likelihood is low if the internal network itself is well secured, so I haven’t 
bothered with ssl. It would be different with a cloud-hosted or other external 
mqtt broker with the weewx-mqtt connection running over a public network. 

  -Les


> On Jul 24, 2021, at 9:33 AM, Matt Johnson  wrote:
> 
> 
> Doing more trouble shooting. I have narrowed it down to a SSL issue. 
> 
> To confirm this I disabled SSL at cloudflare and disabled force SSL for 
> shakerweather.com with my NGINX reverse proxy server and ran with this setup:
> 
> weewx.config
> [[MQTT]]
> server_url = mqtt://usr:p...@mqtt.shakerweather.com:1883/
> 
> topic = weather
> unit_system = US
> binding = archive, loop 
> aggregation = aggregate
> 
> skin.conf
># MQTT Websockets defaults
> mqtt_websockets_enabled = 1
> mqtt_websockets_host = "mqtt.shakerweather.com"
> mqtt_websockets_port = 9001
> mqtt_websockets_ssl = 0
> mqtt_websockets_topic = "weather/loop"
> disconnect_live_website_visitor = 180
> 
> mosquitto.conf
> persistence false
> 
> # mqtt
> listener 1883
> protocol mqtt
> 
> # websockets
> listener 9001
> protocol websockets
> 
> allow_anonymous true
> password_file /etc/mosquitto/passwd
> acl_file /etc/mosquitto/acl
> 
> 
> I am able to see the real time websocket updates internally and externally at 
> http://shakerweather.com (I'll leave it up for a short time so if it doesn't 
> work if you click on it that could be why)
> 
> So at least I have narrowed down the issue. Still not sure how to resolve to 
> ensure all is secured with SSL
>> On Saturday, July 24, 2021 at 10:23:03 AM UTC-4 Matt Johnson wrote:
>> Your setup seems similar to mine so I went for it. Still not working. 
>> 
>> I went ahead and added a mqtt CNAME record to the shakerweather.com 
>> cloudflare setup. I also added mqtt.shakerweather.com to my NGINX Proxy 
>> Server to forward to port 9001 using the same SSL certificate I have for 
>> shakerweather.com that is forwarding to port 80 to serve the page.
>> 
>> Cloudflare:
>> TYPE  NAME CONTENT
>> CNAME  mqttshakerweather.com
>> A shakerweather.com static wan IP
>> 
>> weewx.conf
>> [[MQTT]]
>> server_url = mqtt://user:p...@10.0.0.30:1883/
>> 
>> topic = weather
>> unit_system = US
>> binding = archive, loop 
>> aggregation = aggregate
>> 
>> skin.conf
>>  # MQTT Websockets defaults
>> mqtt_websockets_enabled = 1
>> mqtt_websockets_host = "mqtt.shakerweather.com"
>> mqtt_websockets_port = 443
>> 
>> mqtt_websockets_ssl = 1
>> mqtt_websockets_topic = "weather/loop"
>> disconnect_live_website_visitor = 180
>> 
>> mosquitto.conf
>> persistence false
>> 
>> # mqtt
>> listener 1883
>> protocol mqtt
>> 
>> # websockets
>> listener 9001
>> protocol websockets
>> 
>> 
>> allow_anonymous true
>> password_file /etc/mosquitto/passwd
>> 
>> acl_file /etc/mosquitto/acl
>>> On Saturday, July 24, 2021 at 8:33:43 AM UTC-4 do...@dougjenkins.com wrote:
>>> I had a number of struggles with this when I setup the Belchertown skin on 
>>> my Raspberry Pi hosting my weather site, www.largoweather.com. I think the 
>>> issue is that you need your mqtt_websockets_port to be set to 443 as the 
>>> websocket traffic is getting filtered out by your firewall (9001->8083)
>>> 
>>> Here is what I did to get this to work on largoweather.com:
>>> 
>>> 1. Setup Cloudflare to manage the DNS proxy on 2 domains: 
>>>- largoweather.com (A Record)
>>>- wx.largoweather.com (aka your mqtt.beldenserver.com) - CNAME Record 
>>> pointing the content to largoweather.com
>>>- Setup my SSL/TLS to Strict. I am using Cloudflare to offload my SSL 
>>> processing so essentially all traffic is coming in through 443.
>>>
>>>These are pointed to my public IP address which is dynamic. I use a 
>>> shell script to update cloudflare' content to keep my public IP current for 
>>> their system
>>> 
>>> 2. NGNIX Proxy Manager : I use this program to manage my NGINX instance 
>>> that acts as a reverse proxy manager for my domains:
>>>  2.1 : Setup:
>>> - largoweather.com : Setup to point to my local server ip 
>>> address. The scheme is http. I use the program's lets encrypt function to 
>>> get a SSL certificate and force SSL traffic to my final weewx website.
>>>  - wx.largoweather.com : This handles my sockets setup. I 
>>> forward all traffic to port 9001 and use the same ssl

Re: [weewx-user] Belchertown MQTT Issues

2021-07-24 Thread Les Niles

I think the first configuration, with the local mqtt broker  isn’t going to 
work because mqtt_websockets_host is set to localhost, which will only resolve 
to the weewx/mqtt server when the web browser is running on that server.  You 
need to set something here that will resolve to the weewx/mqtt server from any 
client that you want to get realtime updates.  

Not sure why the second config, with the cloud mqtt broker, isn’t working. Are 
you sure the mqtt broker is configured for SSL on port 8883?  You might put 
“log_success = true” in the weewx [[MQTT]] config and see if the log messages 
tell you anything useful.  

Or forget about the cloud server and go back to getting the first config 
working.  You need a DNS name that will resolve to your firewall and get 
port-forwarded (for port 8083) to the weewx/mqtt server, for 
mqtt_websockets_host. That should enable external access.  And, if your 
firewall will do hairpinning, it should work internally as well. It may take 
some magic with forwarding/masquerading rules on the firewall to get 
hairpinning to work.  (The alternative for internal access is to have an 
internal DNS server that resolves that hostname directly to the internal IP of 
the weewx/mqtt server for clients on the internal network.)

  -Les



> On 23 Jul 2021, at 21:05, Matt Johnson  wrote:
> 
> I've been trouble shooting getting the Belchertown skin MQTT Websocket real 
> time updates to work on my site shakerweather.com for a lot of this week. 
> 
> I have WeeWx installed on a dedicated thin client on Ubuntu 20.04 LTS and 
> have Mosquitto and NGINX installed on the same machine. Running bare metal, 
> no docker or VMs here.
> 
> External access to WeeWx website is handled via NGINX reverse proxy manager 
> with SSL certs on a different server via docker. Requests to 
> shakerweather.com are sent to the proxy server and then to the WeeWx machine.
> 
> With this setup, the site is served up fine internally and externally with 
> the updates at archive intervals every 5 minutes. 
> 
> I know that the weewx-mqtt extension is installed correctly as I have been 
> able to test it locally and get the websocket updates to work perfectly with 
> the following configs:
> 
> weewx.conf
> [[MQTT]]
> server_url = mqtt://user:pw@localhost:8883/
> topic = weather
> unit_system = US
> binding = archive, loop 
> aggregation = aggregate
> 
> skin.conf
>  # MQTT Websockets defaults
> mqtt_websockets_enabled = 1
> mqtt_websockets_host = "localhost"
> mqtt_websockets_port = 8083
> mqtt_websockets_ssl = 0
> mqtt_websockets_topic = "weather/loop"
> disconnect_live_website_visitor = 180
> 
> I am only able to see the the real time updates on the local machine only 
> with WeeWx and Mosquitto. If I try to access it by IP address elsewhere on my 
> LAN on other clients it does not connect and eventually fails. No luck 
> externally either - despite my NGINX Reverse Proxy Manger handling serving 
> the page and SSL certs the websocket real time updates don't pass through. 
> That was my original thought of how it would work.
> 
> After much trial and error, and reading every thread imaginable on this along 
> with many messages and some correspondence with Pat O'Brien I decided to go 
> ahead and setup a Digital Ocean Ubuntu VM and install Mosquito there to serve 
> as a cloud broker. I followed Pat's instructions exactly as he outlines in 
> setting up the cloud broker: 
> https://obrienlabs.net/how-to-setup-your-own-mqtt-broker/ 
> 
> 
> I have the cloud MQTT broker installed correctly at Digital Ocean with Let's 
> Encrypt, and ran tests on it. Messages can be sent when authenticated, ports 
> are open, etc. However, I can get no further with the websockets real time 
> updates than "Connected. Waiting for data". If I reboot the cloud MQTT broker 
> I immediately get a disconnected message on the website so it does appear to 
> be connecting and waiting for data. Somehow the data is simply not 
> transferring from my WeeWx client to the cloud MQTT broker at Digital Ocean. 
> The other weird thing is if I try to access shakerweather.com or the website 
> by local IP address on the machine that hosts WeeWx I always get a failed 
> message, won't even connect to the server. However, any other client on my 
> LAN and external on WAN does not have this issue.
> 
> Here are my current configs:
> 
> weewx.conf
> [[MQTT]]
> server_url = mqtt://user:p...@mqtt.beldenserver.com:8883/
> topic = weather
> unit_system = US
> binding = archive, loop 
> aggregation = aggregate
>  [[[tls]]]
> tls_version = tlsv1
> ca_certs = /etc/ssl/certs/ca-certificates.crt
> 
> skin.conf
> # MQTT Websockets defaults
> mqtt_websockets_enabled = 1
> mqtt_websockets_host = "mqtt.beldenserver.com"
> mqtt_websockets_port = 8083
>

Re: [weewx-user] Settings to change after IP address of Vantage changes

2021-07-08 Thread Les Niles

Don’t worry about the wifi interface, it’s probably not a problem, should be 
easy to confirm if you can run those commands.

  -Les



> On 8 Jul 2021, at 10:22, David Hindley  wrote:
> 
> 
> Les
> 
> OK. Will turn the firewall off temporarily. 
> 
> How do I only use the Ethernet interface? (ie disable the Wi-Fi). 
> 
> David.  
> On Thu, 8 Jul 2021 at 17:57, Les Niles mailto:l...@2pi.org>> 
> wrote:
> Having both interfaces active isn’t a problem itself, but it doesn’t open up 
> the potential for various isconfigurations that can make networking flaky. 
> I’ve discovered a number of them myself. :)  Just want to eliminate that as 
> the source of the problem. 
> 
> David, it would also be useful to turn off the firewall while debugging this. 
> I don’t see evidence that the firewall is the problem, but turning it off 
> would eliminate any possibility. 
> “sudo disable ufw” should do it. 
> 
>   -Les
> 
> 
>> On Jul 8, 2021, at 8:34 AM, vince > <mailto:vinceska...@gmail.com>> wrote:
>> 
>> I have a wired pi that shows both wifi and ethernet interfaces up so that 
>> part is typical.
>> 
>> A quick look at the logs show lots of DNS resolution errors (Temporary 
>> failure in name resolution) and a bouncy eth0 interface (carrier lost).
>> Also some really bizarre hostnames ('home756219443.1and1-data.host')
>> 
>> To me the network looks pretty confused at best.
> 
>> 
>> 
>> -- 
>> 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 
>> <mailto:weewx-user+unsubscr...@googlegroups.com>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/19ef35bc-df92-43f3-a8eb-08717f3fc8e7n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/weewx-user/19ef35bc-df92-43f3-a8eb-08717f3fc8e7n%40googlegroups.com?utm_medium=email_source=footer>.
> 
> 
> -- 
> 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/9gG34XNbgDk/unsubscribe 
> <https://groups.google.com/d/topic/weewx-user/9gG34XNbgDk/unsubscribe>.
> To unsubscribe from this group and all its topics, send an email to 
> weewx-user+unsubscr...@googlegroups.com 
> <mailto:weewx-user+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/E8D77E3A-74AE-47B1-B622-597153F67E45%402pi.org
>  
> <https://groups.google.com/d/msgid/weewx-user/E8D77E3A-74AE-47B1-B622-597153F67E45%402pi.org?utm_medium=email_source=footer>.
> 
> -- 
> 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 
> <mailto:weewx-user+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/CAKbmhJSeXtCZU2-CfGPfz-WQx94049n21%2Br1rgi0Kw1B1hs0MQ%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/weewx-user/CAKbmhJSeXtCZU2-CfGPfz-WQx94049n21%2Br1rgi0Kw1B1hs0MQ%40mail.gmail.com?utm_medium=email_source=footer>.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/2D25B3E2-9C0F-4391-9961-6EA2BA1315EA%402pi.org.

Re: [weewx-user] Settings to change after IP address of Vantage changes

2021-07-08 Thread Les Niles

Having both interfaces active isn’t a problem itself, but it doesn’t open up 
the potential for various isconfigurations that can make networking flaky. I’ve 
discovered a number of them myself. :)  Just want to eliminate that as the 
source of the problem. 

David, it would also be useful to turn off the firewall while debugging this. I 
don’t see evidence that the firewall is the problem, but turning it off would 
eliminate any possibility. 
“sudo disable ufw” should do it. 

  -Les


> On Jul 8, 2021, at 8:34 AM, vince  wrote:
> I have a wired pi that shows both wifi and ethernet interfaces up so that 
> part is typical.
> 
> A quick look at the logs show lots of DNS resolution errors (Temporary 
> failure in name resolution) and a bouncy eth0 interface (carrier lost).
> Also some really bizarre hostnames ('home756219443.1and1-data.host')
> 
> To me the network looks pretty confused at best.
> 
> -- 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/19ef35bc-df92-43f3-a8eb-08717f3fc8e7n%40googlegroups.com.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/E8D77E3A-74AE-47B1-B622-597153F67E45%402pi.org.

Re: [weewx-user] Settings to change after IP address of Vantage changes

2021-07-08 Thread Les Niles

This time it looks like you only have one instance of weewx running.  That’s 
progress.

What do you mean by your “network crashed”?

I didn’t notice this before, but it looks like you’re using both the ethernet 
and wi-fi interfaces on the Pi.  How is the Davis connected to the Pi?  
Please run the commands “/sbin/ifconfig -a”, “sudo /sbin/route -n”, and 
“/usr/sbin/arp -n" and send the outputs.  

  -Les



> On 8 Jul 2021, at 4:40, David Hindley  wrote:
> 
> Gary
> 
> Many thanks for your reply.
> 
> The log of what happened when I did as you suggest is below.  I have included 
> my attempts to kill the weewx PIDs at the start.  There is less than 10mins, 
> as my network crashed half way through (this intermitten crashing is what 
> caused me to change my router set up and hence the IP address of the Davis 
> Vantage Pro2 and hence the issues described here).  At least this now appears 
> to only show one weewx PID, as far as I can see.  Any further help you can 
> give would be really appreciated.
> 
> pi@raspberrypi:~ $ sudo systemctl stop weewx
> 
> pi@raspberrypi:~ $ ps -aux|grep weewx
> 
> pi6438  0.0  0.0   4368   552 pts/0S+   11:23   0:00 grep 
> --color=au
>   
>   
>  to weewx
> 
> pi@raspberrypi:~ $ kill -9 6438
> 
> -bash: kill: (6438) - No such process
> 
> pi@raspberrypi:~ $ kill -9 4368
> 
> -bash: kill: (4368) - No such process
> 
> pi@raspberrypi:~ $ ps -aux|grep weewx
> 
> pi6457  0.0  0.0   4368   564 pts/0S+   11:26   0:00 grep 
> --color=auto weewx
> 
> pi@raspberrypi:~ $ kill -9 6457
> 
> -bash: kill: (6457) - No such process
> 
> pi@raspberrypi:~ $ sudo systemctl start weewx
> 
> pi@raspberrypi:~ $ ps -aux|grep weewx
> 
> root  6484  1.0  1.0  15452  9660 ?S11:27   0:00 python2 
> /usr/share/weewx/weewxd --daemon --pidf   
>   
>   
>   ile=/var/run/weewx.pid /etc/weewx/weewx.conf
> 
> pi6489  0.0  0.0   4368   544 pts/0S+   11:28   0:00 grep 
> --color=auto weewx
> 
> pi@raspberrypi:~ $ showlog
> 
> Jul  8 11:28:07 raspberrypi weewx[6484] DEBUG weewx.drivers.vantage: Getting 
> archive packets since 2021-07-08 06   
>   
>   
>   :20:00 BST (1625721600)
> 
> Jul  8 11:28:07 raspberrypi weewx[6484] DEBUG weewx.drivers.vantage: Gentle 
> wake up of console successful
> 
> Jul  8 11:28:09 raspberrypi weewx[6484] DEBUG weewx.drivers.vantage: 
> Retrieving 12 page(s); starting index= 1
> 
> Jul  8 11:28:09 raspberrypi weewx[6484] DEBUG weewx.drivers.vantage: DMPAFT 
> complete: page timestamp 2021-07-07   
>   
>   
>10:50:00 BST (1625651400) less than final timestamp 2021-07-08 
> 06:20:00 BST (1625721600)
> 
> Jul  8 11:28:09 raspberrypi weewx[6484] DEBUG weewx.drivers.vantage: Catch up 
> complete.
> 
> Jul  8 11:28:09 raspberrypi weewx[6484] INFO weewx.engine: Starting main 
> packet loop.
> 
> Jul  8 11:28:10 raspberrypi weewx[6484] DEBUG weewx.drivers.vantage: Gentle 
> wake up of console successful
> 
> Jul  8 11:28:11 raspberrypi weewx[6484] DEBUG weewx.drivers.vantage: 
> Requesting 200 LOOP packets.
> 
> Jul  8 11:28:11 raspberrypi weewx[6484] DEBUG weewx.drivers.vantage: Gentle 
> wake up of console successful
> 
> Jul  8 11:28:13 raspberrypi kernel: [12270.030958] [UFW BLOCK] IN=wlan0 OUT= 
> MAC=01:00:5e:00:00:fb:6e:a5:b7:f8:4   
>   
>   
>   a:c3:08:00 SRC=192.168.0.36 DST=224.0.0.251 LEN=32 TOS=0x00 PREC=0x00 
> TTL=1 ID=20067 PROTO=2
> 
> Jul  8 11:28:20 raspberrypi kernel: [12276.686821] [UFW BLOCK] IN=wlan0 OUT= 
> MAC=01:00:5e:00:00:01:e4:57:40:c2:d   
>   
>   
>   3:72:08:00 SRC=192.168.0.1 DST=224.0.0.1 LEN=36 TOS=0x00 PREC=0xC0 
> TTL=1 ID=15562 PROTO=2
> 
> Jul  8 11:28:22 raspberrypi kernel: [12278.325287] [UFW BLOCK] IN=wlan0 OUT= 
> MAC=01:00:5e:00:00:fb:78:3e:53:b8:e   
>

Re: [weewx-user] Settings to change after IP address of Vantage changes

2021-07-07 Thread Les Niles

Do you have multiple instances of weewx running?  That number enclosed in ‘[]’ 
after ‘weewx’ in the log messages should be the process ID; there are 3 
different PIDs intermixed in your log.  Run “ps uax | grep weewx” — there 
should be exactly one instance of python running weewxd.  A reboot will 
probably fix it.

  -Les



> On 7 Jul 2021, at 7:09, Doug Jenkins  wrote:
> 
> Have you tried to put the the new IP address in the [MQTT] section of the 
> weewx.conf file? I see this error which leads me to believe your DNS is still 
> pointed to the old IP address of your former network
> 
> Jul  7 11:04:16 raspberrypi weewxd: restx: MQTT: Failed upload attempt 1: 
> [Errno -3] Temporary failure in name resolution
> 
> On Wednesday, July 7, 2021 at 8:06:52 AM UTC-4 david_h wrote:
> Hi - I recently changed my home network set up, which meant the IP address of 
> my Davis Vantage Pro 2 changed.  I am using an IPlogger. I changed the 
> setting of "host" in weewx.conf to the new IP address, but my system doesn't 
> seem to be working.  Have I missed some other setting that I need to change.  
> I use the Belchertown skin (with a MQTT broker on a remote server), but can't 
> see anything in the skin configuration file that references the IP address. 
> Am I missing something.  The log file is shown below.  Any help in solving 
> this would be much appreciated.
> 
> Jul  7 11:03:26 raspberrypi weewx[1716] DEBUG weewx.drivers.vantage: Driver 
> vers  
>   
>   
>ion is 3.2.2
> 
> Jul  7 11:03:26 raspberrypi weewx[1716] DEBUG weewx.drivers.vantage: Option 
> loop  
>   
>   
>_request=1
> 
> Jul  7 11:03:26 raspberrypi weewx[1716] DEBUG weewx.drivers.vantage: Opened 
> up e  
>   
>   
>thernet host 192.168.0.28 on port 2. timeout=4.0, 
> tcp_send_delay=0.5
> 
> Jul  7 11:03:26 raspberrypi kernel: [ 1818.633379] [UFW BLOCK] IN=eth0 OUT= 
> MAC=  
>   
>   
>01:00:5e:00:00:fb:90:21:06:46:88:f9:08:00:46:c0:00:20:00:00:40:00 
> SRC=10.0.1.200
>   
>   
>   DST=224.0.0.251 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF 
> PROTO=2
> 
> Jul  7 11:03:26 raspberrypi weewx[1128] ERROR weewx.drivers.vantage: ip-read 
> err   
>   
>   
>   or: timed out
> 
> Jul  7 11:03:26 raspberrypi weewx[1128] ERROR weewx.drivers.vantage: LOOP try 
> #4
>   
>   
>  ; error: timed out
> 
> Jul  7 11:03:26 raspberrypi weewx[1128] ERROR weewx.drivers.vantage: LOOP max 
> tr
>   
>   
>  ies (4) exceeded.
> 
> Jul  7 11:03:26 raspberrypi weewx[1128] INFO weewx.engine: Main loop exiting. 
> Sh
>   
>   
>  utting engine down.
> 
> Jul  7 11:03:27 raspberrypi weewx[1716] DEBUG weewx.drivers.vantage: Rude 
> wake u
>   
>   
>  p of console successful
> 
> Jul  7 11:03:28

Re: [weewx-user] recommend IP cameras that are easy to grab a single frame from?

2021-07-02 Thread Les Niles

I use an Amcrest wifi security camera (IP4M-1026B). It’s configured to push a 
frame every minute via ftp. Pulling frames would’ve been a little easier, but 
this works just fine since there’s no need for frames to be captured at 
specific times. The timing doesn’t drift and the camera uses ntp so the time 
stamps are accurate. It’s waterproof and has a good field of view for this 
application, and most importantly, I had it laying around when I got the bug to 
add a webcam. 
http://www.2pi.org/wx/index.html

  -Les


> On Jul 2, 2021, at 1:55 PM, Eric K  wrote:
> 
> 
> Based on first hand experience, can people recommend various IP cameras 
> (ideally an Ethernet or wifi camera) with a focus towards ease of grabbing a 
> single frame from a Linux command line?
> I'd like to be able to grab single frames to use in the weewx webpage.
> 
> I don't want an RaspberryPi camera because I'd like multiple cameras and I 
> don't want to be tethered to a RaspberryPi via a short ribbon cable.
> 
> I've tested am Ethernet-connected camera that puts out an rtsp stream.  I 
> successfully used an ffmpeg command line to start the stream, wait 10 seconds 
> and then grab a frame.  Sometimes 10 seconds isn't enough and I have to try 
> 12-15 seconds.
> ffmpeg -loglevel info -rtsp_transport tcp -i 
> "rtsp://192.168.7.51/rtsp-stream" -ss 00:00:10 -r 1 -vframes 1 -y 
> /home/weewx/Pictures/image.jpg
> It works, but I don't think rtsp is the ideal transport method for grabbing a 
> single frame, because you have to wait about 10+ seconds for the stream to 
> fully form a valid image.
> 
> I wonder if anyone has tried the ESP32-CAMs?  They get connected to an 
> ESP6288 wifi module, and are thus small and wireless.
> https://www.amazon.com/ESP32-CAM-Bluetooth-Camera-Module-Development/dp/B07S5PVZKV
> -- 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/058f20b9-782e-408a-bca4-fdd8ca1d2d60n%40googlegroups.com.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/0A2CAE7B-29F7-46C9-BF76-72566B4DC08D%402pi.org.

Re: [weewx-user] Merge "parts" of two databases?

2021-05-08 Thread Les Niles

Here’s an outline of what I would do.  I use mysql and know nothing about 
sqlite, but assume the basic export and delete operations are easy.
1. Export the data you want from the old sqlite database into a CSV file.  
Export the full archive records, not just the missing field(s).  
2. Edit the CSV file if needed, to remove some records or whatever.
3. Use sqlite to delete from the current database the records corresponding to 
those in the CSV file.  (backup copy of db, like you said!)
4. Use wee_import to import the CSV file into the current database.  
5. Use wee_database to drop and rebuilt the daily summaries in weewx.

I used something like this to resurrect a bunch of historical data after a 
severe case of user error earlier this year. 

  -Les



> On 8 May 2021, at 7:46, Ernest Jillson  wrote:
> 
> I imported years of data from wunderground into my weewx db. There was a 
> period of very bad rain data due to a malfunctioning tipping bucket. Also had 
> a day where a small grasshopper managed to get into the little hole, then 
> proceeded to rack up about 15 inches of rain for me that day while trying to 
> escape.
>  
> I stopped weewx, made a copy of my db, then used sqlite browser to remove all 
> of the bad rain data, day by day, week by week. When I was satisfied, I 
> restarted weewx and life was good.
>  
> It wasn't until a month later, while flipping through some of my past data 
> that I realized I had somehow managed to remove much more data than I wanted 
> to. I mean, we're talking like a year's worth of rain data.
>  
> I don't want to import those days all over again, but I can if that's the 
> only way. I'd much rather like to find a way to "bring over" the rain from 
> the saved database for a range of dates, then start the fixing process again. 
> When I brought the data over from wunderground, there were lots of dew 
> point/humidity and temperature anomolies I had to fix as well.
>  
> My question:  Is there a way (perhaps using the sqlite browser) to import a 
> column (rain) from one database (the saved one) to the new database for just 
> a range of dates?
>  
> Thanks in advance!
> 
> 
> -- 
> 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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/CAC5oUmN6qQVrx0YTCLHhkKRdxJAg7%3DEjtcwDkudBO8bzJm956A%40mail.gmail.com
>  
> .

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/C4BC476C-0FF0-48D7-A66D-90C9DC01F3CE%402pi.org.

Re: [weewx-user] Can't get ftp working after reinstall

2021-04-15 Thread Les Niles

And, when doing that kind of testing, I copy/paste all the parameters — server 
name, user name, password and directory name — from weewx.conf to the ftp 
utility.  Often the cause is a minor typo that is hard to spot, like 
substituting the letter “O” for the digit “0” or lower-case “l” for upper-case 
“I”.  More often than I’d like to admit….

  -Les



> On 15 Apr 2021, at 14:18, Garry A Lockyer  wrote:
> 
> With apologies if you have already done this but I would use the 
> Linux/Raspberry Pi OS FTP utility (sudo apt update / sudo apt install ftp if 
> ftp is not already installed) to get ftp working outside WeeWX and then edit 
> weewx.conf based on what I learned (outside WeeWX).
> 
> Regards,
> 
> Garry Lockyer
> C: +1.250.689.0686
> E: ga...@lockyer.ca 
> 
> 
>> On Apr 15, 2021, at 14:10, weerman > > wrote:
>> 
>> Hi,
>> 
>> The missing ' wasn't the problem, i forgot to add it in the post.
>> I tried to remove the comments at the end of server and path, but still no 
>> success
>> 
>> Again, here's my copy of FTP section of weewx.conf. 
>> 
>> Edit: Tried again changing the prefix to http but no success. 
>> 
>> [[FTP]]
>> # FTP'ing the results to a webserver is treated as just another 
>> report,
>> # albeit one with an unusual report generator!
>> skin = Ftp
>> 
>> # If you wish to use FTP, set "enable" to "true", then
>> # fill out the next four lines.
>> # Use quotes around passwords to guard against parsing errors.
>> enable = true
>> user = webxx
>> password = ''
>> server = http://webxx.rex14.flatbooster.com 
>> 
>> path = /html/weewx
>> 
>> # Set to True for an FTP over TLS (FTPS) connection. Not all servers
>> # support this.
>> secure_ftp = true
>> 
>> # To upload files from something other than what HTML_ROOT is set
>> # to above, specify a different HTML_ROOT here.
>> #HTML_ROOT = public_html
>> 
>> # Most FTP servers use port 21
>> port = 21
>> 
>> # Set to 1 to use passive mode, zero for active mode
>> passive = 1
>> 
>> 
>> Here's my weewx error log file
>> 
>> Apr 15 21:01:13 raspberrypi systemd[1]: Starting LSB: weewx weather system...
>> Apr 15 21:01:13 raspberrypi weewx[15101] INFO __main__: Initializing weewx 
>> version 4.5.1
>> Apr 15 21:01:13 raspberrypi weewx[15101] INFO __main__: Using Python 3.5.3 
>> (default, Jan 19 2017, 14:11:04) #012[GCC 6.3.0 20170124]
>> Apr 15 21:01:13 raspberrypi weewx[15101] INFO __main__: Platform 
>> Linux-4.9.41-v7+-armv7l-with-debian-9.1
>> Apr 15 21:01:13 raspberrypi weewx[15101] INFO __main__: Locale is 
>> 'de_DE.UTF-8'
>> Apr 15 21:01:13 raspberrypi weewx[15101] INFO __main__: PID file is 
>> /var/run/weewx.pid
>> Apr 15 21:01:13 raspberrypi weewx[15105] INFO __main__: Using configuration 
>> file /home/weewx/weewx.conf
>> Apr 15 21:01:13 raspberrypi weewx[15105] INFO __main__: Debug is 0
>> Apr 15 21:01:14 raspberrypi weewx[15105] INFO weewx.engine: Loading station 
>> type FineOffsetUSB (weewx.drivers.fousb)
>> Apr 15 21:01:14 raspberrypi weewx[15090]: Starting weewx weather system: 
>> weewx.
>> Apr 15 21:01:14 raspberrypi systemd[1]: Started LSB: weewx weather system.
>> Apr 15 21:01:14 raspberrypi weewx[15105] INFO weewx.drivers.fousb: driver 
>> version is 1.20
>> Apr 15 21:01:14 raspberrypi weewx[15105] INFO weewx.drivers.fousb: polling 
>> mode is PERIODIC
>> Apr 15 21:01:14 raspberrypi weewx[15105] INFO weewx.drivers.fousb: polling 
>> interval is 60
>> Apr 15 21:01:14 raspberrypi weewx[15105] INFO weewx.drivers.fousb: found 
>> station on USB bus= device=
>> Apr 15 21:01:14 raspberrypi weewx[15105] INFO weewx.engine: StdConvert 
>> target unit is 0x1
>> Apr 15 21:01:14 raspberrypi weewx[15105] INFO weewx.engine: Archive will use 
>> data binding wx_binding
>> Apr 15 21:01:14 raspberrypi weewx[15105] INFO weewx.engine: Record 
>> generation will be attempted in 'software'
>> Apr 15 21:01:14 raspberrypi weewx[15105] INFO weewx.engine: Using archive 
>> interval of 300 seconds (software record generation)
>> Apr 15 21:01:14 raspberrypi weewx[15105] INFO weewx.restx: StationRegistry: 
>> Station will be registered.
>> Apr 15 21:01:14 raspberrypi weewx[15105] INFO weewx.restx: Wunderground: 
>> Posting not enabled.
>> Apr 15 21:01:14 raspberrypi weewx[15105] INFO weewx.restx: PWSweather: 
>> Posting not enabled.
>> Apr 15 21:01:14 raspberrypi weewx[15105] INFO weewx.restx: CWOP: Posting not 
>> enabled.
>> Apr 15 21:01:14 raspberrypi weewx[15105] INFO weewx.restx: WOW: Posting not 
>> enabled.
>> Apr 15 21:01:14 raspberrypi weewx[15105] INFO weewx.restx: AWEKAS: Posting 
>> not enabled.
>> Apr 15 21:01:14 raspberrypi weewx[15105] INFO __main__: Starting up weewx 
>> version 4.5.1
>> Apr 15 21:01:14 raspberrypi weewx[15105] INFO weewx.engine: Using

Re: [weewx-user] MQTT for Belchertown skin

2021-03-27 Thread Les Niles

If you still have what you showed earlier

>>>>> [[Belchertown]]
>>>>>  [[[Extras]]]
>>>>> 
>>>>> mqtt_websockets_enabled = 1
>>>>> mqtt_websockets_host = gw.martenhinrichs.de 
>>>>> <http://gw.martenhinrichs.de/>
>>>>> mqtt_websockets_port = 9001
>>>>> mqtt_websockets_ssl = 1
>>>>> mqtt_websockets_topic = weather/loop

 
in your weewx.conf, that will override those variable settings in 
Belchertown/skin.conf.  Just put the IP address in weewx.conf in place of 
gw.martenhinrichs.de <http://gw.martenhinrichs.de/>.

There is an instance of mosquitto already running.  Probably time to reboot the 
pi. 

  -Les



> On 27 Mar 2021, at 17:43, Tom Hackett  wrote:
> 
> This is my Belchertown skin setup
> # MQTT Websockets defaults
> mqtt_websockets_enabled = 0
> mqtt_websockets_host = "192.168.1.170"
> mqtt_websockets_port = 9001
> mqtt_websockets_ssl = 0
> mqtt_websockets_topic = "weather/loop"
> disconnect_live_website_visitor = 30
> 
> I tried sudo netstat -anp | grep 9001 and got 
> pi@raspberrypi:~ $ sudo netstat -anp | grep 9001
> tcp0  0 0.0.0.0:9001 <http://0.0.0.0:9001/>0.0.0.0:*  
>  LISTEN  27650/mosquitto 
> pi@raspberrypi:~ $ # MQTT Websockets defaults
> pi@raspberrypi:~ $ mqtt_websockets_enabled = 0
> bash: mqtt_websockets_enabled: command not found
> pi@raspberrypi:~ $ mqtt_websockets_host = "192.168.1.170"
> bash: mqtt_websockets_host: command not found
> pi@raspberrypi:~ $ mqtt_websockets_port = 9001
> bash: mqtt_websockets_port: command not found
> pi@raspberrypi:~ $ mqtt_websockets_ssl = 0
> bash: mqtt_websockets_ssl: command not found
> pi@raspberrypi:~ $     mqtt_websockets_topic = "weather/loop"
> bash: mqtt_websockets_topic: command not found
> pi@raspberrypi:~ $ disconnect_live_website_visitor = 30
> 
> I'll try tomorrow to find what is running.
> Thanks,Tom
> 
> On Sat, Mar 27, 2021 at 8:32 PM Les Niles  <mailto:l...@2pi.org>> wrote:
> Now it looks like something else is already running on port 9001.  Without 
> trying to start mosquitto, see what you get with
> sudo netstat -anp | grep 9001
> If you get something like “tcp0  0 0.0.0.0:9001 <http://0.0.0.0:9001/>
>  0.0.0.0:* LISTEN   9676/something” then there’s another instance of 
>  running on port 9001; that number right before the “/“ is the 
> process ID.  
> 
> If not, then undo the last change and see if the publishing at least works 
> again, because obviously I don’t know what I’m talking about.
> 
> BTW, once you get the publishing working again, if your web browser is 
> running on the same pi, or at least on the same 192.168.1 subnet, then for 
> testing purposes you could replace gw.martenhinrichs.de 
> <http://gw.martenhinrichs.de/> with the 192.168.1.170 IP address in the 
> [[Belchertown]][[[Extras]]] config; if that magically makes it work, then the 
> issue is related to your networking rather than the broker itself.   
> 
>   -Les
> 
> 
> 
>> On 27 Mar 2021, at 15:52, Tom Hackett > <mailto:tom06...@gmail.com>> wrote:
>> 
>> Thanks.
>> I took out those lines. Since everything is running on same pi I figured I 
>> wouldn't need any special networking.
>> I'm now getting a connection refused.
>> Mosquitto.log:
>> 1616884948: mosquitto version 1.5.7 starting
>> 1616884948: Config loaded from /etc/mosquitto/mosquitto.conf.
>> 1616884948: Opening ipv4 listen socket on port 1883.
>> 1616884948: Opening ipv6 listen socket on port 1883.
>> 1616884948: Opening websockets listen socket on port 9001.
>> 1616884948: Error: Unable to create websockets listener on port 9001.
>> 1616884948: mosquitto version 1.5.7 starting
>> 1616884948: Config loaded from /etc/mosquitto/mosquitto.conf.
>> 1616884948: Opening ipv4 listen socket on port 1883.
>> 1616884948: Opening ipv6 listen socket on port 1883.
>> 1616884948: Opening websockets listen socket on port 9001.
>> 1616884948: Error: Unable to create websockets listener on port 9001.
>> 
>> syslog:
>> Mar 27 18:43:52 raspberrypi weewx[8242] ERROR weewx.restx: MQTT: Failed to 
>> publish record 2021-03-27 18:02:56 EDT (1616882576): Failed upload after 3 
>> tries
>> Mar 27 18:43:52 raspberrypi weewx[8242] DEBUG user.mqtt: Failed upload 
>> attempt 1: [Errno 111] Connection refused
>> Mar 27 18:43:57 raspberrypi weewx[8242] DEBUG user.mqtt: Failed upload 
>> attempt 2: [Err

Re: [weewx-user] MQTT for Belchertown skin

2021-03-27 Thread Les Niles

Now it looks like something else is already running on port 9001.  Without 
trying to start mosquitto, see what you get with
sudo netstat -anp | grep 9001
If you get something like “tcp0  0 0.0.0.0:9001 0.0.0.0:* LISTEN   
9676/something” then there’s another instance of  running on port 
9001; that number right before the “/“ is the process ID.  

If not, then undo the last change and see if the publishing at least works 
again, because obviously I don’t know what I’m talking about.

BTW, once you get the publishing working again, if your web browser is running 
on the same pi, or at least on the same 192.168.1 subnet, then for testing 
purposes you could replace gw.martenhinrichs.de <http://gw.martenhinrichs.de/> 
with the 192.168.1.170 IP address in the [[Belchertown]][[[Extras]]] config; if 
that magically makes it work, then the issue is related to your networking 
rather than the broker itself.   

  -Les



> On 27 Mar 2021, at 15:52, Tom Hackett  wrote:
> 
> Thanks.
> I took out those lines. Since everything is running on same pi I figured I 
> wouldn't need any special networking.
> I'm now getting a connection refused.
> Mosquitto.log:
> 1616884948: mosquitto version 1.5.7 starting
> 1616884948: Config loaded from /etc/mosquitto/mosquitto.conf.
> 1616884948: Opening ipv4 listen socket on port 1883.
> 1616884948: Opening ipv6 listen socket on port 1883.
> 1616884948: Opening websockets listen socket on port 9001.
> 1616884948: Error: Unable to create websockets listener on port 9001.
> 1616884948: mosquitto version 1.5.7 starting
> 1616884948: Config loaded from /etc/mosquitto/mosquitto.conf.
> 1616884948: Opening ipv4 listen socket on port 1883.
> 1616884948: Opening ipv6 listen socket on port 1883.
> 1616884948: Opening websockets listen socket on port 9001.
> 1616884948: Error: Unable to create websockets listener on port 9001.
> 
> syslog:
> Mar 27 18:43:52 raspberrypi weewx[8242] ERROR weewx.restx: MQTT: Failed to 
> publish record 2021-03-27 18:02:56 EDT (1616882576): Failed upload after 3 
> tries
> Mar 27 18:43:52 raspberrypi weewx[8242] DEBUG user.mqtt: Failed upload 
> attempt 1: [Errno 111] Connection refused
> Mar 27 18:43:57 raspberrypi weewx[8242] DEBUG user.mqtt: Failed upload 
> attempt 2: [Errno 111] Connection refused
> Mar 27 18:44:00 raspberrypi weewx[8242] DEBUG user.gw1000: Next update in 20 
> seconds
> Mar 27 18:44:02 raspberrypi weewx[8242] DEBUG user.mqtt: Failed upload 
> attempt 3: [Errno 111] Connection refused
> Mar 27 18:44:04 raspberrypi weewx[8242] DEBUG user.gw1000: Next update in 20 
> seconds
> Mar 27 18:44:07 raspberrypi weewx[8242] ERROR weewx.restx: MQTT: Failed to 
> publish record 2021-03-27 18:02:59 EDT (1616882579): Failed upload after 3 
> tries
> Mar 27 18:44:07 raspberrypi weewx[8242] DEBUG user.mqtt: Failed upload 
> attempt 1: [Errno 111] Connection refused
> Mar 27 18:44:12 raspberrypi weewx[8242] DEBUG user.mqtt: Failed upload 
> attempt 2: [Errno 111] Connection refused
> Mar 27 18:44:17 raspberrypi weewx[8242] DEBUG user.mqtt: Failed upload 
> attempt 3: [Errno 111] Connection refused
> Mar 27 18:44:21 raspberrypi weewx[8242] DEBUG user.gw1000: Next update in 20 
> seconds
> 
> When I run systemctl status mosquitto.service I get 
> mosquitto.service - Mosquitto MQTT v3.1/v3.1.1 Broker
>Loaded: loaded (/lib/systemd/system/mosquitto.service; enabled; vendor 
> preset: enabled)
>Active: failed (Result: exit-code) since Sat 2021-03-27 18:42:29 EDT; 8min 
> ago
>  Docs: man:mosquitto.conf(5)
>man:mosquitto(8)
>   Process: 20719 ExecStart=/usr/sbin/mosquitto -c 
> /etc/mosquitto/mosquitto.conf (code=exited, status=1/FAILURE)
>  Main PID: 20719 (code=exited, status=1/FAILURE)
> 
> Mar 27 18:42:29 raspberrypi systemd[1]: mosquitto.service: Service 
> RestartSec=100ms expired, scheduling restart.
> Mar 27 18:42:29 raspberrypi systemd[1]: mosquitto.service: Scheduled restart 
> job, restart counter is at 5.
> Mar 27 18:42:29 raspberrypi systemd[1]: Stopped Mosquitto MQTT v3.1/v3.1.1 
> Broker.
> Mar 27 18:42:29 raspberrypi systemd[1]: mosquitto.service: Start request 
> repeated too quickly.
> Mar 27 18:42:29 raspberrypi systemd[1]: mosquitto.service: Failed with result 
> 'exit-code'.
> Mar 27 18:42:29 raspberrypi systemd[1]: Failed to start Mosquitto MQTT 
> v3.1/v3.1.1 Broker.
> 
> I seemed to have gone backwards today.
> 
> 
> 
> On Sat, Mar 27, 2021 at 6:35 PM Les Niles  <mailto:l...@2pi.org>> wrote:
> The only odd thing I see now are the certfile, cafile, and keyfile lines 
> under the websockets listener — that may be turning on SSL for websockets.  
> You can just delete those lines (along with the second “protocol 
> websockets”).  
> 
> And confirm tha

Re: [weewx-user] MQTT for Belchertown skin

2021-03-27 Thread Les Niles

The only odd thing I see now are the certfile, cafile, and keyfile lines under 
the websockets listener — that may be turning on SSL for websockets.  You can 
just delete those lines (along with the second “protocol websockets”).  

And confirm that you’ve restarted mosquitto, so the conf changes will take 
effect?

The other potential issue is network topology & routing.  gw.martenhinrichs.de 
<http://gw.martenhinrichs.de/> presumably points to the mosquitto server’s 
internal IP 192.168.1.170.  Does that address translation work for connecting 
from wherever your web browser is running?  I had to do some config on my 
router to make the “hairpin” connection work. 

  -Les



> On 27 Mar 2021, at 12:52, Tom Hackett  wrote:
> 
> /etc/mosquitto/mosquitto.conf:
> # Place your local configuration in /etc/mosquitto/conf.d/
> #
> # A full description of the configuration file is at
> # /usr/share/doc/mosquitto/examples/mosquitto.conf.example
> 
> #pid_file /var/run/mosquitto.pid
> 
> 
> persistence true
> persistence_location /var/lib/mosquitto/
> 
> log_dest file /var/log/mosquitto/mosquitto.log
> 
> include_dir /etc/mosquitto/conf.d
> 
> /etc/mosquitto/conf.d/mosquitto.conf:
> # Place your local configuration in /etc/mosquitto/conf.d/
> #
> # A full description of the configuration file is at
> # /usr/share/doc/mosquitto/examples/mosquitto.conf.example
> 
> pid_file /var/run/mosquitto.pid
> 
> #persistence false
> allow_anonymous true
> password_file /etc/mosquitto/passwd
> acl_file /etc/mosquitto/acl
> # Insecure mqtt to localhost only, and secure mqtt
> listener 1883 localhost
> listener 8883
> certfile /etc/mosquitto/certs/cert.pem
> cafile /etc/mosquitto/certs/chain.pem
> keyfile /etc/mosquitto/certs/privkey.pem
> protocol mqtt
> # websockets
> listener 9001
> protocol websockets
> certfile /etc/mosquitto/certs/cert.pem
> cafile /etc/mosquitto/certs/chain.pem
> keyfile /etc/mosquitto/certs/privkey.pem
> protocol websockets
> 
> #persistence_location /var/lib/mosquitto/
> 
> log_dest file /var/log/mosquitto/mosquitto.log
> 
> The acl:
> # Allow anonymous access to the sys
> topic read $SYS/#
> 
> # Allow anonymous to read weather
> topic read weather/#
> 
> # weewx readwrite to the loop
> user 
> topic weather/#
> 
> Here is part of mosquitto log:
> 1616874562: New connection from 192.168.1.170 on port 1883.
> 1616874562: New client connected from 192.168.1.170 as weewx_4b8e89f4 (c1, 
> k60, u'tph06784').
> 1616874562: Client weewx_4b8e89f4 disconnected.
> 1616874563: New connection from 192.168.1.170 on port 1883.
> 1616874563: New client connected from 192.168.1.170 as weewx_17c9704e (c1, 
> k60, u'tph06784').
> 1616874563: Client weewx_17c9704e disconnected.
> 1616874565: New connection from 192.168.1.170 on port 1883.
> 1616874565: New client connected from 192.168.1.170 as weewx_3ad70f87 (c1, 
> k60, u'tph06784').
> 1616874565: Client weewx_3ad70f87 disconnected.
> 1616874583: New connection from 192.168.1.170 on port 1883.
> 1616874583: New client connected from 192.168.1.170 as weewx_4d17e0e9 (c1, 
> k60, u'tph06784').
> 1616874584: Client weewx_4d17e0e9 disconnected.
> 1616874585: New connection from 192.168.1.170 on port 1883.
> 1616874585: New client connected from 192.168.1.170 as weewx_aa8f33c8 (c1, 
> k60, u'tph06784').
> 1616874585: Client weewx_aa8f33c8 disconnected.
> 1616874603: New connection from 192.168.1.170 on port 1883.
> 1616874603: New client connected from 192.168.1.170 as weewx_76212562 (c1, 
> k60, u'tph06784').
> 1616874603: Client weewx_76212562 disconnected.
> 1616874605: New connection from 192.168.1.170 on port 1883.
> 
> Thanks for taking the time to look at this.
> Tom
> 
> On Sat, Mar 27, 2021 at 3:06 PM Les Niles  <mailto:l...@2pi.org>> wrote:
> The include_dir line in mosquitto.conf is commented out, so the stuff in 
> /etc/mosquitto/conf.d/mosquitto.conf never gets picked up.  Remove the “#” at 
> the beginning of the line. Also, remove the include_dir line in 
> /etc/mosquitto/conf.d/mosquitto.conf to avoid a potentially infinite 
> recursion. 
> 
> Please post your acl_file (should be /etc/mosquitto/acl).  It should have a 
> line like
> topic read weather/#
> near the top, to enable anonymous read access.
> 
> What are you seeing in the mosquitto log?
> 
>   -Les
> 
> 
> 
>> On 27 Mar 2021, at 11:41, Tom Hackett > <mailto:tom06...@gmail.com>> wrote:
>> 
>> I believe SSL is off. I have mqtt_websockets_ssl = 0 in my skin.conf
>> My mqtt (mosquito) config file is in /etc/mosquitto/mosquitto.conf is
>> # Place your local configuration in /etc/mosquitto/conf.d/
>> #
>> # A

Re: [weewx-user] MQTT for Belchertown skin

2021-03-27 Thread Les Niles

The include_dir line in mosquitto.conf is commented out, so the stuff in 
/etc/mosquitto/conf.d/mosquitto.conf never gets picked up.  Remove the “#” at 
the beginning of the line. Also, remove the include_dir line in 
/etc/mosquitto/conf.d/mosquitto.conf to avoid a potentially infinite recursion. 

Please post your acl_file (should be /etc/mosquitto/acl).  It should have a 
line like
topic read weather/#
near the top, to enable anonymous read access.

What are you seeing in the mosquitto log?

  -Les



> On 27 Mar 2021, at 11:41, Tom Hackett  wrote:
> 
> I believe SSL is off. I have mqtt_websockets_ssl = 0 in my skin.conf
> My mqtt (mosquito) config file is in /etc/mosquitto/mosquitto.conf is
> # Place your local configuration in /etc/mosquitto/conf.d/
> #
> # A full description of the configuration file is at
> # /usr/share/doc/mosquitto/examples/mosquitto.conf.example
> 
> pid_file /var/run/mosquitto.pid
> 
> persistence true
> persistence_location /var/lib/mosquitto/
> 
> log_dest file /var/log/mosquitto/mosquitto.log
> 
> #include_dir /etc/mosquitto/conf.d
> 
> There is also in /etc/mosquitto/conf.d/mosquitto.conf
> # Place your local configuration in /etc/mosquitto/conf.d/
> #
> # A full description of the configuration file is at
> # /usr/share/doc/mosquitto/examples/mosquitto.conf.example
> 
> #pid_file /var/run/mosquitto.pid
> 
> persistence false
> allow_anonymous true
> password_file /etc/mosquitto/passwd
> acl_file /etc/mosquitto/acl
> # Insecure mqtt to localhost only, and secure mqtt
> listener 1883 localhost
> listener 8883
> certfile /etc/mosquitto/certs/cert.pem
> cafile /etc/mosquitto/certs/chain.pem
> keyfile /etc/mosquitto/certs/privkey.pem
> protocol mqtt
> # websockets
> listener 9001
> certfile /etc/mosquitto/certs/cert.pem
> cafile /etc/mosquitto/certs/chain.pem
> keyfile /etc/mosquitto/certs/privkey.pem
> protocol websockets
> 
> #persistence_location /var/lib/mosquitto/
> 
> log_dest file /var/log/mosquitto/mosquitto.log
> 
> include_dir /etc/mosquitto/conf.d
> 
> Tom
> 
> On Sat, Mar 27, 2021 at 2:30 PM Les Niles  <mailto:l...@2pi.org>> wrote:
> It looks like weewx is sending updates to the mqtt server.  But the web 
> browser isn’t connecting to the mqtt server to retrieve those updates.  
> Please post your mqtt (mosquito) config file — you need to have websockets 
> enabled there, on port 9001.  
> 
> My suggestion is to turn off SSL on the websockets connection. If you’re not 
> doing authentication on the websockets log-in — usually it’s just set up as 
> read-only but publicly-available — then I don’t see much use for encrypting 
> the connection.  At any rate, turn off SSL until you get everything working 
> without it.
> 
>   -Les
> 
> 
> 
>> On 27 Mar 2021, at 9:46, Tom Hackett > <mailto:tom06...@gmail.com>> wrote:
>> 
>> This is the mosquitto log since the change
>> 1616862009: New connection from 192.168.1.170 on port 1883.
>> 1616862009: New client connected from 192.168.1.170 as weewx_94c44d84 (c1, 
>> k60, u'tph06784').
>> 1616862009: Client weewx_94c44d84 disconnected.
>> 1616862028: New connection from 192.168.1.170 on port 1883.
>> 1616862028: New client connected from 192.168.1.170 as weewx_61789889 (c1, 
>> k60, u'tph06784').
>> 1616862028: Client weewx_61789889 disconnected.
>> 1616862030: New connection from 192.168.1.170 on port 1883.
>> 1616862030: New client connected from 192.168.1.170 as weewx_28e94234 (c1, 
>> k60, u'tph06784').
>> 1616862030: Client weewx_28e94234 disconnected.
>> 1616862048: New connection from 192.168.1.170 on port 1883.
>> 1616862048: New client connected from 192.168.1.170 as weewx_38f31fdb (c1, 
>> k60, u'tph06784').
>> 1616862048: Client weewx_38f31fdb disconnected.
>> 
>> On Sat, Mar 27, 2021 at 12:42 PM Tom Hackett > <mailto:tom06...@gmail.com>> wrote:
>> I have changed MQTT to
>> [[MQTT]]
>> server_url = mqtt://tph06784:0350@192.168.1.170:1883 
>> <http://tph06784:0350@192.168.1.170:1883/>
>> topic = weather
>> unit_system = US
>> binding = archive, loop
>> aggregation = aggregate
>> log_success = true1883
>> 
>> No change
>> 
>> On Sat, Mar 27, 2021 at 11:51 AM vince > <mailto:vinceska...@gmail.com>> wrote:
>> > server_url = mqtt://tph06784:@localhost:1883 <>
>> 
>> This is becoming a FAQ.
>> 
>> Do not use 'localhost'.  Use the fully qualified domain name of the MQTT 
>> broker host or its IP address.
>> 
>> On Saturday, March 27, 2021 at 8:47:11 AM UTC-7 m

Re: [weewx-user] MQTT for Belchertown skin

2021-03-27 Thread Les Niles

It looks like weewx is sending updates to the mqtt server.  But the web browser 
isn’t connecting to the mqtt server to retrieve those updates.  Please post 
your mqtt (mosquito) config file — you need to have websockets enabled there, 
on port 9001.  

My suggestion is to turn off SSL on the websockets connection. If you’re not 
doing authentication on the websockets log-in — usually it’s just set up as 
read-only but publicly-available — then I don’t see much use for encrypting the 
connection.  At any rate, turn off SSL until you get everything working without 
it.

  -Les



> On 27 Mar 2021, at 9:46, Tom Hackett  wrote:
> 
> This is the mosquitto log since the change
> 1616862009: New connection from 192.168.1.170 on port 1883.
> 1616862009: New client connected from 192.168.1.170 as weewx_94c44d84 (c1, 
> k60, u'tph06784').
> 1616862009: Client weewx_94c44d84 disconnected.
> 1616862028: New connection from 192.168.1.170 on port 1883.
> 1616862028: New client connected from 192.168.1.170 as weewx_61789889 (c1, 
> k60, u'tph06784').
> 1616862028: Client weewx_61789889 disconnected.
> 1616862030: New connection from 192.168.1.170 on port 1883.
> 1616862030: New client connected from 192.168.1.170 as weewx_28e94234 (c1, 
> k60, u'tph06784').
> 1616862030: Client weewx_28e94234 disconnected.
> 1616862048: New connection from 192.168.1.170 on port 1883.
> 1616862048: New client connected from 192.168.1.170 as weewx_38f31fdb (c1, 
> k60, u'tph06784').
> 1616862048: Client weewx_38f31fdb disconnected.
> 
> On Sat, Mar 27, 2021 at 12:42 PM Tom Hackett  > wrote:
> I have changed MQTT to
> [[MQTT]]
> server_url = mqtt://tph06784:0350@192.168.1.170:1883 
> 
> topic = weather
> unit_system = US
> binding = archive, loop
> aggregation = aggregate
> log_success = true1883
> 
> No change
> 
> On Sat, Mar 27, 2021 at 11:51 AM vince  > wrote:
> > server_url = mqtt://tph06784:@localhost:1883
> 
> This is becoming a FAQ.
> 
> Do not use 'localhost'.  Use the fully qualified domain name of the MQTT 
> broker host or its IP address.
> 
> On Saturday, March 27, 2021 at 8:47:11 AM UTC-7 mh081...@gmail.com 
>  wrote:
> Hi,
> 
> if you will that mqtt working from ootside of your website you must config 
> public dns names . 
> 
> example from mx site
> 
> weewx.conf
> 
> [[MQTT]]
> server_url = mqtt://pi:pass...@gw.martenhinrichs.de:8883/ 
> 
> topic = weather
> unit_system = METRIC
> binding = archive, loop
> aggregation = aggregate
> log_success = False
> log_failure = True
> [[[tls]]]
> tls_version = tlsv12
> ca_certs = /etc/ssl/certs/ca-certificates.crt
> [[[inputs]]]
> dayRain
> name = dayRain_mm
> units = mm
> rainRate
> name = rainRate_mm_per_hour
> units = mm_per_hour
> 
> [[Belchertown]]
>  [[[Extras]]]
> 
> mqtt_websockets_enabled = 1
> mqtt_websockets_host = gw.martenhinrichs.de 
> 
> mqtt_websockets_port = 9001
> mqtt_websockets_ssl = 1
> mqtt_websockets_topic = weather/loop
> 
> 
> Only difference i use ssl and metric
> 
> 
> 
> tom0...@gmail.com <> schrieb am Samstag, 27. März 2021 um 15:33:58 UTC+1:
> Site only says Connecting to weather station real time data and no updates 
> are happening.
> 
> On Sat, Mar 27, 2021 at 10:25 AM Graham Eddy > wrote:
> what’s not working?
> 
>> On 28 Mar 2021, at 12:33 am, Tom Hackett > wrote:
>> 
>> I just can't figure this out.
> 
> 
> -- 
> 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 <>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/7A79B922-E098-48AE-A46C-3A128A3F9D90%40gmail.com
>  
> .
> 
> 
> -- 
> http://www.shermanctweather.org/wxgraphic.php?type=banner_big 
> https://www.shermanctweather.org/wxgraphic.php?type=banner_big
>  
> https://www.shermanctweather.org/wxgraphic.php?type=banner_big
>  
> https://www.shermanctweather.org/wxgraphic.php?type=banner_big
>  
> http://www.shermanctweather.org/wxgraphic.php?type=banner_big
>

Re: [weewx-user] Skin with webcam?

2021-03-25 Thread Les Niles

Belchertown isn’t exactly pre-loaded, but it is well integrated and the install 
is straightforward.  It has a radar feed. It doesn’t have the webcam built in, 
but It has several places to insert user-defined content and it would be easy 
to put a webcam in one of them.  I hacked it a little to put the webcam in 
place of the current-conditions icon: http://www.2pi.org/wx/ 


  -Les


> On 24 Mar 2021, at 20:53, 'super zee' via weewx-user 
>  wrote:
> 
> Brand new here and still learning.  Got Weewx loaded and it's uploading to 
> CWOP and my web page.  Is there a skin preloaded with WeeWX that can 
> accommodate a web cam and live radar feed?  
> 
> Thanks for the help!
> Chris 
> KAZTEMPE47
> 
> -- 
> 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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/58b570f6-ba28-4b46-bbdf-dcc9447d36a5n%40googlegroups.com
>  
> .

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/567689C8-9593-4479-8037-9780D22563DB%402pi.org.

Re: [weewx-user] tag date and time of the last rain

2021-03-22 Thread Les Niles

Now that’s a name I've not heard in a long time.  I remember the story well, 
but had forgotten the title.  Thanks for the pointer!

The other one that comes to mind in these kinds of conditions is “Sometimes a 
Great Notion.”  A much longer read, but well worth it. 

  -Les

> On 22 Mar 2021, at 16:16, D R  wrote:
> 
> I'm reminded of Ray Bradbury's wonderful and chilling short story, "All 
> Summer in a Day."
> 
> Free online and a quick read.  I still get shivers when I think of it.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/5BCBBCAF-97A5-4829-8609-9BD2D65AD561%402pi.org.

Re: [weewx-user] Problems with Weewx writing MQTT Broker

2021-03-21 Thread Les Niles

It’s happened before.  That’s a hard one to spot, given the visual similarity 
“8” and “3”.  

  -Les



> On 21 Mar 2021, at 15:12, Dun Mac  wrote:
> 
> Thank you, a really dumb mistake on my part. System updating. Issue Resolved
> 
> Duncan
> 
> On Monday, March 22, 2021 at 3:25:06 AM UTC+11 ln77 wrote:
> There's a typo in server_url: the port should be 1883, not 1833.  
> 
>   -Les
> 
> 
> On Saturday, March 20, 2021 at 11:30:35 PM UTC-7 Dun Mac wrote:
> I have been trying for a week to get the live updates to work for Weewx. But 
> I am not having any luck at all, so can someone please help if they can see 
> where my setup is wrong. For background info: Weewx is running on an RPi 4B 
> 192.168.8.155. I have set up an RPi 3A as the MQTT Broker 192.168.8.158. The 
> "service weewx status" shows the following:
> 
>  Mar 21 12:40:23 RPi-weather python3[2185]: weewx[2185] ERROR weewx.restx: 
> MQTT: Failed to publish record 2021-03-21 11
> 
>  The Belchertown page shows:
> 
> "Connected. Waiting for data. Last Updated 21 March 2021 yada yada"
> 
> My Weewx.conf setup is as follows:
> 
>  
> 188 [[MQTT]]
> 189 server_url = mqtt://vantagepro:xxx...@192.168.8.158:1833/ 
> 
> 190 topic = weather
> 191 unit_system = METRIC
> 192 binding = archive,loop
> 193 aggregation = aggregate
> 
> 248 [[Belchertown]]
> 249 skin = Belchertown
> 250 HTML_ROOT = /var/www/html
> 251
> 
>  [[Services]]
> 669  
> 674 restful_services = weewx.restx.StdStationRegistry,.., 
> user.mqtt.MQTT
> 
>  
> I have not set up SSL on the Broker, hence it is disabled.   
> /etc/weewx/skins/Belchertown/skin.conf is as follows:
> 
> 
> 35 # MQTT Websockets 
> 36 mqtt_websockets_enabled = 1
> 37 mqtt_websockets_host = 192.168.8.158
> 38 mqtt_websockets_port = 9001
> 39 mqtt_websockets_ssl = 0
> 40 mqtt_websockets_topic = weather/loop
> 41 disconnect_live_website_visitor = 180
> 
>  
> The MQTT (192.168.8.158) broker.conf is:
> 
>   6 pid_file /run/mosquitto/mosquitto.pid
>  7
>  8 persistence true
>  9 persistence_location /var/lib/mosquitto/
> 10
> 11 log_dest file /var/log/mosquitto/mosquitto.log
> 12
> 13 log_type all
> 14 log_facility 5
> 15 log_type error
> 16 log_type warning
> 17 log_type notice
> 18 log_type information
> 19
> 20 connection_messages true
> 21 log_timestamp true
> 22
> 23 include_dir /etc/mosquitto/conf.d
> 
> and the Broker/conf.d/myconfig.conf
> 
> # mqtt
> listener 1883
> protocol mqtt
> 
> # websockets
> listener 9001
> protocol websockets
> 
> #Allow anonymous to read only and others need to be set in passwd,acl
> allow_anonymous true
> password_file /etc/mosquitto/passwd
> acl_file /etc/mosquitto/acl
> 
>  
> The Broker Pub/Sub is working with and without passwords, using terminals in 
> Weewx RPi (192.168.8.155).
> 
> The Mosquitto client on the Weewx machine (192.168.8.155) has no 
> configuration file
> 
>  
> I know I have something wrong but I just have no idea.
> 
>  
> 
> 
> -- 
> 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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/1db3be70-7147-4d7e-95f5-fe5928d1016dn%40googlegroups.com
>  
> .

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/26AA92D5-CC69-4C97-ABFF-56683DC45906%402pi.org.

Re: [weewx-user] MQTT error connection with Bekchertown skin

2021-03-18 Thread Les Niles

Comparing your configuration to mine, I think you should be publishing to 
“weather” rather than “weather/loop”  That is, in the [[MQTT]] section, set 
“topic = weather” instead of “topic = weather/loop".  Leave the 
"mqtt_websockets_topic = weather/loop” in [[Belchertown]][[[Extras]]] as-is. 

By the way, I found mosquitto_pub and mosquitto_sub (from the mosquitto-clients 
package) to be very useful for debugging MQTT issues. 

  -Les



> On 17 Mar 2021, at 2:36, Carlo  wrote:
> 
> I revome the “[[[tls]]]” section from weewx.conf and now the error disappear:
> 
> 
> INFO weewx.restx: MQTT: Published record 2021-03-17 10:29:15 CET (1615973355)
> 
> 
> but it doesn't work, always in "waiting data from the sation"
> 
> this is the log of mosquitto.conf
> ---
> 1615973513: mosquitto version 1.6.9 starting
> 1615973513: Config loaded from /etc/mosquitto/mosquitto.conf.
> 1615973513: Opening ipv4 listen socket on port 1883.
> 1615973513: Opening ipv4 listen socket on port 8883.
> 1615973513: Opening ipv6 listen socket on port 8883.
> 1615973513: Opening websockets listen socket on port 9001.
> 1615973518: New connection from 127.0.0.1 on port 1883.
> 1615973518: New client connected from 127.0.0.1 as MQTTSubscribe-5787 (p2, 
> c1, k60, u'carlo').
> 1615973536: New client connected from :::X.X.X.X as website502959092 (p2, 
> c1, k60).
> 1615973539: New connection from 127.0.0.1 on port 1883.
> 1615973539: New client connected from 127.0.0.1 as weewx_1f2ccce3 (p2, c1, 
> k60, u'carlo').
> 1615973539: Client weewx_1f2ccce3 disconnected.
> 1615973558: Socket error on client website502959092, disconnecting.
> --
> 
> Thanks
> Carlo
> Il giorno mercoledì 17 marzo 2021 alle 05:11:00 UTC+1 ln77 ha scritto:
> I’ll make a wild guess and hypothesize that the problem is that the weewx 
> MQTT module is trying to speak TLS to the broker on port 1883 rather than 
> 8883.  I would start by getting MQTT working without TLS — just remove the 
> “[[[tls]]]” section from weewx.conf.  Once that is working you can add TLS 
> back, but usually there’s no advantage to encrypting network traffic to 
> localhost.   
> 
>   -Les
> 
> 
> 
>> On 16 Mar 2021, at 10:56, Carlo > > wrote:
>> 
> 
>> Hi everyone. I have a problem with the MQTT Broker on my localhost server.
>> My website (meteopievedicampo.ddns.net ) 
>> work good, but i wanto to enable MQTT.
>> I open on my firewall the 9001 port.
>> 
>> I have this error in mosquitto log:
>> ---
>> 1615760009: New connection from 127.0.0.1 on port 1883.
>> 1615760009: Client  disconnected due to protocol error.
>> 1615760060: New client connected from :::192.168.1.2 as website557173374 
>> (p2, c1, k60).
>> 1615760060: New connection from 127.0.0.1 on port 1883.
>> 1615760060: Client  disconnected due to protocol error
>> -
>> 
>> and this is syslog:
>> -
>> DEBUG user.mqtt: Failed upload attempt 3: [Errno 104] Connessione interrotta 
>> dal corrispondente
>> ERROR weewx.restx: MQTT: Failed to publish record 2021-03-14 23:18:23 CET 
>> (1615760303): Failed upload after 3 tries
>> -
>> 
>> This is my weewx.conf:
>> 
>> -
>> [[MQTT]]
>> server_url = mqtt://carlo:X@localhost:1883/ <>
>> topic = weather/loop
>> unit_system = METRIC
>> binding = archive, loop
>> aggregation = aggregate
>>  [[[tls]]]
>> tls_version = tlsv12
>> ca_certs = /etc/mosquitto/certs/chain.pem
>> 
>>  # MQTT Websockets defaults
>> mqtt_websockets_enabled = 1
>> mqtt_websockets_host = meteopievedicampo.ddns.net 
>> 
>> mqtt_websockets_port = 9001
>> mqtt_websockets_ssl = 1
>> mqtt_websockets_topic = weather/loop
>> disconnect_live_website_visitor = 180
>> 
>> [MQTTSubscribeService]
>> enable = true
>> host = localhost
>> port = 1883
>> keepalive = 60
>> username = carlo
>> password = XX
>> binding = loop
>> [[message_callback]]
>> type = json
>> [[topics]]
>> unit_system = METRIC
>> ---
>> 
>> And this is my

Re: [weewx-user] MQTT error connection with Bekchertown skin

2021-03-16 Thread Les Niles

I’ll make a wild guess and hypothesize that the problem is that the weewx MQTT 
module is trying to speak TLS to the broker on port 1883 rather than 8883.  I 
would start by getting MQTT working without TLS — just remove the “[[[tls]]]” 
section from weewx.conf.  Once that is working you can add TLS back, but 
usually there’s no advantage to encrypting network traffic to localhost.   

  -Les


> On 16 Mar 2021, at 10:56, Carlo  wrote:
> 
> Hi everyone. I have a problem with the MQTT Broker on my localhost server.
> My website (meteopievedicampo.ddns.net) work good, but i wanto to enable MQTT.
> I open on my firewall the 9001 port.
> 
> I have this error in mosquitto log:
> ---
> 1615760009: New connection from 127.0.0.1 on port 1883.
> 1615760009: Client  disconnected due to protocol error.
> 1615760060: New client connected from :::192.168.1.2 as website557173374 
> (p2, c1, k60).
> 1615760060: New connection from 127.0.0.1 on port 1883.
> 1615760060: Client  disconnected due to protocol error
> -
> 
> and this is syslog:
> -
> DEBUG user.mqtt: Failed upload attempt 3: [Errno 104] Connessione interrotta 
> dal corrispondente
> ERROR weewx.restx: MQTT: Failed to publish record 2021-03-14 23:18:23 CET 
> (1615760303): Failed upload after 3 tries
> -
> 
> This is my weewx.conf:
> 
> -
> [[MQTT]]
> server_url = mqtt://carlo:X@localhost:1883/
> topic = weather/loop
> unit_system = METRIC
> binding = archive, loop
> aggregation = aggregate
>  [[[tls]]]
> tls_version = tlsv12
> ca_certs = /etc/mosquitto/certs/chain.pem
> 
>  # MQTT Websockets defaults
> mqtt_websockets_enabled = 1
> mqtt_websockets_host = meteopievedicampo.ddns.net
> mqtt_websockets_port = 9001
> mqtt_websockets_ssl = 1
> mqtt_websockets_topic = weather/loop
> disconnect_live_website_visitor = 180
> 
> [MQTTSubscribeService]
> enable = true
> host = localhost
> port = 1883
> keepalive = 60
> username = carlo
> password = XX
> binding = loop
> [[message_callback]]
> type = json
> [[topics]]
> unit_system = METRIC
> ---
> 
> And this is my mosquitto.conf:
> 
> --
> persistence false
> allow_anonymous true
> password_file /etc/mosquitto/passwd
> acl_file /etc/mosquitto/acl
> # Insecure mqtt to localhost only, and secure mqtt
> listener 1883 localhost
> listener 8883
> certfile /etc/mosquitto/certs/cert.pem
> cafile /etc/mosquitto/certs/chain.pem
> keyfile /etc/mosquitto/certs/privkey.pem
> protocol mqtt
> # websockets
> listener 9001
> certfile /etc/mosquitto/certs/cert.pem
> cafile /etc/mosquitto/certs/chain.pem
> keyfile /etc/mosquitto/certs/privkey.pem
> protocol websockets
> --
> 
> Thanks everyone help me!
> Carlo
> 
> -- 
> 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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/bd2362e9-95fd-4d0b-9aa8-eb0abea25350n%40googlegroups.com
>  
> .

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/6224C3EC-947A-4F0C-BE51-7EA9B2B2453E%402pi.org.

Re: [weewx-user] Question on heat index

2021-03-14 Thread Les Niles

That would be the sensible thing to do.  But it’s a different algorithm, not 
just a change in the low-temperature limit.  The new algorithm is closer to 
Steadman’s original concept of giving a perceived temperature relative to an 
average humidity, so low humidities can result in a heat index that’s lower 
than the ambient temperature, which will never happen with the old algorithm.  

The other subtle difference is that my modification returns None when the 
temperature is below threshold, rather than returning a heat index equal to the 
temperature.  That means there are no abrupt jumps in the value as temperature 
changes slightly; the heat index just isn’t reported.  

  -Les



> On 13 Mar 2021, at 17:16, Pat O'Brien  wrote:
> 
> You don't have to modify any code, just change the calculation formula by 
> setting this option in weewx.conf
> 
> Look for the [StdWXCalculate] section, then beneath add
> 
> [[WXXTypes]]
> [[[heatindex]]]
> algorithm = old
> 
> That put it back to the "old" method for me where heat index is calculated 
> above 80F.
> 
> 
> 
> On Saturday, March 13, 2021 at 6:11:21 PM UTC-5 ln77 wrote:
> First, I misspoke — the change is in heatindexF(), not dewpointF() (duh!)
> In the weewx software directory (/usr/share/weewx when installed as a Debian 
> package), there is a file weewx/wxformulas.py.  Look for the line "if T is 
> None or R is None:” — it’s line 164 in the 4.4.0 version.  Add “ or T < 68”, 
> so that the line becomes “if T is None or R is None or T < 68:”  You could 
> change 68 to 80 or whatever you want the low-temperature threshold to be.  
> 
> WARNING: this is the wrong way to maintain weewx software.  The change will 
> get overwritten when weewx is updated.  There are better ways to implement 
> this, but that would’ve taken me more time than I wanted to spend so I’m OK 
> with the hack for my installation. But use at your own risk. 
> 
>   -Les
> 
> 
> 
> 
>> On 13 Mar 2021, at 14:03, n7uv...@gmail.com  
>> > 
>> wrote:
>> 
> 
>> Hi there Les - less than two days ago I updated my weewx from an older 4.xx 
>> version to the current one, and suddenly i was getting the same weird plot. 
>> Finally typed in "heat index wind chill" into the forum and out popped this 
>> thread. I want to feel better as well - where is the spot where you tweaked 
>> DewpointF()?
>> Cheers - Jon
>> 
>> On Friday, March 12, 2021 at 2:00:13 PM UTC-7 ln77 wrote:
>> It looks strange to see the heat index suddenly dropping a few degrees below 
>> the temperature when the temperature gets above 40ºF. (I just saw this this 
>> morning.) After looking through the thread on weewx’s new heat index 
>> calculation, I noticed an oddity at the National Weather Service: while 
>> their calculator calculates a heat index down to 40ºF, on the page where 
>> they describe the HI equation 
>>  they say the 
>> “Rothfusz regression is not valid for extreme temperature and relative 
>> humidity conditions beyond the range of data considered by Steadman.” 
>> Looking at Steadman’s sultriness papers from 1979 
>>   he 
>> never looked at temperatures below 68ºF. I couldn’t find any reference to 
>> indicate why they arbitrarily extended the javascript calculator down to 
>> 40ºF. Other authors, and the NWS tables, suggest that the heat index isn’t 
>> really of value below 80ºF.  
>> 
>> So I tweaked dewpointF() in my installation to return None if the 
>> temperature is below 68, and now I feel better.  
>> 
>>   -Les
>> 
>> 
>> 
>> 
>> 
>>> On 24 Feb 2021, at 12:54, gjr80 > wrote:
>>> 
>> 
>>> Pat,
>>> 
>>> v4.2.0 saw a new heatindex formula implemented, refer issue 601 
>>> . The new formula gives some 
>>> results in some circumstances that may appear counterintuitive. v4.3.0 
>>> added back the ‘old’ heatindex formula and gives the user the ability to 
>>> choose between the two algorithms . This is covered here 
>>>  in the 
>>> User’s Guide under [[[heatindex]]].
>>> 
>>> By the looks of it you are seeing the ‘new’ algorithm.
>>> 
>>> Gary
>>> 
>>> On Thursday, 25 February 2021 at 06:36:38 UTC+10 pobri...@gmail.com 
>>>  wrote:
>>> I thought heat index wasn't calculated unless the temperature was over 80F? 
>>> Today it's about 49 F and I'm seeing heat index in my charts (which is 
>>> reporting lower than temperature - I thought that was wind chill?). I don't 
>>> recall seeing it before at this temperature range. 
>>> 
>>> I just want to make sure this is expected for temperatures so low to have a 
>>> heat index reading?
>>> 
>>> Top graph is Seasons skin and bottom is Belchertown skin. The values match 
>>> across skins
>>> 
>> 
>>> -- 
>>> You received this message because you are subscribed to the Google

Re: [weewx-user] Question on heat index

2021-03-13 Thread Les Niles

First, I misspoke — the change is in heatindexF(), not dewpointF() (duh!)
In the weewx software directory (/usr/share/weewx when installed as a Debian 
package), there is a file weewx/wxformulas.py.  Look for the line "if T is None 
or R is None:” — it’s line 164 in the 4.4.0 version.  Add “ or T < 68”, so that 
the line becomes “if T is None or R is None or T < 68:”  You could change 68 to 
80 or whatever you want the low-temperature threshold to be.  

WARNING: this is the wrong way to maintain weewx software.  The change will get 
overwritten when weewx is updated.  There are better ways to implement this, 
but that would’ve taken me more time than I wanted to spend so I’m OK with the 
hack for my installation. But use at your own risk. 

  -Les



> On 13 Mar 2021, at 14:03, n7uv...@gmail.com  wrote:
> 
> Hi there Les - less than two days ago I updated my weewx from an older 4.xx 
> version to the current one, and suddenly i was getting the same weird plot. 
> Finally typed in "heat index wind chill" into the forum and out popped this 
> thread. I want to feel better as well - where is the spot where you tweaked 
> DewpointF()?
> Cheers - Jon
> 
> On Friday, March 12, 2021 at 2:00:13 PM UTC-7 ln77 wrote:
> It looks strange to see the heat index suddenly dropping a few degrees below 
> the temperature when the temperature gets above 40ºF. (I just saw this this 
> morning.) After looking through the thread on weewx’s new heat index 
> calculation, I noticed an oddity at the National Weather Service: while their 
> calculator calculates a heat index down to 40ºF, on the page where they 
> describe the HI equation 
>  they say the 
> “Rothfusz regression is not valid for extreme temperature and relative 
> humidity conditions beyond the range of data considered by Steadman.” Looking 
> at Steadman’s sultriness papers from 1979 
>   he never 
> looked at temperatures below 68ºF. I couldn’t find any reference to indicate 
> why they arbitrarily extended the javascript calculator down to 40ºF. Other 
> authors, and the NWS tables, suggest that the heat index isn’t really of 
> value below 80ºF.  
> 
> So I tweaked dewpointF() in my installation to return None if the temperature 
> is below 68, and now I feel better.  
> 
>   -Les
> 
> 
> 
> 
> 
>> On 24 Feb 2021, at 12:54, gjr80 > > wrote:
>> 
> 
>> Pat,
>> 
>> v4.2.0 saw a new heatindex formula implemented, refer issue 601 
>> . The new formula gives some 
>> results in some circumstances that may appear counterintuitive. v4.3.0 added 
>> back the ‘old’ heatindex formula and gives the user the ability to choose 
>> between the two algorithms . This is covered here 
>>  in the 
>> User’s Guide under [[[heatindex]]].
>> 
>> By the looks of it you are seeing the ‘new’ algorithm.
>> 
>> Gary
>> 
>> On Thursday, 25 February 2021 at 06:36:38 UTC+10 pobri...@gmail.com 
>>  wrote:
>> I thought heat index wasn't calculated unless the temperature was over 80F? 
>> Today it's about 49 F and I'm seeing heat index in my charts (which is 
>> reporting lower than temperature - I thought that was wind chill?). I don't 
>> recall seeing it before at this temperature range. 
>> 
>> I just want to make sure this is expected for temperatures so low to have a 
>> heat index reading?
>> 
>> Top graph is Seasons skin and bottom is Belchertown skin. The values match 
>> across skins
>> 
> 
>> -- 
>> 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 
>> .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/f46bd022-500d-414e-b96b-c2bc382d37b9n%40googlegroups.com
>>  
>> .
> 
> 
> -- 
> 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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/c9ac3f2e-8a1b-4dc5-8168-74fff1cc44e9n%40googlegroups.com
>  
> .

-- 
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.
To view this discussion on the web

Re: [weewx-user] Question on heat index

2021-03-12 Thread Les Niles

It looks strange to see the heat index suddenly dropping a few degrees below 
the temperature when the temperature gets above 40ºF. (I just saw this this 
morning.) After looking through the thread on weewx’s new heat index 
calculation, I noticed an oddity at the National Weather Service: while their 
calculator calculates a heat index down to 40ºF, on the page where they 
describe the HI equation 
 they say the 
“Rothfusz regression is not valid for extreme temperature and relative humidity 
conditions beyond the range of data considered by Steadman.” Looking at 
Steadman’s sultriness papers from 1979 
  he never 
looked at temperatures below 68ºF. I couldn’t find any reference to indicate 
why they arbitrarily extended the javascript calculator down to 40ºF. Other 
authors, and the NWS tables, suggest that the heat index isn’t really of value 
below 80ºF.  

So I tweaked dewpointF() in my installation to return None if the temperature 
is below 68, and now I feel better.  

  -Les

> On 24 Feb 2021, at 12:54, gjr80  wrote:
> 
> Pat,
> 
> v4.2.0 saw a new heatindex formula implemented, refer issue 601 
> . The new formula gives some 
> results in some circumstances that may appear counterintuitive. v4.3.0 added 
> back the ‘old’ heatindex formula and gives the user the ability to choose 
> between the two algorithms . This is covered here 
>  in the User’s 
> Guide under [[[heatindex]]].
> 
> By the looks of it you are seeing the ‘new’ algorithm.
> 
> Gary
> 
> On Thursday, 25 February 2021 at 06:36:38 UTC+10 pobri...@gmail.com wrote:
> I thought heat index wasn't calculated unless the temperature was over 80F? 
> Today it's about 49 F and I'm seeing heat index in my charts (which is 
> reporting lower than temperature - I thought that was wind chill?). I don't 
> recall seeing it before at this temperature range. 
> 
> I just want to make sure this is expected for temperatures so low to have a 
> heat index reading?
> 
> Top graph is Seasons skin and bottom is Belchertown skin. The values match 
> across skins
> 
> -- 
> 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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/f46bd022-500d-414e-b96b-c2bc382d37b9n%40googlegroups.com
>  
> .

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/23595CDF-1D28-49B5-AE8C-A108967A34AE%402pi.org.

Re: [weewx-user] Belchertown Skin Assistance

2021-03-09 Thread Les Niles

In general, you need forecasts enabled (Aeris) to get the forecast icons, and 
you need forecast_aeris_use_metar enabled (set to 1) to get the current 
condition icons.  

Please post your weewx.conf and skins/Belchertown/skin.conf files, after 
removing any sensitive information like login IDs and passwords.

  -Les



> On 9 Mar 2021, at 12:36, Pat W.  wrote:
> 
> For the most part, I need forecast and current conditions icons to appear on 
> my FTP'd website:
> 
> https://tinyurl.com/3ay7p3x4 
> 
> Would also like to capture additional data fields from the weather station, 
> like battery status.
> 
> 
> On Tuesday, March 9, 2021 at 2:25:18 PM UTC-6 vince wrote:
> Well there are several thousand here who would help for free if you could 
> describe what you're trying to do.
> It's unlikely you're trying to do things not done before.
> 
> On Tuesday, March 9, 2021 at 9:38:17 AM UTC-8 Pat W. wrote:
> Hello!
> 
> I've had weewx running on RPi's on two different weather stations (WX-200 & 
> Tempest sensors) for a couple years now. All is well, except...
> 
> I can see to get many of the features in the Belchertown skin to work. I'm a 
> "functional novice" and this stuff seems to be a bit above my pay grade. 
> After several weeks of trying and troubleshooting, I'm ready to call in the 
> cavalry. 
> 
> Is anyone available to assist in a paid capacity? 
> 
> Thanks!
> 
> -- 
> 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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/8cae3b12-7af5-491e-a65e-a976f320f705n%40googlegroups.com
>  
> .

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/7E20ADB6-FCCB-4238-8077-0770F773F068%402pi.org.

Re: [weewx-user] Which Raspberry Pi to use? Will more memory help at all?

2021-03-07 Thread Les Niles

I run weewx with the Belchertown skin and a couple of other skins, with a mysql 
database; there’s a local nginx instance running but the pages are uploaded to 
a hosted server that gets most of the traffic.  This configuration was tight on 
an RPi 1B+ with 512MB — every few months it would run out of memory and need a 
restart.  It runs fine on a 3B+ w/1GB.  

  -Les



> On 7 Mar 2021, at 10:07, Christopher Kelley  wrote:
> 
> The problem with Pis being so inexpensive is, I've ended up with a few extras 
> that I bought "just in case".  I've read the documentation, and while it's 
> clear WeeWx will run fine on 1Gb (or 512Mb), I also have 2Gb and 4Gb Pi4s 
> lying about.  
> 
> Is there any advantage to a 2Gb or 4Gb Pi4?  Not just "I've been running on 
> 128Mb for years with no problems", but are there any advantages to having 
> more memory, or would it be completely unused?  I might have the RPi running 
> WeeWx also drive a small display, so there would be that overhead as well.
> 
> I've already got an external M.2. SATA SSD to boot/run from, so there's no 
> worries on the storage / reliability end.
> 
> Thanks!
> 
> -- 
> 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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/aab83780-7877-4d2c-9090-e61574c2ab84n%40googlegroups.com
>  
> .

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/C8ABD159-45C7-4E4A-85D2-F9A90644D236%402pi.org.

Re: [weewx-user] Saving database etc to external drive

2021-02-27 Thread Les Niles

I just put everything on the SSD, so there’s no SD card to fail.  It turned out 
to be really easy (running Debian Buster):

1. With the RPi set up on an SD card, shut down, plug in the SSD, and start up 
the RPi.  Don’t try to mount it or anything; if the system tries to mount it 
automatically, tell it no. 
2. Figure out what “device” is associated with the SSD.  It’s probably /dev/sda 
as long as you don’t have any other storage like a USB stick. (If you do, take 
it out.) Running “fdisk /dev/sda” is a good way to check — a “p” command should 
show a storage device of the correct size.
3. Shut down weewx, any database, and any other services that aren’t necessary 
for running the OS.  Probably the best thing is to boot into single-user mode, 
but I didn’t bother with that.  The important thing is to make sure weewx (and 
mysql, if you use it) are shut down.  
4. Copy the image of the SD card to the SSD.  dd bs=1M if=/dev/mmcblk0 
of=/dev/sda should do it, assuming your SD card is /dev/mmblk0 and the SSD is 
/dev/sda. 
5. Then shut down, remove the SD card, and start the RPi back up.  It should 
just boot from the SSD, and look just like it did before.  The last step is to 
launch raspi-config and run “Expand Filesystem" from the Advanced menu to 
resize the filesystem to use the available space on the SSD.  For some reason I 
had to do this twice; the first time only got about 90% of the space.  Note 
that you need to reboot after each resize.  

This worked for me on an RPi 3 B+, and should be fine on a 4.  It may not work 
on pre-3 versions.  Also, you should probably do an update/full-upgrade before 
starting, in part to make sure you have the latest firmware.  

  -Les

> On 27 Feb 2021, at 16:16, Ken Asmus  wrote:
> 
> I am a very new user of Raspberry Pi and a LINUX neophyte!
> 
> I have WeeWx running now on my RPI4 and it is working fine.
> 
> I have read in numerous locations about the limited life of the micro SD 
> cards. So I acquired and mounted an external SSD drive to my RPI4.
> 
> But how do I save the database and any other files that are are being swapped 
> to the SD card to the SSD to decrease wear on the SD card?
> 
> Any guidance will be appreciated.
> 
> Thanks
> Ken
> 
> 
> -- 
> 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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/6f74a17e-080a-4889-8475-35bd3b25e9acn%40googlegroups.com
>  
> .

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/2982F601-E15E-46D2-A5FF-3B772CDD3866%402pi.org.

Re: [weewx-user] wee_import date/time specifications

2021-02-24 Thread Les Niles

Thanks, Gary!  This is admittedly minor, since wee_import clearly (and 
accurately!) reports what it’s doing.  But cleaning up the docs should save 
others from some head scratching.  

  -Les



> On 24 Feb 2021, at 22:22, gjr80  wrote:
> 
> Thanks Les, QC is obviously lacking at weewx.com  at the 
> moment.
> 
> I have revised the relevant stanzas in the wee_import section of the 
> Utilities Guide and added a brief explanatory note as you suggest. Have also 
> reworked the weeimport.py comments. Issue 652 
>  and commits 402db1f 
> 
>  and 26f2594 
> 
>  refer. Long story but at the moment those changes will only be visible come 
> the next release, in the meantime I will get relevant changes made to the 
> on-line documentation over the next day or so.
> 
> Gary
> On Thursday, 25 February 2021 at 06:47:40 UTC+10 ln77 wrote:
> The documentation for wee_import says that the --from and --to date/times are 
> inclusive and exclusive, respectively.  But what is reported when an import 
> is run, and what the code actually implements, is the other way around: the 
> --from is exclusive and the --to is inclusive. (To further the confusion, the 
> comment at line 187 in weeimport.py implies that both are inclusive.)  The 
> way it is implemented makes sense given that the timestamp points to the end 
> of the archive interval, but the disparity is confusing.  Assuming I’m 
> understanding this correctly, I’d suggest the utilities guide be corrected, 
> perhaps including a brief explanation of why exclusive/inclusive is the 
> appropriate choice.
> 
> That said, I’m very happy to find that wee_import does exactly what I need to 
> recover a bunch of data.  Saved me several hours of work!
> 
>   -Les
> 
> 
> -- 
> 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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/831d2e68-6f2e-4e81-ad8d-5cfae7adb72an%40googlegroups.com
>  
> .

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/FCF06810-B4BE-4447-BAB2-4085DECDE2A6%402pi.org.

[weewx-user] wee_import date/time specifications

2021-02-24 Thread Les Niles

The documentation for wee_import says that the --from and --to date/times are 
inclusive and exclusive, respectively.  But what is reported when an import is 
run, and what the code actually implements, is the other way around: the --from 
is exclusive and the --to is inclusive. (To further the confusion, the comment 
at line 187 in weeimport.py implies that both are inclusive.)  The way it is 
implemented makes sense given that the timestamp points to the end of the 
archive interval, but the disparity is confusing.  Assuming I’m understanding 
this correctly, I’d suggest the utilities guide be corrected, perhaps including 
a brief explanation of why exclusive/inclusive is the appropriate choice.

That said, I’m very happy to find that wee_import does exactly what I need to 
recover a bunch of data.  Saved me several hours of work!

  -Les

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/547B8209-FDD1-45C6-B636-4960DBEE4833%402pi.org.

Re: [weewx-user] Re: New internet provider - now ftp doesn't work

2021-01-18 Thread Les Niles

The server is responding to the PASV command by entering extended passive mode 
EPSV, which apparently is a legal response but which weewx/ftplib is not 
handling correctly. (I don’t have access to the code right now so can’t be more 
precise about where to fix.) The difference is that in EPSV mode the server 
doesn’t return an IP, just a port number. (The line “host, port = 
self.makepasv()” is not going to work.) 

Apparently passive mode has been the default for ftplib since python 2.1, so 
maybe just skip trying to change to PASV entirely?

  -Les


> On Jan 18, 2021, at 7:21 AM, Rich Strle  wrote:
> 
> 
> Command:  TYPE I
> Trace:CFtpControlSocket::OnReceive()
> Response: 200 TYPE is now 8-bit binary
> Trace:CFtpRawTransferOpData::ParseResponse() in state 1
> Trace:CControlSocket::SendNextCommand()
> Trace:CFtpRawTransferOpData::Send() in state 2
> Command:  PASV
> Trace:CFtpControlSocket::OnReceive()
> Response: 200 TYPE is now 8-bit binary
> Trace:CFtpRawTransferOpData::ParseResponse() in state 1
> Trace:CControlSocket::SendNextCommand()
> Trace:CFtpRawTransferOpData::Send() in state 2
> Command:  PASV
> Trace:CFtpControlSocket::OnReceive()
> Response: 227 Entering Passive Mode (107,180,51,77,196,142)
> Trace:CFtpRawTransferOpData::ParseResponse() in state 2
> Trace:CControlSocket::SendNextCommand()
> Trace:CFtpRawTransferOpData::Send() in state 4
> Trace:Binding data connection source IP to control connection source 
> IP 192.168.12.117
> Command:  STOR yearbarometer.png
> Trace:CTransferSocket::OnConnect
> Trace:CTlsSocketImpl::Handshake()
> Trace:Trying to resume existing TLS session.
> Trace:CTlsSocketImpl::ContinueHandshake()
> Trace:CFtpControlSocket::OnReceive()
> Response: 227 Entering Passive Mode (107,180,51,77,197,217)
> Trace:CFtpRawTransferOpData::ParseResponse() in state 2
> Trace:CControlSocket::SendNextCommand()
> Trace:CFtpRawTransferOpData::Send() in state 4
> Trace:Binding data connection source IP to control connection source 
> IP 192.168.12.117
> Command:  STOR yearhilow.png
> 
>> On Monday, January 18, 2021 at 7:16:26 AM UTC-6 tke...@gmail.com wrote:
>> Good to hear that Filezilla is working. We can use it to understand what the 
>> server is doing.
>> 
>> Using Filezilla, go into its "Settings" (under the "Edit" menu). Then the 
>> "Debug" tab. There's a drop down list of message levels. Default is "0 - 
>> None". Set it to "3- Verbose". Then click "OK".
>> 
>> 
>> 
>> Then use Filezilla again to transfer some files. This time, watch the window 
>> at top that tells you what Filezilla is doing. See if the client (Filezilla, 
>> in this case) is negotiating with the server. Tell us what you see, or, 
>> better, copy and paste it into a post.
>> 
>> 
>> 
>>> On Sun, Jan 17, 2021 at 7:33 PM Rich Strle  wrote:
>>> Jan 17 21:30:44 pi-weather weewx[429] ERROR weeutil.ftpupload: Failed 
>>> uploading /var/www/html/weewx/yearradiation.png to server 
>>> www.cliffandbuster.com. Reason: '229 Extended Passive Mode Entered 
>>> (|||50458|)'
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine: 
>>> ftpgenerator: (2): caught exception '': 229 
>>> Extended Passive Mode Entered (|||50458|)
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine: 
>>>   Traceback (most recent call last):
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine: 
>>> File "/usr/share/weewx/weewx/reportengine.py", line 331, in run
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine: 
>>>   n = ftp_data.run()
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine: 
>>> File "/usr/share/weewx/weeutil/ftpupload.py", line 163, in run
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine: 
>>>   ftp_server.storbinary(stor_cmd, fd)
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine: 
>>> File "/usr/lib/python3.7/ftplib.py", line 504, in storbinary
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine: 
>>>   with self.transfercmd(cmd, rest) as conn:
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine: 
>>> File "/usr/lib/python3.7/ftplib.py", line 399, in transfercmd
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine: 
>>>   return self.ntransfercmd(cmd, rest)[0]
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine: 
>>> File "/usr/lib/python3.7/ftplib.py", line 359, in ntransfercmd
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine: 
>>>   host, port = self.makepasv()
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine: 
>>> File

Re: [weewx-user] Question on Weewx, Vantage Vue, and CWOP

2021-01-12 Thread Les Niles

> On 12 Jan 2021, at 12:12, Nate Bargmann  wrote:
> 
> * On 2021 12 Jan 13:40 -0600, galfert wrote:
>> Stop saying that the airport is at the same elevation or at different 
>> elevation from you. That is extraneous and irrelevant information.
> 
> I am merely attempting to be factual as I'll admit to being still a bit
> confused as to what unit the METAR from my airport shows, whether
> barometer or altimeter.  No matter, I shall not concern myself with that
> any longer.

METARs from an airport will always have the altimeter setting, because that’s 
what pilots care about.  At least in the US it is given in hundredths of an 
inch, prefixed with “A”.  For example
KWVI 130053Z AUTO 0KT 10SM CLR 13/07 A3031 RMK AO2 SLP263 T01280072
the altimeter setting is 30.31”.  METARs usually also contain the pressure 
corrected to sea level; that’s the string that begins with “SLP” and gives the 
pressure in tenths of a millibar, without the hundreds and thousands digits.  
“SLP263” = 1026.3 millibar.  (Note that the 30.31 altimeter setting in that 
METAR corresponds to 1026.5 mb, so they really are different values.)

  -Les

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/8D07174F-977F-4D2A-9A47-54D2FDEA5C76%40gmail.com.

Re: [weewx-user] Looking for weather station hardware recommendation with solar radiation

2020-12-10 Thread Les Niles

I recently installed an Ecowitt GW1002 
  which apparently is a Fine 
Offset rebranding.  It’s not a Davis (I’ve had a Pro2 for 6-8 years and think 
it’s great) but it includes solar radiation and UV, and the whole thing costs 
less than a Davis data logger.  I don’t know about the accuracy or long-term 
reliability of any of the instruments, but it seems to work and the readings 
pass the sanity test.  

There is a weewx driver for the gw1000 https://github.com/gjr80/weewx-gw1000 
 I haven’t tried to set it up yet so 
can’t comment, but there’s a lot of discussion in the weewx-user archives.

  -Les

> On 10 Dec 2020, at 13:23, Hans Fangohr  wrote:
> 
> Dear all,
> 
> I'd love to use weewx with a weather station that can report - in addition to 
> the usual observables such as wind, precipitation, temperature, pressure - 
> the solar radiation (i.e. Watts/m^2 or equivalent).
> 
> I have found the Davis Pro2 (but its outside my budget). There also appear to 
> be a range of other devices (such as "Sainlogic FT0300" [1]) which appear to 
> measure solar radiation, but for those it seems they cannot communicate with 
> weewx as they do not have a USB port, and only offer to report data to 
> wunderground via wifi. 
> 
> (I am not satisfied with the data visualisations from underground - that's 
> where I want to use weewx.)
> 
> Has anybody got a recommendation for these requirements:
> - solar radiation
> - can communicate with weewx
> - less expensive than Davis Vantage Pro2?
> 
> Many thanks!
> 
> Hans
> 
> 
> [1] 
> https://www.amazon.de/-/en/Sainlogic-Professional-Wireless-Internet-Forecast/dp/B0836FVVYZ/ref=pd_lpo_86_t_2/258-2155217-5754057?_encoding=UTF8_rd_i=B0836FVVYZ_rd_r=f8d4286c-2b84-4976-b30c-139faa1e0aa2_rd_w=bdvuU_rd_wg=8llDy_rd_p=d5c9797d-0238-4119-b220-af4cc3420918_rd_r=PY28AYH3V5T5ZCYQA7MF=1=PY28AYH3V5T5ZCYQA7MF
> 
> 
> -- 
> 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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/ad4ea55e-1f25-4c62-b851-99710564d433n%40googlegroups.com
>  
> .

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/B0AB2FAC-2C22-4D74-BB70-CD5BC2F910B5%40gmail.com.

Re: [weewx-user] Is anyone using a Davis Airlink with weewx?

2020-09-15 Thread Les Niles

Box fans and square furnace filters are flying off the shelves here in N 
California. 

  -Les


> On Sep 15, 2020, at 5:57 PM, Tom Keffer  wrote:
> 
> 
> Try buying an air purifier. The nearest one I could find was in Kalispell, 
> Montana.
> 
>> On Tue, Sep 15, 2020 at 5:54 PM Alec Bennett  wrote:
>> Interesting about the backorder. They didn't mention that it was backordered 
>> when I placed the order about an hour ago, but of course it hasn't shipped 
>> yet either. I'm hoping to get it soon but I can imagine the demand is sky 
>> high right now.
>> 
>> 
>> 
>>> On Tue, Sep 15, 2020 at 5:47 PM John Kline  wrote:
>>> I’m in the same both, but the SF Bay Area was much better today: 
>>> https:/www.paloaltoweather.com/
>>> 
>>> You can see I have a PurpleAir integrated with weewx.  There are multiple 
>>> plugins to do this (I’m using my own).
>>> 
>>> I also have an Davis AirLink scheduled to arrive tomorrow.  I should have 
>>> an extension to play with shortly thereafter.  I’m sure others will write 
>>> extensions also; I’m just not aware of any at present.
>>> 
> On Sep 15, 2020, at 5:32 PM, Alec Bennett  wrote:
> 
 I just bought an Airlink:
 
 https://www.davisinstruments.com/product/airlink-professional-air-quality-sensor/
 
 Looking forward to be able to put a number on the horrible air we've been 
 having here in Northern California.
 
 I'm wondering if I can integrate it with weewx? 
 
 Is that the sort of thing a plugin would do?
 
 Thanks for any help.
 -- 
 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.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/weewx-user/5a473b16-ad4d-4d00-a813-0004ee17f836n%40googlegroups.com.
>>> 
>>> -- 
>>> 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/waXSbdBxCWo/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to 
>>> weewx-user+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/76A2D8A7-7A02-47BC-8D23-BF5113B088E3%40johnkline.com.
>> 
>> -- 
>> 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.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/CACB9%2Bz2v%3D1jwOxKC3Upsj%3DjBZyAQF4a8s1L46uwKRgn47-23rA%40mail.gmail.com.
> 
> -- 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/CAPq0zECDjdCpWgpeKvqDzyMf9MRf3wAwuwoez_crmWuVTE45wQ%40mail.gmail.com.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/32BF5B14-BC69-47F4-B09C-F4017447EAA6%40gmail.com.

Re: [weewx-user] Re: Using a ProData WiFi Logger?

2020-05-31 Thread Les Niles

Another data point: I’ve been running an RPi-based weewx with a Davis IP 
datalogger for several years. The RPi is sometimes down for over a week; when 
it restarts, all the data is recovered without loss, duplication, or manual 
intervention. This ability to spool the data while the host computer is down is 
how the datalogger earns its price — it’s not just a communication interface. 
Despite power outages, system maintenance, SD card failures, etc., the only 
data loss was one incident when the RPi was down for several weeks and the data 
overran the logger’s storage. BTW, the RPi does have a $4 RTC module. 

I’ve heard of problems with the IP datalogger locking up in some way, but have 
never had that problem in my setup. Maybe it’s because I have it on an isolated 
network, consisting of just a cable from the datalogger to the RPi’s RJ45 jack. 
Communication with the outside world is through a wifi interface on the RPi. 

  -Les


> On May 31, 2020, at 3:22 AM, Greg Troxel  wrote:
> 
> Sébastien Bouillon  writes:
> 
>> This is an important criterion that I hadn't thought of taking into 
>> account. Meteostick does not fit this criterion
>> 
>> I ask myself 2 questions :
>> - When the raspberry is turned off and on, does the data-logger 
>> automatically return any missing data? I read that it was interesting to 
>> put an RTC module on the raspberry. Is it to avoid problem in this type of 
>> situation?
> 
> When you have a Davis in-console logger, and you turn off the weewx
> computer, and wait a few hours:
> 
>  The logger continues to record archive records (typically the interval
>  is set to 5 minutes).
> 
>  When the weewx computer starts, it obtains from the datalogger the
>  archive records that are in the datalogger and not in the weewx
>  database, and puts them in the database.
> 
> It is true that a computer running with the wrong time and running the
> weewx code to extract archive records causes a lot of trouble.  So the
> real requirement is that the computer have the right time before it runs
> weewx.  On normal computers, there is a "RTC" which is a clock with a
> battery and it is read at boot, so the time is close.  On a RPI, or
> similar low-end single-board devices, these are often not present.
> Depending on OS and configuration, time at boot can be in 1970, around
> the time the computer was last shut down, or probably something else.
> 
> The two approaches discussed on the list are:
> 
>  Get a RTC device for the RPI.  They don't cost much, and then the time
>  is correct (close enough) at boot.  This is the standard approach and
>  the most frequent recommmendation.
> 
>  Set up NTP, and write a script that makes sure that the computer is
>  synchronized before starting weewx.  (This is what I'm doing.)
> 
> (It's not clear to me that the lack of clock has to be a problem, as the
> archive records have timestamps, but that's a separate discussion that
> needs a patch to make it work anyway, not ungrounded discussion.)
> 
>> - Is it necessary to regularly update the Davis data-logger firmware: 
>> https://support.davisinstruments.com/article/o3dfmlmgsp-weather-link-ip-data-logger-firmware-1-1
>>  
>> -5-windows
> 
> I have never updated firmware on my serial logger.  The logger is
> plugged into the console and has a serial attached to my weewx computer.
> Therefore my logger does not talk to the Internet at all (which I think
> is a feature!).  The Weatherlink IP is a more complicated device that
> talks to the internet, so there being firmware updates makes sense.
> 
> It seems there is now "Weatherlink Live":
>  https://github.com/weewx/weewx/issues/412
> and I am unclear if one can use it without the cloud (meaning if you
> firewall it from Davis's systems, will it still work locally).
> 
> -- 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/rmilfl8jted.fsf%40s1.lexort.com.
> 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/09FD59F2-4056-40BA-8A05-8EEEAE4E5B28%40gmail.com.

Re: [weewx-user] weewx output to HDMI display on Headless Pi 4

2020-04-25 Thread Les Niles

The simple way to do this is have the Pi start up in desktop mode, auto login, 
and launch a web browser pointed to your weewx web site (which can just be the 
local html directory).  

For the first part, run rasps-config and set the boot options to 
Desktop/CLI->Desktop Autologin. To get the browser launched, see for example 
https://raspberrypi.stackexchange.com/questions/69204/open-chromium-full-screen-on-start-up
 

 where the website is something like /var/www/weewx/index.html depending on 
your weewx installation.

  -Les



> On 25 Apr 2020, at 11:45, David Robertson  wrote:
> 
> I have been using weewx for several months running on a headless Raspberry Pi 
> 4 connected to my old David Weather Monitor II.  It's been working perfectly 
> with great reliability.  In fact it has breathed new life into my 25 year old 
> WMII.  
> 
> Recently I connected a 7" HDMI monitor to the (headless) Pi 4 hoping to use 
> it to display weather data to supplement the old WMII console.  The Pi sees 
> the display and shows a login screen but I do not know how use the display 
> for output while logged into the Pi via VNC.
> 
> Any suggestions?
> 
> Thanks,
> Dave R.
> Flint MI
> 
> -- 
> 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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/5efbde1b-e196-40c1-80f3-28108b6e92d8%40googlegroups.com
>  
> .

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/7CEF533D-AC5E-430F-9AEE-913F32114F6D%402pi.org.

Re: [weewx-user] Apple buys DarkSky, IBM own TheWeatherChannel and WU, what's the next shoe to drop?

2020-04-01 Thread Les Niles

They’ve been trying to do that for years, by proposing to give Accuweather 
exclusives to the NWS products. I was afraid it might happen when the CEO of 
Accuweather was nominated for NOAA administrator, but fortunately he didn’t get 
the job.

  -Les


> On 1 Apr 2020, at 11:10, p q  wrote:
> 
> Privatization of NWS?
> 
> On Wed, Apr 1, 2020 at 11:08 AM Chris Richmond  > wrote:
> Just saw that Apple bought DarkSky, and the API will get disabled end of 
> 2021.  Also noticed that TheWeatherChannel's
> web site is reporting as "by IBM" now.
> 
> 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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/950362db-3e58-4279-a986-18395a4782c8%40googlegroups.com
>  
> .
> 
> 
> -- 
> Peter Quinn
> (415)794-2264
> 
> -- 
> 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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/CAA1SM231h%2BwJRZ102q36EDtSnL_tfdGcZC1PLm1dCT%3D8QmQdaQ%40mail.gmail.com
>  
> .

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/1D9FC6B4-1DEE-45ED-9F92-4AA152ED7534%40gmail.com.

Re: [weewx-user] Re: Recommendations for forecast service

2020-02-29 Thread Les Niles

Yes.  It would be great to get it merged.  

  -Les

> On 29 Feb 2020, at 13:32, mwall  wrote:
> 
> On Saturday, February 29, 2020 at 3:19:03 PM UTC-5, ln77 wrote:
>  I extended the weewx forecast module to support the NWS spot forecasts.
> 
> les,
> 
> could you make a merge request with your spot forecast changes so that i can 
> incorporate that functionality into the weewx-forecast extension?
> 
> https://github.com/matthewwall/weewx-forecast
> 
> 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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/d0dcb529-849d-4bbc-a537-e3ac13f6ceab%40googlegroups.com
>  
> .

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/67AD02D7-B778-4E47-8D4E-D6ABD2879110%40gmail.com.

Re: [weewx-user] Re: Recommendations for forecast service

2020-02-29 Thread Les Niles

Do you use the NWS spot forecasts?  I live on a ridge in the Santa Cruz 
mountains with no NWS stations around and weather that is very different than 
the valleys on either side.  The NWS forecast is pretty accurate, and much 
better than DarkSky which doesn’t seem to understand that we’re above the usual 
summer inversion.  I extended the weewx forecast module to support the NWS spot 
forecasts.

  -Les

> On 29 Feb 2020, at 12:09, p q  wrote:
> 
> In a word, microclimates.
> 
> I'm using NWS now. It's good, but I found that WU was more accurate. Summer 
> high/lows were closer to what I was actually getting. I live in a rain shadow 
> and I think WU did a better job of taking that into account. The nearest NWS 
> station is only 6 miles away but it could be 5 degF different from here in 
> the summer. WU had a forecast for the zipcode. Maybe I'm deluding myself, but 
> it seemed more accurate.
> 
> The second nearest is 15 miles away and could easily be 40 degF different in 
> the summer. 
> 
> On Saturday, February 29, 2020 at 11:26:22 AM UTC-8, vince wrote:
> On Saturday, February 29, 2020 at 11:12:58 AM UTC-8, p q wrote:
> I'm in the US (SF Bay Area). Does anyone have any recommendations for what 
> forecast source to use? Darksky? Windy? Give WU another shot?
> 
> Why not NWS ?
> 
>  I
> 
> -- 
> 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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/3bff6d0a-2dd7-4559-b8c2-a7ea9c5f2563%40googlegroups.com
>  
> .

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/DE32D57B-D305-46F9-943C-2D79982D149A%40gmail.com.

Re: [weewx-user] Re: Mismatch Between Hardware and weeWX Data

2020-02-20 Thread Les Niles

JD said that he “suspects” that would be the right change.  It would help if 
you tested it, but be prepared for it not to work or break the driver.  Save 
the original version of the file, and restart weewx after changing it in order 
to load the new version.

The location of the driver can depend on the type of OS and how you installed 
weewx.  On my raspberry pi, it is /usr/share/weewx/weewx/drivers/ws28xx.py.

  -Les



> On 20 Feb 2020, at 13:31, Dan Blanchard  wrote:
> 
> I was under the impression that what JD wrote was a change I can make to the 
> driver.  If so, how can I access the driver to modify it?
> 
> On Thursday, February 20, 2020 at 12:39:43 AM UTC-8, ln77 wrote:
> I thought your questions were answered: what you’ve done is a workaround. 
> Fundamentally, it’s not a limitation of the LaCrosse hardware, it’s a bug in 
> the driver.  
> 
>   -Les
> 
> 
> 
>> On 19 Feb 2020, at 12:05, Dan Blanchard > wrote:
>> 
>> Where did you all go?  I was hoping for some comments on my last post.  Does 
>> everything I state seem correct?
>> 
>> On Monday, February 17, 2020 at 8:20:34 AM UTC-8, Dan Blanchard wrote:
>> OK guys, thanks for all the help on this.  Jerry, I assume that the info 
>> below is in the driver for my WS-28xx and if that is the case, where is that 
>> driver located?  
>> 
>> Next, I want to clarify something... I have used the calculator at 
>> http://www.csgnetwork.com/barcorrecthcalc.html 
>>  to set my altitude (2,320 
>> ft.) and an observed pressure of 30.16 inHg as reported for my area 
>> (https://tinyurl.com/yx65ckcm ).  This gives 
>> me an adjustment of -2.43 so I have set my station pressure to 27.73 inHg. 
>> This is now reporting 30.35 inHg barometer reading at Weather Underground 
>> (WU).  Although this is working, I feel as if it a work-around but maybe it 
>> is just a limitation of my station?  Thoughts...
>> 
>> On Sunday, February 16, 2020 at 9:44:46 PM UTC-8, J D wrote:
>> Hi,
>> I am using the ws23xx driver on ws2316 hardware and this driver sends 
>> absolute pressure to weewx in the packet as "pressure" ..
>> The ws28xx hardware sends relative pressure and the ws28xx driver also sends 
>> the reading to weewx in the packet as pressure. See below
>> 
>> packet['pressure']= get_datum_diff(data._PressureRelative_hPa,
>>CWeatherTraits.PressureNP(),
>>CWeatherTraits.PressureOFL())
>> 
>> I suspect the code should read.
>> packet['barometer']= get_datum_diff(data._PressureRelative_hPa,
>>CWeatherTraits.PressureNP(),
>>CWeatherTraits.PressureOFL())
>> Or you could just change the altitude of the station as Andrew suggest.
>> 
>> Jerry
>> 
>> On Sunday, February 9, 2020 at 4:36:51 PM UTC-7, Dan Blanchard wrote:
>> I've been running my weather station on weeWX for 2 days now after switching 
>> from a PC based solution for the past several years.  I noticed this problem 
>> after noticing that my station is no longer showing on the 
>> WeatherUnderground (WU) maps.  The data is still showing for my site on WU 
>> though (https://www.wunderground.com/dashboard/pws/KIDPOSTF43 
>> )
>> 
>> Everything has been going fine except I am currently having a problem with 
>> data inaccuracies.  All the data seems correct except the barometer reading. 
>>  The reading on my hardware is currently 30.30 and weeWX is showing 33.093 
>> which is what is reporting to WU.
>> 
>> Can anyone please shed some light on this issue?  I've attached the syslog 
>> for reference.  Please let me know if there is anything else I can provide 
>> to help with this situation. If the solution requires changes in the 
>> configuration file, please be specific as I am still learning the Linux 
>> stuff.
>> 
>> Thanks,
>> 
>> Dan
>> 
>> 
>> Hardware: Lacrosse WS-2813
>> 
>> 
>> -- 
>> 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...@googlegroups.com <>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/d026b7e2-1fb7-4e61-a715-8d48befd725c%40googlegroups.com
>>  
>> .
> 
> 
> -- 
> 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 
> .
> To view this discussion on the web visit 
>

Re: [weewx-user] Re: Mismatch Between Hardware and weeWX Data

2020-02-20 Thread Les Niles

I thought your questions were answered: what you’ve done is a workaround. 
Fundamentally, it’s not a limitation of the LaCrosse hardware, it’s a bug in 
the driver.  

  -Les



> On 19 Feb 2020, at 12:05, Dan Blanchard  wrote:
> 
> Where did you all go?  I was hoping for some comments on my last post.  Does 
> everything I state seem correct?
> 
> On Monday, February 17, 2020 at 8:20:34 AM UTC-8, Dan Blanchard wrote:
> OK guys, thanks for all the help on this.  Jerry, I assume that the info 
> below is in the driver for my WS-28xx and if that is the case, where is that 
> driver located?  
> 
> Next, I want to clarify something... I have used the calculator at 
> http://www.csgnetwork.com/barcorrecthcalc.html 
>  to set my altitude (2,320 
> ft.) and an observed pressure of 30.16 inHg as reported for my area 
> (https://tinyurl.com/yx65ckcm ).  This gives me 
> an adjustment of -2.43 so I have set my station pressure to 27.73 inHg. This 
> is now reporting 30.35 inHg barometer reading at Weather Underground (WU).  
> Although this is working, I feel as if it a work-around but maybe it is just 
> a limitation of my station?  Thoughts...
> 
> On Sunday, February 16, 2020 at 9:44:46 PM UTC-8, J D wrote:
> Hi,
> I am using the ws23xx driver on ws2316 hardware and this driver sends 
> absolute pressure to weewx in the packet as "pressure" ..
> The ws28xx hardware sends relative pressure and the ws28xx driver also sends 
> the reading to weewx in the packet as pressure. See below
> 
> packet['pressure']= get_datum_diff(data._PressureRelative_hPa,
>CWeatherTraits.PressureNP(),
>CWeatherTraits.PressureOFL())
> 
> I suspect the code should read.
> packet['barometer']= get_datum_diff(data._PressureRelative_hPa,
>CWeatherTraits.PressureNP(),
>CWeatherTraits.PressureOFL())
> Or you could just change the altitude of the station as Andrew suggest.
> 
> Jerry
> 
> On Sunday, February 9, 2020 at 4:36:51 PM UTC-7, Dan Blanchard wrote:
> I've been running my weather station on weeWX for 2 days now after switching 
> from a PC based solution for the past several years.  I noticed this problem 
> after noticing that my station is no longer showing on the WeatherUnderground 
> (WU) maps.  The data is still showing for my site on WU though 
> (https://www.wunderground.com/dashboard/pws/KIDPOSTF43 
> )
> 
> Everything has been going fine except I am currently having a problem with 
> data inaccuracies.  All the data seems correct except the barometer reading.  
> The reading on my hardware is currently 30.30 and weeWX is showing 33.093 
> which is what is reporting to WU.
> 
> Can anyone please shed some light on this issue?  I've attached the syslog 
> for reference.  Please let me know if there is anything else I can provide to 
> help with this situation. If the solution requires changes in the 
> configuration file, please be specific as I am still learning the Linux stuff.
> 
> Thanks,
> 
> Dan
> 
> 
> Hardware: Lacrosse WS-2813
> 
> 
> -- 
> 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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/d026b7e2-1fb7-4e61-a715-8d48befd725c%40googlegroups.com
>  
> .

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/BD19A577-510A-4FEF-A8CC-1920EB6F14A8%402pi.org.

Re: [weewx-user] Mismatch Between Hardware and weeWX Data

2020-02-16 Thread Les Niles

That would work, other than having the station console reading uncorrected 
pressure.

Or, the OP could just move to some place at sea level. :)

  -Les


> On 16 Feb 2020, at 21:38, Andrew Milner  wrote:
> 
> well if it is hard coded for pressure then the station adjustment made by the 
> OP should be to set his station to a known sea level pressure and subtract a 
> correction for altitude (2.6 for 2300 ft I think) and all should then be ok
> 
> On Monday, 17 February 2020 07:09:35 UTC+2, ln77 wrote:
> Setting those that way won’t fix the problem.  Those settings are hints to 
> weewx about what to use when the weather station hardware provides multiple 
> values.  The WS28XX driver is hard-coded to interpret the data from the 
> station as weewx “pressure,” and that is the only pressure-related datum sent 
> by the WS28XX stations.  
> 
>   -Les
> 
> 
> 
>> On 16 Feb 2020, at 17:09, Dan Blanchard > wrote:
>> 
>> Andrew, I've set barometer = hardware and altimeter = software and pressure 
>> = software.  I've restarted weewx, but nothing has changed in the Loop.
>> 
>> On Friday, February 14, 2020 at 9:30:06 PM UTC-8, Andrew Milner wrote:
>> if indeed, and i now tend to agree, the station displays and outputs a 
>> manually adjusted barometer which is set to a sea level reading from local 
>> weather stations and not pressure then barometer should be set to hardware 
>> and pressure and altimeter set to software, and not as i previously 
>> suggested.
>> 
>> On Saturday, 15 February 2020 06:22:07 UTC+2, ln77 wrote:
>> OK… The “pressure” that your station is displaying is what it should be 
>> displaying: the ambient air pressure, correct for your altitude.  In weewx, 
>> this is called “barometer” because that is what weather stations report for 
>> barometric pressure.  “Altimeter” is basically the same thing; there are 
>> differences in exactly how it is corrected, but those differences are minor 
>> and can be ignored for now.  The distinction between what weewx calls 
>> “barometer” and “pressure” is important, though, for anyone more than a few 
>> hundred feet above sea level.  
>> 
>> From the manual, it appears that the WS-2813 uses a simple method for 
>> correcting to sea level, by allowing the user to adjust a correction factor 
>> that is applied to the actual measured pressure until the reading matches 
>> some local reference barometric pressure report.  This automatically also 
>> corrects for any errors in the pressure sensor itself, a handy bonus. 
>> There’s not reference in the manual to any other kind of pressure being 
>> reported, so it only makes sense that what it transmits via the USB 
>> interface is also this corrected pressure, i.e., “barometer.”  But the 
>> WS28XX driver documentation, and as far as I can tell the code also, assume 
>> that the pressure reading fro the hardware is what weewx calls “pressure,” 
>> that is, the actual ambient pressure before correction for altitude.  As far 
>> as I can tell, all of the WS28XX LaCrosse stations work the same way as 
>> yours and actually send the corrected barometer reading. Maybe because the 
>> LaCrosse documentation calls it “pressure,” it was mistakenly interpreted as 
>> raw pressure reading in the driver. 
>> 
>> The bottom line is, I’m pretty sure the issue is that the driver is wrong.  
>> I’m not familiar enough with that part of the weewx code to offer a fix, but 
>> it should be pretty simple for someone who is familiar with that code.  
>> 
>>   -Les
>> 
>> 
>> 
>>> On 14 Feb 2020, at 19:44, Dan Blanchard > wrote:
>>> 
>>> It is likely that I am mis-using the terms altimeter, barometer, and 
>>> pressure.  I'll clarify what I mean here.  
>>> 
>>> What I previously defined as 'correct' pressure is that the pressure 
>>> reported by my station (LaCrosse WS-2813U-IT) matches the National Weather 
>>> Service barometer reading 
>>> (https://forecast.weather.gov/MapClick.php?lat=47.7151345=-116.946676#.XkdkXDFKiUk
>>>  
>>> ).
>>>  For example, right now my station is reading 30.06 pressure and the NWS 
>>> site is reporting 30.0 barometer.  Ultimately I just want my WS-2813 
>>> pressure reading to match the WU pressure reading 
>>> (https://www.wunderground.com/dashboard/pws/KIDPOSTF43 
>>> ).  Right now it 
>>> appears that WU is reading the weewx barometer reading.  Is there a way to 
>>> have weewx report the pressure reading to WU?
>>> 
>>> My WS-2813 outputs the manually adjusted pressure in the Loop records (see 
>>> attachment).  I don't see a way to change that.  Here is a link to the 
>>> manual 
>>> (https://www.lacrossetechnology.com/media/catalog/product/w/s/ws-2813u-it.pdf
>>>  
>>> ).
>>> 
>>> On Friday, February 14, 2020 at 9:22:17 AM UTC-8, Andrew Milner

Re: [weewx-user] Re: Mismatch Between Hardware and weeWX Data

2020-02-16 Thread Les Niles

Setting those that way won’t fix the problem.  Those settings are hints to 
weewx about what to use when the weather station hardware provides multiple 
values.  The WS28XX driver is hard-coded to interpret the data from the station 
as weewx “pressure,” and that is the only pressure-related datum sent by the 
WS28XX stations.  

  -Les



> On 16 Feb 2020, at 17:09, Dan Blanchard  wrote:
> 
> Andrew, I've set barometer = hardware and altimeter = software and pressure = 
> software.  I've restarted weewx, but nothing has changed in the Loop.
> 
> On Friday, February 14, 2020 at 9:30:06 PM UTC-8, Andrew Milner wrote:
> if indeed, and i now tend to agree, the station displays and outputs a 
> manually adjusted barometer which is set to a sea level reading from local 
> weather stations and not pressure then barometer should be set to hardware 
> and pressure and altimeter set to software, and not as i previously suggested.
> 
> On Saturday, 15 February 2020 06:22:07 UTC+2, ln77 wrote:
> OK… The “pressure” that your station is displaying is what it should be 
> displaying: the ambient air pressure, correct for your altitude.  In weewx, 
> this is called “barometer” because that is what weather stations report for 
> barometric pressure.  “Altimeter” is basically the same thing; there are 
> differences in exactly how it is corrected, but those differences are minor 
> and can be ignored for now.  The distinction between what weewx calls 
> “barometer” and “pressure” is important, though, for anyone more than a few 
> hundred feet above sea level.  
> 
> From the manual, it appears that the WS-2813 uses a simple method for 
> correcting to sea level, by allowing the user to adjust a correction factor 
> that is applied to the actual measured pressure until the reading matches 
> some local reference barometric pressure report.  This automatically also 
> corrects for any errors in the pressure sensor itself, a handy bonus. There’s 
> not reference in the manual to any other kind of pressure being reported, so 
> it only makes sense that what it transmits via the USB interface is also this 
> corrected pressure, i.e., “barometer.”  But the WS28XX driver documentation, 
> and as far as I can tell the code also, assume that the pressure reading fro 
> the hardware is what weewx calls “pressure,” that is, the actual ambient 
> pressure before correction for altitude.  As far as I can tell, all of the 
> WS28XX LaCrosse stations work the same way as yours and actually send the 
> corrected barometer reading. Maybe because the LaCrosse documentation calls 
> it “pressure,” it was mistakenly interpreted as raw pressure reading in the 
> driver. 
> 
> The bottom line is, I’m pretty sure the issue is that the driver is wrong.  
> I’m not familiar enough with that part of the weewx code to offer a fix, but 
> it should be pretty simple for someone who is familiar with that code.  
> 
>   -Les
> 
> 
> 
>> On 14 Feb 2020, at 19:44, Dan Blanchard > wrote:
>> 
>> It is likely that I am mis-using the terms altimeter, barometer, and 
>> pressure.  I'll clarify what I mean here.  
>> 
>> What I previously defined as 'correct' pressure is that the pressure 
>> reported by my station (LaCrosse WS-2813U-IT) matches the National Weather 
>> Service barometer reading 
>> (https://forecast.weather.gov/MapClick.php?lat=47.7151345=-116.946676#.XkdkXDFKiUk
>>  
>> ).
>>  For example, right now my station is reading 30.06 pressure and the NWS 
>> site is reporting 30.0 barometer.  Ultimately I just want my WS-2813 
>> pressure reading to match the WU pressure reading 
>> (https://www.wunderground.com/dashboard/pws/KIDPOSTF43 
>> ).  Right now it 
>> appears that WU is reading the weewx barometer reading.  Is there a way to 
>> have weewx report the pressure reading to WU?
>> 
>> My WS-2813 outputs the manually adjusted pressure in the Loop records (see 
>> attachment).  I don't see a way to change that.  Here is a link to the 
>> manual 
>> (https://www.lacrossetechnology.com/media/catalog/product/w/s/ws-2813u-it.pdf
>>  
>> ).
>> 
>> On Friday, February 14, 2020 at 9:22:17 AM UTC-8, Andrew Milner wrote:
>> I would expect you to be reporting barometer = sea level pressure which is 
>> pressure adjusted for temperature and altitude because weather stations 
>> always report sea level pressures.
>> 
>> Is what you call 'correct' pressure the raw pressure of the instrument or a 
>> pressure which you have set.  Does the station output the raw pressure or 
>> the manually adjusted pressure in the loop records?
>> 
>> 
>> 
>> On Friday, 14 February 2020 18:07:15 UTC+2, Dan Blanchard wrote:
>> Andrew, that's a good questions; let me clarify.  
>> 
>> This issue started when Weather Underground (WU)

Re: [weewx-user] Re: Mismatch Between Hardware and weeWX Data

2020-02-14 Thread Les Niles

OK… The “pressure” that your station is displaying is what it should be 
displaying: the ambient air pressure, correct for your altitude.  In weewx, 
this is called “barometer” because that is what weather stations report for 
barometric pressure.  “Altimeter” is basically the same thing; there are 
differences in exactly how it is corrected, but those differences are minor and 
can be ignored for now.  The distinction between what weewx calls “barometer” 
and “pressure” is important, though, for anyone more than a few hundred feet 
above sea level.  

>From the manual, it appears that the WS-2813 uses a simple method for 
>correcting to sea level, by allowing the user to adjust a correction factor 
>that is applied to the actual measured pressure until the reading matches some 
>local reference barometric pressure report.  This automatically also corrects 
>for any errors in the pressure sensor itself, a handy bonus. There’s not 
>reference in the manual to any other kind of pressure being reported, so it 
>only makes sense that what it transmits via the USB interface is also this 
>corrected pressure, i.e., “barometer.”  But the WS28XX driver documentation, 
>and as far as I can tell the code also, assume that the pressure reading fro 
>the hardware is what weewx calls “pressure,” that is, the actual ambient 
>pressure before correction for altitude.  As far as I can tell, all of the 
>WS28XX LaCrosse stations work the same way as yours and actually send the 
>corrected barometer reading. Maybe because the LaCrosse documentation calls it 
>“pressure,” it was mistakenly interpreted as raw pressure reading in the 
>driver. 

The bottom line is, I’m pretty sure the issue is that the driver is wrong.  I’m 
not familiar enough with that part of the weewx code to offer a fix, but it 
should be pretty simple for someone who is familiar with that code.  

  -Les



> On 14 Feb 2020, at 19:44, Dan Blanchard  wrote:
> 
> It is likely that I am mis-using the terms altimeter, barometer, and 
> pressure.  I'll clarify what I mean here.  
> 
> What I previously defined as 'correct' pressure is that the pressure reported 
> by my station (LaCrosse WS-2813U-IT) matches the National Weather Service 
> barometer reading 
> (https://forecast.weather.gov/MapClick.php?lat=47.7151345=-116.946676#.XkdkXDFKiUk
>  
> ).
>  For example, right now my station is reading 30.06 pressure and the NWS site 
> is reporting 30.0 barometer.  Ultimately I just want my WS-2813 pressure 
> reading to match the WU pressure reading 
> (https://www.wunderground.com/dashboard/pws/KIDPOSTF43 
> ).  Right now it 
> appears that WU is reading the weewx barometer reading.  Is there a way to 
> have weewx report the pressure reading to WU?
> 
> My WS-2813 outputs the manually adjusted pressure in the Loop records (see 
> attachment).  I don't see a way to change that.  Here is a link to the manual 
> (https://www.lacrossetechnology.com/media/catalog/product/w/s/ws-2813u-it.pdf 
> ).
> 
> On Friday, February 14, 2020 at 9:22:17 AM UTC-8, Andrew Milner wrote:
> I would expect you to be reporting barometer = sea level pressure which is 
> pressure adjusted for temperature and altitude because weather stations 
> always report sea level pressures.
> 
> Is what you call 'correct' pressure the raw pressure of the instrument or a 
> pressure which you have set.  Does the station output the raw pressure or the 
> manually adjusted pressure in the loop records?
> 
> 
> 
> On Friday, 14 February 2020 18:07:15 UTC+2, Dan Blanchard wrote:
> Andrew, that's a good questions; let me clarify.  
> 
> This issue started when Weather Underground (WU) stopped showing my station 
> on the maps. I found out that was because I was reporting an incorrect 
> barometric 'pressure.'  As I dug into the details I found that my station was 
> displaying the correct pressure (29.xx) but by the time it got to WU, it was 
> displaying the barometer reading (32.xx) from weewx.  This can also be 
> demonstrated by looking at the data displayed at 
> /var/www/html/weewx/index.html (see attachment) so I assume that weewx is 
> taking the pressure from my station and somehow converting it or exchanging 
> it for barometric pressure before it gets uploaded to WU.  I just want the 
> pressure from my unit to be what is reported to WU.
> 
> Side note: I've been running this station for many years on a Windows based 
> system and it has been working fine.  So I know the hardware side is working; 
> just something different about how weewx reports pressure (or barometer, or 
> altimiter).
> 
> Does that help clarify my issue?
> 
> On Friday, February 14, 2020 at 2:24:31 AM UTC-8, Andrew Milner wrote:
> I am  not sure I understand what you think is

Re: [weewx-user] Re: Mismatch Between Hardware and weeWX Data

2020-02-11 Thread Les Niles

The link in Gary’s mail explains how to run it — just give the full path to the 
config file as an argument to weewxd. Something like:
sudo weewxd /etc/weewx/weewx.conf

  -Les


> On Feb 11, 2020, at 9:21 AM, Dan Blanchard  wrote:
> 
> 
> I have confirmed and to the best of my knowledge, the station altitude is set 
> correctly (altitude = 2320 foot).
> 
> When I run weewx directly (sudo weewxd weewx.conf) I get the following:
> 
> Traceback (most recent call last):
>   File "/usr/bin/weewxd", line 64, in 
> weewx.engine.main(options, args)
>   File "/usr/share/weewx/weewx/engine.py", line 852, in main
> sane = os.stat(config_path).st_ctime
> OSError: [Errno 2] No such file or directory: '/home/pi/weewx.conf'
> 
> I really do not understand what that means.  I went and looked at line 64 and 
> 852 but don't know enough to see a problem.  I understand the last line 
> because my config file is at /etc/weewx/weewx.conf.  Is there another way to 
> run it directly?
> 
> Once I get past this step, I can try the other suggestions you had.
> 
>> On Tuesday, February 11, 2020 at 2:03:38 AM UTC-8, gjr80 wrote:
>> Sorry, only use hPa here so the obvious nonsense inHg value was lost on me.
>> 
>> WeeWX is flexible enough that you change whatever you want to display on 
>> your web page, you can use another field or recalculate using whatever you 
>> like, it's just a case of altering the appropriate template. Similarly, you 
>> can change what is sent to WU, WeeWX is coded to send field barometer, to 
>> change that you need to dig into the code and your changes would likely not 
>> be safe across an upgrade.
>> 
>> In terms of solutions, one obvious check is that you have your station 
>> altitude set correctly in weewx.conf. You are after the altitude setting 
>> under [Station]. If altitude is set correctly then the solution is in the 
>> driver. The WS-2813 driver emits pressure and WeeWX calculates barometer and 
>> altitude. Have you run WeeWX directly to see what pressures are being 
>> include in loop packet and archive records. You should see all three 
>> pressures included as the data sent to console is after WeeWX has augmented 
>> the packet/record with whatever derived fields it can.
>> 
>> Unfortunately it looks like the WS-2813 driver cannot be run stand alone 
>> which would be handy to see exactly what data is coming from the driver (as 
>> opposed to running WeeWX directly which include driver and WeeWX calculated 
>> fields). You can driver only data by disabling the WeeWX StdWXCalculate 
>> service that calculates the additional fields. To disable StdWXCalculate 
>> edit weewx.conf and locate the process_services setting under [Engine] 
>> [[Services]]. It should look something like this:
>> 
>> process_services = weewx.engine.StdConvert, weewx.engine.StdCalibrate, 
>> weewx.engine.StdQC, weewx.wxservices.StdWXCalculate
>> 
>> just put a # in front of the StdWXCalculate service as follows:
>> 
>> process_services = weewx.engine.StdConvert, weewx.engine.StdCalibrate, 
>> weewx.engine.StdQC #, weewx.wxservices.StdWXCalculate
>> 
>> save and stop WeeWX if running and then run directly again. This time you 
>> should see no derived fields added and what you see should be coming from 
>> the driver. What pressure field is provide and if it is pressure is it 
>> indeed station pressure? If this is the case then the issue lies elsewhere, 
>> if not then the driver needs some scrutiny.
>> 
>> Gary
> 
> -- 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/df992563-d738-4f4d-90ec-ec68c3b995b5%40googlegroups.com.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/D727F86C-860C-4FF2-A734-B1C92A41A47F%40gmail.com.

Re: [weewx-user] Re: Public webpage using MQTT from weewx

2019-11-22 Thread Les Niles

You could use a hosted MQTT service like  https://www.cloudmqtt.com/ which 
gives you your own broker. It’s free for a small number of connections and 
inexpensive for somewhat more. Or you could get a cloud compute instance on aws 
or your favorite cloud provider, and install an MQTT broker there. 

I just put the broker on a ~dedicated RPi on an isolated network (dmz) behind 
my firewall. I do have a static IP, but DDNS works pretty well with most ISPs 
that have dynamic IPs since the IPs rarely change, as long as they assign 
public IPs. 

  -Les


> On Nov 22, 2019, at 3:02 AM, Radek Dohnal  wrote:
> 
> 
> Thanks for super explanation..
> 
> Set up MQTT broker on a public IP address - you mean to you something like 
> this? - https://www.hivemq.com/blog/build-javascript-mqtt-web-application/
> 
> 
> I dont want to use public MQTT (i.e. http://www.mqtt-dashboard.com/) - there 
> is no possibility to password secure.
> 
> 
> 
> Dne čtvrtek 21. listopadu 2019 18:48:18 UTC+1 Greg Troxel napsal(a):
>> 
>> vince  writes: 
>> 
>> > On Thursday, November 21, 2019 at 8:30:34 AM UTC-8, Greg Troxel wrote: 
>> > 
>> >> I don't follow "password-protected" entirely.  
>> >> 
>> > 
>> > oh - I meant protecting the Internet MQTT broker from nefarious 
>> > denial-of-service from the script kiddies. 
>> > 
>> > The LAN broker will need to forward/post to the Internet broker instance. 
>> > You want to make sure it's just 'you' who can post data there, so enabling 
>> > the MQTT username/password setup on the Internet broker will help stop the 
>> > bad guys from messing with your data.  The LAN MQTT broker can (probably) 
>> > be open for writes without username/password needed, depending on how you 
>> > like to set your LAN up. 
>> 
>> I understand now.  It was obvious to me that writes must be 
>> authenticated and thus I thought we were talking about allowing 
>> unauthenticated reads.  However,  it is not obvious to everyone and 
>> excellent advice to someone starting out. 
>> 
>> > My setup at home has a bunch of pi and arduinos and sensors posting to 
>> > local MQTT without any passwords needed.  When I had the Internet MQTT 
>> > broker being bridged to (as MQTT uses the term) from the LAN, I had just 
>> > 'that' one requiring a username/password, and also had some packet filters 
>> > etc. limiting the incoming MQTT traffic to be from the pretty stable 
>> > public 
>> > ip address my home LAN NAT's out to Internet on via my service provider. 
>> 
>> Makes sense.  I have set up TLS on both home and public broker and also 
>> username/passwords and acls.  All of my sensors have credentials that 
>> allows them to write to part of the sensor subspace.   Indeed, this is 
>> much more work. 
>> 
>> > But no I didn't mean webserver username+pass.  Sorry for any confusion 
>> > there. 
>> 
>> No problem, and I was misunderstanding more than you -- I think it's 
>> actually been a very useful discussion.  To sum up for the OP, assuming 
>> they want to do something like Belchertown 
>> 
>>   set up an MQTT broker on a public/stable IP address 
>> 
>>   configure acl to require user/password for writing, to avoid kiddies 
>>   writing to your topics and also storing warez fragements in various 
>>   retained topics, as happened with writable anonymous FTP.  For extra 
>>   credit, set up TLS and only do password-controlled access over TLS to 
>>   prevent password sniffing. 
>> 
>>   allow anonymous reads of the data that you intend to be used by the 
>>   skin -- and only that data. 
>> 
>>   Keep in mind that because MQTT ends up being the way you connect 
>>   everything to everything, almost all data in it is sensitive with 
>>   respect to writes and some data is sensitive with respect to reads. 
>>   
> 
> -- 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/e4344b69-d078-413f-98e4-8dd2cc1d3d0f%40googlegroups.com.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/A7E3E3E3-EF21-4136-B357-6C2E5F2C6E02%402pi.org.

Re: [weewx-user] Weewx on RPi Zero

2019-11-19 Thread Les Niles

Likewise — I have an RTC but no UPS on an RPi 3, and have zero problems with 
data loss or corruption due to power failures from a few seconds to several 
days in duration.  The only issue is if the RPi is down for the 10-15 days that 
it takes the Davis logger’s memory to overflow.  

Going back to the original question on this thread, the RTC should work just as 
easily with a Pi Zero as with a full-sized Raspberry Pi. IIRC the RTC module is 
about $4 so not a huge expense.

  -Les

> On 19 Nov 2019, at 10:35, Andrew Milner  wrote:
> 
> for what it is worth I do not use a UPS - and we get frequent power outages 
> here.  I do use a usb hard drive though instead of the SD card on my rpi.  
> Weewx has always recovered the data from my current davis and my earlier 
> fineoffset without any issues, so i see no need for a ups.  Anyways sometimes 
> our outages are for 3,4,5 hours so it is doubtful the ups would keep things 
> running anyway even if I had one.  I do have an RTC installed to make sure 
> there are no hiccups in recovering the data from the station logger though!!
> 
> 
> 
> On Tuesday, 19 November 2019 20:18:46 UTC+2, David VE3STI wrote:
> Susan: Do you have a Davis system? The reason I ask is that, from my reading 
> of the comments over the last few years, this 'argument' between the RPi 
> starting up and the weather station hardware may be limited to the Davis 
> systems with their logging interface. Would you be willing to share your 
> coding/scripts/etc with the rest of us? Although I have added an RTC and a 
> UPS, I wish that my system was robust enough to reliably deal with power 
> interruptions without these additions. (The RTC and UPS cost more than the 
> RPi!)
> 
> David
> 
> On Mon, 18 Nov 2019 at 21:32, Susan Mackay > wrote:
> I use an RPi Zero W for Weewx and Nginx as well.
> I use systemd to manage it and have pre-requisites that the 'ntp.service' and 
> 'time-sync.service' have completed before it will start.
> Susan
> 
> On Monday, November 18, 2019 at 11:52:38 PM UTC+11, David VE3STI wrote:
> The problems occur during the startup, before the RPi sets its clock from the 
> Internet, and appear to be issues with the RPi and the Davis equipment 
> disagreeing on the time and getting muddled. It has been the topic of much 
> discussion and you can read the gory details in the wiki. I won't go into the 
> details here. If you have a UPS and rarely reboot, it becomes almost a 
> non-issue.
> 
> David
> 
> -- 
> 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/I5C5Wqvtw7c/unsubscribe 
> .
> To unsubscribe from this group and all its topics, send an email to 
> weewx...@googlegroups.com <>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/c6136128-8d33-450f-84b0-e70e75c49330%40googlegroups.com
>  
> .
> 
> -- 
> 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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/44bc2cd3-0c5d-45d1-8f6d-1913424916d0%40googlegroups.com
>  
> .

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/D4715FFB-A16C-4D47-B9AC-9EBC7E095C7E%40gmail.com.

Re: [weewx-user] Force auto-update of web page?

2019-10-24 Thread Les Niles

There’s a refresh tag that can be added to the html.  As Andrew said, google 
for it to find the correct syntax.

Or, use one of the AJAXy skins that does live weather feed — both MesoWX and 
Belchertown have worked well for me. Find them at 
https://github.com/weewx/weewx/wiki#skins 
. This is even better than 
refreshing the page because the data updates in real time, which is 
particularly interesting for winds.  

  -Les



> On 24 Oct 2019, at 9:47, Timothy Buchanan  wrote:
> 
> Now having a working weewx website (thanks to much help here), I am wondering 
> if there is an easy way to force the loaded web page to update whenever weewx 
> runs a report. I am using nginx server.
> 
> -- 
> 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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/a3870dbd-1de8-4573-b186-edc58b0986f7%40googlegroups.com
>  
> .

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/E9B2D173-3DC9-4E0F-8F5D-0CFFE041CAC8%402pi.org.

Re: [weewx-user] weewx barmeter offset

2019-10-05 Thread Les Niles

Jason, is the base unit adjusted for your station elevation? By convention 
barometric pressure is reported adjusted to a sea-level equivalent, and the 14 
mb discrepancy you mention is suspiciously close to what the correction would 
be for 120 m elevation. Mercury barometers measure the absolute pressure 
directly and I think the elevation is generally applied through some kind of 
table lookup, not by adjusting the mercury height scale. Weewx makes the 
elevation correction automatically, based on the station elevation in the 
config file. In other words, the weewx reading may already be correct. 

  -Les


>> On Oct 5, 2019, at 1:29 PM, p q  wrote:
> 
> In weewx.conf, look for StdCalibrate
> You'll want something like
> pressure = pressure - 14
> 
>> On Sat, Oct 5, 2019 at 12:12 PM Jason  wrote:
>> Is it possible to add a Barometer offset to weewx as my ftp upload shows 
>> presssure to be at 14 mb higher than what both my base unit and mercury 
>> Barometer shows.
>> I believe Weewx shows real level pressure which is higher than what it is at 
>> my 120 meter high  location.
>> I have been thro all config entries etc and cannot find an answer
>> -- 
>> 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.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/acdea1c1-f2de-43b6-a5dd-51df64c18de6%40googlegroups.com.
> 
> 
> -- 
> Peter Quinn
> (415)794-2264
> -- 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/CAA1SM20X8_ga%3D3r%3DVtHvYWinfOdys5OLEXMieU9VEAa5E2Uz1Q%40mail.gmail.com.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/D2A20E02-1584-429C-8A9D-5D290888224E%40gmail.com.

Re: [weewx-user] Looking for sample weewx.conf file that includes two sensor sources for Vantage Pro

2019-08-30 Thread Les Niles

I have my anemometer connected to a separate sensor transmitter, with 
the ISS as station 4 and the anemometer as station 3 -- I have a 
neighbor with an ISS on station 1.  weewx is connected to the console by 
an ethernet data logger.  I never touched the iss_id in weewx.conf -- 
it's still the default value of 1.  weewx is just picking up whatever 
sensors/IDs the console is configured to use.  wee_device --info reports 
wind on channel 3 and iss on channel 4, as expected.  But I don't have 
any experience with the Envoy or how to configure it.


  -Les

On 8/30/19 7:49, Bob Borzelleri wrote:
I am switching to a Raspberry Pi 4 with Weewx from a PC running 
Weatherlink for the past 15 years.  Previously, I ran the anemometer 
hard wired into the ISS which would work fine, I assume, with Weewx 
seeing all sensor inputs (rain, temp/humidity/ solar radiation and 
wind) from ISS = 1.


Now that I am 15 years older than when I started this weather stuff, I 
no longer wish to hang off the roof in order to maintain the ISS so I 
am relocating it to a spot in the yard that does not require a crane 
in order to get to.  I have switched the anemometer from hard wire in 
the ISS to plugging into a Davis wireless sensor transmitter.


The Weewx configuration file seems to be happy   seeing the ISS as 
Station 1 ( ISS = 1), but adding Station 2 on the next line 
(Anemometer = 2)  doesn't seem to be the hot setup.


If anyone has two Davis Vantage Pro stations feeding into Weewx, I'd 
appreciate seeing how they included the 2nd one in the configuration file.


BTW, the Davis Console is set up to see the 2nd station and reports 
its activity.  I also have an Envoy that I set up through Weathlink to 
see the 2nd station (menu driven Q & A) and have it plugged into the 
RPi.  I reports all data from the ISS, but not the anemometer and 
lists N/A alongside the Current Conditions for wind.


Now that I have just called up the page, I see that the Barometer 
shows the current reading but also shows (N/A) after the reading.


Any help would be greatly appreciated.

...Bob

--
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 
.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/fba19644-296a-4f6a-8c2a-4b76c304d42d%40googlegroups.com 
.


--
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/2d37435d-f2e4-58eb-e8ad-b6f4132b60ac%402pi.org.

Re: [weewx-user] MQTT Weewx authentication

2019-08-29 Thread Les Niles

It’s in https://github.com/weewx/weewx/wiki/mqtt — put the username/password 
before the server name:
server_url = mqtt://username:password@localhost:1883/

  -Les


> On Aug 29, 2019, at 4:08 AM, Rui Pinto  
> wrote:
> 
> Hello!!
> 
> I'm trying to publish data to a topic in the Mosquitto broker through 
> authentication. 
> I succedd without authentication but i wanted to publish data with 
> authentication.
> 
> I successfully changed the user and password in the mosquitto configurations, 
> but i don't know where do i put the username and password in the Weewx 
> configurations.
> 
> I don't know if i have to put the username and password in the weew.conf 
> file...
> Here's my configuration of MQTT in Weewx.conf: 
> 
> [StdRESTful]
> [[MQTT]]
>server_url = mqtt://localhost:1883/
>topic = weewx/default/default/VantagePro2
>unit_system = METRIC
> -- 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/63673c7b-da3a-4e5f-b865-ce802dd01c5f%40googlegroups.com.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/B8AC4681-CE64-499B-9205-D8BA69915B2F%40gmail.com.

Re: [weewx-user] Davis... IP Datalogger.

2019-07-17 Thread Les Niles

I'd suggest disabling the upload to weatherlink.  I don't think that 
should be necessary, but it removes a variable.


  -Les

On 7/15/19 4:39, Ruben Navarro Huedo wrote:

Hello friends:
I am trying to run last weewx with Davis and IP Datalogger.
I have other davis using USB Datalogger and all is fine.
IP Datalogger is uploading to weatherlink.com but it hasn't data for 
weewx at the archive interval.

How could i solve it?
I don't want upload to weatherlink... i only need data on weewx.

Thank's a lot.
--
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 
.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/be94f9c9-7ece-4671-9ba2-c1da0e9765ce%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/c809465d-64c6-265f-8a74-c77d23888947%402pi.org.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Belchertown Earthquake data error

2019-07-06 Thread Les Niles


The USGS web site was timing out pretty frequently after the big shocks.

  -Les

On 7/6/19 16:25, Patrick Mendiuk wrote:
I have been running the Belchertown skin without any errors for a 
while now and this started happening after the California 
earthquakes.  Is anyone else getting this error?


|
Jul616:04:26MITX-6930weewx[22281]:reportengine:Runningreport 'Belchertown'
Jul616:04:26MITX-6930weewx[22281]:reportengine:Foundconfiguration file 
/etc/weewx/skins/Belchertown/skin.conf forreport 'Belchertown'
Jul616:04:26MITX-6930weewx[22281]:cheetahgenerator:usingsearch list 
['weewx.cheetahgenerator.Almanac','weewx.cheetahgenerator.Station','weewx.cheetahgenerator.Current','weewx.cheetahgenerator.Stats','weewx.cheetahgenerator.UnitInfo','weewx.cheetahgenerator.Extras','user.belchertown.getData']

Jul616:04:26MITX-6930weewx[22281]:manager:Dailysummary version is2.0
Jul616:04:26MITX-6930weewx[22281]:reportengine:Caughtunrecoverable 
exception ingenerator 'weewx.cheetahgenerator.CheetahGenerator'

Jul616:04:26MITX-6930weewx[22281]:NoJSON objectcould be decoded
Jul616:04:26MITX-6930weewx[22281]:Traceback(most recent call last):
Jul616:04:26MITX-6930weewx[22281]:File"/usr/share/weewx/weewx/reportengine.py",line 
204,inrun

Jul616:04:26MITX-6930weewx[22281]: obj.start()
Jul616:04:26MITX-6930weewx[22281]:File"/usr/share/weewx/weewx/reportengine.py",line 
300,instart

Jul616:04:26MITX-6930weewx[22281]:self.run()
Jul616:04:26MITX-6930weewx[22281]:File"/usr/share/weewx/weewx/cheetahgenerator.py",line 
160,inrun
Jul616:04:26MITX-6930weewx[22281]: ngen 
=self.generate(gen_dict[section_name],self.gen_ts)
Jul616:04:26MITX-6930weewx[22281]:File"/usr/share/weewx/weewx/cheetahgenerator.py",line 
234,ingenerate
Jul616:04:26MITX-6930weewx[22281]: ngen 
+=self.generate(section[subsection],gen_ts)
Jul616:04:26MITX-6930weewx[22281]:File"/usr/share/weewx/weewx/cheetahgenerator.py",line 
234,ingenerate
Jul616:04:26MITX-6930weewx[22281]: ngen 
+=self.generate(section[subsection],gen_ts)
Jul616:04:26MITX-6930weewx[22281]:File"/usr/share/weewx/weewx/cheetahgenerator.py",line 
322,ingenerate

Jul616:04:26MITX-6930weewx[22281]: default_binding)
Jul616:04:26MITX-6930weewx[22281]:File"/usr/share/weewx/weewx/cheetahgenerator.py",line 
374,in_getSearchList
Jul616:04:26MITX-6930weewx[22281]: searchList 
+=obj.get_extension_list(timespan,db_lookup)
Jul616:04:26MITX-6930weewx[22281]:File"/usr/share/weewx/user/belchertown.py",line 
636,inget_extension_list

Jul616:04:26MITX-6930weewx[22281]: eqdata =json.load(read_file )
Jul616:04:26MITX-6930weewx[22281]:File"/usr/lib/python2.7/json/__init__.py",line 
291,inload

Jul616:04:26MITX-6930weewx[22281]:**kw)
Jul616:04:26MITX-6930weewx[22281]:File"/usr/lib/python2.7/json/__init__.py",line 
339,inloads

Jul616:04:26MITX-6930weewx[22281]:return_default_decoder.decode(s)
Jul616:04:26MITX-6930weewx[22281]:File"/usr/lib/python2.7/json/decoder.py",line 
364,indecode

Jul616:04:26MITX-6930weewx[22281]: 
obj,end=self.raw_decode(s,idx=_w(s,0).end())
Jul616:04:26MITX-6930weewx[22281]:File"/usr/lib/python2.7/json/decoder.py",line 
382,inraw_decode
Jul616:04:26MITX-6930weewx[22281]:raiseValueError("No JSON object 
could be decoded")
Jul616:04:26MITX-6930weewx[22281]:ValueError:NoJSON objectcould be 
decoded

Jul616:04:26MITX-6930weewx[22281]:Generatorterminated
Jul616:04:26MITX-6930weewx[22281]:copygenerator:copied 2files to 
/var/www/html

|

Patrick



--
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 
.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/195ff59a-8545-4db3-925e-7fa43f214fe2%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/f3b0c3df-34ad-81fe-e3c1-5a7a683142b5%402pi.org.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Chronology

2018-08-20 Thread Les Niles

It is possible to reset the mysql root password as long as you have root access 
to the OS it’s running on.  (Yes, I know this for the obvious reason….)  There 
are a couple of ways to do this; here’s one: 
https://www.digitalocean.com/community/tutorials/how-to-reset-your-mysql-or-mariadb-root-password
 


  -Les


> On 20 Aug 2018, at 11:49, Thomas Keffer  wrote:
> 
> John,
> 
> Please don't summarize what you're finding. Cut-and-paste explicitly into the 
> email. For example, when you say '**I get access denied**' when trying to use 
> mysql, did it prompt for a password first (it should have)? You should have 
> given it the MySQL root password you used when setting up MySQL. If you don't 
> remember it, then you're stuck. Reinstall, and this time remember it.  
> Incidentally, this is a good example of how MySQL is more difficult to manage.
> 
> I don't know what you mean by anything in the "grins and giggles" paragraph. 
> What "not found" error? And, again, don't summarize what you think you're 
> seeing in syslog --- post it. 
> 
> Don't take these setbacks personally. The RPi is not out to get you. Give it 
> the right commands and it will do the right thing.
> 
> -tk
> 
> 
> On Mon, Aug 20, 2018 at 11:32 AM John Clark  > wrote:
> 
> 
> On 8/20/2018 12:24 PM, Thomas Keffer wrote:
>> Nothing wrong with the Rapsberry Pi as a platform: thousands of WeeWX users 
>> are using it successfully. However, you should reconsider your decision to 
>> use MySQL if you are not familiar with it. It is much more complex to 
>> administer then the default sqlite database.
>> 
>> In any case, check the access permissions for user weewx. To do this, run 
>> 'mysql' either as user weewx or user root. Then use the SHOW GRANTS command:
>> 
>> $ mysql -u root -p
>> mysql> SHOW GRANTS FOR 'weewx'@'localhost';
> 
> $ mysql -u root -p **I get access denied**
> mysql> SHOW GRANTS FOR 'weewx'@'localhost'; **I get no results**
> 
> Just for grins and giggles I set it to use sqlite and it did "run" but there 
> was nothing displayed with "localhost/weewx" just the "not found"error and 
> according to the syslog it wasn't uploading to my website.
> 
> So, I am gonna give it a break before I use a hammer on it. THEN, I'm not 
> sure WHAT I'll do.
> -- 
> John Clark 
> 
> -- 
> 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 
> .

-- 
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: Simultaneous clone to mySQL for weewx and weewx-WD?

2018-01-06 Thread Les Niles

Yup, I should’ve mentioned that it’s not particularly fast.  But that’s OK, 
it’s not well tested either. :)
Let me know if it works out for you, and if any issues crop up.  

  -Les

> On 6 Jan 2018, at 19:23, Chris Alemany  wrote:
> 
> initial run is on the go... 11,000 of 1.2 million records already done.  
> Gonna be a minute or 500 :)
> 
> On Saturday, January 6, 2018 at 7:05:12 PM UTC-8, Chris Alemany wrote:
> Thanks! I'll let you know how it goes!
> 
> On Saturday, January 6, 2018 at 6:51:03 PM UTC-8, ln77 wrote:
> Yes,  I forgot to attach the conf file the first time.  The attached has 
> examples for both mysql and sqlite, for both source & destination.  For 
> mysql, the host, user, and password of course need to be filled in; likewise 
> for the path(s) to the sqlite database file(s).  The database name for a 
> mysql destination can be whatever you want; in particular, “weewx” would work 
> fine if you’ve got another weewx installation reading from that db.
> 
>   -Les
> 
> 
> -- 
> 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: Simultaneous clone to mySQL for weewx and weewx-WD?

2018-01-06 Thread Les Niles

Yes, I forgot to attach the conf file the first time. The attached has examples for both mysql and sqlite, for both source & destination. For mysql, the host, user, and password of course need to be filled in; likewise for the path(s) to the sqlite database file(s). The database name for a mysql destination can be whatever you want; in particular, “weewx” would work fine if you’ve got another weewx installation reading from that db. -Les

dbackup.conf
Description: Binary data

wee_dbackup
Description: Binary data
On 6 Jan 2018, at 18:34, Chris Alemany wrote:This is great Les thank you! That sounds very much like a tool that could work. Do you have an example dbackup.conf I could use?On Friday, January 5, 2018 at 2:11:42 PM UTC-8, ln77 wrote:I wrote a little tool for syncing weewx data from one database to another, which I think can address Chris’ cloning request. It’s weewx-specific — when run, it copies all archive records from the source database that are later than the latest record in the destination database, to the destination database. The motivation was to do incremental backups to a remote mysql database, though mysql’s built-in cloning might be better for that. But it uses weewx’s database interface so it is supports the same types of databases and access that weewx does, with the same configuration files. To do the cloning it just needs to get fired off after every archive interval, either from a cron job or by packaging as a report generator. To use from a cron job or manually, put it in the same directory as wee_reports, wee_extension, etc. The comment describes the config file(s) that specify the source and destination. The intent is that weewx.conf will specify the source in the usual case where the source is the active weewx database. The destination specification can be added to weewx.conf, or put in a separate config file. -LesOn 5 Jan 2018, at 11:59, vince wrote:On Friday, January 5, 2018 at 11:06:27 AM UTC-8, Huw Pearce wrote:SQLite-sync - ampliapps.comhttps://ampliapps.com/sqlite-sync/yeccch - requires tomcat and it's binary onlycool idea though

Re: [weewx-user] Re: Simultaneous clone to mySQL for weewx and weewx-WD?

2018-01-05 Thread Les Niles

I wrote a little tool for syncing weewx data from one database to another, which I think can address Chris’ cloning request. It’s weewx-specific — when run, it copies all archive records from the source database that are later than the latest record in the destination database, to the destination database. The motivation was to do incremental backups to a remote mysql database, though mysql’s built-in cloning might be better for that. But it uses weewx’s database interface so it is supports the same types of databases and access that weewx does, with the same configuration files. To do the cloning it just needs to get fired off after every archive interval, either from a cron job or by packaging as a report generator. To use from a cron job or manually, put it in the same directory as wee_reports, wee_extension, etc. The comment describes the config file(s) that specify the source and destination. The intent is that weewx.conf will specify the source in the usual case where the source is the active weewx database. The destination specification can be added to weewx.conf, or put in a separate config file. -LesOn 5 Jan 2018, at 11:59, vince wrote:On Friday, January 5, 2018 at 11:06:27 AM UTC-8, Huw Pearce wrote:SQLite-sync - ampliapps.comhttps://ampliapps.com/sqlite-sync/yeccch - requires tomcat and it's binary onlycool idea though

wee_dbackup
Description: Binary data

Re: [weewx-user] Error 110 timeout on Raspbian 9

2018-01-01 Thread Les Niles

BTW, I run on mysql but I think there’s also a permission issue in creating the 
sqlite database file when running non-root, solved by pre-creating the file and 
setting its ownership.

  -Les

> On 1 Jan 2018, at 16:05, Les Niles <niles@gmail.com> wrote:
> 
> Under what user ID are you running weewx?  I install from the debian package 
> on a Raspberry Pi, and have to work around some permission issues related to 
> running non-root.  IIRC, there are two:
> * weewx can’t create the PID file in /var/run, causing it to exit almost 
> immediately.  My hack is putting lines in the startup script (actually in 
> /etc/defaults/weewx) to touch /var/run/weewx.pid and to chown that file to 
> the weewx user ID.
> * weewx can’t create the html, etc. files because it can’t write to 
> /var/www/html. Solution is to manually create weewx's html directory and make 
> that directory owned by the weewx user ID. 
> 
>   -Les
> 
> 
>> On 1 Jan 2018, at 9:25, Cycle London <cycle.london...@gmail.com 
>> <mailto:cycle.london...@gmail.com>> wrote:
>> 
>> Yeah, I'm a friend of UNIX.  30 years of administering first Solaris, then 
>> RHEL and Slackware, FreeBSD, HP-UX and SCO UNIX.  But zero knowledge of 
>> Python, so completely unable to troubleshoot this.   And most of my days now 
>> are taken up with CentOS and RHEL, and I don't use apache2.  
>> 
>> Anyway, the system now appears to be running. 
>> 
>> root@weather:~# ps -ef | grep weather
>> avahi  322 1  0  2017 ?00:00:17 avahi-daemon: running 
>> [weather.local]
>> 
>> Still nothing in the HTML_ROOT however.  That's fine I guess since it's 
>> aliasing to /home/weewx/public_html but what should the permissions be on 
>> that directory?  
>> 
>> drwxr-xr-x  6 root root  4096 Jan  1 17:20 public_html
>> 
>> And lynx localhost/weewx` still returns a 404 (with nothing in the httpd log 
>> but just that: 404).
>> 
>> Trying to hit the Pi on http from my Mac also returns a 404, which isn't 
>> anything to do with name resolution as the Pi is in DNS and I can ping it on 
>> its FQDN. 
>> 
>> Stumped, now.
>> 
>> 
>> On 1 January 2018 at 15:45, mwall <mw...@users.sourceforge.net 
>> <mailto:mw...@users.sourceforge.net>> wrote:
>> On Monday, January 1, 2018 at 9:33:55 AM UTC-5, Cycle London wrote:
>> Now I seem to have broken the entire thing.  I decided to try the python 
>> installation method, so ran `apt-get remove weewx` and then downloaded the 
>> tarball to try a manual installation. 
>> 
>> This time, there is content in /var/www/html but hardly anything (except 
>> user) under /usr/share/weewx.  Everything is under /home but even when I 
>> place the new driver into /usr/share/weewx/user and modify the configuration 
>> file, I still get... 
>> 
>> welcome to "unix is user-friendly, it is just picky about who its friends 
>> are"
>> 
>> there are a few things you should understand about debian linux and about 
>> python.
>> 
>> 1) setup.py and apt-get are not compatible
>> 
>> you really should use one or the other.  the weewx wiki has instructions 
>> about how to change from one to the other.
>> 
>> https://github.com/weewx/weewx/wiki/How%20to%20convert%20from%20setup.py%20install%20to%20debian%20install
>>  
>> <https://github.com/weewx/weewx/wiki/How%20to%20convert%20from%20setup.py%20install%20to%20debian%20install>
>> 
>> 2) how to use apt-get
>> 
>> apt-get install weewx
>> apt-get remove weewx
>> apt-get purge weewx
>> 
>> install does both initial installation as well as updates (but not upgrades)
>> 
>> three different commands which do three different things.  remove does not 
>> destroy any configuration files, especially not any that you have modified.  
>> it also does not remove any debconf values.
>> 
>> purge deletes all configuration files and debconf values.  it does not touch 
>> any weewx data (nominally /var/lib/weewx/weewx.sdb)
>> 
>> for the state diagrams, see:
>> 
>> https://www.debian.org/doc/debian-policy/#maintainer-script-flowcharts 
>> <https://www.debian.org/doc/debian-policy/#maintainer-script-flowcharts>
>> 
>> we try to test installer stuff, but as you can see the surface area for 
>> testing is massive.  so if you can clarify any procedures you make that 
>> result in unexpected results, that makes it more likely that someone will 
>> fix it.
>> 
>> 3) python coders are lazy, and that is a good thing
>> 
>> weewx d

Re: [weewx-user] Error 110 timeout on Raspbian 9

2018-01-01 Thread Les Niles

Under what user ID are you running weewx?  I install from the debian package on 
a Raspberry Pi, and have to work around some permission issues related to 
running non-root.  IIRC, there are two:
* weewx can’t create the PID file in /var/run, causing it to exit almost 
immediately.  My hack is putting lines in the startup script (actually in 
/etc/defaults/weewx) to touch /var/run/weewx.pid and to chown that file to the 
weewx user ID.
* weewx can’t create the html, etc. files because it can’t write to 
/var/www/html. Solution is to manually create weewx's html directory and make 
that directory owned by the weewx user ID. 

  -Les


> On 1 Jan 2018, at 9:25, Cycle London  wrote:
> 
> Yeah, I'm a friend of UNIX.  30 years of administering first Solaris, then 
> RHEL and Slackware, FreeBSD, HP-UX and SCO UNIX.  But zero knowledge of 
> Python, so completely unable to troubleshoot this.   And most of my days now 
> are taken up with CentOS and RHEL, and I don't use apache2.  
> 
> Anyway, the system now appears to be running. 
> 
> root@weather:~# ps -ef | grep weather
> avahi  322 1  0  2017 ?00:00:17 avahi-daemon: running 
> [weather.local]
> 
> Still nothing in the HTML_ROOT however.  That's fine I guess since it's 
> aliasing to /home/weewx/public_html but what should the permissions be on 
> that directory?  
> 
> drwxr-xr-x  6 root root  4096 Jan  1 17:20 public_html
> 
> And lynx localhost/weewx` still returns a 404 (with nothing in the httpd log 
> but just that: 404).
> 
> Trying to hit the Pi on http from my Mac also returns a 404, which isn't 
> anything to do with name resolution as the Pi is in DNS and I can ping it on 
> its FQDN. 
> 
> Stumped, now.
> 
> 
> On 1 January 2018 at 15:45, mwall  > wrote:
> On Monday, January 1, 2018 at 9:33:55 AM UTC-5, Cycle London wrote:
> Now I seem to have broken the entire thing.  I decided to try the python 
> installation method, so ran `apt-get remove weewx` and then downloaded the 
> tarball to try a manual installation. 
> 
> This time, there is content in /var/www/html but hardly anything (except 
> user) under /usr/share/weewx.  Everything is under /home but even when I 
> place the new driver into /usr/share/weewx/user and modify the configuration 
> file, I still get... 
> 
> welcome to "unix is user-friendly, it is just picky about who its friends are"
> 
> there are a few things you should understand about debian linux and about 
> python.
> 
> 1) setup.py and apt-get are not compatible
> 
> you really should use one or the other.  the weewx wiki has instructions 
> about how to change from one to the other.
> 
> https://github.com/weewx/weewx/wiki/How%20to%20convert%20from%20setup.py%20install%20to%20debian%20install
>  
> 
> 
> 2) how to use apt-get
> 
> apt-get install weewx
> apt-get remove weewx
> apt-get purge weewx
> 
> install does both initial installation as well as updates (but not upgrades)
> 
> three different commands which do three different things.  remove does not 
> destroy any configuration files, especially not any that you have modified.  
> it also does not remove any debconf values.
> 
> purge deletes all configuration files and debconf values.  it does not touch 
> any weewx data (nominally /var/lib/weewx/weewx.sdb)
> 
> for the state diagrams, see:
> 
> https://www.debian.org/doc/debian-policy/#maintainer-script-flowcharts 
> 
> 
> we try to test installer stuff, but as you can see the surface area for 
> testing is massive.  so if you can clarify any procedures you make that 
> result in unexpected results, that makes it more likely that someone will fix 
> it.
> 
> 3) python coders are lazy, and that is a good thing
> 
> weewx does not create a database until it has to use it
> 
> weewx does not create the html directory or any files in that directory until 
> it has something to write.  in a default installation, that means you will 
> not see anything until after the first archive interval (nominally 5 minutes, 
> but it depends on your configuration).
> 
> 4) you almost never need to reinstall the operating system.  linux is not 
> windows, no matter how much certain redhat employees would like to make it so.
> 
> hope that helps!
> 
> m
>  
> 
> -- 
> 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/iGXSDG5XsOQ/unsubscribe 
> .
> To unsubscribe from this group and all its topics, send an email to 
> weewx-user+unsubscr...@googlegroups.com 
> .
> For more options, visit

Re: [weewx-user] Anyone using the La Crosse 330-2315 Professional Weather Station with weewx

2017-12-29 Thread Les Niles

I don’t see any interface for getting the data from that console, other than 
its wifi that appears to be specialized to posting the data to weather 
underground, so it doesn’t support weewx in the usual way.

But there’s hope! I ran across this posting on the wxforum Lacrosse topic 
https://www.wxforum.net/index.php?topic=30932.msg335582#msg335582 
 from 
someone who’s doing what you want to do, by sniffing the data.  I’d assume that 
means the console is configured to post to weather underground, with some code 
on the RPi sniffing the network connection and extracting the data.  Not sure 
if this was discussed on this forum but you might contact the author directly.

  -Les

> On 29 Dec 2017, at 8:54, Ted Bevenour  wrote:
> 
> So Santa brought me this station 
> 
>  for xmas this year... I'd like to run weewx on a RPi and access the stations 
> data that way. I didn't see this particular model listed on the hardware 
> page, but was curious if anyone might be using it anyway.
> 
> I'm guess this is probably a no, but thought I'd ask anyway.
> 
> Thanks in advance,
> 
> // Ted
> 
> --
> 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.

signature.asc
Description: Message signed with OpenPGP

Re: [weewx-user] Re: Assistance please

2017-11-19 Thread Les Niles

Try this. I didn’t see aprs.tar.gz posted anywhere, so I just built this by cloning the git archive and tarring it up. It seems to work on my weewx, though I don’t know if the generated packet is actually correct. -Les

aprs.tar.gz
Description: GNU Zip compressed data

On 19 Nov 2017, at 8:37, Jerry Kutche wrote:I think I need the aprs.tar.gz file it is not on the site that has this extension... can anyone send It to me or tell me where to Download it.. Google is no help with searching for aprs.tar.gz except heads me to the same dead end. ThanksOn Sunday, November 19, 2017 at 11:04:53 AM UTC-5, Jerry Kutche wrote:Good day all, I just installed weewx and removed wview from my new Pi3 Running Raspbian Stretch Very nice and easy install.My question is I need a file APRS formatted to my LinBPQ software can grab it and tx it on RF I am not sure if a file like that exists in weewx. I read about an extension for weewx but when I follow instructions.. all I get are errors.. Can some one point me in the correct direction. Thanks Jerry N9LYAroot@raspberrypi:~# wee_extension --install aprs.tar.gzRequest to install 'aprs.tar.gz'Traceback (most recent call last): File "/usr/bin/wee_extension", line 83, in main() File "/usr/bin/wee_extension", line 75, in main ext.install_extension(options.install) File "/usr/share/weewx/weecfg/extension.py", line 124, in install_extension raise InstallError("Extension '%s' not found." % extension_path)weecfg.extension.InstallError: Extension 'aprs.tar.gz' not found.root@raspberrypi:~# userspi pi rootroot@raspberrypi:~#

signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [weewx-user] RTC vs NTP on Raspberry Pi 3

2017-03-12 Thread Les Niles

The problem with not having an RTC is mostly around startup, when the system 
time has not yet been set by NTP.  Starting weewx can be delayed until the 
system time is set, but that becomes problematic if the internet connection 
isn’t available or is delayed when the system boots.  Not having an RTC also 
makes things like boot-time log analysis more difficult since the system clock 
doesn’t get set until much later.  It can work, especially if you have a very 
reliable internet connection, but is more brittle.  Once it’s running, NTP is 
plenty accurate, better than the RTC in fact.  Unless you need those GPIO pins 
for something else, five bucks for an RTC module is a good investment, IMHO.

  -Les 

> On 12 Mar 2017, at 13:38, Francisco Puig  wrote:
> 
> Anyone here is using an RTC (hardware) on a raspberry pi ? I'm trying to find 
> data of if this is really necessary for the reports accuracy even when the pi 
> is connected to the internet using the raspbian pre-configured NTP.
> 
> 
> 
> -- 
> 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: Is it worth swapping from fine offset to Davis Vantage?

2016-12-13 Thread Les Niles

One of the factors that led me to go with Davis is the wind update rate. When 
it's really blowing it's usually pretty gusty and I want to see something 
approaching real time. I'd never believe an anemometer that's only showing 30 
second averages or even 30 second latency.  Also, after doing some research, 
and my own experiments with stand-alone thermometers, I decided that a 
fan-aspirated radiation shield was going to be necessary to get reasonably 
accurate temperatures. 

That pretty much means a VP2. The other problem with integrated instruments 
like the Vue is that the anemometer really should be sited differently than the 
temp and rain collector. My anemometer is 25' above the roof, on a pole that 
couldn't support an integrated instrument package (and that would be a bad 
place to measure temperature anyway). The rain collector and thermometer should 
also be sited somewhat differently but putting them together is not so much of 
a compromise. So while the Vue may measure accurately, putting all the 
instruments in one package ends up making the weather data less accurate than 
it could be. 

  -Les

> On Dec 13, 2016, at 3:20 PM, vince  wrote:
> 
>> On Tuesday, December 13, 2016 at 2:29:17 PM UTC-8, pon...@gmail.com wrote:
>>  I'd rather just buy a "VW" that works (not a Rolls Royce). It's certainly 
>> been interesting to see the reports of driver problems with other hardware. 
>> Working with weewx is now a requirement for me and I wouldn't consider 
>> anything that doesn't. Thanks again. 
>> 
> 
> You have to ask yourself what your time and stress level are worth to you. 
> Personally, I spent the money for the VP2 a long time ago.  Worth it for me.
> 
> Back then, the Vue was just announced, so I didn't go with a model new to 
> market. I'd probably go with the Vue if I was buying today, due to its 
> smaller size, unless there were quality or accuracy things saying it wasn't 
> comparable in quality that I haven't been keeping up with.
> 
> And Davis support was 'great' the two times I had to contact them.  They even 
> sent me a ISS circuit board replacement a month 'after' mine was out of 
> support.  Great service.
> 
> 
> -- 
> 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] USB over Ethernet & Belfryboy Clone USB logger

2016-08-22 Thread Les Niles

> On 22 Aug 2016, at 8:34, vince  > wrote:
> 
> On Monday, August 22, 2016 at 8:24:13 AM UTC-7, ln77 wrote:
> At the risk of being one of "those guys" who replies to a simple question 
> with a redesign of the system:
> Why not run weewx on a tiny computer -- a raspberry Pi or similar-- that's 
> directly connected to the USB cable and upload the web pages (and 
> sync/archive the data if you want) to the Debian server over the LAN? The 
> little computer shouldn't cost much more or be much bigger than the 
> USB-over-Ethernet adapter, and there'll probably be a lot less fiddling to 
> get it working reliably. 
> 
> My answer here to that would be "it's not always money as the limiting 
> factor".   Sometimes you don't want more computers period.  Sometimes you 
> have box-A onsite in one place, but you can't put anything else close to it 
> physically. Sometimes finding a way to do unusual stuff is part of the 
> adventure itself.

Sure, there are plenty of generic reasons why it might not be a good solution. 
I was just wondering about zkab’s reasons in particular — which he has answered 
— given that USB-over-ethernet adapters are really not that different in terms 
of hardware than one of these credit-card computers.  

  -Les

-- 
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] USB over Ethernet & Belfryboy Clone USB logger

2016-08-22 Thread Les Niles

At the risk of being one of "those guys" who replies to a simple question with 
a redesign of the system:
Why not run weewx on a tiny computer -- a raspberry Pi or similar-- that's 
directly connected to the USB cable and upload the web pages (and sync/archive 
the data if you want) to the Debian server over the LAN? The little computer 
shouldn't cost much more or be much bigger than the USB-over-Ethernet adapter, 
and there'll probably be a lot less fiddling to get it working reliably. 

  -Les


> On Aug 22, 2016, at 5:48 AM, Thomas Keffer  wrote:
> 
> I seem to recall several people doing just that, albeit using a conventional 
> Davis logger. Search the archives.
> 
> My hunch is that the results will not be super reliable, but it can probably 
> be made to work.
> 
> -tk
> 
>> On Mon, Aug 22, 2016 at 5:38 AM, zkab  wrote:
>> I have ordered Belfryboy Clone USB logger to use with Vantage Vue Console 
>> and I will run weewx in a Debian server.
>> Problem is that the Deb server is in another building than the Vue Console 
>> but I have a LAN available in the premises.
>> Can I use a USB over Ethernet adapter to connect the logger to my Deb server 
>> ?
>> 
>> -- 
>> 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.

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

66 matches

Mail list logo