I am going to stop pushing fixes for / updates to 0.31.x, in favour of 0.41.x - the two are ‘identical’, except 0.41.x includes support for config flow (thanks to @trvrnrth!). Both appear equally stable.
Thus, 0.41.8 will shortly be made available as a non-beta release.
Now is people’s last opportunity to convince me that this is a bad idea!
The only reason I still prefer the yaml version to the config flow is that the yaml stays intact even if you remove the integration and reinstall it.
Also the yaml allows comments and is generally more flexible (hackable).
If there was a way to back up the config flow variables, such that it could be restored, then I too would vote for the 0.4x version. Config flows are more user friendly as its all UI driven.
Having said that, I have moved directly from 0.2x to 0.4x, so am not actually using the 0.3x version.
I agree. I also miss the flexibility of a yaml.file (eg comments).
It has already happened to me that by copying and pasting incorrect yaml code into ‘Known device IDs’ I lost everything after saving.
I am missing a yaml correct code check before saving.
I also have some problems with the wide of the pop-up (class ha-dialog 600px, 95vw) edit window, it is too narrow and commands like 'medium: " I — 37:139773 32:139773 --:------ 22F1 003 000307" do not fit into the window. I have no overview of the content.
I now keep a copy of my /config/.storage/core.config_entries file just in case. This is where HA seems to store the config flow data including those for ramses_cc
Unfortunately, config flow is the future, and there won’t be an option to not use it.
If you want to keep the option of using YAML, simply:
ramses_cc: section in the configuration.yaml file (despite the log file instructing you remove it) - it is ignored because a config entry exists with the same nameWhen you want to use the ramses_cc: configuration again, simply
Delete the RAMSES RF integration from the web UI:Settings > Devices & Services > Integrations > RAMSES RF
ramses_cc as a config entry no longer exists with the same name)@zxdavb see my message above. Config flow data is stored in the .storage folder in the config folder in HA.
Maybe add that information to the wiki.
Bruce, I am not sure of your point.
I understood the question was wanting to keep using YAML, but with the benefit of config flow and it’s features??
I was simply providing a suggestion for someone who wanted to keep a back up of their config flow data. It does not plug the yaml loss but a yaml can easily be recreated from the config flow data, if required.
Hi, I’m starting using ramses_cc integration with my HVAC system. The brand is Valsir (an italian company) but inside it installs the Airios VMD-02RPS66-2 control board and is controlled by VMN-02LM11 remote (VMI-02WSJ44 is also available, but I have the basic one). I sniffed a little bit the communication with ramses_rf and my FAN is 32:133335, while my REM is 32:124070. My configuration is (I’m using the configuration flow version):
orphans_hvac:
- "18:003869"
- "32:133335"
- "32:124070"
"18:003869":
class: HGI
schema: orcon
"32:133335":
class: FAN
"32:124070":
class: REM
faked: true
scheme: orcon
commands:
low: " I --- 32:124070 32:133335 --:------ 22F1 003 000207"
medium: " I --- 32:124070 32:133335 --:------ 22F1 003 000307"
high: " I --- 32:124070 32:133335 --:------ 22F1 003 000707"
bypass_open: " W --- 32:124070 32:133335 --:------ 22F7 003 00C8EF"
bypass_close: " W --- 32:124070 32:133335 --:------ 22F7 003 0000EF"
bypass_auto: " W --- 32:124070 32:133335 --:------ 22F7 003 00FFEF"
reset_filter: " W --- 32:124070 32:133335 --:------ 10D0 002 00FF"
I’m using the Orcon schema (but I suspect that Orcon uses Airios OEM boards). I can control the fan speed using the ramses_cc.send_command:
service: ramses_cc.send_command
data:
entity_id: remote.32_124070
command: medium
2024-03-07T15:16:38.945405 000 I --- 18:003869 63:262142 --:------ 7FFF 023 0011018E1945F4D932324631204933323A313234303730
2024-03-07T15:16:38.964774 000 I --- 32:124070 32:133335 --:------ 22F1 003 000307
2024-03-07T15:16:39.009520 000 I --- 18:003869 63:262142 --:------ 7FFF 023 0011018E1945F50C32324631204933323A313234303730
2024-03-07T15:16:39.030272 000 I --- 32:124070 32:133335 --:------ 22F1 003 000307
2024-03-07T15:16:39.059608 000 I --- 18:003869 63:262142 --:------ 7FFF 023 0011018E1945F54232324631204933323A313234303730
2024-03-07T15:16:39.066268 000 I --- 32:124070 32:133335 --:------ 22F1 003 000307
But the status of the FAN unit is unavailable:
Looking to the captured packets dump HGI is requesting periodically the status, but no answer is sent back:
2024-03-07T15:01:18.506474 # ramses_tx 0.31.7
2024-03-07T15:01:18.555164 000 I --- 18:003869 63:262142 --:------ 7FFF 015 0010018E1937E9AD76302E33312E37
2024-03-07T15:01:18.562454 ... I --- 18:003869 63:262142 --:------ 7FFF 015 0010018E1937D83F76302E33312E37 # 7FFF| I|18:003869
2024-03-07T15:01:33.755818 000 RQ --- 18:003869 32:133335 --:------ 22F2 001 00
2024-03-07T15:01:36.777833 000 RQ --- 18:003869 32:133335 --:------ 22F1 001 00
2024-03-07T15:01:36.780508 000 RQ --- 18:003869 32:133335 --:------ 2210 001 00
2024-03-07T15:01:36.797938 000 RQ --- 18:003869 32:133335 --:------ 22E0 001 00
2024-03-07T15:01:36.818661 000 RQ --- 18:003869 32:133335 --:------ 22E5 001 00
2024-03-07T15:01:36.839743 000 RQ --- 18:003869 32:133335 --:------ 22E9 001 00
2024-03-07T15:01:36.860731 000 RQ --- 18:003869 32:133335 --:------ 22F4 001 00
2024-03-07T15:01:36.875700 000 RQ --- 18:003869 32:133335 --:------ 22F8 001 00
2024-03-07T15:01:48.846281 000 RQ --- 18:003869 32:133335 --:------ 313E 001 00
2024-03-07T15:01:51.857670 000 RQ --- 18:003869 32:133335 --:------ 10D0 001 00
2024-03-07T15:01:51.864584 000 RQ --- 18:003869 32:133335 --:------ 3222 001 00
Is my configuration wrong? Is the compatibility with Airios board only partial?
Thank you for this awesome integration!
The Ramses RF integration is agnostic to any OEM. That is, it should be able to support all features available to you, limited only be the hardware implementation…
The difficulty is knowing the specifics of your OEM’s specifics: oem_code, etc.
Close. Try:
orphans_hvac:
- "32:133335"
- "32:124070"
known_list:
"18:003869": class: HGI
"32:133335": class: FAN
"32:124070":
class: REM
faked: true
commands:
low: " I --- 32:124070 32:133335 --:------ 22F1 003 000207"
medium: " I --- 32:124070 32:133335 --:------ 22F1 003 000307"
high: " I --- 32:124070 32:133335 --:------ 22F1 003 000707"
bypass_open: " W --- 32:124070 32:133335 --:------ 22F7 003 00C8EF"
bypass_close: " W --- 32:124070 32:133335 --:------ 22F7 003 0000EF"
bypass_auto: " W --- 32:124070 32:133335 --:------ 22F7 003 00FFEF"
reset_filter: " W --- 32:124070 32:133335 --:------ 10D0 002 00FF"
At the moment, you are impersonating - if you want to fake a VMI-02WSJ44, you’ll likely need to bind a fully-faked device.
(IIRC, I am not using the scheme option as yet.)
AFAIK, all HVAC OEMs are based upon airios.
Easiest thing is to provide me a 24 hour packet log to see what packets the FAN is casting. You should be able to PM me - include the make / model of your hardware.
Either it is not casting 31DA packets at all - or there is an issue with my code.
Other useful information is to have a packet log of non-faked HW binding to a FAN (PIV/HRU/etc.).
You can provide this data with your existing hardware, by pinging me a packet log with:
10E0 packets for your kitWe’d then add a wiki page with the details, so that others can benefit.
This is not unexpected - these are speculative RQs.
Hi, thank you for all the details and suggestions. I’m going to update my configuration as reported. To add some missing informations, I’m trying to impersonate a real VMI-02WSJ44 already binded to the FAN unit (and that I will close than in a drawer…). But looking at the logs to I just realized that I’m not receiving any data from the FAN! I must have some problem on RF RX channel. I will try to solve that fist.
At the moment I’m using a DIY USB stick based on Sparkfun clone pro micro (Atmega32U4 3.3V 8MHz) + a green board with CC1101 board like this one with evofw3 firmware with “Pro micro” pinout.
I assume SPI connections are correct, since I can control the fan speed.
I already received a replacement for the green board, an E07 900M10S module with a rubber antenna, but to connect it to my pro micro board I need to design a custom PCB. This is not an easy task for me, I’m not an enectronic engineer and I’m not a master in soldering 
Hmmm, I see also my own physical remote messages, so I’m receiving data. Don’t know why FAN is not transmitting.
I just tried to migrate from migrating from 0.31.7 to 0.41.7 and got an issue:
LookupError: Can't create 08:060775: it is in the schema, but not in the known_list (check the lists and the schema)
In the config I don’t have the ‘08’ device:
ramses_cc:
serial_port: /dev/serial/by-id/usb-Texas_Instruments_TUSB3410_Boot_Device_TUSB3410-if00-port0
restore_cache: true
#restore_cache: # Required to add new device
# restore_schema: false
# restore_state: true
scan_interval: 60
packet_log:
file_name: /config/ramses_cc_packet.log
rotate_bytes: null
rotate_backups: 7
ramses_rf:
enable_eavesdrop: false
enforce_known_list: true # Set false to add new device
#disable_qos: False
01:223036:
system:
appliance_control: 10:040239
zones:
"00": { sensor: 01:223036 }
known_list:
01:223036: # Evohome (Temperature control system)
04:231770:
04:231772:
04:231774:
04:231776:
04:050559:
04:155445:
04:155403:
04:081849:
04:155407:
04:155551:
04:155533:
04:155537:
04:017541: # Slaapkamer Febe
10:040239: # OTB
18:005567: # Honeywell HGI80
In the binary_sensor.18_005567_status I do see this 2 devices in the list that aren’t in the known_list:
id: 18:005567
schema:
'01:223036':
system:
appliance_control: '10:040239'
zones:
'00':
sensor: '01:223036'
config:
enforce_known_list: false
known_list:
- '01:223036':
class: controller
- '10:040239':
class: opentherm_bridge
- '04:231772':
class: radiator_valve
- '04:231774':
class: radiator_valve
- '04:231776':
class: radiator_valve
- '04:231770':
class: radiator_valve
- '04:155537':
class: radiator_valve
- '04:155533':
class: radiator_valve
- '04:155551':
class: radiator_valve
- '04:155445':
class: radiator_valve
- '04:155407':
class: radiator_valve
- '04:155403':
class: radiator_valve
- '04:050559':
class: radiator_valve
- '04:081849':
class: radiator_valve
- '04:017541':
class: radiator_valve
- '08:060775':
class: jasper_interface
- '31:136826':
class: jasper_thermostat
- '18:005567':
class: gateway_interface
block_list:
is_evofw3: false
device_class: problem
friendly_name: 18:005567 Gateway status
Is the known_list being ignored in the config?
Version 0.31.11 has been released, and is a recommended upgrade from 0.31.7.
Version 0.41.11 will be released presently.
Can anyone confirm they’ve used 0.31.11 without any issues?
Its working fine for me. It seems to improve the serial/device initialisation issue that I was experiencing on the previous release.
Looks like I spoke too soon 
, on reboot it looks like I continue to get an initialisation error. The issue is reported here SSM-D2 stopped working with 0.31.7 ? · Issue #174 · zxdavb/ramses_cc · GitHub
I have tested 0.31.11 and it seems that `climate.set_temperature` with multiple zones: not all are updated · Issue #149 · zxdavb/ramses_cc · GitHub with 3 seconds delay is no longer enough. I have tested with 5 seconds and only 3 out of 4 climates changed.
Any idea?
There is no doubt that ramses_cc / ramses_rf is complex to configure…
On that issue, we have a message:
Best practice is exactly one gateway (HGI) in the known_list: []
In this case, ‘exactly one’ does not mean 0!
That is, the corresponding known_list, which is enforced, has no HGIs in it.:
known_list:
32:142858 : {class: FAN}
32:126818:
class: REM
...
Try adding a HGI like so, and see how you go!
known_list:
18:136974: class: HGI
32:142858: class: FAN
32:126818:
class: REM
...