[weewx-user] plot custom variable in select time frame using python matplotlib

[mihec]

Hi,
I would like to plot e.g. temperature and solar radiation from my sqlite3 
weewx's database file for the whole last year or just selected season. Is 
there a code example how to do that? The problem I have is actually to 
extract the data from the database file. The plotting part I can handle.
Alternatively, is there a way to convert the selected timeframe from the 
database to the .csv file?
Thank you.

-- 
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/1b611686-0f84-4215-b1c3-d77e71f26664n%40googlegroups.com.

Re: [weewx-user] Corrections for barometric pressure from TWI station

[pannetron]

I've left my local twi.py reporting what the station reports as 
"barometer".  I'm pretty sure the station actually reports a calculated 
"altimeter" from its pressure sensor.  To review, I calibrated my console 
to display local pressure adjusted to my altitude.  If I let the driver 
report values as "pressure" weewx reports crazy high calculated values for 
barometer and altimeter.When I change the twi.py -- or the simulator -- 
to report only "altimeter", I get nothing in the barometer and pressure 
archive records.  My weewx.conf is configure to expect "altimeter" from 
hardware and both barometer and pressure from software.  Where should I 
look to see why weewx is not calculating barometer and pressure from 
altimeter?  I'm fluent in python.  I'd prefer this approach to configuring 
the twi.py driver to insert the stations readings into "pressure" and then 
having to put a large negative offset in weewx,conf to "correct" the 
pressure value.  Does the calculation of barometer and pressure from 
altimeter require some time span of altimeter values?

On Monday, January 9, 2023 at 3:21:50 PM UTC-7 Jeff A. D. wrote:

> Barometer uses outdoor temperature for correction.  Indoor pressure for 
> all practical purposes is the same as outdoor pressure which is determined 
> by the weather.
>
> But again, if the algorithm is the same as for the original VP, then the 
> barometer corrections depending on temperature at high altitude are pretty 
> meaningless, at least to me.   Maybe you would get better readings using a 
> more consistent indoor reading, but that's not the way it's meant to work 
> and wouldn't give true barometer readings, for whatever they're worth.  
> Altimeter is far more meaningful in my opinion, and seems to be what 
> stations around here use.
>
> On Monday, January 9, 2023 at 2:44:36 PM UTC-7 pannetron wrote:
>
>> Good catch.  No, the station has no input for altitude.  And I was wrong 
>> about setting the tags in twi.py to "altitude" -- that caused issues with 
>> the Belchertown skin I use and the value reported to PWSWeather.  I changed 
>> the tags to "barometer" and things work okay now but I'm left unsure what 
>> errors that may introduce into calculated station pressure and altitude 
>> pressure values.  That's something I can live with.  Seems only a few folks 
>> use a TWI station so maybe this is good enough as long as the hack is made 
>> known as a caveat? 
>>
>> I suspect the station displays and reports "gauge pressure."  I manually 
>> adjusted the station's barometer calibration for my altitude so the console 
>> display is meaningful for comparisons with other stations around me and 
>> agrees with my Kestrel 3000.  The values reported to CWOP compare very 
>> well with neighboring stations.  Some day I may play with setting the tags 
>> in twi.py back to "pressure" and, as others suggested, use a calibration 
>> calculation in weewx.conf to get back to true "gauge pressure".  
>>
>> One of my questions remains unanswered: since the barometric sensor is 
>> indoors, should SLP adjustments for temperature use indoor or outdoor 
>> temperature?
>>
>> BTW, Tom, thanks so much for your replies and work on weeWX!!!
>>
>> Russ
>>
>> On Mon, Jan 9, 2023 at 12:55 PM Tom Keffer  wrote:
>>
>>> Sounds good.
>>>
>>> Just a reality check: if your instrument emits altimeter pressure, then 
>>> there must be a way of setting altitude in the instrument. Hope that's true.
>>>
>>> On Mon, Jan 9, 2023 at 7:23 AM pannetron  wrote:
>>>
 Update on a revised twi.py.  Changing the genLoopPacket "tags" from 
 "pressure" to "altimeter"  from values parsed  from the station reports 
 did 
 the trick.  After some previous changes from strings to binary strings, 
 there was a bug with how wind_dir values were parsed so I fixed that, too. 
  
 After a few more days of testing, I'll submit a PR.

 On Sunday, January 8, 2023 at 10:45:43 AM UTC-7 pannetron wrote:

