Honeywell CH/DHW via RF - evohome, sundial, hometronics, chronotherm

[iMiMx (iMx)]

Way of the world - perhaps not worth buying a lottery ticket this week

[maesenator]

Those are wise words my friend…

[maesenator]

Got it all working. Thanks everyone for the help.
I’ve got roughly 23 entities showing up but roughly 80% of them are set to unavailable.
The controller is working perfectly (it’s in another room)

I tried moving the home assistant box around a bit to see if it’s a range issue but not much is changing.

I’m using a home assistant blue, in the back I also have a z-wave dongle inserted (also works on 868mhz because I’m in Europe). Could interference be the reason that most of the devices are set to unavailable or am I missing something?

It’s quite weird. As you can see in this screenshot I’ve got a single device where different entities are not available. In this screenshot you see I have a heat_demand and a temperature but not the battery or window sensor.

[iMiMx (iMx)]

@maesenator

I’ve got roughly 23 entities showing up but roughly 80% of them are set to unavailable.
The controller is working perfectly (it’s in another room)

Some devices have to be ‘sniffed’, rather than ‘queried’ - i.e they have to broadcast something, that may only be broadcast once a day (battery sensors), or every few hours, or when they make a call/change.

There will be a change coming where the state will be remembered, or assumed, but for now when you restart HA devices have to be ‘re-sniffed’ or discovered… so you may find you don’t have battery sensors, or not for very long, until you restart again.

[maesenator]

Perfect, that makes sense. Thanks again

[zxdavb (David Bonnes)]

@iMiMx

There will be a change coming where the state will be remembered

I have this feature working at home.

[maesenator]

I have a question / feature request / idea
The HR92 valves have unreliable temperature reporting because they’re so close to the radiator. If you depend on the internal temperature sensor then you will often find (unrealistic) spikes in your temperature charts.
In some cases, for example when you want the temp in the bathroom to be 23° for 30 minutes, the temperature in the room never truly hits the temperature you want. To solve this I have purchased an external honeywell temperature sensor for some rooms. However, that’s quite expensive…

I do have temperature sensors in every room. They come from A/C units or Z-wave multisensors.
Now, wouldn’t it be amazing if this integration could “spoof” a honeywell temperature sensor using the values of any home-assistant temperature sensor?.
Is this feasible?

[iMiMx (iMx)]

@maesenator

Now, wouldn’t it be amazing if this integration could “spoof” a honeywell temperature sensor using the values of any home-assistant temperature sensor? .
Is this feasible?

I think this is on the road-map somewhere - I seem to recall a discussion about this, someway way up there ^^^

Personally, I just have a normal TRV wide open in the bathrooms/toilet. I’m sure I read somewhere that with Evohome there should be at least 1 radiator set as such - so that there is always an outlet for heat, i.e to prevent all TRVs being closed potentially at any point.

And, generally, in our house there will always be a radiator on somewhere else, when we want the towel rails to be warm in the bathroom.

[maesenator]

Good to hear that it may be on the roadmap. I’ll try and find the discussion somewhere up there ^^

True about the open TRV, I have that in the garage (cat’s live there they also need warmth )
I also have a dump valve on the boiler so that in the event heat cannot dissipate it will be immediately returned to the boiler so that it recognizes the hot return temperature and stops heating.

[iMiMx (iMx)]

@maesenator

Good to hear that it may be on the roadmap. I’ll try and find the discussion somewhere up there ^^

Honeywell CH/DHW via RF - evohome, sundial, hometronics, chronotherm

Hello, I currently have a HGI80 connected to domoticz which I use to simulate evohome thermostats in some rooms (using Xiaomi temperature sensors). On the Home Assistant side I use the integration via the API of evohome website. I would be very interested to remove domoticz (it’s less stable than HA in my setup) and put everything in HA. I’ve tried to read this feed to see what is possible with the evohome_cc integration, but I cannot see if it enables also to simulate thermostats using a tempe…

That was it, it’s possible with Domoticz, planned for this.

[zxdavb (David Bonnes)]

@maesenator

Now, wouldn’t it be amazing if this integration could “spoof” a honeywell temperature sensor using the values of any home-assistant temperature sensor? .
Is this feasible?

Yes, this is planned. I have all the necessary hardware, but I am short on time. I can guarantee it will be in place by next winter.

[maesenator]

Nice. Thanks for the reply.

Will it work with the nanocul or will we need the new ATMega332u4?

[zxdavb (David Bonnes)]

@maesenator

Will it work with the nanocul or will we need the new ATMega332u4?

