Thanks for post! I think there are some differences between our units. Mine won’t respond if I use a random remote code/id. I have to use the id of the real (paired) remote or somehow pair my fake remote, otherwise the unit won’t respond. And it looks like the MVS-15 reports less status information?
Sorry I did not express myself correctly. I do have a remote control paired with my ventilallation (like yours my ventillation won’t respond to random remote id). What I meant is that I used the commands from the wiki to fake the remote control and I replaced in these commands the ID of the ventillation with my ventillation ID and the ID of the remote control with my remote control ID so that the commands look like they are being sent by my remote control. I also declared my remote control as faked in my scheme.
This looks like this in my configuration:
ramses_cc:
serial_port: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00 #/dev/ttyACM2
restore_cache: true
packet_log:
file_name: ramses_packet.log
rotate_backups: 7
ramses_rf:
enforce_known_list: true
01:076010:
system:
appliance_control: 10:052644
underfloor_heating:
02:024358: {}
orphans_hvac: [29:156898, 32:132125]
known_list:
01:076010: #controller
02:024358: #UFH zone
03:111111: {faked: true}
03:222222: {faked: true}
03:111113: {faked: true}
03:111114: {faked: true}
03:123456: {faked: true}
04:081013:
04:161168:
04:161198:
04:240790:
10:052644:
18:198151:
22:015492:
22:015505:
30:042165:
32:132125: {class: FAN} #Orcon ventillation
29:156898:
class: REM
faked: True
commands:
away: ' I --- 29:156898 32:132125 --:------ 22F1 003 000007'
low: ' I --- 29:156898 32:132125 --:------ 22F1 003 000107'
medium: ' I --- 29:156898 32:132125 --:------ 22F1 003 000207'
high: ' I --- 29:156898 32:132125 --:------ 22F1 003 000307'
auto: ' I --- 29:156898 32:132125 --:------ 22F1 003 000407'
auto2: ' I --- 29:156898 32:132125 --:------ 22F1 003 000507'
boost: ' I --- 29:156898 32:132125 --:------ 22F1 003 000607'
disable: ' I --- 29:156898 32:132125 --:------ 22F1 003 000707'
bypass_open: ' W --- 29:156898 32:132125 --:------ 22F7 003 00C8EF'
bypass_close: ' W --- 29:156898 32:132125 --:------ 22F7 003 0000EF'
bypass_auto: ' W --- 29:156898 32:132125 --:------ 22F7 003 00FFEF'
reset_filter: ' W --- 29:156898 32:132125 --:------ 10D0 002 00FF'
_note: based upon an Orcon 15RF 6-button remote (VMN-15LF01)
I hope this clarifies what I meant.
Interesting. I have the same understanding as what you describe concerning the naming but I have the opposite than what you observe. In my system the exhaust temperature is always lower than the outdoor temperature (which does not make sense).
See graph below:
I wonder why my system is different 
In my experience there can be a lack of consistency both between and within vendors.
I hook up on this thread to clarify a few basic things ::
My heating system is controlled by a Honeywell CM927 and BDR91.
My domotic platform is Home Assistant running on Raspberry PI 4.
I have a RFXtrx433XL : can I use it ? It doesn’t seem supported to run evofw3 : correct ?
The SSM-D2 from Idalo-tech seems an easy choice since already preloaded with evofw3. Right ?
With Home Assistant connected to my BDR91, what should/could I do with my existing CM927 ? Keep it running in parallel ? Or decommission it ?
Thanks, Bernard.
Hi,
Firstly, fantastic and impressive development ! Thank to the developer and the community.
I’m reading all 3200 posts and got to 600.
I’m new to HA and as I have got a new W11 PRO powerful laptop and I used the HYPERV machine (quicker way for me). Don’t blame me…I know but the same computer will be used for other VM for my job (no choice).
Because of that, and for HA, I therefore prefer to use gateway on which I connect RF modules and connect to HA through Ethernet (using MQTT) :
- I currently use an Rpi as a gateway with RFM69 modules (Mysensors library).
- In the future I will add ZigBee to the same Rpi Gateway.
- I will use an ESP32 to connect Bluetooth sensors (SwitchBot)
I have understood the following: I need to buy a USB NANOCUL which must be recognized by HA. Do you have a link on Amazon for this module ?
I know a solution to transfer a COM port from HyperV Host to a VM running Windows (I use a Windows VM for Arduino development and I connect the USB FTDI from the HyperV host : very easy and short command).
But, this is between Hyper V Windows to VM Windows.
Keep Hyper V VM
Is it possible to do the same Between a Windows host and VM LINUX ?
Is it possible to have the NANOCUL recognized in HA (linux) through the HyperV VM (windows) ?
The problem with HA is that it is not a standard linux and I’ll have more difficulties.
I saw that it is possible to install an Portainer Addon, but could it help ?
If it’s too complex, I have to use something other than a VM on HYPER V.
But I would like to keep my Windows11 PRO (new PC)
use another virtualization or Container on Windows 11
Maybe install HA in a Linux distribution in a virtualization (KVM,QEMU) / Container.
And then use a similar command to mount the USB connected to the host (Windows) on the Linux machine (running in HyperVisor).
Other solution
If this is not possible, what other solution I have ?
WSL : https://learn.microsoft.com/en-us/windows/wsl/install
Installing HA on the Rpi does not seem to me a good idea in the long term (SDCard reliability).
Do you also have a gateway solution ?
In Short : which setup I can use to mount the NANOCUL on HA and keep my Windows OS ?
As soon as I have a return, I could also launch myself on this integration.
Thank for the help.
With these controllers, ramses_cc is essentially read-only (with some minor exceptions).
No - it does not support evofw3.
This is the gold-standard for the gateway hardware.
You can bind the evofw3-compatible gateway (and thus ramses_cc / HA) to the controller in addition to the CM927 - the BDR will be ‘on’ when either asks it to be on.
However, you will have to create all the logical for a call for heat yourself. Completely doable (you could create the equivalent of an evohome controller), but would be a lot of work.
I feel you would be better of getting an old evohome controller, or a round thermostat and an RFG100 instead of sepnding youe money on an SSM-D2, and using HA’s official evohome integration - this would give you a lot of additional functionality, for the least financial outlay.
There are links further up the thread. If you can, get an SSM-D2 instead.
I use WSL for test/dev and it works fine for me.
However, I feel any Windows Laptop configuration will not be reliable enough for general use of HA.
I would persist with the Raspberry Pi (version 3 or newer) you can buy SD cards that are designed for that environment.
1 Like
Thanks David,
So does the rfg100 connect to my bdr91 ?
While the CM927 is also connected to the same bdr91 ?
Hi Community,
Anybody to help me and clarify ?
Thanks,
yes, i think they can be used in parallel. i use a evotouch in parallel to my HGI80. so i can control my heating either via the evotouch interface or via home assistant.
Just received my nanocul you suggested. Alexander from schlauHaus did already the preloading of evofw3 for me. Will try to connect it to HA this weekend. 
1 Like
OK. now I am lost. How do I recognize familiar ID’s?
After playing with the remote I get many readings all the time… I tried playing with the settings…, but I have no idea what I am doing…to be honest.
ramses_cc:
scan_interval: 10
serial_port: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0
packet_log:
file_name: packet.log
rotate_bytes: null
rotate_backups: 7
ramses_rf:
enforce_known_list: false # if not true, still enforces the block_list
disable_discovery: false
disable_sending: false # do not transmit any packets, ever
enable_eavesdrop: true # can be used to create an initial system schema
Packet.log
2023-01-21T15:21:00.204520 000 RQ --- 18:075527 29:207773 --:------ 22F4 001 00
2023-01-21T15:21:29.961242 000 RQ --- 18:075527 29:207706 --:------ 2210 001 00
2023-01-21T15:21:30.192219 000 RQ --- 18:075527 29:207773 --:------ 22F8 001 00
2023-01-21T15:21:59.975312 000 RQ --- 18:075527 29:207706 --:------ 22E0 001 00
2023-01-21T15:22:00.205225 000 RQ --- 18:075527 29:207773 --:------ 313E 001 00
2023-01-21T15:22:29.982628 000 RQ --- 18:075527 29:207706 --:------ 22E5 001 00
2023-01-21T15:22:30.213809 000 RQ --- 18:075527 29:207773 --:------ 3222 001 00
2023-01-21T15:22:54.383243 075 I --- 32:102841 --:------ 32:102841 1298 003 0002CA
2023-01-21T15:22:54.430076 000 RQ --- 18:075527 29:207706 --:------ 22E9 001 00
2023-01-21T15:22:57.452936 000 RQ --- 18:075527 29:207773 --:------ 10D0 001 00
2023-01-21T15:22:57.680091 000 RQ --- 18:075527 29:207706 --:------ 22F2 001 00
2023-01-21T15:23:27.440866 000 RQ --- 18:075527 29:207773 --:------ 22F1 001 00
2023-01-21T15:23:27.668264 000 RQ --- 18:075527 29:207706 --:------ 22F4 001 00
2023-01-21T15:23:57.445759 000 RQ --- 18:075527 29:207773 --:------ 2210 001 00
2023-01-21T15:23:57.672727 000 RQ --- 18:075527 29:207706 --:------ 22F8 001 00
2023-01-21T15:24:01.795159 052 I --- 32:102225 29:207706 --:------ 31E0 008 0000000001006400
2023-01-21T15:24:01.810122 079 I --- 29:207706 --:------ 29:207706 31D9 003 000003
2023-01-21T15:24:01.866146 000 RQ --- 18:075527 29:207706 --:------ 313E 001 00
2023-01-21T15:24:02.094988 000 RQ --- 18:075527 29:207773 --:------ 22E0 001 00
2023-01-21T15:24:31.830949 000 RQ --- 18:075527 29:207706 --:------ 3222 001 00
2023-01-21T15:24:32.061784 000 RQ --- 18:075527 29:207773 --:------ 22E5 001 00
2023-01-21T15:25:01.882152 000 RQ --- 18:075527 29:207773 --:------ 22E9 001 00
2023-01-21T15:25:04.848451 000 RQ --- 18:075527 29:207706 --:------ 10D0 001 00`
OK @nickasdf little update on the progress.
Had no clue entities would pop up automatically…
Also found an older post from you where you had some config set and I think it helped me a little figuring out what is what…
At least I got on thing working and those are CO2 sensor from the remote. I think one is from the neighbour and already figured out which one is which.
So far so good, but then…
Trying to figuring out the buttons on the remote… I got the next thing from the packet.log
2023-01-21T22:11:32.687391 000 RQ --- 18:075527 10:123446 --:------ 3220 005 00000F0000
2023-01-21T22:12:02.672294 000 RQ --- 18:075527 10:123446 --:------ 3220 005 0000300000
2023-01-21T22:12:13.300328 054 RQ --- 32:102225 29:207706 --:------ 31D9 001 00
2023-01-21T22:12:13.338189 082 RP --- 29:207706 32:102225 --:------ 31D9 003 000004
2023-01-21T22:12:13.385284 000 RQ --- 18:075527 10:123446 --:------ 3220 005 0080310000
2023-01-21T22:12:16.176095 051 I --- 32:102225 29:207706 --:------ 22F3 007 00123C01040404
2023-01-21T22:12:16.210062 082 I --- 29:207706 --:------ 29:207706 31D9 003 000001
2023-01-21T22:12:16.708412 082 I --- 29:207706 --:------ 29:207706 31D9 003 000001
2023-01-21T22:12:16.751404 000 RQ --- 18:075527 10:123446 --:------ 3220 005 0000000000
2023-01-21T22:12:46.793543 000 RQ --- 18:075527 10:123446 --:------ 3220 005 0000050000
2023-01-21T22:13:16.770088 000 RQ --- 18:075527 10:123446 --:------ 3220 005 0080730000
2023-01-21T22:13:39.562618 051 I --- 32:102225 29:207706 --:------ 22F3 007 00123C02040404
2023-01-21T22:13:39.598529 082 I --- 29:207706 --:------ 29:207706 31D9 003 000002
2023-01-21T22:13:39.634782 000 RQ --- 18:075527 10:123446 --:------ 2401 001 00
2023-01-21T22:13:40.597740 083 I --- 29:207706 --:------ 29:207706 31D9 003 000002
2023-01-21T22:14:09.628175 000 RQ --- 18:075527 10:123446 --:------ 3EF0 001 00
2023-01-21T22:14:11.387282 094 I --- 29:207773 --:------ 29:207773 31D9 003 000003
2023-01-21T22:14:11.508784 094 I --- 29:207773 --:------ 29:207773 31D9 003 000003
2023-01-21T22:14:11.638977 095 I --- 29:207773 --:------ 29:207773 31D9 003 000003
2023-01-21T22:14:39.623460 000 RQ --- 18:075527 10:123446 --:------ 10A0 001 00
2023-01-21T22:14:57.721028 053 I --- 32:102225 29:207706 --:------ 31E0 008 0000000001006400
2023-01-21T22:14:57.744946 081 I --- 29:207706 --:------ 29:207706 31D9 003 000002
2023-01-21T22:14:57.778927 000 RQ --- 18:075527 10:123446 --:------ 1081 001 00
2023-01-21T22:15:27.759624 000 RQ --- 18:075527 10:123446 --:------ 22D9 001 00
So my config file looks like this right now with a little help of an earlier post of yours:
ramses_cc:
serial_port: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0
scan_interval: 10
packet_log:
file_name: packet.log
rotate_backups: 28
known_list:
18:075527: # nanoCul 868 Mhz dongle? 18:070912?
class: HGI
_note: nanoCul 868 Mhz
29:207706: # Orcon 15RF remote
class: REM
# faked: true
_note: Orcon 15RF
commands:
auto: " I --- 29:207706 --:------ 29:207706 31D9 003 000004"
low: " I --- 29:207706 --:------ 29:207706 31D9 003 000001"
medium: " I --- 29:207706 --:------ 29:207706 31D9 003 000002"
high: " I --- 29:207706 --:------ 29:207706 31D9 003 000001"
away: " I --- 29:207706 --:------ 29:207706 31D9 003 000000"
timer_15mins: " I --- 32:102225 29:207706 --:------ 22F3 007 00123C01040404"
timer_30mins: " I --- 32:102225 29:207706 --:------ 22F3 007 00123C02040404"
timer_60mins: " I --- 32:102225 29:207706 --:------ 22F3 007 00123C03040404"
32:102225: {class: CO2}
32:102841: {class: CO2}
ramses_rf:
enforce_known_list: false # 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
Apparently you managed to send signals. Everything seems a little bit confusing to me, but I get this error if I try to use RAMSES Send remote command. Maybe I am doing something completely wrong. But I hope you or someone else can help me with this.
Thanks!
I think you have the ID of your 15RF remote not figured out correctly yet. The remote sends 22F1 for a non-timed mode and 22F3 for a timed mode. 29:207706 is the ID of your fan, and 32:102225 is the ID of your CO2 sensor, which can also act as a remote. Currently ramses_cc doesn’t support faking of a device that is both a remote and a CO2-sensor. And you need to set faked to true for a remote that you wish to impersonate, otherwise ramses_cc will refuse to send packets. So that’s a problem.
31D9 is a fan mode report, not a command.
You should also add the fan to your known list.
Thanks that makes sense I think. SO I’ve set it up right now like this:
ramses_cc:
serial_port: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0
scan_interval: 10
packet_log:
file_name: packet.log
rotate_backups: 28
known_list:
18:075527: # nanoCul 868 Mhz dongle? 18:070912?
class: HGI
_note: nanoCul 868 Mhz
32:102225: # Orcon 15RF remote
class: REM
faked: true
_note: Orcon 15RF
commands:
away: "I --- 32:102225 29:207706 --:------ 22F3 007 00520C00040404"
auto: " I --- 32:102225 29:207706 --:------ 22F1 003 000404"
timer1_60mins_low: " I --- 32:102225 29:207706 --:------ 22F3 007 00123C01040404"
timer2_13hours_medium: " I --- 32:102225 29:207706 --:------ 22F3 007 00123C02040404"
timer3_60mins_high: " I --- 32:102225 29:207706 --:------ 22F3 007 00123C03040404"
29:207706: # Orcon MVS-15 fan
class: FAN
_note: Orcon MVS-15
# 32:102225: {class: CO2}
32:102841: {class: CO2}
ramses_rf:
enforce_known_list: false # 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
I noticed I had a little bit of different remote then Nickasdf… But I think this should be right then…
I am not sure If I can change the name of the remote (32:102225: # Orcon 15RF remote) something into 32:123456. Cause now I can’t read the CO2 sensor.
Anyways… trying to send still gives me an error…
Am I missing something?
I always use the remote.send_command service myself, that seems to work.
I think I reported an issue with ramses_cc.send_command, but I don’t think it was fixed yet.
1 Like
Thanks!! That seems to work! 
or
service: remote.send_command
data:
command: auto
target:
entity_id: remote.32_102225
Too bad I can’t get the reading now from the CO2 sensor. Any work around for this?
Thanks Ivo,
However I’m not familiar with this HGI80.
David was suggesting RFG100 instead.
@zxdavb : can you please confirm ?
Does anyone use a hardware device with HA that needs a baud rate lower than what the HGI80/SSM-D uses I.e. 115200?
If so, how would you specify that in the ramses_cc configuration yaml?