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.
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:
⌠they are currently out of stock, though I know more are coming. 
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.
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.
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
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?