Re: [weewx-user] Not reporting Wind Gusts

[Francisco Puig]

Ok, finally I had time and disabled "rapidfire" and the wind gust started 
reporting fine on WU. So the question is, is there a way that I can get the 
gusts reporting with rapifire ON or, could be possible to decrease the 
reporting interval of the script with the rapidfire in OFF?

Thanks for the help...

On Sunday, November 26, 2017 at 1:14:25 AM UTC-5, gjr80 wrote:
>
> It may well have worked before but it is not now. Other services such as 
> CWOP, WOW etc are updated every archive period using data from the archive 
> record covering that archive period. Many stations report windSpeed in loop 
> packets but windGust is not calculated/reported (by weeWX or the station) 
> until the end of the archive period when windGust is calculated as the 
> highest loop packet windSpeed value seen during the archive period. 
> Rapidfire uses loop packets, so if there is no windGust field included in 
> the loop packet then no windGust data will be posted. Because windGust is 
> included in the archive record posting to CWOP etc includes the windGust 
> data.
>
> You can see what is in each loop packet along with what is being posted to 
> WU when using rapidfire by turning on rapidfire and setting debug=3. There 
> will be an entry in the log just before each rapidfire post that lists the 
> contents of the loop packet.
>
> 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.

[weewx-user] Re: FineOffset Hang ups

[Andrew Dibbins]

I must admit, I had a similar issue, for me I was locking up repeatedly 
weekly and then sometimes daily.

I started on a separate project to remove the lcd display from my WS, by 
using weewx-sdr, but it hasn't worked out well for me, see other threads.

For me the solution has been very simple, as a post somewhere mentioned a 
similar issue, but their problem was a mechanical or quality issue releated 
to the internal wire antenna in the LCD display.
I dismantled my lcd display and carefully re-routed the wire inside the lcd 
to avoid it being trapped by sharp edges of the case, and that has fixed 
it, I haven't had a lock up since.

Worth considering ?

Rgds Andy

On Monday, 11 December 2017 22:54:03 UTC, Redanman wrote:
>
> My old WH1080 is getting more more and more USB hang-ups.  I have to reset 
> the unit (remove the USB cable) to reboot the it.  I obviously lose the 
> data in the circular buffer, so, depending on when I notice the hang-up, it 
> leads to data loss of several hours or even days.
> I power the WH1080 through the USB cable connected to my Pi, but I do not 
> have a USB hub, so cannot cycle the power through the hub.  I have noticed 
> that if I reboot the Pi it cycles the power on the Pi's own USB ports, so 
> resetting the WH1080.  Is it possible to do this automatically within Weewx 
> if it detects a USB hang-up?
> Mike

-- 
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] --reading failure in weewx_3.8.0-1 and weewx-owfs-0.21 Raspberry Pi & DS18B20

[Glenn McKechnie]

Well, it's a bit of a puzzle

We know you have had it working with owfs.py as your first post shows
it returning a result when you used the --iface localhost:4304


On 12 December 2017 at 23:32, mixpc75  wrote:
> Dear Glenn,
>
[...]

> PYTHONPATH=/usr/share/weewx python /usr/share/weewx/user/owfs.py --sensors
> gives the usual error:
> Traceback (most recent call last):
>   File "/usr/share/weewx/user/owfs.py", line 618, in 
> main()
>   File "/usr/share/weewx/user/owfs.py", line 578, in main
> ow.init(iface)
>   File "/usr/lib/python2.7/dist-packages/ow/__init__.py", line 224, in init
> raise exNoController
> ow.exNoController

you've forgotten to add the --iface string ' --iface localhost:4304 '
. Add that and see if it works again.

[...]

> PYTHONPATH=/usr/share/weewx python /usr/share/weewx/user/owfs.py --iface
> localhost:4304 --sensors
> PYTHONPATH=/usr/share/weewx sudo python /usr/share/weewx/user/owfs.py
> --iface localhost:4304 --sensors
> result in the same respective errors as indicated above

Now I'm really confused, because you had it working before with that
exact same command...

pi@raspberrypi:~ $ sudo PYTHONPATH=/usr/share/weewx python
/usr/share/weewx/user/owfs.py --iface localhost:4304 --sensors
67C6697351FF: /10.67C6697351FF DS18S20
4AEC29CDBAAB: /05.4AEC29CDBAAB DS2405

although I note that you've switched sudos positioning.

[...]

> Just to check weewx status I run
> pi@raspberrypi:~ $ sudo systemctl status weewx.service
> ● weewx.service - LSB: weewx weather system
>Loaded: loaded (/etc/init.d/weewx; generated; vendor preset: enabled)
>Active: active (exited) since Tue 2017-12-12 13:20:34 CET; 1min 53s ago
>  Docs: man:systemd-sysv-generator(8)
>   Process: 249 ExecStart=/etc/init.d/weewx start (code=exited,
> status=0/SUCCESS)
>CGroup: /system.slice/weewx.service
>
> Dec 12 13:20:34 raspberrypi weewx[349]: owfs: driver version is 0.21
> Dec 12 13:20:34 raspberrypi weewx[349]: owfs: interface is localhost:4304
> Dec 12 13:20:34 raspberrypi weewx[349]: owfs: sensor map is {}
> Dec 12 13:20:34 raspberrypi weewx[349]: owfs: sensor type map is {}
> Dec 12 13:20:34 raspberrypi weewx[349]: owfs: polling interval is 10
> Dec 12 13:20:34 raspberrypi weewx[349]: owfs: sensor unit system is metric
> Dec 12 13:20:39 raspberrypi OWFS[349]: DEFAULT: owlib.c:(52) No valid 1-wire
> buses found
> Dec 12 13:20:39 raspberrypi OWFS[349]: import of driver failed:  ( 'ow.exNoController'>)
> Dec 12 13:20:39 raspberrypi OWFS[349]: engine: Unable to load driver:
> Dec 12 13:20:39 raspberrypi OWFS[349]:   Exiting...
>
> So there it is, the same error. So it seems now there is no way to get the
> --sensors value... I have attached a link to the three config files:

Indeed, it's not working. I wonder if changing to an IP would make a difference?

interface = 127.0.0.1:4304

The port 4304 was working before and is the one in the owfs.conf file
so that should be correct.
If you run...
netstat -nlp
you can check and confirm if it's actually listening there. The
owfs.py notes suggest 3003 but...?

