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

PietPiraat80 · February 3, 2024, 4:31pm

Thanks for answering, yes I’ve read the wiki and I had it setup as you mentioned but unfortunately that didn’t work. Any other sugestions?

zxdavb · February 3, 2024, 4:35pm

There are confirmation/troubleshooting steps in there - how is that going…

Can you see the packets in the packet log that you shoudl?

zxdavb · February 3, 2024, 6:18pm

Can anyone with Itho Spider kit please send me packet logs?

PietPiraat80 · February 3, 2024, 7:02pm

Yes packets are being received. All devices are present in the known list and they are available in home assistant. The only thing missing is the faked sensor.

in the home assitant log i’m getting these messages, I have no idea what they mean

2024-02-03 19:45:00.495 INFO (MainThread) [ramses_rf.dispatcher] || 18:262143 | 63:262142 | I | puzzle_packet | || {'datetime': '2024-02-03T19:45:00.441', 'impersonating': '30C9| I|03:123456', 'parser': 'v0.31.6'}

and

2024-02-03 19:45:42.680 INFO (MainThread) [ramses_rf.dispatcher] || 01:079786 | 18:262143 | RP | system_fault | 00 || {'log_idx': '00', 'log_entry': ('24-02-03T18:15:33', 'restore', 'comms_fault', 'sensor', '08', '03:123456', 'B0', '0000', 'FFFF7000')}

zxdavb · February 3, 2024, 7:25pm

Please PM a 24 packet log that includes a restart of HA.

PyroPath · February 3, 2024, 7:35pm

This part isn’t in my automation, it was in the “old” version but isn’t in the “new” one.

Also, I seem to remember I had to first “create” the sensor before it was available in HA. Don’t see the “create_device: true” anywhere in the wiki anymore, so don’t know if this is now automated?

cmseasy · February 3, 2024, 11:54pm

When I call the put.co2.level service for a fake CO2 entity the service gives a unknown error on http://homeassistant.local:8123/developer-tools/service

service: ramses_cc.put_co2_level
data:
 entity_id: sensor.37_097277_co2_level
 co2_level: 900

In the logs:

