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

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.

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

1 Like

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.

1 Like

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ā€ā€¦

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.

2 Likes

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

1 Like

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.

2 Likes

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)

1 Like

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 :smiley:

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

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.

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.

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.

1 Like

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 :smile:

2 Likes

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ā€¦

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

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

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 m2 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?

1 Like

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?

1 Like

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.

3 Likes