[weewx-user] Re: GW1000.py crashing when attempting to rediscover GW1000
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:
> 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
[weewx-user] weather submiting data to others
I have things setup and working in weewx for a fw of them like CWOP and APRS WU. I added the code for Weatherbug and downloaded and installed but not sure where to register to get the publisher id etc. From what I seen it looks like Weatherbug stopped PWS a few years ago but on the git hub it has activity like it may still be in use. -- 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/e72d11cd-57c1-4fe2-a770-8aa9ac1f6204n%40googlegroups.com.
Re: [weewx-user] plots and how to display a constant value ie a limit
Update on this issue.
First: I was wrong. The problem is not that weewx is attempting to evaluate
the constant as an xtype. The problem is in how we autoconfigure which
plots to create. The templates test to see whether there is any data in a
plot before deciding whether to generate it.
There is a workaround, which involves abandoning the test. In the file
telemetry.html.tmpl you'll find a stretch that looks something like this:
#for obs in $getobs($plot_name)
#if $getVar('year.%s.has_data' % $obs)
#set $show_plot = 1
#end if
#end for
Comment out the highlighted lines by using double hash marks, so it becomes:
#for obs in $getobs($plot_name)
##if $getVar('year.%s.has_data' % $obs)
#set $show_plot = 1
##end if
#end for
Now if you use an [ImageGenerator] spec such as the below, it will work:
[[[dayvolt]]]
yscale = 3.6, 4.2, 0.1
consBatteryVoltage
label = Transmitter battery
color = 0xb48242# blue
voltMin
data_type = 3.7
label = ' '
color = orange
width = 1
To user "plinepa":
You can do what you want by using the SQLite function "IIF()
". Unfortunately, it is
available only in SQLite 3.32 and later, which came out about 2 years ago.
It's still pretty rare, but you might get lucky. In that case, assuming
your database is in US Customary units, you could do something like this:
[[[dayoutTemp]]]
outTemp
freezing
data_type = "IIF(outTemp<48.0, 32.0, null)"
label = ' '
This produces a plot that looks like:
[image: image.png]
-tk
On Tue, Mar 8, 2022 at 10:42 PM 'plin...@googlemail.com' via weewx-user <
weewx-user@googlegroups.com> wrote:
> I am a beginnger and use the Seasons skin, I forgot to write that
>
> plin...@googlemail.com schrieb am Mittwoch, 9. März 2022 um 07:39:40
> UTC+1:
>
>> I'll join this thread for a moment.
>>
>> I also had the question of how to draw an additional line into a plot.
>>
>> So far I haven't been able to find anything about it in the instructions.
>> But since the topic is being discussed here...
>>
>> In my case, I want an additional line at 0°C on the temperature plots.
>> This would make it very easy to see if the temperatures have gone below
>> zero.
>>
>> But I only want this line at minimum temperatures below 0°C.
>> Is there any way I can link this to a condition?
>>
>> tke...@gmail.com schrieb am Mittwoch, 9. März 2022 um 01:05:57 UTC+1:
>>
>>> I was able to reproduce your error.
>>>
>>> It did work with v3.7. It appears that in my zeal to allow xtypes to be
>>> used in arbitrary plots, I broke something.
>>>
>>> I've opened issue #761 to
>>> track.
>>>
>>> -tk
>>>
>>> On Tue, Mar 8, 2022 at 3:35 PM ianpre...@gmail.com
>>> wrote:
>>>
Thanks
I won't pretend that I understood but it may help others.
It did give me a clue as to how to move forward a bit .I think
I tried this ...and it worked ..an orange line at 4v ...1
step forward
and telemetry display updates.
[[[dayvolt]]]
yscale = 3.6, 4.2, 0.1
consBatteryVoltage
label = Transmitter battery
color = 0xb48242# blue
#color = 0x4242b4# red
# place limit line on graph
voltMin
data_type = consBatteryVoltage - consBatteryVoltage + 4
label = ' '
color = orange
width = 1
but I want the limit at 3.7v so using the above
[[[dayvolt]]]
yscale = 3.6, 4.2, 0.1
consBatteryVoltage
label = Transmitter battery
color = 0xb48242# blue
#color = 0x4242b4# red
# place limit line on graph
voltMin
data_type = consBatteryVoltage - consBatteryVoltage +
3.7
label = ' '
color = orange
width = 1
fail errors in the log ...places the orange line, but telemetry
page is now frozen
Mar 9 08:56:06 weatherstn weewx[14006] DEBUG weewx.reportengine: Found
configuration file /etc/weewx/skins/Seasons/skin.conf for report
'SeasonsReport'
Mar 9 08:56:06 weatherstn weewx[14006] DEBUG user.MQTTSubscribe:
(Driver) data-> final loop packet is tele/weather-stn-sensor/STATE
2022-03-09 08:56:04 AEST (1646780164): 'batteryStatus1': '0.0',
'consBatteryVoltage': '4.086810112', 'dateTime': '1646780164.264368',
'extraTemp1': '33.0', 'signal1': '1515', 'signal2': '-34.0',
'supplyVoltage': '12.13632011', '
Re: [weewx-user] Ftdi error
Samuli Kettunen writes: > I've been using Davis Envoy + Weewx combo since 2011. About year ago I > moved Weewx from bare metal to Proxmox VM. Since that I have got ftdi > errors every 1-4 weeks that can be solved only by pulling usb-plug out and > putting it back again (for example system reboot does not restore > communication - ftdi chip needs to be actually depowered): I have not done what you are doing, but my guess is that your problems are that you are running a USB device drive in a VM, either PCI passthrough to the controller, or to an emulated controller which is then talking to hardware. You should understand what's really happening and it is likely pretty complicated. I don't know if weewx has easy support for this, but if you can run a process in the dom0 (host kernel on the hardware) and then connect weewx to that over TCP from inside the VM, you will have removed all the USB driver issues from the VM. -- 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/rmio827rm68.fsf%40s1.lexort.com. signature.asc Description: PGP signature
[weewx-user] Ftdi error
Hi I've been using Davis Envoy + Weewx combo since 2011. About year ago I moved Weewx from bare metal to Proxmox VM. Since that I have got ftdi errors every 1-4 weeks that can be solved only by pulling usb-plug out and putting it back again (for example system reboot does not restore communication - ftdi chip needs to be actually depowered): syslog: Mar 12 13:59:06 keito weewx[266587] ERROR weewx.drivers.vantage: LOOP try #1; error: Expected to read 99 chars; got 0 instead Mar 12 13:59:10 keito weewx[266587] ERROR weewx.drivers.vantage: LOOP try #2; error: Expected to read 99 chars; got 0 instead Mar 12 13:59:14 keito weewx[266587] ERROR weewx.drivers.vantage: LOOP try #3; error: Expected to read 99 chars; got 0 instead Mar 12 13:59:18 keito weewx[266587] ERROR weewx.drivers.vantage: LOOP try #4; error: Expected to read 99 chars; got 0 instead Mar 12 13:59:18 keito weewx[266587] ERROR weewx.drivers.vantage: LOOP max tries (4) exceeded. Mar 12 13:59:18 keito weewx[266587] INFO weewx.engine: Main loop exiting. Shutting engine down. Mar 12 13:59:18 keito weewx[266587] INFO weewx.engine: Shutting down StdReport thread Mar 12 13:59:18 keito kernel: [1654776.457856] ftdi_sio ttyUSB0: usb_serial_generic_write_bulk_callback - nonzero urb status: -71 Mar 12 13:59:18 keito kernel: [1654776.459321] ftdi_sio ttyUSB0: failed to get modem status: -71 Mar 12 13:59:18 keito kernel: [1654776.460276] ftdi_sio ttyUSB0: error from flowcontrol urb Mar 12 13:59:18 keito weewx[266587] CRITICAL __main__: Caught WeeWxIOError: Max tries exceeded while getting LOOP data. Mar 12 13:59:18 keito weewx[266587] CRITICAL __main__: Waiting 60 seconds then retrying... Mar 12 14:00:18 keito weewx[266587] INFO __main__: retrying... Mar 12 14:00:18 keito kernel: [1654836.516473] ftdi_sio ttyUSB0: ftdi_set_termios FAILED to set databits/stopbits/parity Mar 12 14:00:18 keito kernel: [1654836.517516] ftdi_sio ttyUSB0: ftdi_set_termios urb failed to set baudrate Mar 12 14:00:18 keito weewx[266587] INFO weewx.engine: Loading station type Vantage (weewx.drivers.vantage) Mar 12 14:00:18 keito weewx[266587] ERROR weewx.engine: Import of driver failed: [Errno 5] Input/output error () Mar 12 14:00:18 keito kernel: [1654836.518524] ftdi_sio ttyUSB0: failed to set flow control: -84 Mar 12 14:00:18 keito kernel: [1654836.520634] ftdi_sio ttyUSB0: failed to set flow control: -84 Mar 12 14:00:18 keito weewx[266587] CRITICAL weewx.engine: Traceback (most recent call last): Mar 12 14:00:18 keito weewx[266587] CRITICAL weewx.engine: File "/usr/share/weewx/weewx/engine.py", line 119, in setupStation Mar 12 14:00:18 keito weewx[266587] CRITICAL weewx.engine: self.console = loader_function(config_dict, self) Mar 12 14:00:18 keito weewx[266587] CRITICAL weewx.engine: File "/usr/share/weewx/weewx/drivers/vantage.py", line 40, in loader Mar 12 14:00:18 keito weewx[266587] CRITICAL weewx.engine: return VantageService(engine, config_dict) Mar 12 14:00:18 keito weewx[266587] CRITICAL weewx.engine: File "/usr/share/weewx/weewx/drivers/vantage.py", line 1916, in __init__ Mar 12 14:00:18 keito weewx[266587] CRITICAL weewx.engine: Vantage.__init__(self, **config_dict[DRIVER_NAME]) Mar 12 14:00:18 keito weewx[266587] CRITICAL weewx.engine: File "/usr/share/weewx/weewx/drivers/vantage.py", line 514, in __init__ Mar 12 14:00:18 keito weewx[266587] CRITICAL weewx.engine: self.port.openPort() Mar 12 14:00:18 keito weewx[266587] CRITICAL weewx.engine: File "/usr/share/weewx/weewx/drivers/vantage.py", line 309, in openPort Mar 12 14:00:18 keito weewx[266587] CRITICAL weewx.engine: self.serial_port = serial.Serial(self.port, self.baudrate, timeout=self.timeout) Mar 12 14:00:18 keito weewx[266587] CRITICAL weewx.engine: File "/usr/lib/python3/dist-packages/serial/serialutil.py", line 244, in __init__ Mar 12 14:00:18 keito weewx[266587] CRITICAL weewx.engine: self.open() Mar 12 14:00:18 keito weewx[266587] CRITICAL weewx.engine: File "/usr/lib/python3/dist-packages/serial/serialposix.py", line 343, in open Mar 12 14:00:18 keito weewx[266587] CRITICAL weewx.engine: self._update_dtr_state() Mar 12 14:00:18 keito weewx[266587] CRITICAL weewx.engine: File "/usr/lib/python3/dist-packages/serial/serialposix.py", line 691, in _update_dtr_state Mar 12 14:00:18 keito weewx[266587] CRITICAL weewx.engine: fcntl.ioctl(self.fd, TIOCMBIS, TIOCM_DTR_str) Mar 12 14:00:18 keito weewx[266587] CRITICAL weewx.engine: OSError: [Errno 5] Input/output error Mar 12 14:00:18 keito weewx[266587] CRITICAL __main__: Unable to load driver: [Errno 5] Input/output error Mar 12 14:00:18 keito weewx[266587] CRITICAL __main__: Exiting... Mar 12 14:00:18 keito kernel: [1654836.528654] ftdi_sio ttyUSB0: failed to get modem stat
Re: [weewx-user] Unable to wake up Vantage console
Use wee_device with --info to see if that can communicate, when weewx is not running. check cabling and that your serial port has the same name you are using in the driver config. http://www.weewx.com/docs/hardware.htm#vantage_notes -- 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/rmimthrt3cs.fsf%40s1.lexort.com. signature.asc Description: PGP signature
[weewx-user] Unable to wake up Vantage console
I am unsure how to start with this issue. I had to move out of my house
for a month during renovations, and left the Davis Vantage console plugged
into the garage to collect data. I took the computer to the hotel to use
for work, and I think WeeWX updated during that time.
Now that I am back in the house, I have connected the device back into the
computer. I got half a day of records, but then I started getting this
*CRITICAL
__main__: Unable to load driver: Unable to wake up Vantage console* error.
Maybe this is a quick fix?
Log to follow.
Dave
Mar 15 11:28:32 HP-Iron weewx[78695]: * Starting weewx weather system weewx
Mar 15 11:28:32 HP-Iron weewx[78706] INFO __main__: Initializing weewx
version 4.7.0
Mar 15 11:28:32 HP-Iron weewx[78706] INFO __main__: Using Python 3.8.10
(default, Nov 26 2021, 20:14:08) #012[GCC 9.3.0]
Mar 15 11:28:32 HP-Iron weewx[78706] INFO __main__: Platform
Linux-5.13.0-35-generic-x86_64-with-glibc2.29
Mar 15 11:28:32 HP-Iron weewx[78706] INFO __main__: Locale is 'en_US.UTF-8'
Mar 15 11:28:32 HP-Iron weewx[78706] INFO __main__: Using configuration
file /etc/weewx/weewx.conf
Mar 15 11:28:32 HP-Iron weewx[78706] INFO __main__: Debug is 0
Mar 15 11:28:32 HP-Iron weewx[78706] INFO __main__: PID file is
/var/run/weewx.pid
Mar 15 11:28:32 HP-Iron weewx[78720] INFO weewx.engine: Loading station
type Vantage (weewx.drivers.vantage)
Mar 15 11:28:32 HP-Iron weewx[78695]:...done.
Mar 15 11:28:53 HP-Iron weewx[78720] ERROR weewx.drivers.vantage: Unable to
wake up console
Mar 15 11:28:53 HP-Iron weewx[78720] ERROR weewx.engine: Import of driver
failed: Unable to wake up Vantage console ()
Mar 15 11:28:53 HP-Iron weewx[78720] CRITICAL weewx.engine:
Traceback (most recent call last):
Mar 15 11:28:53 HP-Iron weewx[78720] CRITICAL weewx.engine:
File "/usr/share/weewx/weewx/engine.py", line 119, in setupStation
Mar 15 11:28:53 HP-Iron weewx[78720] CRITICAL weewx.engine:
self.console = loader_function(config_dict, self)
Mar 15 11:28:53 HP-Iron weewx[78720] CRITICAL weewx.engine:
File "/usr/share/weewx/weewx/drivers/vantage.py", line 40, in loader
Mar 15 11:28:53 HP-Iron weewx[78720] CRITICAL weewx.engine:
return VantageService(engine, config_dict)
Mar 15 11:28:53 HP-Iron weewx[78720] CRITICAL weewx.engine:
File "/usr/share/weewx/weewx/drivers/vantage.py", line 1916, in __init__
Mar 15 11:28:53 HP-Iron weewx[78720] CRITICAL weewx.engine:
Vantage.__init__(self, **config_dict[DRIVER_NAME])
Mar 15 11:28:53 HP-Iron weewx[78720] CRITICAL weewx.engine:
File "/usr/share/weewx/weewx/drivers/vantage.py", line 517, in __init__
Mar 15 11:28:53 HP-Iron weewx[78720] CRITICAL weewx.engine:
self._setup()
Mar 15 11:28:53 HP-Iron weewx[78720] CRITICAL weewx.engine:
File "/usr/share/weewx/weewx/drivers/vantage.py", line 1335, in _setup
Mar 15 11:28:53 HP-Iron weewx[78720] CRITICAL weewx.engine:
self.port.wakeup_console(max_tries=self.max_tries)
Mar 15 11:28:53 HP-Iron weewx[78720] CRITICAL weewx.engine:
File "/usr/share/weewx/weewx/drivers/vantage.py", line 120, in
wakeup_console
Mar 15 11:28:53 HP-Iron weewx[78720] CRITICAL weewx.engine:
raise weewx.WakeupError("Unable to wake up Vantage console")
Mar 15 11:28:53 HP-Iron weewx[78720] CRITICAL weewx.engine:
weewx.WakeupError: Unable to wake up Vantage console
Mar 15 11:28:53 HP-Iron weewx[78720] CRITICAL __main__: Unable to load
driver: Unable to wake up Vantage console
Mar 15 11:28:53 HP-Iron weewx[78720] CRITICAL __main__: 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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/weewx-user/3bb52705-9e83-4b35-a78d-27858ac5bf76n%40googlegroups.com.
[weewx-user] GW1000.py crashing when attempting to rediscover GW1000
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: MQTT Belchertown server_url Syntax?
On Tuesday, March 15, 2022 at 7:56:04 AM UTC-7 Geni wrote: > I have now installed the Mosquitto on the weewx-raspi that still has > Buster Lite and there was still the version 1.5.7 installed. The error is > only " Address already in use". > > pi@Wetter-Raspi:~$ mosquitto -v > 1647355421: mosquitto version 1.5.7 starting > 1647355421: Using default config. > 1647355421: Opening ipv4 listen socket on port 1883. > 1647355421: Error: Address already in use > > You have the mosquitto MQTT server already listening, so this is normal. Run "sudo netstat -tupln" and you will see the broker is listening. A simple MQTT test is to use mosquitto_sub and mosquitto_pub in two shell windows. In the first window:"mosquitto_sub -h x.x.x.x -t testing" In the second window: "mosquitto_pub -h x.x.x.x -t testing -m testing123" (Use your ip address instead of x.x.x.x in the commands above) -- 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/810e4001-1e65-4c84-b723-928439cf425bn%40googlegroups.com.
[weewx-user] Re: MQTT Belchertown server_url Syntax?
I have now installed the Mosquitto on the weewx-raspi that still has Buster Lite and there was still the version 1.5.7 installed. The error is only " Address already in use". pi@Wetter-Raspi:~$ mosquitto -v 1647355421: mosquitto version 1.5.7 starting 1647355421: Using default config. 1647355421: Opening ipv4 listen socket on port 1883. 1647355421: Error: Address already in use weewx produces the following: Mar 15 15:38:36 Wetter-Raspi weewx[1491] INFO weewx.manager: Starting backfill of daily summaries Mar 15 15:38:36 Wetter-Raspi weewx[1491] INFO weewx.manager: Daily summaries up to date Mar 15 15:38:36 Wetter-Raspi weewx[1491] DEBUG weewx.drivers.vantage: Getting archive packets since 2022-03-15 15:30:00 CET (1647354600) Mar 15 15:38:36 Wetter-Raspi weewx[1491] DEBUG weewx.drivers.vantage: Gentle wake up of console successful Mar 15 15:38:36 Wetter-Raspi weewx[1491] DEBUG weewx.drivers.vantage: Retrieving 0 page(s); starting index= 0 Mar 15 15:38:36 Wetter-Raspi weewx[1491] INFO weewx.engine: Starting main packet loop. Mar 15 15:38:36 Wetter-Raspi weewx[1491] DEBUG weewx.drivers.vantage: Gentle wake up of console successful Mar 15 15:38:36 Wetter-Raspi weewx[1491] DEBUG weewx.drivers.vantage: Requesting 200 LOOP packets. Mar 15 15:38:36 Wetter-Raspi weewx[1491] DEBUG weewx.drivers.vantage: Gentle wake up of console successful Mar 15 15:38:37 Wetter-Raspi weewx[1491] DEBUG user.mqtt: Failed upload attempt 1: [Errno 104] Die Verbindung wurde vom Kommunikationspartner zurückgesetzt Mar 15 15:38:42 Wetter-Raspi weewx[1491] DEBUG user.mqtt: Failed upload attempt 2: [Errno 104] Die Verbindung wurde vom Kommunikationspartner zurückgesetzt Mar 15 15:38:47 Wetter-Raspi weewx[1491] DEBUG user.mqtt: Failed upload attempt 3: [Errno 104] Die Verbindung wurde vom Kommunikationspartner zurückgesetzt Mar 15 15:38:52 Wetter-Raspi weewx[1491] ERROR weewx.restx: MQTT: Failed to publish record 2022-03-15 15:38:37 CET (1647355117): Failed upload after 3 tries Mar 15 15:38:52 Wetter-Raspi weewx[1491] DEBUG user.mqtt: Failed upload attempt 1: [Errno 104] Die Verbindung wurde vom Kommunikationspartner zurückgesetzt Mar 15 15:38:57 Wetter-Raspi weewx[1491] DEBUG user.mqtt: Failed upload attempt 2: [Errno 104] Die Verbindung wurde vom Kommunikationspartner zurückgesetzt Mar 15 15:39:01 Wetter-Raspi CRON[1514]: (pi) CMD (sudo wget -q http://alarm.meteocentrale.ch/images/map/schweiz_index.png -O /home/pi/wetter/meteo/uwz.png) Mar 15 15:39:01 Wetter-Raspi automount[535]: key ".config" not found in map source(s). Mar 15 15:39:02 Wetter-Raspi weewx[1491] DEBUG user.mqtt: Failed upload attempt 3: [Errno 104] Die Verbindung wurde vom Kommunikationspartner zurückgesetzt Mar 15 15:39:07 Wetter-Raspi weewx[1491] ERROR weewx.restx: MQTT: Failed to publish record 2022-03-15 15:38:37 CET (1647355117): Failed upload after 3 tries I think the error comes from "https://github.com/matthewwall/weewx-mqtt/archive/master.zip";. This has not been maintained for more than 2 years, is there an alternative? The function test with MQTT.fx works fine How can I narrow down the error? Geni vince schrieb am Montag, 14. März 2022 um 18:17:10 UTC+1: > Yes of course they can run on any model pi. > > Google the message you highlighted in yellow and red for many threads > about this. > > In v2 the default is to listen only on localhost so you need to configure > it to listen on all interfaces. See > https://mosquitto.org/man/mosquitto-conf-5.html and the 'listener' > section. Set your bind_address to 0.0.0.0 to listen on all interfaces. > -- 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/c265023b-2ad6-4633-94c8-a1113b1508c3n%40googlegroups.com.
[weewx-user] Re: Station upgrade advice (Acurite -> Davis)
I'm using a VP2 - about 12 years worth now. My connection is via a serial Weatherlink in a Weather Envoy, as my weewx install is in the basement and my console is upstairs in the living room. Since the WL Live came out the Envoy is more affordable than it used to be, and works great. If you can put your console next to (or close to) the weewx PC then you can just use the serial/USB module, otherwise you'll need the Envoy. I use the standard anemometer on my roof; I also have a Tempest with sonic anemometer, and it doesn't seem to be quite as accurate or sensitive as the old-school version. (It's also $500 extra, and I'm cheap...) My anemometer has needed absolutely no maintenance in that 12 years. I'm also thinking about using the AirLink if I can get it's data pulled into weewx and integrated, but haven't seen any discussion about it in here. Next plan is to start using the Tempest to report into a weewx instance and see how it compares to the VP2, If it's accurate and reliable it'll go up on the roof pole with the VP2 anemometer and do it's thing. On Monday, March 14, 2022 at 4:33:20 AM UTC-8 do...@dougjenkins.com wrote: > > 1. Should I use the WeatherLink or a direct connection module? Pros/Cons? > 2. Has anyone used the Air Quality module from Davis on their weather > station and reported the data using WeeWX? > 3. Has anyone used the Davis Sonic Anemometer? I am thinking of putting > the anemometer high up on the tower (33ft/10m), but maintaining that will > be a big chore. I am surrounded by large oaks, so the higher the > anemometer, the better wind reading. > > -- 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/7dc8e108-0fd7-4acb-ab88-36aa2db142ecn%40googlegroups.com.