[...]

In summary
we know you had it working from the command line
we know it's at (or was at)  localhost:4304 and that --iface
localhost:4304  worked
It appears that - weewx.conf is not accepting that as the interface entry?

I see the other thread has become active and offers further insight ,
I shall move there - if required!


Cheers
 Glenn

rorpi - read only raspberry pi & various weewx addons
https://github.com/glennmckechnie

-- 
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] Acurite (ugh), and weewx ona RasbPi.

[John Pierce]

I'm running weewx on a raspberry pi3 attached to a AcuRite 01036CDI (Costco 
Special).

I've been getting a lot of gaps in my data. the station instrument has 
fresh batteries, there is only like 40-50'  and a plaster+beam ceiling and 
asphalt shingle roof between the instrument and the display panel.   last 
24 hours temps have been low: 46F, high: 70 F, so I don't think its 
temperature related.

my panel has no USB mode setting.   

during these dropped data intervals, its logging like...

Dec 12 06:22:20 raspberrypi weewx[457]: restx: Wunderground-PWS: Published 
record 2017-12-12 06:22:00 PST (1513088520)
Dec 12 06:22:25 raspberrypi weewx[457]: cheetahgenerator: Generated 14 
files for report StandardReport in 5.83 seconds
Dec 12 06:22:27 raspberrypi weewx[457]: imagegenerator: Generated 12 images 
for StandardReport in 1.57 seconds
Dec 12 06:22:27 raspberrypi weewx[457]: copygenerator: copied 0 files to 
/var/weewx/reports
Dec 12 06:22:28 raspberrypi weewx[457]: cheetahgenerator: Generated 1 files 
for report simple in 0.50 seconds
Dec 12 06:22:30 raspberrypi weewx[457]: imagegenerator: Generated 16 images 
for simple in 1.99 seconds
Dec 12 06:22:30 raspberrypi weewx[457]: rsyncupload: rsync'd 43 files 
(158,417 bytes) in 0.84 seconds
Dec 12 06:22:38 raspberrypi weewx[457]: acurite: R1: ignoring stale data 
(rssi indicates no communication from sensors): 01 90 c8 78 00 46 59 32 00 
00
Dec 12 06:22:56 raspberrypi weewx[457]: acurite: R1: ignoring stale data 
(rssi indicates no communication from sensors): 01 90 c8 78 00 46 59 32 00 
00
Dec 12 06:23:14 raspberrypi weewx[457]: acurite: R1: ignoring stale data 
(rssi indicates no communication from sensors): 01 90 c8 78 00 46 59 32 00 
00
Dec 12 06:23:32 raspberrypi weewx[457]: acurite: R1: ignoring stale data 
(rssi indicates no communication from sensors): 01 90 c8 78 00 46 59 32 00 
00
Dec 12 06:23:50 raspberrypi weewx[457]: acurite: R1: ignoring stale data 
(rssi indicates no communication from sensors): 01 90 c8 78 00 46 59 32 00 
00
Dec 12 06:24:08 raspberrypi weewx[457]: acurite: R1: ignoring stale data 
(rssi indicates no communication from sensors): 01 90 c8 78 00 46 59 32 00 
00
Dec 12 06:24:26 raspberrypi weewx[457]: acurite: R1: ignoring stale data 
(rssi indicates no communication from sensors): 01 90 c8 78 00 46 59 32 00 
00
Dec 12 06:24:26 raspberrypi weewx[457]: manager: Added record 2017-12-12 
06:24:00 PST (1513088640) to database 'weewx'
Dec 12 06:24:27 raspberrypi weewx[457]: manager: Added record 2017-12-12 
06:24:00 PST (1513088640) to daily summary in 'weewx'
Dec 12 06:24:27 raspberrypi weewx[457]: restx: Wunderground-PWS: Published 
record 2017-12-12 06:24:00 PST (1513088640)
Dec 12 06:24:32 raspberrypi weewx[457]: cheetahgenerator: Generated 14 
files for report StandardReport in 5.09 seconds
Dec 12 06:24:33 raspberrypi weewx[457]: imagegenerator: Generated 12 images 
for StandardReport in 1.53 seconds
Dec 12 06:24:33 raspberrypi weewx[457]: copygenerator: copied 0 files to 
/var/weewx/reports
Dec 12 06:24:34 raspberrypi weewx[457]: cheetahgenerator: Generated 1 files 
for report simple in 0.37 seconds
Dec 12 06:24:36 raspberrypi weewx[457]: imagegenerator: Generated 16 images 
for simple in 1.87 seconds
Dec 12 06:24:36 raspberrypi weewx[457]: rsyncupload: rsync'd 43 files 
(158,605 bytes) in 0.86 seconds

and the ISS Signal Quality Graph looks like...














any idea whats going on here?

-- 
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: Newbie looking for hardware suggestions.

[mwall]

On Tuesday, December 12, 2017 at 2:29:59 PM UTC-5, vince wrote:
>
>
> Matthew do you have a Amazon link for the precise model for a bridge ? 
>

afaik, there is only one device - the bridge.  it recognizes RF signals 
from the acurite sensors then emits them over wired tcp/ip as http GET 
requests to wu and/or the acurite web servers.

acurite did a forced update of the firmware in 2016, and around that time 
they changed the branding from 'acurite bridge' to 'smarthub'

https://github.com/weewx/weewx/wiki/acuritebridge

a year or two ago i picked up some t/h sensors at walmart once for $5 each 
- they work fine with the bridge.  (don't recall the model number, but they 
look exactly like the ones in the 01059RM amazon link you posted)

you can also sniff the RF traffic using an SDR USB device.  but the bridge 
is nice because it has a pressure sensor on it - if you go the SDR route 
then you'll have to build your own pressure sensor.

the t/h sensors have a dip switch inside with 3 positions - channels A, B, 
and C.  but each sensor also has a serial number, so there should be no 
limit to the number of sensors you can monitor (the weewx-interceptor and 
weewx-sdr drivers use the serial number, not the channel, to identify 
sensors).

batteries in the t/h units have lasted 2 years, but we often just replace 
once each year as part of a regular maintenance schedule.

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.

[weewx-user] Re: FineOffset Hang ups

[Redanman]

