Honeywell CH/DHW via RF - evohome, sundial, hometronics, chronotherm

Share your Projects!
4142

Overnight all heating related have gone unavailable so reverting back to 0.30.9
Look forward to trying the 0.30.4

image
image502Ɨ779 28.3 KB

just wondering if someting in my config causing this?
my config

ramses_cc:
serial_port: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00
restore_cache: true
packet_log:
file_name: packet.log
rotate_bytes: null
rotate_backups: 7
scan_interval: 60
advanced_features:
message_events: None
ramses_rf:
enable_eavesdrop: false
enforce_known_list: true
01:095421: {}

known_list:
01:095421: #class: controller
13:246010: #class: electrical_relay
07:043766: #class: dhw_sensor
13:133295: #class: electrical_relay
04:112342: #class: radiator_valve
04:112622: #class: radiator_valve
04:256582: #class: radiator_valve
04:112616: #class: radiator_valve
04:256354: #class: radiator_valve
04:112626: #class: radiator_valve
04:123563: #class: radiator_valve
04:112340: #class: radiator_valve
04:112346: #class: radiator_valve
04:112624: #class: radiator_valve
04:112338: #class: radiator_valve
04:256588: #class: radiator_valve
22:172595: #class: thermostat
22:172591: #class: thermostat
22:143362: #class: thermostat
02:019383: #class: ufh_controller
18:135685: {class: HGI} #class: gateway_interface

4143

Please format your yaml:

ramses_cc:
  serial_port: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00
  restore_cache: true
  packet_log:
    file_name: packet.log
    rotate_bytes: null
    rotate_backups: 7
  scan_interval: 60
  advanced_features:
    message_events: None
4144

Apologies, my bad, I have pasted it as text content and have lost the formating, but whatā€™s on the config file is same as you have indicated
image

Strangly when I reverted back to 0.30.9 everyting stayed as offline and when I looked at the packet log, nothing was captured for last 12 hours, so Iā€™ve shutdown the pi4, reconnected all USBs and booted again and eveything started working again.
I will try upgrading again to see the same problem repeats.

4145

Iā€™ve been using the 30.x releases and Iā€™ve noticed that when I change the setpoint using the stock card, it doesnā€™t always work reliably. Sometimes it works and other times it doesnā€™t. Previously I could change the temp and close the window within a second and it worked flawlessly. Has anyone else noticed this?

image

4146

I think I have fixed this is 0.31.4.

4147

Oh great! :grinning: I thought it was just me!

4148

Version 0.31.4 has just been released.

It includes a number of bug fixes. It is the only recommended release from the 0.31.x track - the others are just too buggy.

Please try it - and let me know if you find any bugs.

Fixes include:

  • CO2 sensors were missing from the ramses_cc.put_co2_level service call
  • The material design icons used for relay state (open/closed) were swapped
  • The user wasnā€™t warned that hold_secs isnā€™t supported for the remote.send_command service call
  • The binary_sensor.18_xxxxxx_gateway_status sensor had the opposite value (e.g. Problem when is OK)
  • The ramses_cc.send_packet service call has a shorted max payload length
  • Backoff (of polling interval) has been disabled for now
  • Deprecation (of non-responsive devices) has been disabled for now
  • Several other binary sensor icons have been improved
  • Fix bug with updating entity state via async_write_ha_state_delayed
  • Most FAN sensors are exposed by default, as before
  • Refactoring of OTB._handle_msg() and associated code
  • Lots of unavailable OTB sensors
4149

I recommend people have use_native_ot: prefer (or omit use_native_ot altogether)

4150

Hi all,
i started with Evofw3 on a Nanocul last night, but eighter iā€™m missing something orā€¦
i need some help understanding what iā€™m doing wrong

iā€™ve got the log file in place and receive data .

My setup is :
A bdr as heater relay
evohome controller in livingroom the controller is the sensor , and has a bdr91 for a seperate 2way valve.
8 x hr92
2 zones with 2 hr92
and 4 with a single hr92.

