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
There is a big drop coming soon - lots of improvements / fixes, and some new features. Please bear with me.
7 Likes
Can’t wait! 
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).
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.
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
Can’t wait for the update
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.
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.
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?
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_demandis the % heat demand of the entire CH/DHW system, and -
sensor.01_123456_08_heat_demandis 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.
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!
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.
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.
Would you suggest to buy a nanoCUL (or and SSM-D2, if better)? Do you think that at this point it must be an HW issue and nothing that my machine would “discard” for some reason?
I mean… if, as you confirmed, my configuration is able to replicate the same exact message sent from my remote, should there be anything at network level that lets the machine recognize the faked message and discard it?
I New HA user here, I am setting up the HACS integration to use my HGI80 which I was previously using with Domoticz and I am coming across a weird situation.
I’ve followed the documented install steps starting with the installation of HACS itself and that seems fine, then I add the custom repository for Ramses_cc using the explore and download button and again that seems to go fine, but once all is done and I’ve rebooted the RPi that is hosting HA HACS still only shows 1 service (HACS itself) and I am struggling to understand what step(s) I have missed here and how to resolve it. Can anyone offer any quick advice on what to check please?
You need to enable the integration in your config.yaml. Please refer to the wiki pages of the integration, you can start here.
Thanks for taking the time to reply. I should have included those screenshots also. The integration is enabled as far as I can tell.
but even with this in place for several hours no information is in the log file and no additional service or entities within HACS. I’m a bit confusd and not really sure what I’ve missed!
There should be some sort of error message in the log file…
Anyway, your serial-port needs to be fully-qualified, starting from /dev .
Thanks for the reply, I hadn’t spotted that typo! That seems to have it working now as I have plenty of entries in the log.
Is there an easy way to figure out the structure of the known_list… do I just add all the device references seen in the log?