Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch to force kph for weather stations #2846

Open
nitrogen76 opened this issue Feb 22, 2024 · 6 comments
Open

Switch to force kph for weather stations #2846

nitrogen76 opened this issue Feb 22, 2024 · 6 comments

Comments

@nitrogen76
Copy link

nitrogen76 commented Feb 22, 2024

it'd be nice if we had a switch to force wind speed reporting in kph, vs m/s

I just acquired a Fineoffset WS90, which reports wind in m/s, but I have an additional weather station that reports to kph.

I hacked up the source to do this for me, but it'd be nice if everything could be forced the same

EDIT: I Also noticed that the "customary" switch doesn't convert m/s on this weather station to mph.

@zuckschwerdt
Copy link
Collaborator

That needs to be cleaned up indeed. There are still _mph and _kph conversions that are not used anymore (keys are always _mi_h and _km_h).
As you noticed there is no m_s conversion. What is the customary equivalent?

We don't have and km_hvs m_s conversions and it is not clear how we could support that, or if we should even do that (rtl_433 tries it's best to report values in the units supplied by the sensor).

@nitrogen76
Copy link
Author

Customary equiv would be feet per second.

I ended up just modifying the code on my own to do what I needed. It still would be nice to be able to convert from different SI units so everything could be consistent if you needed it to be. Looks like r_api.c does conversions between things like Celsius to Fahrenheit, possibly some code in here plus an additional switch in RTL_433.c might do it.

I'm not much of a c programmer, but I might take a crack at it unless someone who knows what they're doing a lot more than I do wants to.

@zuckschwerdt
Copy link
Collaborator

Problem might be that we want the conversion and then the additional scale change on top. The logic is not that straigt forward. And we'd need four cases: force to km/h, m/s mp/h, ft/s -- or maybe just two (force to h or s) combined with si and customary.

@nitrogen76
Copy link
Author

Gotcha. After digging into this last night, I see what you mean (and it appears you wrote or worked on a lot of that code so you would have known better than me anyway)

For now I will probably just stay with my easier fix of hard coding the conversion in the device file, but would it be nice if something like this was at least on the roadmap to be implemented properly one day.

@ProfBoc75
Copy link
Collaborator

Problem might be that we want the conversion and then the additional scale change on top. The logic is not that straigt forward. And we'd need four cases: force to km/h, m/s mp/h, ft/s -- or maybe just two (force to h or s) combined with si and customary.

Hi @zuckschwerdt : could be something like this:

-C native | si[:<option>] | customary[:<option>] Convert units in decoded output.
    Use "native" to get decoded output without conversion. 
    Use "si" to get km, km/h or m/s based on native unit
    Use "si:h" to get km or km/h
    Use "si:m" or "si:s" to get m or m/s
    Use "customary" to get mp/h or ft/s based on native unit
    Use "customary:h" to get mi or mp/h
    Use "customary:s" to get ft or ft/s
    Use "customary:i" to get in or in/s

I was also looking to take into account the conversion for "km" to "mi" and the reverse for the lightning sensors using the existing functions from r_util.c since it's same conversion (kmph2mph and mph2kmph).

Few new functions must be added into r_util.c and r_api.c to get all these use cases.

@zuckschwerdt
Copy link
Collaborator

zuckschwerdt commented Feb 29, 2024

@ProfBoc75 it could be an option to add those "sub-options", only km/h, mi/h and m/s, ft/s though. That would give :h and :s but then there are transmit_s, uptime_s and volume_flow_h keys and we likely don't want to convert those, so it must be :kmh, :mph and :ms, :fts -- or something other, really not sure.
Seems a rabbit hole to do properly. I wouldn't go into all this as presentation is not rtl_433's goal.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants