0.87: SmartThings, Areas and Entity Registry UI.

Blog
1

![](upload://jMYQhAc9RGusj7yL2ih73pBnnF0.png)

Today we’re releasing Home Assistant 0.87, our third release of the year. Besides a bunch of bugs squashing and performance improvements, we got some cool new features too.

Let’s start with the big one: we now support SmartThings. Via a custom app that can be installed inside SmartThings, you can now push the state of each device, as soon as it changes, to Home Assistant. No more fiddling with MQTT bridges or other solutions. Big shoutout to @andrewsayre for making this possible. Have a look at the SmartThings docs to get started.

New in this release is a new area feature thanks to @Kane610. Areas will allow users to organize their devices by their physical area, like kitchen or living room. This will unlock a whole new range of possible new features (of which none are implemented yet). With this release, users will just be able to manage areas in the configuration panel and place devices in areas via the integration page. In the future, we’re planning to add area based user permissions and a Lovelace area card. If you can’t wait to start leveraging areas today, [@thomasloven] has created a custom Lovelace card that can leverage areas.

This release also includes a UI to manage the entity registry. The entity registry contains all entities with unique IDs that Home Assistant has ever seen. It will allow users to quickly rename entities, change entity IDs or have Home Assistant forget entities that are no longer active.

We didn’t forget about the frontend in this release. In the last release we introduced Lovelace, so for this release we focused on bug squashing, performance improvements and usability. The YAML editor is now rendered using a full editor including line numbers thanks to @bramkragten. There is also a new system health component that will help users diagnose problems from the “info” developer tool. See changelog for the frontend.

In this release we have also upgraded the Material Design Icons to 3.3.92, which renames some icons. Make sure to check their changelog.

If you prefer a podcast over release notes, check out the Hass Podcast in which Phil and Rohan discuss each new Home Assistant release and keep a tap on what’s happening in the home automation space.

New Platforms

New Features

If you need help…

…don’t hesitate to use our very active forums or join us for a little chat. The release notes have comments enabled but it’s preferred if you use the former communication channels. Thanks.

Reporting Issues

Experiencing issues introduced by this release? Please report them in our issue tracker. Make sure to fill in all fields of the issue template.

Breaking Changes

  • SolarEdge sensors: This PR changes the entity names of this sensor and the monitoring condition keys in the configuration: sensor.solaredge_current_power -> sensor.solaredge_current_power, sensor.solaredge_last_day_data -> sensor.solaredge_energy_today, sensor.solaredge_last_month_data -> sensor.solaredge_energy_this_month, sensor.solaredge_last_year_data -> sensor.solaredge_energy_this_year, sensor.solaredge_life_time_data -> sensor.solaredge_lifetime_energy, (@LouisMT - #20109) (sensor.solaredge docs) (breaking change)
  • Geolocation is no longer creating a default group. (@exxamalte - #20338) (geo_location docs) (breaking change)
  • The Dovado sensor platform has been broken up into a Dovado component with sensor and notify platforms. The configuration variables have been changed. Please refer to the documentation for the correct configuration. (@rohankapoorcom - #20339) (dovado docs) (sensor.dovado docs) (breaking change)
  • Brottsplatskartan: The incident type count is reset every day. Before this change, it didn’t reset until you restarted Home assistant. (@chrillux - #20117) (sensor.brottsplatskartan docs) (breaking change)
  • Ambient PWS has new configuration and entity IDs will change. Configure it now via the integrations page. (@bachya - #20332) (ambient_station docs) (sensor.ambient_station docs) (breaking change)
  • New Transmission component. With the introduction of the Transmission component, the configuration for Transmission sensor and switch has been moved to the component configuration. Configuration must be changed accordingly. (@MatteGary - #19230) (transmission docs) (sensor.transmission docs) (breaking change) (new-platform)
  • The alarm control panel will now flag mistyped configs from configuration.yaml correctly as invalid, instead of just ignoring them. (@emontnemery - #20224) (alarm_control_panel docs) (breaking change)
  • MQTT platforms will now flag mistyped configs from configuration.yaml correctly as invalid, instead of just ignoring them. (@emontnemery - #20562) (mqtt docs) (breaking change)

Beta Fixes

All changes

This is a companion discussion topic for the original entry at https://www.home-assistant.io/blog/2019/01/30/release-87/
3

So the smart things component allows you to expose your home assistant entities to smart things ? Abit like homekit ? Or?

4

The other way around, SmartThings devices in Home Assistant.

1 Like
5

Right is it possible to expose HA to smart things ? Like homekit?

6

I do not understand the UTILITY METER, wehen it says

“Both track the same sensor ( sensor.energy ) which continously monitors the energy consumed.”

utility_meter:
  energy:
    source: sensor.energy_in_kwh

but are we talking of POWER (KW) or ENERGY (KWH)?? Because by each instant in time you have the power not the energy: the energy is the power in an interval of time.

Basically I have my Efergy sensor giving me a KW value (not KWh = kilowattHOUR), is that sensor that I need to put in Utility meter?

If so its more correct to call it kW (not kWh)

7

I tried switching over from MQTT to the Smartthings component, but when I click on the app in the Smartthings Classic app it just says “Something went wrong.” I’m open the the internet using SSL behind a reverse proxy and every other integration that needed access the internet has worked. Anyone else have the same issue?

8

That sentence is in the context of multiple tariffs (peak, off-peak, etc) where a new sensor will show up for each of the tariffs, all new sensores tracking the same source.

But answering your question:

The utility meter tracks energy (therefore the unit is kWh), you need to use an ENERGY sensor as the source

If you have a sensor that provides you power, you can convert that sensor into an energy sensor. For that you can use Integration sensor (https://www.home-assistant.io/components/sensor.integration/#energy) which was also released in 0.87

2 Likes
9

What a sensor measure is power at a given moment . Energy is just power x time interval

10

Sorry, I don’t understand your comment, can you re-phrase ?

11

A sensor measure the power in the instant is measured. Energy is just those values in a time interval.
Utility meter i think is tracking power not energy. And from that (power) sensor values it calculates energy in an interval of time (hourly, daily, weekly and so on). Or not?

12

It depends on the sensor you have. There are sensors that provide you with power readings (in Watts) and sensors that provide you energy readings (in kiloWattshour - kWh)

The utility_meter will ONLY WORK with sensors that provide you ENERGY readings (kWh).

What I explained in my previous comment is that if you DON’T HAVE a sensor that provides you with ENERGY readings, but have a sensor that provides you POWER readings, you can calculate energy using the INTEGRATION SENSOR (energy is the integral of power over time, multiplying power * time is just a rough estimate). Now that you have the integration.sensor providing you with ENERGY readings, you can use it as a source for the utility_meter.

13

utility_meter is just making sure you reset your energy counters periodically, it does not transform your data from POWER to ENERGY.

to transform POWER to ENERGY you can use the integration sensor (see comment above)

14

I’m getting the same issue @JoeA Did you find a fix?

15

So if I understand correctly if you have sensors that measure W you first need to pipe them through the integration sensor and that output needs to go into the utility_meter component, right?

16

Right. Here is an example:

You already have sensor.current_power which provides you power usage (in Watts)

sensor:
  - platform: integration
    source: sensor.current_power
    name: energy_spent
    unit_prefix: k
    round: 2

utility_meter:
  daily_energy:
    source: sensor.energy_spent
    cycle: daily
1 Like
17

Therer is an issue, I think. By defaut

Yearly energy is unit_of_measurement: kWh
Monthly energy and weekly energy and dauily energy is unit_of_measurement: W (not KWh and not even Wh)
Hourlyenergy is unit_of_measurement: kWh

utility_meter:
  hourly_energy:
    source: sensor.total_energy_spent
    cycle: hourly
  daily_energy:
    source: sensor.total_energy_spent
    cycle: daily
  weekly_energy:
    source: sensor.total_energy_spent
    cycle: weekly
  monthly_energy:
    source: sensor.total_energy_spent
    cycle: monthly
  yearly_energy:
    source: sensor.total_energy_spent
    cycle: yearly

sensor:
  - platform: integration
    source: sensor.efergy_8xxxx
    name: total_energy_spent
    unit_prefix: k
    round: 2

Cattura
Cattura767×177 13.4 KB

Cattura2
Cattura2750×155 11.7 KB

18

The utility_meter inherits the unit_of_measurement from the source:

If yearly_energy is in kWh, I don’t see how the others could be in any other unit since they all share the same source…

19

I don’t know: the source is the same: sensor.total_energy_spent

20

please join me on discord, my handle is dgomes

21

I am not a programmer, I have a hard time understand what could be wrong. The integration sensor I think is working properly. I do not have discord, you want me to open an issue in github?

Cattura