Setup_platform vs setup_platform

Development
1

I’m currently looking at the Hive integration, and noticed that it only exposes entities, and not devices.

While this seems fine for some of the functionality, there are a lot of areas where a device seems to be necessary. For example in the conditions and actions in automations, there are a lot of options where you need to select from a list of devices - if the entity is not assiciated with a device, then there is no way to query or act on those entities.

So, I set out to see if I could change this. It would seem that there are 2 ways of creating entities…

async_setup_platform
async_setup_entry

Here’s my understanding. The first uses the platform, (in this case the Hive API) to build the set of entities on the fly. The second uses the configuration to create them. In the second model, you’d have the platform enumerate the devices/entities when the platform is configured, and then store the configuration.

However, it seems that for the async_setup_platform, it is only possible to set up entities, and not devices. I quote from the Architecuture documentation:

“Entity device info is only read if the entity is loaded via a config entry”

So, although I have added a device_info function, it still doesn’t create the devices.

Why is this? Why can’t I associate platform-generated entities with devices? Or am I missing something?

2

So I think I understand why this is. Stuff that’s generated on the fly could come and go, and so can’t really be tied to configuration. I think I probably want to change how this integration works, so that it does more of a sort of “discovery”, and then configures the devices, so that then you can assign them to areas, put them on floorplans, and do all of that funky kind of stuff.

3

You can create sensors from such information but I think what you are striving for is not just to read values but to also write them ???

This is a bit like the nest scenario where they closed throttled down the API to try to force people to buy from ‘their’ supported platform.

Good Luck with pulling ‘that’ gordian knot apart.

You could just read the temperature into your own climate component and do all the ‘smart things’ (not a copyright infringement - honest ! ) in there.

e.g. : - Change set point on door open, house unoccupied, day temperature, evening temperature and night temperature.
You have to be careful about changing boiler operational temperature as if set ‘much’ (read ‘at all’) above obtaining a return temperature >~ 54° C then you won’t gain ANY of the major efficiencies of a condensing boiler (the phase change on the outgoing water vapour) - This only applies if you have a boiler capable of such (a more expensive option)
I realise this will turn your expensive thermostat into a plain thermometer - but you did pay for a very pretty one :smiley:

4

@martinlong1978, What is it that you are trying to achieve that you cant with the current implementation?

If you use the Hive custom component then more sensors are added to exposing more of the data from Hive

1 Like
5

The hive system doesn’t allow adjustment of the boiler output temperature. That is set on the boiler.

It does however, allow setting of individual TRV setpoints, as well as the overall “house” thermostat, via commands to the API (I’m not sure if pyhiveapi exposes this (yet), but the beekeeper REST API it uses certainly does (I’ve used and modified parts of the Smartthings integration).

There are things I want to do, like boost the towel radiators in the bathrooms after the humidity sensor detects that you’ve had a shower. I’m currently able to do them using WebCoRE, but I’m not trying to switch everything to HA.

6

That’s a nice idea, you could even turn down other radiators (not living area) to cater for an assumed temperature up swing.
I like the idea but having it split across different platforms sort of limits your user base to those that have them. Might be worth thinking about
Regardless, good luck

1 Like