That’s strange. I just took a switch devie, added power entity via settings, then added a second power entity in repair mode and both are shown and updated.
Can you please try again and after capability removal send a diagnostics report? Hopefully I can see something useful.
Here you go:
4ecb57f9-884f-49a5-b7c6-a8034557931a
I have no idea…
- The capability data to add looks good
- Capability is added
- On devie init, the capability seems to be there
But if that would be true, you wouldn’t be able to add it a second time.
Can you just restart your Homey? Just to be sure.
PS: I’m also on 12.13.0-rc.6, so this shouldn’t be a reason.
Just tried again after restart
ee4f2091-f717-4983-8883-4de5d57dc325
Hi,
I am experiencing an issue with the management of my solar system and consumption metrics in Homey.
I am aware that this is a very specific request related to my setup. However, other users with different systems may have found a working solution that I could try to adapt to my use case, since each sensor requires specific data to be configured.
I have created four different custom devices to manage Battery, Panels, Grid, and Loads.
These are the data I receive from Home Assistant.
Data From Home Assistant
{
“sensor.epcube_battery_daily_charge”: {
“entity_id”: “sensor.epcube_battery_daily_charge”,
“state”: “0.7”,
“attributes”: {
“state_class”: “total”,
“unit_of_measurement”: “kWh”,
“device_class”: “energy”,
“friendly_name”: “Battery Daily Charge”
},
“last_changed”: “2026-03-26T10:25:32.410693+00:00”,
“last_reported”: “2026-03-26T10:25:32.410693+00:00”,
“last_updated”: “2026-03-26T10:25:32.410693+00:00”,
“homey_capability”: “meter_power.sensor.epcube_battery_daily_charge”
},
“sensor.epcube_battery_daily_discharge”: {
“entity_id”: “sensor.epcube_battery_daily_discharge”,
“state”: “2.96”,
“attributes”: {
“state_class”: “total”,
“unit_of_measurement”: “kWh”,
“device_class”: “energy”,
“friendly_name”: “Battery Daily Discharge”
},
“last_changed”: “2026-03-26T11:01:32.431953+00:00”,
“last_reported”: “2026-03-26T11:01:32.431953+00:00”,
“last_updated”: “2026-03-26T11:01:32.431953+00:00”,
“homey_capability”: “meter_power.sensor.epcube_battery_daily_discharge”
},
“sensor.epcube_batterycurrentelectricity”: {
“entity_id”: “sensor.epcube_batterycurrentelectricity”,
“state”: “1.15”,
“attributes”: {
“state_class”: “measurement”,
“unit_of_measurement”: “kWh”,
“friendly_name”: “EPCUBE Battery Energy Current”
},
“last_changed”: “2026-03-26T11:01:32.427327+00:00”,
“last_reported”: “2026-03-26T11:01:32.427327+00:00”,
“last_updated”: “2026-03-26T11:01:32.427327+00:00”,
“homey_capability”: “meter_power.sensor.epcube_batterycurrentelectricity”
},
“sensor.epcube_battery_power”: {
“entity_id”: “sensor.epcube_battery_power”,
“state”: “-0.12”,
“attributes”: {
“state_class”: “measurement”,
“unit_of_measurement”: “kW”,
“device_class”: “power”,
“friendly_name”: “Battery Power (Live)”
},
“last_changed”: “2026-03-26T11:01:32.432021+00:00”,
“last_reported”: “2026-03-26T11:01:32.432021+00:00”,
“last_updated”: “2026-03-26T11:01:32.432021+00:00”,
“homey_capability”: “measure_numeric”
}
}
{
“sensor.epcube_gridelectricityfrom”: {
“entity_id”: “sensor.epcube_gridelectricityfrom”,
“state”: “1.28”,
“attributes”: {
“state_class”: “total_increasing”,
“unit_of_measurement”: “kWh”,
“device_class”: “energy”,
“friendly_name”: “EPCUBE Grid Energy From”
},
“last_changed”: “2026-03-26T10:43:32.577278+00:00”,
“last_reported”: “2026-03-26T10:43:32.577278+00:00”,
“last_updated”: “2026-03-26T10:43:32.577278+00:00”,
“homey_capability”: “meter_power.sensor.epcube_gridelectricityfrom”
},
“sensor.epcube_gridelectricityto”: {
“entity_id”: “sensor.epcube_gridelectricityto”,
“state”: “0.0”,
“attributes”: {
“state_class”: “total_increasing”,
“unit_of_measurement”: “kWh”,
“device_class”: “energy”,
“friendly_name”: “EPCUBE Grid Energy To”
},
“last_changed”: “2026-03-26T00:00:01.683380+00:00”,
“last_reported”: “2026-03-26T00:00:01.683380+00:00”,
“last_updated”: “2026-03-26T00:00:01.683380+00:00”,
“homey_capability”: “meter_power.sensor.epcube_gridelectricityto”
},
“sensor.epcube_gridpower”: {
“entity_id”: “sensor.epcube_gridpower”,
“state”: “0.0”,
“attributes”: {
“state_class”: “measurement”,
“unit_of_measurement”: “W”,
“device_class”: “power”,
“friendly_name”: “EPCUBE Grid Power”
},
“last_changed”: “2026-03-26T08:01:26.480860+00:00”,
“last_reported”: “2026-03-26T08:01:26.480860+00:00”,
“last_updated”: “2026-03-26T08:01:26.480860+00:00”,
“homey_capability”: “measure_power”
}
}
{
“sensor.epcube_backupflowpower”: {
“entity_id”: “sensor.epcube_backupflowpower”,
“state”: “1340.0”,
“attributes”: {
“state_class”: “measurement”,
“unit_of_measurement”: “W”,
“device_class”: “power”,
“friendly_name”: “EPCUBE Home Power Consumption Flow”
},
“last_changed”: “2026-03-26T11:02:30.671814+00:00”,
“last_reported”: “2026-03-26T11:02:30.671814+00:00”,
“last_updated”: “2026-03-26T11:02:30.671814+00:00”,
“homey_capability”: “measure_power”
},
“sensor.epcube_backupelectricity”: {
“entity_id”: “sensor.epcube_backupelectricity”,
“state”: “5.85”,
“attributes”: {
“state_class”: “total_increasing”,
“unit_of_measurement”: “kWh”,
“device_class”: “energy”,
“friendly_name”: “EPCUBE Home Energy Consumption”
},
“last_changed”: “2026-03-26T11:02:30.671205+00:00”,
“last_reported”: “2026-03-26T11:02:30.671205+00:00”,
“last_updated”: “2026-03-26T11:02:30.671205+00:00”,
“homey_capability”: “meter_power.sensor.epcube_backupelectricity”
},
“select.ep_cube_modalita”: {
“entity_id”: “select.ep_cube_modalita”,
“state”: “Autoconsumo”,
“attributes”: {
“options”: [
“Autoconsumo”,
“Tariffazione”,
“Backup”
],
“icon”: “mdi:transmission-tower”,
“friendly_name”: “EP CUBE Modalità”
},
“last_changed”: “2026-03-24T08:59:43.301731+00:00”,
“last_reported”: “2026-03-24T08:59:43.301731+00:00”,
“last_updated”: “2026-03-24T08:59:43.301731+00:00”,
“homey_capability”: “mode_select.select.ep_cube_modalita”
}
}
{
“sensor.epcube_solardcpower”: {
“entity_id”: “sensor.epcube_solardcpower”,
“state”: “1100.0”,
“attributes”: {
“state_class”: “measurement”,
“unit_of_measurement”: “W”,
“device_class”: “power”,
“friendly_name”: “EPCUBE Solar DC Power”
},
“last_changed”: “2026-03-26T11:03:31.536217+00:00”,
“last_reported”: “2026-03-26T11:03:31.536217+00:00”,
“last_updated”: “2026-03-26T11:03:31.536217+00:00”,
“homey_capability”: “measure_power”
},
“sensor.epcube_solardcelectricity”: {
“entity_id”: “sensor.epcube_solardcelectricity”,
“state”: “2.5”,
“attributes”: {
“state_class”: “total_increasing”,
“unit_of_measurement”: “kWh”,
“device_class”: “energy”,
“friendly_name”: “EPCUBE Solar DC Energy”
},
“last_changed”: “2026-03-26T11:03:31.535327+00:00”,
“last_reported”: “2026-03-26T11:03:31.535327+00:00”,
“last_updated”: “2026-03-26T11:03:31.535327+00:00”,
“homey_capability”: “meter_power.sensor.epcube_solardcelectricity”
}
}
Could someone help me with the Advanced Settings of the various devices so that the information is displayed properly?
At the moment, I can only see the energy imported from or exported to the grid and the solar panel production. In addition, the exported/sold energy values are incorrect. I also have no information about battery usage or the total household consumption.
Yesterday I saw this. 154kWh Exported are impossible
Today from epcube system I see this
From Homey
Hi Simone,
yor devices are correct I think.
Grid in/out is shown in the chart in blue/green color.
Solar production is shown in yellow.
Battery is showing negative value that is correct for discharge.
The battery should show up at the house
If you meant the epcube chart, then it’s not possible to show all information Homey in one chart.
So all seems to be fine in your data.
Or are you missuing values (or are there wrong values).
Homey doesn’t show a chart for house usage. It only shows the single devices defined as top consumers. I just hide all consumers (it makes no sense if only some devices have energy data) and added home usage as consumer (it shows up as consumer if it has measure_power capability and if it’s not defined as main meter).
Only way to show this data as chart is as insights chart (battery, home usage etc) in HomeyDashboard, but not as a one in all chart.
The devices report correct data. What I cannot achieve is displaying this data graphically in the Energy tab of Homey. In that tab, I can correctly see the amount of power imported from the grid and the solar production, but I cannot see the amount of power drawn from the battery, nor the energy exported to the grid, which previously appeared excessively high.
I assume the last two issues are caused by incorrect device configuration.
Additionally, I cannot understand how to view the total consumption, even though the device exposes the measure_power value.
“sensor.epcube_backupflowpower”: {
“entity_id”: “sensor.epcube_backupflowpower”,
“state”: “280.0”,
“attributes”: {
“state_class”: “measurement”,
“unit_of_measurement”: “W”,
“device_class”: “power”,
“friendly_name”: “EPCUBE Home Power Consumption Flow”
},
“last_changed”: “2026-03-27T07:27:55.412347+00:00”,
“last_reported”: “2026-03-27T07:27:55.412347+00:00”,
“last_updated”: “2026-03-27T07:27:55.412347+00:00”,
“homey_capability”: “measure_power”
}
Hello, great App. I have one issue though.
The Thermostat Capability feature is a very helpful addition. However, only one thermostat can be used per device capability. Is it possible to expand the app so that multiple thermostats can be used? For example, I would need comfort-, normal-, and reduced- temperature settings.
(Multiple entities can already be integrated with the sliders)
The background is the integration of Viessmann heating control into Homey. A wide variety of parameters need to be set.
Unfortunately, the existing Viessmann apps are of limited use because both are missing essential entities.
Hi,
this is not how it would work in Homey.
A thermostat device can only have one GUI control - defined by target_temperature and measure_temperature capabilities. It’s not possible to add more.
Such mode dependent values would be set as device settings for a manufacturer app.
So you can only deal with sliders or just set it once in HA.
Then use the mode selection to switch the modes. In normal case, the termostat should now use the predefined mode settings.
When using the advanced virtual device (AVD) of the Device Capabilities app, it’s possible to have multiple thermostats in one device.
When you add the 3 separate HA thermostats to Homey, and hide those in the UI (possible since Mob v9.9.0 Web v1.16.0), you can have those mirrored to an aforementioned AVD.
AVD settings:
Choose the desired thermostat device and entities @ “Device” and “Property” fields reflecting the measure_temperature and target_temperature capabilities to automatically create a thermostat UI.
No flows needed!
It can look a bit intimidating at first, but you’ll need to select and enter just a few fields each thermostat
Are they added as subcapability? I think I already tested it and it only worked for main capabilities. But perhaps Athom added this feature in the meantime.
Then I have to check if I can extend the “add input_number entity as thermostat” feature if subcapabilities would pe possible.
Hi Ronny,
Yeah I’ve tried with a custom device, but the “trick” Arie (Godschalk) uses didn’t work.
I’ve tried with a combo of main and subcapababilities, just similar to the screenshot below.
The AVD capabilities look like this below, indeed the additional thermostats are added as subcapababilities.
This has been possible since Arie started the app back in '21 - '22
Hi Peter,
Thanks so much for the tip. I actually found a ready-made template in the Advanced Capabilities section that matches the one you described in your post.
With about 10 adjustable parameters and roughly twenty sensors (which need to be imported first using the HA Community app), it does take a bit of work.
I’ve already set up the temperature readings and a few other values. It’s works.
I can also add several HA entities as target_temperature.
This is one main and one subcapability.
The difference is:
- When adding an entity as subcapability, the capability ID is defined based on entity:
measure_numeric.input_number.thermostat - For most capabiities this is working.
- It seems, not for thermostats
- But when using only one subcapability identifier, it works:
measure_numeric.01
I think I have to add an input field for optional subcapability name below select box 
Great find, Ronny.
I just tested, adding additional thermostats to a HAC app climate device, and it works when using (consecutive) numbers as part of subcapababilities, like
measure_temperature
target_temperature
measure_temperature.02
target_temperature.02
measure_temperature.03
target_temperature.03
or even:
measure_temperature.kamer04
target_temperature.kamer04
New test version 1.15.1:
- Fixed subcapability issue for thermostat capability (input_number entities).
When using subcapability (to add more than one thermostat), the subcapability ID is now fixed to not use additional points in subcabability to bypass the Homey issue.
Use:
-
When adding an input_number a single thermostat, use the “add as main capability” option. This way, a target_temperature caopabilility is added.
-
When adding additional thermostat, don’t activate the “add as main capability”. This way, the entity part is used as subcapability (poit replaced with underline for thermostat).
@Peter_Kawa @Heiko_B FYI and test. It should be possible now to add several thermostats 
New test version 1.15.2
- prevents unneeded mode list updates
Hello there General Winkler,
and once again: thank you for your awesome service to this community so far! I deeply appreciate all your work.
Unfortunately this is not the only things I got to say today.
Since Home Assistant Core 2026.3, color temperature commands from Homey to HA lights no longer work. The Homey flow card “Set a temperature” (and equivalents) sends the command, but the resulting light.turn_on service call arriving at HA contains no color temperature parameter at all – only brightness. The light therefore does not change its color temperature.
In the following I will use HACA short for Home Assistant Community App, I hope this is okay.
Environment
- HACA app version: 1.15.1
- Home Assistant Core: 2026.4.4
- Home Assistant OS: 17.2
- Affected lights: confirmed across multiple brands and Z2M-bridged devices (innr RB 286 C, Philips Hue LCL007 / LCA001, Paul Neuhaus NLG-RGB-TW / NLG-TW). Issue is independent of the bulb.
Reproduction
- Add any HA light entity with color temperature support to Homey via HACA.
- In Homey, create a flow with the card “Set a temperature” (e.g. 50%).
- In Home Assistant, open Developer Tools → Events → listen for
call_service. - Trigger the flow.
Observed result
The captured event contains no color temperature parameter:
event_type: call_service
data:
domain: light
service: turn_on
service_data:
entity_id: light.wohnzimmer_deckenleuchte
brightness: 255
On/off, brightness and RGB color all continue to work normally.
Root cause (or what it seems to be to me)
Home Assistant 2026.3 removed the deprecated mired-based light features:
- The state attributes
color_temp,min_miredsandmax_miredsare no longer exposed. - The
light.turn_onservice no longer accepts thecolor_temp(mireds) orkelvinparameters. - Only
color_temp_kelvin,min_color_temp_kelvinandmax_color_temp_kelvinremain.
Reference: Remove deprecated light features | Home Assistant Developer Docs
The affected entities now only expose min_color_temp_kelvin / max_color_temp_kelvin, e.g.:
min_color_temp_kelvin: 1801
max_color_temp_kelvin: 6535
supported_color_modes: [color_temp, xy]
It appears the HACA still relies on min_mireds / max_mireds to compute the target value from Homey’s normalized 0–1 input. When those attributes are missing, the conversion fails and the color temperature parameter is dropped from the outgoing service call entirely – which matches the observed behavior.
My thoughts for a fix on this issue
- Read the range from
min_color_temp_kelvin/max_color_temp_kelvininstead ofmin_mireds/max_mireds(with backward-compatible fallback). - Send
color_temp_kelvinin thelight.turn_onservice call instead ofcolor_temp. - Update the state-reading side to use
color_temp_kelvinfor displaying and updating the Homeylight_temperaturecapability.
Another problem with NLG-Lights in general
I use two light from Paul Neuhaus, NLG for short, and the HACA sends a turn_on with a brightness of 0 - which does not work for these lamps:
event_type: call_service
data:
domain: light
service: turn_on
service_data:
entity_id: light.kuche_deckenfluter
brightness: 0
Happy to provide additional logs or test a pre-release if useful. Always feel free to ask for anything that may help from me.
Hi, thanks for reporting this issue. I read about these color temperatures months ago but didn’t know they really changed/removed it.
I will take a look at it, but it wil take week until I will have time to fix it. If I need some details, I will ask via PM (in german ).