2024-02-04 00:37:53.606 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [140628596826176] Error handling message: Unknown error (unknown_error) Martin from 192.168.1.22 (Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:122.0) Gecko/20100101 Firefox/122.0)
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 782, in handle_execute_script
script_result = await script_obj.async_run(
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 1587, in async_run
return await asyncio.shield(run.async_run())
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 426, in async_run
await self._async_step(log_exceptions=False)
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 479, in _async_step
self._handle_exception(
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 502, in _handle_exception
raise exception
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 476, in _async_step
await getattr(self, handler)()
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 713, in _async_call_service_step
response_data = await self._async_run_long_action(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 675, in _async_run_long_action
return long_task.result()
^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/core.py", line 2149, in async_call
response_data = await coro
^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/core.py", line 2186, in _execute_service
return await target(service_call)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 831, in handle_service
return await service.entity_service_call(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 882, in entity_service_call
single_response = await _handle_entity_call(
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 942, in _handle_entity_call
task = hass.async_run_job(
^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/core.py", line 739, in async_run_job
return self.async_run_hass_job(HassJob(target), *args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/core.py", line 691, in async_run_hass_job
hassjob.target(*args)
File "/config/custom_components/ramses_cc/sensor.py", line 214, in async_put_co2_level
self._device.co2_level = co2_level # would accept None
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/ramses_rf/device/hvac.py", line 102, in co2_level
self._send_cmd(Command.put_co2_level(self.id, value))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/ramses_tx/command.py", line 775, in put_co2_level
payload = f"00{hex_from_double(co2_level)}"
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/ramses_tx/helpers.py", line 198, in hex_from_double
raise ValueError(f"Invalid value: {value}, is not a double (a float)")
ValueError: Invalid value: 900, is not a double (a float)

Another question. Is there a way to unbind a device with a ramses rf command from the Orcon valve?
The problem is that Orcon cannot unbind a device from the valve, only from the CO2 device. Unbinding is not working with the valve buttons and Orcon has no intention of solving that.

zxdavb · February 4, 2024, 10:11am

This is a stupid programming error, easily fixed.

In the interim, try 900.0.

As far as I know, the RAMSES_II protocol has no unbind - this is up to the devices.

For example, in ecohome, the only way to remove a TRV from a zone is to delete that zone and start again.

Having said that, I am not sure I have fully understood your question.

zxdavb · February 4, 2024, 10:18am

In the wiki (for example), it says:

This ‘creates’ the device.

PyroPath · February 4, 2024, 11:40am

Anyone else experiencing issues with both evohome and ramses? This morning, both stopped working for me and a reboot shows in the logs that both failed to load/setup

Verry odd, had to reseat the USB stick and reboot, now back to normal

PyroPath · February 4, 2024, 12:02pm

Well that would explain why he had problems with it. It probably wasn’t being created then.

zxdavb · February 4, 2024, 2:31pm

Version 0.31.7 has been released as a stable. This is not a beta / pre-release version.

Please report any bugs here

This bug has been fixed:

invoking ramses_cc.put_co2_level causes ValueError

smartypants · February 4, 2024, 9:58pm

Latest version, and I get this in the logs now:

/dev/serial/by-id/usb-FTDI_USB-RS232_Cable_FT5S4V48-if00-port0: the gateway type is not determinable, will assume evofw3, TIP: specify the serial port by-id (i.e. /dev/serial/by-id/usb-...)

As you can see, I’m already using /dev/serial/by-id…
It says treating as an evofw3 device, however, I actually have a serial HGI80 connected via usb adapter. It works fine but latest updates treat it as an evofw3.

Can we have a manual switch to tell it what it is?

keesma · February 4, 2024, 10:02pm

Thank you for your feedback.

I think the 01:111111 is a remainder of a copied example and have removed it.
I will disable the cache and retry.

Edit 1:
With the cache disabled and the 01:111111 sensor removed the error message has disappeared.

zxdavb · February 5, 2024, 8:49am

As 0.31.x is now a stable release, please report all issues here, at the github repo.

So871 · February 5, 2024, 9:34am

@keesma

Completely offtopic , but were you the one that made the intergas code a few years ago ?

If yes , thanks for the hard work on it!
It helped me alot on a custom component in Esphome.

zxdavb · February 5, 2024, 4:17pm

Config Flow!

We have two active release tracks for ramses_cc:

0.31.7, which is stable (bug fixes only), and
0.41.7, which is a pre-release version that include config flow!

Kudos out to @trvrnrth who has done all the heavy lifting to add config flow to ramses_cc.

Please consider 0.41.7 to be experimental at this stage - it works fine for me, but YMMV.

Adventurous people will:

backup HA before upgrading to 0.41.7
check that all their expectations are met (e.g. test their automations)
and report back here

If you need to roll back to 0.31.7 (stable), you could try doing so without a restore:

you may need to delete ramses_cc.json
you will probably have issues, regardless

stevieb12345 · February 5, 2024, 5:31pm

I’ve upgraded to 0.41.7 no problems or warnings.

peternash · February 5, 2024, 6:00pm

Upgraded to 0.41.7 and all seems OK. Config migrated across and all devices and entities showing as expected. I’ve commented out the YAML config to confirm it’s no longer being used. Custom dashboards all look the same as before. Noticed that the default sensor entity names now have helpful HGI / BDR / OTB / TRV / THM / DHW prefixes.

Lloyd · February 5, 2024, 6:15pm

Looking at the release notes (for 0.31.2 - trying to assess the upgrade from 0.22.1 to 0.31.7), there is the line

The schema sensor, sensor:01_123456_status is now called sensor:01_123456_status

Should that be

binary_sensor:01_123456_schema is now called sensor:01_123456_status ?