Please try 0.20.14 and report back.
Please try 0.20.15 and report back.
Working with 0.20.15!
Do I need to keep this or can I revert to my previous config?
My expectation is that you can use any configuration you like. However, I strongly recommend:
ramses_cc:
ramses_rf:
enforce_known_list: true
@cinnamon Please remind me - is your ventilation kit Orcon, or Itho, or something else?
It would be helpful if you could give me make/models.
Hi,
Just want to say that I’ve switched over to the new version and so far everything is working very nicely for me.
Thanks
If anyone uses HVAC (Orcon, Itho) and wants to test sensor faking for CO2 and/or humidity (i.e. you have a third-party humidity/CO2 sensor in your house):
- You will need to download release 0.20.16 or later
- You will need a USB dongle that is is running evofw3
- You will need to set up a faked sensor, e.g., I have this setup:
ramses_cc:
schema:
orphans_hvac:
- 32:123456 # instantiate the device on startup
known_list:
- 32:123456: {class: HUM, faked: true} # set the attributes of the device when it is instantiated
- 32:111111: {class: CO2, faked: true}
- You will also have to bind them to your fan. Here is how you start a device binding (put the fan in listen mode first)…
service: ramses_cc.fake_device
data:
device_id: '32:123456'
start_binding: true
- Here is the service call for humidity:
service: ramses_cc.put_indoor_humidity
data:
entity_id: sensor.32_123456_indoor_humidity
indoor_humidity: 59.3
1 Like
Obviously, the next step is to fake a remote… this will require a change to the schema that I am currently sorting out.
I’ve just upgraded to 0.20.15, and I think I have it working with my setup below. I’ve got lots of new things from my Nuaire PIV too.
ramses_cc:
serial_port: /dev/ttyACM2
packet_log: /config/packet_logs
restore_schema: true
known_list:
- 10:051349 # Appliance Control
- 01:169176 # main_controller
- 18:135447 # Config Sensor
- 04:190691 # Harry's Room
- 04:198483 # Bedroom
- 04:198487 # Spare Room
- 04:112546 # Living Room 1
- 04:198485 # Living Room 2
- 04:038015 # Utility Room
- 04:090189 # Kitchen
- 32:166025: {class: CO2}
- 32:123456: {class: CO2, faked: true}
- 30:079129: {class: FAN}
- 32:168240: {class: HUM}
- 32:172534: {class: REM}
# - 32:172522: {class: SWI}
- 03:000001 # kitchen
- 03:000002 # Living Room 1
- 03:000004 # Harry's Room
- 03:000005 # Master Bedroom
- 03:000006 # Utility Room
- 03:000007 # Spare Room
# block_list:
# - 10:051349
ramses_rf:
enforce_known_list: true
enable_eavesdrop: false
schema:
orphans_hvac:
- 32:172534
- 32:168240
- 32:172534
- 32:123456
- 30:079129
controller: 01:169176
system:
appliance_control: 10:051349
I have his error with the binary_sensor.18
Logger: homeassistant.components.binary_sensor
Source: custom_components/ramses_cc/helpers.py:30
Integration: Binary Sensor (documentation, issues)
First occurred: 15:02:12 (1 occurrences)
Last logged: 15:02:12
Error while setting up ramses_cc platform for binary_sensor
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 250, in _async_setup_platform
await asyncio.shield(task)
File "/config/custom_components/ramses_cc/binary_sensor.py", line 58, in async_setup_platform
new_sensors += [
File "/config/custom_components/ramses_cc/binary_sensor.py", line 59, in <listcomp>
entity_factory(broker, dev, k, **v)
File "/config/custom_components/ramses_cc/binary_sensor.py", line 45, in entity_factory
migrate_to_ramses_rf(hass, "binary_sensor", f"{device.id}-{attr}")
File "/config/custom_components/ramses_cc/helpers.py", line 30, in migrate_to_ramses_rf
if hass.states.get(entity_id).state == STATE_UNAVAILABLE: # HACK
AttributeError: 'NoneType' object has no attribute 'state'
Yes it’s there every time I restart.
but system works ok otherwise? if not, i’ll push a hotfix
Yeah, everything seems to be working as it should.
all - I have settled upon a final configuration schema, as documented: the Wiki
It will necessitate further breaking changes:
- I am hoping that no further changes will be needed
- it offers all the features needed, going forward, especially for HVAC
Perhaps people could look at it and make comment?
Hello,
I had a look at the schema in the wiki. It looks good to me. I am just unsure about one point. How would you indicate the buttons of a remote for HVAC in this schema ? I guess every brand has different buttons (e.g. speeds, booster, away, …). With other faked sensors (temperature, humidity, …) a mapping between a real sensor measuring this value and the fake sensor is enough, but in the case of remote control should the schema offer the possibility to declare how many buttons are needed for instance? I understand the schema must remain generic to work with as many brands and cases as possible, but i am struggling to see how the mapping will work for remote controls. Feel free to disregard this comment if I am missing something obvious 
Thanks. The RF remote things is a WIP, and not fully resolved.
In short, there are bits of the schema that are not yet fully documented, but it would be a device trait, like:
ramses_cc:
known_devices:
29:123456: {class: REM, scheme: orcon}
29:222222: {class: REM, scheme: itho, faked: true}
There are many common remote layouts, e.g.: Away, 1, 2, 3, Boost (10, 20, 30 mins) & Auto.
I should add that the remote is not the limit - many ventilation units will likely take instructions that your remote doesn’t have a button for. This uncertainty is a common problem for any 3rd-party remote.
Anyway, the way the new schema is designed is that the above would be an extension to the schema, and not a breaking change.
Running 0.20.15 and yesterday and today some or most sensors/climate entities goes in a state of unknown.
Config isn’t changed.
Logs: Nextcloud
Restart of HA resolves it
I think I have most of the remote commands that itho remotes can send. If it helps, they can be found here:
Thanks.
Are you familiar with 31DA[36:38] (the 37th, 38th bytes of the payload of): ramses_rf/ramses.py#L1250
- do you know what the codes from 0x1A to 0x1F mean?
Here is an example of how we can provide more functionality that the existing remotes. For example, with 22F1 (0x0A = 10 minutes):
const uint8_t ithoMessageTimer1CommandBytes[] = {0x22, 0xF3, 0x03, 0x00, 0x00, 0x0A}; // 10 minutes full speed
- the obvious thing to do is set it to (say) 15 minutes instead of 10/20/30 minutes - actually, the protocol allows for hours, days too! I think this is how DF does 30, 60 minutes?
22F3 is not fully understood, esp. the fallback speed feature.
I’ve never seen 22F8 before - I would love to receive some packet logs of those.
const uint8_t ithoMessageAUTORFTAutoNightCommandBytes[] = {0x22, 0xF8, 0x03, 0x63, 0x02, 0x03};
const uint8_t ithoMessageDFLowCommandBytes[] = {0x22, 0xF8, 0x03, 0x00, 0x01, 0x02};
const uint8_t ithoMessageDFHighCommandBytes[] = {0x22, 0xF8, 0x03, 0x00, 0x02, 0x02};
Note the RFT has 0x03 at the end, whilst the DF has only 0x02. That tells me: that command class (code) supports up to 0x03 - so ventilation units may respond to packets with the send-last byte set to 0x00, 0x01, 0x02, and 0x03 - and maybe even 0x04, etc. Have you tested that? I have, on Orcon units… nothing happended.
Your code says setpoint for 22F8, but obviously there’s no setpoint in the payload - what can you tell me about it?
Does Itho have the equivalent of the 2411 command class? ramses_rf/ramses.py#1149
Finally, 31E0 is not fully understood - I am waiting for faking of RF remotes before exploring that further.