I've already tried 2 and 3.  I could procure a powered hub but I assumed 
that the power_cycle_station code in fousb.py was there for all those 
people for whom your 3 steps did not resolve the problem.  For the time 
being I've modified my config to pretend that I have a powered USB hub and 
rather than calling power_cycle_station when the console hangs I have added 
a line to reboot the Pi.  I'll see what that does.

On Tuesday, 12 December 2017 14:16:36 UTC, Andrew Milner wrote:
>
> 1. Do not use the rpi usb port directly, use a powered hub to power the 
> station (but I also keep batteries in the station)- even if you cannot 
> switch the port on and off
> 2. Ensure the usb cable to the station goes nowehere near power supplies 
> or screens - route it carefully away from all sources of possible 
> interference.
> 3. Consider magnetic rings for the usb lead - again to reduce interference 
> issues
>
> Following the above 'rules' my Fine Offset very rarely 'locks up', and in 
> fact I cannot remember when I last had a problem - so have never needed to 
> use the powered hub reset method.
>
> It seems to me that one is better solving the cause, or minimising the 
> chances of lock up occurring, rather than focussing on recovery methods.
>
>
>
> On Tuesday, 12 December 2017 14:31:42 UTC+2, Redanman wrote:
>
>> Yes, I did look at the Wiki on FineOffset lock-ups, but as I mentioned in 
>> post I do not have a powered hub.  A solution for me seems to be intimated 
>> in the latter part of the post with a dedicated scripted to look at the 
>> syslog file and react to the specific message related to USB hang-ups.  The 
>> Pi shuts downs in a coordinated fashion and then a 555 watchdog restarts 
>> the Pi.  That would work for me although I would prefer to just do "sudo 
>> reboot" rather than mess with a 555 circuit.  I was hoping for some more 
>> details on this solution.
>>
>> On Tuesday, 12 December 2017 08:58:16 UTC, Thorsten Wöll wrote:
>>>
>>> Take a close look here:
>>>
>>> https://github.com/weewx/weewx/wiki/FineOffset-USB-lockup
>>>
>>> Am Montag, 11. Dezember 2017 23:54:03 UTC+1 schrieb Redanman:

 My old WH1080 is getting more more and more USB hang-ups.  I have to 
 reset the unit (remove the USB cable) to reboot the it.  I obviously lose 
 the data in the circular buffer, so, depending on when I notice the 
 hang-up, it leads to data loss of several hours or even days.
 I power the WH1080 through the USB cable connected to my Pi, but I do 
 not have a USB hub, so cannot cycle the power through the hub.  I have 
 noticed that if I reboot the Pi it cycles the power on the Pi's own USB 
 ports, so resetting the WH1080.  Is it possible to do this automatically 
 within Weewx if it detects a USB hang-up?
 Mike
>>>
>>>

-- 
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: Newbie looking for hardware suggestions.

[John Russell]

Hi Vince,

Those are the same exact links I've found on Amazon for the "bridge".  They 
are also the same exact prices on the acurite website (with free shipping 
there too).

Here 
is 
the sensor itself on the accurite website and there it has compatible 
hardware on the receiving end.  Perhaps check your hardware for a match and 
maybe you can use your same sensor with a newly purchased bridge.

John

On Tuesday, December 12, 2017 at 2:29:59 PM UTC-5, vince wrote:
>
> On Tuesday, December 12, 2017 at 10:38:59 AM UTC-8, mwall wrote:
>
>> the acurite consoles are horrible wrt comms - there are firmware bugs, 
>> they revert to usb mode 2 (no comms) after power cycle, and we had to do a 
>> lot of hacking to ensure that we could get good data from them.  but they 
>> are quite nice from a display point of view - the ticker is lame, but the 
>> rest of the display is better than most low-end weather stations.
>>
>> the bridge performs flawlessly.  if you are loath to give away your data, 
>> you can prevent it from sending data to acurite by using your own dns on 
>> your lan.  you can run weewx-interceptor in either sniff or listen mode, 
>> depending on your network configuration and skills.
>>
>>
> Matthew do you have a Amazon link for the precise model for a bridge ?   
> Their model listings are a little confusing and use different 
> terminology
>
>-  
>
> https://www.amazon.com/AcuRite-09150-smartHUB-Remote-Monitoring/dp/B00T5U1JRE 
>- is this the bridge (aka smartHUB) ?
>-  
>
> https://www.amazon.com/AcuRite-01166M-3-Sensor-Temperature-Monitoring/dp/B00WXIR2TE
>  
>- is this the same, just with 3 temp/humidity sensors ?
>
> I currently have a 
> https://www.amazon.com/AcuRite-00418-Wireless-Thermometer-Clock/dp/B004V1XK6A 
> which indeed seems to last a year+ on a couple batteries, mainly to get a 
> quickie display into the house and 'semi-close' temperature, but if the 
> sensors are the same and a bridge could let me and easily integrate several 
> easily with weewx, that would be pretty cool to fiddle with.  
>
>
>

-- 
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: Newbie looking for hardware suggestions.

[John Russell]

Thanks for the reply, I think I'll give the acurite stuff a try.  Maybe 
I'll tell my wife that I'll buy if for my own Christmas gift this year... :)

John

On Tuesday, December 12, 2017 at 1:38:59 PM UTC-5, mwall wrote:
>
> On Tuesday, December 12, 2017 at 1:27:14 PM UTC-5, John Russell wrote:
>>
>> Thanks m,  This appears to be exactly what I was looking for.  The 
>> "smartHUB" is the bridge you're referring to, correct? Do you have any 
>> hand-on experience with their equipment, especially with regards to 
>> integration with weeWX? I'll do some searches to see what I can find, but 
>> it's definitely a modular approach and their range of sensors looks to be 
>> good!
>>
>
> i've been using acurite hardware at 3 different locations since 2013 (i 
> think the first acurite usb driver was released dec 2013, and i think the 
> bridge/smarthub driver came out summer of 2014)
>
> the acurite consoles are horrible wrt comms - there are firmware bugs, 
> they revert to usb mode 2 (no comms) after power cycle, and we had to do a 
> lot of hacking to ensure that we could get good data from them.  but they 
> are quite nice from a display point of view - the ticker is lame, but the 
> rest of the display is better than most low-end weather stations.
>
> (te923 have the most readable display, imho.  but i would avoid all 
> consoles and just use an android tablet - that way you get not just 
> easy-to-read, but also information display that beats *any* weather station)
>
> the bridge performs flawlessly.  if you are loath to give away your data, 
> you can prevent it from sending data to acurite by using your own dns on 
> your lan.  you can run weewx-interceptor in either sniff or listen mode, 
> depending on your network configuration and skills.
>
> the sensors seem to be pretty solid - they track pretty closely with those 
> from other vendors.
>
> the lightning sensors were pretty flaky in the first batches, but they 
> seem to be better now.  but you'll need an sdr dongle to capture lightning 
> data (the bridge does not understand output from the lightning sensors).
>
> i would avoid netatmo - they actively prevent you from getting your own 
> data unless you go through their servers.
>
> weatherflow is a much better option if you want to go with a netatmo 
> equivalent.
>
> 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.

