Feature request: allow specification of device classes for health sensors in the same way as for presence sensors #194
Replies: 4 comments
-
Good point. This should be relatively straightforward to implement, added to the queue |
Beta Was this translation helpful? Give feedback.
-
As a note, my specific variety of this issue has been cleared up since Home Assistant introduced the dedicated "tamper" device class and with the sending of relevant PRs to get integrations to update to using that instead of "problem" for tamper sensors. I don't know how relevant this remains with regard to how other integrations that I don't use may use the "problem" device class. |
Beta Was this translation helpful? Give feedback.
-
Thanks for the update, still it would be a nice feature to allow specification of what device classes you want on your health sensors |
Beta Was this translation helpful? Give feedback.
-
This is implemented in release 4.0.0 which is out! |
Beta Was this translation helpful? Give feedback.
-
At the moment, as I understand it, health sensors include classes problem, smoke, moisture, safety, and gas.
Trouble is, for me, all the sensors of type problem are tamper entities attached to some other sensor, which seems to me to be a different class of issue. I get an aggregate sensor of Area Problem ([room]), which I treat as my "problem with some sensor in here, go fix it" warning, but the same issues show up in my Area Health ([room]) sensor, which I want to treat more urgently, as smoke, flood, gas, and suchlike obviously need to be treated. I can't get the tamper sensors out of health without excluding the entities entirely, at which point I don't get the Problem aggregate either.
Beta Was this translation helpful? Give feedback.
All reactions