Well, hoping the conversion code is suitable, it works perfectly. If we change our distance unit « imperial/US » or « SI », we convert the associated distance units.
I would have reversed the icons; that seems more logical to me. You can see whether the door is ‹ closed › or ‹ not closed ›, the window ‹ closed › or ‹ not closed ›. Right?
3rd PR : Addition of the handling of distance unit conversions imperial US (mile) / SI (meter). Of course, for this PR I started from PR #2 to have something to work with, so I just left the new units duplicated in both PRs. Tested and functional in PR #2 and tested with the existing types DEVICE_FEATURE_CATEGORIES.DISTANCE_SENSOR and DEVICE_FEATURE_CATEGORIES.LEVEL_SENSOR.
The conversions from inch to mm or cm depending on the dimension are OK.
The conversions from feet to cm or m depending on the dimension are OK.
The conversions from mile to mm or cm depending on the dimension are OK.
Etc.
Tests written. You can look at the implementation I added. https://github.com/GladysAssistant/Gladys/pull/2323
It may be a minor detail for now, but regarding consumption, we should specify whether it refers to since departure / since the last charge / since the last trip.
Because as it stands we can’t guess.
No, you’re right, it’s not a minor detail because for API data, the assigned types cannot be changed afterwards.
For the first step, it will only concern the values sent by the API; the types are tied, and then it’s up to the API development to specify in the feature name what it represents. Only those that are specific and can be linked to an interface have a specific type. There will then be the possibility to add more general types that can be associated with Custom if you want to perform calculations (via MQTT fake_device), and there it will be up to the user to put the correct names.
In the screenshots I posted, those are fake_device that I used for tests; I may not have reflected the feature names accurately.
[quote=« Terdious, post:45, topic:9529 »] 1st PR: Addition of the « target_current » feature and its handling identical to temperature to change intensity.
[/
@Terdious The fact that the setpoint intensity only changes in increments of 1, is that practical or not? (I can’t tell what the values are going to be)
Yes, generally with current control like that, you don’t change differently than that value on the ampere scale. And honestly I don’t see any other use than for a car or solar batteries to date.
For a vehicle, for example, as a rule we’re on a range of 5 to 32 A in most cases (some apparently go from 1 to 32 A) and in terms of power we’re therefore on increments of 250 W.