[weewx-user] Re: Newbie looking for hardware suggestions.

[vince]

On Tuesday, December 12, 2017 at 10:38:59 AM UTC-8, mwall wrote:

> the acurite consoles are horrible wrt comms - there are firmware bugs, 
> they revert to usb mode 2 (no comms) after power cycle, and we had to do a 
> lot of hacking to ensure that we could get good data from them.  but they 
> are quite nice from a display point of view - the ticker is lame, but the 
> rest of the display is better than most low-end weather stations.
>
> the bridge performs flawlessly.  if you are loath to give away your data, 
> you can prevent it from sending data to acurite by using your own dns on 
> your lan.  you can run weewx-interceptor in either sniff or listen mode, 
> depending on your network configuration and skills.
>
>
Matthew do you have a Amazon link for the precise model for a bridge ?   
Their model listings are a little confusing and use different 
terminology

   -  
   
https://www.amazon.com/AcuRite-09150-smartHUB-Remote-Monitoring/dp/B00T5U1JRE 
   - is this the bridge (aka smartHUB) ?
   -  
   
https://www.amazon.com/AcuRite-01166M-3-Sensor-Temperature-Monitoring/dp/B00WXIR2TE
 
   - is this the same, just with 3 temp/humidity sensors ?
   
I currently have a 
https://www.amazon.com/AcuRite-00418-Wireless-Thermometer-Clock/dp/B004V1XK6A 
which indeed seems to last a year+ on a couple batteries, mainly to get a 
quickie display into the house and 'semi-close' temperature, but if the 
sensors are the same and a bridge could let me and easily integrate several 
easily with weewx, that would be pretty cool to fiddle with.  


-- 
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: Newbie looking for hardware suggestions.

[Andrew Milner]

Matthew

Do you have a weatherflow driver for weewx??

Andrew


On Tuesday, 12 December 2017 20:38:59 UTC+2, mwall wrote:

> On Tuesday, December 12, 2017 at 1:27:14 PM UTC-5, John Russell wrote:
>>
>> Thanks m,  This appears to be exactly what I was looking for.  The 
>> "smartHUB" is the bridge you're referring to, correct? Do you have any 
>> hand-on experience with their equipment, especially with regards to 
>> integration with weeWX? I'll do some searches to see what I can find, but 
>> it's definitely a modular approach and their range of sensors looks to be 
>> good!
>>
>
> i've been using acurite hardware at 3 different locations since 2013 (i 
> think the first acurite usb driver was released dec 2013, and i think the 
> bridge/smarthub driver came out summer of 2014)
>
> the acurite consoles are horrible wrt comms - there are firmware bugs, 
> they revert to usb mode 2 (no comms) after power cycle, and we had to do a 
> lot of hacking to ensure that we could get good data from them.  but they 
> are quite nice from a display point of view - the ticker is lame, but the 
> rest of the display is better than most low-end weather stations.
>
> (te923 have the most readable display, imho.  but i would avoid all 
> consoles and just use an android tablet - that way you get not just 
> easy-to-read, but also information display that beats *any* weather station)
>
> the bridge performs flawlessly.  if you are loath to give away your data, 
> you can prevent it from sending data to acurite by using your own dns on 
> your lan.  you can run weewx-interceptor in either sniff or listen mode, 
> depending on your network configuration and skills.
>
> the sensors seem to be pretty solid - they track pretty closely with those 
> from other vendors.
>
> the lightning sensors were pretty flaky in the first batches, but they 
> seem to be better now.  but you'll need an sdr dongle to capture lightning 
> data (the bridge does not understand output from the lightning sensors).
>
> i would avoid netatmo - they actively prevent you from getting your own 
> data unless you go through their servers.
>
> weatherflow is a much better option if you want to go with a netatmo 
> equivalent.
>
> m
>

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

Re: [weewx-user] Re: weewx-owfs failure with new Raspbian Stretch

[mixpc75]

Matthew,

Thank you for the link. File owfs-3.2p1.tar.gz downloaded from sourceforge

Please, kindly have a look at attached .txt file for the compilation
output. It took a bit.

After compilation:

pi@raspberrypi:~/owfs-3.2p1 $ sudo LD_LIBRARY_PATH=/opt/owfs-2.9p5/
PYTHONPATH=/home/weewx/bin python /home/weewx/bin/user/owfs.py --sensors
python: can't open file '/home/weewx/bin/user/owfs.py': [Errno 2] No such
file or directory


pi@raspberrypi:~/owfs-3.2p1 $ sudo LD_LIBRARY_PATH=/opt/owfs-2.9p5/
PYTHONPATH=/usr/share/weewx python /usr/share/weewx/user/owfs.py --sensors
Traceback (most recent call last):
  File "/usr/share/weewx/user/owfs.py", line 618, in 
main()
  File "/usr/share/weewx/user/owfs.py", line 578, in main
ow.init(iface)
  File "/usr/lib/python2.7/dist-packages/ow/__init__.py", line 224, in init
raise exNoController
ow.exNoController

pi@raspberrypi:~/owfs-3.2p1 $ sudo LD_LIBRARY_PATH=/opt/owfs-2.9p5/lib
PYTHONPATH=/usr/share/weewx python /usr/share/weewx/user/owfs.py --sensors
Traceback (most recent call last):
  File "/usr/share/weewx/user/owfs.py", line 618, in 
main()
  File "/usr/share/weewx/user/owfs.py", line 578, in main