> On Sun, Jan 8, 2023 at 4:51 AM Tom Keffer  wrote:
>
>> It sounds like the TWI instrument is emitting "altimeter" or 
>> "barometer", but the driver is labelling it "pressure" (i.e., gauge 
>> pressure). So, weewx feels the need to "correct" it to SLP, resulting in 
>> your enormous pressures.
>>
>> I would recommend filing an issue at the TWI repository 
>> . Expect it to take a 
>> while. Matthew is swamped.
>>
>> Or, better yet, do a fork and submit a PR.
>>
>> Cloned weewx-twi, working on a revised driver.  The current driver is 
> populating loop packets with "pressure" while the station reports 
> "altitude"... 
>
 -- 
 You received this message because you are subscribed to the Google 
 Groups "weewx-user" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to weewx-user+...@googlegroups.com.
 To view this discussion on

Re: [weewx-user] plot custom variable in select time frame using python matplotlib

[Tom Keffer]

WeeWX does not use matplotlib.

You would have to extract the data from the database, then use it. The
command-line tool "sqlite3 " can emit CSV
files.

On Thu, Jan 19, 2023 at 9:15 AM mihec  wrote:

> Hi,
> I would like to plot e.g. temperature and solar radiation from my sqlite3
> weewx's database file for the whole last year or just selected season. Is
> there a code example how to do that? The problem I have is actually to
> extract the data from the database file. The plotting part I can handle.
> Alternatively, is there a way to convert the selected timeframe from the
> database to the .csv file?
> Thank you.
>
> --
> 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/1b611686-0f84-4215-b1c3-d77e71f26664n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/CAPq0zECMtmP5FJS-SPD1mEVc11qU1Se-Q-8aA3SMD%3DGFAvqsyA%40mail.gmail.com.

Re: [weewx-user] plot custom variable in select time frame using python matplotlib

[mihec]

Thanks, I'll have a look how to do that.

četrtek, 19. januar 2023 ob 20:25:16 UTC+1 je oseba tke...@gmail.com 
napisala:

> WeeWX does not use matplotlib.
>
> You would have to extract the data from the database, then use it. The 
> command-line tool "sqlite3 " can emit CSV 
> files.
>
> On Thu, Jan 19, 2023 at 9:15 AM mihec  wrote:
>
>> Hi,
>> I would like to plot e.g. temperature and solar radiation from my sqlite3 
>> weewx's database file for the whole last year or just selected season. Is 
>> there a code example how to do that? The problem I have is actually to 
>> extract the data from the database file. The plotting part I can handle.
>> Alternatively, is there a way to convert the selected timeframe from the 
>> database to the .csv file?
>> Thank you.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx-user+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/1b611686-0f84-4215-b1c3-d77e71f26664n%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/a24a0454-a39c-4d0f-8dbe-eb6f0026d4f3n%40googlegroups.com.

[weewx-user] new river level monitor

[Graham Eddy]

i posted some time ago about my trusty old river level monitor. i am still 
receiving occasional enquiries about it - yes, unfortunately that product i 
used is no longer available. whilst it is still working for me, i have now 
deployed a new river level monitor in parallel, some details below

old river level monitor

Aquagauge provided a radio receiver with serial interface and a number of 
sensor types with radio transmitters. a receiver could support up to 8 
transmitters. the radio and serial protocols are proprietary

i wrote a weewx service that read the serial interface and inserted the data 
values into weewx packets. later i migrated this to a daemon that emitted the 
data as mqtt messages, and weewx reads the mqtt messages. this works fine; it 
is still in use

this river level sensor is pressure-based i.e. the probe sits on river bottom 
(in my case wrapped around a brick and tucked into a river bank nook) and 
measures the water pressure. there is a very inconvenient cable from the probe 
to the transmitter. the latter measures atmospheric pressure, the pressure 
difference is the weight of the water above the sensor thence deriving water 
depth. it proved to be quite accurate

