[weewx-user] Re: GW1000.py crashing when attempting to rediscover GW1000

2022-08-18 Thread Dr__Bob
Just to complete this:  I have now verified that whenever my gw1000 
disappears for while (technically the error is ""ERROR user.*gw1000*: 
Failed to obtain response to command 'CMD_*GW1000*_LIVEDATA' after 3 
attempts"), the driver now correctly recovers. This has happened a couple 
of times, most recently yesterday, and my weewx instance has been up for 
114 days.

So Gary, thanks

Bob 

On Saturday, March 19, 2022 at 11:15:03 PM UTC-7 gjr80 wrote:

> Just to tidy this up I have released the GW1000 driver v0.4.2 
> <https://github.com/gjr80/weewx-gw1000/releases/tag/v0.4.2> that fixes 
> this issue.
>
> Gary
>
> On Thursday, 17 March 2022 at 13:39:29 UTC+10 gjr80 wrote:
>
>> Bob,
>>
>> The GW100 driver uses discovery only if an IP address for your device is 
>> not specified in weewx.conf and then only in two general areas. First is 
>> during startup; the driver will broadcast to the network and the first 
>> device that responds will be used. The driver identifies and keeps track of 
>> the device being used by MAC address. If no device provides a valid 
>> response WeeWX will either exit or retry in 60 seconds (the default value) 
>> depending on how WeeWX is configured. The second time discovery is used is 
>> if the driver loses contact with the device (this usually occurs if the 
>> device does not respond to a command after three (the default value) 
>> attempts). In this case the driver broadcasts again looking for a device 
>> with the same MAC address as previously noted. If found the driver updates, 
>> if required, the IP address and port used to contact the device. If the 
>> same MAC cannot be found WeeWX will either exit or retry in 60 seconds 
>> depending on how WeeWX is configured. If an IP address is specified 
>> discovery is never used.
>>
>> Other than discovery there is no difference between how the driver 
>> handles a device whether an IP address is specified or not. Experience has 
>> shown that sometimes discovery has been unreliable and hence the preference 
>> for specifying an IP address.
>>
>> Gary
>> On Thursday, 17 March 2022 at 03:56:34 UTC+10 Dr__Bob wrote:
>>
>>> Hi Gary,
>>>
>>> Thanks for looking into this!  Yeah, my "fix" was just me typing away in 
>>> the message, so I indeed did miss the extra ":%d". My coding may be bad, 
>>> but it ain't *that* bad! :-)  
>>> I had, up to now, the ip address for the GW1000 set to auto.  I have an 
>>> atrociously difficult to manage Spectrum router (which I should replace 
>>> with a better one) that doesn't have a web interface to manage it, but 
>>> rather an app.  IP allocation on that app is difficult to find, but I did 
>>> find it, and now I have changed weewx.conf to have a fixed ip address for 
>>> the GW1000.  Will that change anything if weewx again loses contact with 
>>> the GW1000?
>>>
>>> Thanks,
>>>
>>> Bob
>>>
>>> On Tuesday, March 15, 2022 at 11:27:27 PM UTC-7 gjr80 wrote:
>>>
>>>> Thanks for spotting that, device_list is a list of dicts so line 3928 
>>>> was never going to work. I am surprised it has not shown up previously, 
>>>> though it is buried in some code that is seldom used. You almost have the 
>>>> fix correct, but '%s' should be '%s:%d' to give the *IP address:port 
>>>> number* format. There are also a couple of other changes further down 
>>>> from line 3298 that will also need to be made. I should have an update in 
>>>> the next few days; the rediscovery code is complex and I want to make sure 
>>>> sure it is functioning properly (now) - testing of the rediscovery code is 
>>>> time consuming.
>>>>
>>>> In the meantime, are you operating your device with a fixed IP 
>>>> allocation? If possible that is the recommended way to use the GW1x00 
>>>> devices with the GW1000 driver.
>>>>
>>>> Gary
>>>>
>>>> On Wednesday, 16 March 2022 at 04:42:02 UTC+10 Dr__Bob wrote:
>>>>
>>>>> Hi.  From time to time, it seems like my GW1000 disappears.  It looks 
>>>>> like the code is trying to rediscover it, but in the process hits a bug 
>>>>> in 
>>>>> the code and crashes.  This is with weewx 4.5.1 with python 3.7.3 and 
>>>>> GW1000 0.41.  The syslog looks like:
>>>>>
>>>>> Mar 15 04:14:45 raspberrypi weewx[1374] ERROR user.gw1000: Failed to 
>>>>> obtain response to command 'CMD_READ_SEN

[weewx-user] Re: GW1000.py crashing when attempting to rediscover GW1000

2022-03-16 Thread Dr__Bob
Hi Gary,

Thanks for looking into this!  Yeah, my "fix" was just me typing away in 
the message, so I indeed did miss the extra ":%d". My coding may be bad, 
but it ain't *that* bad! :-)  
I had, up to now, the ip address for the GW1000 set to auto.  I have an 
atrociously difficult to manage Spectrum router (which I should replace 
with a better one) that doesn't have a web interface to manage it, but 
rather an app.  IP allocation on that app is difficult to find, but I did 
find it, and now I have changed weewx.conf to have a fixed ip address for 
the GW1000.  Will that change anything if weewx again loses contact with 
the GW1000?

Thanks,

Bob

On Tuesday, March 15, 2022 at 11:27:27 PM UTC-7 gjr80 wrote:

> Thanks for spotting that, device_list is a list of dicts so line 3928 was 
> never going to work. I am surprised it has not shown up previously, though 
> it is buried in some code that is seldom used. You almost have the fix 
> correct, but '%s' should be '%s:%d' to give the *IP address:port number* 
> format. There are also a couple of other changes further down from line 
> 3298 that will also need to be made. I should have an update in the next 
> few days; the rediscovery code is complex and I want to make sure sure it 
> is functioning properly (now) - testing of the rediscovery code is time 
> consuming.
>
> In the meantime, are you operating your device with a fixed IP allocation? 
> If possible that is the recommended way to use the GW1x00 devices with the 
> GW1000 driver.
>
> Gary
>
> On Wednesday, 16 March 2022 at 04:42:02 UTC+10 Dr__Bob wrote:
>
>> Hi.  From time to time, it seems like my GW1000 disappears.  It looks 
>> like the code is trying to rediscover it, but in the process hits a bug in 
>> the code and crashes.  This is with weewx 4.5.1 with python 3.7.3 and 
>> GW1000 0.41.  The syslog looks like:
>>
>> Mar 15 04:14:45 raspberrypi weewx[1374] ERROR user.gw1000: Failed to 
>> obtain response to command 'CMD_READ_SENSOR_ID_NEW' after 3 attempts
>>
>> Mar 15 04:14:45 raspberrypi weewx[1374] INFO user.gw1000: Attempting to 
>> re-discover GW1000...
>>
>> Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:   
>> Traceback (most recent call last):
>>
>> Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000: 
>> File "/usr/share/weewx/user/gw1000.py", line 3587, in get_sensor_id
>>
>> Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000: 
>>   return self.send_cmd_with_retries('CMD_READ_SENSOR_ID_NEW')
>>
>> Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000: 
>> File "/usr/share/weewx/user/gw1000.py", line 3740, in send_cmd_with_retries
>>
>> Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000: 
>>   raise GW1000IOError(_msg)
>>
>> Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:   
>> user.gw1000.GW1000IOError: Failed to obtain response to command 
>> 'CMD_READ_SENSOR_ID_NEW' after 3 attempts
>>
>> Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:   
>>
>> Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:   
>> During handling of the above exception, another exception occurred:
>>
>> Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:   
>>
>> Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:   
>> Traceback (most recent call last):
>>
>> Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000: 
>> File "/usr/share/weewx/user/gw1000.py", line 3024, in run
>>
>> Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000: 
>>   self.client.collect_sensor_data()
>>
>> Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000: 
>> File "/usr/share/weewx/user/gw1000.py", line 2476, in collect_sensor_data
>>
>> Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000: 
>>   queue_data = self.get_live_sensor_data()
>>
>> Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000: 
>> File "/usr/share/weewx/user/gw1000.py", line 2525, in get_live_sensor_data
>>
>> Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000: 
>>   self.update_sensor_id_data()
>>
>> Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000: 
>> File "/usr/share/weewx/user/gw1000.py", line 2538, in update_sensor_id_data
>>
>> Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000: 
>>   s

[weewx-user] GW1000.py crashing when attempting to rediscover GW1000

2022-03-15 Thread Dr__Bob
Hi.  From time to time, it seems like my GW1000 disappears.  It looks like 
the code is trying to rediscover it, but in the process hits a bug in the 
code and crashes.  This is with weewx 4.5.1 with python 3.7.3 and GW1000 
0.41.  The syslog looks like:

Mar 15 04:14:45 raspberrypi weewx[1374] ERROR user.gw1000: Failed to obtain 
response to command 'CMD_READ_SENSOR_ID_NEW' after 3 attempts

Mar 15 04:14:45 raspberrypi weewx[1374] INFO user.gw1000: Attempting to 
re-discover GW1000...

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:   
Traceback (most recent call last):

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000: 
File "/usr/share/weewx/user/gw1000.py", line 3587, in get_sensor_id

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:   
return self.send_cmd_with_retries('CMD_READ_SENSOR_ID_NEW')

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000: 
File "/usr/share/weewx/user/gw1000.py", line 3740, in send_cmd_with_retries

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:   
raise GW1000IOError(_msg)

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:   
user.gw1000.GW1000IOError: Failed to obtain response to command 
'CMD_READ_SENSOR_ID_NEW' after 3 attempts

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:   

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:   
During handling of the above exception, another exception occurred:

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:   

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:   
Traceback (most recent call last):

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000: 
File "/usr/share/weewx/user/gw1000.py", line 3024, in run

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:   
self.client.collect_sensor_data()

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000: 
File "/usr/share/weewx/user/gw1000.py", line 2476, in collect_sensor_data

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:   
queue_data = self.get_live_sensor_data()

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000: 
File "/usr/share/weewx/user/gw1000.py", line 2525, in get_live_sensor_data

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:   
self.update_sensor_id_data()

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000: 
File "/usr/share/weewx/user/gw1000.py", line 2538, in update_sensor_id_data

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:   
sensor_id_data = self.station.get_sensor_id()

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000: 
File "/usr/share/weewx/user/gw1000.py", line 3591, in get_sensor_id

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:   
if not self.rediscover():

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000: 
File "/usr/share/weewx/user/gw1000.py", line 3928, in rediscover

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:   
gw1000_str = ', '.join([':'.join(['%s:%d' % b]) for b in device_list])

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000: 
File "/usr/share/weewx/user/gw1000.py", line 3928, in 

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:   
gw1000_str = ', '.join([':'.join(['%s:%d' % b]) for b in device_list])

Mar 15 04:15:05 raspberrypi weewx[1374] CRITICAL user.gw1000:   
TypeError: not enough arguments for format string

I *think* the bug is on line 3928 in rediscover(self):

gw1000_str = ', '.join([':'.join(['%s:%d' % b]) for b in device_list])

This looks like a copy of the similar line further up in the code where the 
GW1000 is first discovered.  I'm a complete python newbie, but it looks 
like the second join in the above line wants two fields but is only getting 
one.  Shouldn't it be ".join(['%s' % (b['ip_address'],b['port'])])"? 
 That's the way the first version of gw1000_str is formed.

Cheers,

Bob Clare 

-- 
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/1dc836dd-f2ba-4754-99c1-a86d7ba3f6bcn%40googlegroups.com.


[weewx-user] Re: cmon - Extension / cpu_temp missing on raspberry

2021-03-12 Thread Dr__Bob
In the file cmon.py, there is a check on a directory (tdir) and a check on 
a specific file (tfile).  Apparently on some unices, the directory tdir 
contains a file with the cpu temp.  On raspberries, the directory exists, 
but doesn’t contain the temperature file.  The cpu temp is actually in the 
file tfile.  So basically, you have to swap the order of the check:  check 
first for tfile then tdir.  I’d post the necessary mod, but I don’t have 
access to my rpi right now.

Hope this helps and sorry for not being able to give more details!

On Wednesday, March 10, 2021 at 9:12:00 AM UTC-8 plin...@googlemail.com 
wrote:

> Hello,
>
> i have installed the cmon extension as described in 
> https://github.com/weewx/weewx/wiki/cmon
>
> In the plots the cpu_temp - Graph has no values.
>
> I use an raspberry pi 4
>
> does someone have a tip about it?
>
> Many thanks and greetings
>
> plinepa
>
>
>

-- 
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/df7404aa-e50c-4451-af49-a9b9b1de5b53n%40googlegroups.com.


[weewx-user] Re: Did someone test Weewx in Raspbian Buster?

2019-07-29 Thread Dr__Bob
Hi, I just recently upgraded to Buster and also weewx 3.9.1.  I'm using the 
HP1000 driver (contributed by AussieSusan).  All works fine except for the 
cpu_temp in the cmon skin.  I had to flip the order of an "if-elif" block 
in cmon.py to get it to work.  I've let Matthew Wall know.  It's probably a 
change going from Jessie to Buster adding a directory in the /sys tree. 
 After that change, the system is running very nicely.


-- 
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/8360d026-3064-478f-8321-56e27b86daed%40googlegroups.com.


[weewx-user] Re: How do I edit the weewx.conf file?

2017-01-04 Thread Dr__Bob
I'm not sure what exactly your question is.  If you are trying to figure 
out how to edit the file, then you need to use an editor.  "nano" is a good 
straight-forward choice:

 nano /etc/weewx/weewx.conf

However, /etc is typically a protected directory and you have to a) either 
be logged in as root (*never* a good idea!) or b) better use "sudo":

 sudo nano /etc/weewx/weewx.conf

