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

Share your Projects!
690

I noticed that the climate.* entities were named, the corresponding battery, window and heat_demand were not - not sure if that’s just me.

But I believe the climate entities SHOULD be named within about a minute, when evohome_cc queries the controller - if it can’t transmit, or the transmit from the nanoCUL is not received by the controller because of poor reception, then it takes longer as it has to sniff rather than query.

P.S. If you wrap your logs in the code formatting </>, from the menu bar, it’s easier to read :slight_smile:

691

When you are posting, it will help everyone if we use some basic formatting - such as the back-ticks when the text is from a log file:

2021-02-17T09:24:53.546972 091 RP — 10:071257 01:161604 --:------ 3220 005 00C0110000
2021-02-17T09:24:53.729004 071 RQ — 01:161604 10:071257 --:------ 3220 005 0000120000

For example, the lines above are preceded by 3 back-ticks & the word text, and followed by another 3 back-ticks like so:
```text
… log lines here …
```

Also: there is a wiki to read & edit - can I encourage people to contribute to it, and I will ‘tweak’ if if required. Please sign-post others to it contents as often as you can - this will make life easier for everyone & save me having to write things multiple times.

If I post a response here - perhaps someone can update the wiki: https://github.com/zxdavb/evohome_cc/wiki

Those nanoCULs that appear listen-only - it appears they are the exact same one I have (i.e. same eBay item number, pictures look the same), and is the one recommended above:https://www.ebay.co.uk/itm/372221622516 - I can say that the vendor has consistently been a good actor, so I am not sure what is happening there.

The reasons why it is not performing properly is being investigated by the firmware dev, here: https://github.com/ghoti57/evofw3/issues/6

There is another device in the works that may perform better: https://www.automatedhome.co.uk/vbulletin/showthread.php?6366-Introducing-the-HGI80-alternative-the-latest-DIY-kid-on-the-block

The only other viable alternative is a HGI80, and these are rare/expensive.

Things with evohome_cc is a bit messy at the the moment** (for those of you who pull directly from the evohome_rf repo), but I plan to push a new pair today.

See: https://github.com/zxdavb/evohome_cc/wiki/Tips-for-the-configuration.yaml-file

There are new features arriving, that I suggest you take advantage of. In addition, support for full schemas will come, which will help this limited to eavesdropping (listen-only) mode.

If you want help, you have to present information in a way that makes it easy for others to help. That includes collecting good logs & posting them in a good format, above.

At the moment, you’re required to produce packet logs for this integration to work:

evohome_cc:
  serial_port: /dev/ttyUSB1
  config:
    packet_log: /folder/packet.log

… this obligation will be dropped in future, when the code becomes stable.

People can always PM me 24 hour log files >24 hour log - they help me to improve the parsers (some stuff is still not fully understood), and - more importantly now - make evohome_rf more resilient.

To see how to check if your nanoCUL is transmitting OK, see: https://github.com/zxdavb/evohome_cc/wiki/How-to-check-your-nanoCUL-is-transmitting-OK

Could people update that wiki with data for:

  • what path to use for the packet log for a given install type
  • how to read that file

Missing zone names are an indication that RQ\0004 packets are not getting a RP from the controller - you need to know if that is being caused by a) a problematic (listen-only) nanoCUL,or; b) poor radio reception.

See the wiki, above for tips on how to do tell the difference. One trick is to press teh button on a HR92UK TRV, which will cause it to send an RQ/0004 packet & evohoem_rf can eavesdrop it, and *evohome_cc will then display it in HA.

Obviously a) does not apply to HGI80s.

1 Like
692

thanks a million David, I’m amazed by the support you - and others on this forum - offer. I’ll bookmark this so I will be able to supply more usable information in the future.

693

David, amazing work. I have a feature request if I may. I would imagine a lot of the functionality required is already in the evohome_rf library. If I actually had any idea what I was doing with Python I would take a look myself…

Would it be possible to add a feature where a normal HA temperature sensor could be exposed to the RF Ramesis bus as a room thermostat/actual temp? Idea being one could use it instead of the internal stat in the HR92 TRV, much like when binding a Y87RF2023 to act as a zone thermostat.

I guess it would need a emulated bind function, so it can be bound on the EvoTouch to the zone, then regular actual temp broadcasts from its address…

This would allow much more accurate room stats away from the TRV to be used as the actual temp for the zone. In my case I have some wall mounted KNX stats in most of the rooms which are much more accurate than the TRV stat. Would be amazing to be able to use them. Using HA to expose the temp would allow the use of say z-wave/zigbee temperature sensors etc.

I have used them before as references, but the logic always works against the Evotouch which is using the bound TRV stat for the actual temp.

I hope this makes sense!