It will work with the nanoCUL (it may not work with a HGI80).

I will always support the nanoCUL - it will be supported as long is practical, and - for good reasons - I will likely be doing most development with it rather than a ATMega332u4 or even a HGI80 (although I was very kindly given the newer unit yesterday).

The truth is I’ll be switching between all three.

I cannot see any issue in the short term that will cause the nanoCUL to stop being usable - it’s just that the newer unit is more reliable.

[zxdavb (David Bonnes)]

Is anyone able/willing to help me create / integrate a custom lovelace card to include with this custom_component?

Not my area of expertise…

But we should be able to create a card with a bunch of radio buttons. one being the current system mode, plus an optional time until.

[TheMystery (Johnny)]

I am using the simpel thermostat card, is has everything except the time until sadly.
But maybe it can be build in this project?
Example of my card:

[zxdavb (David Bonnes)]

@TheMystery

simpel thermostat card,

Is that this custom card?
nervetattoo/simple-thermostat: A different take on the thermostat card for Home Assistant (github.com)

[zxdavb (David Bonnes)]

So: v0.7.7:

• save / restore state feature (you wont lose, e.g., battery state when restarting HA)
• system should update immediately after making a service call or similar - no need for very short scan_interval
• added custom mode as a preset
• added back in a lot of device state attributes, e.g. a device’s parent zone, and controller ID

Because of the restore state / rapid update features, I recommend a scan_interval of 300 (default) and no less than 60 seconds in any case (there is simply no need for updating more than once every 5 minutes)…

(that gives me an idea…)

It may be buggy - sorry: I have no test suite, only you mob - please test these new features.

[TheMystery (Johnny)]

Yes, this is the card.

[phdelodder (Philippe Delodder)]

Updated to the new version on my nanocul test environment. I’ll give it a few tests of my own.

I’m wondering could you have a look at https://github.com/zxdavb/evohome_cc/pull/25, as would make a bit easier to test it.

[TheMystery (Johnny)]

Just updated from 0.75 to 0.77 changed the config because it was changed in 0.76 to:

evohome_cc:
  scan_interval: 60
  serial_port: /dev/ttyUSB2
  packet_log: /home/homeassistant/packet.log
  config:
    max_zones: 6
  schema:
    controller: 01:155341
  allow_list:
    - 01:155341
    - 04:008512
    - 04:070150
    - 04:070154
    - 04:070160
    - 04:073460
    - 04:108167
    - 04:108169
    - 04:108171
    - 04:108173
    - 13:189740

now i get this error:

Apr 02 08:32:24 hassbian hass[4363]: 2021-04-02 08:32:24 WARNING (MainThread) [custom_components.evohome_cc] evohome_cc v0.7.7, using evohome_rf v0.7.7 - versions match (this is good)
Apr 02 08:32:26 hassbian hass[4363]: 2021-04-02 08:32:26 DEBUG (MainThread) [evohome_rf.schema] An allow_list has been created, length = 11
Apr 02 08:32:26 hassbian hass[4363]: 2021-04-02 08:32:26 WARNING (MainThread) [evohome_rf.transport] Using an allow_list: ['01:155341', '04:008512', '04:070150', '04:070154', '04:070160', '04:073460', '04:108167', '04:108169', '04:108171', '04:108173', '13:189740']
Apr 02 08:32:26 hassbian hass[4363]: 2021-04-02T08:32:26.703536 # evohome_rf 0.7.7
Apr 02 08:32:27 hassbian hass[4363]: 2021-04-02 08:32:27 ERROR (MainThread) [homeassistant.setup] Error during setup of component evohome_cc
Apr 02 08:32:27 hassbian hass[4363]: Traceback (most recent call last):
Apr 02 08:32:27 hassbian hass[4363]:   File "/srv/homeassistant/lib/python3.8/site-packages/homeassistant/setup.py", line 213, in _async_setup_component
Apr 02 08:32:27 hassbian hass[4363]:     result = await task
Apr 02 08:32:27 hassbian hass[4363]:   File "/home/homeassistant/.homeassistant/custom_components/evohome_cc/__init__.py", line 100, in async_setup
Apr 02 08:32:27 hassbian hass[4363]:     await broker.async_restore_client_state()
Apr 02 08:32:27 hassbian hass[4363]:   File "/home/homeassistant/.homeassistant/custom_components/evohome_cc/__init__.py", line 188, in async_restore_client_state
Apr 02 08:32:27 hassbian hass[4363]:     await self.client._set_state(**app_storage["client_state"])
Apr 02 08:32:27 hassbian hass[4363]: KeyError: 'client_state'