(sudo lets you become the "superuser" (aka root) and "do" something.)

Once you've edited the file, you'll have to stop and restart weewx, of 
course.

On Wednesday, January 4, 2017 at 6:41:49 PM UTC-8, Steve Dulmes wrote:
>
> Hi, I'm new to weewx and to Python. I have an Acurite 5in1 connected to a 
> Raspberry Pi3 with USB. I have weewx installed and running and it is 
> working well. 
> I would like get it reporting to Weather Underground but I do not know how 
> to edit the config file to put my weather station info in the appropriate 
> section and save it. 
> I've tried using the open command, but it continues to say I've made a 
> syntax error. 
> Examples of my failed tries:
> open (/etc/weewx/weewx.conf)
> open('/etc/weewx/weewx.conf')
> open(/etc/weewx/weewx.conf, w) ...to write and save a new copy of the file?
> cd etc/weewx ...this worked to change the directory, but then all my tries 
> to get to the weewx.conf failed
> Probably pretty simple, but I can't figure it out.
> Any help would be appreciated.
> 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.
For more options, visit https://groups.google.com/d/optout.


[weewx-user] exfoliation skin and interactions with the forecast skin

2017-01-04 Thread Dr__Bob
Hi All,

I'm a new weewx user and I've been playing with the exfoliation skin by 
mwall. I've brought the items below to mwall's attention over on the 
wxforum, but it probably doesn't hurt to give them more exposure on this 
list. Maybe someone else has seen them before or has some additional ideas..