hereā€™s a snippet of the packet log

2024-01-27T15:15:56.335539 # ramses_rf 0.21.40
2024-01-27T15:15:56.439137 ... RQ --- 01:131289 13:239590 --:------ 3EF0 001 00 # 3EF0|RQ|01:131289
2024-01-27T15:15:57.312845 ...  I --- 04:158578 --:------ 04:158578 30C9 003 0006BE # 30C9| I|04:158578
2024-01-27T15:15:57.318918 ... RP --- 01:131289 04:205452 --:------ 0100 005 006E6CFFFF # 0100|RP|01:131289
2024-01-27T15:15:57.333323 ...  I --- 04:205410 --:------ 04:205410 30C9 003 00062C # 30C9| I|04:205410
2024-01-27T15:15:57.344401 ...  I --- 04:158204 --:------ 04:158204 30C9 003 00067A # 30C9| I|04:158204
2024-01-27T15:15:57.429818 ...  I --- 04:250553 --:------ 01:131289 12B0 003 010000 # 12B0| I|04:250553|01 (01)
2024-01-27T15:15:57.434248 ...  I --- 04:205410 --:------ 01:131289 2309 003 020640 # 2309| I|04:205410|02 (02)
2024-01-27T15:15:57.453497 ...  I --- 01:131289 --:------ 01:131289 000A 048 001001F40DAC011001F40898021001F40DAC031001F40DAC041001F40DAC051001F40DAC061001F40DAC071001F40DAC # 000A| I|01:131289 (True)
2024-01-27T15:15:57.456031 ...  I --- 04:205512 --:------ 01:131289 3150 002 0400 # 3150| I|04:205512|04 (04)
2024-01-27T15:15:57.658098 ...  I --- 04:250553 --:------ 01:131289 2309 003 010640 # 2309| I|04:250553|01 (01)
2024-01-27T15:15:57.769006 ...  I --- 01:131289 --:------ 01:131289 0008 002 FC00 # 0008| I|01:131289|FC (FC)
2024-01-27T15:15:57.781068 ...  I --- 04:156304 --:------ 01:131289 3150 002 0600 # 3150| I|04:156304|06 (06)
2024-01-27T15:15:57.793028 ...  I --- 04:158204 --:------ 01:131289 12B0 003 040000 # 12B0| I|04:158204|04 (04)
2024-01-27T15:15:57.855062 ...  I --- 01:131289 --:------ 01:131289 0008 002 0000 # 0008| I|01:131289|00 (00)
2024-01-27T15:15:57.920083 ...  I --- 04:234364 --:------ 04:234364 30C9 003 000608 # 30C9| I|04:234364
2024-01-27T15:15:58.563560 ...  I --- 04:205512 --:------ 01:131289 12B0 003 040000 # 12B0| I|04:205512|04 (04)
2024-01-27T15:15:58.628550 ...  I --- 04:158578 --:------ 01:131289 3150 002 0500 # 3150| I|04:158578|05 (05)
2024-01-27T15:15:58.653574 ...  I --- 04:205512 --:------ 01:131289 2309 003 0404B0 # 2309| I|04:205512|04 (04)
2024-01-27T15:15:58.667359 ...  I --- 13:239590 --:------ 13:239590 3B00 002 00C8 # 3B00| I|13:239590
2024-01-27T15:15:58.772356 ...  I --- 13:239590 --:------ 13:239590 3EF0 003 0000FF # 3EF0| I|13:239590
2024-01-27T15:15:58.786153 ...  I --- 01:131289 --:------ 01:131289 3B00 002 FCC8 # 3B00| I|01:131289|FC (FC)
2024-01-27T15:15:58.792393 ...  I --- 13:194278 --:------ 13:194278 3EF0 003 0000FF # 3EF0| I|13:194278
2024-01-27T15:15:58.821951 ...  I --- 04:234364 --:------ 01:131289 3150 002 0300 # 3150| I|04:234364|03 (03)
2024-01-27T15:15:58.888940 ...  I --- 04:234364 --:------ 01:131289 12B0 003 030000 # 12B0| I|04:234364|03 (03)
2024-01-27T15:15:58.895166 ...  I --- 04:205512 --:------ 04:205512 30C9 003 00064E # 30C9| I|04:205512
2024-01-27T15:15:58.903231 ...  I --- 04:205410 --:------ 01:131289 3150 002 022E # 3150| I|04:205410|02 (02)
2024-01-27T15:15:58.907523 ...  I --- 04:205410 --:------ 01:131289 12B0 003 020000 # 12B0| I|04:205410|02 (02)
2024-01-27T15:15:58.919929 ...  I --- 04:250553 --:------ 04:250553 30C9 003 00068A # 30C9| I|04:250553
2024-01-27T15:15:58.922874 ...  I --- 04:250553 --:------ 01:131289 3150 002 0114 # 3150| I|04:250553|01 (01)
2024-01-27T15:15:58.927251 ...  I --- 01:131289 --:------ 01:131289 2309 024 00073A0106400206400303E80404B00505DC0604B00701F4 # 2309| I|01:131289 (True)
2024-01-27T15:15:58.936876 ...  I --- 01:131289 --:------ 01:131289 30C9 024 0007F501068A02062C03060804064E0506BE06062A077FFF # 30C9| I|01:131289 (True)