694

Yes - this is on the to-do list.

695

Thanks for all the good work.

696

I can’t find the setpoint value/target temperature in Grafana (data stored in influx db), any suggestions how to query thuis? It is visible in the entity card as a graph, so the data is available.
I do see a heat demand percentage in the query tool, also interesting, but I would like to relate also to the set temperature.

697

Just installed the latest evofw3 (0.6.8) on a nanoCUL and the latest evohome_cc, the ‘Check Configuration’ will not finish - it just keeps spinning.

If I #-out the evohome_cc configuration, it then completes. Same configuration that was working with earlier versions, without any changes.

evohome_cc:
  scan_interval: 60
  serial_port: /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0
  config:
    packet_log: /config/packet.log
  schema:
    controller: 01:xxxxxx
#  ignore_list:

Just curious to see if anyone else is/has seen the same? Before I start digging further…

698

@iMiMx You need to provide a HA log file, if you wish for me to help.

699

Understood. I shall revisit when I have some hardware that is capable of TX-ing - the eBay seller has not responded to any messages, so I shall have to look at other options.

Even with my nanoCUL within metres of the controller, I am unable to force an RP reply to an RQ message - the evofw3 dev believes it to be faulty hardware.

700

I haev the same hardware nanocul and also getting the no tx issue (well i cant set temperatures/modes etc…), but im ok with just listening at the moment anyway.
I’ve just gone through HACS and updated the honeywell_rf integration and rebooted homeassistant.
Ive got an issue popping up, this is in the log:-

Logger: homeassistant.util.package
Source: util/package.py:85
First occurred: 9:09:37 AM (1 occurrences)
Last logged: 9:09:37 AM

Unable to install package evohome-rf==0.5.6: ERROR: Could not find a version that satisfies the requirement evohome-rf==0.5.6 (from versions: 0.2.0, 0.2.1, 0.2.2, 0.2.3, 0.2.4, 0.2.5, 0.3.0, 0.3.1, 0.3.2, 0.3.3, 0.3.4, 0.3.5, 0.4.0, 0.4.2, 0.4.3, 0.5.0, 0.5.1, 0.5.2, 0.5.4, 0.5.5) ERROR: No matching distribution found for evohome-rf==0.5.6 WARNING: You are using pip version 20.2.4; however, version 21.0.1 is available. You should consider upgrading via the '/usr/local/bin/python3 -m pip install --upgrade pip' command.

I was running 0.5.5 for both rf and cc, i’m not seeing a recent _rf on github. Is this correct?

701

For me the grafana chart of both setpoint and actual temp is done like this:

Setpoint:
SELECT max(“temperature”) FROM “state” WHERE (“entity_id” = ‘(—ROOM NAME HERE—’) AND $timeFilter GROUP BY time($__interval) fill(previous)

Actual Temp:
SELECT max(“value”) FROM “°C” WHERE (“entity_id” = ‘(ROOM_ID_temperature’) AND $timeFilter GROUP BY time($__interval) fill(previous)

702

Good spot - latest version is 0.5.5:

If you edit /config/custom_components/evohome_cc/manifest.json, you can manually change it:

    "requirements": [
      "evohome-rf==0.5.5", "pyserial-asyncio==0.5"

This then resolves my cannot ‘Check Configuration’ problem, as presumably it was then failing on the dependencies. Albeit with the anticipated error:

ERROR (MainThread) [custom_components.evohome_cc] evohome_cc v0.5.6, using evohome_rf v0.5.5 - versions don't match (this is bad)

1 Like
703

Great! this works, took me a while to find out how to do this from within the GUI (db queries aren’t really my thing), I still have a lot to learn.

The GUI query to show the Evohome_cc room target temperature:

target temp evohome
target temp evohome928×251 14.9 KB

(Thanks to Glanerbronx)

704

Is it possible to limit the size of log file? Or set-up it to fixed size value? Then overwrite the data if size is going to reach the limit value…

705

Is it possible to limit the size of log file?

I assume you mean the packet log, no HA’s log file…

I can implement this before the next drop (any day now) - would it be OK to limit to last 7 days by default - or do you have another suggestion?

Suggestions:

  • roll over to a new log at midnight, and keep only the last 7 days?
  • roll over over at 1MB and keep the last 3 logs?
706

I prefer: roll over to a new log at midnight, and keep only the last 7 days

707

Yes, that could be fine. I think… Now…

708

I’ve updated the WiKi, would somebody check it pls (makes sense to me at least!)

709

If anyone is feeling adventurous - perhaps try latest master branch of evohome_cc?

  • it is still v0.5.6, but is using evohome_rf v0.5.7
  • I will push it as v0.5.7 later today/early tomorrow, when major bugs removed