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

Here is what evohome_rf has learnt about the controller after approx 10 mins. You can see teh fault log (limited to first 3 entries); it hasn’t picked up the DHW sensor (yet), but it has picked up the TPI relay:

    "01:145038": {
        "description": "Evo Color",
        "device_type": "CTL",
        "dhw_sensor": null,
        "fault_log": [
            {
                "log_idx": "00",
                "timestamp": "20-05-14 16:14:37",
                "fault_state": "Fault",
                "fault_type": "BatteryLow",
                "zone_idx": "03",
                "device_class": "Actuator",
                "device_id": "04:056057"
            },
            {
                "log_idx": "01",
                "timestamp": "20-05-14 05:43:24",
                "fault_state": "Restore",
                "fault_type": "BatteryLow",
                "zone_idx": "00",
                "device_class": "Controller?",
                "device_id": "00:000001"
            },
            {
                "log_idx": "02",
                "timestamp": "20-05-14 00:42:05",
                "fault_state": "Fault",
                "fault_type": "BatteryLow",
                "zone_idx": "00",
                "device_class": "Controller?",
                "device_id": "00:000001"
            }
        ],
        "language": "en",
        "last_pkt": "2020-05-18T12:06:08.742970",
        "parent_000c": null,
        "parent_zone": "FF",
        "pkt_1fc9": [
            {
                "zone_idx": "00",
                "command": "device_info",
                "device_id": "01:145038"
            },
            {
                "zone_idx": "00",
                "command": "bind_device",
                "device_id": "01:145038"
            }
        ],
        "pkt_codes": [
            "1F09", "1FC9", "10E0", "0002", "0418", "2E04", "000A", "12B0", "30C9",
            "2349", "000C", "0004", "1100", "0005", "1F41", "1260", "0100", "10A0",
            "313F", "0016", "0008", "2309", "3B00"
        ],
        "system_mode": {
            "mode": "Eco",
            "until": null
        },
        "tpi_relay": "13:237335"
    },

Here’s what it picks up for a zone:

    "01": {
        "actuators": ["04:056053", "04:056059"],
        "configuration": {
            "local_override": true,
            "multi_room_mode": false,
            "openwindow_function": true,
            "max_temp": 35.0,
            "min_temp": 5.0
        },
        "devices": ["04:056059", "04:056053", "34:092243"],
        "heat_demand": 0,
        "last_pkt": "2020-05-18T12:02:31.116455",
        "name": "Front Room",
        "pkt_codes": ["000A", "12B0", "30C9", "2349", "000C", "2309", "3150" ],
        "sensor": "34:092243",
        "setpoint_status": {
            "setpoint": 5.0,
            "mode": "FollowSchedule",
            "until": null
        },
        "temperature": 19.14,
        "window_open": false,
        "zone_type": "Radiator Valve"
    },

… and, an exampl of a non-TRV device (a BDR91 in this case):

    "13:237335": {
        "actuator_enabled": null,
        "actuator_state": null,
        "description": null,
        "device_type": "TPI",
        "is_tpi": true,
        "last_pkt": "2020-05-18T13:13:04.927614",
        "parent_000c": null,
        "parent_zone": null,
        "pkt_1fc9": [
            {"command": "actuator_enabled", "device_id": "13:237335"},
            {"command": "sync_tpi","device_id": "13:237335"}
        ],
        "pkt_codes": ["3EF0", "1FC9", "0016", "3B00"],
        "rf_signal": {"rf_strength": 5, "rf_value": 24}
    },

@Captain I think your UFH is in zone 1 (what I call zone “00”), but would you be willing to run the latest code for me to test my probe/discovery system? You’d have to download a special branch of my latest code & run it outside of HA - it would only take 5 minutes.

That’s great.

I’ve just ordered the nano 868Mhz, it should be here by the end of the week, sending packets is not that important to me, so I can get the same functionality I need from HGI80 (eavesdropping), for a fraction of the price, if it will be able to send packets in the future, it’s even better.
Meanwhile I’m setting up HA and will download the code so I have everything ready.

As soon as I get my hands on it, I can do all the testing you’ll need and help as much as I can.

Thanks.

To be clear - a HGI80 can send packets. The nanoCUL will be able to send packets, and be capable of impersonation (i.e. pretend it’s a device other than a HGI80).

I think we are both saying the same thing :smiley: but thanks for clarifying.

I’ve just received my nanoCUL will try to make it work and will report back :slight_smile:

I might need some help uploading the firmware to the board, it’s my first time using Arduino UI and when i do compile verify it complains about:

In file included from sketch/cc1101.c:19:0:
config.h:11:12: fatal error: hw\atm328_pins.h: No such file or directory
   #include "hw\atm328_pins.h"
            ^~~~~~~~~~~~~~~~~~

What am I doing wrong ?

Board: Arduino Nano
Processor: ATmega328P (Old Bootloader)

Steps:
Cloned evofw3 repository.
Opened from Arduino UI the evofw3.ino file.
Click on Sketch->Verify/Compile

What am I doing wrong ?

Hmm Dunno _ I’m using master branch, latest commit - same Board/Processor, and just select Sketch->Upload.

I have only noticed some compile errors - never saw before, only because I never looked - no fatal errors though. That file is definitely in my folder, under hw, and with the same filename.

Once it is uploaded OK, then you can just select: Tools -> Serial Monitor

  • Carriage return, 115200 baud & you should see something like:
21:42:57.891 -> # evofw3 0.3.2
21:43:09.028 -> 070  I --- 13:237335 --:------ 13:237335 3EF0 003 0000FF
21:43:09.543 -> 070  I --- 13:237335 --:------ 13:237335 3B00 002 00C8
21:43:09.577 -> 056  I --- 01:145038 --:------ 01:145038 3B00 002 FCC8

If you can’t make that work, maybe could could ask the dev direct.

I managed to make it work by moving the atm328_pins.h next to the other files and changing the config.h.

It seems to be working fine now and the client is working well and I’m getting packets :smiley:

@zxdavb what would be the best way to capture the packets you’re looking for ?

How well do you know Python?

git clone zxdavb/evohome_rf
git checkout bleeding_edge
Setup a venv, pip install -r requirements.txt and requirements-dev.txt

The client has two main modes and there’s a shedload of switches, but main ones might be:

python client.py monitor /dev/ttyUSB0 -o

Also:
-r don’t parse packets into messages
-o create/append a log file, called packets.log by default
-k create use a known devices DB (friendly names, etc.), called known_devices.json by default

(you can’t use -p -x yet)

Later you can always:

cat packets.log | grep ' 01:' | python client.py parse -k

Or:

(venv) ➜  evohome git:(bleeding_edge) ✗ python client.py -h
Usage: client.py [OPTIONS] COMMAND [ARGS]...

  A CLI for the evohome_rf library.

  evohome_rf is used to process RAMSES-II packets, either via RF or from a
  file.

Options:
  -k, --known-devices PATH  TBD
  -w, --device-whitelist    TBD
  -m, --message_log PATH    TBD
  -r, --raw-output          TBD
  -z, --debug-mode          TBD
  -h, --help                Show this message and exit.

Commands:
  monitor  Monitor a serial port for packets.
  parse    Parse a file for packets.

(venv) ➜  evohome git:(bleeding_edge) ✗ python client.py monitor -h
Usage: client.py monitor [OPTIONS] SERIAL_PORT

  Monitor a serial port for packets.

Options:
  -d, --database PATH
  -p, --probe-system      TBD
  -x, --execute-cmd TEXT  TBD
  -T, --evofw-flag TEXT   TBD
  -C, --ser2net TEXT      addr:port, e.g. '127.0.0.1:5001'
  -o, --packet_log PATH   TBD
  -h, --help              Show this message and exit.

(venv) ➜  evohome git:(bleeding_edge) ✗ python client.py parse -h
Usage: client.py parse [OPTIONS] [INPUT_FILE]

  Parse a file for packets.

Options:
  -h, --help  Show this message and exit.

Thanks for the detailed explanation, I know Python enough to get around, but I’m not proficient.

For how long shall I leave it capturing packets ? I’ll try to get it tomorrow.

You get about 30% of what’s going in 1 sync_cycle (say 200-300 secs) (e.g. zone temps, setpoints).

You get another 30% in 24h (e.g. TRVs broadcast their battery state every 24h).

You get another 30% if you can probe (the -p switch, with an upcoming version of evofw3, or a HGI80)(e.g. which BDR91 is the boiler relay, assuming you’ve >1 of them) - this takes <1min after the first sync_cycle.

Great, thanks a lot :slight_smile:

I do have more than 1 BDR91, 2 actually, one for the main heating line and another that controls one zone, I also have 2 HCE80 (controlling 3 zones each) , so I guess we can get a lot of data.

I’m also running the latest evofw3 so I can try probing, for sure.

What I’ll do is to get those 90% in 3 batches following your advise. I’m now curious how to get the remaining 10%.

I think I got the first 30% :slight_smile:

