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

Share your Projects!
3457

I’ve just been giving this a go to get a packet log, but have run into a snag…

Although I can get the Eco Drimaster back into binding mode, I can’t find a way to get the switch itself back into binding mode.

Have tried a battery removal but it still appears to be bound. As a result, holding down the Boost button for even as much as a minute does not result in the double-flash of the green LED described in Nuaire’s documentation. (The switch remains bound and still controls the unit)

More than happy to provide a full log if anyone knows how to reset this switch…

Here’s a snippet of my config if it’s of any use to anyone…

  orphans_hvac: [30:085433, 32:209342]

  known_list:
    01:124821:
    30:085433: { class: FAN, _note: Nuaire PIV }
    32:209342:
      class: REM
      faked: true
      commands:
        normal:      ' I --- 32:209342 30:085433 --:------ 22F1 003 00020A'
        boost:       ' I --- 32:209342 30:085433 --:------ 22F1 003 00030A'
        heater_auto: ' I --- 32:209342 30:085433 --:------ 22F1 003 000A0A'
        heater_off:  ' I --- 32:209342 30:085433 --:------ 22F1 003 00090A'
      _note: Nuaire DRI-ECO-4S (4-way switch)
3458

The bootloader is fine since if it wasn’t i shouldn’t have been able to load the program in the first place. Wiring is also good, as i double checked with what the author commented on this issue: CC1101 to ATMEGA328P pinning · Issue #11 · ghoti57/evofw3 · GitHub.
I’m starting to think to buy a nanoCUL, but i guess it would be a loss of money: i can’t think of any HW possible differencd, except for voltage level shifters, but thst would have given problem on the RX rather than TX (3.3V logic of the CC101 vs 5V logic of the Arduino).

Isn’t there away to test the TX in some way? Maybe the problem is with the machine that somehow discards the faked message?

3459

Your premise is wrong - evofw3 has no problem with faked messages - in its opinion, there is no difference between a faked packet and any other.

However, have a look at the packet log - you should see these 7FFF packets:

 I --- 18:005904 63:262142 --:------ 7FFF 015 00100181164C226476302E31392E32

They are not faked, they are sent from the dongle (and to 63:262142).

Or these discovery packets:

RQ --- 18:004878 10:070473 --:------ 3220 005 0080730000

Again, not faked: they are RQ packets, sent to another device.

If you see none of these, then if Pete (ghoti57) didn’t have an answer for you, then you’re buggered: sorry.

3460

Not the worlds biggest packet log, but still can’t get the thing (Home Assistant and the USB dongle) to go into Binding mode or accept any commands, whilst the fan itself will quite happily go into Binding mode, etc.

2023-04-20T14:25:30.683035 # ramses_rf 0.21.40
2023-04-20T14:25:31.009327 ...  I --- 30:071135 63:262142 --:------ 10E0 038 000001C90023006CFEFEFFFFFFFF1C0707E5425244472D30324A415330310000000000000000 # 10E0| I|30:071135
2023-04-20T14:52:05.071367 # ramses_rf 0.21.40
2023-04-20T14:52:05.336315 ...  I --- 30:071135 63:262142 --:------ 10E0 038 000001C90023006CFEFEFFFFFFFF1C0707E5425244472D30324A415330310000000000000000 # 10E0| I|30:071135
2023-04-20T19:07:33.390334 # ramses_rf 0.21.40
2023-04-20T19:07:33.804168 ...  I --- 30:071135 63:262142 --:------ 10E0 038 000001C90023006CFEFEFFFFFFFF1C0707E5425244472D30324A415330310000000000000000 # 10E0| I|30:071135

Any ideas?

3461

Hello all,
@zxdavb thanks for the excellent work on ramses_cc & associated libraries.

I have a goal to achieve a CC1101 <-> homeassistant bridge via wifi.
My approach so far has been to:

  • connect a nanoCUL to an ESP32 (I made a PCB for this - PM me and I’ll happily share the CAD data and I might have a spare blank PCB or two)
  • run ESPHome on the ESP32 and publish the serial port output from the nanoCUL as text_sensor

This works quite nicely - I achieved this with a short yaml within ESPHome which uses the UART debug feature and then publishes the recevied text string:
image

Next step is to connect the text_sensor which now appears in HA to ramses_cc. This is where I nee some advice on how to proceed:

Option 1: use socat to create a pseduo serial port - problem is that I’m running HAOS so socat isn’t included and it appears that the docker containerisation would make this fiddly. So this seems unappealing
Option 2: open a dedicated TCP socket on the ESP32 using https://github.com/oxan/esphome-stream-server - and then I believe this should connect directly to ramses_cc using the socket::// syntax (the pyserial module appears to support this). What I don’t like about this is that it uses just a plain TCP socket for a relatively unreliable connection, whereas I believe the underling ESPhome API transport mechanism is more robust
Option 3: modify ramses_cc to allow it to connect to to my text_sensor - this seems like the most elegant option… but it looks like it would require modifying ramses_cc (to connect to the sensor within HA) and ramses_rf - to allow it to use this new sensor as opposed to something supported by pyserial.