ow.init(iface)
  File "/usr/lib/python2.7/dist-packages/ow/__init__.py", line 224, in init
raise exNoController
ow.exNoController

Any indication or tip is welcome, of course.

Regards,



On 12 December 2017 at 18:52, mwall  wrote:

> btw, you can download the code for owfs software (not the weewx-owfs
> driver/service) from sourceforge:
>
> http://owfs.org/
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-user+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

cd owfs-3.2p1/

sudo ./configure --prefix=/opt/owfs-2.9p5 --disable-owhttpd --disable-owftpd 
--disable-owserver --disable-owperl --disable-owphp --disable-owtcl 
--disable-i2c --disable-w1 --disable-parport --disable-owcapi --disable-owmon 
--disable-owtap --disable-owshell --disable-owexternal --disable-debug 
--disable-ownet --disable-ownetlib --enable-owpython --enable-usb

checking whether make supports nested variables... yes
Configuring owfs-3.2p1
checking build system type... armv6l-unknown-linux-gnueabihf
checking host system type... armv6l-unknown-linux-gnueabihf
checking target system type... armv6l-unknown-linux-gnueabihf
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking for echo... /bin/echo
checking for test... /usr/bin/test
checking for rm... /bin/rm
checking for rpm... no
checking for rpmbuild... no
checking for swig... no
checking for soelim... /usr/bin/soelim
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking whether ln -s works... yes
checking whether make sets $(MAKE)... (cached) yes
checking for gawk... (cached) mawk
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking the maximum length of command line arguments... 1572864
checking how to convert armv6l-unknown-linux-gnueabihf file names to 
armv6l-unknown-linux-gnueabihf format... func_convert_file_noo  

 p
checking how to convert armv6l-unknown-linux-gnueabihf file names to toolchain 
format... func_convert_file_noop
checking for /usr/bin/ld o

[weewx-user] Re: Newbie looking for hardware suggestions.

[mwall]

On Tuesday, December 12, 2017 at 1:27:14 PM UTC-5, John Russell wrote:
>
> Thanks m,  This appears to be exactly what I was looking for.  The 
> "smartHUB" is the bridge you're referring to, correct? Do you have any 
> hand-on experience with their equipment, especially with regards to 
> integration with weeWX? I'll do some searches to see what I can find, but 
> it's definitely a modular approach and their range of sensors looks to be 
> good!
>

i've been using acurite hardware at 3 different locations since 2013 (i 
think the first acurite usb driver was released dec 2013, and i think the 
bridge/smarthub driver came out summer of 2014)

the acurite consoles are horrible wrt comms - there are firmware bugs, they 
revert to usb mode 2 (no comms) after power cycle, and we had to do a lot 
of hacking to ensure that we could get good data from them.  but they are 
quite nice from a display point of view - the ticker is lame, but the rest 
of the display is better than most low-end weather stations.

(te923 have the most readable display, imho.  but i would avoid all 
consoles and just use an android tablet - that way you get not just 
easy-to-read, but also information display that beats *any* weather station)

the bridge performs flawlessly.  if you are loath to give away your data, 
you can prevent it from sending data to acurite by using your own dns on 
your lan.  you can run weewx-interceptor in either sniff or listen mode, 
depending on your network configuration and skills.

the sensors seem to be pretty solid - they track pretty closely with those 
from other vendors.

the lightning sensors were pretty flaky in the first batches, but they seem 
to be better now.  but you'll need an sdr dongle to capture lightning data 
(the bridge does not understand output from the lightning sensors).

i would avoid netatmo - they actively prevent you from getting your own 
data unless you go through their servers.

weatherflow is a much better option if you want to go with a netatmo 
equivalent.

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.

[weewx-user] Re: Newbie looking for hardware suggestions.

[John Russell]

Thanks m,  This appears to be exactly what I was looking for.  The 
"smartHUB" is the bridge you're referring to, correct? Do you have any 
hand-on experience with their equipment, especially with regards to 
integration with weeWX? I'll do some searches to see what I can find, but 
it's definitely a modular approach and their range of sensors looks to be 
good!

John


On Monday, December 11, 2017 at 8:13:38 PM UTC-5, mwall wrote:
>
> john,
>
> acurite might be in your budget.
>
> a bridge plus 3 t/h sensors goes for about 100$US, a 5-in-1 sensor cluster 
> goes for about $80.  those are retail prices - you can often get package 
> deals that bring those prices lower.  acurite also has standalone rain 
> gauges, refrigerator/freezer sensors, water probes, and lightning sensors.
>
> don't bother with their consoles for data collection - it is much more 
> reliable to get data from the bridge, and the bridge can talk to any number 
> of sensors.  get a console only if you want a standalone display.
>
> install weewx with the weewx-interceptor driver, make the bridge send data 
> to weewx, and bob's your uncle!
>
> m
>

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

Re: [weewx-user] Re: weewx-owfs failure with new Raspbian Stretch

[mwall]

btw, you can download the code for owfs software (not the weewx-owfs 
driver/service) from sourceforge:

http://owfs.org/


-- 
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-owfs failure with new Raspbian Stretch

[mwall]

miguel,

to install owfs on debian systems do:

sudo apt-get install python-ow

to see what is installed, do:

dpkg --list | grep ow

these systems are working properly for me:

Debian GNU/Linux 7

Linux 3.2.0-4-amd64 #1 SMP Debian 3.2.89-2 x86_64 GNU/Linux

owfs 2.8p15-1

owfs-common  2.8p15-1

python-ow2.8p15-1


Debian GNU/Linux 6.0

Linux 2.6.34.9 #1 PREEMPT Thu Jun 23 10:15:49 PHT 2011 armv5tel GNU/Linux

owfs-2.9p5 (compiled from source)


i compiled owfs-2.9p5 using these options:

./configure --prefix=/opt/owfs-2.9p5 --disable-owhttpd --disable-owftpd --di

sable-owserver --disable-owperl --disable-owphp --disable-owtcl 
--disable-i2c --

disable-w1 --disable-parport --disable-owcapi --disable-owmon 
--disable-owtap --

disable-owshell --disable-owexternal --disable-debug --disable-ownet 
--disable-o

wnetlib --enable-owpython --enable-usb


-- 
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-owfs failure with new Raspbian Stretch

[mixpc75]

Howard, I cannot prove your theory but can add my tests and inn my case
usb-devices shows

