And honestly: I'm really glad you consider the expressions complicated. For me, they were. I needed to write a test to figure them out :D Tom Keffer schrieb am Sonntag, 10. März 2024 um 16:24:35 UTC+1:
> Honestly, with an expression that complicated, I would write a simple > WeeWX service. > > On Sun, Mar 10, 2024 at 3:51 AM '[email protected]' via weewx-user < > [email protected]> wrote: > >> This one seems way better: >> [StdCalibrate] >> >> [[Corrections]] >> windSpeed = ws90_windSpeed if 'windSpeed' not in locals() else >> windSpeed if 'ws90_windSpeed' not in locals() else ws90_windSpeed if >> ws90_windSpeed > windSpeed else windSpeed >> windGust = ws90_windGust if 'windGust' not in locals() else >> windGust if 'ws90_windGust' not in locals() else ws90_windGust if >> ws90_windGust > windGust else windGust >> windDir = ws90_windDir if 'ws90_windDir' in locals() and >> ws90_windDir is not None else windDir >> [email protected] schrieb am Samstag, 9. März 2024 um 08:37:01 UTC+1: >> >>> Anyway, thank you for helping me with this one! >>> >>> For the record: >>> >>> I have two pieces of hardware, one is using a classic anemometer with >>> cups, the other one is an ultrasonic device. With very low wind speeds, the >>> classic one shows zero wind, while the ultrasonic one shows low, but very >>> plausible values. The ultrasonic one also doesn't freeze or gets blocked by >>> snow, because is has a heating. On the other hand, the ultrasonic device >>> often misses wind gusts and lacks accuracy in wet conditions. >>> In short, the closes approach to represent reality is: always use the >>> values from the sensor, which is showing the higher reading. >>> Also, the Wind direction of the ultrasonic device has a better >>> resolution and no vane that sometimes doesn't move, even in wind speeds, >>> the classic anemometer is rotating. >>> So the second thing is: always use windDir from the ultrasonic device. >>> >>> Both readings arrive in the same loop packet, their names are >>> "windSpeed" and "ws90_windSpeed" (the latter ultrasonic), together with >>> their gust speed and direction, except for situations, the sensor's data >>> cannot be received by the console. So my first approach >>> >>> [StdCalibrate] >>> [[Corrections]] >>> windSpeed = ws90_windSpeed if ws90 if ws90_windSpeed > >>> windSpeed else windSpeed >>> windGust = ws90_windGust if ws90_windGust > windGust else >>> windGust >>> windDir = ws90_windDir if ws90_windDir is not None else windDir >>> >>> is working, but only in cases, both of the readings are present. >>> >>> Yesterday, windSpeed (from the classic device) was missing, where >>> ws90_windSpeed was there. The result was, no windSpeed was recorded as at >>> all, due to a python NameError, which was silently ignored. >>> >>> try: >>> event.record[obs_type] = eval(self.corrections[obs_type], {'math': math >>> }, >>> event.record) >>> except (TypeError, NameError): >>> pass >>> >>> So, if this should work as intended, we need to check if windSpeed is >>> there, or not. >>> >>> What I want is to >>> >>> - store whatever wind speed/gust is the higher, if both are present >>> - store whatever wind speed/gust, when only one is present >>> - store the ultrasonic wind direction if present, or else the other >>> one >>> >>> For now, I use these expressions, and the loop packets look good, and >>> there shouldn't be a need to check for both being present: >>> >>> [StdCalibrate] >>> >>> [[Corrections]] >>> # For each type, an arbitrary calibration expression can be >>> given. >>> # It should be in the units defined in the StdConvert section. >>> # Example: >>> #foo = foo + 0.2 >>> windSpeed = ws90_windSpeed if 'windSpeed' not in locals() or >>> ws90_windSpeed > windSpeed else windSpeed >>> windGust = ws90_windGust if 'windGust' not in locals() or >>> ws90_windGust > windGust else windGust >>> windDir = ws90_windDir if 'ws90_windDir' in locals() and >>> ws90_windDir is not None else windDir >>> >>> I think this way I think I get my desired results, but after a long week >>> my brain is a bit overloaded. So if anybody with cognitive capacities left >>> could check if my expressions really make that much sense: very much >>> appreciated :) >>> >>> [email protected] schrieb am Samstag, 9. März 2024 um 08:15:24 UTC+1: >>> >>>> Actually >>>> >>>> *outTemp = 44 if outTemp in locals() else None* >>>> >>>> >>>> yields *None* when *outTemp * is there. >>>> >>>> Since we are looking for the key '*outTemp' *and not it's value, our >>>> expression needs to be: >>>> >>>> *outTemp = 44 if 'outTemp' in locals() else None* >>>> >>>> >>>> >>>> Tom Keffer schrieb am Samstag, 9. März 2024 um 03:22:24 UTC+1: >>>> >>>>> The facility uses the Python function eval >>>>> <https://docs.python.org/3/library/functions.html#eval>. A dictionary >>>>> with key 'math' and value the math module is passed in for *globals*. >>>>> The record is passed in for *locals*. So, you could use the expression >>>>> >>>>> *outTemp = 44 if outTemp in locals() else None* >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, Mar 8, 2024 at 3:33 PM Graham Eddy <[email protected]> wrote: >>>>> >>>>>> oops, python syntax would be: expr if ops_tye in globals() else None >>>>>> *⊣GE⊢* >>>>>> >>>>>> On 9 Mar 2024, at 10:31 am, Graham Eddy <[email protected]> wrote: >>>>>> >>>>>> i think ' if obs_type in globals() then expr else None ' would work >>>>>> *⊣GE⊢* >>>>>> >>>>>> On 9 Mar 2024, at 9:13 am, '[email protected]' via weewx-user < >>>>>> [email protected]> wrote: >>>>>> >>>>>> I think I remember that this has been asked before, how to check with >>>>>> an expression in Corrections, if an obs_type is present? >>>>>> >>>>>> -- >>>>>> 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 [email protected]. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/weewx-user/ae1bbcf8-23b1-475e-8749-62286df24fb0n%40googlegroups.com >>>>>> >>>>>> <https://groups.google.com/d/msgid/weewx-user/ae1bbcf8-23b1-475e-8749-62286df24fb0n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "weewx-user" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> >>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/weewx-user/0507D046-7EED-4A96-8F28-038B70BECEC7%40geddy.au >>>>>> >>>>>> <https://groups.google.com/d/msgid/weewx-user/0507D046-7EED-4A96-8F28-038B70BECEC7%40geddy.au?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- >> You received this message because you are subscribed to the Google Groups >> "weewx-user" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/weewx-user/bb81e928-8b6f-4e1c-92d5-e430a38cb6aen%40googlegroups.com >> >> <https://groups.google.com/d/msgid/weewx-user/bb81e928-8b6f-4e1c-92d5-e430a38cb6aen%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/28313204-f9ed-4143-b841-24da96e871edn%40googlegroups.com.
