Allow device_class injection or overrides for individual services

[NorthernMan54]

@jeroenvermeulen @StumbleNOLA I was thinking about the use case for basic contact and motion sensors, and am thinking about adding the ability inject the device_class based on the unique id. This was some basic on/off sensor types can be properly reflected within HomeKit without a lot of work.

In my setup I have these basic sensor types

• Motion sensor - turns a GPIO on / off
• Contact sensor - turns a GPIO on / off
• Water leak sensor - Is a value read from the ADC pin. Am thinking of making a rule on the device itself that would map it to a on / off value when it crosses a threshold

In the config I was thinking of something like this

{ unique_id: "DFDFDFDD", device_class: "Contact" }

What's your thoughts?

[jeroenvermeulen]

So this means you need to build up a library of devices? Isn’t it true the root cause of the problem are the Tasmota devices forget to set the device class?

On 2 Oct 2020, at 19:02, Northern Man notifications@github.com wrote:  @jeroenvermeulen @StumbleNOLA I was thinking about the use case for basic contact and motion sensors, and am thinking about adding the ability inject the device_class based on the unique id. This was some basic on/off sensor types can be properly reflected within HomeKit without a lot of work.

In my setup I have these basic sensor types

Motion sensor - turns a GPIO on / off Contact sensor - turns a GPIO on / off Water leak sensor - Is a value read from the ADC pin. Am thinking of making a rule on the device itself that would map it to a on / off value when it crosses a threshold In the config I was thinking of something like this

{ unique_id: "DFDFDFDD", device_class: "Contact" }

What's your thoughts?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[StumbleNOLA]

I would love this. Most of the contact sensors I have seen are either high or low, they exist in a binary world. As I hope has become apparent I have no programming background, and minimal understanding of how the plugin works. But adding support for this would be great. Even if they are just treated as toggle switches and you had to define them yourself inside HomeKit.

I already use a plugin that just created dummy toggle switches, so having a sensor control one of them would be great.

[NorthernMan54]

@jeroenvermeulen For devices like your CO2 sensor, you are correct that is a gap and they should have included a device_class, and pushed home assistant to include it as part of the available options. Looking at the available device_class options it isn't even listed

Sensors - https://www.home-assistant.io/integrations/sensor/#device-class

Binary Sensors - https://www.home-assistant.io/integrations/binary_sensor/#device-class

For my basic sensors they are listed, so I think you are correct and let me raise a Issue against Tasmota asking for support of a device class option. Implementation may be complex as you can have multiple binary sensors on a single device.

In the interim if I implement an override, then it just becomes redundant if Tasmota implements something.

This would also allow some flexibility on devices, as I found in my setup a dimmer that was controlling a Fan, and after I switched it over, it is now a light bulb ;-(

[NorthernMan54]

@effelle I see that you are one of main contributors to the Home Assistant Auto Discovery functionality for Tasmota, and was wondering about the feasibility of adding device_class support for the binary_sensor types? We are working thru using this feature of the Tasmota firmware to also integrate into HomeBridge, and were discussing approach for this GAP.

I realize that this is a bit complex as a single device can have multiple binary sensors, and would likely require some thought. Has this been considered or thought about?

PS I'm using the home assistant auto discovery feature of the Tasmota firmware to create devices within HomeBridge, and reduce the complexity of the current approach with requires a complex configuration.

[effelle]

Fun fact, even if I'm the maintainer of the Ha discovery I literally not using it. In fact I don't use HA at all! In the last year the MQTT discovery grown a lot in term of functions thanks to a "joint venture" between me and @emontnemery from HA dev team (the first iteration of the discovery under Tasmota was his work).

All of this lead to an idea that we are transforming in reality right now: we are introducing Tasmota discovery as an official integration under Home Assistant. This doesn't means the MQTT discovery as we know now will die anytime soon but is also important to remember that you'll probably see less update from the internal discovery and one day could be gone.

About the binary_Sensors, we didn't "forget" to add the device class, is simply not logic from our point of view since there is no way to decide what is what, at least not as Tasmota is now. Also, there was a breaking change for inputs under the discovery some months ago after I've introduced the new buttons multipress for Tasmota. They became automation triggers as some switches did. The classic ON/OFF switches are still announced as binary sensors but again know if is a PIR instead of a simple switch or anything else is another story. Ping me on Discord if you like, perhaps a chat is a better way to help me understand what you want to archive.

[NorthernMan54]

@effelle Tks for the offer for a chat on discord, which one are you part of and what is your id ? I'm interested in the new discovery pattern you are working on, as it appears it may be a better longer term option for homebridge integration.

Tks

[NorthernMan54]

@jeroenvermeulen @StumbleNOLA After thinking about this further, I'm going to create a discovery object merge function. And combine the Tasmota discovery message with values from the config.json, with the config.json object values taking priority over the Tasmota discovery message. What is different from my original approach is that this would allow overriding or injecting any field rather than just device_class field. This would allow overwriting or supplementing any discovery object fields and values as needed.

UNIQ_ID would be the unique id of the service

overrides: [ 'UNIQ_ID1': { device_class: 'Fan', name: 'Floor Fan' }, 'UNIQ_ID2': { pl_on: 'Off' } ]

[effelle]

effelle here, effelle in Tasmota Discord. Ping me on general. https://discord.gg/Ks2Kzd4