Re: [weewx-user] Changing signal names ("Members") in existing WeeWx database
Hallo, I used the rename-colum option of the wee_database utility and it worked fine. Thank you for the hint. I noticed one thing concerning case sensitivity. I wanted to rename "CO2" to "co2" but I got the following output: pi@WeatherDuinoPI:~ $ wee_database --rename-column=CO2 --to-name=co2 Using configuration file /etc/weewx/weewx.conf Using database binding 'wx_binding', which is bound to database 'archive_sqlite' Rename column 'CO2' to 'co2' (y/n)? y Traceback (most recent call last): File "/usr/share/weewx/weedb/sqlite.py", line 30, in guarded_fn return fn(*args, **kwargs) File "/usr/share/weewx/weedb/sqlite.py", line 219, in execute return sqlite3.Cursor.execute(self, *args, **kwargs) sqlite3.OperationalError: there is already another table or index with this name: archive_day_co2 Seems as there is a problem with case sensitivity, so I changed the name to "carbon" and then to "co2" as workaround. Regards, engolling engolling schrieb am Montag, 3. Mai 2021 um 20:55:01 UTC+2: > Thank you for your quick answer. I will give it a try. > > Do I have to make sure if the new_name does not exist already (as far as I > have seen in this is not the case for me) or would it be overridden? > > Regards, > engolling > > tke...@gmail.com schrieb am Montag, 3. Mai 2021 um 14:19:56 UTC+2: > >> As an alternative, if you are using WeeWX v4.5, you can just use the >> utility wee_database with the --rename-column >> <http://www.weewx.com/docs/utilities.htm#Action_--rename-column> option. >> >> *wee_database --rename-column=old_name --to-name=new_name* >> >> This has the advantage that it directly alters the database, so it is >> very fast. >> >> Make a backup first. >> >> On Mon, May 3, 2021 at 5:11 AM engolling wrote: >> >>> >>> Hello, >>> >>> I have an existing WeeWx Database with following signals I generated >>> myself: "Snow_Heigt", "AQM_PM10_0", etc... >>> With WeeWx 4 some of my signals were introduced as default and I would >>> like to moove my scheme to the default for compatibility reasons with skins >>> and so on. >>> >>> I would therefore just rename my "old" columns to the new default name >>> (and delete the default comlums if available". >>> Adjust my old schemes that it is compatible angain an then >>> >>>- *Reconfigure the Database: wee_database weewx.conf --reconfigure* >>>- *Rebuild the daily tables: wee_database weewx.conf --rebuild-daily* >>> >>> Do you think there is anythink else to take into account? I would like >>> to do it right the first time, since my Database has already 600MB it might >>> take a while ;) >>> >>> Regards, >>> engolling >>> >>> -- >>> 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/5ff06bd8-d3bd-459f-84aa-d3f65f1ab9bcn%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/weewx-user/5ff06bd8-d3bd-459f-84aa-d3f65f1ab9bcn%40googlegroups.com?utm_medium=email_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/ffa79226-5948-42e9-919b-e59c48ef58ffn%40googlegroups.com.
Re: [weewx-user] Changing signal names ("Members") in existing WeeWx database
Thank you for your quick answer. I will give it a try. Do I have to make sure if the new_name does not exist already (as far as I have seen in this is not the case for me) or would it be overridden? Regards, engolling tke...@gmail.com schrieb am Montag, 3. Mai 2021 um 14:19:56 UTC+2: > As an alternative, if you are using WeeWX v4.5, you can just use the > utility wee_database with the --rename-column > <http://www.weewx.com/docs/utilities.htm#Action_--rename-column> option. > > *wee_database --rename-column=old_name --to-name=new_name* > > This has the advantage that it directly alters the database, so it is very > fast. > > Make a backup first. > > On Mon, May 3, 2021 at 5:11 AM engolling wrote: > >> >> Hello, >> >> I have an existing WeeWx Database with following signals I generated >> myself: "Snow_Heigt", "AQM_PM10_0", etc... >> With WeeWx 4 some of my signals were introduced as default and I would >> like to moove my scheme to the default for compatibility reasons with skins >> and so on. >> >> I would therefore just rename my "old" columns to the new default name >> (and delete the default comlums if available". >> Adjust my old schemes that it is compatible angain an then >> >>- *Reconfigure the Database: wee_database weewx.conf --reconfigure* >>- *Rebuild the daily tables: wee_database weewx.conf --rebuild-daily* >> >> Do you think there is anythink else to take into account? I would like to >> do it right the first time, since my Database has already 600MB it might >> take a while ;) >> >> Regards, >> engolling >> >> -- >> 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/5ff06bd8-d3bd-459f-84aa-d3f65f1ab9bcn%40googlegroups.com >> >> <https://groups.google.com/d/msgid/weewx-user/5ff06bd8-d3bd-459f-84aa-d3f65f1ab9bcn%40googlegroups.com?utm_medium=email_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/5c1d8bea-38e4-4974-a732-61e1e3b2489dn%40googlegroups.com.
[weewx-user] Changing signal names ("Members") in existing WeeWx database
Hello, I have an existing WeeWx Database with following signals I generated myself: "Snow_Heigt", "AQM_PM10_0", etc... With WeeWx 4 some of my signals were introduced as default and I would like to moove my scheme to the default for compatibility reasons with skins and so on. I would therefore just rename my "old" columns to the new default name (and delete the default comlums if available". Adjust my old schemes that it is compatible angain an then - *Reconfigure the Database: wee_database weewx.conf --reconfigure* - *Rebuild the daily tables: wee_database weewx.conf --rebuild-daily* Do you think there is anythink else to take into account? I would like to do it right the first time, since my Database has already 600MB it might take a while ;) Regards, engolling -- 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/5ff06bd8-d3bd-459f-84aa-d3f65f1ab9bcn%40googlegroups.com.
Re: [weewx-user] No wind tag after transferring the database
Hallo, thank you for your quick reply and the outstanding support. Exactly this was my fault. Think I introduced it when playing with the database transfer. I wish you a happy new year. Best regards, engolling tke...@gmail.com schrieb am Donnerstag, 31. Dezember 2020 um 14:15:06 UTC+1: > I suspect you have a configuration problem for the new database. See if this > thread > <https://groups.google.com/g/weewx-user/c/sunTiSNUn6s/m/qaLVDckeBgAJ> > helps. > > On Thu, Dec 31, 2020 at 3:48 AM engolling wrote: > >> >> Hello, >> due to a hardware failure I lost my original weewx sqlite database. >> I had a backup with only the archive table but not the summaries on my >> SQL webserver. Which I copied back with wee_database ---transfer (according >> to the tutorial in the documentation). >> >> Everything seems to work despite that there are no wind tags anymore. >> I saw in the documentation that they should be build with the daily >> summary. >> http://www.weewx.com/docs/customizing.htm#Tags >> >> I tried wee_database --calc-missing --update and --rebuilid-daily without >> success. >> >> Dec 31 12:20:52 WeatherDuinoPI weewx[6736] INFO __main__: Initializing >> weewx version 4.2.0 >> Dec 31 12:20:52 WeatherDuinoPI weewx[6736] INFO __main__: Using Python >> 3.7.3 (default, Jul 25 2020, 13:03:44) #012[GCC 8.3.0] >> Dec 31 12:20:52 WeatherDuinoPI weewx[6736] INFO __main__: Platform >> Linux-5.4.79-v7l+-armv7l-with-debian-10.7 >> Dec 31 12:20:52 WeatherDuinoPI weewx[6736] INFO __main__: Locale is >> 'en_US.UTF-8' >> Dec 31 12:20:52 WeatherDuinoPI weewx[6736] INFO __main__: PID file is >> /var/run/weewx.pid >> Dec 31 12:20:52 WeatherDuinoPI weewx[6740] INFO __main__: Using >> configuration file /etc/weewx/weewx.conf >> Dec 31 12:20:52 WeatherDuinoPI weewx[6740] INFO __main__: Debug is 1 >> >> >> >> Dec 31 12:30:25 WeatherDuinoPI weewx[6740] ERROR weewx.reportengine: >> Caught unrecoverable exception in generator >> 'weewx.imagegenerator.ImageGenerator' >> Dec 31 12:30:25 WeatherDuinoPI weewx[6740] ERROR >> weewx.reportengine: no such table: archive_day_wind >> Dec 31 12:30:25 WeatherDuinoPI weewx[6740] ERROR >> weewx.reportengine: Traceback (most recent call last): >> Dec 31 12:30:25 WeatherDuinoPI weewx[6740] ERROR >> weewx.reportengine: File >> "/usr/share/weewx/weedb/sqlite.py", line 29, in guarded_fn >> Dec 31 12:30:25 WeatherDuinoPI weewx[6740] ERROR >> weewx.reportengine: return fn(*args, **kwargs) >> Dec 31 12:30:25 WeatherDuinoPI weewx[6740] ERROR >> weewx.reportengine: File >> "/usr/share/weewx/weedb/sqlite.py", line 211, in execute >> Dec 31 12:30:25 WeatherDuinoPI weewx[6740] ERROR >> weewx.reportengine: return sqlite3.Cursor.execute(self, >> *args, **kwargs) >> Dec 31 12:30:25 WeatherDuinoPI weewx[6740] ERROR >> weewx.reportengine: sqlite3.OperationalError: no such table: >> archive_day_wind >> Dec 31 12:30:25 WeatherDuinoPI weewx[6740] ERROR >> weewx.reportengine: **** >> Dec 31 12:30:25 WeatherDuinoPI weewx[6740] ERROR >> weewx.reportengine: During handling of the above exception, >> another exception occurred: >> Dec 31 12:30:25 WeatherDuinoPI weewx[6740] ERROR >> weewx.reportengine: >> >> Do you have an idea how I get the table archive_day_wind recalculated >> again? >> >> Regards, >> engolling >> >> -- >> 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/5ef65d01-89ac-48ab-878a-fdba6613f680n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/weewx-user/5ef65d01-89ac-48ab-878a-fdba6613f680n%40googlegroups.com?utm_medium=email_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/b236fee4-7b65-4a5a-97dd-b340a9c695d5n%40googlegroups.com.
[weewx-user] No wind tag after transferring the database
Hello, due to a hardware failure I lost my original weewx sqlite database. I had a backup with only the archive table but not the summaries on my SQL webserver. Which I copied back with wee_database ---transfer (according to the tutorial in the documentation). Everything seems to work despite that there are no wind tags anymore. I saw in the documentation that they should be build with the daily summary. http://www.weewx.com/docs/customizing.htm#Tags I tried wee_database --calc-missing --update and --rebuilid-daily without success. Dec 31 12:20:52 WeatherDuinoPI weewx[6736] INFO __main__: Initializing weewx version 4.2.0 Dec 31 12:20:52 WeatherDuinoPI weewx[6736] INFO __main__: Using Python 3.7.3 (default, Jul 25 2020, 13:03:44) #012[GCC 8.3.0] Dec 31 12:20:52 WeatherDuinoPI weewx[6736] INFO __main__: Platform Linux-5.4.79-v7l+-armv7l-with-debian-10.7 Dec 31 12:20:52 WeatherDuinoPI weewx[6736] INFO __main__: Locale is 'en_US.UTF-8' Dec 31 12:20:52 WeatherDuinoPI weewx[6736] INFO __main__: PID file is /var/run/weewx.pid Dec 31 12:20:52 WeatherDuinoPI weewx[6740] INFO __main__: Using configuration file /etc/weewx/weewx.conf Dec 31 12:20:52 WeatherDuinoPI weewx[6740] INFO __main__: Debug is 1 Dec 31 12:30:25 WeatherDuinoPI weewx[6740] ERROR weewx.reportengine: Caught unrecoverable exception in generator 'weewx.imagegenerator.ImageGenerator' Dec 31 12:30:25 WeatherDuinoPI weewx[6740] ERROR weewx.reportengine: no such table: archive_day_wind Dec 31 12:30:25 WeatherDuinoPI weewx[6740] ERROR weewx.reportengine: Traceback (most recent call last): Dec 31 12:30:25 WeatherDuinoPI weewx[6740] ERROR weewx.reportengine: File "/usr/share/weewx/weedb/sqlite.py", line 29, in guarded_fn Dec 31 12:30:25 WeatherDuinoPI weewx[6740] ERROR weewx.reportengine: return fn(*args, **kwargs) Dec 31 12:30:25 WeatherDuinoPI weewx[6740] ERROR weewx.reportengine: File "/usr/share/weewx/weedb/sqlite.py", line 211, in execute Dec 31 12:30:25 WeatherDuinoPI weewx[6740] ERROR weewx.reportengine: return sqlite3.Cursor.execute(self, *args, **kwargs) Dec 31 12:30:25 WeatherDuinoPI weewx[6740] ERROR weewx.reportengine: sqlite3.OperationalError: no such table: archive_day_wind Dec 31 12:30:25 WeatherDuinoPI weewx[6740] ERROR weewx.reportengine: Dec 31 12:30:25 WeatherDuinoPI weewx[6740] ERROR weewx.reportengine: During handling of the above exception, another exception occurred: Dec 31 12:30:25 WeatherDuinoPI weewx[6740] ERROR weewx.reportengine: Do you have an idea how I get the table archive_day_wind recalculated again? Regards, engolling -- 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/5ef65d01-89ac-48ab-878a-fdba6613f680n%40googlegroups.com.
Re: [weewx-user] Re: Add additional rain gauge via second data source
Hello, I have finally found the problem. Seemingly the image generator is not case sensitive with the signal names. The input signal was named 'rain_RG11'. The unit group system IS case sensitive because in my plugin I linked weewx.units.obs_group_dict['Rain_RG11'] = 'group_rain' And so I got a graph but with no units on the y-axis and no conversion. Regards, engolling Am Freitag, 22. November 2019 00:01:00 UTC+1 schrieb engolling: > > Hello, > > I checked my image generation settings again and I also tried to check the > imagegenerator.py file but I did not find any reason why the conversion to > "mm" is not applied or at least the native database unit "cm" is not > applies. > > I would be glad, if someone can give me a hint where this could come from > and what is the best way to debug. > > Regards, > engolling > > Am Dienstag, 5. November 2019 22:18:59 UTC+1 schrieb engolling: >> >> Hello to all, >> >> I got another question. The import of additional rain works fine now. >> So if a add the following tag to my template: >> $day.Rain_RG11.sum >> I get the correct value in my preselected unit. (Database is metric and >> my default unit for group_rain is "mm") >> >> I'm also generating two graphs with the following code: >> [[[dayrain]]] >> # Make sure the y-axis increment is at least 0.02 for the >> rain plot >> yscale = None, None, 0.02 >> plot_type = bar >> rain >> aggregate_type = sum >> aggregate_interval = 3600 >> label = Niederschlag (Stundenwerte) >> [[[dayrain_RG11]]] >> # Make sure the y-axis increment is at least 0.02 for the >> rain plot >> yscale = None, None, 0.02 >> plot_type = bar >> rain_RG11 >> aggregate_type = sum >> aggregate_interval = 3600 >> label = Niederschlag (Stundenwerte) >> >> Here I get the following images (do not look at the actual bar values - >> they are not representative and result due to testing): >> >> My self added rain source generates correct values but it does not >> display the unit and the values which are plotted are seeming to be in the >> native unit [cm] as it is stored in the database. >> Does anybody has an idea what could be the matter here? Tags are working >> fine, but not the image generation. >> >> Thanks in advance for your answers. >> >> Regards, >> engolling >> >> >> Am Dienstag, 28. Mai 2019 00:20:07 UTC+2 schrieb gjr80: >>> >>> On Tuesday, 28 May 2019 06:52:22 UTC+10, engolling wrote: >>>> >>>> So I started off with the noob variant... >>>> https://github.com/menachers/WeatherDuino/tree/master/WeeWx_Plugin >>>> >>> >>> That looks like it will work, but be aware that if the record you are >>> augmenting is in anything other than US customary units no conversion will >>> be applied (this may be fine given your current setup but who knows how it >>> may change in the future). Nothing to worry about if you are going to >>> rewrite the code anyway. >>> >>> >>>> I will change it to the sophisticated procedure you proposed. >>>> As I got you right >>>> # express our rainfall value as a ValueTuple >>>> rainfall_vt = weewx.units.ValueTuple(rainfall, 'mm', 'group_rain') >>>> I have to generate a tuple with the variable holding the actual value, >>>> followed by the unit of the signal as it can be found in the units.py dict >>>> and ending with the unit group which it belongs to. >>>> >>> >>> Correct. The ValueTuple is the basis of the WeeWX system for unit >>> conversion; it brings together the value, the units used and the unit group >>> to which it belongs. When WeeWX needs to convert the value to some other >>> units or to the units used in a particular unit system (US, Metric or >>> MetricWX) the ValueTuple has the core information used to determine how to >>> do the conversion. You might want to look at the class ValueTuple in >>> bin/weewx/units.py >>> <https://github.com/weewx/weewx/blob/master/bin/weewx/units.py#L454>. >>> the other good thing about ValueTuple based conversion is that it will >>> handle the case where the data value is None - note how in the simple >>> approach I outlined we had to take care of the case where the data value >>> may be None. >>> >>> 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/c7e114a4-904d-44f1-a173-e8d8d0932c24%40googlegroups.com.
Re: [weewx-user] Re: Add additional rain gauge via second data source
Hello, I checked my image generation settings again and I also tried to check the imagegenerator.py file but I did not find any reason why the conversion to "mm" is not applied or at least the native database unit "cm" is not applies. I would be glad, if someone can give me a hint where this could come from and what is the best way to debug. Regards, engolling Am Dienstag, 5. November 2019 22:18:59 UTC+1 schrieb engolling: > > Hello to all, > > I got another question. The import of additional rain works fine now. > So if a add the following tag to my template: > $day.Rain_RG11.sum > I get the correct value in my preselected unit. (Database is metric and my > default unit for group_rain is "mm") > > I'm also generating two graphs with the following code: > [[[dayrain]]] > # Make sure the y-axis increment is at least 0.02 for the > rain plot > yscale = None, None, 0.02 > plot_type = bar > rain > aggregate_type = sum > aggregate_interval = 3600 > label = Niederschlag (Stundenwerte) > [[[dayrain_RG11]]] > # Make sure the y-axis increment is at least 0.02 for the > rain plot > yscale = None, None, 0.02 > plot_type = bar > rain_RG11 > aggregate_type = sum > aggregate_interval = 3600 > label = Niederschlag (Stundenwerte) > > Here I get the following images (do not look at the actual bar values - > they are not representative and result due to testing): > > My self added rain source generates correct values but it does not display > the unit and the values which are plotted are seeming to be in the native > unit [cm] as it is stored in the database. > Does anybody has an idea what could be the matter here? Tags are working > fine, but not the image generation. > > Thanks in advance for your answers. > > Regards, > engolling > > > Am Dienstag, 28. Mai 2019 00:20:07 UTC+2 schrieb gjr80: >> >> On Tuesday, 28 May 2019 06:52:22 UTC+10, engolling wrote: >>> >>> So I started off with the noob variant... >>> https://github.com/menachers/WeatherDuino/tree/master/WeeWx_Plugin >>> >> >> That looks like it will work, but be aware that if the record you are >> augmenting is in anything other than US customary units no conversion will >> be applied (this may be fine given your current setup but who knows how it >> may change in the future). Nothing to worry about if you are going to >> rewrite the code anyway. >> >> >>> I will change it to the sophisticated procedure you proposed. >>> As I got you right >>> # express our rainfall value as a ValueTuple >>> rainfall_vt = weewx.units.ValueTuple(rainfall, 'mm', 'group_rain') >>> I have to generate a tuple with the variable holding the actual value, >>> followed by the unit of the signal as it can be found in the units.py dict >>> and ending with the unit group which it belongs to. >>> >> >> Correct. The ValueTuple is the basis of the WeeWX system for unit >> conversion; it brings together the value, the units used and the unit group >> to which it belongs. When WeeWX needs to convert the value to some other >> units or to the units used in a particular unit system (US, Metric or >> MetricWX) the ValueTuple has the core information used to determine how to >> do the conversion. You might want to look at the class ValueTuple in >> bin/weewx/units.py >> <https://github.com/weewx/weewx/blob/master/bin/weewx/units.py#L454>. >> the other good thing about ValueTuple based conversion is that it will >> handle the case where the data value is None - note how in the simple >> approach I outlined we had to take care of the case where the data value >> may be None. >> >> 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/9ce76a4e-3c6b-4a2b-bb2c-717bf9963b80%40googlegroups.com.
Re: [weewx-user] Re: Add additional rain gauge via second data source
Hello to all, I got another question. The import of additional rain works fine now. So if a add the following tag to my template: $day.Rain_RG11.sum I get the correct value in my preselected unit. (Database is metric and my default unit for group_rain is "mm") I'm also generating two graphs with the following code: [[[dayrain]]] # Make sure the y-axis increment is at least 0.02 for the rain plot yscale = None, None, 0.02 plot_type = bar rain aggregate_type = sum aggregate_interval = 3600 label = Niederschlag (Stundenwerte) [[[dayrain_RG11]]] # Make sure the y-axis increment is at least 0.02 for the rain plot yscale = None, None, 0.02 plot_type = bar rain_RG11 aggregate_type = sum aggregate_interval = 3600 label = Niederschlag (Stundenwerte) Here I get the following images (do not look at the actual bar values - they are not representative and result due to testing): My self added rain source generates correct values but it does not display the unit and the values which are plotted are seeming to be in the native unit [cm] as it is stored in the database. Does anybody has an idea what could be the matter here? Tags are working fine, but not the image generation. Thanks in advance for your answers. Regards, engolling Am Dienstag, 28. Mai 2019 00:20:07 UTC+2 schrieb gjr80: > > On Tuesday, 28 May 2019 06:52:22 UTC+10, engolling wrote: >> >> So I started off with the noob variant... >> https://github.com/menachers/WeatherDuino/tree/master/WeeWx_Plugin >> > > That looks like it will work, but be aware that if the record you are > augmenting is in anything other than US customary units no conversion will > be applied (this may be fine given your current setup but who knows how it > may change in the future). Nothing to worry about if you are going to > rewrite the code anyway. > > >> I will change it to the sophisticated procedure you proposed. >> As I got you right >> # express our rainfall value as a ValueTuple >> rainfall_vt = weewx.units.ValueTuple(rainfall, 'mm', 'group_rain') >> I have to generate a tuple with the variable holding the actual value, >> followed by the unit of the signal as it can be found in the units.py dict >> and ending with the unit group which it belongs to. >> > > Correct. The ValueTuple is the basis of the WeeWX system for unit > conversion; it brings together the value, the units used and the unit group > to which it belongs. When WeeWX needs to convert the value to some other > units or to the units used in a particular unit system (US, Metric or > MetricWX) the ValueTuple has the core information used to determine how to > do the conversion. You might want to look at the class ValueTuple in > bin/weewx/units.py > <https://github.com/weewx/weewx/blob/master/bin/weewx/units.py#L454>. the > other good thing about ValueTuple based conversion is that it will handle > the case where the data value is None - note how in the simple approach I > outlined we had to take care of the case where the data value may be None. > > 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/664d5727-d289-4149-924a-5683010a4b0e%40googlegroups.com.
[weewx-user] Re: Unit conversion rule in conf file
Hallo Gary, thank you very much. As so often you are my last hope. The last point that WeeWx 3.9.0. introduced the new settings was the right hint. I compared my WeeWx conf files with the newest once and I saw this was missing. I probably have made something wrong when updating the software. Now I fixed it and it works as expected :) Best regards, Stefan Am Freitag, 11. Oktober 2019 01:14:17 UTC+2 schrieb gjr80: > > The other side of the coin is the actual tag that is used in the template. > For example, $current.windSpeed will show the current archive record wind > speed formatted/converted as per weewx.conf and skin.conf but > $current.windSpeed.knot will always display the current archive record > wind speed in knots. It would be unusual to find such a tag with hard coded > units in a properly developed customisable skin but who knows. > > WeeWX 3.9.0 introduced the [StdReport] [[Defaults]] stanza and defaults.py > <http://weewx.com/docs/upgrading.htm#Skin_defaults> for setting default > units (and formats and other things) but in your case since you have an > appropriate override in [StdReport] [[StandardReport]] this should not be > the cause of your problem. > > Gary > > On Friday, 11 October 2019 08:26:59 UTC+10, engolling wrote: >> >> Hello, >> >> I'm stuck at a relativley simple problem of unit conversion in >> combination with the used neowx skin. >> >> In the weewx.conf the standard report section is looking like this: >> [[StandardReport]] >> # See the customizing guide to change the units, plot types and >> line >> # colors, modify the fonts, display additional sensor data, and >> other >> # customizations. Many of those changes can be made here by >> overriding >> # parameters, or by modifying templates within the skin itself. >> >> # The StandardReport uses the 'Standard' skin, which contains the >> # images, templates and plots for the report. >> skin = neowx >> [[[Units]]] >> Groups >> group_altitude = meter >> group_speed2 = km_per_hour2 >> group_pressure = mbar >> group_rain = mm >> group_rainrate = mm_per_hour >> group_temperature = degree_C >> group_degree_day = degree_C_day >> group_speed = km_per_hour >> >> >> and in the skin.conf like this: >> [[Groups]] >> # For each group of measurements, this section sets what units to >> # use for it. >> # NB: The unit is always in the singular. I.e., 'mile_per_hour', >> # NOT 'miles_per_hour' >> >> group_altitude = meter# Options are 'foot' >> or 'meter' >> group_degree_day = degree_C_day # Options are >> 'degree_F_day' or 'degree_C_day' >> group_direction= degree_compass >> group_moisture = centibar >> group_percent = percent >> group_pressure = hPa # Options are 'inHg', >> 'mmHg', 'mbar', or 'hPa' >> group_radiation= watt_per_meter_squared >> group_rain = mm # Options are 'inch', >> 'cm', or 'mm' >> group_rainrate = mm_per_hour # Options are >> 'inch_per_hour', 'cm_per_hour', or 'mm_per_hour' >> group_speed= km_per_hour # Options are >> 'mile_per_hour', 'km_per_hour', 'knot', or 'meter_per_second' >> group_speed2 = km_per_hour2 # Options are >> 'mile_per_hour2', 'km_per_hour2', 'knot2', or 'meter_per_second2' >> group_temperature = degree_C # Options are >> 'degree_F' or 'degree_C' >> group_uv = uv_index >> group_volt = volt >> group_length = cm >> >> # The following are used internally and should not be changed: >> group_count= count >> group_interval = minute >> group_time = unix_epoch >> group_elapsed = second >> >> [[StringFormats]] >> # This section sets the string formatting for each type of unit. >> >> centibar = %.0f >> cm = %.2f >> cm_per_hour= %.2f >> degree_C = %.1f >> degree_F = %.1f >> degree_compass = %.0f >> foot
[weewx-user] Unit conversion rule in conf file
= " %" volt = " V" watt_per_meter_squared = " W/m²" day = " Tag"," Tage" hour = " Stunde", " Stunden" minute= " Minute", " Minuten" second= " Sekunde", " Sekunden" NONE = "" [[TimeFormats]] # This section sets the string format to be used for each time scale. # The values below will work in every locale, but may not look # particularly attractive. See the Customization Guide for alternatives. day= %X week = %X (%A) month = %x %X year = %x %X rainyear = %x %X current= %x %X ephem_day = %X ephem_year = %x %X [[Ordinates]] # The ordinal directions. The last one should be for no wind direction directions = N, NNO, NO, ONO, O, OSO, SO, SSO, S, SSW, SW, WSW, W, WNW, NW, NNW, N/A [[DegreeDays]] # This section sets the base temperatures used for the calculation # of heating and cooling degree-days. # Base temperature for heating days, with unit: heating_base = 65, degree_F # Base temperature for cooling days, with unit: cooling_base = 65, degree_F [[Trend]] time_delta = 10800 # 3 hours time_grace = 300# 5 minutes ### It's the normal neowx skin conf a bit extended and translated to German. If I look at the output page here http://wetter2.kuntn-forum.de/index.html the wind speed is still in m/s but I want it to be in km/h - I checked the .confs twice - I don't find my mistake. Overiding the unit with .km_per_hour in the template works. Does anybody have an idea what could be wrong? Beste regards, engolling -- 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/678a0161-38d0-402b-a1de-39ca544834be%40googlegroups.com.
Re: [weewx-user] Re: Add additional rain gauge via second data source
Hi Gary, sometimes I can't see the forest because of all of those trees anymore... :) Thank you for your great answer again. So I started off with the noob variant... https://github.com/menachers/WeatherDuino/tree/master/WeeWx_Plugin I will change it to the sophisticated procedure you proposed. As I got you right # express our rainfall value as a ValueTuple rainfall_vt = weewx.units.ValueTuple(rainfall, 'mm', 'group_rain') I have to generate a tuple with the variable holding the actual value, followed by the unit of the signal as it can be found in the units.py dict and ending with the unit group which it belongs to. best regards, engolling -- 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/8ef8d2da-4c89-4629-8f21-4495fe059ba5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [weewx-user] Re: Add additional rain gauge via second data source
Hello Andrew, indeed it actually is only augmenting. But in case the archive data is gained from a DMPAFT packet it seems to be converted complete after augmenting. If the archive data is gained from a LOOP packet it converted before. So the following things would probably solve the issue: - Only using record generation hardare - Database in US units My intention is that my plugin works with any configuration, so I would like to work out an solution for this. So my idea would be to find an indicator of the archive data is gained from an LOOP packet or a DMPAFT packet - so conversion could be done if necessary. Regards, engolling Am Sonntag, 26. Mai 2019 13:53:46 UTC+2 schrieb Andrew Milner: > > The script you posted SHOULD only be augmenting REC packets, and not be > affected by any LOOP packets. > > Maybe you should set record generation to either use hardware or use > software and not prefer hardware or prefer software. Your augmented data > should be use software I would have thought > > > > > > On Sunday, 26 May 2019 13:37:27 UTC+3, engolling wrote: >> >> Hallo, >> think I tracked the issue down. >> First it starts with record generation software. >> >> So each time a archive dataset is retreivedn form the hardware logger my >> data is augmented and then it runs apparently through the unit converter, >> converting it to metric units (in case of my augmented data coming in >> metric this is bad). >> This happens whenn WeeWx was off for some time. >> Each time an archive paket is gained from the LOOP data it was seemingly >> already converted my data is augmented and it is saved correctly to the >> database. >> >> So my question is simplified. Is it possible to determine if a archive >> record is archived of hardware logger data or LOOP data or can I influence >> the order of augmenting and converting? >> >> Best regards, >> engolling >> >> Am Mittwoch, 22. Mai 2019 23:20:08 UTC+2 schrieb engolling: >>> >>> Hello, >>> >>> of course I can give more details :-) >>> >>> So as you know I'm augmenting some extra data to my archive records >>> which I get from emulated davis loop packaged. >>> My file whichs contains always the latest data looks like this: >>> >>> https://github.com/menachers/WeatherDuino/blob/master/WeeWx_Plugin/WeeWx_Exp.txt >>> So there is written a signal name, a unit group and the actual data as >>> csv. >>> >>> The data is then augmented with the following script: >>> >>> https://github.com/menachers/WeatherDuino/blob/master/WeeWx_Plugin/WeeWx_WeatherDuino_Logger_plugin.py >>> called as data service in the weewx.conf >>> >>> record_generation is set to software, target_unit is set to metric. >>> >>> The augmented data is in °C and most of the time it is saved to the >>> database without being converted but sometimes a few datasets are double >>> converted. >>> >>> When record_generation is set to hardware the data is always converted, >>> so I'm exporting the data in US units and weewx converts it back. This is >>> no problem either. >>> But it is hard to handle when weewx jumps between no conversion and >>> conversion. >>> >>> Hopefully it is more clear now what I mean. >>> >>> Regards, >>> engolling >>> >>> >>> Am Montag, 20. Mai 2019 00:49:56 UTC+2 schrieb gjr80: >>>> >>>> Hi, >>>> >>>> Perhaps you could give us some more details as to how the extra >>>> temperature data is being obtained/provided/added to WeeWX, happy to see >>>> code/data formats etc - code usually gives an unambiguous picture, >>>> descriptions are often open to interpretation. I am having a little >>>> difficulty understanding how the numeric data is always being received but >>>> not the units, but perhaps that will become clear once you provide some >>>> more detail. >>>> >>>> Gary >>>> >>>> On Monday, 20 May 2019 05:55:18 UTC+10, engolling wrote: >>>>> >>>>> Hello, >>>>> >>>>> me again :). >>>>> Thank you for your last answer Thomas. Works fine. >>>>> >>>>> Now I have a new "thing" I do not understand. >>>>> As discussed above I'm augmenting different data - also rain data to >>>>> the archive records as described in the customization guide. >>>>> >>
Re: [weewx-user] Re: Add additional rain gauge via second data source
Hallo, think I tracked the issue down. First it starts with record generation software. So each time a archive dataset is retreivedn form the hardware logger my data is augmented and then it runs apparently through the unit converter, converting it to metric units (in case of my augmented data coming in metric this is bad). This happens whenn WeeWx was off for some time. Each time an archive paket is gained from the LOOP data it was seemingly already converted my data is augmented and it is saved correctly to the database. So my question is simplified. Is it possible to determine if a archive record is archived of hardware logger data or LOOP data or can I influence the order of augmenting and converting? Best regards, engolling Am Mittwoch, 22. Mai 2019 23:20:08 UTC+2 schrieb engolling: > > Hello, > > of course I can give more details :-) > > So as you know I'm augmenting some extra data to my archive records which > I get from emulated davis loop packaged. > My file whichs contains always the latest data looks like this: > > https://github.com/menachers/WeatherDuino/blob/master/WeeWx_Plugin/WeeWx_Exp.txt > So there is written a signal name, a unit group and the actual data as csv. > > The data is then augmented with the following script: > > https://github.com/menachers/WeatherDuino/blob/master/WeeWx_Plugin/WeeWx_WeatherDuino_Logger_plugin.py > called as data service in the weewx.conf > > record_generation is set to software, target_unit is set to metric. > > The augmented data is in °C and most of the time it is saved to the > database without being converted but sometimes a few datasets are double > converted. > > When record_generation is set to hardware the data is always converted, so > I'm exporting the data in US units and weewx converts it back. This is no > problem either. > But it is hard to handle when weewx jumps between no conversion and > conversion. > > Hopefully it is more clear now what I mean. > > Regards, > engolling > > > Am Montag, 20. Mai 2019 00:49:56 UTC+2 schrieb gjr80: >> >> Hi, >> >> Perhaps you could give us some more details as to how the extra >> temperature data is being obtained/provided/added to WeeWX, happy to see >> code/data formats etc - code usually gives an unambiguous picture, >> descriptions are often open to interpretation. I am having a little >> difficulty understanding how the numeric data is always being received but >> not the units, but perhaps that will become clear once you provide some >> more detail. >> >> Gary >> >> On Monday, 20 May 2019 05:55:18 UTC+10, engolling wrote: >>> >>> Hello, >>> >>> me again :). >>> Thank you for your last answer Thomas. Works fine. >>> >>> Now I have a new "thing" I do not understand. >>> As discussed above I'm augmenting different data - also rain data to the >>> archive records as described in the customization guide. >>> >>> I also augment temperature signals and sometimes they are converted to >>> metric variables and sometimes not. The problem is the signal is already in >>> °C and should be in °C, but if it is converted it looks like this: >>> >>> >>> <http://www.google.com/url?q=http%3A%2F%2Fwetter2.kuntn-forum.de%2Fdaytempdew.png=D=1=AFQjCNGQMmsS1cPqrlD8F5tydTWEueDaEg> >>> The database is mertric. If I get for example a temperature of 22.61°C >>> which should be imported into the database directly and it is most time. >>> But sometimes I get -5.21°C (which is the result of the Farenheit Celsius >>> conversion of 22.61°C). >>> >>> My Raspberry Pi has a bad WIFI internet connection and FTP often fails >>> and it seems to be related to this. >>> >>> Could this be a reason and do you know how to handle the conversion? >>> >>> Regards, >>> engolling >>> >>> Am Dienstag, 7. Mai 2019 23:30:27 UTC+2 schrieb Thomas Keffer: >>>> >>>> Yes. That's certainly possible. >>>> >>>> -tk >>>> >>>> On Tue, May 7, 2019 at 1:35 PM engolling wrote: >>>> >>>>> Hello together, >>>>> >>>>> it's me again with hopefully a last question... >>>>> As you know I'm augmenting some extra data from my service to the >>>>> WeeWx archive records. But if archive records are loaded of the stations >>>>> logger this data (which is in the future) is also augmented. >>>>> Is it possible to read the timestamp of the archive record beeing >>>>> sav
Re: [weewx-user] Re: Add additional rain gauge via second data source
Hello, of course I can give more details :-) So as you know I'm augmenting some extra data to my archive records which I get from emulated davis loop packaged. My file whichs contains always the latest data looks like this: https://github.com/menachers/WeatherDuino/blob/master/WeeWx_Plugin/WeeWx_Exp.txt So there is written a signal name, a unit group and the actual data as csv. The data is then augmented with the following script: https://github.com/menachers/WeatherDuino/blob/master/WeeWx_Plugin/WeeWx_WeatherDuino_Logger_plugin.py called as data service in the weewx.conf record_generation is set to software, target_unit is set to metric. The augmented data is in °C and most of the time it is saved to the database without being converted but sometimes a few datasets are double converted. When record_generation is set to hardware the data is always converted, so I'm exporting the data in US units and weewx converts it back. This is no problem either. But it is hard to handle when weewx jumps between no conversion and conversion. Hopefully it is more clear now what I mean. Regards, engolling Am Montag, 20. Mai 2019 00:49:56 UTC+2 schrieb gjr80: > > Hi, > > Perhaps you could give us some more details as to how the extra > temperature data is being obtained/provided/added to WeeWX, happy to see > code/data formats etc - code usually gives an unambiguous picture, > descriptions are often open to interpretation. I am having a little > difficulty understanding how the numeric data is always being received but > not the units, but perhaps that will become clear once you provide some > more detail. > > Gary > > On Monday, 20 May 2019 05:55:18 UTC+10, engolling wrote: >> >> Hello, >> >> me again :). >> Thank you for your last answer Thomas. Works fine. >> >> Now I have a new "thing" I do not understand. >> As discussed above I'm augmenting different data - also rain data to the >> archive records as described in the customization guide. >> >> I also augment temperature signals and sometimes they are converted to >> metric variables and sometimes not. The problem is the signal is already in >> °C and should be in °C, but if it is converted it looks like this: >> >> >> <http://www.google.com/url?q=http%3A%2F%2Fwetter2.kuntn-forum.de%2Fdaytempdew.png=D=1=AFQjCNGQMmsS1cPqrlD8F5tydTWEueDaEg> >> The database is mertric. If I get for example a temperature of 22.61°C >> which should be imported into the database directly and it is most time. >> But sometimes I get -5.21°C (which is the result of the Farenheit Celsius >> conversion of 22.61°C). >> >> My Raspberry Pi has a bad WIFI internet connection and FTP often fails >> and it seems to be related to this. >> >> Could this be a reason and do you know how to handle the conversion? >> >> Regards, >> engolling >> >> Am Dienstag, 7. Mai 2019 23:30:27 UTC+2 schrieb Thomas Keffer: >>> >>> Yes. That's certainly possible. >>> >>> -tk >>> >>> On Tue, May 7, 2019 at 1:35 PM engolling wrote: >>> >>>> Hello together, >>>> >>>> it's me again with hopefully a last question... >>>> As you know I'm augmenting some extra data from my service to the WeeWx >>>> archive records. But if archive records are loaded of the stations logger >>>> this data (which is in the future) is also augmented. >>>> Is it possible to read the timestamp of the archive record beeing saved >>>> at the moment and then decide if data should be augmented or not? >>>> Im thinking of a code like this: >>>> if dateTime_AugmentedData - event.record[dateTime] < 300: >>>>--> augment_data >>>> >>>> >>>> >>>> >>>> >>>> Am Mittwoch, 3. April 2019 00:54:17 UTC+2 schrieb gjr80: >>>>> >>>>> Good that you have tracked down the issue. Running hardware record >>>>> generation on a Davis station has it advantages, though maybe not so >>>>> advantageous on emulated hardware. >>>>> >>>>> Regards plotting rain data from two sensors. The current WeeWX plot >>>>> engine will certainly allow you to plot two obs in a bar graph plot, >>>>> though >>>>> I expect the outcome will be one bar plotted over the top of the other. >>>>> Not >>>>> really what you are seeking. There is no option to plot the bars adjacent >>>>> to each other. It may be possible to modify the plot engine though I do >>>&g
Re: [weewx-user] Re: Add additional rain gauge via second data source
Hello, me again :). Thank you for your last answer Thomas. Works fine. Now I have a new "thing" I do not understand. As discussed above I'm augmenting different data - also rain data to the archive records as described in the customization guide. I also augment temperature signals and sometimes they are converted to metric variables and sometimes not. The problem is the signal is already in °C and should be in °C, but if it is converted it looks like this: <http://wetter2.kuntn-forum.de/daytempdew.png> The database is mertric. If I get for example a temperature of 22.61°C which should be imported into the database directly and it is most time. But sometimes I get -5.21°C (which is the result of the Farenheit Celsius conversion of 22.61°C). My Raspberry Pi has a bad WIFI internet connection and FTP often fails and it seems to be related to this. Could this be a reason and do you know how to handle the conversion? Regards, engolling Am Dienstag, 7. Mai 2019 23:30:27 UTC+2 schrieb Thomas Keffer: > > Yes. That's certainly possible. > > -tk > > On Tue, May 7, 2019 at 1:35 PM engolling > wrote: > >> Hello together, >> >> it's me again with hopefully a last question... >> As you know I'm augmenting some extra data from my service to the WeeWx >> archive records. But if archive records are loaded of the stations logger >> this data (which is in the future) is also augmented. >> Is it possible to read the timestamp of the archive record beeing saved >> at the moment and then decide if data should be augmented or not? >> Im thinking of a code like this: >> if dateTime_AugmentedData - event.record[dateTime] < 300: >>--> augment_data >> >> >> >> >> >> Am Mittwoch, 3. April 2019 00:54:17 UTC+2 schrieb gjr80: >>> >>> Good that you have tracked down the issue. Running hardware record >>> generation on a Davis station has it advantages, though maybe not so >>> advantageous on emulated hardware. >>> >>> Regards plotting rain data from two sensors. The current WeeWX plot >>> engine will certainly allow you to plot two obs in a bar graph plot, though >>> I expect the outcome will be one bar plotted over the top of the other. Not >>> really what you are seeking. There is no option to plot the bars adjacent >>> to each other. It may be possible to modify the plot engine though I do not >>> expect it would be a simple modification, the plot engine is fairly >>> rudimentary. You may need to use an external charting package which should >>> easily do what you want, though this too will not be a turn key solution as >>> you will need to generate the necessary data for the package as well as >>> integrate it into your web page(s). >>> >>> Gary >>> >>> On Wednesday, 3 April 2019 03:44:09 UTC+10, engolling wrote: >>>> >>>> Hi Gary, >>>> >>>> again thanks for your extended reply. >>>> Meanwhile I added a lot of debugging code in the vantage driver and the >>>> WeatherDuino code and was able to find out the reason what happened. >>>> Their is a buffer on the flash chip which is written before storing the >>>> data in the flash page. And this buffer always had the outdated data of >>>> the >>>> page before in the last entries. >>>> This lead to this behaviour that the actual written page contained >>>> wrong data, but the page before and the page after was pretty fine... >>>> >>>> It took me quite some time to find the system behind this error. >>>> I'm in touch with the developper of the WeatherDuino and this issue >>>> will be fixed in the next firmware release so there will be full >>>> compatibility with WeeWx. >>>> >>>> Now that erverything is working I have a last question - do you, or >>>> anybody else, think it is possible to draw a bar graph having the rain >>>> bars >>>> of two sensors right beside? >>>> I did not find anything in the manual and if I define the diagramm like >>>> in the line / dot graphs the two bars overlay, so that the bar of the >>>> second rain sensor is not visible, if it is a bit smaller. >>>> >>>> Thank you for all your replies. >>>> >>>> Regards, >>>> engolling >>>> >>>> Am Dienstag, 2. April 2019 16:01:11 UTC+2 schrieb gjr80: >>>>> >>>>> Sorry for being a little tardy in replying but I wanted to sit down >>>&g
[weewx-user] Re: Add additional rain gauge via second data source
Hello together, it's me again with hopefully a last question... As you know I'm augmenting some extra data from my service to the WeeWx archive records. But if archive records are loaded of the stations logger this data (which is in the future) is also augmented. Is it possible to read the timestamp of the archive record beeing saved at the moment and then decide if data should be augmented or not? Im thinking of a code like this: if dateTime_AugmentedData - event.record[dateTime] < 300: --> augment_data Am Mittwoch, 3. April 2019 00:54:17 UTC+2 schrieb gjr80: > > Good that you have tracked down the issue. Running hardware record > generation on a Davis station has it advantages, though maybe not so > advantageous on emulated hardware. > > Regards plotting rain data from two sensors. The current WeeWX plot engine > will certainly allow you to plot two obs in a bar graph plot, though I > expect the outcome will be one bar plotted over the top of the other. Not > really what you are seeking. There is no option to plot the bars adjacent > to each other. It may be possible to modify the plot engine though I do not > expect it would be a simple modification, the plot engine is fairly > rudimentary. You may need to use an external charting package which should > easily do what you want, though this too will not be a turn key solution as > you will need to generate the necessary data for the package as well as > integrate it into your web page(s). > > Gary > > On Wednesday, 3 April 2019 03:44:09 UTC+10, engolling wrote: >> >> Hi Gary, >> >> again thanks for your extended reply. >> Meanwhile I added a lot of debugging code in the vantage driver and the >> WeatherDuino code and was able to find out the reason what happened. >> Their is a buffer on the flash chip which is written before storing the >> data in the flash page. And this buffer always had the outdated data of the >> page before in the last entries. >> This lead to this behaviour that the actual written page contained wrong >> data, but the page before and the page after was pretty fine... >> >> It took me quite some time to find the system behind this error. >> I'm in touch with the developper of the WeatherDuino and this issue will >> be fixed in the next firmware release so there will be full compatibility >> with WeeWx. >> >> Now that erverything is working I have a last question - do you, or >> anybody else, think it is possible to draw a bar graph having the rain bars >> of two sensors right beside? >> I did not find anything in the manual and if I define the diagramm like >> in the line / dot graphs the two bars overlay, so that the bar of the >> second rain sensor is not visible, if it is a bit smaller. >> >> Thank you for all your replies. >> >> Regards, >> engolling >> >> Am Dienstag, 2. April 2019 16:01:11 UTC+2 schrieb gjr80: >>> >>> Sorry for being a little tardy in replying but I wanted to sit down and >>> work my way through the Davis protocol. It seems everything is being >>> followed, I do not know if the lack of a final acknowledgement is critical >>> or not but what I would say is that the Davis driver works with real Davis >>> hardware without issue. >>> >>> One thing I did wonder, the DMPAFT command downloads all archive records >>> after a given timestamp. Archive records are downloaded a page at a time >>> and a page contains 5 archive records. When we look at the earlier log >>> extracts you have provided there seems to be groups of 5 archive records >>> being processed (1 page?) but of course all that are already in the archive >>> are rejected, for example: >>> >>> Mar 18 22:45:18 WeatherDuinoPi weewx[12220]: manager: Unable to add >>> record 2019-03-18 22:43:00 CET (1552945380) to database 'weewx.sdb': >>> UNIQUE constraint failed: archive.dateTime >>> Mar 18 22:45:20 WeatherDuinoPi weewx[12220]: manager: Added record 2019- >>> 03-18 22:44:00 CET (1552945440) to database 'weewx.sdb' >>> Mar 18 22:45:20 WeatherDuinoPi weewx[12220]: manager: Added record 2019- >>> 03-18 22:44:00 CET (1552945440) to daily summary in 'weewx.sdb' >>> Mar 18 22:45:22 WeatherDuinoPi weewx[12220]: manager: Unable to add >>> record 2019-03-18 22:40:00 CET (1552945200) to database 'weewx.sdb': >>> UNIQUE constraint failed: archive.dateTime >>> Mar 18 22:45:24 WeatherDuinoPi weewx[12220]: manager: Unable to add >>> record 2019-03-18 22:41:00 CET (1552945260) to database 'weewx.sdb': >>> UNIQUE constraint failed: archive.da
[weewx-user] Re: Add additional rain gauge via second data source
Hi Gary, again thanks for your extended reply. Meanwhile I added a lot of debugging code in the vantage driver and the WeatherDuino code and was able to find out the reason what happened. Their is a buffer on the flash chip which is written before storing the data in the flash page. And this buffer always had the outdated data of the page before in the last entries. This lead to this behaviour that the actual written page contained wrong data, but the page before and the page after was pretty fine... It took me quite some time to find the system behind this error. I'm in touch with the developper of the WeatherDuino and this issue will be fixed in the next firmware release so there will be full compatibility with WeeWx. Now that erverything is working I have a last question - do you, or anybody else, think it is possible to draw a bar graph having the rain bars of two sensors right beside? I did not find anything in the manual and if I define the diagramm like in the line / dot graphs the two bars overlay, so that the bar of the second rain sensor is not visible, if it is a bit smaller. Thank you for all your replies. Regards, engolling Am Dienstag, 2. April 2019 16:01:11 UTC+2 schrieb gjr80: > > Sorry for being a little tardy in replying but I wanted to sit down and > work my way through the Davis protocol. It seems everything is being > followed, I do not know if the lack of a final acknowledgement is critical > or not but what I would say is that the Davis driver works with real Davis > hardware without issue. > > One thing I did wonder, the DMPAFT command downloads all archive records > after a given timestamp. Archive records are downloaded a page at a time > and a page contains 5 archive records. When we look at the earlier log > extracts you have provided there seems to be groups of 5 archive records > being processed (1 page?) but of course all that are already in the archive > are rejected, for example: > > Mar 18 22:45:18 WeatherDuinoPi weewx[12220]: manager: Unable to add > record 2019-03-18 22:43:00 CET (1552945380) to database 'weewx.sdb': > UNIQUE constraint failed: archive.dateTime > Mar 18 22:45:20 WeatherDuinoPi weewx[12220]: manager: Added record 2019-03 > -18 22:44:00 CET (1552945440) to database 'weewx.sdb' > Mar 18 22:45:20 WeatherDuinoPi weewx[12220]: manager: Added record 2019-03 > -18 22:44:00 CET (1552945440) to daily summary in 'weewx.sdb' > Mar 18 22:45:22 WeatherDuinoPi weewx[12220]: manager: Unable to add > record 2019-03-18 22:40:00 CET (1552945200) to database 'weewx.sdb': > UNIQUE constraint failed: archive.dateTime > Mar 18 22:45:24 WeatherDuinoPi weewx[12220]: manager: Unable to add > record 2019-03-18 22:41:00 CET (1552945260) to database 'weewx.sdb': > UNIQUE constraint failed: archive.dateTime > Mar 18 22:45:25 WeatherDuinoPi weewx[12220]: manager: Unable to add > record 2019-03-18 22:42:00 CET (1552945320) to database 'weewx.sdb': > UNIQUE constraint failed: archive.dateTime > > I did not see anywhere where you ran WeeWX directly > <http://weewx.com/docs/usersguide.htm#Running_directly> and provided a > few minutes of console output. Maybe that may shed more light on the > problem. Failing that you may need to put some logging in the vantage > driver to see exactly what the driver is reading and then sending to WeeWX. > > Gary > > > On Wednesday, 27 March 2019 07:44:59 UTC+10, engolling wrote: >> >> Hi Gary, >> >> I tried to debug the system and therefore I built a "serial sniffer" in >> form of an Arduino Mega passing through the data between serial0 and >> serial1 and printing all messages out on serial2. >> I used HTERM to display it and I will provide some screenshots for a >> better visibility. >> Here we see a typical archive request: >> >> 1. DMPAFT\n - request of WeeWx >> 2. WeatherDuino acknowledge with 0x06 >> 3. WeeWx sends Date, Time and Checksum >> 4. WeatherDuino acknowledge with 0x06 >> 5. WeatherDuino sends number of pages and checksum >> 6. WeeWx acknowledge >> 7. WeatherDuino sends page and overhead - in sum 267 bytes as expected. >> *8. WeeWx sends LineFeed, but should acknowledge, send a CRC failure or >> skip - that is strange...* >> >> See documentation line 35 and 36 >> >> https://www.davisinstruments.com/support/weather/download/VantageSerialProtocolDocs_v261.pdf >> >> 1 Minute and 360ms later the next DMPAFT command is sent. >> >> This example is starting today at 19:05:16 local time - this is written >> into the logfile. >> Mar 26 19:05:17 WeatherDuinoPi weewx[17760]: manager: Added record 2019- >> 03-26 19:04:00 CET (1553623440) to database 'weewx.sdb' >> Mar 26 19:05:17 Weath
[weewx-user] Re: Add additional rain gauge via second data source
Hi Gary, I tried to debug the system and therefore I built a "serial sniffer" in form of an Arduino Mega passing through the data between serial0 and serial1 and printing all messages out on serial2. I used HTERM to display it and I will provide some screenshots for a better visibility. Here we see a typical archive request: 1. DMPAFT\n - request of WeeWx 2. WeatherDuino acknowledge with 0x06 3. WeeWx sends Date, Time and Checksum 4. WeatherDuino acknowledge with 0x06 5. WeatherDuino sends number of pages and checksum 6. WeeWx acknowledge 7. WeatherDuino sends page and overhead - in sum 267 bytes as expected. *8. WeeWx sends LineFeed, but should acknowledge, send a CRC failure or skip - that is strange...* See documentation line 35 and 36 https://www.davisinstruments.com/support/weather/download/VantageSerialProtocolDocs_v261.pdf 1 Minute and 360ms later the next DMPAFT command is sent. This example is starting today at 19:05:16 local time - this is written into the logfile. Mar 26 19:05:17 WeatherDuinoPi weewx[17760]: manager: Added record 2019-03- 26 19:04:00 CET (1553623440) to database 'weewx.sdb' Mar 26 19:05:17 WeatherDuinoPi weewx[17760]: manager: Added record 2019-03- 26 19:04:00 CET (1553623440) to daily summary in 'weewx.sdb' Mar 26 19:05:19 WeatherDuinoPi weewx[17760]: manager: Unable to add record 2019-03-26 19:00:00 CET (1553623200) to database 'weewx.sdb': UNIQUE constraint failed: archive.dateTime Mar 26 19:05:21 WeatherDuinoPi weewx[17760]: manager: Unable to add record 2019-03-26 19:01:00 CET (1553623260) to database 'weewx.sdb': UNIQUE constraint failed: archive.dateTime Mar 26 19:05:31 WeatherDuinoPi weewx[17760]: cheetahgenerator: Generated 9 files for report StandardReport in 10.25 seconds Mar 26 19:06:19 WeatherDuinoPi weewx[17760]: manager: Added record 2019-03- 26 19:05:00 CET (1553623500) to database 'weewx.sdb' Mar 26 19:06:20 WeatherDuinoPi weewx[17760]: manager: Added record 2019-03- 26 19:05:00 CET (1553623500) to daily summary in 'weewx.sdb' Mar 26 19:06:23 WeatherDuinoPi weewx[17760]: manager: Unable to add record 2019-03-26 19:01:00 CET (1553623260) to database 'weewx.sdb': UNIQUE constraint failed: archive.dateTime In my opinion the WeatherDuino is acting as described in the protocol description. It is also a bit strange that WeeWx tries to add the "older" records now to the database which are also saved in the same page of the flash. But as it does not acknowledge the received page something strange is going on at this point. Maybe you or somebody else owning an original Davis station has an idea. Regards, engolling Am Montag, 25. März 2019 14:47:08 UTC+1 schrieb gjr80: > > The vantage driver is somewhat complex. How the vantage driver operates > depends on whether hardware or software record generation is in use. If > software record generation is in use then the vantage driver obtains loop > packets from the console (using the LOOP command) and the loop packets are > then passed to WeeWX. This goes on continuously. WeeWX accumulates the loop > packets and at the end of each archive interval WeeWX synthesises an > archive record from the accumulated loop packets. This archive record is > then further processed by various services, saved to database and used as > necessary in report generation. > > If hardware record generation is in use then the same loop packet > processes occur as for software record generation (ie the driver passes > loop packets to WeeWX and WeeWX accumulates them) but at the end of the > archive interval instead of WeeWX synthesising an archive record from the > accumulated loop packets, WeeWX asks the driver to obtain an archive record > from the console. The driver uses the DMPAFT command to obtain the archive > record and this archive record is passed back to WeeWX. This hardware > archive record is further processed by various services, saved to database > and used as necessary in report generation. > > As far as I know the DMPAFT command is only used at the end of the archive > interval (eg every 5 minutes) and not very few seconds. I think to dig any > further into the issue would take some detailed analysis of how the > WeatherDuino responds to various commands. I suspect that somewhere the > behaviour when the WeatherDuino receives the DMPAFT command is slightly > different to the Davis console/logger. You should be able to instrument the > vantage driver to log anything from raw data from the console/logger > through to the decoded observations and packets/records. The good thing is > the Davis protocols are documented and in the public domain so it should be > easy to compare actual and expected responses. > > Gary > > On Sunday, 24 March 2019 09:03:28 UTC+10, engolling wrote: >> >> Hi Gary, >> I checked the emulation of the WeatherDuino in the
[weewx-user] Re: Add additional rain gauge via second data source
Hi Gary, I checked the emulation of the WeatherDuino in the code and from my point of view it seems to be implemented as in the protocol description. Nevertheless it might differ in any behaviour which is not exactly defined in the description. It's very hard for me to understand the python code of the vantage driver since I am not familiar with the language. I estimate that the vantage driver make the weewx engine to save an archive record each time it gets one from the hardware. According to my observations und the upper preconditions it seems that archive records are received in the same frequency as the LOOP packets. This would mean that the vantage driver polls with a DMPAFT command each view seconds. Do you have any knowledge about this matter and do you know how it should work correctly? To get this issue solved I think it would be necessary to get a serial sniffer in place to be able to see the communications between both devices. Can I simply add some logs in the source of the vantage driver, like I did in my data service? Regards, engolling Am Freitag, 22. März 2019 00:48:49 UTC+1 schrieb gjr80: > > It seems that the WeatherDuino emulation of the Davis logger may still > have some issues. It's possible that the WeeWX vantage driver has some > issues but the driver is mature and has been in use for many years > communicating with actual Davis hardware without issue. One thing I have > noticed with some of the other PWS software packages is that they seem to > operate using the vantage loop packets only, whereas WeeWX has the option > of operating with loop packets only (record_generation=software) or a > combination of loop packets and hardware archive records ( > record_generation=hardware). That may explain why no one else sees this > issue. I am certain I have seen another WeeWX user who was using the > WeatherDuino as a Davis emulator and there were some clear issues with the > emulator. Unfortunately I cannot find that thread. > > You can obtain extra debug info in the log by setting debug=1 in > weewx.conf, though for the vantage driver I doubt this will give you too > much more information. The vantage driver does not have the debug > capabilities that some other driver have so that you can see individual > commands and responses. > > Gary > > On Wednesday, 20 March 2019 08:26:33 UTC+10, engolling wrote: >> >> Hi Gary, >> >> I disabled my data service and the errors still were there. See the >> logfile in attachment. >> >> So I assumed that there is a problem with the vantage driver in >> combination with my hardware. >> So I changed in weewx.conf to >> # If possible, new archive records are downloaded from the station >> # hardware. If the hardware does not support this, then new archive >> # records will be generated in software. >> # Set the following to "software" to force software record >> generation. >> record_generation = software >> this solves the problem with the logging errors. >> >> With the "unable to add records" problem solved I finished my data >> service - also in attachment - which seems to be working now :). >> >> Back to the issue with the archive records - I read in the customization >> guide, that in case of the record generation is set hardware, the archive >> records are directly genereted by the hardware. So I assume, that my >> hardware emitts an archive record to often. >> As I have seen in the vantage protocol descriptin the archive data can be >> requested via the DMPAFT command and sending the timestamp of the last >> received archive record. >> I think somewhere is a slight different behaviour between my WeatherDuino >> and an original Davis device - because the developper of the WeatherDuino >> says the emulation is compatible with the original Davis software and >> nearly each other weather software. I can confirm this. >> Maybe it is necessary to use some kind of port sniffer to check the >> communication or do you know if there are additional debug outputs of the >> driver available. >> >> Best regards, >> engolling >> >> Am Dienstag, 19. März 2019 00:57:16 UTC+1 schrieb gjr80: >>> >>> On Tuesday, 19 March 2019 07:57:06 UTC+10, engolling wrote: >>>> >>>> Hi Gary, >>>> thanks for your patience. >>>> >>>> This is not normal operation. Because something it triggering an >>>>> archive record to be saved every few seconds the NEW_ARCHIVE_RECORD event >>>>> is also triggered which causes your service to fire as well. The issue >>>>> here >>>>
[weewx-user] Re: Add additional rain gauge via second data source
Hi Gary, I disabled my data service and the errors still were there. See the logfile in attachment. So I assumed that there is a problem with the vantage driver in combination with my hardware. So I changed in weewx.conf to # If possible, new archive records are downloaded from the station # hardware. If the hardware does not support this, then new archive # records will be generated in software. # Set the following to "software" to force software record generation. record_generation = software this solves the problem with the logging errors. With the "unable to add records" problem solved I finished my data service - also in attachment - which seems to be working now :). Back to the issue with the archive records - I read in the customization guide, that in case of the record generation is set hardware, the archive records are directly genereted by the hardware. So I assume, that my hardware emitts an archive record to often. As I have seen in the vantage protocol descriptin the archive data can be requested via the DMPAFT command and sending the timestamp of the last received archive record. I think somewhere is a slight different behaviour between my WeatherDuino and an original Davis device - because the developper of the WeatherDuino says the emulation is compatible with the original Davis software and nearly each other weather software. I can confirm this. Maybe it is necessary to use some kind of port sniffer to check the communication or do you know if there are additional debug outputs of the driver available. Best regards, engolling Am Dienstag, 19. März 2019 00:57:16 UTC+1 schrieb gjr80: > > On Tuesday, 19 March 2019 07:57:06 UTC+10, engolling wrote: >> >> Hi Gary, >> thanks for your patience. >> >> This is not normal operation. Because something it triggering an archive >>> record to be saved every few seconds the NEW_ARCHIVE_RECORD event is also >>> triggered which causes your service to fire as well. The issue here is not >>> your service but whatever is causing this archive record to be written >>> every few seconds. I suggest we step back a bit and get a clear picture of >>> how your system is configured and what it is running. >>> >> >> I was wondering where these errors where coming from and I already tried >> to get more information about it. I found somewhere a statement that is not >> too bad and might happen if a very narrow saving interval is used. But now >> I increasingly understand... >> > > Errors involving 'Unable to add record' are not good and are a sign > something is wrong, at the very least you are wasting processor time, > something you probably should avoid with such a short archive interval. A > short archive interval should not be the cause in itself > > On Tuesday, 19 March 2019 08:21:12 UTC+10, engolling wrote: > >> One more thing - I do not own a original davis station - I'm using a >> WeatherDuino, emulating a davis station for import of "standard" data. >> https://www.meteocercal.info/forum/index.php >> > > OK, not saying that is the issue but it is another complicating factor. > Your weewx.conf looks fine and I don't see anything in your service that > would be causing the archive record problem. Let's step right back to > basics and disable your service so that you have WeeWX running just the > vantage driver to talk the WeatherDuino. To do this: > > 1. edit weewx.conf, and change: > > [Engine] > > [[Services]] > # This section specifies the services that should be run. They are > # grouped by type, and the order of services within each group > # determines the order in which the services will be run. > prep_services = weewx.engine.StdTimeSynch > data_services = user.WeeWx_WeatherDuino_Logger_plugin.WeeWxService > , > process_services = weewx.engine.StdConvert, weewx.engine. > StdCalibrate, weewx.engine.StdQC, weewx.wxservices.StdWXCalculate > > to > > [Engine] > > [[Services]] > # This section specifies the services that should be run. They are > # grouped by type, and the order of services within each group > # determines the order in which the services will be run. > prep_services = weewx.engine.StdTimeSynch > data_services = , # > user.WeeWx_WeatherDuino_Logger_plugin.WeeWxService, > process_services = weewx.engine.StdConvert, weewx.engine. > StdCalibrate, weewx.engine.StdQC, weewx.wxservices.StdWXCalculate > > 2. save weewx.conf > > 3. restart WeeWX and let it run for 10 minutes or so then take a copy of > the log from when WeeWX was restarted and post it here, make sure yo
[weewx-user] Re: Add additional rain gauge via second data source
One more thing - I do not own a original davis station - I'm using a
WeatherDuino, emulating a davis station for import of "standard" data.
https://www.meteocercal.info/forum/index.php
My plan is to get some extra data out of my hardware wich can not be
transmitted via the LOOP packets e.g. the readings of a second rain gauge
like the RG11.
engolling
Am Montag, 18. März 2019 22:57:06 UTC+1 schrieb engolling:
>
> Hi Gary,
> thanks for your patience.
>
> This is not normal operation. Because something it triggering an archive
>> record to be saved every few seconds the NEW_ARCHIVE_RECORD event is also
>> triggered which causes your service to fire as well. The issue here is not
>> your service but whatever is causing this archive record to be written
>> every few seconds. I suggest we step back a bit and get a clear picture of
>> how your system is configured and what it is running.
>>
>
> I was wondering where these errors where coming from and I already tried
> to get more information about it. I found somewhere a statement that is not
> too bad and might happen if a very narrow saving interval is used. But now
> I increasingly understand...
>
> Now I have attached the output of wee_debug --info an excerpt of the
> syslog with debug option disabled and the lastest version of my
> WeatherDuino_Logger_plugin.
>
> Regards,
> engolling
>
>
> Am Montag, 18. März 2019 01:48:39 UTC+1 schrieb gjr80:
>>
>> On Monday, 18 March 2019 08:36:24 UTC+10, engolling wrote:
>>>
>>> Hi Gary,
>>>
>>> maybe I have found my problem after looking at my code and your advices
>>> again.
>>> Because it seems that I have bound my additional signals to the archive
>>> record and not to the LOOP packet
>>>
>>
>> There is nothing wrong with augmenting archive records. As I pointed out
>> in my first post there are two ways to add additional sensor data to WeeWX.
>> One approach is to augment the archive record and to do this your would
>> bind to NEW_ARCHIVE_RECORD. If you augment archive records you will not see
>> any of your data in loop packets, this is normal expected behaviour. The
>> other approach is to augment loop packets, to do this you must bind to
>> NEW_LOOP_PACKET. If you augment loop packets your should see your data in
>> loop packets and archive records. Note that if augmenting loop packets you
>> may not necessarily see your data in every loop packet, it depends on how
>> you implement your service. Neither approach is right or wrong, the
>> approach you use is what best suits you or your setup.
>>
>>
>>> class WeeWxService(StdService):
>>> def __init__(self, engine, config_dict):
>>> super(WeeWxService, self).__init__(engine, config_dict)
>>> d = config_dict.get('WeatherDuino_logger_service', {})
>>> self.filename = d.get('filename',
>>> '/home/pi/WeatherDuino/WeeWx_Exp.txt')
>>> syslog.syslog(syslog.LOG_INFO, "WeatherDuino: using %s" % self.
>>> filename)
>>> self.bind(weewx.NEW_ARCHIVE_RECORD, self.read_file)
>>> self.last_rain = []
>>>
>>>
>>>
>>> But the logfile tells me my plugin is executed in a frequency like the
>>> loop packets:
>>> Mar 17 23:22:19 WeatherDuinoPi weewx[7972]: WeatherDuino: Valid values
>>> found
>>> Mar 17 23:22:23 WeatherDuinoPi weewx[7972]: manager: Added record
>>> 2019-03-17 23:21:00 CET (1552861260) to database 'weewx.sdb'
>>> Mar 17 23:22:23 WeatherDuinoPi weewx[7972]: manager: Added record
>>> 2019-03-17 23:21:00 CET (1552861260) to daily summary in 'weewx.sdb'
>>> Mar 17 23:22:24 WeatherDuinoPi weewx[7972]: WeatherDuino: Valid values
>>> found
>>> Mar 17 23:22:27 WeatherDuinoPi weewx[7972]: manager: Unable to add
>>> record 2019-03-17 23:17:00 CET (1552861020) to database 'weewx.sdb': UNIQUE
>>> constraint failed: archive.dateTime
>>> Mar 17 23:22:27 WeatherDuinoPi weewx[7972]: WeatherDuino: Valid values
>>> found
>>> Mar 17 23:22:30 WeatherDuinoPi weewx[7972]: manager: Unable to add
>>> record 2019-03-17 23:18:00 CET (1552861080) to database 'weewx.sdb': UNIQUE
>>> constraint failed: archive.dateTime
>>> Mar 17 23:22:30 WeatherDuinoPi weewx[7972]: WeatherDuino: Valid values
>>> found
>>> Mar 17 23:22:33 WeatherDuinoPi weewx[7972]: manager: Unable to add
>>> record 2019-03-17 23:19:00 CET (1552861140) to database 'weewx.sdb': UNIQUE
>>> constraint failed: archive.dateTime
>>> Ma
[weewx-user] Re: Add additional rain gauge via second data source
Hi Gary,
thanks for your patience.
This is not normal operation. Because something it triggering an archive
> record to be saved every few seconds the NEW_ARCHIVE_RECORD event is also
> triggered which causes your service to fire as well. The issue here is not
> your service but whatever is causing this archive record to be written
> every few seconds. I suggest we step back a bit and get a clear picture of
> how your system is configured and what it is running.
>
I was wondering where these errors where coming from and I already tried to
get more information about it. I found somewhere a statement that is not
too bad and might happen if a very narrow saving interval is used. But now
I increasingly understand...
Now I have attached the output of wee_debug --info an excerpt of the syslog
with debug option disabled and the lastest version of my
WeatherDuino_Logger_plugin.
Regards,
engolling
Am Montag, 18. März 2019 01:48:39 UTC+1 schrieb gjr80:
>
> On Monday, 18 March 2019 08:36:24 UTC+10, engolling wrote:
>>
>> Hi Gary,
>>
>> maybe I have found my problem after looking at my code and your advices
>> again.
>> Because it seems that I have bound my additional signals to the archive
>> record and not to the LOOP packet
>>
>
> There is nothing wrong with augmenting archive records. As I pointed out
> in my first post there are two ways to add additional sensor data to WeeWX.
> One approach is to augment the archive record and to do this your would
> bind to NEW_ARCHIVE_RECORD. If you augment archive records you will not see
> any of your data in loop packets, this is normal expected behaviour. The
> other approach is to augment loop packets, to do this you must bind to
> NEW_LOOP_PACKET. If you augment loop packets your should see your data in
> loop packets and archive records. Note that if augmenting loop packets you
> may not necessarily see your data in every loop packet, it depends on how
> you implement your service. Neither approach is right or wrong, the
> approach you use is what best suits you or your setup.
>
>
>> class WeeWxService(StdService):
>> def __init__(self, engine, config_dict):
>> super(WeeWxService, self).__init__(engine, config_dict)
>> d = config_dict.get('WeatherDuino_logger_service', {})
>> self.filename = d.get('filename',
>> '/home/pi/WeatherDuino/WeeWx_Exp.txt')
>> syslog.syslog(syslog.LOG_INFO, "WeatherDuino: using %s" % self.
>> filename)
>> self.bind(weewx.NEW_ARCHIVE_RECORD, self.read_file)
>> self.last_rain = []
>>
>>
>>
>> But the logfile tells me my plugin is executed in a frequency like the
>> loop packets:
>> Mar 17 23:22:19 WeatherDuinoPi weewx[7972]: WeatherDuino: Valid values
>> found
>> Mar 17 23:22:23 WeatherDuinoPi weewx[7972]: manager: Added record
>> 2019-03-17 23:21:00 CET (1552861260) to database 'weewx.sdb'
>> Mar 17 23:22:23 WeatherDuinoPi weewx[7972]: manager: Added record
>> 2019-03-17 23:21:00 CET (1552861260) to daily summary in 'weewx.sdb'
>> Mar 17 23:22:24 WeatherDuinoPi weewx[7972]: WeatherDuino: Valid values
>> found
>> Mar 17 23:22:27 WeatherDuinoPi weewx[7972]: manager: Unable to add record
>> 2019-03-17 23:17:00 CET (1552861020) to database 'weewx.sdb': UNIQUE
>> constraint failed: archive.dateTime
>> Mar 17 23:22:27 WeatherDuinoPi weewx[7972]: WeatherDuino: Valid values
>> found
>> Mar 17 23:22:30 WeatherDuinoPi weewx[7972]: manager: Unable to add record
>> 2019-03-17 23:18:00 CET (1552861080) to database 'weewx.sdb': UNIQUE
>> constraint failed: archive.dateTime
>> Mar 17 23:22:30 WeatherDuinoPi weewx[7972]: WeatherDuino: Valid values
>> found
>> Mar 17 23:22:33 WeatherDuinoPi weewx[7972]: manager: Unable to add record
>> 2019-03-17 23:19:00 CET (1552861140) to database 'weewx.sdb': UNIQUE
>> constraint failed: archive.dateTime
>> Mar 17 23:22:33 WeatherDuinoPi weewx[7972]: WeatherDuino: Valid values
>> found
>>
>> According to your answers this should be the problem because in this case
>> I have to take care that the rain is only augmented once each minute, right?
>>
>
> I am not sure what is going on with your system but the log extract above
> shows that WeeWX is attempting to save an archive record every few seconds
> - refer to the following entries:
>
> Mar 17 23:22:27 WeatherDuinoPi weewx[7972]: manager: Unable to add record
> 2019-03-17 23:17:00 CET (1552861020) to database 'weewx.sdb': UNIQUE
> constraint failed: archive.dateTime
> Mar 17 23:22:30 WeatherDuinoPi weewx[7972]: manager: Unable to add record
> 2019-
[weewx-user] Re: Add additional rain gauge via second data source
Hi Gary,
maybe I have found my problem after looking at my code and your advices
again.
Because it seems that I have bound my additional signals to the archive
record and not to the LOOP packet
class WeeWxService(StdService):
def __init__(self, engine, config_dict):
super(WeeWxService, self).__init__(engine, config_dict)
d = config_dict.get('WeatherDuino_logger_service', {})
self.filename = d.get('filename',
'/home/pi/WeatherDuino/WeeWx_Exp.txt')
syslog.syslog(syslog.LOG_INFO, "WeatherDuino: using %s" % self.
filename)
self.bind(weewx.NEW_ARCHIVE_RECORD, self.read_file)
self.last_rain = []
But the logfile tells me my plugin is executed in a frequency like the loop
packets:
Mar 17 23:22:19 WeatherDuinoPi weewx[7972]: WeatherDuino: Valid values found
Mar 17 23:22:23 WeatherDuinoPi weewx[7972]: manager: Added record
2019-03-17 23:21:00 CET (1552861260) to database 'weewx.sdb'
Mar 17 23:22:23 WeatherDuinoPi weewx[7972]: manager: Added record
2019-03-17 23:21:00 CET (1552861260) to daily summary in 'weewx.sdb'
Mar 17 23:22:24 WeatherDuinoPi weewx[7972]: WeatherDuino: Valid values found
Mar 17 23:22:27 WeatherDuinoPi weewx[7972]: manager: Unable to add record
2019-03-17 23:17:00 CET (1552861020) to database 'weewx.sdb': UNIQUE
constraint failed: archive.dateTime
Mar 17 23:22:27 WeatherDuinoPi weewx[7972]: WeatherDuino: Valid values found
Mar 17 23:22:30 WeatherDuinoPi weewx[7972]: manager: Unable to add record
2019-03-17 23:18:00 CET (1552861080) to database 'weewx.sdb': UNIQUE
constraint failed: archive.dateTime
Mar 17 23:22:30 WeatherDuinoPi weewx[7972]: WeatherDuino: Valid values found
Mar 17 23:22:33 WeatherDuinoPi weewx[7972]: manager: Unable to add record
2019-03-17 23:19:00 CET (1552861140) to database 'weewx.sdb': UNIQUE
constraint failed: archive.dateTime
Mar 17 23:22:33 WeatherDuinoPi weewx[7972]: WeatherDuino: Valid values found
According to your answers this should be the problem because in this case I
have to take care that the rain is only augmented once each minute, right?
Should I change the binding to
self.bind(weewx.NEW_LOOP_PACKET, self.read_file)
?
Moreover I try to simplify my code as you have proposed, so I added the
last line in the init function (is it a function ?) of the class.
My idea was to make a empty list, which I can expand as I want because
there can be up to 4 rain values - is this a reasonable solution or do I
have to make a list with 4 entries at the beginning?
Thanks for all your help.
Best regards,
engolling
Am Sonntag, 17. März 2019 02:32:13 UTC+1 schrieb gjr80:
>
> OK, your archive schema appears fine, that rules out one variable. WeeWX
> services are loaded at WeeWX startup and are retained as long as WeeWX
> continues to run so any properties you add are retained. Have a go at
> simplifying your service then I suggest you run WeeWX directly
> <http://weewx.com/docs/usersguide.htm#Running_directly> so you can see
> the loop packets and archive records that are generated. It should be clear
> then what is/is not going on.
>
> Gary
>
> On Sunday, 17 March 2019 09:40:03 UTC+10, engolling wrote:
>>
>> Hello Gary,
>>
>>
>>
>> thanks fot your efforts. You are right with your description how my code
>> should work.
>>
>> Let's say my main problem is that I know how I construct software in
>> principle, but my python knowledgde is not very good, so in order to safe
>> the last cumulative rain value my only solution was to write it into a
>> file. Otherwise I tought the value might get lost between executing the
>> data service
>>
>>
>>
>> I will try to 'buffer' my last rain value in a variable as you describe
>> it and give you feedback.
>>
>>
>> But I still think WeeWx does not accumulate correctly in my case, because
>> im nearly 100% sure, that I have checked that my (indeed strange) code
>> emits the values correctly.
>>
>>
>> My schema looks like this - I think it is fine.
>>
>>> sqlite> .schema archive
>>> CREATE TABLE archive (`dateTime` INTEGER NOT NULL UNIQUE PRIMARY KEY,
>>> `usUnits` INTEGER NOT NULL, `interval` INTEGER NOT NULL, `barometer` REAL,
>>> `pressure` REAL, `altimeter` REAL, `inTemp` REAL, `outTemp` REAL,
>>> `inHumidity` REAL, `outHumidity` REAL, `windSpeed` REAL, `windDir` REAL,
>>> `windGust` REAL, `windGustDir` REAL, `rainRate` REAL, `rain` REAL,
>>> `dewpoint` REAL, `windchill` REAL, `heatindex` REAL, `ET` REAL, `radiation`
>>> REAL, `UV` REAL, `extraTemp1` REAL, `extraTemp2` REAL, `extraTemp3` REAL,
>>> `soilTemp1` REAL, `soilTemp2` REAL, `soilTemp3` REAL, `soilTemp4` REAL,
>>> `leafTemp1` REAL, `leafTemp2` REAL, `extraHu
[weewx-user] Re: Add additional rain gauge via second data source
Hi Gary,
maybe I have found my problem after looking at my code and your advices
again.
Because it seems that I have bound my additional signals to the archive
record and not to the LOOP packet
class WeeWxService(StdService):
def __init__(self, engine, config_dict):
super(WeeWxService, self).__init__(engine, config_dict)
d = config_dict.get('WeatherDuino_logger_service', {})
self.filename = d.get('filename',
'/home/pi/WeatherDuino/WeeWx_Exp.txt')
syslog.syslog(syslog.LOG_INFO, "WeatherDuino: using %s" %
self.filename)
self.bind(weewx.NEW_ARCHIVE_RECORD, self.read_file)
self.last_rain = []
But the logfile tells me my plugin is executed in a frequency like the loop
packets:
Mar 17 23:22:19 WeatherDuinoPi weewx[7972]: WeatherDuino: Valid values found
Mar 17 23:22:23 WeatherDuinoPi weewx[7972]: manager: Added record
2019-03-17 23:21:00 CET (1552861260) to database 'weewx.sdb'
Mar 17 23:22:23 WeatherDuinoPi weewx[7972]: manager: Added record
2019-03-17 23:21:00 CET (1552861260) to daily summary in 'weewx.sdb'
Mar 17 23:22:24 WeatherDuinoPi weewx[7972]: WeatherDuino: Valid values found
Mar 17 23:22:27 WeatherDuinoPi weewx[7972]: manager: Unable to add record
2019-03-17 23:17:00 CET (1552861020) to database 'weewx.sdb': UNIQUE
constraint failed: archive.dateTime
Mar 17 23:22:27 WeatherDuinoPi weewx[7972]: WeatherDuino: Valid values found
Mar 17 23:22:30 WeatherDuinoPi weewx[7972]: manager: Unable to add record
2019-03-17 23:18:00 CET (1552861080) to database 'weewx.sdb': UNIQUE
constraint failed: archive.dateTime
Mar 17 23:22:30 WeatherDuinoPi weewx[7972]: WeatherDuino: Valid values found
Mar 17 23:22:33 WeatherDuinoPi weewx[7972]: manager: Unable to add record
2019-03-17 23:19:00 CET (1552861140) to database 'weewx.sdb': UNIQUE
constraint failed: archive.dateTime
Mar 17 23:22:33 WeatherDuinoPi weewx[7972]: WeatherDuino: Valid values found
According to your answers this should be the problem because in this case I
have to take care that the rain is only augmented once each minute, right?
Should I change the binding to
self.bind(weewx.NEW_LOOP_PACKET, self.read_file)
?
Moreover I try to simplify my code as you have proposed, so I added the
last line in the init function (is it a function ?) of the class.
My idea was to make a empty list, which I can expand as I want because
there can be up to 4 rain values - is this a reasonable solution or do I
have to make a list with 4 entries at the beginning?
Thanks for all your help.
Best regards,
engolling
Am Sonntag, 17. März 2019 02:32:13 UTC+1 schrieb gjr80:
>
> OK, your archive schema appears fine, that rules out one variable. WeeWX
> services are loaded at WeeWX startup and are retained as long as WeeWX
> continues to run so any properties you add are retained. Have a go at
> simplifying your service then I suggest you run WeeWX directly
> <http://weewx.com/docs/usersguide.htm#Running_directly> so you can see
> the loop packets and archive records that are generated. It should be clear
> then what is/is not going on.
>
> Gary
>
> On Sunday, 17 March 2019 09:40:03 UTC+10, engolling wrote:
>>
>> Hello Gary,
>>
>>
>>
>> thanks fot your efforts. You are right with your description how my code
>> should work.
>>
>> Let's say my main problem is that I know how I construct software in
>> principle, but my python knowledgde is not very good, so in order to safe
>> the last cumulative rain value my only solution was to write it into a
>> file. Otherwise I tought the value might get lost between executing the
>> data service
>>
>>
>>
>> I will try to 'buffer' my last rain value in a variable as you describe
>> it and give you feedback.
>>
>>
>> But I still think WeeWx does not accumulate correctly in my case, because
>> im nearly 100% sure, that I have checked that my (indeed strange) code
>> emits the values correctly.
>>
>>
>> My schema looks like this - I think it is fine.
>>
>>> sqlite> .schema archive
>>> CREATE TABLE archive (`dateTime` INTEGER NOT NULL UNIQUE PRIMARY KEY,
>>> `usUnits` INTEGER NOT NULL, `interval` INTEGER NOT NULL, `barometer` REAL,
>>> `pressure` REAL, `altimeter` REAL, `inTemp` REAL, `outTemp` REAL,
>>> `inHumidity` REAL, `outHumidity` REAL, `windSpeed` REAL, `windDir` REAL,
>>> `windGust` REAL, `windGustDir` REAL, `rainRate` REAL, `rain` REAL,
>>> `dewpoint` REAL, `windchill` REAL, `heatindex` REAL, `ET` REAL, `radiation`
>>> REAL, `UV` REAL, `extraTemp1` REAL, `extraTemp2` REAL, `extraTemp3` REAL,
>>> `soilTemp1` REAL, `soilTemp2` REAL, `soilTemp3` REAL, `soilTemp4` REAL,
>>> `leafTemp1` REAL, `leafTemp2` REAL, `extraHu
[weewx-user] Re: Add additional rain gauge via second data source
Am Sonntag, 17. März 2019 02:32:13 UTC+1 schrieb gjr80: > > OK, your archive schema appears fine, that rules out one variable. WeeWX > services are loaded at WeeWX startup and are retained as long as WeeWX > continues to run so any properties you add are retained. Have a go at > simplifying your service then I suggest you run WeeWX directly > <http://weewx.com/docs/usersguide.htm#Running_directly> so you can see > the loop packets and archive records that are generated. It should be clear > then what is/is not going on. > > Gary > > On Sunday, 17 March 2019 09:40:03 UTC+10, engolling wrote: >> >> Hello Gary, >> >> >> >> thanks fot your efforts. You are right with your description how my code >> should work. >> >> Let's say my main problem is that I know how I construct software in >> principle, but my python knowledgde is not very good, so in order to safe >> the last cumulative rain value my only solution was to write it into a >> file. Otherwise I tought the value might get lost between executing the >> data service >> >> >> >> I will try to 'buffer' my last rain value in a variable as you describe >> it and give you feedback. >> >> >> But I still think WeeWx does not accumulate correctly in my case, because >> im nearly 100% sure, that I have checked that my (indeed strange) code >> emits the values correctly. >> >> >> My schema looks like this - I think it is fine. >> >>> sqlite> .schema archive >>> CREATE TABLE archive (`dateTime` INTEGER NOT NULL UNIQUE PRIMARY KEY, >>> `usUnits` INTEGER NOT NULL, `interval` INTEGER NOT NULL, `barometer` REAL, >>> `pressure` REAL, `altimeter` REAL, `inTemp` REAL, `outTemp` REAL, >>> `inHumidity` REAL, `outHumidity` REAL, `windSpeed` REAL, `windDir` REAL, >>> `windGust` REAL, `windGustDir` REAL, `rainRate` REAL, `rain` REAL, >>> `dewpoint` REAL, `windchill` REAL, `heatindex` REAL, `ET` REAL, `radiation` >>> REAL, `UV` REAL, `extraTemp1` REAL, `extraTemp2` REAL, `extraTemp3` REAL, >>> `soilTemp1` REAL, `soilTemp2` REAL, `soilTemp3` REAL, `soilTemp4` REAL, >>> `leafTemp1` REAL, `leafTemp2` REAL, `extraHumid1` REAL, `extraHumid2` REAL, >>> `soilMoist1` REAL, `soilMoist2` REAL, `soilMoist3` REAL, `soilMoist4` REAL, >>> `leafWet1` REAL, `leafWet2` REAL, `rxCheckPercent` REAL, `txBatteryStatus` >>> REAL, `consBatteryVoltage` REAL, `hail` REAL, `hailRate` REAL, >>> `heatingTemp` REAL, `heatingVoltage` REAL, `supplyVoltage` REAL, >>> `referenceVoltage` REAL, `windBatteryStatus` REAL, `rainBatteryStatus` >>> REAL, `outTempBatteryStatus` REAL, `inTempBatteryStatus` REAL, >>> `AVG_Rcv_RX0` REAL, `AVG_Rcv_RX1` REAL, `AVG_Rcv_RX2` REAL, `BatVolt_0` >>> REAL, `SysTemp_0` REAL, `Rsfan_0` REAL, `PacketsSentPerHour_0` REAL, >>> `Snow_Height` REAL, `BatVolt_1` REAL, `SysTemp_1` REAL, `Rsfan_1` REAL, >>> `PacketsSentPerHour_1` REAL, `BatVolt_2` REAL, `SysTemp_2` REAL, `Rsfan_2` >>> REAL, `PacketsSentPerHour_2` REAL, `Soil_Temp_Full1` REAL, >>> `Soil_Temp_Full2` REAL, `Soil_Temp_Full3` REAL, `Soil_Temp_Full4` REAL, >>> `AQI_PM1_0` REAL, `AQI_PM2_5` REAL, `AQI_PM10_0` REAL, `AQI_Index` REAL, >>> `AQI_Temp` REAL, `AQI_Hum` REAL, `CO2` REAL, `GAS_2` REAL, `WiFi_T0` REAL, >>> `WiFi_H0` REAL, `Signal_Quality_TX0` REAL, `Signal_Quality_TX1` REAL, >>> `Signal_Quality_TX2` REAL, `Rain_RG11` REAL, `Rain_Rate_RG11` REAL, >>> `Rain_TX2` REAL, `Rain_Rate_TX2` REAL); >>> >> >> Thank you, >> engolling >> >> Am Samstag, 16. März 2019 07:44:10 UTC+1 schrieb gjr80: >>> >>> Hi, >>> >>> I had a look through your code and I think you have made things overly >>> complex for yourself. As I understand your setup you have a file, >>> /home/pi/WeatherDuino/WeeWx_Exp.txt, that contains your WeatherDuino >>> data, there are three rows of semicolon separated data, the rows being >>> labels/names, units and values. One of those fields is a cumulative rain >>> value. You also use the file /home/pi/WeatherDuino/Rain_tmp.txt that >>> you use in an elaborate arrangement to read and save the last cumulative >>> rain value and you obtain the delta rain value by taking the difference >>> between the current cumulative rain value and the value read from >>> /home/pi/WeatherDuino/Rain_tmp.txt. >>> >>> The logic appears to be sound but you are going about it in a very >>> complex manner and I suspect that is tripping you up. The need to deter
[weewx-user] Re: Add additional rain gauge via second data source
Hello Gary, thanks fot your efforts. You are right with your description how my code should work. Let's say my main problem is that I know how I construct software in principle, but my python knowledgde is not very good, so in order to safe the last cumulative rain value my only solution was to write it into a file. Otherwise I tought the value might get lost between executing the data service I will try to 'buffer' my last rain value in a variable as you describe it and give you feedback. But I still think WeeWx does not accumulate correctly in my case, because im nearly 100% sure, that I have checked that my (indeed strange) code emits the values correctly. My schema looks like this - I think it is fine. > sqlite> .schema archive > CREATE TABLE archive (`dateTime` INTEGER NOT NULL UNIQUE PRIMARY KEY, > `usUnits` INTEGER NOT NULL, `interval` INTEGER NOT NULL, `barometer` REAL, > `pressure` REAL, `altimeter` REAL, `inTemp` REAL, `outTemp` REAL, > `inHumidity` REAL, `outHumidity` REAL, `windSpeed` REAL, `windDir` REAL, > `windGust` REAL, `windGustDir` REAL, `rainRate` REAL, `rain` REAL, > `dewpoint` REAL, `windchill` REAL, `heatindex` REAL, `ET` REAL, `radiation` > REAL, `UV` REAL, `extraTemp1` REAL, `extraTemp2` REAL, `extraTemp3` REAL, > `soilTemp1` REAL, `soilTemp2` REAL, `soilTemp3` REAL, `soilTemp4` REAL, > `leafTemp1` REAL, `leafTemp2` REAL, `extraHumid1` REAL, `extraHumid2` REAL, > `soilMoist1` REAL, `soilMoist2` REAL, `soilMoist3` REAL, `soilMoist4` REAL, > `leafWet1` REAL, `leafWet2` REAL, `rxCheckPercent` REAL, `txBatteryStatus` > REAL, `consBatteryVoltage` REAL, `hail` REAL, `hailRate` REAL, > `heatingTemp` REAL, `heatingVoltage` REAL, `supplyVoltage` REAL, > `referenceVoltage` REAL, `windBatteryStatus` REAL, `rainBatteryStatus` > REAL, `outTempBatteryStatus` REAL, `inTempBatteryStatus` REAL, > `AVG_Rcv_RX0` REAL, `AVG_Rcv_RX1` REAL, `AVG_Rcv_RX2` REAL, `BatVolt_0` > REAL, `SysTemp_0` REAL, `Rsfan_0` REAL, `PacketsSentPerHour_0` REAL, > `Snow_Height` REAL, `BatVolt_1` REAL, `SysTemp_1` REAL, `Rsfan_1` REAL, > `PacketsSentPerHour_1` REAL, `BatVolt_2` REAL, `SysTemp_2` REAL, `Rsfan_2` > REAL, `PacketsSentPerHour_2` REAL, `Soil_Temp_Full1` REAL, > `Soil_Temp_Full2` REAL, `Soil_Temp_Full3` REAL, `Soil_Temp_Full4` REAL, > `AQI_PM1_0` REAL, `AQI_PM2_5` REAL, `AQI_PM10_0` REAL, `AQI_Index` REAL, > `AQI_Temp` REAL, `AQI_Hum` REAL, `CO2` REAL, `GAS_2` REAL, `WiFi_T0` REAL, > `WiFi_H0` REAL, `Signal_Quality_TX0` REAL, `Signal_Quality_TX1` REAL, > `Signal_Quality_TX2` REAL, `Rain_RG11` REAL, `Rain_Rate_RG11` REAL, > `Rain_TX2` REAL, `Rain_Rate_TX2` REAL); > Thank you, engolling Am Samstag, 16. März 2019 07:44:10 UTC+1 schrieb gjr80: > > Hi, > > I had a look through your code and I think you have made things overly > complex for yourself. As I understand your setup you have a file, > /home/pi/WeatherDuino/WeeWx_Exp.txt, that contains your WeatherDuino > data, there are three rows of semicolon separated data, the rows being > labels/names, units and values. One of those fields is a cumulative rain > value. You also use the file /home/pi/WeatherDuino/Rain_tmp.txt that you > use in an elaborate arrangement to read and save the last cumulative rain > value and you obtain the delta rain value by taking the difference between > the current cumulative rain value and the value read from > /home/pi/WeatherDuino/Rain_tmp.txt. > > The logic appears to be sound but you are going about it in a very complex > manner and I suspect that is tripping you up. The need to determine delta > rain from a stream of cumulative rain values is common in many WeeWX > drivers. the approach taken in theses drivers is to create a property, > let's call it last_rain that is initialised to None in the drivers > __init__(). Then when the driver obtains a cumulative rain value, let's > call it cumulative_rain, there is a simple check whether last_rain is None, > if it is then delta_rain is set to None, if last_rain is not None the > delta_rain is set to cumulative_rain - last_rain. Finally last_rain is > set to cumulative_rain. In code it might look like this: > > > class SomeDriver(): > > def __init__(): > > self.last_rain = None > > > def get_delta_rain(cumulative_rain): > > if self.last_rain is not None: > delta_rain = cumulative_rain - self.last_rain > else: > delta_rain =None > self.last_rain = cumulative_rain > return delta_rain > > I have left a lot of things out there but the point was to illustrate the > overall logic and structure. By using the last_rain property there is no > need to write temporary values to file; your code is a lot neater,
[weewx-user] Re: Add additional rain gauge via second data source
Hi Gary, thanks for your very interesting reply. I tried to augment my extra data to the NEW_LOOP_PACKET, whichs works in priciple for all my data except the rain delta. As I mentioned it seems that the rain delta values are getting sorted out somehow. You can find the code here: https://github.com/menachers/WeatherDuino/tree/master/WeeWx_Plugin and an excerpt of my weewx.conf in an earlier post. So if I hardcode a deltarain of 0.1[in] it sums up correctly with each archive record - so after 5 minutes I get a total rain of 0.5[in]. If it is augmented to one loop packet (beeing emitted aproximatly every 3 seconds) i can also see it in the live display of the loop packet, but it can not be found in the archive record. So it seems that is is not accumulated internaly. Best regards, engolling Am Freitag, 15. März 2019 06:09:09 UTC+1 schrieb gjr80: > > Hi, > > When using a data service to add data to WeeWX you have two choices, you > either add your data to the archive records or you add your data to the > loop packets. Either way will work. If you decide that your data service is > to augment archive records with your rainfall data then your data service > must (1) bind to the event NEW_ARCHIVE_RECORD and (2) add the total > rainfall seen by your sensor during that archive period (in your case that > is the last 1 minute) to the archive record. If you decide your data > service is to augment the loop packets then your service must (1) bind to > the NEW_LOOP_PACKET event and (2) add the total rainfall seen since the > last loop packet you augmented to the loop packet concerned. Note that you > do not need to add your data to every loop packet, you can add it to > whichever loop packets you wish, but the value you add must be the total > rainfall since the last loop packet you augmented. The WeeWX internal > machinery will then take care of accumulating the loop data and your > accumulated data will appear in the archive record generated by WeeWX. > > Which way you decide to go is up to you. If you decide to augment the > archive record then your service would need to (in your case) obtain the > total rainfall for each 1 minute archive period, this may or may not be > easy depending on your hardware. The key here is you need to stick to the > archive period. If you decide to augment loop packets you can augment > whenever you want, you can skip loop packets if you want as long as you > stick to the rule of providing total rainfall since you last augmented a > loop packet. The loop packet approach is probably simpler, you just add > data when ever you can/want; you are not forced to rigidly stick to a fixed > interval as you are with the archive approach. > > In terms of saving data to the archive there are two conditions that must > be met. Firstly, the field/data you wish to save must appear in the WeeWX > generated archive record (you can see the WeeWX generated loop packets and > archive records by running weeWX directly > <http://weewx.com/docs/usersguide.htm#Running_directly>). Secondly, your > archive table schema must contain a field with the same name as the field > of interest in the archive record. So if your service added a field named > 'rain2' to the archive records (or loop packets) and the archive table your > WeeWX database had a field named 'rain2', then WeeWX would automatically > save your rain2 data to the archive. The steps involved in changing your > schema are covered in the Customization Guide > <http://weewx.com/docs/customizing.htm> under Adding a new type to the > database <http://weewx.com/docs/customizing.htm#add_archive_type>. Note > there are other approaches to saving new data to archive (eg creating a > second database) but these approaches are usually more complex or more > involved so I have ignored them in this case. > > You might also find that posting your code may help as that way we can see > exactly what you are/are not doing. > > Gary > > On Friday, 15 March 2019 08:45:03 UTC+10, engolling wrote: >> >> Short update: >> I have found out that my plugin is executed via data_services each time a >> loop package is generated and this is approximatly every 3 seconds. >> An archive dataset is written every 60 seconds, leading to chance of 1/20 >> that the raindelta is saved correctly - thats too less :-D >> >> So I see two possible solutions: >> 1. The data service is only executed once before the archiv dataset is >> written. Has anybody a idea how this could be done? >> >> 2. I have access to some kind of software flag saying that a archive >> record has been written. >> >> I had also a look into the vantage driver and I think this piece of c
[weewx-user] Re: Add additional rain gauge via second data source
Short update: I have found out that my plugin is executed via data_services each time a loop package is generated and this is approximatly every 3 seconds. An archive dataset is written every 60 seconds, leading to chance of 1/20 that the raindelta is saved correctly - thats too less :-D So I see two possible solutions: 1. The data service is only executed once before the archiv dataset is written. Has anybody a idea how this could be done? 2. I have access to some kind of software flag saying that a archive record has been written. I had also a look into the vantage driver and I think this piece of code does the magic of calculating the data: # Because the Davis stations do not offer bucket tips in LOOP data, we # must calculate it by looking for changes in rain totals. This won't # work for the very first rain packet. if self.save_monthRain is None: delta = None else: delta = loop_packet['monthRain'] - self.save_monthRain # If the difference is negative, we're at the beginning of a month. if delta < 0: delta = None loop_packet['rain'] = delta self.save_monthRain = loop_packet['monthRain'] return loop_packet But I do not understand how overwriting the delta is prevented here. Hoping for some replys. Best wishes, engolling Am Sonntag, 3. März 2019 13:16:49 UTC+1 schrieb engolling: > > Hello, > I tried to implement a driver providing the rainfall in intervall but > until now it does not work as expected. > > I'am able to handle the correct data to WeeWx with this command: > syslog.syslog(syslog.LOG_DEBUG, "WeatherDuino: " + > str(names[n+1]) + ": " + str(deltarain)) > event.record[str(names[n+1])] = float(deltarain) > The debug log output says: > >> Mar 3 11:56:16 WeatherDuinoPi weewx[1366]: WeatherDuino: Rain_RG11: >> 0.17716535433 >> > > But in the database there is a "0" logged. > > If i change the code hardcoding the rain intervall to 10 it works fine. > syslog.syslog(syslog.LOG_DEBUG, "WeatherDuino: " + > str(names[n+1]) + ": " + str(10)) > event.record[str(names[n+1])] = 10 > > So I think my driver is executed more often then my one minute logging > intervall and so the value of the event.record is overwritten with a zero > again - because the driver thinks the value is already in the WeeWx > database. > > You can find my code here: > https://github.com/menachers/WeatherDuino/tree/master/WeeWx_Plugin > > It is embedded in the weewx.conf: > # This section configures the internal weewx engine. > > [Engine] > > [[Services]] > # This section specifies the services that should be run. They are > # grouped by type, and the order of services within each group > # determines the order in which the services will be run. > prep_services = weewx.engine.StdTimeSynch > data_services = user.WeeWx_WeatherDuino_Logger_plugin.WeeWxService > , > process_services = weewx.engine.StdConvert, weewx.engine. > StdCalibrate, weewx.engine.StdQC, weewx.wxservices.StdWXCalculate > archive_services = weewx.engine.StdArchive > restful_services = weewx.restx.StdStationRegistry, weewx.restx. > StdWunderground, weewx.restx.StdPWSweather, weewx.restx.StdCWOP, weewx. > restx.StdWOW, weewx.restx.StdAWEKAS > report_services = weewx.engine.StdPrint, weewx.engine.StdReport > > Regards, > engolling > > > Am Samstag, 23. Februar 2019 14:10:36 UTC+1 schrieb Andrew Milner: >> >> weewx requires rain during archive interval for storing in the database >> archive records. A driver may have to convert whatever it receives (eg >> running total) so as to obtain the value for the interval. Daily is >> accumulated by weewx from the archive interval values and weekly and >> monthly are derived form the daily totals. This is possibly an over >> simplification - but should give the idea. >> >> so if the second source gives a value for rainfall in interval it should >> be enough for weewx to derive the remainder. >> >> >> >> On Saturday, 23 February 2019 12:30:38 UTC+2, engolling wrote: >>> >>> Hello community, >>> >>> I would like to add an additional rain gauge as additional source >>> described in the customization guide. >>> Can you give me any hints how to do this the easiest way, to get the >>> daily, weekly and monthly percipation. >>> Can I use any modules or calculations that are already done inside the >>> system or is t
[weewx-user] Re: Add additional rain gauge via second data source
Hello, I tried to implement a driver providing the rainfall in intervall but until now it does not work as expected. I'am able to handle the correct data to WeeWx with this command: syslog.syslog(syslog.LOG_DEBUG, "WeatherDuino: " + str(names[n+1]) + ": " + str(deltarain)) event.record[str(names[n+1])] = float(deltarain) The debug log output says: > Mar 3 11:56:16 WeatherDuinoPi weewx[1366]: WeatherDuino: Rain_RG11: > 0.17716535433 > But in the database there is a "0" logged. If i change the code hardcoding the rain intervall to 10 it works fine. syslog.syslog(syslog.LOG_DEBUG, "WeatherDuino: " + str(names[n+1]) + ": " + str(10)) event.record[str(names[n+1])] = 10 So I think my driver is executed more often then my one minute logging intervall and so the value of the event.record is overwritten with a zero again - because the driver thinks the value is already in the WeeWx database. You can find my code here: https://github.com/menachers/WeatherDuino/tree/master/WeeWx_Plugin It is embedded in the weewx.conf: # This section configures the internal weewx engine. [Engine] [[Services]] # This section specifies the services that should be run. They are # grouped by type, and the order of services within each group # determines the order in which the services will be run. prep_services = weewx.engine.StdTimeSynch data_services = user.WeeWx_WeatherDuino_Logger_plugin.WeeWxService, process_services = weewx.engine.StdConvert, weewx.engine. StdCalibrate, weewx.engine.StdQC, weewx.wxservices.StdWXCalculate archive_services = weewx.engine.StdArchive restful_services = weewx.restx.StdStationRegistry, weewx.restx. StdWunderground, weewx.restx.StdPWSweather, weewx.restx.StdCWOP, weewx.restx .StdWOW, weewx.restx.StdAWEKAS report_services = weewx.engine.StdPrint, weewx.engine.StdReport Regards, engolling Am Samstag, 23. Februar 2019 14:10:36 UTC+1 schrieb Andrew Milner: > > weewx requires rain during archive interval for storing in the database > archive records. A driver may have to convert whatever it receives (eg > running total) so as to obtain the value for the interval. Daily is > accumulated by weewx from the archive interval values and weekly and > monthly are derived form the daily totals. This is possibly an over > simplification - but should give the idea. > > so if the second source gives a value for rainfall in interval it should > be enough for weewx to derive the remainder. > > > > On Saturday, 23 February 2019 12:30:38 UTC+2, engolling wrote: >> >> Hello community, >> >> I would like to add an additional rain gauge as additional source >> described in the customization guide. >> Can you give me any hints how to do this the easiest way, to get the >> daily, weekly and monthly percipation. >> Can I use any modules or calculations that are already done inside the >> system or is this normally done by the corresponding driver, so I have to >> handle all the signals precalculated. >> >> I hope you understand what I mean. >> >> Best Regards, >> engolling >> > -- 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] Add additional rain gauge via second data source
Hello community, I would like to add an additional rain gauge as additional source described in the customization guide. Can you give me any hints how to do this the easiest way, to get the daily, weekly and monthly percipation. Can I use any modules or calculations that are already done inside the system or is this normally done by the corresponding driver, so I have to handle all the signals precalculated. I hope you understand what I mean. Best Regards, engolling -- 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: Behaviour when adding a second data source
Hi Gary, thank you for your detailed explanation. Everything's clear for me so far. I think it would be nice to add a sentence concerning this in the customization guide. engolling -- 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] Behaviour when adding a second data source
Hello,
I added a second data source to my WeeWx installation on RPI as it is
explained in the customization guide.
My database is metric.
So I imported a temperature 'AQM_Temp' in degree Celsius and a snow height
'Snow_height' in cm.
I assinged the 'group_temperature' as unit group to the signal 'AQM_Temp'
and defined the following new unit group for the snow height:
#Define unit groups which are not already defined
weewx.units.USUnits['group_snow_height'] = 'inch1'
weewx.units.MetricUnits['group_snow_height'] = 'cm1'
weewx.units.MetricWXUnits['group_snow_height'] = 'cm1'
weewx.units.default_unit_format_dict['inch1'] = '%.0f'
weewx.units.default_unit_label_dict['inch1'] = ' in'
weewx.units.default_unit_format_dict['cm1'] = '%.0f'
weewx.units.default_unit_label_dict['cm1'] = ' cm'
weewx.units.conversionDict['inch1'] = {'cm1': lambda x : x * 2.54}
weewx.units.conversionDict['cm1'] = {'inch1': lambda x : x * 0.394}
The signal 'AQM_Temp' is automatically converted from deg Farenheit to
Celsius, so from US unit to METRIC unit.
The signal 'Snow_height" is not converted at all and still is in cm after
importing it.
Even if I define a new unit group 'group_temperature2' with all the
conversion rules the signal 'AQM_Temp' is automatically converted to deg
Celsius (with the specified conversion calculation).
If I convert 'AQM_Temp' in deg Farenheit first and leave 'Snow_height' in
Celsius everything is fine even when assigning the unit group
'group_temperature'
I do not understand how WeeWx can seperate between those two signals and
why is is behaving different.
Maybe sombody has an idea.
Regards,
engolling
--
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.
