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

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

Me to, as simple example:

I want to be able to add several templates and helper sensors to my plant device such as a PH entity “an input-number helper”, then us a threshold helper for the new PH entity.

1 Like

I am currently building a custom integration that will allow the user to modify devices in the following ways:

  • Change device attributes
  • (Re-)Assign any entity to any device
  • Create new devices
  • Merge two devices

Changing attributes and assigning entities already works, however the integration is currently under development, lacking documentation and should be treated as unstable and experimental.

If you are still interested in these features, Maybe you’d like to check out the repository and follow the development: GitHub - EuleMitKeule/device-tools: Device tools integration for Home Assistant.

3 Likes

Seems like something I’ll have to look into this weekend!

1 Like

Just to add my 2c, I was impressed at utility meter etc being added to the correct device.
The problem i’m hitting now though is i’ve a device that provides a voltage and amps reading, and so I wanted to create a helper via template that uses these two sensors to create a wattage sensor. Had to make this using template, but these would not be automatically added to a device (even though both sensors come from the same device), and there’s no way to manually assign them to it so it appears on the device page.
Being able to manually assign to a device would be awesome.

1 Like

I just stumbled across this very recent pull request that implements some of what is being requested here…

Add the ability to bind the template helper entity to a device

This looks encouraging - go give it a thumbs up :slight_smile:

2 Likes

Because in 2024, Home Assistant still resets all the last updated times on every restart, I’m forced to use Input Datetimes to track when things last happened (last smoke alarm, last rain, etc.). But now we can’t add those to our devices.