2020-05-21T00:12:48.426788 037  I --- 34:190267 --:------ 34:190267 30C9 003 000993
2020-05-21T00:12:57.400584 076  I --- 34:204867 --:------ 34:204867 30C9 003 000999
2020-05-21T00:13:22.421871 067  I --- 34:219917 --:------ 34:219917 30C9 003 000953
2020-05-21T00:20:38.883251 056  I --- 01:191718 --:------ 01:191718 1F09 003 FF06E0
2020-05-21T00:20:38.936233 056  I --- 01:191718 --:------ 01:191718 2309 021 00076C01076C02076C03076C04076C05076C06076C
2020-05-21T00:20:38.959366 056  I --- 01:191718 --:------ 01:191718 30C9 021 0009830109910209CE030944040999050992060953
2020-05-21T00:20:42.390245 072  I --- 20:016443 --:------ 20:016443 31DA 029 00EF007FFFEFEF7FFF7FFF7FFF7FFFF000EF0101000000EFEF7FFF7FFF
2020-05-21T00:20:49.873499 062  I --- 34:172927 --:------ 34:172927 30C9 003 000944
2020-05-21T00:20:55.401150 070  I --- 20:016443 --:------ 20:016443 5731 217 11000601002020202020202020202020200057 * Truncated
2020-05-21T00:20:56.711040 055  I --- 34:219801 --:------ 34:219801 30C9 003 0009CC
2020-05-21T00:21:36.526162 096  I --- 08:025719 --:------ --:------ ???? ??? * Invalid Manchester Code
2020-05-21T00:21:52.442671 056  I --- 01:191718 --:------ 01:191718 3150 002 FC00
2020-05-21T00:22:00.204107 074  I --- 34:204867 --:------ 34:204867 30C9 003 000999
2020-05-21T00:22:04.051911 037  I --- 34:190267 --:------ 34:190267 3120 007 0070B0000000FF
2020-05-21T00:22:34.608028 066  I --- 34:219917 --:------ 34:219917 30C9 003 000953
2020-05-21T00:22:43.729118 037  I --- 34:190267 --:------ 34:190267 30C9 003 000992
2020-05-21T00:23:27.432259 063  I --- 34:219793 --:------ 34:219793 30C9 003 00098F
2020-05-21T00:23:34.882899 056  I --- 01:191718 --:------ 01:191718 1F09 003 FF06E0
2020-05-21T00:23:34.934725 056  I --- 01:191718 --:------ 01:191718 2309 021 00076C01076C02076C03076C04076C05076C06076C
2020-05-21T00:23:34.949560 056  I --- 01:191718 --:------ 01:191718 30C9 021 0009830109920209CC03094404099905098F060953

Does this help in anyway ?

What device could it be that starting with 20: ? on the logs I could se a “relative_humidity” column… Maybe the EvoHome ?

More data is always good - I’m desperate to see UFH that is not in zone 0.

There’s no batches - it’s just a matter of how long you run the monitor for, and whether it is capable of probing - the latest evofw3 is not yet so capable.

I’ve never been able to probe UFH, so that will be good, when evofw3 can do that.

The remaining 10% is odd/event-driven - e.g. a powering-on a round thermostat is the only thing I know to cause it to send a 10E0.

