Did you remember to flush the cache?
No, i didn’t. Which cache are you referring to?
I just tried to add restore_state in the HA config:
ramses_cc:
serial_port: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00
restore_state: false
But that doesn’t work:
“Configuration warnings
Invalid config for ‘ramses_cc’ at configuration.yaml, line 46: ‘restore_state’ is an invalid option for ‘ramses_cc’, check: ramses_cc->restore_state”
Your formatting seems to be off. It should be:
ramses_cc:
restore_cache:
restore_schema: false
restore_state: false
Don’t forget to set it back to true afterwards
1 Like
yeah, this was the fix. Thanks!!
I think it is not correctly documented in the ramses_cc Wiki: 9. FAQ · zxdavb/ramses_cc Wiki · GitHub
You’re absolutely welcome mate. That’s what we’re all here for.
Just updated HAOS on my green to version 12.0 and I’m now getting this error logged:
Logger: homeassistant.components.climate
Source: components/climate/init.py:354
Integration: Climate (documentation, issues)
First occurred: 15:27:23 (1 occurrences)
Last logged: 15:27:23
Entity climate.01:215596 (<class ‘custom_components.ramses_cc.climate.RamsesController’>) implements HVACMode(s): heat, off, auto and therefore implicitly supports the turn_on/turn_off methods without setting the proper ClimateEntityFeature. Please create a bug report at Issues · zxdavb/ramses_cc · GitHub
This post from a couple days ago suggests it might relate to a change in HA 2024.2 update?
EDIT: sorry forgot to add, I’m using RAMSES CC version 0.41.7
yes it is. The integration needs some fixes (not much…)
btw at the moment it is nothing blocking
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!
2 Likes
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:
- keep the
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 name - ensure if you change the configuration via the UI, you consider if you shoudl update the configuration.yaml file (e.g. cache config: likely not, known list: likely yes)
When you want to use the ramses_cc: configuration again, simply
- make any changes to the configuration.yaml file
- use the (three dot) menu to
Deletethe RAMSES RF integration from the web UI:
Settings > Devices & Services > Integrations > RAMSES RF
- reboot HA (it will now load
ramses_ccas 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:
- re-binding your remote & sensors to the FAN
- using all the features of the remote
- including and
10E0packets for your kit
We’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?