Someone had the remote (Landlord) scanner for Nuaire PIVs (DRI-ECO-RM) - can they PM me pls.
1 Like
I take it the relative humidity is not from your fan? But your RH controller?
I’m trying to build a remote for the 4 way in HA. Shame I can’t tell fan setting so it might change the switch to normal when it comes off boost.
Need to setup a timer for it for now. Also trying to make a picture card for the current status of the system.
Running 0.31.1 and noticed that the battery_low binary sensor has 2 attributes of battery_level, how can I select it using a template?
id: "04:231770"
battery_level:
battery_low: false
battery_level: 0.5
device_class: battery
friendly_name: 04:231770 Batterij
I’d use something of this form, where class is a nested attribute of schema
{{ state_attr(“climate.evohome_cc_01_185426_04”, “schema”)[“class”] }}
Just a thought but have you tried reaching out to Nuaire directly to see whether they will share their protocol implementation? This would save having to reverse engineer it, perhaps I’m being too optimistic! 
Hi guys, I desperately need your help and some guidance. I have an EvoHome system comprising 12 individual zones each one with its own DT92 thermostat. I have an HGI80 connected to Home Assistant and ramses_cc installed through HACS. It recognizes all my zones and temperatures readings are ok. I have also tried to make some automations that turn the heat off in case an window is open for a zone by using a community blueprint: Window open, climate off - Blueprints Exchange - Home Assistant Community (home-assistant.io), and some Aqara door and window sensors. However it seems that the ramses_cc integration is only exposing 2 modes: Auto and Heat and does not expose the Off mode. I have also installed the cloud integration for EvoHome and there I have the Off mode exposed and the automation based on the blueprint above is working, except that I do not want to rely on cloud and would prefer to have everything local. I will attach 2 print screen for the same thermostat, one coming from ramses_cc and the other one based on EvoHome cloud integration to see the exposed modes. What am I not getting right here and how can I make the ramses_cc exposed climate entities work with the automation above? Thanks a lot in advance!
I have posted the issue also on Github:
I thought about that. I did ask them years ago how they connected and they did inform me it was RF but would not tell me much more. They might if you ask however. No harm in trying.
Too optimistic.
When I first started, I had this device that would pop up - no idea what is was - eventually worked out it was my Nuaire PIV (think: ventilation unit, like Orcon/Itho).
It was totally unexpected to me that RAMSES_II would support anything other than CH/DHW!
Took a while to decode the frame fully - a very complex payload… Not helped by lack of documentation.
It was obvious then that Orcon/Itho had much more going on in their payloads than my Nuaire, and others helped me - now the 31DA / 31D9 are almost fully understood - remarkable, really.
In all that time, I never received ‘official’ documentation from a vendor - not even under an NDA.
My PIV got decommissioned years ago, but I kept it, and have just revived it in my test bed - I’ll see what I can will be gleaning from it with (say) an RQ|10D0, etc.
1 Like
The mapping between evohome modes and HA modes/pre-sets (and thus, HomeKit / Google / etc.) is not straight-forward.
For example: zones are never truly ‘off’. They only have three modes:
- FollowSchedule
- TemporaryOverride, and
- PermanentOverride
However, the TCS (the controller, i.e. a collection of zones +/- DHW) can be off:
- HeatingOff (the DHW remains on)
I think the obvious thing for a zone to be set ‘off’ is for it to be set to 5 'C indefintely (PermanentOverride) - but others may disagree.
And the difficulty is not so much turning a zone ‘off’, but working out when it is ‘off’…
You could easily say a zone is ‘off’ if it’s setpoint is 5 ‘C (and what is the relationship of that to the zones min_setpoint - I have never fully checked), but there are 4 reasons why a zone setpoint can be 5’ C:
- PermanentOverride - set to 5 indefinitely
- TemporaryOverride - set to 5 for a while
- FollowSchedule - set to 5 as per schedule
- OpenWindowMode - is any PO/TO/FS, but set to 5, regardless of setpoint, for a short while
[ There are other reasons why a zone’s TRV can be set to 5’ C! ]
Then, what part does the TCS mode play? What happens if the zone is FS, set to 5 'C, but the controller is (say):
- Auto
- Away
- HeatingOff
I am the ‘code owner’ of HA’s evohome integration, and I have long recognized that the mappings I made when first implementing that integration are not satisfactory.
They need correcting, so that integration with 3rd-party systems via HA work seamlessly… But these corrections will be breaking changes.
I have always had it on my to-do list to fully understand what changes are required & implement them - but I want to do it only the once - get it right first time.
TL;DR: I would then like this integration, ramses_rf, to be compliant with evohome, and for them both to be ‘right’, but doing so is a breaking change, and I haven’t got my head around it.
Hello! Been a while since I’ve read up on this project. Has the possibility of faking TRVs been explored? I.e. replacing Honeywell TRVs with generic (eg Zigbee) TRVs and having them operate as if they were Evohome ones?
Hi, I’ve been using version 0.30.9 of ramses_cc successfully for a week or two, but since upgrading to 0.31.1 I’ve noticed that the following binary sensors are showing as unavailable and reporting as no longer being provided by the integration:
binary_sensor.01_215596_schema
binary_sensor.13_129802_active
binary_sensor.01_215596_active_fault
Is this normal/expected for 0.31.1? I can’t see any obvious warning/errors in the HA logs for the ramses components. When I switch back to 0.30.9, these entities are restored.
ramses_cc:
serial_port: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00
#packet_log:
# file_name: packet.log
# rotate_backups: 7
restore_cache:
restore_schema: true
restore_state: true
ramses_rf:
enforce_known_list: true # if not true, still enforces the block_list
disable_discovery: false
disable_sending: false # do not transmit any packets, ever
enable_eavesdrop: false # can be used to create an initial system schema
01:215596:
zones:
"00": {sensor: 01:215596}
known_list:
01:215596: #controller
04:038777: #bedroom 2
04:038779: #kitchen
04:038781: #bedroom 1
04:038783: #lounge
04:172415: #bathroom
13:129802: #boiler relay
18:138258: {class: HGI} #gateway_interface
Any ideas?
So reading the manuals on the Nuaire it looks like you could set a 5th button for those not using Humidity control maybe. this is Boost. (not to be confused with Boost button that is actually purge)
Boost only puts the unit up by 1 speed vs full speed of purge (the 4 way boost button)
I assume we can send the Boost command that the Humidity sensor uses to do this. then using any humidity sensor or similar you can then control the PIV using all these 5 options.
So practically the integration is not usable at this moment for what I want to achieve, no? Meaning in case a window is open to put the heat in that room to 5 degree celsius in permanent mode and than after the window is closed to return to the existing schedule (x degree celsius from let’s say 18.00 to 20.00).
Hi, how can I change you blueprint so that instead of turning off the climate to put it to 5 degree permanent?
I believe it has been looked at briefly, but that opens up a huge can of worms, as it would require “translation” of heat demand/valve position between something both evohome and the TRV understand (IF even available on the latter). The only way I see this being doable or possible is if you could fake a zone valve but that would mean open/close only and that’s something you should be able to create yourself by automations in HA if it’s a secondary or tertiary (etc) TRV. Because it would still need a possibility to tell the boiler/furnace/zone valve to “fire”. But building it into the integration seems daunting, not in the least because there are so many TRVs for sale.
Should be possible if you clear all your schedules and rely on HA for your scheduling. That way you will have HA set the desired temps. All optimizations for schedules are out the window then though and might have unwanted side effects, like evohome not learning the heating behaviour. For example, I have a few rooms with very short schedules for heating and it’s having trouble to learn how long and it should heat for and over shoots easily. Another identical room has a steady schedule and rarely overshoot.
BTW, I believe there is a distinction between the “off” setting on the controller and a zone being “off” i.e. 5 degrees set point and turning a HR92 to off.