Hi David, you know I’m not sure if it has. It was a posting above that made me check. I’ve switched on packet logs and done a restart of HA. I will share the findings over the weekend.
Thanks
Donald
Interesting I got a different request from a broadcast. Wonder what the difference in the packet is. I have no idea how to decode the data from the fan.
I’ll try the above. See how it goes.
Sorry to report that min/max temperatures don’t seem to reliably restore from cache.
I just did a restart for 2023.12.3 and see that zones [00 - 07] came up with null min/max, but [08 - 0b] restored OK. Before the HA restart all zones had min/max. I noticed this precise behavior yesterday when testing 0.30.7 initially but figured it was something to do with the cache building.
There’s no obvious difference in type or complexity to explain why zones 08+ are different
So I thought I had done this right. nothing seemed to complete on the binding. so either something obvious is missing or I just need to wait till the new year for you.
Thought it was worth a try. either way, when ready I am happy to try more options for you when you are ready as I have a system with no real remote. so a perfect use case.
Thanks
2023-12-15T10:22:10.299831 000 I --- 32:208628 --:------ 32:208628 1FC9 018 0022F1832EF46C10E0832EF4001FC9832EF4
2023-12-15T10:22:10.411111 068 W --- 30:081993 32:208628 --:------ 1FC9 012 2131DA7940496C10E0794049
2023-12-15T10:22:11.511031 068 W --- 30:081993 32:208628 --:------ 1FC9 012 2131DA7940496C10E0794049
2023-12-15T10:22:12.610973 069 W --- 30:081993 32:208628 --:------ 1FC9 012 2131DA7940496C10E0794049
2023-12-15T10:22:13.307906 000 I --- 18:071184 63:262142 --:------ 7FFF 023 0011018C6CFF810D31464339204933303A303938313635
2023-12-15T10:22:13.311786 000 I --- 32:208628 30:098165 --:------ 1FC9 001 21
2023-12-15T10:22:18.737268 000 I --- 18:071184 63:262142 --:------ 7FFF 023 0011018C6CFF964231304530204933323A323038363238
2023-12-15T10:22:18.761090 000 I --- 32:208628 63:262142 --:------ 10E0 030 000001C85A01016CFFFFFFFFFFFF010607E0564D4E2D32334C4D48323300
2023-12-15T10:22:18.933040 000 I --- 18:071184 63:262142 --:------ 7FFF 023 0011018C6CFF970B31304530204933323A323038363238
2023-12-15T10:22:19.140140 000 I --- 32:208628 63:262142 --:------ 10E0 030 000001C85A01016CFFFFFFFFFFFF010607E0564D4E2D32334C4D48323300
2023-12-15T10:22:19.335336 000 I --- 18:071184 63:262142 --:------ 7FFF 023 0011018C6CFF97D531304530204933323A323038363238
2023-12-15T10:22:19.541069 000 I --- 32:208628 63:262142 --:------ 10E0 030 000001C85A01016CFFFFFFFFFFFF010607E0564D4E2D32334C4D48323300
Could anyone advise what the following error in my log is. Ramses seems to be working ok though not sure if it may be slowing my system down?
ELogger: ramses_rf.processor
Source: runner.py:188
First occurred: 16:48:35 (2 occurrences)
Last logged: 16:49:46
RP --- 01:081083 18:196881 --:------ 000C 012 060800106C00060800106ADE < AttributeError('NoneType' object has no attribute '_hgi80')
RQ --- 18:000070 01:081083 --:------ 30C9 001 05 < LookupError(Can't create 18:000070: it is not an allowed device_id (if required, add it to the known_list))
Also this warning:
Logger: ramses_rf.entity_base
Source: runner.py:188
First occurred: 16:55:55 (3 occurrences)
Last logged: 16:59:10
* No response for task(1100|RP|13:173107): throttling to 1/24h
* No response for task(000C|RP|01:081083|0008): throttling to 1/24h
* No response for task(0004|RP|01:081083|03): throttling to 1/24h
Heres my Config:
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: 7
ramses_rf:
enforce_known_list: true
known_list:
01:081083: #main TCS
04:023774: #Hall Actuator
04:023780: #Studies Sensor class': 'radiator_valve
04:027356: #Studies Actuator and 80 above
04:027648: #Lounge class: radiator_valve and sensor
04:027360: #Niamh SEnsor & Actuator class': 'radiator_valve
04:027646: #Ellie SEnsor & Actuator class': 'radiator_valve
04:027650: #Hall Actuator
04:027656: #TV Lounge sensor and actator class': 'radiator_valve
04:027714: #Hall Actuator
04:027716: #Master Bed SEnsor & Actuator class': 'radiator_valve
04:027718: #Craig SEnsor & Actuator class': 'radiator_valve
04:027720: #Hall Actuator
04:027722: #Hall Landing Sensor and actuator class': 'radiator_valve
07:025191: #Stored Hot Water Sensor
13:001489: #Kitchen Diner Actuator
13:001522: #Ensuite Actuator
13:055679: #Grnd Bed Actuator
13:173107: #Hot water Valve
13:224329: #games room Actuator
18:196881: #gateway_interface
34:027677: #Grnd Bed Sensor class': 'zone_valve
34:063533: #games Room sensor class': 'zone_valve'
34:150571: #EnSuite Sensor class': 'zone_valve
34:150655: #Kitchen Diner SEnsor class': 'zone_valve
Thank-you.
In your known list, you need to explicitly state the type of gateway:
18:196881: {class: HGI}
The first warning with the weird 18: device might be down to the software UART in the nano CUL - it can cause corrupted packets. If you can, get a gateway with a hardware UART like the SSM D2 or Busware ones mentioned in this thread.
The second warning is just ‘informational’ if I have understood David correctly
Many thanks.
I followed your suggestion and added:
18:196881: {class: HGI}
to my known list and removed the duplicate labelled “gateway interface”.
But still get the following:
Logger: ramses_rf.processor
Source: runner.py:188
First occurred: 18:07:20 (2 occurrences)
Last logged: 18:07:31
RP --- 01:081083 18:196881 --:------ 000C 012 060800106C00060800106ADE < AttributeError('NoneType' object has no attribute '_hgi80')
RP --- 01:081083 18:196881 --:------ 000C 012 060800106C00060800106ADE < LookupError(Can't create 04:027358: it is not an allowed device_id (if required, add it to the known_list))
There is a difference now refering to 04:027358 in the last line.
Appreciate advice.
Do I have to maybe add the attribute some how?
It’s either a corrupted packet or you’re missing that 04: device from your known list. 04’ are usually radiator valves, HR80/91/92.
1 Like
Thanks for your help. I found the valve. Added it and no more errors. Greatly appreciate your assistance.
I think you just were quick enough with the I|1FC9|21 after the first W|1FC9|21...
Mind you - I haven’t checked your payloads. Did you put in the correct (hex) device id?
Or the oem_codes… (6C|21)!
This could be normal behaviour - what are other people seeing?
I used your remote ID so the hex should be correct. I didn’t see a piece in the hex needed for the main PIV needing to be calling unless I missed something.
I assumed the oem code 6C was nuaire thought I saw that somewhere in my digging.
As to the 10E0 hex. I was not sure if I needed to alter much and if so what bits so assumed I could reuse yours. Maybe not!
Here is the output of cat packet.log* | grep -E ‘RP.* 000C … 010E’
2023-11-09T21:10:33.699524 ... RP --- 01:108199 18:069148 --:------ 000C 006 010E00362AC3 # 000C|RP|01:108199|010E (010E)
2023-12-14T18:49:49.226880 ... RP --- 01:108199 18:069148 --:------ 000C 006 010E00362AC3 # 000C|RP|01:108199|010E (010E)
2023-12-14T18:52:14.933944 ... RP --- 01:108199 18:069148 --:------ 000C 006 010E00362AC3 # 000C|RP|01:108199|010E (010E)
2023-12-14T21:14:34.874042 048 RP --- 01:108199 18:069148 --:------ 000C 006 010E00362AC3
2023-12-14T21:14:35.001924 048 RP --- 01:108199 18:069148 --:------ 000C 006 010E00362AC3
2023-12-15T21:14:35.047528 051 RP --- 01:108199 18:069148 --:------ 000C 006 010E00362AC3
2023-12-15T21:14:35.174416 051 RP --- 01:108199 18:069148 --:------ 000C 006 010E00362AC3
21:14:35.174 || 01:108199 | 18:069148 | RP | zone_devices | 010E || {'zone_type': '0E', 'domain_id': 'F9', 'device_role': 'heating_valve', 'devices': ['13:142019']}
Did I suggest cat packet.log* | grep -E 'RP.* 000C … 010E'?
Sorry - got that wrong, it should be: cat packet.log* | grep -E 'RP.* 000C … 000E'
2023-11-09T21:10:33.806872 ... RP --- 01:108199 18:069148 --:------ 000C 006 000E7FFFFFFF # 000C|RP|01:108199|000E (000E)
2023-12-14T18:49:52.372694 ... RP --- 01:108199 18:069148 --:------ 000C 006 000E7FFFFFFF # 000C|RP|01:108199|000E (000E)
2023-12-14T18:52:20.687961 ... RP --- 01:108199 18:069148 --:------ 000C 006 000E7FFFFFFF # 000C|RP|01:108199|000E (000E)
2023-12-14T21:20:15.158515 047 RP --- 01:108199 18:069148 --:------ 000C 006 000E7FFFFFFF
2023-12-15T21:20:18.213986 051 RP --- 01:108199 18:069148 --:------ 000C 006 000E7FFFFFFF
2023-12-15T21:20:18.301511 050 RP --- 01:108199 18:069148 --:------ 000C 006 000E7FFFFFFF
I can upload the logfiles if you tell me how - I’m told they are not supported file types.
This packet is decoded thus:
21:20:18.301 || 01:108199 | 18:069148 | RP | zone_devices | 000E || {'zone_type': '0E', 'domain_id': 'FA', 'device_role': 'hotwater_valve', 'devices': []}
It is teh controller saying that it does not have a bound hotwater_valve.
Thus, your working schema:
system:
appliance_control: null
stored_hotwater:
sensor: '07:030355'
hotwater_valve: null
heating_valve: '13:142019'
… is correct!
That’s odd as it would suggest I’m not getting hot water which I am.
If I go to advanced settings on the evotouch I see a possible issue in the System Summary:
Stored Hot Water: 2 Two Port or Three Port Valves
Do I need to re-bind 13:181949 on the eve touch? Have I somehow also got 13:142019 bound to the hot water and need to unbind it?
System Devices says
Boiler Controls: Wireless Relay Box
Stored Hot Water: Enabled
Weird 
18:069148 status:
- '01:108199': class: controller
- '18:069148': class: gateway_interface alias: evofw3
- '02:022960': class: ufh_controller
- '07:030355': class: dhw_sensor
- '13:142019': class: electrical_relay
- '13:181949': class: electrical_relay
The truth is, I hear that argument over & over again (just look in this thread).
In any case: it doesn’t suggest exactly what you think it does.
In short: ramses_cc is telling you the truth about how the controller is configured. It cannot tell you what wiring the plumber has implemented.
The rest is up to you. Rebinding the BDR correctly is ostensibly the way forward, but may change the behaviour of the system in ways you don’t want.
If it working OK, why not just leave it be?
I am thinking of releasing 0.30.8, and marking it as stable.
Please let me know if there are any bugs in 0.30.7 that are not already in 0.2x.x.
1 Like