Does anyone else have an interest in working on this solution? Any alternative ideas on how to connect my text_sensor to ramses_cc?

thanks Paul!

3462

You can hook in via service calls (to send pkts to the RF) & triggers (to pull pkts from the RF).

Have a look at: 2. configuration.yaml · zxdavb/ramses_cc Wiki · GitHub

Look at the bottom:

  • ramses_cc.send_packet service call, and
  • message_events triggers

The latter may not work exactly as you need - but it’s a start for you - let me know how you get on.

As an aside, Pete (who wrote evofw3) is working on a solution for this - an RF / Wifi gateway using MQTT.

3463

For those looking to fully fake a virtual switch for Nuaire, rather than merely impersonate an existing physical switch, I have a solution worked out - please bear with me whilst I take the time to implement it.

3 Likes
3464

There is a big drop coming soon - lots of improvements / fixes, and some new features. Please bear with me.

7 Likes
3465

Can’t wait! :heart_eyes:

3466

A quick question, how do I get the 18:xxxxxx entity to show in HA?

I’ve added my USB sniffer 18:xxxxxx to the known_list but don’t see the entity (everything else works great).

3467

Had a nanoCUL ‘die’ after a few years usage, it would basically work for a bit, then just stop ‘seeing’ any messages (packet log was empty). Tried reflashing, re-tuning, in the end I just swapped it out. Luckily I had a spare to get things up and running again.

Feeling relieved, I went to order another spare to keep as a replacement but noticed that the shipping for them on eBay was a wee bit insane (£37 for the unit, plus £13 shipping) from Germany.

… so, I bought an SSM-D2 instead.

The different is like night and day, I perhaps get the odd ‘unavailable’ state, it’s for mainly 1 TRV that probably has the most amount of walls/stuff between it and the unit, but nothing compared to the nanoCUL. I haven’t even bothered running the autotune on the SSM-D2.

Whilst the nanoCUL was perfectly usable, I’d still often see a couple of unavailable states a few times a day. Sometimes it would recover, other times restarting HA would ‘fix’ it for bit. Not required since switching to the SSM-D2.

3468

Try specifying the class, maybe? For example:

18:068121: {class: HGI} # SSM-D2 Dongle

And if all else fails, maybe try clearing the cache - edit config similar to the below, reload HA, wait until reload finishes, edit the config again and change false → true (for the next reload, so cache is restored, when ever that may be):

ramses_cc:
  restore_cache:
    restore_schema: false
    restore_state: false

… although I think mine did take a few hours, maybe a day, for the new entry to pop up after I swapped my fake-HGI.

1 Like
3469

Can’t wait for the update

3470

Hi David,

Any chance you could expose the field filter_dirty from the fan_state (31D9) packet as an entity to Home Assistant? I’d like to put a notification on that.

I know that it works, since it was True this morning and it changed to False after I replaced the filter and reset the indication.

3471

Thanks @zxdavb - I’ll follow up those suggestions.

I’d actually missed your post, and I’ve spend a couple of days on Option3. I’ve managed to get ramses_rf to (using client.py) work as expected with my esp32<->evofw3 bridge.

I’ve committed the patch which archives this to a fork of your ramses_rf repo . But the patch is a mess and not ready for public consumption. I ended up extending the python serial port library to create a new serial port type “esphomeapi://”, and managed to monkey patch it into the current version of ramses_rf .

The MQTT route is probably more elegant - I’m pretty sure my existing esp32 (running esphome) would be capable of MQTT without any changes. I think it’s just a case of writing a yaml.

3472

Hi David,

I’ve started implementing a connector from my EvoControl Smart Heat Alexa skill to HA via ramses_cc and the REST API, with help from Bruce Miranda because I’m a total HA noob. In order to configure the connector, users of the skill will login to their account dashboard at my back-end and enter a https URL/credentials that resolve to their HA, plus their Long-Lived Access Token. I already have a script that deploys ngrok to expose their :8123 to Amazon if they need it. So accessing HA instances remotely is not the issue I’m facing, it’s more about entity_ids and such.

I’ll need to ‘discover’ their ramses_cc configuration by remotely querying the REST API. For my own simple test setup with a nanoCUL, I’ve seen that if I query /api/states, there will be an entity with a name like binary_sensor.01_154595_schema which contains an array with zone identifiers. I can then find further sensors for active_fault, window_open, heat_demand and temperature, etc. So it seems to be a good starting point for further discovery.

My question is how ramses_cc assigns entity_ids and if they persist across reboots or are freshly/randomly assigned every time HA starts? If persistent I can cache them but if ephemeral I will need to poll every time. When discovering somebody’s setup, can I just look for /binary_sensor\..+?_schema/ to find the schema object in the JSON or might that clash with other integrations that also name a binary_sensor that way? Would it be safer to also get people to fill in their schema entity_id on the connector web-form so I don’t have to infer it from the JSON?

