Attributes naming inconsistency

[michalk-k]

Not sure you take attribute names from Ford API, where those are inconsistent or it a result of mapping issue, but exprience some inconsistences. For example

The hood is not an upper case like others

In other places, there are the 1st letters uppercase only

There is also a discrepancy in using space between words

[SquidBytes]

The hood is not an upper case like others

The Ford API reports those sensors in ALL CAPS, so it just depends on how it was written. For some of the attributes, we are grabbing the name from the API. While others are assigned. As you can see from below, we are grabbing the names from the API for everything, except the "Hood" which the name is manually assigned. This can easily be fixed, but since we have been busy implementing the new API - its just a few inconsistencies missed. These can easily be addressed for future improvements

In other places, there are the 1st letters uppercase only There is also a discrepancy in using space between words

Its the same with these. The Ford API uses camelCase, so while adding sensors and attributes we generally check for the value - then assign the value. Usually while developing and debugging I keep the name of the attribute exactly like the API as it helps me find potential issues and it is easily checked, and searched for, because there are not different names.

I also didn't want to go through and start renaming all the attribute names, because that could throw off peoples custom sensors, etc.

Moving forward though I'll try to remember to double check naming, and make sure they are consistent.

I'll talk with itchannel, and see what naming structure would be best moving forward, and we can probably have a consistent name structure in the next release.

[SquidBytes]

If you take a look at the fordpass_indicators sensor you will see exactly what the API returns, as it is just being mapped based on what is returned

If we wanted to rename each of those items, we would have to break it out and manually change the name of each value. This isn't hard, but it also has the potential to throw errors for different vehicles based on the vehicles capabilities.

So just a thing to keep in mind, if we do move forward with consistent/manually assigned names; there will still probably be some inconsistencies in different sensors.

As for different sensors we are already breaking out and checking, I'll start ensuring they have a more clear name.

[itchannel]

I think @SquidBytes has covered this issue pretty well. The issue we have is inconsistent naming comes from the API as well. The "Hood" variable can easily be changed to match the same case as the doors which is something I probably should of done and was manually set by me. Where possible I generally leave the json key from the API as the same name as the sensor values, just incase Ford ever make a change it won't stop working. Also makes iterating over the arrays a lot easier than doing manual name changes if/when new data occurs.