2.0 root hub
SMC9512/9514 USB Hub
SMSC9512/9514 Fast Ethernet Adapter
which is just the Raspberry Pi. So no trace of DS18B20.

pi@raspberrypi:~ $ tail /var/log/syslog
Dec 12 18:12:13 raspberrypi weewx[573]: Stopping weewx weather system:
weewx not running
Dec 12 18:12:13 raspberrypi systemd[1]: Stopped LSB: weewx weather system.
Dec 12 18:12:40 raspberrypi OWFS[594]: DEFAULT: owlib.c:(208) Cannot open
USB bus master
Dec 12 18:12:40 raspberrypi OWFS[594]: DEFAULT: owlib.c:(52) No valid
1-wire buses found
Dec 12 18:13:18 raspberrypi OWFS[603]: DEFAULT: owlib.c:(52) No valid
1-wire buses found
Dec 12 18:14:51 raspberrypi OWFS[630]: DEFAULT: owlib.c:(52) No valid
1-wire buses found
Dec 12 18:15:14 raspberrypi OWFS[639]: DEFAULT: owlib.c:(208) Cannot open
USB bus master
Dec 12 18:15:14 raspberrypi OWFS[639]: DEFAULT: owlib.c:(52) No valid
1-wire buses found


Matthew, in my case:
weewx-owfs-0.21.tgz

OS version
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/";
SUPPORT_URL="http://www.raspbian.org/RaspbianForums";
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs";

If you could provide with the owfs source (I am more of Debian newbie) I
could try to compile, run tests and share output.

Regards,


On 12 December 2017 at 18:21, mwall  wrote:

> howard,
>
> you're on the right track.  enumerate the owfs and operating system
> versions that each of you is using.  i assume you are all using the latest
> weewx-owfs (v0.21 as of 12dec2017).
>
> the weewx-owfs extension (driver and service) depends on the owfs
> libraries.
>
> if you are lucky, you can install owfs using apt or yum.
>
> i had to compile owfs on some arm systems, since the owfs that shipped
> with them was too old or was broken.
>
> you can easily build owfs without messing up your system.  download the
> owfs source, then build it like this:
>
> ./configure --prefix=/opt/owfs-x.y ...
> make
> make install
>
> for a complete list of the options to configure that matter, see the end
> of the owfs wiki page
>
>   https://github.com/weewx/weewx/wiki/owfs
>
> most of the stuff in owfs is not needed by the weewx-owfs driver/service,
> so i always disable it.
>
> to use your compiled version of owfs instead of whatever the system
> provides, put it in the path.  for example:
>
> LD_LIBRARY_PATH=/opt/owfs-x.y PYTHONPATH=/home/weewx/bin python
> /home/weewx/bin/user/owfs.py --sensors
>
> when you get that to work, put the LD_LIBRARY_PATH into the weewx rc
> script or whatever you use to run weewx as a daemon.
>
> 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.
>

-- 
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-owfs failure with new Raspbian Stretch

[mwall]

howard,

you're on the right track.  enumerate the owfs and operating system 
versions that each of you is using.  i assume you are all using the latest 
weewx-owfs (v0.21 as of 12dec2017).

the weewx-owfs extension (driver and service) depends on the owfs libraries.

if you are lucky, you can install owfs using apt or yum.

i had to compile owfs on some arm systems, since the owfs that shipped with 
them was too old or was broken.

you can easily build owfs without messing up your system.  download the 
owfs source, then build it like this:

./configure --prefix=/opt/owfs-x.y ...
make
make install

for a complete list of the options to configure that matter, see the end of 
the owfs wiki page 

  https://github.com/weewx/weewx/wiki/owfs

most of the stuff in owfs is not needed by the weewx-owfs driver/service, 
so i always disable it.

to use your compiled version of owfs instead of whatever the system 
provides, put it in the path.  for example:

LD_LIBRARY_PATH=/opt/owfs-x.y PYTHONPATH=/home/weewx/bin python 
/home/weewx/bin/user/owfs.py --sensors

when you get that to work, put the LD_LIBRARY_PATH into the weewx rc script 
or whatever you use to run weewx as a daemon.

m

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

Re: [weewx-user] Re: weewx-owfs failure with new Raspbian Stretch

[Howard Walter]

Glenn,

Are you running on a Wheezy based Raspbian or a Stretch based Raspian? If 
it is Stretch, which Raspbian distribution did you use?

To summarize:
I have a fully functioning 1-wire weewx using Matt's owfs running on Wheezy 
Raspbian. The problem occurs when installing weewx-owfs on the new Stretch 
based Raspbian.

I started with Matt's owfs.py and get the error messages shown in my first 
post.The additional 1-wire messages in syslog are shown on Wheezy but not 
on Stretch.

The test program is a (very!) short version of owfs.py and, by running it 
as root, I was hoping to bypass any udev issues just as you did when you 
ran Matt's program as root.

I installed owfs in the unlikely event that Stretch required something else 
in the owfs package. It is not installed when I run weewx.

usb-devices shows
T:  Bus=01 Lev=02 Prnt=02 Port=03 Cnt=03 Dev#= 10 Spd=12  MxCh= 0
D:  Ver= 1.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS= 8 #Cfgs=  1
P:  Vendor=04fa ProdID=2490 Rev=00.02
C:  #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)

So it looks like it can't find the 1-wire driver.
My current theory is that owlib.c which is imported (I think) by python-ow 
is broken on Stretch.

-- 
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] --reading failure in weewx_3.8.0-1 and weewx-owfs-0.21 Raspberry Pi & DS18B20

[mixpc75]

Hello,

Thank you for your message. Appreciated indeed. Well, then as the sensor is
connected to the Raspberry Pi GPIO pins, there should be a script that
reads temperature values and passes them to weewx, as far as I can imagine.

I have found a message by weewx-user group user Horacio who has coded that
script and gives instructions on how to implement it:
"How to add a ds18b20 thermometer to raspberry pi and weewx"
https://groups.google.com/d/msg/weewx-user/n1BbF3FAKh8/XxdPovR3AgAJ

As you can see he is using the OWFSS approach and adding a ds18b20.py
script to
/usr/share/weewx/user

What I do not know is how to implement the [OWFS] section in weewx.conf as
there is no such information in his post and again, do not know what should
be placed in interface.