I notice that the climate.xxx entries in the JSON sometimes contain my zone names (lowercased) like climate.bathroom but sometimes have a different identifier like e.g. climate.ramses_cc_01_154595_02 which actually was my garage zone but for some reason was not called climate.garage. Any idea why that might have happened? If all I have is access to the JSON coughed up by a call to /api/states, what would be the most bulletproof path to extracting all the correct entity_ids so that I can then use the REST API for full querying/control of a setup? Or is there a smarter REST API call I could use for discovery?

3473

Hi Phil,

Congratulations on your Alexa skill, which is amazing work!!

I hope this will provide the answers you need, but do ask more questions if you have to, and PM me if you prefer. I am afraid I think I need to go into some detail…

First, each RAMSES II-compatible device that broadcasts on the RF will have a hard-coded, (apparently) unique device ID such as: 01:123456 (i.e. of the format xx:yyyyyy)…

Such devices come from one of two domains, heat (CH/DHW) or HVAC. For those from the heat domain (but not the HVAC domain), the first two character will tell you what type of device it is, for example:
02: - UFH controller
04: - TRV
07: - DHW sensor, etc.

Specifically you will be interested in 01: (controllers) and 18: (HGI80s, or - more likely - evofw3-compatible dongles). That is, you will likely need the user to tell you the address of one or the other (the 18: device has a structured schema attr that can tell you the device id of the controller)…

In addition, many such devices have a ‘context’. In the case of an evohome controller, there is a index for each of the (up to) 12 heating zones 00 to 0B (i.e. 0x00 to 0x0B, or 0 to 11) and for DHW (IIRC, FA) and heat source (aka appliance, FC).

So… In ramses_rf, 01:123456|FA means the DHW subsystem of the entire CH/DHW system. In HA, you might see IDs that includes 01_123456_FA.

Each HA entity can have multiple identifiers (or names), the two main IDs are relevant here:

  • unique_id, which is persistent across the lifetime of the entity (regardless of HA reboots), and
  • entity_id, which is also unique and persists, but - importantly - can be changed at any time by the user

For many operations, you can use either ID - and, thus a zone would have ids like:

  • climate.bathroom (the entity_id), and
  • climate.01_123456_03 (the unique_id)

In HA/ramses_cc, all unique ids must include a device id. For example:

  • sensor.01_123456_FC_heat_demand is the % heat demand of the entire CH/DHW system, and
  • sensor.01_123456_08_heat_demand is the % heat demand of the zone in the 9th slot of the 12 possible heating zones

It is important to be clear what I mean with I say the above, otherwise confusion may reign…

When you create a heating zone, say called ‘Bedroom 1’, it will be attached to one of the 12 slots… Specifically, it will use the first available slot, ordered by slot number (index/context). That is:

  • starting with no zones (i.e. you just reset the controller)
  • the first zone, ‘Loungeroom’, will be in slot 00
  • the next zone, ‘Bathroom’, will be in slot 01

If you create a new zone, ‘Bedroom 1’, and then delete the ‘Loungeroom’ zone, you’ll have

  • slot 01 - ‘Bathroom’, and
  • slot 02 - ‘Bedroom 1’

However, if you had instead deleted the ‘Loungeroom’ zone, and then create ‘Bedroom 1’, you’d have had:

  • slot 00 - ‘Bedroom 1’, and
  • slot 01 - ‘Bathroom’,

In both cases, the ‘Bedroom 1’ zone will have the entity_id climate.bedroom_1, but the unique_id will differ, e.g.: climate.01_123456_00 vs climate.01_123456_02 !!

Worse still: the entity_id will initially utilise the zone name, until the point where the user first changes that name - then that name will persist for the entity with that unique_id.

I hope that is a good start for you!

Please keep be abreast as to what end-points you’re relying upon - I will avoid breaking things for you.

3474

Thanks a million, David — very helpful indeed. I was unaware that the id is actually based on something hard-coded in the Honeywell hardware, but that’s good for me because it means it will thus be static for a particular user. In my case, I’m not seeing the nanoCUL showing a schema entry — the only entry I see in the JSON for an 18: entity is binary_sensor.18_072478_status. But as I can ask the user for their 01: device ID that will suffice for the schema. I can then parse the rest of the JSON and extract what I need from there. Based on your explanation, I’ll work with the unique_ids and use them as basis instead of the entity_ids as would seem to be more robust.

I’ll certainly let you know how it pans out and many thanks again!

3475

I don’t believe the nanoCUL has a Schema entity. It has a binary sensor Status entity that has a Schema section within its State Atributes. This is where your hand crafted schema gets loaded. The Controller on the other hand has a Schema entity that also has a Schema section within its State Atributes. This is where ramses_cc stores the Schema it builds up for your system.

3476

I have always maintained that it’s acceptable to ask an end user to enter the Controller’s Device ID 123456 (01:123456) because the Evohome controller displays that on the Controller within the Settings->Device Settings->System Information screen. Beyond that you are talking to geeks and nerds…which includes a lot of us.