Prerequisites
Describe the Feature Request
Support passing in the unit type into API requests for weather providers when supported. Use the current implementation (the module does the conversions) otherwise.
Describe the Use Case
The current implementation of the weather module always requests metric units in the Provider APIs. This is bad for rounding reasons. Some providers (e.g. WeatherFlow) support providing data with precision (e.g., the tenths place for temperature). When using C (which has a smaller available range), we lose accuracy by as much as 0.2F when manually converting the API response to F.
Note: WeatherFlow does not support providing units in the conditions API where it provides precision; it always returns C. But it supports units in the better_forecast endpoint (however, it always rounds to the nearest whole number for the temperature, which is unfortunate).
A better example of this might be OpenWeatherMap. They provide precise temperatures and support specifying units. Therefore, a C return being converted to F by the module may result in a loss of accuracy due to double-rounding (the API rounds for C, and the module rounds again for F).
Describe Preferred Solution
- New public readonly property in provider JS classes. This property defines whether the provider supports specifying units in the API. If this is false, then the weather module does its own conversions (as it currently does). If true, then the module assumes the returned data from the Provider is already converted (and does not convert anything).
- When a provider supports unit conversions, use the specified MagicMirror configuration for units if possible. Pass this in the API call for the provider. For special cases, add new Provider-specific configuration properties.
Describe Alternatives
No response
Related Code
No response
Additional Information
No response
Participation
Prerequisites
Describe the Feature Request
Support passing in the unit type into API requests for weather providers when supported. Use the current implementation (the module does the conversions) otherwise.
Describe the Use Case
The current implementation of the weather module always requests metric units in the Provider APIs. This is bad for rounding reasons. Some providers (e.g. WeatherFlow) support providing data with precision (e.g., the tenths place for temperature). When using C (which has a smaller available range), we lose accuracy by as much as 0.2F when manually converting the API response to F.
Note: WeatherFlow does not support providing units in the conditions API where it provides precision; it always returns C. But it supports units in the better_forecast endpoint (however, it always rounds to the nearest whole number for the temperature, which is unfortunate).
A better example of this might be OpenWeatherMap. They provide precise temperatures and support specifying units. Therefore, a C return being converted to F by the module may result in a loss of accuracy due to double-rounding (the API rounds for C, and the module rounds again for F).
Describe Preferred Solution
Describe Alternatives
No response
Related Code
No response
Additional Information
No response
Participation