[weewx-user] Re: Crash with log info

[vk3anz]

AAGGHH - this is what happens when you try to refactor your code and forget 
about variable scoping.
The 'network_retry_count' variable IS set (with the line you added) in line 
493 which is right at the start of the 'getLoopPackets' function.
The next part of the process is to use the 'self.connectToWeatherStation()' 
function which originally only existed where the function call is located. 
However when I added the functionality to read the history data, I needed 
to connect to the weather station from several places and so I moved the 
code into a separate function. Of course that is when I forgot about the 
scope of the variable!
It also shows that my network is fairly reliable as I've obviously never 
triggered that error condition in my testing.
My apologies for the bugs and my thanks for helping me find them.
I'll update my repository tonight (hopefully).
Susan

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Crash with log info

[vk3anz]

I've updated the files in github with the error fix(es) that Ron suggested.
I have *NOT* tested this with the latest version of Weewx nor with the 
Python 3 version - that work is yet to come.
Susan

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Crash with log info

[vk3anz]

I'm not sure what this means but if it works then great.

On Monday, April 8, 2019 at 8:59:13 PM UTC+10, Ron wrote:
>
> Oh, in my repo I also changed the formatting of the installation steps in 
> the README file. Githubs markdown was smushing them all onto a single line 
> and eating the portions of the commands saying to insert the HP1000 
> directory.


You have uncovered a bug in my code that has been there all along with 
regard to the 'sleep' command. As I mentioned above, there is a 
'sleep'command in the genLoopPackates function that stops the weather 
station being accessed too frequently. in *that* call to 'sleep' I *do* 
prefix it with 'time.' but in all other cases I don't. I guess it shows 
that I hadn't checked all of the error code paths well enough!!!

The only word of warning I'd make is that anyone using your code will get 
the additional 'loginf' messages as it is reading in the history 
packets.(BTW, in line 785 of your file, the 'loginf' is after the 'raise' 
so probably won;t get actioned.)

Thanks for the assistance on this - I'll update my repository over the next 
few days as time permits (my daughter is about to make me a 'Grannie' 
again).

Susan

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Crash with log info

[vk3anz]

Also which version of weewx are you running?

I've not tested the HP1000 driver with the latest version (I know, I know).

Susan

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Crash with log info

[vk3anz]

Sorry everyone but I've only just seen this thread (it would have helped if 
the title referenced the HP1000 driver).

As for the unpacking error - that would indicate that the packet from the 
HP1000 itself has altered, especially if it was working and then stopped.
Has something been updated - if so what?

Regarding the 'sleep' error, the 'time' namespace should be added to the 
global namespace. As Ron mentions, 'sleep' is used in several places, 
including the main packet generation loop (to stop it trying to access the 
weather station multiple times a second). Therefore if it has worked at all 
then it also indicates that something else has changed.

