Commit #85 does not allow UoM from entity about bom-weather-card

[TheCranston]

Oh, yeah. I agree, if keeping the override then your suggested flow

I think the best option would be to use the override first, if that is not define then use the sensor units and if that is also not defined then drop back to the current silly way.

is a good path to ease any transitions while keeping the most open to the various weather integrations.

[TheCranston]

Updated: I see the config variable for show_decimals_pressure. That'll fix the rounding. Mea culpa. Read the source, Luke...

However what is the thinking behind a config variable for the UoM of the pressure entity? Wouldn't it make more sense to let the integration being used to feed the card specify the UoM for its measurements and have that flow thru to the card. Right now I see that I can set config.pressure_units as a way to hard code the UoM. More work for the end user and a possibility for a disconnect between the config file and the integration feeding the card. Thoughts?

In my humble thinking, it would make sense for the integration to specify the UoM for its entities and the card to honor them as they stand. I don't see how that would cause a problem for any source integration. And given that the typical deployment of the card there is a template mapping of from the Integration into the card entities the user can adapt the source units there if they must change them to a local unit that the weather integration does not provide natively. Why not take the complexity out of the card by letting the units flow thru?

[DavidFW1960]

Yeah it's a bloody breaking change.. If you don't configure this at all it will use the configured units to set the UoM just like it always used to do. The pressure in BoM for instance is unitless even though the unit is an attribute it's not linked to the state of the entity a all and is not parsed to the card.
The reason for this change is people in the US for instance use in/Hg as the unit and with imperial it was defaulting to something else. It's really just an override.
I understand your sentiment however NONE of the integrations include the unit in the state so somehow that would need to be read from an attribute. (another template sensor or the like) This is generally not required as the length units (metric or imperial) set the pressure automatically.

[TheCranston]

@DavidFW1960,
The NWS integration does provide units natively. See:

Accessing this directly in the javascript could be accomplished by:
${this._hass.states[this.config.entity_pressure].attributes.unit_of_measurement}
Where it is provided by the integration a simple test for it's presence would work and otherwise flow into the getUoM() process being used now.

[DavidFW1960]

Accessing this directly in the javascript could be accomplished by: ${this._hass.states[this.config.entity_pressure].attributes.unit_of_measurement} Where it is provided by the integration a simple test for it's presence would work and otherwise flow into the getUoM() process being used now.

Ok. Let me take this up with Simon. I'm not opposed to including this. @Makin-Things what do you think?

[Makin-Things]

Making this change may upset some people. Currently the card uses a weird formula to decide on the units, which I don't think is correct. If the systems length unit is Kilometer then it uses hPa if its anything else it uses mbar. Both hPa and mbar are metric pressure units (in fact they are equivalent).
If I ditch that and use the units from the sensor there is a chance that people will see the displayed pressure switch from hPa to mbar (or vise versa). There is also the chance that people don't have any units set on the sensor (who knows). Just be aware that you may get some whinging.
I think the best option would be to use the override first, if that is not define then use the sensor units and if that is also not defined then drop back to the current silly way.

[DavidFW1960]

I think the best option would be to use the override first, if that is not define then use the sensor units and if that is also not defined then drop back to the current silly way.

I would agree with this.

Making this change may upset some people.

Any change even the most sensible upsets someone. See slots... hahahaha
I hate pissing people off or taking something from them they cherish so we try and accommodate while moving forward....

[TheCranston]

Simon, I agree, changes can cause negative reactions...

That being said, the provided weather.yaml example manipulates the integration data into known entities for the card. I'd propose that the better place to make a units change is right there in the template section. If you don't like hPa you can make the change. The card's goals of being agnostic to the weather integration, as I understand it, would align with that thought of accepting the units as presented by the entity.

Please take a look at PR #82 for the NWS.yaml and NWS-lovelace.yaml work that I proposed.

Basically the units get ironed out either by being passed thru from the integration, or manipulated in the template sensor logic. Either way, the card, I propose, should pass it all thru in keeping with the goal being a generic card working with any provider. I do see the edge case where an integration does not provide units of measure for its entity. That's easily remedied in the jinja of the template sensor setup, or via some logic catching "undefined" states and making a best guess or some sort of error communication.

Thoughts?

[Makin-Things]

@DavidFW1960 I am having second thoughts on this and think removing the initial override might be a better idea. So use units from sensor if available and if not then use the old method.
Interesting thing is I went looking at a bunch of countries weather bureau sites and 99% of them use hPa as that is the accepted unit of measure as specified by the WMO. The US weather site is weird, on the observation map it is in hPa but go to a station and it is in inHg.

[DavidFW1960]

So no flag needed then?

[Makin-Things]

Yeah, it would remove the pressure_units override and rely on the sensor units if available and use the current method as the fallback if the sensor doesn't have a unit.

[DavidFW1960]

Well its a pity throwing the new override aside but it will likely work better anyway. Just a pity we didn't consider this earlier.

[Makin-Things]

Sometimes you make poor decisions, just best to recognise that and fess up and move on.

[DavidFW1960]

Ill do the release tomorrow but master should fix the units and use the entity.