Thanks again to both, this got me an idea about how things are working! I was asking about testing because my Station/Driver does not provide any "extra-fields" which are not saved, just fields included in the schema. I should have said that I am the Dave from the weewx-wdc Skin, whom John mentioned earlier, so I wanted to test this out when implementing it into the skin.
I had a quick look at the Simulator driver provided by WeeWX. Looks like it could be easily modified to emit some extra fields for testing. Rainer Lang schrieb am Mittwoch, 28. Juni 2023 um 11:00:49 UTC+2: > "Where is this data actually stored if not in the database? Is there any > way to test this out, besides actually using the said driver?" > > The data is not stored on a medium (e.g. disk) but just kept in memory > during the runtime of the program - and even there > only as long as the program logic allows. > > Maybe the use of other terms will make it clearer if you are not familiar > with the Python programming language and its jargon. > A dictionary in Python is a defined (potentially complex) data structure > of the same or different data types. > These structures have different names in different programming languages. > They exist during the runtime of the program and are used > to store data during runtime and also use this data during runtime. In > older programming languages like COBOL they were just a so-called > record, a structured description of a memory area (like a line in a > spreadsheet with different columns). > On a low level they are (from the point of view of the computer program > structured) > areas in memory which can be accessed and manipulated by the program code. > > If you want to do testing here, whatever are your ideas here and whatever > you want to do and for what purpose, you would have to create your > own Python code which does what you want to do (your "testing"). > If you want to see the definition of these structures (Python > dictionaries), > you will have to find the place where they are defined in the weewx > coding. > As Python is an interpreter language, the program code is available on > your computer. > > I'm not exactly clear on what you want to "test" here and what for ... > - certain observations are stored or not stored, depending on what you > want and define (e.g. in weewx.conf) > you want some observation to be stored, do it via the one of the two > approaches mentioned earlier, > some are predefined by the database schema used, for others this would > need to be defined > - you can also define what type of accumulation of this data you want > (also in weewx.conf) > - when displaying the data you can also define (in skin.conf) what type of > depiction your want > > so much for the technical aspect - storing or not storing (storing here in > the sense of archiving into a database) > > as for the functional/logical aspect, you have to be clear on what the > information you want to archive means > like in the example of the Ecowitt sensor "signal" observation which is an > indicator of successfully received and processed data packages > i.e. rather a signal quality indicator but not a signal strength > indicator. Even though on an Ecowitt console or app you can see "reception > bars", > they cannot be compared to the signal reception bars of your mobile phone > (where they are an indicator of signal strength). > > If you want to enter more deeply into how Ecowitt consoles and sensors > work, I recommend to read the (whole !) wxforum.net thread > https://www.wxforum.net/index.php?topic=40730.0 > In the field of battery and signal values there is unfortunately > (historically grown) not a consistent logic, especially with the batteries. > You have to know which values each sensor provides and what they mean > > weewx is only using the output from these consoles through whichever > driver you are using to do so (Ecowitt Gateway, Interceptor, RTL433). > It's up to you to make sense of it and what you choose to depict and how > to depict. > > > > > On 28.06.2023 01:19, David Bätge wrote: > > Hi Rainer and Gary, > > thank you both very much for the detailed explanation! I was not aware > that the $current tag also provides access to ALL observations of the > current record, regardless if they are archived or not. > > Is the $current tag the only tag that provides this access? I assume the > $latest tag also does? > > The $span tag would not be able to get values from those fields, since > it's an aggregate, right? Just asking because I have added a check for > displaying the battery states, like eg. #if $getattr($span($day_delta=1, > boundary='midnight'), 'wh31_ch1_batt').has_data which does not really > make sense after understanding the internals, it should test against > $current. > > *[...] weewx includes values from the database and the current values of > all observations in the current values table, also from those which have > not been archived but are still available in memory from what has been > provided from the driver [...]* > Where is this data actually stored if not in the database? Is there any > way to test this out, besides actually using the said driver? > > Sorry for a load of questions, please point me to the right documentation > if I missed something in the guides. Thanks in advance and thanks again for > enlighten me about this :) > gjr80 schrieb am Dienstag, 27. Juni 2023 um 18:21:54 UTC+2: > >> David, >> >> Some answers/comments below. >> >> On Tuesday, 27 June 2023 at 01:16:51 UTC+1 david....@gmail.com wrote: >> >> >> Signal level observations: All *_sig observations like, wh31_ch1_sig, >> wh31_ch2_sig, wh32_sig. I don't understand these: What is the signal >> level here? Values seem to be `0` or `4` in that LOOP packet (looks like >> battery state fields?). >> >> >> Ecowitt gateway signal levels are a pseudo-signal levels at best; the >> number represents the number of the last four data packets from the sensor >> that were successfully received/decoded. So most of the time, if the >> sensors have a reliable connection to the gateway device, you will see a 4, >> on startup you will see 0 and it will ramp up to 4 if all sensors connect >> successfully and reliably. The number bears no reference to the sensor >> signal level received by the gateway device or emitted by the sensor. >> >> >> So the problem with all these observations is basically (as far as I >> understand, please correct me if I am wrong): WeeWX does not know about >> them and does not save them to the database (but you will need this data to >> show plots of the battery voltages for the last week for example). There >> should be two ways to overcome this: >> >> 1. Add the fields provided by the GW1000 driver to the database, see >> http://weewx.com/docs/latest/customizing.htm#Modifying_an_existing_database >> 2. Map the GW1000 fields to WeeWX schema fields (see >> https://github.com/weewx/weewx/blob/master/bin/schemas/wview_extended.py#L16) >> >> I assume that was somehow done for a short period of time because e.g. >> rxCheckPercent or consBaterryVoltage are showing/having data for a few >> days!?) >> >> @Gary I don't quite understand what you have written about that: >> >> *It is not necessary to do so if only displaying current values (ie >> values from the current archive record)* >> >> >> A quick and simplified WeeWX data flow 101. A WeeWX driver gathers data >> from a station/sensors and emits loop packets on a regular and frequent >> basis. WeeWX accumulates these loop packets and at the end of an archive >> period WeeWX synthesises an archive record from the accumulated loop >> packets, this record is known as the current archive record. WeeWX saves >> the current archive record to database, but only those fields that are >> common to the WeeWX database schema and the current archive record. WeeWX >> then generates reports. Note, there are usually a number of additional >> WeeWX services that 'do things' (eg quality control, calculate derived >> values etc) to the loop packets and archive records before they are >> accumulated/saved to database. >> >> When WeeWX generates reports all fields in the current archive record are >> available for use in WeeWX generated reports via the $current tag, >> irrespective of whether the field was saved to database or not. So if you >> wish to include only the current value of a field in a WeeWX report there >> is no need to save that field to the database, but if you wish to display >> any sort of historical data (eg an aggregate in a report or plot historical >> values) for a field you need to save the field to database. For example, >> generally folks want to display max/min values of outside temperature or >> plot outside temperature over some period so outTemp is usually saved to >> database. However, you may only wish to display the current signal level >> value for a given sensor using a $current tag so you may chose not to >> save the sensor signal level to database. >> >> So in terms of WeeWX 'knowing about a field' there are two things to >> consider. (1) does the WeeWX schema need to include this field, if it does >> this can be achieved by mapping to an already existing database field or >> adding a new field to the database schema (or a combination of both) and >> (2) do any enabled reports need to know about the field, this may entail a >> simple config change in a skin config file or modification/creation of a >> template. >> >> >> How would you show fields like wh41_ch1_batt from the current archive >> record when the data is not saved? Am I missing something? >> >> >> As outlined above, in such a case you can display the current >> wh41_ch1_batt value but will not be able to display any historical >> values or aggregates nor will you be able to plot wh41_ch1_batt. If you >> wish to display any historical values or aggregates or plot wh41_ch1_batt >> you >> need to add the field wh41_ch1_batt to the database or map field >> wh41_ch1_batt to an existing, unused database field. >> >> > -- > > 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/abf92ed8-282f-45f3-b367-c9ee084eee74n%40googlegroups.com > > <https://groups.google.com/d/msgid/weewx-user/abf92ed8-282f-45f3-b367-c9ee084eee74n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > > -- 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/6be6aa37-f5be-48c4-a1fc-f15694207a0fn%40googlegroups.com.
