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

Can you try:

tail -f /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00

Give a few moments (up to 3 minutes), or just press a button somewhere. Do you get any output?

Like this:

(venv) dbonnes@vm-builder ~/c/evohome (refactor_parser)> tail -f /dev/ttyACM0
061  I --- 34:021943 --:------ 34:021943 0008 002 0000
059  I --- 34:064023 --:------ 34:064023 30C9 003 0007CF
051  I --- 30:082155 --:------ 30:082155 1F09 003 000537

People have asked to change this:

if mode is None:  # and setpoint is not None: TODO: use: advanced_override?
    mode = ZoneMode.TEMPORARY if until else ZoneMode.PERMANENT

to this:

if mode is None:
    mode = ZoneMode.TEMPORARY if until else ZoneMode.ADVANCED

That is, if you change the setpoint of a zone, it’s an advanced override, and not a permanent override.

The answer is that this will have to wait until profiles are implemented - it works for evohome, but not non-evohome systems.

1 Like

No output.

The usb dongle has 2 red LED lights constantly illuminated on the top of it, if that’s of any help.

Guys - I apologies for dropping in a sale in the middle of the discussion and will delete on request - But in respect for this community, I have a HGI 80, and Full Evohome starter kit that I am offloading - I have not posted this anywhere yet, in the event that someone here is looking for this hard to locate kit. PM Me.

It seems to me, you’ve got an issue getting the USB device to work…

Did you try /dev/ttyUSB0 or /dev/ttyACM0 or whatever? Maybe others could help you.

Yes, HGI80s are hard to get a hold of. However, I feel these devices are superior:

Wireless (onlineweb.shop)

… they are currently out of stock, though I know more are coming. :frowning:

I can see some output using /dev/ttyACMO. I therefore switched over my configuration to reference that instead, but still getting the same error on startup of evohome_cc.

So there is no confusion, it is /dev/ttyACM0 and not /dev/ttyACMO, right?

Is it the exact same message? Please upgrade to the latest version of evohome_cc, version 0.8.1 - the message will be different.

If that fails, try this minimal configuration:

evohome_cc:
  serial_port: /dev/ttyACM0
  restore_state: false

Can you, or the shop give a reason and a bit more info on these. The website has nothing.

I have ordered and received one, yet to try. The soldering is a bit poor and a non shelled USB connector but otherwise looks OK.

They are made by the chap who maintains the evofw3 repo.

All evidence is that he knows what he is doing. I am not qualified to comment on anyone’s soldering, but I have one of his units, and it works perfectly.

I guess that - until he has an excess of these devices in stock - he doesn’t need to gloss up his website.

Both evofw3 and this hardware platform were developed in line with (collaboratively with) evohome_rf - it is ‘version 2’ of the hardware platform, as there were issues with the nanoCULs used previously.

I no longer see any reason to buy a HGI80 or a nanoCUL over one of these units - although I will continue to support all 3 platforms (two, really: HGI80, and anything running evofw3).

@ghoti57 did tell me the specifics of the advantages of a SSM over a nanoCUL, but I’ll leave that to him to explain, rather than make a mistake.

I’ve upgraded and also reinstalled and miraculously everything now looks to be working. Probably user error on my side. Thanks for your help trying to diagnose.

The SSM is the next best thing to the HGI80 and it’s taken a long time to get to this point. But those of you that have the HGI80, hold on to them. There are some Evohome devices that simply don’t like to play nice with anything other than the HGI80 e.g. the OTB it works about 90% with the SSM. But it’s the worst performing device on the radio waves.

@brucemiranda Is that the case, even after autotune?

I haven’t had to tun e any SSM modules yet. It uses what appear to be much more reliable CC1101 modules

@xAPPO see this post fun with evohome and rfbee

I plan to update the evofw3 wiki when I get chance to include more information that will give more information

The issue isn’t with Autotune or any shortcomings in the SSM design or firmware. The issue is with some of the Evohome kit itself. The HGI80 just appears to be able to cope with these few dodgy devices better. But most people will never ever encounter these issues with the SSM.

Hallo David, I found a small bug. Custom service evohome_cc.set_sysyem_mode mode: heating_off doesn’t work.

So, logging has been a small challenge for a while… I have (hopefully) simplified it greatly.

  1. the packet_log is now optional (but is recommended):
evohome_cc:
  restore_state: true
  scan_interval: 300
  serial_port: /dev/ttyACM0
  # packet_log: packet.log
  config:
    enable_eavesdrop: false
    max_zones: 12
  1. most issues should be debug-able with the following logging:
logger:
  default: warn  # prefer warn over info, avoid debug
  logs:
    homeassistant.core: debug           # to see: call_service & state_changed
    custom_components.evohome_cc: info  # for: Devices, Schema, Params, Status, etc.
    evohome_rf.message: info            # for: (rcvd) MSGs (decoded packets)
    # evohome_rf.transport: info        # for: (rcvd) PKTs (raw packets)
    # evohome_rf.protocol: info         # for: Rx, Tx of PKTs

Here is an example of the logging you’ll see. First from HA:

2021-04-26 17:51:18 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event call_service[L]: domain=evohome_cc, service=set_system_mode, service_data=mode=heat_off>

… then, immediately after, the consequential messages from evohome RF:

2021-04-26 17:51:18 INFO (MainThread) [evohome_rf.message] || HGI:006402 | CTL:145038 |  W | system_mode      | 01FFF... || {'system_mode': 'heat_off', 'until': None}
2021-04-26 17:51:18 INFO (MainThread) [evohome_rf.message] || CTL:145038 |            |  I | system_mode      | 01FFF... || {'system_mode': 'heat_off', 'until': None}
2021-04-26 17:51:18 INFO (MainThread) [evohome_rf.message] || CTL:145038 | HGI:006402 |  I | system_mode      | 01FFF... || {'system_mode': 'heat_off', 'until': None}

I think the bug is a typo - it should be heat_off (‘heat’ off and not ‘heating’ off).

What should happen is that you make a change to evohome via HA (via a service call, or the UI), and - within a second - that change should appear in the (lovelace) UI (e.g. change a zone setpoint, or a system mode).

This is irrespective of the scan_interval…

One person is having an issue with this (IIRC, they are using ser2net) - is anyone else having this issue? Even occasionally?