BTW - are these systems running under the weewx Python 3 version? If so 
then I have not made any attempt (yet!) to have the code run under that 
version. (When I wrote this, the answer about Python 3 as generally 'too 
hard at this time' so I wrote it for Python 2.7; the same as weewx itself.)

I'll try to have a look at these issues tonight (no promises).

Susan

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Can Weewx send alerts if it stops reporting?

[vk3anz]

It comes down to the source of the failure you want to monitor.
Using systemd will let you restart weewx if it stops running  but will not 
detect it looping or otherwise 'working' (as seen by the OS). It also won't 
detect a OS crash or power down.
if you just want the appearance of a file or data records etc. on some 
external computer (whether inside or outside your LAN) then you could set 
up something like an MQTT broker and have an app that subscribes tot he 
packets and does whatever you want if something is not received - a bit 
like a 'heartbeat monitor' app. However this would show you an error if 
anything between weewx and the subscriber was not working, not weewx 
specifically.
Susan

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: (Off Topic?) How does weewx tell systemctl it is running

[vk3anz]

OK - I found the problem and the underlying fault is mine (as usual)!
What was happening is, during the startup phase, the driver was reading the 
'historic' records from the weather station. It reads these in batches and 
then processes therm into the database (and any other places that Weewx 
sends the records - in my case this is WOW, CWOP and the local 
Meteotemplate).
It then goes back to read the next batch of records and repeats until it is 
up to date. It then moves to the normal loop phase.
What was happening is that the time to process each 'batch' of records 
(about 2 minutes as it turned out) was longer than the weather station 
maintained the link - when the driver went back to read the next match it 
got a 'broken pipe' error. However, in trying to get things written in the 
first place, I had inadvertently told Python to let the default error 
handler process this error which it did by silently stopping the 
program.
The solution is to process in smaller batches, let Python tell the program 
of the error and then handle it properly.
As far as systemd is concerned, it saw the program stop and restarted it, 
so it was doing exactly what it was supposed to do.
During the initial testing, I was processing the historical records only 
back to the database and so it was occurring fairly quickly. I suspect (but 
have not confirmed) that adding in the connections to the other places - 
especially WOW as I get a number of log entries about retry failures to 
there - has added the extra time and led to the 'broken pipe' timeout.
I've re-written that part of the driver and loaded it back into the Github 
repository.
Susan

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: RPI and Saving Files to NAS

[vk3anz]

The entry to the drive (whichis the root for weewx) is:
x.x.x.x:/volume1/weewx/home/weewx   nfs  
 defaults,nofail,noatime,nolock,intr   0   0

Of course the first part is the reference to the NAS folder

Susan

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: RPI and Saving Files to NAS

[vk3anz]

I have Weewx running on a RPi (zero, also used 3B+) that connects to my 
Synology NAS via WiFi.The entire Weewx folder lives on the NAS so that the 
data base and regularly generated files all live on storage that is not so 
prone to wearing out.
I also use systemd to make sure that the network is up and the NAS drive is 
mounted before it tries to start Weewx.
Worked nicely and has done for a couple of years now.
(I also use a memory drive for the log files - in theory the SD card has 
very minimal writes to it.)
Susan

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: use Weewx on raspberry

[vk3anz]

You need to make sure that the weewx bin directory is in the PYTHONPATH.

I've just run weewx from python, but something like 

$ PYTHONPATH=/home/weewx/bin thonny..

- Use whatever the location of weewx is and whatever command you use to 
invoke thonny.

Susan

On Friday, December 21, 2018 at 6:03:05 AM UTC+11, Patrick Tranchant wrote:
>
> hello Pat,
>
> I try to run the script with Thonny, and I have an error on line" import 
> weedb" => ImportError : No Module named "weedb"
> problem with the path !!!
>
> Patrick
>
> On Saturday, December 8, 2018 at 3:40:43 PM UTC+1, Patrick Tranchant wrote:
>>
>> hello I am a newbie from France ( sorry for my english )
>>
>> I want to use weewx on a raspberry with a weather station built by myself 
>> (view on Magpi)
>> I don't see my station on your website to configure :
>>
>> Weather Station Hardware Comparison: I don't found my weather station.
>> Do you have a solution or how to configure Weewx
>>
>> thank you for your help
>>
>> 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: (Off Topic?) How does weewx tell systemctl it is running

[vk3anz]

Thanks everyone.

Some responses:
- the log I showed in the OP was from journalctl - thanks for the 
suggestion though
- I didn't think that weewx as doing something special during the 
'genStartupRecords' step but I just wanted to check
- I did Google those messages and (as with the replies here) they so often 
degenerate into a 'systemd is bad/dumb/' argument without 
addressing the underlying issue/questions being asked; also running the 
latest Rasbian versions you don't really have a choice as the SysV init 
files are used to dynamically create the service files - that is why I 
created my own as the conversion did not do any of the required dependency 
checking.
- weewx *is * being stopped and started again as the snippets of  the log 
show - and there is only one process with weewx running in it on the system 
as a 'ps -aux' shows
- learning what I can about systemd, I suspect that the message about 
monitoring the PID file is a bit misleading; it would appear to come up 
when systemd finds a PID file already in existence but the process not 
running and restarts a new process - the new PID file does hold the new 
Process ID and the PID reported is the correct new one
- mwall - the thread you referenced has my comments in it already; the key 
difference is that the original question there does not reference any error 
messages before the crash - at least I'm getting that one about the holdoff 
timer (even if I still don't understand why). Also the system  itself keeps 
running in my case rather than what appears to be a (silent) system crash

So the question now seems to be why systemd is not detecting (on its own) 
that weewx is running while it is reading the historical records, but is 
detecting that it is running once that is complete?

Back to the books (err Google searches).

Thanks all

Susan

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] (Off Topic?) How does weewx tell systemctl it is running

[vk3anz]

(Note: Probably off topic but weewx related)

I am running weewx (on a raspberry Pi Zero) and I'm seeing something that I 
can't explain

Using my HP1000 driver to access my WS1001, weewx and the driver seem to be 
doing what they should in that the driver is reading the old records that 
it missed while it was stopped as shown in the following log:

Dec 11 20:02:02 weather weewx[1181]: manager: added record 2018-12-11 19:47:
51 AEDT (1544518071) to daily summary in 'weewx.sdb'

Dec 11 20:02:02 weather weewx[1181]: manager: added record 2018-12-11 19:52:
51 AEDT (1544518371) to database 'weewx.sdb'

Dec 11 20:02:02 weather weewx[1181]: manager: added record 2018-12-11 19:52:
51 AEDT (1544518371) to daily summary in 'weewx.sdb'

Dec 11 20:02:02 weather weewx[1181]: restx: Meteotemplate: Published record 
2018-12-11 19:47:51 AEDT (1544518071)

Dec 11 20:02:02 weather weewx[1181]: restx: WOW: Published record 2018-12-11 
15:37:51 AEDT (1544503071)

Dec 11 20:02:08 weather systemd[1]: weewx.service holdoff time over, 
scheduling restart.

Dec 11 20:02:08 weather systemd[1]: Stopping weewx weather system...

Dec 11 20:02:08 weather systemd[1]: Starting weewx weather system...

Dec 11 20:02:08 weather systemd[1]: Started weewx weather system.

Dec 11 20:02:09 weather weewx[1274]: engine: Initializing weewx version 3.6.
2

Dec 11 20:02:09 weather weewx[1274]: engine: Using Python 2.7.9 (default, 
Sep 26 2018, 05:58:52) 

 [GCC 4.9.2]

Dec 11 20:02:09 weather weewx[1274]: engine: Platform Linux-4.9.35+-armv6l-
with-debian-8.0

Dec 11 20:02:09 weather weewx[1274]: engine: pid file is /var/run/weewx.pid

Dec 11 20:02:09 weather systemd[1]: weewx.service: Supervising process 1278 
which is not our child. We'll most likely not notice when it exits.

Dec 11 20:02:09 weather weewx[1278]: engine: Using configuration file 
/home/weewx/weewx.conf

Dec 11 20:02:09 weather weewx[1278]: engine: Loading station type HP1000 
(user.HP1000)

Then after about 2 minutes of weewx running, I get the message from 
systemctl that the holdoff time is over and it restarts the service.

However, when all of the historic records have been read and weewx starts 
its main loop, then the service is not restarted by systemctl:

Dec 11 20:02:10 weather weewx[1278]: engine: Starting up weewx version 3.6.2

Dec 11 20:02:11 weather weewx[1278]: HP1000: Connected to address (
'10.1.1.97', 53495)

Dec 11 20:02:12 weather weewx[1278]: HP1000: Established contact at 11/12/18 
20:02:12

Dec 11 20:02:12 weather weewx[1278]: HP1000: Retrieving startup records

Dec 11 20:02:30 weather weewx[1278]: engine: Starting main packet loop.

Dec 11 20:03:22 weather wpa_supplicant[453]: wlan0: WPA: Group rekeying 
completed with b8:8d:12:5f:bf:7b [GTK=CCMP]

Dec 11 20:04:00 weather python[705]: INFO:apscheduler.executors.default:
Running job "bomIRJob (trigger: cron[minute='4-55/10'], next run at: 
2018-12-11 20:04:00 AEDT)" (scheduled at 2018-12-11 20:04:00+11:00)

Dec 11 20:04:00 weather animatedgif.py[705]: Running BoM IR Satellite at 11/
12/2018 20:04:00

Dec 11 20:04:00 weather python[705]: INFO:apscheduler.executors.default:
Running job "bomRadarJob (trigger: cron[minute='4-58/6'], next run at: 
2018-12-11 20:04:00 AEDT)" (scheduled at 2018-12-11 20:04:00+11:00)

Dec 11 20:04:00 weather animatedgif.py[705]: Running BoM Radar at 11/12/2018 
20:04:00

Dec 11 20:04:05 weather python[705]: INFO:apscheduler.executors.default:Job 
"bomRadarJob 
(trigger: cron[minute='4-58/6'], next run at: 2018-12-11 20:10:00 AEDT)" 
executed successfully

Dec 11 20:05:01 weather CRON[1284]: pam_unix(cron:session): session opened 
for user root by (uid=0)

Dec 11 20:05:01 weather CRON[1288]: (root) CMD (command -v debian-sa1 > 
/dev/null && debian-sa1 1 1)

Dec 11 20:05:01 weather CRON[1284]: pam_unix(cron:session): session closed 
for user root

Dec 11 20:05:24 weather weewx[1278]: manager: added record 2018-12-11 20:05:
00 AEDT (1544519100) to database 'weewx.sdb'

Dec 11 20:05:24 weather weewx[1278]: manager: added record 2018-12-11 20:05:
00 AEDT (1544519100) to daily summary in 'weewx.sdb'

You can see by the timestamps that the service is allowed to run.

Does anyone know what weewx does when in the main packet loop that tells 
systemctl that the service is running in the 'genLoopPackets' area that it 
does not do in the 'genStartuprecords' space?

Susan


-- 
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: weewx abends with no reason

[vk3anz]

I'm not sure what procedure you are talking about with the 'historic' 
values.

As far as the HP1000 driver is concerned, it looks at the last date in the 
weewx database and then queries the weather station for any records it has 
for after that date. Therefore it typically only downloads historic data 
since the last time the driver talked to the weather station (often hours 
or perhaps a day or two).

Even when I was testing it out (about a year ago), I managed to download 
all of the data from the weather station back to about September 2016. I 
know that this is the "my light bulb works; don't know why yours is broken" 
defence but I do know that it *can* work.

Also, does the weewx database hold the historic data for you? You might not 
be able to push that back to the weather station but does that really 
matter?

Susan

On Monday, December 3, 2018 at 9:54:07 PM UTC+11, Gary Hopkins wrote:
>
> OK Update.
>
> I did get the new Pi but I've not installed it with weewx.
>
> I was "fiddling" with the historic values on the WS and I went to delete 
> all the 2017 ones. Instead I accidentally deleted the 2018 ones so by then 
> it was too late.
>
> Once I'd gone back and deleted all the 2017 entries and there was no 
> longer any historical data to download everything is working fine and has 
> been since Saturday.
>
> I suspect that there is something "wrong" with pulling down the historical 
> data that was causing something to fail. Downloading "live" data and 
> running all the reporting scripts is working without a hitch. I'll just 
> live with the fact that I've lost all my historic data on the WS. 
>
> Thanks again for all your suggestions and 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: weewx abends with no reason

[vk3anz]

I must be missing something but I can't see any error messages in the logs 
posted so far. Without those it i shard to guess what is going on.

As far as I am aware, I don't have any try-except blocks that capture and 
ignore everything and if an error occurs in the HP1000 driver that I don't 
catch then the main weewx driver manager code does and give a trace-back.

Susan

On Sunday, December 2, 2018 at 1:32:57 AM UTC+11, mwall wrote:
>
> @aussisusan (or some enterprising python sleuth) will probably have to 
> help you at this point.  you'll have to check the code for cases where a 
> try-except block is catching all exceptions, not just the intended 
> exception.  a generic catch block like that will hide the exception trace 
> that would otherwise tell you where the failure is coming from.
>
>

-- 
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] Belchertown skin for weewx now available!

[vk3anz]

I just tried the Colin's site and the map is centred on my lat/long 
(Melbourne, Australia).

Looking at the web page source, I can see it passing the Wellington 
lat/long to windy.com so it must be picking my location up from somewhere 
else.

Susan

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Ambient Weather WS-2902 and WeewX

[vk3anz]

As the author of the HP1000 driver I have not tested it on anything other 
than the HP1000/WS1001/ that I have and some 
other users have found works for them.

It relies on being able to connect to the console over the network, and for 
the packets being exchanged with the console to be of exactly the right 
structure.

Looking at the description of the WS-2902 
at https://www.ambientweather.com/amws2902.html I see that it mentions 
'Encrypted WiFi Internet two-way communication' - if the network traffic is 
encrypted then that would rule out my driver unless the encryption is known.

I also see mention of IFTTT in the above link. I have no idea how this fits 
in (if at all) but it might be something to look at.

Susan

On Thursday, August 2, 2018 at 12:05:10 AM UTC+10, Bruno BORDAS wrote:
>
> #--> The HP1000 driver.
>
> I tried several of them, but nothing worked.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: raspberry pi 3 and weewx fail at first hurdle

[vk3anz]

Unless you specifically want your RPi to be a DHCP server for WiFI devices, 
I suggest that you stop the 'dhcpcd' service.
The commands:

sudo systemctl stop dhcpcd
sudo systemctl disable dhcpcd

should do the trick. (The first stops the service running if it is, and the 
second stops is automatically starting on booting.)
Susan

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: UV index

[vk3anz]

Simple answer is : no.

The driver starts by doing a broadcast using the net mask to ask the 
weather station console to respond with its IP address. This type of 
broadcast cannot cross subnets (i.e. it is not routable) and also assumes 
that the router will allow the broadcast to pass through it. (it is an 
old-style broadcast and not a multicast message.)

If no response is received within a space of time, then it tries the 
broadcast again and again until the 'retry_count' count is reached when you 
get the message you reported.

If you know the IP address of the weather station console (it is shown on 
the startup and also the 'About' display) then you could try pinging it to 
see if you can actually access it. Alternatively use WeatherIP or similar 
to see if you can access it. If you can then you should be able to get my 
driver to see it.

Susan

On Thursday, April 19, 2018 at 7:33:58 PM UTC+10, Ian Millard wrote:
>
> Yes is it the ip mask address of my home network. The weather station 
> console and computer on which WeeWX runs (Raspberry Pi 3) are both 
> connected to this network. I am not sure if it will work when a remote 
> location is involved but I will defer to Aussie Susan to give the 
> definitive answer on this one.
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: UV index

[vk3anz]

That indicates that you have not followed the instructions for installing 
the driver and configuring the 'weewx.conf' file.
Susan

On Thursday, April 19, 2018 at 4:38:24 AM UTC+10, Damjan Hajsek wrote:
>
> I also tried HP1000 driver as it was suggested by some use, but get this 
> error.
>
> Apr 18 20:31:49 localhost weewx[593]: engine: Caught unrecoverable 
> exception in engine:
> Apr 18 20:31:49 localhost weewx[593]:  No module named HP1000
> Apr 18 20:31:49 localhost weewx[593]:  Traceback (most recent call 
> last):
> Apr 18 20:31:49 localhost weewx[593]:File 
> "/usr/share/weewx/weewx/engine.py", line 865, in main
> Apr 18 20:31:49 localhost weewx[593]:  engine = 
> engine_class(config_dict)
> Apr 18 20:31:49 localhost weewx[593]:File 
> "/usr/share/weewx/weewx/engine.py", line 71, in __init__
> Apr 18 20:31:49 localhost weewx[593]:  
> self.setupStation(config_dict)
> Apr 18 20:31:49 localhost weewx[593]:File 
> "/usr/share/weewx/weewx/engine.py", line 95, in setupStation
> Apr 18 20:31:49 localhost weewx[593]:  __import__(driver)
> Apr 18 20:31:49 localhost weewx[593]:  ImportError: No module 
> named HP1000
> Apr 18 20:31:49 localhost weewx[593]:  Exiting.
>
>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: weewx crashes with error: unpack requires a string of len 104

