Update to neohubapi 2.3 - Add support for profiles and repeaters

[ocrease]

This PR updates the neohubapi to version 2.3. The main changes are:

• The api now exposes profile data
• Some new helper methods have been added to clean up the code here (rather than manually creating a message to send)
• Support for repeaters has been added back in
• Away/Holiday sensors on the hub entity

Profiles

The biggest change in this PR is to add support for profiles (#27):

It add a select entity to allow changing the profile and a few helper sensors for current and next temperature and next time. For timers it just has the current profile state (on or off) and the next time.

Details for Profile 0 (where the profile is directly stored on the thermostat) are also shown if that is the current profile.

Repeaters

There is not a lot that can be done with repeaters, but there is a request in #196 to be able to remove them, so it should now be possible to see what is there and there is also a button to remove them. I haven't been able to test this since I don't have any repeaters. I am hoping @PhillyGilly will be keen to try it out once merged

Away/Holiday on hub device

Added some sensors to report the away/holiday state of the hub. If it is on holiday, the holiday end time is also reported. I do wander if it would be better to combine the two binary sensors of away and holiday. We could have a single binary sensor. If it is on and there is no end time, it means away (eg permanently away), but if an end time is defined then it is a holiday (eg away with a known end date). If we change it, we should combine the binary sensor on the thermostats as well

[ocrease]

@MindrustUK thanks for merging. I think that's the bulk of the changes I had planned. We should let this version bed in for a while, but maybe it's a good point to consider what else needs to be done before cutting the next release? Not before January at the very earliest, don't want to break people's heating over Christmas!

[MindrustUK]

Hi @ocrease sounds good to me. I've been thinking about a good cut off point for a while now. Let's let the current release bed in and aim for a full version 3 release towards the middle of January. Agreed on the Christmas change freeze!

[ocrease]

@MindrustUK, when would you like to target a release? Maybe mid to late next week?

[PhillyGilly]

I'm not sure if I have already confirmed but the remove repeater function works as expected. Thanks

[MindrustUK]

@ocrease I guess we can go for 16th / 17th. For V3.0.0.

[ocrease]

Sounds good

[MindrustUK]

@ocrease I've released version v3.0.0, it looks like the HACS looping bug of "Updated to latest version" has appeared again for some odd reason. Not sure why it's not happy with v3.0.0 as a release name.

[MindrustUK]

@ocrease I suspect HACS was having a disambiguation issue, I've published as "v3.0.0-release". I'm guessing v3.0.0 was matching v3.0.0* so was causing the loop.

[ocrease]

@MindrustUK maybe it needed to be v3.0.1? One to try next time when moving from a pre release to release

[PhillyGilly]

I went to look for 3.0.0 when you said it would be released, but just stayed in the last beta which was run really well over the holidays (still haven't found time to do the automation blueprint:-( )

[ocrease]

The download counter has to be my favourite feature of the new release 😆