Backport Home Assistant PR into custom_component

[zxdavb]

This is the same as the PR, but with changes to imports as required by a custom component.

Also some minor improvements to README.md.

This is running with no logged errors in my production system (on HA 0.89.x)

[zxdavb]

OK, just run it for the first time - fantastic!

But I can't see a DHW/boiler/water_heater (I know you have no water_heater, but some people implement them as a climate entity?

OK, I see in the client API you don't have a getDHWList.

[GeoffAtHome]

Another question - should a sensor return a JSON object for each value (battery level, temperature, luminance, motion) or should each value be a unique sensor in its own right?

[GeoffAtHome]

Happy to add getDHWList but don't have one of these so never added it.

[zxdavb]

Another question - should a sensor return a JSON object for each value (battery level, temperature, luminance, motion) or should each value be a unique sensor in its own right?

Short answer: sensors only have a single value, the state property, and other defined attributes, such as unit_of_measurement, and name. Everything else for that sensor should be placed in the device_state_attributes() property, which you can make anything you want, including JSON.

I think, strictly speaking (and HA can be quite strict), that each Zone would be a single Climate object, and the sensors should be in device_state_attibutes rather than separate entities - I was a little surprised HA have accepted your schema, but sometimes they can be fooled...

Here's an example for an evohome (similar to geniushub) Zone, slightly edited:

2019-03-18 17:17:11 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=climate.main_room, 
  old_state=<state climate.main_room=Auto; current_temperature=19.2, min_temp=5.5, max_temp=24.0, temperature=20.0, target_temp_step=0.5, operation_mode=FollowSchedule, operation_list=['FollowSchedule', 'TemporaryOverride', 'PermanentOverride'], status=zoneId=3432521, temperatureStatus=temperature=19.5, isAvailable=True, activeFaults=[], setpointStatus=targetHeatTemperature=20.0, setpointMode=FollowSchedule, name=Main Room, status=Scheduled, mode=Off, apiV1Status=temp=19.19, setpoint=20.0, switchpoints=, friendly_name=Main Room, icon=mdi:radiator, supported_features=4225 @ 2019-03-18T14:26:55.020642+00:00>, 
  new_state=<state climate.main_room=Auto; current_temperature=19.4, min_temp=5.5, max_temp=24.0, temperature=20.0, target_temp_step=0.5, operation_mode=FollowSchedule, operation_list=['FollowSchedule', 'TemporaryOverride', 'PermanentOverride'], status=zoneId=3432521, temperatureStatus=temperature=19.5, isAvailable=True, activeFaults=[], setpointStatus=targetHeatTemperature=20.0, setpointMode=FollowSchedule, name=Main Room, status=Scheduled, mode=Off, apiV1Status=temp=19.38, setpoint=20.0, switchpoints=, friendly_name=Main Room, icon=mdi:radiator, supported_features=4225 @ 2019-03-18T14:26:55.020642+00:00>>

1) the 'primary' attribute is the state() property) operating_mode (or current_operation, I forget) - 'Auto' here 2) some recognized 'secondary' attributes - e.g. current_temperature, temperature (setpoint/target temperature) 3) the option for everything else in the device_state_attributes() property - from status=zoneId=3432521 onwards, which is JSON (the a=b=c is just a display bug):

status = {
    "zoneId": "3449740",
    "temperatureStatus": {
        "isAvailable": False
    },
    "activeFaults": [],
    "setpointStatus": {
        "targetHeatTemperature": 5.0,
        "setpointMode": "FollowSchedule"
    },
    "name": "Test"
}