In Python the way to get those readings has to do with

os.system('modprobe w1-gpio')
os.system('modprobe w1-therm')

but I have not any clue about a value for interface = in this particular
setting.

Wish I could provide more info, I do the best I can.

Regards,




On 12 December 2017 at 14:10, mwall  wrote:

> miguel,
>
> i suspect that your problem is the interface.
>
> if you are using a 1wire-to-usb adapter such as the DS9490R, then the
> interface is 'u'.  if you are running one-wire server software, then the
> interface is 'hostname:port'.  if you are using 1wire-to-serial,
> 1wire-to-i2c, or some other physical interface, then interface will be the
> device spec for that physical interface, such as /dev/ttyS0 or perhaps
> /dev/i2c (i am not sure how i2c devices are enumerated, and i'm pretty sure
> they are enumerated differently for arm vs x86 architectures, and i know
> they are enumerated differently for different operating systems).
>
> 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.
>

-- 
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: FineOffset Hang ups

[Andrew Milner]

1. Do not use the rpi usb port directly, use a powered hub to power the 
station (but I also keep batteries in the station)- even if you cannot 
switch the port on and off
2. Ensure the usb cable to the station goes nowehere near power supplies or 
screens - route it carefully away from all sources of possible interference.
3. Consider magnetic rings for the usb lead - again to reduce interference 
issues

Following the above 'rules' my Fine Offset very rarely 'locks up', and in 
fact I cannot remember when I last had a problem - so have never needed to 
use the powered hub reset method.

It seems to me that one is better solving the cause, or minimising the 
chances of lock up occurring, rather than focussing on recovery methods.



On Tuesday, 12 December 2017 14:31:42 UTC+2, Redanman wrote:

> Yes, I did look at the Wiki on FineOffset lock-ups, but as I mentioned in 
> post I do not have a powered hub.  A solution for me seems to be intimated 
> in the latter part of the post with a dedicated scripted to look at the 
> syslog file and react to the specific message related to USB hang-ups.  The 
> Pi shuts downs in a coordinated fashion and then a 555 watchdog restarts 
> the Pi.  That would work for me although I would prefer to just do "sudo 
> reboot" rather than mess with a 555 circuit.  I was hoping for some more 
> details on this solution.
>
> On Tuesday, 12 December 2017 08:58:16 UTC, Thorsten Wöll wrote:
>>
>> Take a close look here:
>>
>> https://github.com/weewx/weewx/wiki/FineOffset-USB-lockup
>>
>> Am Montag, 11. Dezember 2017 23:54:03 UTC+1 schrieb Redanman:
>>>
>>> My old WH1080 is getting more more and more USB hang-ups.  I have to 
>>> reset the unit (remove the USB cable) to reboot the it.  I obviously lose 
>>> the data in the circular buffer, so, depending on when I notice the 
>>> hang-up, it leads to data loss of several hours or even days.
>>> I power the WH1080 through the USB cable connected to my Pi, but I do 
>>> not have a USB hub, so cannot cycle the power through the hub.  I have 
>>> noticed that if I reboot the Pi it cycles the power on the Pi's own USB 
>>> ports, so resetting the WH1080.  Is it possible to do this automatically 
>>> within Weewx if it detects a USB hang-up?
>>> Mike
>>
>>

-- 
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] --reading failure in weewx_3.8.0-1 and weewx-owfs-0.21 Raspberry Pi & DS18B20

[mwall]

miguel,

i suspect that your problem is the interface.

if you are using a 1wire-to-usb adapter such as the DS9490R, then the 
interface is 'u'.  if you are running one-wire server software, then the 
interface is 'hostname:port'.  if you are using 1wire-to-serial, 
1wire-to-i2c, or some other physical interface, then interface will be the 
device spec for that physical interface, such as /dev/ttyS0 or perhaps 
/dev/i2c (i am not sure how i2c devices are enumerated, and i'm pretty sure 
they are enumerated differently for arm vs x86 architectures, and i know 
they are enumerated differently for different operating systems).

m

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

Re: [weewx-user] --reading failure in weewx_3.8.0-1 and weewx-owfs-0.21 Raspberry Pi & DS18B20

[mixpc75]

Dear Glenn,

Thank you for your feedback and support. In order to do it clean I have
done it again from scratch so...

raspbian stretch minimal image file copied to SD card
sudo raspi-config (to enable 1-Wire)
wget -qO - http://weewx.com/keys.html | sudo apt-key add -
wget -qO - http://weewx.com/apt/weewx.list | sudo tee
/etc/apt/sources.list.d/weewx.list
sudo apt-get update
sudo apt-get install weewx
and choose Simulator as default station

To check weewx status I run
sudo systemctl status weewx.service
and it is active so...
sudo systemctl stop weewx.service
now
sudo systemctl status weewx.service
shows inactive

and then the steps in https://github.com/weewx/weewx/wiki/owfs
that is...
wget
http://lancet.mit.edu/mwall/projects/weather/releases/weewx-owfs-0.21.tgz
sudo apt-get install python-ow
sudo wee_extension --install weewx-owfs-0.21.tgz
sudo reboot

sudo systemctl status weewx.service
is active so...
sudo systemctl stop weewx.service
as you well note 1-wire bus can be accessed from one process at a time.

PYTHONPATH=/usr/share/weewx python /usr/share/weewx/user/owfs.py --sensors
gives the usual error:
Traceback (most recent call last):
  File "/usr/share/weewx/user/owfs.py", line 618, in 
main()
  File "/usr/share/weewx/user/owfs.py", line 578, in main
ow.init(iface)
  File "/usr/lib/python2.7/dist-packages/ow/__init__.py", line 224, in init
raise exNoController
ow.exNoController

However adding sudo results in a different message:
PYTHONPATH=/usr/share/weewx sudo python /usr/share/weewx/user/owfs.py
--sensors
Traceback (most recent call last):
  File "/usr/share/weewx/user/owfs.py", line 168, in 
import weewx
ImportError: No module named weewx

So this time I have done as follows:
sudo nano /etc/weewx/weewx.conf
station_type = Simulator
to
station_type = OWFS

and
[OWFS]
interface = u
driver = user.owfs
[[sensor_type]]
[[sensor_map]]
to
[OWFS]
interface = localhost:4304
driver = user.owfs
[[sensor_type]]
[[sensor_map]]