They are interesting - will be a ventilation unit - your or your neighbours - I would love to see heaps of packets from them - the parser for 31DA (and associated packets are not well understood.

This is your first 30% - just 3 packets:

2020-05-21T00:20:38.883251 056  I --- 01:191718 --:------ 01:191718 1F09 003 FF06E0
2020-05-21T00:20:38.936233 056  I --- 01:191718 --:------ 01:191718 2309 021 00076C01076C02076C03076C04076C05076C06076C
2020-05-21T00:20:38.959366 056  I --- 01:191718 --:------ 01:191718 30C9 021 0009830109910209CE030944040999050992060953

That ventilation unit packet, I don’t really know where it comes from, probably from a neighbour indeed and here’s another weird one that starts with 8.

Here there’s a new capture with a few more packets and I see different ones already.

2020-05-21T00:12:48.426788 037  I --- 34:190267 --:------ 34:190267 30C9 003 000993
2020-05-21T00:12:57.400584 076  I --- 34:204867 --:------ 34:204867 30C9 003 000999
2020-05-21T00:13:22.421871 067  I --- 34:219917 --:------ 34:219917 30C9 003 000953
2020-05-21T00:20:38.883251 056  I --- 01:191718 --:------ 01:191718 1F09 003 FF06E0
2020-05-21T00:20:38.936233 056  I --- 01:191718 --:------ 01:191718 2309 021 00076C01076C02076C03076C04076C05076C06076C
2020-05-21T00:20:38.959366 056  I --- 01:191718 --:------ 01:191718 30C9 021 0009830109910209CE030944040999050992060953
2020-05-21T00:20:42.390245 072  I --- 20:016443 --:------ 20:016443 31DA 029 00EF007FFFEFEF7FFF7FFF7FFF7FFFF000EF0101000000EFEF7FFF7FFF
2020-05-21T00:20:49.873499 062  I --- 34:172927 --:------ 34:172927 30C9 003 000944
2020-05-21T00:20:55.401150 070  I --- 20:016443 --:------ 20:016443 5731 217 11000601002020202020202020202020200057 * Truncated
2020-05-21T00:20:56.711040 055  I --- 34:219801 --:------ 34:219801 30C9 003 0009CC
2020-05-21T00:21:36.526162 096  I --- 08:025719 --:------ --:------ ???? ??? * Invalid Manchester Code
2020-05-21T00:21:52.442671 056  I --- 01:191718 --:------ 01:191718 3150 002 FC00
2020-05-21T00:22:00.204107 074  I --- 34:204867 --:------ 34:204867 30C9 003 000999
2020-05-21T00:22:04.051911 037  I --- 34:190267 --:------ 34:190267 3120 007 0070B0000000FF
2020-05-21T00:22:34.608028 066  I --- 34:219917 --:------ 34:219917 30C9 003 000953
2020-05-21T00:22:43.729118 037  I --- 34:190267 --:------ 34:190267 30C9 003 000992
2020-05-21T00:23:27.432259 063  I --- 34:219793 --:------ 34:219793 30C9 003 00098F
2020-05-21T00:23:34.882899 056  I --- 01:191718 --:------ 01:191718 1F09 003 FF06E0
2020-05-21T00:23:34.934725 056  I --- 01:191718 --:------ 01:191718 2309 021 00076C01076C02076C03076C04076C05076C06076C
2020-05-21T00:23:34.949560 056  I --- 01:191718 --:------ 01:191718 30C9 021 0009830109920209CC03094404099905098F060953
2020-05-21T00:27:41.384965 037  I --- 34:190267 --:------ 34:190267 30C9 003 000992
2020-05-21T00:28:05.405190 063  I --- 34:219793 --:------ 34:219793 30C9 003 00098F
2020-05-21T00:29:26.871334 056  I --- 01:191718 --:------ 01:191718 1F09 003 FF06E0
2020-05-21T00:29:26.925618 056  I --- 01:191718 --:------ 01:191718 000A 042 001001F40DAC011001F408FC021001F40DAC031001F40DAC041001F40DAC051001F40DAC061001F40DAC
2020-05-21T00:30:20.144842 055  I --- 34:219801 --:------ 34:219801 30C9 003 0009C8
2020-05-21T00:30:20.336267 064  I --- 02:001075 --:------ 02:001075 22C9 018 00076C0A280101076C0A280102076C0A2801
2020-05-21T00:30:26.869969 075  I --- 02:000921 --:------ 01:191718 3150 002 0300
2020-05-21T00:30:27.017446 075  I --- 02:000921 --:------ 01:191718 3150 002 0600
2020-05-21T00:30:27.164770 076  I --- 02:000921 --:------ 01:191718 3150 002 0400
2020-05-21T00:30:45.232745 071  I --- 20:016443 --:------ 20:016443 31DA 029 00EF007FFFEFEF7FFF7FFF7FFF7FFFF000EF0101000000EFEF7FFF7FFF
2020-05-21T00:30:48.933655 062  I --- 34:172927 --:------ 34:172927 30C9 003 000944
2020-05-21T00:30:58.180906 070  I --- 20:016443 --:------ 20:016443 5831 217 11000601002020202020202020202020200056 * Truncated
2020-05-21T00:31:03.010615 075  I --- 34:204867 --:------ 34:204867 30C9 003 000998
2020-05-21T00:31:12.425961 056  I --- 01:191718 --:------ 01:191718 0008 002 FC00
2020-05-21T00:31:46.781249 066  I --- 34:219917 --:------ 34:219917 30C9 003 000953
2020-05-21T00:31:52.913243 076  I --- 02:000921 --:------ 02:000921 22C9 018 00076C0A280101076C0A280102076C0A2801
2020-05-21T00:31:58.857776 076  I --- 02:000921 --:------ 02:000921 0008 002 FA00
2020-05-21T00:31:59.005219 076  I --- 02:000921 --:------ 02:000921 22D0 004 00000002
2020-05-21T00:32:15.528078 056  I --- 01:191718 --:------ 01:191718 0008 002 0000
2020-05-21T00:32:22.880310 056  I --- 01:191718 --:------ 01:191718 1F09 003 FF06E0
2020-05-21T00:32:22.929689 056  I --- 01:191718 --:------ 01:191718 2309 021 00076C01076C02076C03076C04076C05076C06076C
2020-05-21T00:32:22.944121 056  I --- 01:191718 --:------ 01:191718 30C9 021 00096E0109920209C803094404099805098F060953
2020-05-21T00:32:34.097800 092  I --- 04:188729 --:------ 01:141663 3150 002 0200
2020-05-21T00:32:34.251539 093  I --- 04:188735 --:------ 01:141663 3150 002 02 * Invalid Manchester Code
2020-05-21T00:32:39.066229 037 RP --- 08:025719 31:034164 --:------ 3EF1 018 00B0406ACBB43D85468C2E04C6B2F1 * Invalid Manchester Code
2020-05-21T00:32:43.372880 062  I --- 34:219793 --:------ 34:219793 30C9 003 00098F
2020-05-21T00:32:57.210098 064  I --- 02:001075 --:------ 01:191718 3150 002 0100
2020-05-21T00:32:57.357424 063  I --- 02:001075 --:------ 01:191718 3150 002 0500
2020-05-21T00:32:57.504937 064  I --- 02:001075 --:------ 01:191718 3150 002 0200
2020-05-21T00:33:19.856934 074  I --- 02:000921 --:------ 02:000921 0008 002 FC00
2020-05-21T00:33:19.988022 075  I --- 02:000921 --:------ 02:000921 3150 002 FC00
2020-05-21T00:34:41.190233 063  I --- 02:001075 --:------ 02:001075 0008 002 FA00
2020-05-21T00:34:41.337586 064  I --- 02:001075 --:------ 02:001075 22D0 004 00000002
2020-05-21T00:35:01.855495 055  I --- 34:219801 --:------ 34:219801 30C9 003 0009C6
2020-05-21T00:35:18.869478 056  I --- 01:191718 --:------ 01:191718 1F09 003 FF06E0
2020-05-21T00:35:18.924825 056  I --- 01:191718 --:------ 01:191718 2309 021 00076C01076C02076C03076C04076C05076C06076C
2020-05-21T00:35:18.938899 056  I --- 01:191718 --:------ 01:191718 30C9 021 00096E0109910209C603094404099805098F060953
2020-05-21T00:35:34.432232 076  I --- 34:204867 --:------ 34:204867 30C9 003 000996
2020-05-21T00:35:48.465654 062  I --- 34:172927 --:------ 34:172927 30C9 003 000941
2020-05-21T00:36:22.886406 066  I --- 34:219917 --:------ 34:219917 30C9 003 000952
2020-05-21T00:36:28.830737 048  I --- 13:154184 --:------ 13:154184 3B00 002 00C8
2020-05-21T00:36:29.043443 048  I --- 13:154184 --:------ 13:154184 3EF0 003 0000FF
2020-05-21T00:36:30.877422 056  I --- 01:191718 --:------ 01:191718 3B00 002 FCC8
2020-05-21T00:36:31.548977 052  I --- 13:163420 --:------ 13:163420 3EF0 003 0000FF
2020-05-21T00:37:21.346309 062  I --- 34:219793 --:------ 34:219793 30C9 003 00098E
2020-05-21T00:37:36.706588 037  I --- 34:190267 --:------ 34:190267 30C9 003 000992
2020-05-21T00:38:14.876095 056  I --- 01:191718 --:------ 01:191718 1F09 003 FF06E0
2020-05-21T00:38:14.926590 056  I --- 01:191718 --:------ 01:191718 2309 021 00076C01076C02076C03076C04076C05076C06076C
2020-05-21T00:38:14.944573 056  I --- 01:191718 --:------ 01:191718 30C9 021 00096E0109920209C603094104099605098E060952

In this one I see an unknown message at time 00:34:41.337, is this in anyway interesting ?

It’s already a bit late here, I’ll be around tomorrow, maybe we can find a tool where we can chat more in real time and I can monitor/probe whatever else is needed with a bit of your guidance.

I don’t yet have a parser for 22D0: main reason is I’ve never seen anything other than the payload you’ve got. We can chat on gitter: https://gitter.im/evohome_rf/community

Run the monitor overnight. In the morning: don’t stop it, just try this:

kill -USR1 <pid>