Wth can't I add a helper to a existing device?

Unlucky_Gagball · October 1, 2022, 2:13pm

I have helpers like input_booleans and input_select that I have made to help control a certain device it would be great if I could just add these entities to the relevant device.

Cougar · October 1, 2022, 2:19pm

Relates to this one but you question is boarder than just templates: Why can't we add template entities to existing devices?

frenck · October 1, 2022, 2:30pm

Helpers are not provided by a device in any way. So I’m not sure how that would work?

A template entity… yeah, maybe, if it provided/extracted information from a device. However, for an input/helper that isn’t the case.

Unlucky_Gagball · October 1, 2022, 3:10pm

it’s more an organise kinda thing.

If I set up an esphome device that relies on a helper for example then adding that helper to the device in HA would make it more “logic”. More a “related to” instead of “stemming from”…

Cougar · October 1, 2022, 3:14pm

I agree. Most of my helpers are also related with one device. Usually via some automation but still meant for this particular device. All Riemann sum and Utility Meters are always related with one device.

frenck · October 1, 2022, 3:18pm

I agree on those, as these consume the device itself (unlike input_* helpers).
But those cases could just be fixed/handled by the respective integrations already. For example, when using a Switch as X, the replacement entity gets added to the device.

So from that perspective, I think “Wth can’t I add a helper an existing device” would maybe be better described as “Wth don’t Riemann sum and Utility Meters add themselves to their respective devices”.

…/Frenck

Cougar · October 1, 2022, 3:30pm

Yeah, “helpers” that use one source entity should always be under this device. I agree that it would be nice to get Riemann sum and Utility meters (what periods?) somehow automatically.

There are also “helpers” that are not obvious like “Derivative sensor” or statistics min/max/avg sensor.

One simple solution would be to automatically assign all other sensors whose input is from device, under the same device but show them like “related”. It is still good to have distinction what sensors are coming from device/integration and what are added extra by user.

Sometimes the “Related” doesn’t work even with the entity itself - again both Rieman sum and Utility Meter are the first ones I see this information missing.

mobile.andrew.jones · October 2, 2022, 2:52am

It would just be a UI upgrade though right? So it would be similar to how you currently can assign any entity to any area. But it would just be another drop down, which would allow you to assign any entity to any device. The backend stuff is pretty much already in the place, because the likes of MQTT sensors uses it - mapping a sensor to a device. So on the backend surely it would be as simple as storing in the JSON config - that an entity belongs to a particular device. The only things it wouldn’t work for - would be YAML defined entities that have no unique_id (which is fine, because they can’t be configured in the UI anyway)

Unlucky_Gagball · October 2, 2022, 8:39pm

