#Add support for Wearable device status f...
terse galleon
since it can never be "charging" and "full" at the same time, I agree with @hushed hinge because the binary_sensors would be mutually exclusive
wind cipher
but having the device class has benefits
As in, having a binary sensor with battery_charging device class is much more usable in automations than a sensor with a state trigger
terse galleon
As in, having a binary sensor with battery_charging device class is much more us...
yeah, but not if the "battery charging" binary sensor goes to OFF when its fully charged
wind cipher
I mean, that's quite ambiguous anyway, because charging is adding energy to a battery, which is different from having a charger attached
But now that you say, it's more like the 3 are together, so if it's full and you remove it. It wouldn't be full for a moment
hushed hinge
Thats not true as most batteries are full at 98% or similar. Also some
devices allow to be connected for long time and keep the device full. For example led headlights we have at the mountain rescue (and they have bluetooth so I could even automate on it)
wind cipher
Thats not true as most batteries are full at 98% or similar. Also some
devices a...
Yes but the current state doesn't show that
hushed hinge
And in my opinion we should not split a three value sensor into multiple just for UI or device class. That's wrong imo and create edge cases which can be avoided
wind cipher
Thats not true as most batteries are full at 98% or similar. Also some
devices a...
Yes but that depends on the implementation, some devices consider "being attached to a charger" as charging, while others consider "adding energy" is charging
hushed hinge
The api of the device is reporting three values and we should not split them
wind cipher
I'm saying, if they mix the context of two things it wouldn't be bad to potentially split them as that would end up clearer for the user
hushed hinge
No splitting makes it worst for the user
Full is for me a valid charging state
Nevertheless I will put this PR to the agenda of the next core meeting
wind cipher
Full is for me a valid charging state
Then you're not understanding what I mean
I'm saying if they mix 2 separate concepts in a single field, it's okay to split
It's not a must, but it's not bad either
hushed hinge
I understand you and they are not mixing two things in my opinion as for the on a charging sensor full makes totally sense. Full means trickle charging so it's still charging to keep the battery full. Common in at least in German
Anyways let's discuss it on Tuesday
hushed hinge
I tried it but we didn't came to an conclusion so I have put it on the agenda
wind cipher
I mean i never said anything what i thought about what you said, i just mainly tried explaining what i was trying to say
So 🤷🏼
hushed hinge
and I'm against your suggestion in the PR as in my opinion makes it more complex and the states are mutually exclusive so they should be one sensor. As we have different opinions (which is fine) we need the opinion of the others, which can be asked quickly in the next core meeting
wind cipher
I am never saying that i have a strong opinion on this one
wind cipher
It's not a must, but it's not bad either
I am just saying this
Like I just want to explain where i came from and move on lol
Otherwise we'd have another 15 minutes talking about this that's just not needed
terse galleon
the API reports a 3 state thing, and we have no way to properly separate it into 4 states (two binary sensors), so we should keep it as a 3 state thing
no calculated states yada yada 😄
(yes, I know "calculated" is a stretch here)
terse galleon
Otherwise we'd have another 15 minutes talking about this that's just not needed
fully agree. but are you ok with a sensor then?
wind cipher
I'd say it depends. If you remove the wearable from the charger and it would still show as full for maybe the top 10%, then you have 2 concepts in a single field: 1. Charging 2. The device being full
wind cipher
fully agree. but are you ok with a sensor then?
Ye
wind cipher
I'd say it depends. If you remove the wearable from the charger and it would sti...
But I also think we should be doing more device class entities. We now are going to have nice triggers for for example the battery state and when it starts and stops charging iirc. That wouldn't work out of the box with this approach
terse galleon
I'd say it depends. If you remove the wearable from the charger and it would sti...
yeah, but that's what the API reports, so not much to do about it 🤷 we just pass that to the user. binary sensors would be misleading depending on the situation
wind cipher
But I also think we should be doing more device class entities. We now are going...
But that's just a side quest and not relevant
But it's a thought I'm playing with
terse galleon
But I also think we should be doing more device class entities. We now are going...
yeah, but I think its better to be "transparent" (reflect what the API shows) than trying to be smart about it and then having an inconsistent behavior anyway (like it charging=OFF when its full).
wind cipher
yeah, but I think its better to be "transparent" (reflect what the API shows) th...
I'd say our goal is to find the balance between making it useful and being transparent/raw. We also don't pass along numbers as strings because they're strings in the API
(although all states are strings, so that doesn't really fly, but there are probably other examples)
terse galleon
yeah, but we don't change the numbers eheh
wind cipher
Ye
terse galleon
the point is that here it would not make it more usefull, because it breaks the expectation of what "charging" means
wind cipher
But that's what I'm saying, it depends on what full means
In any case, it's starting to become a principle thing 😂
terse galleon
But that's what I'm saying, it depends on what full means
no, depends on what "charging" means. I think that is a well established concept 🤣
wind cipher
no, depends on what "charging" means. I think that is a well established concept...
Nope
Adding energy vs having a charger attached
Both can be seen as charging
terse galleon
right. but what is the common one?
wind cipher
I dont have any reason to believe there's a general common one, I've seen both
And I don't have data to use here
hushed hinge
Joost full will probably only reported back if it's connected to the charger. When you disconnect it it will go immediately to not charging.
The full status can be used to identify when the device is fully charged.
My laptop has the same including a led for signaling. Led off not charging, led red charging and led white means full
when I disconnect it the led is immediately off. Similar one has the macbook
It's a simole automation to notify the user when the device is fully charged with one sensor
with two sensor it gets really more complex
wind cipher
Joost full will probably only reported back if it's connected to the charger. Wh...
But that's what I'm saying lol, in this case it's one concept and it's fine
hushed hinge
But you requested in the PR to split it into two binar sensors
wind cipher
I sometimes also make mistakes or just write something down that i think is interesting
I definitely interpret full in a different way
hushed hinge
that's fine 🙂 Just update the PR to say that we keep the sensor as it is 🙂