1) I had to comment out the following bit of code in index.html.tmpl as it 
wasn't working.  I got the string "$day.maxSolarRad.max.format('%.0f')
?'maxSolarRad'?" on my page.

##if $varExists('day.maxSolarRad')
##  $day.maxSolarRad.max.format('%.0f')
##  $current.maxSolarRad.format('%.0f')
##end if
 
2) I had to modify forecast_strip.inc in the forecast skin to get it to 
work with another skin (ss, the Stainless Steel gauges).  Maybe I did 
something not quite correct, but I just included in the ss/index.html.tmpl 
the following in the :

  
  

and then put the following where I wanted the forecast strip:

#set global $forecast_strip_settings = dict()
#set global $forecast_strip_settings['source'] = 'NWS'
#include "../forecast/forecast_strip.inc"

That works, except for the icons.  To get the icons to work, I had to 
change every occurrence of "icons/" in  forecast_strip.inc to be 
"../forecast/icons/".  That then worked.  I don't think that html allows 
for multiple search paths for images.  (Yeah, I know enough html to do 
serious damage to any web page that I come in contact with.  I'm slowly 
picking up some css.  What can I say; I grew up on Fortran and you know 
about old dogs and new tricks...)  Anyway, if you are in the forecast 
directory, "../forecast/icons/" works just as well as "icons/".  However, 
it doesn't work if the relative directory structure changes, I'm guessing.

3) To get the forecasts to work in the exfoliation skin I had to add  
search_list_extensions = user.forecast.ForecastVariables 
to [CheetahGenerator] in the exfoliation skin.conf.  I knew to do that 
after reading the forecast wiki and getting it to work in the ss skin but I 
was kind of surprised, since forecasts were included all over the place in 
the exfoliation skin.  Maybe just a gentle reminder somewhere in the 
exfoliation skin.conf would be useful?  Would adding the following in 
weewx.conf

[StdReport]
  [[CheetahGenerator]]
 search_list_extensions = user.forecast.ForecastVariables 

work to get the variables available in all reports?

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