I think we can say this is sorted. Interesting that my controller (red line) missed one of the updates that evofw3 (blue line) detected. (And this was confirmed by looking at the display on the controller.)
Thanks for sorting this.
1 Like
Yes it is the short one 
But the corner where the HR92 is, is pretty build in with stuff and wifi used to be doggy (before adding an extra AP on the first floor) on the attic as well in that corner.
Both the evofw3 sticks where seeing the HR92 with a RSSI of 85 when they where on the first floor.
The building signal test of the HR92 is also poor, but it works 
So Iām pretty sure it is a reception issue
Pigtails are oke, but not that great.
Here is a challenge for someoneā¦
I am looking at implementing something like the following for edge-cases:
evohome_cc:
serial_port: /dev/ttyACM0
ramses_rf:
use_regexp:
"( 03:.* 1060 003) FF": "\1 00"
Which would be used to convert invalid packets like this:
I 000 03:196196 --:------ 03:196196 1060 003 FFFF01
ā¦ into this (below), so that they can be parsed by ramses_rf:
I 000 03:196196 --:------ 03:196196 1060 003 00FF01
The first string is the search: "( 03:.* 1060 003) FF", the second is the replace: "\1 00".
So, can anyone come up with a regexp search/replace pair for the following?
Convert:
RP --- 01:050858 18:141846 --:------ 000C 006 04080010D8DA
RP --- 01:050858 18:141846 --:------ 000C 011 04080010D8DA080010D92A
RP --- 01:050858 18:141846 --:------ 000C 016 04080010D8DA080010D92A080010D92B
RP --- 01:050858 18:141846 --:------ 000C 021 04080010D8DA080010D92A080010D92B080010D92C
ā¦ into:
RP --- 01:050858 18:141846 --:------ 000C 006 04080010D8DA
RP --- 01:050858 18:141846 --:------ 000C 012 04080010D8DA04080010D92A
RP --- 01:050858 18:141846 --:------ 000C 018 04080010D8DA04080010D92A04080010D92B
RP --- 01:050858 18:141846 --:------ 000C 024 04080010D8DA04080010D92A04080010D92B04080010D92C
For context, each 6-byte chunk is: zz-tt-dddddddd (zone-idx, device-type, device-id).
I wont implement this feature unless it can be made to do the above.
@iMiMx To fix your zone 00, try this:
evohome_cc
schema:
controller: 01:123456
zones:
'00':
devices:
- '04:111111'
- '04:222222'
Populates devices, but not actuators:
'00':
_name: Living Room
heating_type: radiator_valve
sensor: '22:245508'
devices:
- '04:055594'
- '04:055514'
- '22:245508'
_sensor: '22:245508'
_actuators: null
But does seem to show āHeatingā i.e it knows that it is heating, for the first time since we/I came across this issue. Previously it was just āHeatā when all the others showed āHeatingā.
Yes, thatās right.
The controller will not tell ramses_rf if/when a zone has a heat demand (is āheatingā), despite showing this data in the UI.
So ramses_rf aggregates the heat demand of the constituent actuators to approximate this value.
Before the next release drops, add the equivalent of this JSON to your configuration.yaml as YAML:
"01:024170": {
"zones": {
"00": {
"heating_type": "underfloor_heating",
"sensor": "01:024170",
"devices": ["02:016894"]
},
"02": {
"heating_type": "underfloor_heating",
"devices": ["02:017729"]
},
"03": {
"heating_type": "underfloor_heating",
"devices": ["02:017825"]
}
}
},
See: this part of the evohome_cc Wiki
i have got also an empty 00 zone:
system:
heating_control: '10:078099'
orphans: []
stored_hotwater: {}
underfloor_heating: {}
zones:
'00':
_name: Woonkamer
heating_type: underfloor_heating
sensor: null
devices: []
_sensor: null
_actuators: []
'01':
_name: Badkamer
heating_type: radiator_valve
sensor: '04:225661'
devices:
- '04:225661'
_sensor: '04:225661'
_actuators:
- '04:225661'
'02':
_name: Slaapkamer Evi
heating_type: radiator_valve
sensor: '04:225663'
devices:
- '04:225663'
_sensor: '04:225663'
_actuators:
- '04:225663'
'03':
_name: Kastenkamer
heating_type: radiator_valve
sensor: '04:023992'
devices:
- '04:023992'
_sensor: '04:023992'
_actuators: []
'04':
_name: Toilet
heating_type: radiator_valve
sensor: '04:225657'
devices:
- '04:225657'
_sensor: '04:225657'
_actuators:
- '04:225657'
'05':
_name: Slaapkamer Nova
heating_type: radiator_valve
sensor: '04:024000'
devices:
- '04:024000'
_sensor: '04:024000'
_actuators:
- '04:024000'
'07':
_name: Slaapkamer
heating_type: radiator_valve
sensor: '04:059569'
devices:
- '04:059569'
_sensor: '04:059569'
_actuators:
- '04:059569'
friendly_name: 01:087939 (schema)
i have got also the follow error in my log:
RQ --- 18:000070 10:078099 --:------ 3220 005 0080130000 < There appears to be more than one HGI80-compatible device (active gateway: 18:073736), this is unsupported
RQ --- 18:000370 01:087939 --:------ 0418 003 000004 < There appears to be more than one HGI80-compatible device (active gateway: 18:073736), this is unsupported
My config:
evohome_cc:
serial_port: /dev/ttyUSB-EVOHOME
scan_interval: 60
packet_log:
file_name: /config/evohome_cc.log
rotate_bytes: null
rotate_backups: 3
restore_state: false
ramses_rf:
enforce_known_list: true
max_zones: 9
schema:
controller: 01:087939
system:
heating_control: 10:078099
known_list:
- 01:087939 # Controller
- 04:225661 # Badkamer
- 04:225663 # Slaapkamer Evi
- 02:017205 # Woonkamer
- 04:023992 # Kastenkamer
- 04:059569 # Slaapkamer
- 04:225657 # Toilet
- 04:024000 # Slaapkamer Nova
- 10:078099 # Heating control
Iāve been running successfully for about a week having received my SSM-D - great work and thanks for the effort you are putting into this!
The only small issue Iāve noticed, which is not causing any real problems, are the following errors (one after the other) which I believe are coming from a zone configured as an Electric Zone.
validate_command(): object of type 'int' has no len()
Traceback (most recent call last):
File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/command.py", line 143, in _wrapper
return fcn(*args, **kwargs)
File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/command.py", line 505, in get_relay_demand
return cls(RQ, _0008, zone_idx, dev_id, **kwargs)
File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/command.py", line 267, in __init__
self._validate(
File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/command.py", line 336, in _validate
self._len = int(len(self.payload) / 2)
TypeError: object of type 'int' has no len()
followed by
Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/local/lib/python3.9/site-packages/ramses_rf/helpers.py", line 17, in execute_func
return func(*args, **kwargs)
File "/usr/local/lib/python3.9/site-packages/ramses_rf/entities.py", line 98, in wrapper
return func(self, discover_flag=discover_flag)
File "/usr/local/lib/python3.9/site-packages/ramses_rf/zones.py", line 845, in _discover
super()._discover(discover_flag=discover_flag)
File "/usr/local/lib/python3.9/site-packages/ramses_rf/zones.py", line 251, in _discover
self._send_cmd(Command.get_relay_demand(self._ctl.id, zone_idx=self.idx))
File "/usr/local/lib/python3.9/site-packages/ramses_rf/entities.py", line 195, in _send_cmd
cmd._source_entity = self
AttributeError: 'NoneType' object has no attribute '_source_entity'
Iām not sure whether get_relay_demand here is referring to the boiler relay BDR91, or the BDR91 that is the actuator for the electric zone. I suspect the former, as the only ill effect that these errors cause is that my ā01:225826_08 (heat_demand)ā entity is always Unavailable (my eletric zone is zone index 08). Not a problem as I wouldnāt expect electric zones to create a boiler demand anyway, but perhaps the error could be addressed. Note that my ā13:076092 (relay_demand)ā entity, which is the electric zoneās BDR91 actuator, does reliably show a correct demand percentage.
The following lines immediately precede the above assertions in the log and look to relate to zone 08, should they be useful:
2021-11-27 12:25:10 INFO (MainThread) [ramses_rf.protocol.transport] RF Tx: b'RQ --- 18:000730 01:225826 --:------ 0004 002 0800'
2021-11-27 12:25:10 INFO (MainThread) [ramses_rf.protocol.transport] RF Rx: b'000 RQ --- 18:204306 01:225826 --:------ 0004 002 0800'
2021-11-27 12:25:10 INFO (MainThread) [ramses_rf.protocol.transport] PktProtocolQos.data_rcvd(rcvd=0004|RQ|01:225826|08): boff=0, want=0004|RQ|01:225826|08, tout=2021-11-27T12:25:10.300: QoS: wa
nting Tx (RQ) pkt: was MATCHED (now waiting for the corresponding Rx (RP) pkt)
2021-11-27 12:25:10 INFO (MainThread) [ramses_rf.protocol.protocol] rcvd: RQ --- 18:204306 01:225826 --:------ 0004 002 0800
2021-11-27 12:25:10 INFO (MainThread) [ramses_rf.protocol.transport] RF Rx: b'061 RP --- 01:225826 18:204306 --:------ 0004 022 080047617264656E20726F6F6D000000000000000000'
2021-11-27 12:25:10 INFO (MainThread) [ramses_rf.protocol.transport] PktProtocolQos.data_rcvd(rcvd=0004|RP|01:225826|08): boff=0, want=0004|RP|01:225826|08, tout=2021-11-27T12:25:10.300: QoS: wa
nting Rx (RP) pkt: was MATCHED (now done)
2021-11-27 12:25:10 INFO (MainThread) [ramses_rf.protocol.protocol] rcvd: RP --- 01:225826 18:204306 --:------ 0004 022 080047617264656E20726F6F6D000000000000000000
2021-11-27 12:25:10 INFO (MainThread) [ramses_rf.message] || CTL:225826 | HGI:204306 | RP | zone_name | 08 || {'zone_idx': '08', 'name': 'Garden room'}
2021-11-27 12:25:10 INFO (MainThread) [ramses_rf.protocol.protocol] sent: RQ --- 18:000730 01:225826 --:------ 0004 002 0800
2021-11-27 12:25:10 INFO (MainThread) [ramses_rf.protocol.transport] RF Tx: b'RQ --- 18:000730 01:225826 --:------ 000A 002 0800'
2021-11-27 12:25:10 INFO (MainThread) [ramses_rf.protocol.transport] RF Rx: b'000 RQ --- 18:204306 01:225826 --:------ 000A 002 0800'
2021-11-27 12:25:10 INFO (MainThread) [ramses_rf.protocol.transport] PktProtocolQos.data_rcvd(rcvd=000A|RQ|01:225826|08): boff=0, want=000A|RQ|01:225826|08, tout=2021-11-27T12:25:10.357: QoS: wa
nting Tx (RQ) pkt: was MATCHED (now waiting for the corresponding Rx (RP) pkt)
2021-11-27 12:25:10 INFO (MainThread) [ramses_rf.protocol.protocol] rcvd: RQ --- 18:204306 01:225826 --:------ 000A 002 0800
2021-11-27 12:25:11 INFO (MainThread) [ramses_rf.protocol.transport] RF Rx: b'061 RP --- 01:225826 18:204306 --:------ 000A 006 081001F40DAC'
2021-11-27 12:25:11 INFO (MainThread) [ramses_rf.protocol.transport] PktProtocolQos.data_rcvd(rcvd=000A|RP|01:225826|08): boff=0, want=000A|RP|01:225826|08, tout=2021-11-27T12:25:10.357: QoS: wa
nting Rx (RP) pkt: was MATCHED (now done)
2021-11-27 12:25:11 INFO (MainThread) [ramses_rf.protocol.protocol] rcvd: RP --- 01:225826 18:204306 --:------ 000A 006 081001F40DAC
2021-11-27 12:25:11 INFO (MainThread) [ramses_rf.message] || CTL:225826 | HGI:204306 | RP | zone_params | 08 || {'zone_idx': '08', 'min_temp': 5.0, 'max_temp': 35.0, 'local_override': Tru
e, 'openwindow_function': True, 'multiroom_mode': False, '_unknown_bitmap': '0b00010000'}
2021-11-27 12:25:11 INFO (MainThread) [ramses_rf.protocol.protocol] sent: RQ --- 18:000730 01:225826 --:------ 000A 002 0800
Let me know if you need any more logs.
@bluediamond84 is running with a very old evohome controller - and an old firmware at that - discovery isnāt working on his system.
It shouldnāt be necessary for you (or anyone who has an Evo Colour) to do the same as he.
The next release will include some UFH-specific fixes - please report back to me if it doesnāt work for you after that.
UFH is a poor cousin, currently - I have no test bed for it, so UFH/UFC development is difficult for me.
The above are corrupted packets (the device_id should be 18:000730) - unfortunately they remain valid. The ānewā device looks like a (second) HGI-compatible device, and so ramses_rf is rightfully rejecting the packet.
The system is full of these corruptions, and a lot of effort is spent detecting them.
I see you have a known_list (a white list). The reason why the packet isnāt filtered out is because 10:078099 is in that list (or, if so configured, neither is not in a block_list).
Maybe the code isnāt quite right, as this warning is coming from a lower layerā¦ For now, add your gateway device ID to your known_list.
ā¦ and please send me a 24 packet log running the latest 0.16.x and I will address the above.
At first glance, I canāt see the cause of the error - given that the logging is so unhelpful, I will fix that & you can update me with the improved error message from the next release (if required).
I have identified & fixed this bug.
Thatās great, thank you. I will be happy to test the next release and report back.
Start testing - release 0.16.22 is available.
I am interested in UFH zones - is the schema complete? Do they have a valid heat_demand?
@cinnamon ?
Seeing a few of these (with 0.16.20). Doesnāt seem to the causing any issues (famous last words!)
WARNING (MainThread) [ramses_rf.entities] RQ --- 18:000730 01:185426 --:------ 1260 001 00 < Sending inadvisable for 07:046786 (DHW) (has a battery)
I have these added to my configuration.yaml. But it wonāt be added to the schema sensor.
ramses_rf:
enable_eavesdrop: false
schema:
controller: 01:024170
zones:
"00":
heating_type: underfloor_heating
sensor: "01:024170"
devices:
- "02:016894"
"02":
heating_type: underfloor_heating
devices:
- "02:017729"
"03":
heating_type: underfloor_heating
devices:
- "02:017825"
@zxdavb I see the following with 0.16.22:
2021-11-27 19:37:34 ERROR (MainThread) [ramses_rf.protocol.command] get_relay_demand((<class 'ramses_rf.protocol.command.Command'>, '13:076092'), {
}): Unknown format code 'X' for object of type 'str'
Traceback (most recent call last):
File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/command.py", line 147, in _wrapper
return fcn(*args, **kwargs)
File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/command.py", line 523, in get_relay_demand
return cls(RQ, _0008, f"{zone_idx:02X}", dev_id, **kwargs)
ValueError: Unknown format code 'X' for object of type 'str'
2021-11-27 19:37:34 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/local/lib/python3.9/site-packages/ramses_rf/helpers.py", line 17, in execute_func
return fnc(*args, **kwargs)
File "/usr/local/lib/python3.9/site-packages/ramses_rf/entities.py", line 98, in wrapper
return fnc(self, discover_flag=discover_flag)
File "/usr/local/lib/python3.9/site-packages/ramses_rf/devices.py", line 1571, in _discover
super()._discover(discover_flag=discover_flag)
File "/usr/local/lib/python3.9/site-packages/ramses_rf/devices.py", line 434, in _discover
super()._discover(discover_flag=discover_flag)
File "/usr/local/lib/python3.9/site-packages/ramses_rf/entities.py", line 98, in wrapper
return fnc(self, discover_flag=discover_flag)
File "/usr/local/lib/python3.9/site-packages/ramses_rf/devices.py", line 739, in _discover
self._send_cmd(
File "/usr/local/lib/python3.9/site-packages/ramses_rf/entities.py", line 195, in _send_cmd
cmd._source_entity = self
AttributeError: 'NoneType' object has no attribute '_source_entity'
I get similar errors for both my boiler relay (13:032648) and my electric zone actuator (13:076092).
There is a regression - the wrong library is being loaded - I will issue a quick fix.
Which hardware is the gateway device ID?
Version 0.16.23 released.
The one starting with 18:, yours is 18:073736?
i think so 
i add just add it to my known_list. The zones of the UFH doesnāt show any info. (i dont know if i can expect that)