when i go into HA Entities i see several , and several climates, but none are responsive.
I see a temperature , and i see the setpoint, but cant control them,

hereā€™s a snippet of grep schema

2024-01-27 15:15:56.332 WARNING (MainThread) [custom_components.ramses_cc.schemas] Using a merged schema (cached schema is not a superset of config schema), if required, use 'restore_cache: restore_schema: false'
2024-01-27 15:15:56.345 INFO (MainThread) [custom_components.ramses_cc.coordinator] Success initialising with a merged (config/cached) schema: {'main_tcs': '01:113289', '01:113289': {'system': {'appliance_control': '13:239590'}, 'orphans': [], 'stored_hotwater': {}, 'underfloor_heating': {}, 'zones': {}}, '01:131289': {'system': {'appliance_control': '13:194278'}, 'orphans': [], 'stored_hotwater': {}, 'underfloor_heating': {}, 'zones': {'00': {'_name': None, 'class': None, 'sensor': None, 'actuators': []}, '01': {'_name': None, 'class': None, 'sensor': '04:250553', 'actuators': ['04:250553']}, '02': {'_name': None, 'class': None, 'sensor': '04:205410', 'actuators': ['04:205410']}, '03': {'_name': None, 'class': None, 'sensor': '04:234364', 'actuators': ['04:234364']}, '04': {'_name': None, 'class': None, 'sensor': None, 'actuators': ['04:158204', '04:205512']}, '05': {'_name': None, 'class': None, 'sensor': None, 'actuators': ['04:158578']}, '06': {'_name': None, 'class': None, 'sensor': None, 'actuators': ['04:156304']}, '07': {'_name': None, 'class': None, 'sensor': '01:131289', 'actuators': []}}}, '01:011289': {'system': {'appliance_control': None}, 'orphans': [], 'stored_hotwater': {}, 'underfloor_heating': {}, 'zones': {}}, '01:001128': {'system': {'appliance_control': None}, 'orphans': [], 'stored_hotwater': {}, 'underfloor_heating': {}, 'zones': {}}, '01:001182': {'system': {'appliance_control': None}, 'orphans': [], 'stored_hotwater': {}, 'underfloor_heating': {}, 'zones': {}}, 'orphans_heat': ['13:194278'], 'orphans_hvac': []}
2024-01-27 15:16:15.007 INFO (MainThread) [custom_components.ramses_cc.binary_sensor] Found a Binary Sensor for 01:113289: schema

