OK - with the bare minimum config, as you suggested, I get this in the packet.log:
2022-11-06T14:52:46.503093 # ramses_rf 0.21.0
2022-11-06T14:52:47.678535 000 I --- 18:070686 63:262142 --:------ 7FFF 015 001001844D6E072B76302E32312E30
And a binary sensor appears in the entity list:
binary_sensor.18_070686_status
The binary sensor shows as a “problem” by default, but that can be changed. Nothing else appears to show and nothing else is configurable…
Can you check the attributes on that binary sensor? I think it represents your gateway device. It may show unmapped devices in the “Other list”.
Schema {}
Config enforce_known_list: true
Known list
- '32:xxxxxx': class: ventilator
- '18:xxxxxx': class: gateway_interface
- '37:xxxxxx': class: co2_sensor
- '29:xxxxxx': class: switch
- '37:yyyyyy': class: switch faked: true
Block list
Other list
is evofw3 true
This is what is shown on my binary sensor attributes. I only have HRU devices, so I only have entries in the orphans_hvac list and the known_list dict. I have eavesdropping disabled. I’ll see what happens if I turn that on, I would expect my neighbours’ fans to show up in the “Other list” then.
The attributes on the sensor are :
Attributes
Schema
{}
Config
enforce_known_list: false
Known list
- '18:070686':
class: gateway_interface
Block list
Other list
is evofw3
true
Other list remains empty for me, with eavesdropping enabled. The packet.log shows plenty of other devices that are not mine.
@zxdavb Did something change there? It used to show my neighbours’ devices there, even with eavesdropping disabled…
Eavesdropping has to do with making decision about payloads (or not), not if a packets is ignored (or not) - in any case - every packet seen (valid or not) will end up in the packet log, so check that.
If relevant, try tuning dongle and/or leave it running and turn the Nuaire off/on & see?
My hardware works fine, my packet log contains many more devices than just mine.
What I meant is that I expected things to show up in the “Other list” too, I’m pretty sure an older version of the software put any devices in there that were seen but were not on my known list.
Version 0.22.1 released - includes bugfixes and a small enhancement.
Bugfix: failure during HA startup:
None is of the wrong type ... @ data['ramses_cc']['advanced_features']['message_events']
Bugfix for ramses_cc:learn_command and remote:learn_command service calls:
"TypeError: must be exactly one command to learn"
Bugfix/Enhancement: Can’t use send_packet service to cast commands from gateway
Bugfix: failure to instantiate global orphans under certain circumstances
ramses_cc: {heat_orphans: xxx, hvac_orphans: yyy}
Possible bugfix: incorrect error logged for BDR91Ts
Support the development of ramses_rf by reporting this packet (byte 5: )
I misunderstood - I thought we were taking about @dgillings’s system.
Not sure - would have to check for a regression.
I received my nanoCUL today.
(unfortunately the one from ebay from Smarthome Komponente)
I followed the wiki and everything was done according instructions.
However I receive no data/ packets in the logs.
When I send a command to a Evohome zone, I can see in the log the following, but no data/ logs in the packet.log
[custom_components.ramses_cc.coordinator] Saving the client state cache (packets, schema)...
Well, I’ve got one - and it works fine for me.
This is really an issue for Pete, me thinks - as you’ve installed evofw3 and there’s no evidence that bit is working.
I seem to recall you have to make sure you chose the right board, etc. Have a look at:
Whats the difference between climate.controller and climate.ramses_cc_01_xxxxxx_00 (which is the actual climate for the zone which has evotouch set)?
The temps dont match and ‘call for heat/heating’ seems totally random…
You are making an assumption that I hope I can clear up for you…
All climate entities are zones, with the exception of the climate.controller, which is the system as a whole (i.e. not a zone): maybe it should be called climate.temperature_control_system (TCS) instead.
For example:
climate.ramses_cc_01_xxxxxx_00 can be set to FollowSchedule, PermanentOverride, AdvancedOverride, or PermamentOverrideclimate.controller can be set to Auto, Away, HeatingOff, etc.In addition, the former can have a setpoint (target temperature), the latter cannot.
The Controller has a temperature sensor, that maybe is configured as the sensor for a zone (or not):
sensor.ramses_cc_01_xxxxxxThe temperature of climate.controller is an anachronism. All climate entities must have a current temperature, but the TCS (the system as a whole, i.e. the whole house) doesn’t have such a concept…
So, what to do?
The temperature of the TCS entity (climate.controller) is the average of all the zones that have a non-null temperature. This is a HA convention.
Your assumption is that the controller device is a monolithic unit. No. It two things: a TCS and a temperature sensor (which, like any such sensor, can be configured as a zone sensor) that happen to be in the same plastic box.
I hope that answers the question - it should be in the FAQ section of the wiki, I guess…
Thanks I had a look at the wiki, and when I connect the nanoCUL to ArduinoIDE monitor I get following data, so I presume it works.
# evofw3 0.7.1
070 I --- 04:212668 --:------ 01:217699 2309 003 020640
074 I --- 01:217699 --:------ 01:217699 0009 003 FC00FF
073 I --- 04:212668 --:------ 01:217699 12B0 003 020000
072 I --- 04:212668 --:------ 01:217699 12B0 003 020000
I have a very simple config, but no packets are logged in HA. (after 24h)
ramses_cc:
serial_port:
port_name: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0
packet_log:
file_name: packet.log
Yep - looks good. Are you moving it elsewhere in the house when it is connected to HA?
If so - coudl be a reception problem? Take a TRV off a radiator at with it <1m from the dongle, press a button or two - that will let you know if it is a simple problem of RF reception.
Have you 100% confirmed you’ve got the correct port_name?
Do any errors show up in the home-assistant.log?
At most, you should only have to wait 5-6 mins between packets (even that is a little excessive).
I tried to hold it a TRV close to the HA server, but no effect.
This is my log (I just installed the latest beta to try)
2022-11-09 14:11:07.506 INFO (MainThread) [custom_components.ramses_cc] ramses_cc v0.22.1, is using ramses_rf v0.22.1
2022-11-09 14:11:07.506 DEBUG (MainThread) [custom_components.ramses_cc]
Config = OrderedDict([('serial_port', OrderedDict([('port_name', '/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0'), ('dsrdtr', False), ('rtscts', False), ('xonxoff', True), ('timeout', 0), ('baudrate', 115200)])), ('known_list', OrderedDict([('01:217699', OrderedDict([('class', 'HGI'), ('alias', None), ('faked', None), ('_domain', 'heat')]))])), ('packet_log', OrderedDict([('file_name', 'packet.log'), ('rotate_backups', 7)])), ('block_list', {}), ('scan_interval', datetime.timedelta(seconds=60)), ('ramses_rf', {'max_zones': 12, 'disable_sending': False, 'disable_discovery': False, 'enable_eavesdrop': False, 'use_aliases': False, 'reduce_processing': 0, 'use_native_ot': 'prefer', 'enforce_known_list': False}), ('restore_cache', {'restore_schema': True, 'restore_state': True}), ('advanced_features', {'send_packet': False, 'message_events': None})])
2022-11-09 14:11:07.733 DEBUG (MainThread) [custom_components.ramses_cc.schemas] Loaded a cached schema: {'main_tcs': None, 'orphans_heat': [], 'orphans_hvac': []}
2022-11-09 14:11:07.733 DEBUG (MainThread) [custom_components.ramses_cc.schemas] A config schema was not provided
2022-11-09 14:11:07.733 INFO (MainThread) [custom_components.ramses_cc.schemas] Using the cached schema (cached schema is a superset of config schema)
2022-11-09 14:11:07.734 WARNING (MainThread) [ramses_rf.protocol.schemas] Best practice is exactly one gateway (HGI) in the known_list: []
2022-11-09 14:11:07.738 WARNING (MainThread) [ramses_rf.protocol.schemas] It is strongly recommended to use the known_list as a whitelist (device_id filter), configure: enforce_known_list = True
2022-11-09 14:11:07.741 INFO (MainThread) [custom_components.ramses_cc.coordinator] Success initialising with the cached schema: {'main_tcs': None, 'orphans_heat': [], 'orphans_hvac': []}
2022-11-09 14:11:07.741 INFO (MainThread) [custom_components.ramses_cc.coordinator] Restoring the client state cache (packets only)...
2022-11-09 14:11:07.836 INFO (MainThread) [homeassistant.setup] Setting up evohome
2022-11-09 14:11:07.842 WARNING (MainThread) [custom_components.solaredge_modbus_multi.hub] Advanced Power Control: StorEdge Control is enabled. Use at your own risk!
2022-11-09 14:11:07.854 WARNING (MainThread) [custom_components.solaredge_modbus_multi.hub] Advanced Power Control: Export Limit Control is enabled. Use at your own risk!
2022-11-09 14:11:07.856 INFO (MainThread) [ramses_rf.protocol.transport] RAMSES_RF protocol library v0.22.1, using PacketProtocolFile
2022-11-09 14:11:07.856 DEBUG (MainThread) [ramses_rf.protocol.transport] PacketProtocolFile.pause_writing()
2022-11-09 14:11:07.857 DEBUG (MainThread) [ramses_rf.protocol.transport] PacketProtocolFile.connection_made(<ramses_rf.protocol.transport.SerTransportRead object at 0x7fb3bdba8040>)
2022-11-09 14:11:07.858 WARNING (MainThread) [ramses_rf.protocol.transport] Not using any device filter: using a known_list (as a whitelist) is strongly recommended)
2022-11-09 14:11:07.860 DEBUG (MainThread) [ramses_rf.protocol.transport] PacketProtocolFile.pause_writing()
2022-11-09 14:11:07.912 INFO (MainThread) [custom_components.ramses_cc.coordinator] Restored the cached state.
2022-11-09 14:11:07.912 DEBUG (MainThread) [custom_components.ramses_cc.coordinator] Starting the RF monitor...
2022-11-09 14:11:07.938 INFO (MainThread) [ramses_rf.protocol.transport] RAMSES_RF protocol library v0.22.1, using PacketProtocolQos
2022-11-09 14:11:07.939 DEBUG (MainThread) [ramses_rf.protocol.protocol] MsgTransport._set_dispatcher(<bound method PacketProtocolQos.send_data of PacketProtocolQos(enforce_include=False)>)
2022-11-09 14:11:07.948 DEBUG (MainThread) [ramses_rf.protocol.transport] PacketProtocolQos.connection_made(SerialTransport(<_UnixSelectorEventLoop running=True closed=False debug=False>, PacketProtocolQos, Serial<id=0x7fb3bffbcca0, open=True>(port='/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=0, xonxoff=True, rtscts=False, dsrdtr=False)))
2022-11-09 14:11:07.948 WARNING (MainThread) [ramses_rf.protocol.transport] Not using any device filter: using a known_list (as a whitelist) is strongly recommended)
2022-11-09 14:11:07.949 DEBUG (MainThread) [ramses_rf.protocol.transport] PacketProtocolQos.resume_writing()
20
2022-11-09 14:11:08.055 DEBUG (MainThread) [custom_components.ramses_cc]
Store = {'client_state': {'schema': {'main_tcs': None, 'orphans_heat': [], 'orphans_hvac': []}, 'packets': {}}, 'remotes': {}}
2022-11-09 14:11:08.055 DEBUG (MainThread) [custom_components.ramses_cc] Finished fetching ramses_cc data in 0.000 seconds (success: True)
2022-11-09 14:11:08.055 INFO (MainThread) [homeassistant.setup] Setup of domain ramses_cc took 0.5 seconds
2022-11-09 14:16:07.914 INFO (MainThread) [custom_components.ramses_cc.coordinator] Saving the client state cache (packets, schema)...
2022-11-09 14:21:07.914 INFO (MainThread) [custom_components.ramses_cc.coordinator] Saving the client state cache (packets, schema)...
2022-11-09 14:26:07.916 INFO (MainThread) [custom_components.ramses_cc.coordinator] Saving the client state cache (packets, schema)...
2022-11-09 14:31:07.917 INFO (MainThread) [custom_components.ramses_cc.coordinator] Saving the client state cache (packets, schema)...
So you definitely don’t get:
2022-11-09 16:15:07.197 ERROR (MainThread) [ramses_rf.protocol.transport] Failed to open /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0
… in your HA log? (I have to ask, as you have posted an edited log).
This is what I have:
2022-11-09 16:32:32.407 DEBUG (MainThread) [ramses_rf.protocol.transport] PacketProtocolQos.connection_made(SerialTransport(<_UnixSelectorEventLoop running=True closed=False debug=False>, PacketProtocolQos, Serial<id=0x7ff61b6c2260, open=True>(port='/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=0, xonxoff=True, rtscts=False, dsrdtr=False)))
If that doesn’t help: you’re not doing anything odd, like running in a VM, are you?
No VM, just HASSOS on a NUC
Could a Z-wave stick in the neighborhood cause interference?
2022-11-09 18:56:16.410 WARNING (MainThread) [ramses_rf.protocol.schemas] Best practice is exactly one gateway (HGI) in the known_list: []
2022-11-09 18:56:16.415 WARNING (MainThread) [ramses_rf.protocol.schemas] It is strongly recommended to use the known_list as a whitelist (device_id filter), configure: enforce_known_list = True
2022-11-09 18:56:16.418 INFO (MainThread) [custom_components.ramses_cc.coordinator] Success initialising with the cached schema: {'main_tcs': None, 'orphans_heat': [], 'orphans_hvac': []}
2022-11-09 18:56:16.418 INFO (MainThread) [custom_components.ramses_cc.coordinator] Restoring the client state cache (packets only)...
2022-11-09 18:56:16.547 INFO (MainThread) [homeassistant.setup] Setting up homekit_controller
2022-11-09 18:56:16.560 INFO (SyncWorker_2) [pyfritzhome.fritzhome] Updating Devices ...
2022-11-09 18:56:16.565 INFO (MainThread) [ramses_rf.protocol.transport] RAMSES_RF protocol library v0.22.1, using PacketProtocolFile
2022-11-09 18:56:16.565 DEBUG (MainThread) [ramses_rf.protocol.transport] PacketProtocolFile.pause_writing()
2022-11-09 18:56:16.576 INFO (MainThread) [homeassistant.setup] Setting up fritz
2022-11-09 18:56:16.576 INFO (MainThread) [homeassistant.setup] Setup of domain fritz took 0.0 seconds
2022-11-09 18:56:16.578 DEBUG (MainThread) [ramses_rf.protocol.transport] PacketProtocolFile.connection_made(<ramses_rf.protocol.transport.SerTransportRead object at 0x7fc8a2ac6f40>)
2022-11-09 18:56:16.578 WARNING (MainThread) [ramses_rf.protocol.transport] Not using any device filter: using a known_list (as a whitelist) is strongly recommended)
2022-11-09 18:56:16.579 DEBUG (MainThread) [ramses_rf.protocol.transport] PacketProtocolFile.pause_writing()
2022-11-09 18:56:16.744 INFO (MainThread) [homeassistant.setup] Setup of domain homekit_controller took 0.2 seconds
2022-11-09 18:56:16.744 INFO (MainThread) [custom_components.ramses_cc.coordinator] Restored the cached state.
2022-11-09 18:56:16.745 DEBUG (MainThread) [custom_components.ramses_cc.coordinator] Starting the RF monitor...
2022-11-09 18:56:16.747 INFO (MainThread) [ramses_rf.protocol.transport] RAMSES_RF protocol library v0.22.1, using PacketProtocolQos
2022-11-09 18:56:16.750 DEBUG (MainThread) [ramses_rf.protocol.protocol] MsgTransport._set_dispatcher(<bound method PacketProtocolQos.send_data of PacketProtocolQos(enforce_include=False)>)
2022-11-09 18:56:16.890 INFO (MainThread) [homeassistant.setup] Setting up hacs
2022-11-09 18:56:16.890 INFO (MainThread) [homeassistant.setup] Setup of domain hacs took 0.0 seconds
2022-11-09 18:56:16.892 DEBUG (MainThread) [ramses_rf.protocol.transport] PacketProtocolQos.connection_made(SerialTransport(<_UnixSelectorEventLoop running=True closed=False debug=False>, PacketProtocolQos, Serial<id=0x7fc8a1447eb0, open=True>(port='/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=0, xonxoff=True, rtscts=False, dsrdtr=False)))
2022-11-09 18:56:16.892 WARNING (MainThread) [ramses_rf.protocol.transport] Not using any device filter: using a known_list (as a whitelist) is strongly recommended)
2022-11-09 18:56:16.894 DEBUG (MainThread) [ramses_rf.protocol.transport] PacketProtocolQos.resume_writing()
I have no error when connecting to the serial port.
How can I verify the port? I checked in the hardware settings of HA
Could it be something with the bootloader?
I used the ‘standard’ bootloader
Yes it perfectly answers it, thanks!
Hello, I’m super sorry to ask an idiotic question but I’m having trouble following direction.
I have HA installed on a Pi4 and am using a SSM-D2 from indalo tech. I’m trying to control a Nuaire PIV instead of splashing out on their remote control.
I’ve got as far as the ramses configuration and can see things in the packet log:
2022-11-09 21:15:24.408 ERROR (MainThread) [ramses_rf.dispatcher] I --- 30:112130 --:------ 30:112130 1F09 003 0005AA < TypeError(Invalid device type to be a controller: 30:112130 (RFG))
2022-11-09 21:17:49.409 ERROR (MainThread) [ramses_rf.dispatcher] I --- 30:112130 --:------ 30:112130 1F09 003 0005AA < TypeError(Invalid device type to be a controller: 30:112130 (RFG))
2022-11-09 21:18:43.903 ERROR (MainThread) [ramses_rf.protocol.message] I 025 30:112130 --:------ 30:112130 31D9 017 2100FF0000000000000000000000000000 < AssertionError(What!! (AA))
Traceback (most recent call last):
File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/message.py", line 338, in _validate
return {**self._idx, **result}
File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/message.py", line 219, in _idx
assert self._pkt._idx == "00", "What!! (AA)"
AssertionError: What!! (AA)
2022-11-09 21:20:14.411 ERROR (MainThread) [ramses_rf.dispatcher] I --- 30:112130 --:------ 30:112130 1F09 003 0005AA < TypeError(Invalid device type to be a controller: 30:112130 (RFG))
2022-11-09 21:22:39.414 ERROR (MainThread) [ramses_rf.dispatcher] I --- 30:112130 --:------ 30:112130 1F09 003 0005AA < TypeError(Invalid device type to be a controller: 30:112130 (RFG))
2022-11-09 21:25:04.417 ERROR (MainThread) [ramses_rf.dispatcher] I --- 30:112130 --:------ 30:112130 1F09 003 0005AA < TypeError(Invalid device type to be a controller: 30:112130 (RFG))
2022-11-09 21:27:25.683 WARNING (MainThread) [ramses_rf.protocol.parsers] I --- 30:112130 63:262142 --:------ 10E0 038 000001C90023006CFEFEFFFFFFFF1C0707E5425244472D30324A415330310000000000000000 < Support the development of ramses_rf by reporting this packet, with the make/model of device: RFG:112130 (device type 30 not known to have signature: 0001C90023006CFEFE)
2022-11-09 21:27:51.135 ERROR (MainThread) [ramses_rf.dispatcher] I --- 30:112130 --:------ 30:112130 1F09 003 0005AA < TypeError(Invalid device type to be a controller: 30:112130 (RFG))
2022-11-09 21:30:16.138 ERROR (MainThread) [ramses_rf.dispatcher] I --- 30:112130 --:------ 30:112130 1F09 003 0005AA < TypeError(Invalid device type to be a controller: 30:112130 (RFG))
2022-11-09 21:32:41.140 ERROR (MainThread) [ramses_rf.dispatcher] I --- 30:112130 --:------ 30:112130 1F09 003 0005AA < TypeError(Invalid device type to be a controller: 30:112130 (RFG))
2022-11-09 21:34:00.229 WARNING (MainThread) [ramses_rf.entity_base] No response for task(000C|RP|01:090099|000E): throttling to 1/24h
2022-11-09 21:34:10.138 WARNING (MainThread) [ramses_rf.entity_base] No response for task(000C|RP|01:090099|010E): throttling to 1/24h
2022-11-09 21:34:20.048 WARNING (MainThread) [ramses_rf.entity_base] No response for task(10A0|RP|01:090099|00): throttling to 1/24h
2022-11-09 21:35:06.142 ERROR (MainThread) [ramses_rf.dispatcher] I --- 30:112130 --:------ 30:112130 1F09 003 0005AA < TypeError(Invalid device type to be a controller: 30:112130 (RFG))
2022-11-09 21:37:28.647 WARNING (MainThread) [ramses_rf.entity_base] No response for task(000C|RP|01:090099|000F): throttling to 1/24h
2022-11-09 21:37:31.144 ERROR (MainThread) [ramses_rf.dispatcher] I --- 30:112130 --:------ 30:112130 1F09 003 0005AA < TypeError(Invalid device type to be a controller: 30:112130 (RFG))
I don’t know what to do next, I’m not sure what class of device my PIV is and what numbers I should use to configure it. Should a device/entity magically shown up in HA by now? Do I need to look at the packet log and work out a number I should be using in the configuration? Do I need to pair/bind something with the PIV (it uses a pairing/binding method with the off-the-shelf control).
I’d appreciate any hints as to where I’m going wrong, I’m happy to read, I just don’t know what I’m doing. thanks