[vk3anz]

Hello Graham,

I've not been able to come up with anything so far but I'm still looking at 
this. It is a real puzzle because there should be log file entries from 
WeeWx if my code was exiting or encountering a fault etc.. Instead there is 
nothing in the log file.

I'm still looking into this

By the way, I noticed a number of messages in your syslog file from wlan0 
about router advertisements and soliciting an DCHPV6 lease. I used to get a 
number of those as well and I found that it was my system running its own 
DHCP server (dhcpd) on that interface as well as the main DHCP server in my 
router. I stopped the dhcpd service on the system and those all went away. 
Not what you were after but might help in other areas anyway.

Susan

-- 
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: weewx crashes with error: unpack requires a string of len 104

[vk3anz]

Mmmm - I'll have a look to see if there is an issue with the delay setting.

I've had a look at the log file and I can't see any reason why it should 
just stop like that. I fact, how do you know that it *has* stopped? Can you 
do a 'ps' or 'top' to se if the process is still running, or if you are 
using systemd, then do a status on weewx to see what has happened.

As far as I know (and in like with the original title of this thread) if 
there was an error then it should have displayed that and then continued. 
In my (limited) experience, Python code only stops when the program exits 
normally.

Susan

On Saturday, April 7, 2018 at 6:44:11 PM UTC+10, Graham Seward wrote:
>
> Hi Susan
> Your last comment got me to thinking about the loop delay so I reset 
> weewx.conf to a loop delay of 15 secs. It has now been running for 14 hours 
> without a glitch so it looks like I had caused the problem but I’m not sure 
> how. I will leave it as is.
> Thanks 
> Graham 
>
> Sent from my iPad
>
> On 5 Apr 2018, at 03:37, vk3...@gmail.com  wrote:
>
> You are not being a nuisance at all, but it is a bit hard to do 'remote 
> diagnostics'.
>
> The log file would be useful but not the whole thing: just the part a bit 
> before you start weewx until just after it has stopped will be enough.
>
> Where are you setting the loop delay value and can you show us the 
> file/line in question?
>
> Susan
>
> On Thursday, April 5, 2018 at 2:20:53 AM UTC+10, Graham Seward wrote:
>>
>> Hi Susan
>>
>> Regret to say that weewx stopped running again without writing anything 
>> to syslog, messages or user.log. Syslog shows that when weewx starts it is 
>> using the correct version of the driver, so I’m puzzled as to what is going 
>> on. Would you like a copy of the syslog file in it’s entirety to see if 
>> that throws up any clues?
>>
>>  
>>
>> I’m going to run weewx again but with your original driver to see what 
>> happens this time. Incidentally if I set the loop-delay to 60 secs the 
>> program doesn’t run at all – currently set at 30secs. 
>>
>>  
>>
>> Sorry to be a nuisance!
>>
>> Graham
>>
>>  
>>
>> *From:* weewx...@googlegroups.com  *On Behalf 
>> Of *vk3...@gmail.com
>> *Sent:* 04 April 2018 03:50
>> *To:* weewx-user 
>> *Subject:* Re: [weewx-user] Re: weewx crashes with error: unpack 
>> requires a string of len 104
>>
>>  
>>
>> G - too long since I wrote the code and I made a stupid mistake. The 
>> two 'loginf' lines should read
>>
>>  
>>
>> loginf('Bad data: length = {0}'.format(len(rxData)))
>>
>> loginf('Bad data: "{0}"'.format(rxData))
>>
>>  
>>
>> I've attached your file with the correction in it.
>>
>>  
>>
>> Sorry about that.
>>
>>  
>>
>> Susan
>>
>>  
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx-user+...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to weewx-user+...@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: weewx crashes with error: unpack requires a string of len 104

[vk3anz]

You are not being a nuisance at all, but it is a bit hard to do 'remote 
diagnostics'.

The log file would be useful but not the whole thing: just the part a bit 
before you start weewx until just after it has stopped will be enough.

Where are you setting the loop delay value and can you show us the 
file/line in question?

Susan

On Thursday, April 5, 2018 at 2:20:53 AM UTC+10, Graham Seward wrote:
>
> Hi Susan
>
> Regret to say that weewx stopped running again without writing anything to 
> syslog, messages or user.log. Syslog shows that when weewx starts it is 
> using the correct version of the driver, so I’m puzzled as to what is going 
> on. Would you like a copy of the syslog file in it’s entirety to see if 
> that throws up any clues?
>
>  
>
> I’m going to run weewx again but with your original driver to see what 
> happens this time. Incidentally if I set the loop-delay to 60 secs the 
> program doesn’t run at all – currently set at 30secs. 
>
>  
>
> Sorry to be a nuisance!
>
> Graham
>
>  
>
> *From:* weewx...@googlegroups.com   > *On Behalf Of *vk3...@gmail.com 
> *Sent:* 04 April 2018 03:50
> *To:* weewx-user 
> *Subject:* Re: [weewx-user] Re: weewx crashes with error: unpack requires 
> a string of len 104
>
>  
>
> G - too long since I wrote the code and I made a stupid mistake. The 
> two 'loginf' lines should read
>
>  
>
> loginf('Bad data: length = {0}'.format(len(rxData)))
>
> loginf('Bad data: "{0}"'.format(rxData))
>
>  
>
> I've attached your file with the correction in it.
>
>  
>
> Sorry about that.
>
>  
>
> Susan
>
>  
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to weewx-user+...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: weewx crashes with error: unpack requires a string of len 104

[vk3anz]

G - too long since I wrote the code and I made a stupid mistake. The 
two 'loginf' lines should read

loginf('Bad data: length = {0}'.format(len(rxData)))
loginf('Bad data: "{0}"'.format(rxData))

I've attached your file with the correction in it.

Sorry about that.

Susan

