I may have jumped the gun a bit there…
Have now changed enforce_known_list: true to FALSE. Will wait and see if anything shows up.
One hour on and nothing in packet log yet apart from two lines displaying Ramses version.
If my usb device is not contacting the opentherm transmitter could that be the problem as there is some distance between? The Evohome is not too far however.
I had a similar thing, and it ended up that the customer did not install evofw3 firmware in my nancoul. Normal should packets fly in straight away since pressed any button on remote
Hi all, I am really desperate.
Has anyone been working impersonating the NUAIRE PIV remote or successful bind ?
Have
- Nuaire Drimaster ECO Heat PIV
- Nuaire DRI-ECO-4S (4-way switch)
- nanoCul 868 Mhz dongle with the latest evofw3
- SSM‐D2 from indalo tech
- Home Assistant Supervised v11.1 Fresh install (nothing else apart from standard )
The packet flew in and out, and log captured them, so both dongles worked as expected.
I tried impersonating and faking, etc., but nothing worked. Read zillions of materials.
This is my HA config when doing setup and test.
serial_port:
port_name: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 # Black One
# port_name: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00 # White One
baudrate: 115200
scan_interval: 60
advanced_features:
send_packet: true
# message_events: None
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:
file_name: ramses_packet_via_black.log
# file_name: ramses_packet_via_white.log
rotate_bytes: null
rotate_backups: 28
restore_cache:
restore_schema: false
restore_state: false
orphans_hvac: [18:135172, 30:071287, 32:205847, 32:123456]
known_list:
# 18:000730 ramses_rf itself
18:135172: # nanoCul 868 Mhz dongle # Black One
class: HGI
_note: nanoCul 868 Mhz
# 18:004628: # SparkFun_evofw3 ssm-32u4d2 # White One
# class: HGI
# _note: ssm-d2 868 Mhz
30:071287: # by fan ID FAN:071287
class: FAN
_note: Nuaire Drimaster Eco Heat DRI-ECO-HEAT-HC
32:205847: # by real remote REM:205847
class: REM
faked: false
commands:
normal: ' I --- 32:205847 30:071287 --:------ 22F1 003 00020A'
boost: ' I --- 32:205847 30:071287 --:------ 22F1 003 00030A'
heater_auto: ' I --- 32:205847 30:071287 --:------ 22F1 003 000A0A'
heater_off: ' I --- 32:205847 30:071287 --:------ 22F1 003 00090A'
_note: Nuaire DRI-ECO-4S (4-way switch)
32:123456: # FAKEd one
class: REM
faked: true
commands:
normal: ' I --- 32:123456 30:071287 --:------ 22F1 003 00020A'
boost: ' I --- 32:123456 30:071287 --:------ 22F1 003 00030A'
heater_auto: ' I --- 32:123456 30:071287 --:------ 22F1 003 000A0A'
heater_off: ' I --- 32:123456 30:071287 --:------ 22F1 003 00090A'
_note: Faked Nuaire DRI-ECO-4S (4-way switch)
Tried any version of ramses_cc and downgrade HA , same error always “Must be one command to learn” when trying to run commands.
Bind also does not work, shows "Assertation error " and “< Corrupt payload: Payload doesn’t match.”
This is when I want to send a command
Same error as always: “One command to learn.”
Do you have any ideas on which version HA is confirmed to be working with?
Don’t know what I could do wrong. Otherwise, it looks like both dongles are only worth binning them
How to impersonate ? Find current hardware remote IDs, add them in the config, and then run command. Done such way, and always same bug about “learn”
Drimaster PIV remote commands work perfectly for me. First you must bind the physical 4-way switch and confirm that it is working. Then use the remote ID (32:205847) with FAKED set TRUE assuming this RF ID corresponds with your physical 4-way switch remote.
Binding a faked remote is not currently supported and therefore if you try to create a random remote ID without binding it first it will be ignored by the Drimaster. That said, if you already have a physical switch there is little point in trying this as the Drimaster only supports binding one remote switch.
Extract from my configuration:
ramses_cc:
serial_port: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00
restore_cache:
restore_schema: true
restore_state: true
advanced_features:
send_packet: true
ramses_rf:
enforce_known_list: true
enable_eavesdrop: false
known_list:
30:098165: {class: FAN} # Nuaire PIV
32:208628:
class: REM
faked: true
commands:
normal: ' I --- 32:208628 30:098165 --:------ 22F1 003 00020A'
boost: ' I --- 32:208628 30:098165 --:------ 22F1 003 00030A'
heater_auto: ' I --- 32:208628 30:098165 --:------ 22F1 003 000A0A'
heater_off: ' I --- 32:208628 30:098165 --:------ 22F1 003 00090A'
_note: Nuaire DRI-ECO-4S (4-way switch)
I use the remote.send_command service, that works for me.
service: remote.send_command
data:
command: bypass_auto
target:
entity_id: remote.29_123456
If I remember correctly, the ramses_cc.send_command service doesn’t work. I believe I also reported that here before.
Edit: I get the same error as you when I use ramses_cc.send_command.
I “believed” I had installed the Evofw3 correctly when I originally did it. But following your suggestion (I am not familiar with using Ardinho) followed the same process and get an error “Include config.h instead of this file” Heres a screenshot. No idea if this where my issue is though.
Hi,
You need to import the whole project and files in one folder, otherwise, Arduino can not find the necessary files.
Hi, Thank you a lot for your reply now I know what I can and cannot do. Ramses_cc manual led me to confuse.
EDIT: You are a star: finally made it work by doing, checking and comparing configs and with your forum colleague’s response it made it happen
1 Like
Hi, big thank you for your reply. Now checking.
EDIT: You are a star: finally made it working doing this way rather thank sposed to do way
1 Like
Having spent far too many hours on this I’m getting nowhere - have re flashed the Nano cul on another Win PC (fresh install) Changed to old bootloader (which seemed to be the issue of not compiling) and then was able to verify/compile then did upload to device with no errors.
Plug it back in to HA machine, restart but still nothing. I’m running a Nuc with a Proxmox VM - In Proxmox when plugged in I get this:
In HA System I get this:
So have my config as follows:
ramses_cc:
serial_port: /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0
packet_log:
file_name: packet.log
rotate_backups: 28
ramses_rf:
enforce_known_list: true
Am pulling hair out now and getting to the point of giving up. Any further advice appreciated.
Thanks
I would like to announce ramses_cc alpha release 0.30.0.
Please install, test & report bugs here (there will be many bugs).
Please backup your HA before installing this version.
You should be able to roll back to your previous version of ramses_cc without resorting to restoring a backup, but you never know.
It is a pre-release, and you will not see it in HACS, unless you enable beta versions.
1 Like
Please post your config in this format:
ramses_cc:
serial_port: /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0
packet_log:
file_name: packet.log
rotate_backups: 28
ramses_rf:
enforce_known_list: false
You use three back-quotes (`), followed by ‘yaml’: (```yaml), then paste your lines after that, then three more back quotes.
ALso, please set enforce_known_list: false for now.
Also please look at:
cat home-assistant.log | grep ramses
And finally:
the baud rate you used to flash evofw3 on a nano (recommended 57600) should be the same used in HA.
Please let us know how to improve the docs.
In general, the manual is fantastic, explaining all the bits and pieces which I found useful. Truly, I do not want to be disrespectful because a lot of work is done to cover this manual. The only thing is some parts are not related to HVAC and vice versa.
I would suggest something like a “quick start guide.” and a sample full config for the quick start guide, for example, NAUAIRE PIV and common issues to date. Like the above full sample config and tip that In need to use remotely from service sorted a lot with the newest ramses cc version 22.40
No offense taken.
It woudl be reasonable for someone to add a section:
- How to fake a HVAC switch
FYI (all): because 0.30.x is so different to all previous versions, I will not be fixing any bugs in previous versions.
1 Like
Many thanks.
The correctly formatted version is as follows:
ramses_cc:
serial_port: /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0
packet_log:
file_name: packet.log
rotate_backups: 28
ramses_rf:
enforce_known_list: true
Have set enforce_known_list to false
I have also added:
logger:
logs:
custom_components.ramses_cc: info # show ramses_cc/ramses_rf state
ramses_rf.dispatcher: info # show packet payloads
I’m using HA OS so not sure I can or even know how to use:
cat home-assistant.log | grep ramses
I flashed at 115200 and my revised config is as follows:
ramses_cc:
serial_port: /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0
baudrate: 115200
packet_log:
file_name: packet.log
rotate_backups: 28
ramses_rf:
enforce_known_list: true
logger:
logs:
custom_components.ramses_cc: info # show ramses_cc/ramses_rf state
ramses_rf.dispatcher: info # show packet payloads
Appreciate your help.
These are the mistakes I can see:
ramses_cc:
serial_port:
port_name: /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0
baudrate: 115200
packet_log:
file_name: packet.log
rotate_backups: 28
ramses_rf:
enforce_known_list: false # set true only if you have a good known_list
logger:
logs:
custom_components.ramses_cc: info # show ramses_cc/ramses_rf state
ramses_rf.dispatcher: info # show packet payloads
NOTE: I have edited the above several times.
So to be clear my port name is wrong? Where do I find correct is it maybe /dev/ttyUSB0 which is device path?
I have the following identified in System Hardware for the device:
ttyUSB0
/dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0
Subsystem:
tty
Device path:
/dev/ttyUSB0
ID:
/dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0
Attributes:
DEVLINKS: >-
/dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0
/dev/serial/by-path/pci-0000:01:1b.0-usb-0:4.1:1.0-port0
DEVNAME: /dev/ttyUSB0
DEVPATH: >-
/devices/pci0000:00/0000:00:1e.0/0000:01:1b.0/usb2/2-4/2-4.1/2-4.1:1.0/ttyUSB0/tty/ttyUSB0
Also my file name: packet.log is incorrect? I believe that was from the Wiki.
I’ll have to read up on how the logger works.
Thanks
Where did you get your USB device from?
Has it ever received (picked up) packets.
Do you have access to a Linux CLI?
The logger is a separate piece of software, separate from ramses_cc.
I have asked you to cat home-assistant.log | grep ramses, and you have not provided that information.