Continuing the discussion from WeatherFlow PyConsole:
It seems as though if Units Other is not set in the app/Web settings, and remains with the default value of ‘imperial’, a corresponding field is not created in the API. Has anyone else experienced this? It’s hard to recreate as a brand new station setup is required to test.
your not alone all the rain conversions in the template i do are screwed for weatherflow api something changed but according mr guru its always been like but why suddenly issues of rain conversion as just appeared . need some official weatherflow clarification because compairing an api output from january 2018 to current there is no other units .
this is also affecting meteobridge when used with weatherflow hardware rain is appearing in cm so all this has just arisen this week. i cant recall ever changing the conversions in months as i understood values were always in metric and units defaulted to metric … if its always been like this then indont understand why it wasnt picked up months ago. .
perhaps if the change was announced then lock whatever thread because its hard to wade through the noise at times and see the information… just my 2 turkish kurus worth 
this was my reference point and developed upon note the units …tell me im not going nuts or misreading
As you can see, it is stored in metric. And no need to be insulting.
Good catch, Peter. It certainly seems like this unit is not being set to any value.
Look at this from station 5248
"station_units": {
"units_temp": "f",
"units_wind": "mph",
"units_precip": "in",
"units_pressure": "mb",
"units_distance": "mi",
"units_direction": "degrees"
},
units_other is missing.
David, @dsj
Peter found a very serious bug.
@peter , I moved this to Bug Report so it will get picked up by @anon84912554
no ones insulting you. take it how you feel just a bit of fun .this is what we were saying the other day units string now as metric and non metric this was not there before it was always set to metric… hence the template uses the units string default of metric now it has to be rewritten to use non metric phrases ,along with wind phrases and so on basically rewrite whole template structure if im understanding this all correctly . sorry was not meant to be an insult … i have two reports of also being reported rain in cm i never have seen this before . so please its not an insult… just a bit of humor . brian…
comparing an api out from jan 2018 to a current api output now has non metric phrases . i dont recall ever seeing those even way back to early 2017…
I think you now hold the record for discovering the oldest bug. It’s just by chance that this came up.
@anon84912554 will need to go through the database and set that for all stations that do not have it set.
This is how WeatherFlow handles it in the applications.
return e.user.userOtherUnits() == e.OtherUnit.IMPERIAL ? (.062428 * t).toFixed(5) + " lbs/ft3" : t + " kg/m3"
So, if it is not set to Imperial, it defaults to metric.
Where are you seeing non-metric phrases?
The data has always been stored in metric and rain has always been stored in mm.
Phrases have never been stored in the data.
“units_temp”:“f”,“units_wind”:“mph”,“units_precip”:“in”,“units_pressure”:“inhg”,“units_distance”:“mi”,“units_direction":“cardinal”},“outdoor_keys”:[“timestamp”,“air_temperature”,“barometric_pressure”,“sea_level_pressure”,“relative_humidity”,“precip”,“precip_accum_last_1hr”,“precip_accum_last_24hr”,“precip_accum_local_day”,“precip_accum_local_yesterday”,“wind_avg”,“wind_direction”,“wind_gust”,“wind_lull”,“solar_radiation”,“uv”,“brightness”,“lightning_strike_last_epoch”,“lightning_strike_last_distance”,“lightning_strike_count”,“lightning_strike_count_last_3hr”,“feels_like”,“heat_index”,“wind_chill”,“dew_point”,“wet_bulb_temperature”,“delta_t”,“air_density”],“obs”:[{“timestamp”:1536765474,“air_temperature”:27.0,“barometric_pressure”:971.0,“sea_level_pressure”:1008.7,”**relative_humidity":34,“precip”:0.0,“precip_accum_last_1hr”:0.0,“precip_accum_last_24hr”:0.004,“precip_accum_local_day”:0.0,"precip_accum_local_yesterday":0.004,“wind_avg”:0.7,“wind_direction”:110,“wind_gust”:1.0,“wind_lull”:0.3,“solar_radiation”:465,“uv”:4.94,“brightness”:55834,“lightning_strike_last_epoch”:1535951988,“lightning_strike_last_distance”:24,“lightning_strike_count”:0,“lightning_strike_count_last_3hr”:0,“feels_like”:27.0,“heat_index”:27.0,“wind_chill”:27.0,“dew_point”:9.8,“wet_bulb_temperature”:16.6,“delta_t”:10.4,“air_density”:1.12697}]}
take a look at this i see values themselves in metric or are they particularly rain or wind speed . the other anomalie is see is sea level pressure at 1008 but barometric pressure at 971.0 that big difference what does barometric pressure relate too normally if a difference between station pressure to sea level the difference is not that high or ive neever seen such a large difference in all hardware i have owned in past and present .
thanks for your help but im going to sit down next week and try and digest the changes and see if I can make sense of it .next week because i have a complete production kit arriving this time direct form china so might be better for me to use realtime data.my current skys all have some anomaly brian
Good catch, indeed. Turns out the “units_other” field was not part of the original station_units definition, but was added later (earlier this year) at the same time we added “air density” to the “derived values”. From that point forward, an entry for units_other was correctly created any time a new account was created. And that field was updated any time a user changed his/her units. But, since we added handlers for the lack that field to our apps, we did not bother to go back and update the station_units for accounts that were created before the new field was added. We should have.
So, once identified, the fix was easy: we just added that field to any account that didn’t have it set. Unless there’s some other way those units are being set, this issue should be resolved. Please confirm. And thanks again for finding and reporting this bug!
WOW! That is F A S T !!
Thank you David.
And this is the One reason I enjoy working with and on WeatherFlow. Issues get resolved as quickly as possible.
I checked station 5248 and it does indeed have the parameter added.
All values are in metric. It is up to the application to convert them to the assigned units that have been selected by the user.
It’s not an anomaly. barometric pressure is the pressure at the station. It is what gets converted to sea level pressure.
ok i get that part but i don’t understand are these a new feature because i dont recall seeing them in the past. thats what im asking is it new or something i overlooked for the last 12 months or more . im baffled this has only arisen this week as i say my oversight or something new is the question… anyway its not urgent just looking for some clarification .
This missing “units_other” parameter is not new - @peter just discovered it while troubleshooting his PyConsole software.
I don’t think this is related to the missing “units_other” parameter. We haven’t changed anything regarding rain data in the API - not on purpose anyway!
Please describe what you’re seeing that’s odd or new - maybe we have another issue going on here.
No, they are not new. I have been working on this for over 16 (maybe more) months and they were in there when I started writing code.
never mind David if you have not changed anything thats all i wanted to hear …its something else and I cant fathom out why its only just appeared ill look at it sometime thanks for responding .