Truth is I just want the DS18B20 sensor readings (pins to GPIO physical
pins 1 (power), 6 (gnd) and 7 (GPIO4) to be output by whichever interface
it has to be.

No changes to sensor type as I expect --sensors to output the true valid
value for that DS18B20.

PYTHONPATH=/usr/share/weewx python /usr/share/weewx/user/owfs.py --sensors
PYTHONPATH=/usr/share/weewx sudo python /usr/share/weewx/user/owfs.py
--sensors
PYTHONPATH=/usr/share/weewx python /usr/share/weewx/user/owfs.py --iface
localhost:4304 --sensors
PYTHONPATH=/usr/share/weewx sudo python /usr/share/weewx/user/owfs.py
--iface localhost:4304 --sensors
result in the same respective errors as indicated above

pi@raspberrypi:~ $ tail /var/log/syslog
Dec 12 12:57:42 raspberrypi systemd[1]: Reached target Multi-User System.
Dec 12 12:57:42 raspberrypi systemd[1]: Reached target Graphical Interface.
Dec 12 12:57:43 raspberrypi systemd[1]: Starting Update UTMP about System
Runlevel Changes...
Dec 12 12:57:43 raspberrypi systemd[1]: Started Update UTMP about System
Runlevel Changes.
Dec 12 12:57:43 raspberrypi systemd[1]: Startup finished in 2.942s (kernel)
+ 1min 31.756s (userspace) = 1min 34.698s.
Dec 12 12:59:08 raspberrypi OWFS[487]: DEFAULT: owlib.c:(208) Cannot open
USB bus master
Dec 12 12:59:08 raspberrypi OWFS[487]: DEFAULT: owlib.c:(52) No valid
1-wire buses found
Dec 12 13:02:50 raspberrypi OWFS[501]: DEFAULT: owlib.c:(52) No valid
1-wire buses found
Dec 12 13:07:53 raspberrypi OWFS[535]: DEFAULT: owlib.c:(208) Cannot open
USB bus master
Dec 12 13:07:53 raspberrypi OWFS[535]: DEFAULT: owlib.c:(52) No valid
1-wire buses found

I realize I have not installed the webserver so...
sudo apt-get install lighttpd
sudo reboot

Just to check weewx status I run
pi@raspberrypi:~ $ sudo systemctl status weewx.service
● weewx.service - LSB: weewx weather system
   Loaded: loaded (/etc/init.d/weewx; generated; vendor preset: enabled)
   Active: active (exited) since Tue 2017-12-12 13:20:34 CET; 1min 53s ago
 Docs: man:systemd-sysv-generator(8)
  Process: 249 ExecStart=/etc/init.d/weewx start (code=exited,
status=0/SUCCESS)
   CGroup: /system.slice/weewx.service

Dec 12 13:20:34 raspberrypi weewx[349]: owfs: driver version is 0.21
Dec 12 13:20:34 raspberrypi weewx[349]: owfs: interface is localhost:4304
Dec 12 13:20:34 raspberrypi weewx[349]: owfs: sensor map is {}
Dec 12 13:20:34 raspberrypi weewx[349]: owfs: sensor type map is {}
Dec 12 13:20:34 raspberrypi weewx[349]: owfs: polling interval is 10
Dec 12 13:20:34 raspberrypi weewx[349]: owfs: sensor unit system is metric
Dec 12 13:20:39 raspberrypi OWFS[349]: DEFAULT: owlib.c:(52) No valid
1-wire buses found
Dec 12 13:20:39 raspberrypi OWFS[349]: import of driver failed:  ()
Dec 12 13:20:39 raspberrypi OWFS[349]: engine: Unable to load driver:
Dec 12 13:20:39 raspberrypi OWFS[349]:   Exiting...

So there it is, the same error. So it seems now there is no way to get the
--sensors value... I have attached a link to the three confi

[weewx-user] Re: FineOffset Hang ups

[Redanman]

Yes, I did look at the Wiki on FineOffset lock-ups, but as I mentioned in 
post I do not have a powered hub.  A solution for me seems to be intimated 
in the latter part of the post with a dedicated scripted to look at the 
syslog file and react to the specific message related to USB hang-ups.  The 
Pi shuts downs in a coordinated fashion and then a 555 watchdog restarts 
the Pi.  That would work for me although I would prefer to just do "sudo 
reboot" rather than mess with a 555 circuit.  I was hoping for some more 
details on this solution.

On Tuesday, 12 December 2017 08:58:16 UTC, Thorsten Wöll wrote:
>
> Take a close look here:
>
> https://github.com/weewx/weewx/wiki/FineOffset-USB-lockup
>
> Am Montag, 11. Dezember 2017 23:54:03 UTC+1 schrieb Redanman:
>>
>> My old WH1080 is getting more more and more USB hang-ups.  I have to 
>> reset the unit (remove the USB cable) to reboot the it.  I obviously lose 
>> the data in the circular buffer, so, depending on when I notice the 
>> hang-up, it leads to data loss of several hours or even days.
>> I power the WH1080 through the USB cable connected to my Pi, but I do not 
>> have a USB hub, so cannot cycle the power through the hub.  I have noticed 
>> that if I reboot the Pi it cycles the power on the Pi's own USB ports, so 
>> resetting the WH1080.  Is it possible to do this automatically within Weewx 
>> if it detects a USB hang-up?
>> Mike
>
>

-- 
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: FineOffset Hang ups

['Thorsten Wöll' via weewx-user]

Take a close look here:

https://github.com/weewx/weewx/wiki/FineOffset-USB-lockup

Am Montag, 11. Dezember 2017 23:54:03 UTC+1 schrieb Redanman:
>
> My old WH1080 is getting more more and more USB hang-ups.  I have to reset 
> the unit (remove the USB cable) to reboot the it.  I obviously lose the 
> data in the circular buffer, so, depending on when I notice the hang-up, it 
> leads to data loss of several hours or even days.
> I power the WH1080 through the USB cable connected to my Pi, but I do not 
> have a USB hub, so cannot cycle the power through the hub.  I have noticed 
> that if I reboot the Pi it cycles the power on the Pi's own USB ports, so 
> resetting the WH1080.  Is it possible to do this automatically within Weewx 
> if it detects a USB hang-up?
> Mike

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