You can assign a unique id to most yaml defined entities. just add unique_id: like you would add friendly_name: (enjoy updating your yaml files

mobile.andrew.jones · October 2, 2022, 9:44pm

Oh I know, as I’ve updated from the old format for things like MQTT and Template stuff, I’ve added unique IDs to stuff. But not everything in YAML has always been able to have a unique ID - it’s reasonably recent that that has improved. Once an entity has a unique ID - there is no reason it can’t be added to a device, because it’s uniquely identifiable

wigster · October 3, 2022, 9:35am

It should also be possible to assign a device for various template sensors, or SQL sensors. I create various template sensors from power use states of devices and it would be nice to have those appear on the device page.

Hellis81 · October 3, 2022, 10:05am

I like this idea.

Here is my NS panel and it groups the automations and scripts I have to this device in the left panel.
It would be very nice if these included a edit and this input_* filed.

And please make sure there is a edit button so that we can add them manually because my scripts are not here in the list.
That would make it very easy to organize and find everything related to one device.

Mheeniac · October 5, 2022, 9:36pm

I fully concur with this WTH. It is very similar to one from last year (WTH can’t I manually create a device from entities?).

I would extend this WTH to be more general, as in the one I linked above. WTH can I not add/link entities to a device, or even compile several into a ‘virtual’ device? For example, I have a smart plug on my dishwasher that allows me to monitor the power consumption. I have a template that uses this power consumption to create a dishwasher state (off, idle, drying, washing). Currently, this template entity state just floats by itself rather than being linked to the Dishwasher device.

zipp0kms · November 6, 2022, 7:47am

The powercalc integration create sensors about power and energy from a device. The new sensor is added to the device overview. It’s perfect! But why I can’t do it manually? I want it

antonio1475 · March 6, 2023, 9:35am

You are very right. Powercalc is able to add a new Sensor box in the device overview.

I created a Real power sensor for my TV feeding from the socket Power, which creates an Energy sensor for the device (the actual TV).

[It doesn’t actually create/duplicate the power sensor into the TV, it creates a new Energy one that feeds off the power, but that is by design of the creator to avoid duplication I guess).

So, it’s possible to do this (add a sensor to a device). As you pointed, the quesiton is how to do this manually. I have sensors, template entities, etc floating around that I would love to merge into the device…

stefan.schaedeli · June 14, 2023, 7:34pm

would love this one too… I programed an automation to tilt my untitlable blinds and would need a place to store my manually enabled tilt percentage… I have 15 blinds… now I have either unsorted helpers or do some nasty hack… this would be great if I could manually extend a device to store this value

dougiteixeira · June 17, 2023, 12:05am

I implemented the inclusion of the helper entity in the device of the source entity for helpers that have only one source entity.

Summary of the implementation in all helpers:

Helper	Helper Domain	PR
Derivative sensor	derivative	#94751
Integration - Riemann sum integral sensor	integration	#94727
Threshold Sensor	threshold	#94753
Utility Meter	utility_meter	#94734
Combine the state of several sensors	min_max	Can contain many source entities… how should it be handled?
Group	group	Can contain many source entities… how should it be handled?
Change device type of a switch	switch_as_x	Already implemented
Counter	counter	Does not come from a source entity
Toggle	input_boolean	Does not come from a source entity
Button	input_button	Does not come from a source entity
Date and/or time	input_datetime	Does not come from a source entity
Number	input_number	Does not come from a source entity
Dropdown	input_select	Does not come from a source entity
Text	input_text	Does not come from a source entity
Schedule	schedule	Does not come from a source entity
Timer	timer	Does not come from a source entity
Times of the Day Sensor	tod	Does not come from a source entity

sophof · July 28, 2023, 12:12pm

I don’t understand why it matters if it comes from a ‘source’ entity? To give you an example (it is why I came here via search).

I have created an input_number helper that tracks how many m² is left before I need to maintenance the filter on my robot vacuum. Keeping track of this number (and notifying me when I need to maintenance it) is handled by an automation. In my opinion this new entity totally is ‘part’ of the device, just as much as total_clean_area is for instance.

I could think of essentially a variation on this for almost any helper (and for templates) and they all sound completely valid to me. It seems that you and Frenck have a totally different mental model of what a device is? I’m also unclear about the downside (except for the extra work it requires to implement obviously), but I feel they are implied to be there?.

Maybe this can be a 5th type of entity? I mean besides control, sensors, configuration and debug?

wunsch · November 16, 2023, 3:30pm

Hello all,

I also would like to create devices out of entities.
I also think of device as a physical or virtual object with multiple entities (as attributes of the devices - do not confuse this concept with attributes of entities).

I also read last years thread: WTH can’t I manually create a device from entities? , which I totally agree to.

I have a lot of entities floating around, and would love to bring them together in a device to more easily find them.

Same is true for the mass of entities created by eg. the “Sungrow-Modbus-Integration” - which actually is “only” a package/config to create entities as yaml-config.
see: GitHub - mkaiser/Sungrow-SHx-Inverter-Modbus-Home-Assistant: Sungrow SH Integration for Home Assistant for SH3K6, SH4K6, SH5K-20, SH5K-V13, SH3K6-30, SH4K6-30, SH5K-30, SH3.RS, SH3.6RS, SH4.0RS, SH5.0RS, SH6.0RS, SH5.0RT, SH6.0RT, SH8.0RT, SH10RT, SH5.0RT-20, SH6.0RT-20, SH8.0RT-20, SH10RT-20, SH5.0RT-V112, SH6.0RT-V112, SH8.0RT-V112, SH10RT-V112, SH5.0RT-V122, SH6.0RT-V122, SH8.0RT-V122, SH10RT-V122, SH4.6R

here it would be good if I could simply enhance the script / sensor-configurations to all be part of one device …

e.g. (non existing yaml-configuration option as sample-code):

modbus:
  - name: SungrowSHx
    type: tcp
    host: !secret sungrow_modbus_host_ip
    port: !secret sungrow_modbus_port
    retries: 10
    sensors:
      - name: Sungrow device type code
        unique_id: sg_dev_code
        slave: !secret sungrow_modbus_slave
        address: 4999 # reg 5000
        input_type: input
        data_type: uint16
        scan_interval: 600
        device:
            device_id: 'modbus_sungrow_sh10rt_sw'
            manufacturer: "Sungrow"
            model: "SH10RT-v112"
            name: "Sungrow SH10RT v112"

The idea would be, that by adding the “device: > device_id:” I would create a device, and add the sensor-entity to the device.

It would help me a lot finding the entities, as they are then all structured in a device.
I think creating an automation to add every entity in only this “Sungrow-modbus” would be massive overkill for these 50+ entities (so there is a workaround - but it is massively inconcenient!)

I think a new config item in the configuration.yaml would even be better - where one could create a device and add the entities to the device there (as shared in last years WTH):

device:
  - device_id: 'modbus_sungrow_sh10rt_sw'
    manufacturer: "Sungrow"
    model: "SH10RT-v112"
    name: "Sungrow SH10RT v112"
    entities:
      - entity: sensor.sungrow_device_type_code

Wouldn’t that make a lot of sense?

Unlucky_Gagball · November 16, 2023, 3:54pm

I agree. I find the freedom we are granted in this topic is lacking.

If we can make a device or edit or just add a entity we have the freedom to implement this based on our needs.

Because even input_booleans that might not come from a device might be relevant to just 1 device.

My water boiler comes with just a bunch of entities. Being able to group them in a device together with the input_select that I use to control my water boiler would be very useful.