StdCalibrate - sequence lost in [[Corrections]] ?

[Graham Eddy]

i apply some rules in [[Corrections]] that depend upon the order they are executed

looking at the code in StdCalibrate (around lines 359-363 in weewx.engine) i see the sequencing from ‘correction_dict.scalars' would be lost when placed in simple dictionary ‘corrections'. i also see that the corrections are not applied in a deterministic sequence (line 374). so my dependency upon the sequence seems to be screwed...

assuming my interpretation is correct - that rule execution sequence under [[Corrections]] is not determinsitic - my workaround is to sort the data_type keys when the rules are being applied i.e. line 374

#GJE        for obs_type in self.corrections:

        for obs_type in sorted(self.corrections):

this is just a workaround to give me determinism so i can devise rules that work predictably, but the real answer is preserving the original sequencing

i have weewx clone but not fork so can’t submit a pull request. i don’t think i would for this workaround anyway...

[Tom Keffer]

Because types of ConfigObj are ordered dictionaries, we can use that. Add this to the list of imports in engine.py

import configobj

then change this

self.corrections = {}

to this

self.corrections = configobj.ConfigObj()

See if that works.

-tk

--
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/C09CFFD7-BDB4-48B6-A009-C841D2D79B09%40gmail.com.

[Graham Eddy]

OrderedDict or stick to ConfigObj ?

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/CAPq0zEDZm898HdSFqEUFrx%2Bj9uTa6FRcaGAs8zKK%3DyoDMwgarA%40mail.gmail.com.

[Tom Keffer]

One could use OrderedDict, but it would be the only use anywhere in weewx. By using ConfigObj, we avoid pulling in the collections module.

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/852B1D30-30F8-4EE2-AA44-4F358E32607A%40gmail.com.

[Graham Eddy]

that make sense

yes it does preserve the order, so i’m happy

in so doing i picked up a config bug of my own that has been puzzling me: the above test showed an obs_type of “altRain *”. <sound of hand smacks forehead> i can’t do ‘altRain *= 1.12’, it has to be ‘altRain = altRain * 1.12’. now i know why this weird ‘altRain *’ data_type starting appearing in my packets…

(i measured my brand new GW1000’s WH40 rain gauge three times by hand with up to 500ml and that’s the under-reading i got consistently)

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/CAPq0zEBin3txnXQsFtfqy2xzq%2BgGcKxxFSzgQeUi-MfN%3DtYkmQ%40mail.gmail.com.

[Tom Keffer]

LOL!

You got the error because the option is a ConfigObj mapping assignment, not a general Python expression. Only the right-hand side of the option gets compiled.

-tk

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/AEEB0584-7F79-4B1F-9169-FF66957C6C0A%40gmail.com.

[Graham Eddy]

so i discovered when i looked at the code. and i discovered OrderedDict at the same time, so it was a productive time-spend

and we can’t blame the rain gauge under-read on water draining in the reverse direction in southern hemisphere

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/CAPq0zECFmA0TOTPOqTCAhr8ArEvmhzxuCjgv%3DDhp73Xu0k6s1g%40mail.gmail.com.