I need some help and was hoping to find a direction here.
I added the integration per the wiki steps.
Entities are found I cant use them. Can someone help?
i dont see any things in the HA logā¦ and here is my HA config file
ramses_cc:
serial_port: /dev/ttyUSB1
packet_log:
file_name: packet.log
rotate_backups: 28
restore_cache: true
scan_interval: 60
ramses_rf:
enforce_known_list: true
known_list:
18:123456: # Honeywell HGI80
Your are enforcing the known_list, but it is empty except for a value from the docs. You need to populate that with the devices that are in your network.
Is the SSM-D2 solution with Atmega32U4 preferable to the Atmega328p solutions?
Yes, the SSM-D2 from Indalo-Tech is the gold standard hardware for this integration. It is preferable to all other solutions.
2 Likes
For those in the EU, this also works well and has the hardware UART. evofw can be uploaded using the Zadig tool (it has a DFU bootloader.)
https://shop.busware.de/product_info.php/products_id/29
1 Like
Oh!
I might have to invest in one.
Let home assistant run for some time wit enforce_known_list: false.
Then restart home assitant and in the home assistant logging you can find a schema of the devices that have been found. See a few example in this forum (e.g. search for main_tcs).
Is the 3.3v and the processor running at 8 MHz a problem with this integration?
Running rock solid so far. Voltage is a non-issue and evofw3 supports both 8 and 16mhz versions.
1 Like
This is really a question for the dev of evofw3, but IIRC, 8 MHz is OK for a HW UART, but a SW UART should have 16 MHz to be reliable.
I have a fully workin virtual Itho Co2 remote implemented in my repository.
Take a look at:
I am able to pair a randomly generated remote address to my HRU and it accepts commands.
Iām really interested in the log of an Itho RFT N remote which sadly I donāt have.
Having trouble impersonating an already bound Nuaire PIV 4 way remote.
[547168192448] Error handling message: Unknown error (unknown_error) Mo Gusbi from 2a00:23c7:e48d:f301:4868:70e4:4669:5a55 (Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36)
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/decorators.py", line 26, in _handle_async_response
await func(hass, connection, msg)
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 731, in handle_execute_script
script_result = await script_obj.async_run(msg.get("variables"), context=context)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 1578, in async_run
return await asyncio.shield(run.async_run())
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 420, in async_run
await self._async_step(log_exceptions=False)
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 470, in _async_step
self._handle_exception(
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 493, in _handle_exception
raise exception
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 468, in _async_step
await getattr(self, handler)()
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 704, in _async_call_service_step
response_data = await self._async_run_long_action(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 666, in _async_run_long_action
return long_task.result()
^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/core.py", line 2035, in async_call
response_data = await coro
^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/core.py", line 2072, in _execute_service
return await target(service_call)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 830, in handle_service
await service.entity_service_call(
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 876, in entity_service_call
response_data = await _handle_entity_call(
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 948, in _handle_entity_call
result = await task
^^^^^^^^^^
File "/config/custom_components/ramses_cc/remote.py", line 216, in svc_send_command
await self.async_learn_command(*args, **kwargs)
File "/config/custom_components/ramses_cc/remote.py", line 135, in async_learn_command
raise TypeError("must be exactly one command to learn")
TypeError: must be exactly one command to learn
Hereās my config:
ramses_cc:
serial_port: /dev/ttyACM0
ramses_rf:
enforce_known_list: true
known_list:
18:074254:
class: FAN
_note: Nuaire PIV
30:071138:
class: REM
faked: true
commands:
normal: " I --- 30:071138 18:074254 --:------ 22F1 003 00020A"
boost: " I --- 30:071138 18:074254 --:------ 22F1 003 00030A"
heater_auto: " I --- 30:071138 18:074254 --:------ 22F1 003 000A0A"
heater_off: " I --- 30:071138 18:074254 --:------ 22F1 003 00090A"
_note: Nuaire DRI-ECO-4S (4-way switch)
My Config looks like this:
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
My logs only say this:
023-11-10 15:31:15.953 WARNING (SyncWorker_0) [homeassistant.loader] We found a custom integration ramses_cc which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2023-11-10 15:31:24.299 WARNING (MainThread) [ramses_rf.protocol.schemas] Best practice is exactly one gateway (HGI) in the known_list:
2023-11-10 15:31:24.299 WARNING (MainThread) [ramses_rf.protocol.schemas] An empty known_list was provided, so it cant be used as a whitelist (device_id filter)
2023-11-10 15:31:24.299 WARNING (MainThread) [ramses_rf.protocol.schemas] It is strongly recommended to provide a known_list, and use it as a whitelist (device_id filter), configure: enforce_known_list = True
2023-11-10 15:31:24.416 WARNING (MainThread) [ramses_rf.protocol.transport] Not using any device filter: using a known_list (as a whitelist) is strongly recommended)
2023-11-10 15:31:24.428 WARNING (MainThread) [ramses_rf.protocol.transport] Not using any device filter: using a known_list (as a whitelist) is strongly recommended)
Where do I find Known list devices to add/
Thanks for help.
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.