the transmitter has suffered many travails, the latest being going for a swim 
during a flood when the bridge it was on was swept downstream. it is very 
robust but now failing more often and i fear one day soon not being able to 
rescusitate it → motivation for replacement. this product is no longer sold or 
supported

new river level sensor

i decided to try an ultrasound sensor i.e. the probe measures round-trip time 
for a signal reflected from river surface back to probe with known speed of 
signal. this means there is no cable needed to run into the river

my river level sensor must be a commercial off-the-shelf product, for which i 
am happy to write interface software. it also has to be wireless connection to 
RPi at least 50 meters away and be powered by long-life battery

i picked a Dragino LDDS75 Distance Detector 
(https://www.dragino.com/products/distance-level-sensor/item/161-ldds75.html). 
i mounted it under the sparkling new bridge i built over the river, higher than 
the old bridge. it sends quite large and complex messages via mqtt, so i wrote 
a daemon that plucks the salient data and re-publishes as simple message, 
imported into weewx. my daemon also configures a fix-point height for the 
sensor, so the simplified mqtt message includes a ‘level’ field as well as 
‘distance’ for easy digestion

this is a LoRaWAN device so provides the long distance and battery longevity i 
require

radio receiver server

the new river level sensor is the first of several sensors on my new open radio 
network, as opposed to the closed proprietary radio network per Aquagauge, so i 
need a radio transceiver to talk to them. i assume familiarity with LoRaWAN 
(https://www.thethingsnetwork.org/docs/lorawan/architecture/)

for the local LoWRaWAN gateway, i put a RAK 2245 LoRaWAN HAT 
(https://www.rakwireless.com/en-us/products/lpwan-gateways-and-concentrators/rak2245-pihat)
 on an RPi 4B and installed RAK’s gateway software from their GitHub

i tried using the chirpstack LoRaWAN stack running on local server but couldn’t 
get it to work reliably, it seemed to work only intermittently. i think i was 
having trouble with not picking up the radio packet preamble but, not being a 
radiohead, gave it up as too much like hard work. i tried The Things Network 
stack (https://www.thethingsindustries.com/docs/getting-started/ttn/) and, to 
paraphrase steve jobs, ‘it just worked’. i am using the ’community edition’, 
which is a subscribed but free service. the downside is that the network server 
and join server run on TTN’s hardware over the internet so i lose device 
connectivity when internet link is down. they provide the software to run your 
own copy of the stack, which i plan to do in future

so, the river level sensor emits radio packets, my RPi gateway receives the 
packets and sends to TTN stack, the TTN stack processes and emits them as 
complex mqtt messages, which my dameon picks up and simplifies, then weewx 
digests the simplified mqtt messages. (i have chosen to put LoRaWAN gateway on 
a separate RPi from the weewx RPi)

the TTN stack’s mqtt broker is on their remote server. i have chosen to bridge 
that mqtt broker to my RPi gateway so that, from my home network’s perspective, 
all that LoRaWAN stuff is happening on my RPi gateway. this fits my plan to 
move the TTN stack to the RPi gateway in future

the RAK 2245 includes an itty bitty antenna. i get a good signal and reliable 
connection at 100 meters, haven’t tested further distance. LoRa supports 10 km 
with a decent antenna

additional sensors

the LoRaWAN gateway supports a lot of LoRa devices simultaneously, it is just a 
case of joining them to the radio network and processing their dat

i have also deployed a river temperature sensor (replacing the VP2 wir

[weewx-user] 433Mhz Barometer?

[Glen Collins]

Hi everyone.  Does anyone know of a barometer that transmits on 433Mhz? I 
have one that transmits on 915Mhz but not to my liking. I'm interested in 
consolidating into one frequency to make my setup easier.

I've been searching searching and have yet to find one out of the US.

Thanks

Glen Collins


-- 
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/ab89ccd8-3f59-436c-ae9e-e5de0ca8b446n%40googlegroups.com.

Re: [weewx-user] Re: Trouble viewing new data column(s)

['Cameron D' via weewx-user]

I hope this is not a real example you are suggesting -  part_per_million  
would be a concentration, which already has an implied volume component 
according to whether it is in air, water etc.   A unit of  
 part_per_million_per_cubic_meter does not make any sense to me. 

On Wednesday, 18 January 2023 at 7:31:52 pm UTC+10 steep...@btinternet.com 
wrote:

> Gary,
> Follow up question from me in a similar vein. What is the correct way to 
> add a completely new measurement group to WeeWX, for example 
> part_per_million_per_cubic_meter?
> Ian
>
> Sent from my iPad.
>
> On 17 Jan 2023, at 05:20, gjr80  wrote:
>
> If you add a new observation to the database you need to tell WeeWX what 
> unit group it belongs to in order to be able to effectively use the 
> formatting and unit conversion capabilities of the WeeWX tag system in 
> reports. For example, if you add a field that is a pressure once WeeWX 
> knows the new field is a pressure WeeWX knows what default formatting to 
> apply, the correct unit label and you can use the formatting and unit 
> conversion aspects of the tag system to change the format/convert units in 
> a WeeWX report template. If WeeWX does not know what unit group the 
> observation belongs to you just get the raw value from the database (which 
> is typically a float with many decimal places - ie what you are seeing now).
>
>
> There are a number of ways to assign an observation to a unit group. In 
> your case the easiest approach is to add a few lines of code to 
> /home/weewx/bin/user/extensions.py (or /usr/share/weewx/user/extensions.py 
> if you installed WeeWX as a package). Try adding the following to the 
> bottom of extensions.py:
>
> import weewx.units
> weewx.units.obs_group_dict['waterTemp'] = 'group_temperature'
> weewx.units.obs_group_dict['tideHeight'] = 'group_length'
>
> (group_temperature was the obvious choice for waterTemp; tideHeight could 
> be group_length, group_altitude, group_rain or group_distance. The 
> deciding factor here is the available units for each group - if you look at 
> the Units  appendix to the 
> Customisation Guide you will see what I mean)
>
> You will need to restart WeeWX for the changes to take effect. The 
> extensions.py code is run at WeeWX startup and the above lines will make 
> the appropriate unit group assignments for your new fields. You should now 
> be able to use tags based on waterTemp and tideHeight in your reports. 
> You will find some further info on assigning unit groups in the Customising 
> units and unit groups 
>  section of the 
> Customisation Guide. You will also find information on the WeeWX tag system 
> in the Tags  section of the 
> Customisation Guide.
>
> A couple of notes about units.
>
> For the WeeWX tag system to correctly and consistently display observation 
> values and units you need to ensure the data you are adding to the database 
> is in the correct units. How you do this depends on how you are inserting 
> data into the database. If you are using a WeeWX service to augment loop 
> packets (the preferred approach) then your service needs to take cognisance 
> of the unit system (ie WeeWX field usUnits) of the loop packet being 
> augmented and add waterTemp and tideHeight to the loop packet using the 
> appropriate units for the unit group each observation belongs to for the 
> unit system used by the loop packet. For example, if the loop packet uses 
> US customary units (ie usUnits = 0) then waterTemp would need to be in 
> Fahrenheit and tideHeight in inches. Once you do this WeeWX takes care of 
> everything else. You will find information on the unit systems, unit groups 
> and units used by WeeWX in the Units 
>  appendix to the 
> Customisation Guide.
>
> If you are directly inserting data in the WeeWX database (not the 
> preferred approach) then it is up to you to ensure that the values are 
> inserted using units applicable to the database unit system and the unit 
> group used for each observation.
>
> Apologies for the long response but the WeeWX tag/unit/formatting system 
> has a lot of moving parts and you need to have them all correctly 
> configured or you will have problems.
>
> Gary
> On Tuesday, 17 January 2023 at 07:19:24 UTC+10 ja...@runser.net wrote:
>
>> Incremental progress. As described above but with the addition of a 
>> restart I have data in the statistics section but still N/A for Water Temp 
>> in "Current Conditions". Further, the data in statistics is formatted as 
>> "00.00" instead of the hoped-for "00.00  °F". I've walked through the 
>> template and inc files but still can't find the right building blocks. I 
>> even tried changing the waterTemp column from a double to a double(4,2) but 
>> am still getting all the extra zeros.
>>
>> On Monday, January 16, 2023 at