Screenshot_20240127_160857_Home Assistant
Screenshot_20240127_160857_Home Assistant1080Ɨ2400 90.3 KB

hereā€™s my config

  serial_port: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0
  restore_cache: true
  packet_log: packet.log
  
  ramses_rf:
    enable_eavesdrop: true
    enforce_known_list: true 
    

  01:131289:
    system:
      appliance_control: 13:194278  # an OTB
    zones:
      "00": {sensor: 01:131289}  # controller is the sensor
 
  known_list:
    01:131289: #controller
    04:250553: #02
    04:234364: #03
    04:158204: #04-1
    04:205512: #04-2
    04:158578: #05
    04:156304: #06
    18:262143: {class: HGI}  #gateway_interface   
    13:194278: # relay floor
    13:239590: # relay
4151

Youā€™ve flashed the evofw3 FW incorrectly, it seems - you can Tx, but not Rx - this is common.

Have you looked at the firmware section of the wiki?

If you notice any issues in the wiki, let us know.

4153

i thought i took the correct steps . ill take another look
is this the latest version ?

ghoti57/evofw3: Major overhaul of evofw2 Evohome listening software to use asynchronous radio mode (github.com)

4154

Only difference is i used 115200 by accident the first time .

Still same behavior, any advise ?

This is the module btw ,
A 328P ,

image
image829Ɨ718 19.9 KB

4155

Not directly Ramses_cc related, but out of curiosity, I have a UFH system in the living room which should work in combination with some radiators. Whenever it is a sunny day the room is heated with the energy of the sunshine. But in the winter, the temperature can go down rather fast when the sun goes under. Iā€™ve noticed that a temperature sensor on floor level goes down much quicker than the room sensor at 1,5m from the floor. As you might know, it takes a lot longer to heat up the floor, so right now there is a delay of about 1,5 hours before the temperature starts rising again after heating kicks in.

Is there any way to have the floorsensor report to ramses_cc so the heating kicks in a little quicker, until it registers a temperature above x and then switches to the other sensor?

4156

Upgraded to 0.31.4 and so far everyting is working well.
As I had issues with 0.3 on first upgrade attempt, Iā€™ve tried with setting restore_cache: false, enable_eavesdrop: true and enforce_known_list: false and leaving for few hours and then inverting the values and rebooting and this workd, so repeated the same with 0.4.
Gateway status is now showing as ok and speed of changes of temp on cards is back to previous speed as well.
Many thanks

4157

Thanks for the valuable feedback.

Version 0.31.5 released with some minor fixes.

There are still some known bugs:

  • some OTB sensors (dhw_setpoint, and ch_max_setpoint) are often unavailable when they shouldnā€™t be
  • fetching controller logbook entries (system faults) is broken

Please stop using eavesdropping - its only purpose is to allow you to determine your schema when you first start using ramses_cc (or when you do something that changes your schema). Even then, most people will not need to use this feature.

AFAIK, there is no reason to disable your state (packet) cache when you upgrade to/from 0.3x.x, unless you change your system schema (add/remove/move devices/zones, etc.).

Once you have your known_list, you should always enforce it, unless you add/remove devices from your system.

1 Like
4158

Testing 0.31.4 and a big improvement in Opentherm sensors - particularly boiler_output_temperature and ch_water_pressure which now seem solid. For information, still some problems with the percent and value Opentherm sensors. No other issues seen so far with 0.31.4

4159

These are experimental sensors - not sure what the values represent.

4160

No, Iā€™m not sure what percent and value represent either - both seem related to boiler output in some way. I mentioned them for completeness as they appear as OTB sensors on my system.

4161

Percentage could be modulation percentage?
And value ? What does the value look like ?

4162

Here stil breaking my head over the nanocul , when flashed with the calibrate version i get responses and can change temperatures from the climate.
So doesnt seem to be a HW issue