-- 
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.
#
#Copyright (c) 2017 Susan Mackay
#   acknowledging that this driver code originated from and 
#   is structured in a similar way to the Weewx 'Simulator' driver code
#   that carries the following line:
#Copyright (c) 2009-2015 Tom Keffer 
#
#
"""hp1000 driver for the weewx weather system

This driver communicates with the HP1000/WS1001/XC0422 and whatever other clone
weather stations respond over the LAN to the 'easyweather' protocol.

Communication starts with a UDP IP broadcast on the local subnet to port 6000 to
see if the weather station responds. The broadcast packet is structured as:

Offset  Value   Structure   Comment
0x00PC2000  8 byte string   Identifies the calling station
0x08SEARCH  8 byte string   Command
0x10nulls   24 null bytes   I think there could be structure here but
sending nulls works!

(NB: All strings are null padded if required)


The weather station returns a packet structured as:

Offset  Value   Structure   Comment
0x00HP2000  8 byte string   Name of the seather station
0x08SEARCH  8 byte string   Command
0x108 byte string   Unknown
0x1816 bytesNot yet deciphered
0x28text24 byte string  MAC address of the weather station
0x40text16 byte string  IP address of the weather station


The last item is the one that we are after as then then make an TCP connection
to port 6500 on that address for all further communications.

All packets have the same basick structure: the 8-byte (null terminated) sending
device name, the 8 byte command (READ - sent to the weather station requesting
data; WRITE - the response from the wreather station with the requested data)
and a 12-byte sub-command with the type of data to be read/sent. This is followed
by what appears to be random characters but sending nulls does not seem to affect
things.

READ packets are always 40 bytes and WRITE packets vary in length depending on the
data but has a 32-byte header (structured as above).

The weather station will send data using the unit selection in the 'set up' screen
(e.g temperature in degrees Fahrenheit or Celsius). Therefore you need to know what
conversions (if any) are needed to build up the LOOP record. 

The driver follows the (nearly) universal convention and uses the Metric (METRICWX) 
system for the LOOP packet and so will convert al values to SI units.

To find out what units are being sent by the weather staiton, send a "SETUP" command and 
interpret the response as follows (after the 32-byte header):

Offset  Value   Structure   Comment
0x20unknown 16 bytesYet to be deciphered
0x30Time1 byte  1 = 'H:mm:ss', 2="h:mm:ss AM", 4='AM h:mm:ss'
0x31Date1 byte  16 = 'DD-MM-', 32 = 'MM-DD-', 64 = '-MM-DD'
0x32Temperature 1 byte  0 = Celsius, 1 = Fahrenheit
0x33Pressure1 byte  0 = hPa, 1 = inHg, 2 = mmHg
0x34Wind speed  1 byte  0 = m/s, 1 = km/h, 2 = knots, 3 = mph, 4 = Beaufort, 5 = ft/s
0x35Rainfall1 byte  0 = mm, 1 = in
0x36Solar rad   1 byte  0 = lux, 1 = fc, 2=W/m^2
0x37Rain display1 byte  0 = rain rate, 1 = daily, 2 = weekly, 3 = monthly, 4 = yearly
0x38Graph time  1 byte  0 = 12h, 1 = 24h, 2 = 48h, 3 = 72h
0x39Barometer   1 byte  0 = absolute, 1 = relative
0x3aWeather 1 byte  number
0x3bStorm   1 byte  number
0x3cCurrent 1 byte  0 = sunny, 1 = partly cloudy, 2 = cloudy, 3 = raim. 4 = strom
0x3dReset   1 byte  Month for yearly rain reset, 1 = Jan, 2 = Feb...
0x3eUpdate  1 byte  Update interval in minutes

Many of these (from offset 0x37 on) are of little interest for the driver byte the 
temperature, pressure, wind speed, rain and solar radiaiton units are all used.


The main data packet that is fetched is the NOWRECORD and it has the following structure
(again after the 32 byte header):

Offset  Value   Structure   Comment
0x20unknown 8 bytes Yet to be deciphered
0x28Wind dir2 bytes Wind direction (in degrees from North = 0) [4]
0x2ainHumidity  1 byte  Inside humidity [5]
0x2boutHumidity 1 byte  Outside humidity [6]
0x2cinTemp  4 bytes Inside temperature 

Re: [weewx-user] Re: weewx crashes with error: unpack requires a string of len 104

[vk3anz]

First off, my apologies to all - given the subject line I completely missed 
that this question was related to my HP1000 driver.
Given the line number, you are using the latest version of the driver (I 
note that the driver that Bob provides above is based on the earlier 
version).
Is it possible to edit the HP1000.py file and change  line 524 from

interp_data = struct.unpack("8s8s16s8shbb14fbbh", rxData)

to

try:
interp_data = struct.unpack("8s8s16s8shbb14fbbh", rxData)
except:
loginf('Bad data: length = {0}', len(rxData))
loginf('Bad data: "{0}"', rxData)
continue

(Note the indenting of 4 spaces - Pythin is very sensitive to the indenting 
of the code.)
That should dump out to the system log file the bad data so that we can 
look at it and see what is wrong.

When I wrote the driver I only had my own weather station as a guide so if 
other firmware creates different sized (or formatted) records then there 
will be problems. It is hard to know the level of 'error protection' that 
is needed when yo don't know the sources of the possible errors (at least 
that is my excuse!).

Susan

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WeeWX data use

[vk3anz]

Not sure if this answers your questions but... if you want a way of 
accessing your device when the IP address changes, what about using DDNS. 
I know that you use your NAS differently to mine, but I have a Synology 
NASas well and they provide a DDNS service so I can talk to the NAS from 
wherever I am. The NBN (Deity-help-me) connection plan I'm on means I get a 
new IP address every time the model reconnects but the DDNS name is updated 
within a few seconds of each reconnect.
There are a number of DDNS providers around.
You could also try using a Raspberry Pi to run WeeWx - that is what I do. I 
also use the NAS as the WeeWx directory so that I can have an (almost) 
read-only SD card and it has lasted over 12 months with no indication of 
any issues as it rarely every gets written to. (I also have the logs go to 
a ram-disk - I loose them in the event of a crash but that has not been an 
issue so far [touch wood]).
Susan

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: HP 1000 and UV-Index

[vk3anz]

In my HP1000 weewx driver, I use the formula (in Python)
int(round(data_value)/256)
where data_value is the value I read directly from the device itself.
The resulting values seem to match those displayed on the console itself.
Susan

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: How to config Weewx to get data from Sense-Hat for the Raspberry Pi

[vk3anz]

One thing to be aware of is that the heat from the ARM chip can bias the 
temperature sensor in the Hat - it did with mine when running on an RPi3 
and could well with other (earlier) boards that run a little cooler.
Therefore I'd suggest that you add in a way to calibrate your sensors 
before using the values.
Susan

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: http://weewx.com/stations.html weewx map show skins used by stations as you can show by hardware type

[vk3anz]

I was not aware of that map - any my station is not on it (not that I 
really want to make it public - I would need to make 2 interfaces to keep 
the 'internal' data private)
Therefore it may not be a truly representative sample of what skins (or 
anything else) is out there.
Susan

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Most reliable mini computer for weeWX?

[vk3anz]

Personally I'd be checking on what is causing the 'freezing' because, if it 
is something like running out of space for the ram-disk based log files (as 
happened to me once), or the lack of space on the SD card (not necessarily 
from WeeWx itself but from other files being written) or even a failure 
with the SD card (a portion that is not written to for about a month after 
the boot) then those might well be transferred to the new device.

Susan

On Thursday, January 25, 2018 at 6:38:36 AM UTC+11, Alec Bennett wrote:
>
> I've been running weeWX on a Beaglebone Black for about a year now, and 
> the thing has been freezing about once a month. It's running headless so is 
> hard to diagnose.
>
> I'm probably going to switch to a Pi, but thought I'd see if anyone has 
> any other suggestions for a very reliable mini computer that plays nice 
> with weeWX?
>
>  
>

-- 
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: weewx won't start

[vk3anz]

You can get around the issue with the clock by switching from the old 
'init.d' approach to the systemctl equivalent. (With the versions of 
Raspbian - which I assume you are using on the RPi - any files in the 
'init.d' directories are automatically converted to a (roughly) equivalent 
systemctl script anyway which is then used.)
Using systemctl you can make sure that weewx does not start up until the 
network system time etc. are all set and available - as far as I know you 
cannot do this with the old way.
Susan

-- 
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] Disabling Weewx Autostart

[vk3anz]

Jessie actually converts everything to use the systemctl service. There is 
a specific "generator" app that runs early in the bootstrap process that 
reads all of these 'init.d' files and creates a (supposedly) equivalent 
.service file for systemctl.

I'm not exactly sure where these generated service files are located (there 
are quite a few places that the systemctl service looks for the service 
files) but it should be something like weewx.service.

I'm mentioning all of this because you can use this generated file to 
create your own file that is permanent and includes a line 
"Requires=ntp.service" that will tell the systemctl daemon to run your 
service only after the NTP service has done its thing (I'm no expert on 
these things but that is what I;ve been told and seems to work on my RPi3 
system).

I've attached my file if you are interested. You can also see the file path 
where I have placed it. (I run weewx in its own account that is actually on 
a NAS - hence the wait for the network, '/home' and '/home/weewx' folders 
being available; you may not need those.)

Just an alternative to think about.

Susan


On Tuesday, December 26, 2017 at 8:28:35 PM UTC+11, gjr80 wrote:
>
> Hi,
>
> *sudo rm /etc/init.d/weewx *
>
> should what you want.
>
> 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.
For more options, visit https://groups.google.com/d/optout.
pi@weather:~ $ cat /etc/systemd/system/weewx.service
# systemd configuration for weewx

[Unit]
Description=weewx weather system
Requires=syslog.service
Requires=ntp.service
Requires=network-online.target
After=syslog.service
After=ntp.service
After=network-online.target
RequiresMountsFor=/home
RequiresMountsFor=/home/weewx

[Service]
ExecStart=/home/weewx/bin/weewxd --daemon --pidfile=/var/run/weewx.pid 
/home/weewx/weewx.conf
ExecReload=/bin/kill -HUP $MAINPID
Type=simple
PIDFile=/var/run/weewx.pid
#User=weewx
#Group=weewx
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target
pi@weather:~ $

Re: [weewx-user] Cheetah Generator error reason '##'

[vk3anz]

Thanks Glenn - there were lots of such entries in the Melbourne (where I 
am) xml file. Deleted teh xml files and all is well again.

I noticed that I was getting errors from other BOM files a couple of days 
ago as well - they seem to be having a few problems lately (their main 
radar broke in the middle of the storms here this afternoon!).

Susan

On Friday, December 1, 2017 at 6:15:27 PM UTC+11, Glenn McKechnie wrote:
>
> Hi Susan, 
>
> From memory this is caused by a corrupted download from the BOM. One 
> of the xml files will be incomplete and has ## as placeholders ( 
> instead of data) within the file. 
>
> Navigate to /var/lib/weewx/aussearch and delete the *.xml files and on 
> the next run aussearch should replace them and will hopefully fetch a 
> good file. 
>
> Ah, Just found and checked a stale directory that I backed up here - 
> the line that bites looks something like. 
>
> grep * -e '##' 
>
> hash-hash-IDV10753.xml: type="forecast_icon_code">## 
> hash-hash-IDV10753.xml: type="air_temperature_minimum" units="Celsius">## 
> hash-hash-IDV10753.xml: type="air_temperature_maximum" units="Celsius">## 
>
>
> Cheers 
>  Glenn 
>
> rorpi - read only raspberry pi & various weewx addons 
> https://github.com/glennmckechnie 
>
>
> On 1 December 2017 at 18:00,   wrote: 
> > Weewx has just started to create this error: 
> > 
> > Dec  1 17:51:04 weather weewx[20911]: cheetahgenerator: Generate failed 
> with 
> > exception '' 
> > 
> > Dec  1 17:51:04 weather weewx[20911]: cheetahgenerator:  Ignoring 
> > template /home/weewx/skins/Responsive/forecast.html.tmpl 
> > 
> > Dec  1 17:51:04 weather weewx[20911]: cheetahgenerator:  Reason: 
> '##' 
> > 
> > Dec  1 17:51:04 weather weewx[20911]:   Traceback (most recent call 
> > last): 
> > 
> > Dec  1 17:51:04 weather weewx[20911]: File 
> > "/home/weewx/bin/weewx/cheetahgenerator.py", line 315, in generate 
> > 
> > Dec  1 17:51:04 weather weewx[20911]:   print >> _file, text 
> > 
> > Dec  1 17:51:04 weather weewx[20911]: File 
> > "/usr/lib/python2.7/dist-packages/Cheetah/Template.py", line 1005, in 
> > __str__ 
> > 
> > Dec  1 17:51:04 weather weewx[20911]:   rc = getattr(self, 
> > mainMethName)() 
> > 
> > Dec  1 17:51:04 weather weewx[20911]: File 
> > "_home_weewx_skins_Responsive_forecast_html_tmpl.py", line 487, in 
> respond 
> > 
> > Dec  1 17:51:04 weather weewx[20911]: File 
> > "_home_weewx_skins_Responsive_forecast_html_tmpl.py", line 141, in 
> > __errorCatcher11 
> > 
> > Dec  1 17:51:04 weather weewx[20911]: File "", line 1, 
> in 
> >  
> > 
> > Dec  1 17:51:04 weather weewx[20911]:   KeyError: '##' 
> > 
> > Dec  1 17:51:20 weather weewx[20911]: cheetahgenerator: Generate failed 
> with 
> > exception '' 
> > 
> > Dec  1 17:51:20 weather weewx[20911]: cheetahgenerator:  Ignoring 
> > template /home/weewx/skins/Responsive/index.html.tmpl 
> > 
> > Dec  1 17:51:20 weather weewx[20911]: cheetahgenerator:  Reason: 
> '##' 
> > 
> > Dec  1 17:51:20 weather weewx[20911]:   Traceback (most recent call 
> > last): 
> > 
> > Dec  1 17:51:20 weather weewx[20911]: File 
> > "/home/weewx/bin/weewx/cheetahgenerator.py", line 315, in generate 
> > 
> > Dec  1 17:51:20 weather weewx[20911]:   print >> _file, text 
> > 
> > Dec  1 17:51:20 weather weewx[20911]: File 
> > "/usr/lib/python2.7/dist-packages/Cheetah/Template.py", line 1005, in 
> > __str__ 
> > 
> > Dec  1 17:51:20 weather weewx[20911]:   rc = getattr(self, 
> > mainMethName)() 
> > 
> > Dec  1 17:51:20 weather weewx[20911]: File 
> > "_home_weewx_skins_Responsive_index_html_tmpl.py", line 1674, in respond 
> > 
> > Dec  1 17:51:20 weather weewx[20911]: File 
> > "/usr/lib/python2.7/dist-packages/Cheetah/Template.py", line 1615, in 
> > _handleCheetahInclude 
> > 
> > Dec  1 17:51:20 weather weewx[20911]:  
> > self._CHEETAH__cheetahIncludes[_includeID].respond(trans) 
> > 
> > Dec  1 17:51:20 weather weewx[20911]: File 
> > "_home_weewx_skins_Responsive_index_forecast_tmpl.py", line 150, in 
> respond 
> > 
> > Dec  1 17:51:20 weather weewx[20911]:   KeyError: '##' 
> > 
> > Dec  1 17:51:20 weather weewx[20911]: cheetahgenerator: Generated 7 
> files 
> > for report StandardReport in 50.82 seconds 
> > 
> > 
> > This has managed to stop the main HTML page being generated (although 
> the 
> > images are being created and displayed). 
> > 
> > 
> > I'm not sure if it helps but the start of the 'index-forecast.tmpl' file 
> is: 
> > 
> > ## Australian Index Forecast panel 
> > 
> > ## Included in index.html.tmpl 
> > 
> > ## 
> > 
> > ## Depending of your location and XML file in skin.conf 
> > 
> > ## you will need to adjust this file in a few places 
> > 
> > ## 
> > 
> > #import dateutil.parser 
> > 
> >  
> > 
> >
> > 
> >  
> > 

[weewx-user] Cheetah Generator error reason '##'

[vk3anz]

Weewx has just started to create this error:

Dec  1 17:51:04 weather weewx[20911]: cheetahgenerator: Generate failed 
with exception ''

Dec  1 17:51:04 weather weewx[20911]: cheetahgenerator:  Ignoring 
template /home/weewx/skins/Responsive/forecast.html.tmpl

Dec  1 17:51:04 weather weewx[20911]: cheetahgenerator:  Reason: '##'

Dec  1 17:51:04 weather weewx[20911]:   Traceback (most recent call 
last):

Dec  1 17:51:04 weather weewx[20911]: File 
"/home/weewx/bin/weewx/cheetahgenerator.py", line 315, in generate

Dec  1 17:51:04 weather weewx[20911]:   print >> _file, text

Dec  1 17:51:04 weather weewx[20911]: File 
"/usr/lib/python2.7/dist-packages/Cheetah/Template.py", line 1005, in 
__str__

Dec  1 17:51:04 weather weewx[20911]:   rc = getattr(self, 
mainMethName)()

Dec  1 17:51:04 weather weewx[20911]: File 
"_home_weewx_skins_Responsive_forecast_html_tmpl.py", line 487, in respond

Dec  1 17:51:04 weather weewx[20911]: File 
"_home_weewx_skins_Responsive_forecast_html_tmpl.py", line 141, in 
__errorCatcher11

Dec  1 17:51:04 weather weewx[20911]: File "", line 1, in 


Dec  1 17:51:04 weather weewx[20911]:   KeyError: '##'

Dec  1 17:51:20 weather weewx[20911]: cheetahgenerator: Generate failed 
with exception ''

Dec  1 17:51:20 weather weewx[20911]: cheetahgenerator:  Ignoring 
template /home/weewx/skins/Responsive/index.html.tmpl

Dec  1 17:51:20 weather weewx[20911]: cheetahgenerator:  Reason: '##'

Dec  1 17:51:20 weather weewx[20911]:   Traceback (most recent call 
last):

Dec  1 17:51:20 weather weewx[20911]: File 
"/home/weewx/bin/weewx/cheetahgenerator.py", line 315, in generate

Dec  1 17:51:20 weather weewx[20911]:   print >> _file, text

Dec  1 17:51:20 weather weewx[20911]: File 
"/usr/lib/python2.7/dist-packages/Cheetah/Template.py", line 1005, in 
__str__

Dec  1 17:51:20 weather weewx[20911]:   rc = getattr(self, 
mainMethName)()

Dec  1 17:51:20 weather weewx[20911]: File 
"_home_weewx_skins_Responsive_index_html_tmpl.py", line 1674, in respond

Dec  1 17:51:20 weather weewx[20911]: File 
"/usr/lib/python2.7/dist-packages/Cheetah/Template.py", line 1615, in 
_handleCheetahInclude

Dec  1 17:51:20 weather weewx[20911]:   
self._CHEETAH__cheetahIncludes[_includeID].respond(trans)

Dec  1 17:51:20 weather weewx[20911]: File 
"_home_weewx_skins_Responsive_index_forecast_tmpl.py", line 150, in respond

Dec  1 17:51:20 weather weewx[20911]:   KeyError: '##'

Dec  1 17:51:20 weather weewx[20911]: cheetahgenerator: Generated 7 files 
for report StandardReport in 50.82 seconds


This has managed to stop the main HTML page being generated (although the 
images are being created and displayed).


I'm not sure if it helps but the start of the 'index-forecast.tmpl' file is:

## Australian Index Forecast panel

## Included in index.html.tmpl

##

## Depending of your location and XML file in skin.conf

## you will need to adjust this file in a few places

##

#import dateutil.parser



  



  

Forecast

  



  

  

#set $FC = 
$aus.FC_LOCAL.forecast('area',description=str($aus.index_locality))

(There is more and I can attach it if needed.)

Any suggestions on what the error might be and how to fix it?

Susan

-- 
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: Australian XC0422 (same as HP1000??) Weather Station VID and PID

[vk3anz]

You are replying to a post of mine that is very out of date and my 
misunderstanding was corrected shortly after I posted.

In fact, if you look under the drivers section of the Wiki you will find 
the HP1000 driver that I wrote that uses the Wifi connection directly from 
Weewx to gather data from these consoles.

Susan

On Tuesday, October 17, 2017 at 7:12:25 PM UTC+11, Andrew Milner wrote:
>
> doesn't the HP1000 communicate via wifi rather than usb??  See the drivers 
> section of the weewx wiki (under support)
>
> On 17 October 2017 at 10:34,  wrote:
>
>>
>>
>> On Wednesday, 13 July 2016 13:50:18 UTC+8, vk3...@gmail.com wrote:
>>>
>>> I have just bought an XC0422 Weather station from Jaycar (in Australia) 
>>> and it appears to be working well. My understanding is that this is a 
>>> re-badged Fine Offset HP1000 - it appears to be identical except that mine 
>>> came with rechargeable batteries!
>>> I have installed Weewx on a Raspberry Pi (2 B+) and told it that it 
>>> should connect via USB using the weewx.drivers.fousb driver. However I 
>>> suspect that there is a difference in the USB VID and PID that the driver 
>>> is looking for as all of the various weewx utilities and weewx itself seem 
>>> to crash with a python stack dump about 'unable to find USB device'.
>>> I get syslog messages saying that it cannot find a device with a VID of 
>>> 0x1941 and a PID of 0x8021. My VID is 0x45e and PID is 0x00ce
>>> Is there somewhere I can set the VID and PID for the driver to look for 
>>> to see my device?
>>> Susan
>>>
>> -- 
>> 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/FdbfX4zPXq4/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> weewx-user+...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Have the tide on website weewx

[vk3anz]

Just a word of caution - there is more to the tide than just the location 
of the sun and moon. The local coastline and bathymetry play a bit part and 
can change times by some hours.
When I worked for the local meteorological organisation, I found that it 
was not at all straight forward to provide general tide information. For a 
specific location it is possible to work out the various biases involved 
and this is how the published tide tables are done.
Susan

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Autostart WeeWX with systemd

[vk3anz]

Sorry - I didn't mean to make the 'N' a capital but I'm not sure if it 
matters.
Susan

On Thursday, August 24, 2017 at 12:32:56 PM UTC+10, vk3...@gmail.com wrote:
>
> If you are trying to use the network to send to WeatherUnderground, then 
> you may need to wait for it to start as well.
>
> Something like:
>
> Requires=Network-online.target
> After=Network-online.target
>
> if I remember correctly.
>
> Susan
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Autostart WeeWX with systemd

[vk3anz]

If you are trying to use the network to send to WeatherUnderground, then 
you may need to wait for it to start as well.

Something like:

Requires=Network-online.target
After=Network-online.target

if I remember correctly.

Susan

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: weewx with the SenseHat

[vk3anz]

I've played with the SenseHAT (but on a RPi3) and you may need to 
compensate for the fact that the chip heats up the SenseHAT and so it shows 
a higher than actual temperature reading. I've seen this mentioned in 
several places on the Web and there are suggestions about how to compensate 
for this.
I guess it all depends on what you want the system to do for you.
Susan

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: weewx doesn't start automatically after reboot

[vk3anz]

On Thursday, March 23, 2017 at 1:39:36 PM UTC+11, vk3...@gmail.com wrote:
>
> Looks like you are using systemd - in that case I had this problem until I 
> asses the lines to the .service. file to  wait until everything necessary 
> is started. From memory this is the file system, network time (and in my 
> case the network and an NFS mount point).
> If not then you can edit the sysv (or whatever it is called) to add in the 
> equivalent items.
> Susan
>
>> That 'asses' word should be 'added'!!!
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: How to wipe out bad rain data

[vk3anz]

Waiting until today did the trick for the graphics.

As gjr80  mentioned, the NOAA monthly report is still wrong but now I knwo 
how to sort that out as well.

Thanks everyone

Susan

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: How to wipe out bad rain data

[vk3anz]

Thanks - I managed to get that to work.

At first I tried just setting the values to 0 but I needed to set them to 
NULL (as per the instructions - I know!!!) before the next report would set 
the 'Month' displays to sensible values.

However the 'Year' summaries is still out. Is there an equivalent to 
'--drop-daily' and '--backfill-daily' that works for the yearly data?

Susan

-- 
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: WeeWx not starting up automatically, and then not starting correctly on first run.

[vk3anz]

>
> Thanks for the response. I tried this but it doesn't seem to solve my 
> situation. When I do a reboot of the RPi, this is what happens:
>

I just looked further back in this thread to see what OS you are running . 
I see you are running Debian 8.0 ( take it that is 'Jessie') and I'm 
running the latest Rasbian which should be derived from Jessie.
I was wondering if you were using SysV or systemd. I *think* the reference 
I made to $network requires systemd so that it will be auto-translated into 
the correct dependency in the systemd equivalent to the 'init.d' file.

Susan

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Change Standard report pressure from 'mbar' to 'hPa'

[vk3anz]

Thanks for the replies. I mean the weewx generated 'standard report'.
I've also just seen that the 'weewx.conf' section for [StdReport] 
[[StandardReport]] [[[Units]]] Groups has a 'group_pressure' entry 
that is set for 'mbar' so I'll try setting that when I get home. (I assume 
that this overrides other settings on the report template itself - and 
assorted files.)
Isn't it always the way that you look and look, then ask the question and 
see the answer right in front of you!
Susan 

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Change Standard report pressure from 'mbar' to 'hPa'

[vk3anz]

I am running weewx 3.6.2 on a RPi using the standard report.
I can't find where to change the web output to show 'hPa' for the pressure 
measurements, instead of 'mbar'. I've tried 'skin.conf' under 
'group_pressure' and in 'units.py' (the definition of 'MetricUnits' and 
'MetrixWXUnits' for 'group_pressure')
Any suggestion of where to look?
Thanks
Susan

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] WOW Data update

[vk3anz]

I'm using weewx 3.6.2 and it has been working well on my RPi (even with my 
custom driver).
I have recently started sending data to WOW and I've noticed that the wind 
direction is always 'NNE' and that the wind speed (which is displayed in 
knots on WOW) is always much higher than on the standard reports (which 
matches what the weather station is saying and what the weather station is 
sending to WU).
Is there something I need to do other than the entry in the weewx.config 
file under '[[WOW]]'?
Susan

-- 
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: WeeWx not starting up automatically, and then not starting correctly on first run.

[vk3anz]

I had the same problem. A bit of research shows that I needed to edit the 
/etc/init.d/weewx file so that the 

# Required-Start: 

line contains '$network'.

This is converted by the tools that translate the SysVInit code to 
'systemd' code to wait until the network is operational.

Susan

On Saturday, November 26, 2016 at 7:14:35 AM UTC+11, mwall wrote:
>
>
>
> On Friday, November 25, 2016 at 2:53:34 PM UTC-5, Jon Adams wrote:
>>
>> 083529 (row 547): weewx exits because it can't find a network (but there 
>> was a network already set up?)
>>
>
> jon,
>
> your configuration requires a network connection to the vantage station, 
> and weewx is bailing out when it finds no network (see lines 546 and 547 of 
> the syslog you posted).
>
> by the time you try to start weewx directly, then network is functional.
>
> you need to tell systemd that weewx needs a fully functional network 
> before it is started up.
>
> or you can add the loop-on-init option to your weewx configuration file:
>
> loop_on_init = True
>
> that will make weewx keep retrying the startup process instead of exitting.
>
> m 
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.