All the 0.30.x will have the same problem.
I can’t recall if it is 0.21.x that will work for evofw3 or 0.22.x, so try that?
Maybe version 0.30.8 has fixed this issue.
I’m almost pulling my hairs out right now, now also tried 0.21.4 and…no dice.
Removed the complete integration from my HA OS system, removed the FAN and REM from the config from the orphans section and from the known list, removed all the entities, rebooted. Removed the SSM-D2, moved it to another port. restarted the system, added things back in, not yet trying to fake anything. All related entities to the fan 37:xxxx get re-added, for the remote, only the 29_057880_battery_low entity returns. Is there anyone here with a Itho system that can tell me how they got this working?
Oh Christ…
I
AM
SUCH
AN
IDIOT
!
I was constantly using the exact ID of the physical remote, I was trying to literally clone the remote and was expecting for a “remote.29_057880” to pop up in my system… Once I added a 29:123456 to my HVAC orphans and known list, telling the system it was faked and telling it to send 29.057880 in the commands and rebooted, a new remote entity appeared, remote.29_123456, with the commands in there, using 29:057880:
When I calm down from my stupidity, I’ll try and write it up, so someone else doesn’t have to make the same stupid mistake…
edit:
BTW, is there a simple way to link this remote to the card of the ventilation unit itself, or does that have to be a seperate button card?
1 Like
I have tried binding in 0.22 and 0.30.7
Not that I am aware of - it may be something added in the future, but would require a HVAC schema, and people have enough trouble with the Heat (CH/DHW) schemas.
If you ar einterested in teh device type table, it has moved: please see: here
All: please don’t PM me unless I ask. Instead, post your questions here, so that all can benefit.
Hi PyroPath,
I’m using RAMSES CC a while for controlling my Evohome system and it works great.
Recently I bought an ITHO Daalderop CVE-S ECO SE unit and was trying to add this in Home Assistant, using ESPHome/ESP8266/CC1101 as described here: GitHub - Scriptman/ESPHome_ITHO_Eco_Fan_CC1101: Library for NodeMCU ESP8266 in combination with Hassio Home Assistant ESPHome ITHO Eco Fan CC1101 (Including older Eco fans!)
I have some issue’s to pair this device with the CVE-S. Searching for a solution for my problem, I saw a post from zxdavb that it was possible to control ITHO Devices with RAMSES CC.
In the packet.log I see logs belonging to the commands I send via Home Assistant/ESPHome:
Join:
2023-12-21T11:11:31.037517 045 I 017 --:------ --:------ 02:153425 1FC9 012 0022F10A57510110E00A5751
High:
2023-12-21T11:28:51.180704 045 I 019 --:------ --:------ 02:153425 22F1 003 000404
Medium:
2023-12-21T11:29:52.620848 045 I 021 --:------ --:------ 02:153425 22F1 003 000304
Low:
2023-12-21T11:29:34.296072 045 I 020 --:------ --:------ 02:153425 22F1 003 000204
Standby:
2023-12-21T11:30:17.781647 045 I 022 --:------ --:------ 02:153425 22F1 003 000104
Timer 1:
2023-12-21T11:30:57.294774 045 I 023 --:------ --:------ 02:153425 22F3 003 00000A
Timer 2:
2023-12-21T11:31:17.681465 045 I 024 --:------ --:------ 02:153425 22F3 003 000014
Timer 3
2023-12-21T11:31:34.600209 045 I 025 --:------ --:------ 02:153425 22F3 003 00001E
The strange thing here is that the device ID starts with 02 instead of 29.
While searching through this posts here in the Home Assistant community I found your posts where you describe your attempts. Using the info you shared, I could add my CVE-S and a fake remote to Home Assistant, just like you did.
But how can I pair/link the fake remote with the CVE-S and how can I execute the commands defined for the fake device.
I’m using 0.30.9
This is my configuration
ramses_cc:
serial_port: /dev/ttyACM0
packet_log:
file_name: packet.log
rotate_backups: 7
restore_cache:
restore_state: false
restore_schema: false
ramses_rf:
enforce_known_list: true
01:044181: # Evohome Controller
zones:
"00": { sensor: 01:044181 }
known_list:
01:044181:
13:128343:
18:135447:
04:038015:
04:190691:
04:198485:
04:112546:
04:198487:
04:198483:
04:090189:
32:168240:
03:123456: { faked: true }
I use the service call below.
service: ramses_cc.fake_device
data:
device_id: "03:123456"
create_device: true
start_binding: false
Which gives me
binary_sensor.03_123456_battery_low reports as normal.
sensor.03_123456_temperature reports as unavailable.
If I restart home assistant they report as no longer being provided by the integration.
The advantage I have, is that I have an existing physical remote, which is already bound to the CVE, so I had my packet log at the ready, pushed the buttons on the physical remote and looked in the packet log what communication corresponded with the button presses and the “dance” between the remote and CVE. That’s where I got my device id’s (29:xxxxxx and 37:xxxxxx) from. First I added those to the orphans hvac and known list, telling the system these were the remote (not faked!) and CVE.
After this I created the new, faked, remote, using the same type of syntax for the colon (29:), but a new ID after the colon (:123456) and added that to the orphans_hvac and known list and also specified the commands in the known_list. These commands however use the device ID of the existing, physical, remote. In my case, 29:057880. So whenever I send the command, the command is transmitted, using the device ID of the existing, physical remote. Because this remote is already bound with the CVE, the CVE responds as if it gets a command from the existing, physical, remote and is none the wiser that it was actually a command being send by a different device, because the command contains the ID of the existing remote.
Unfortunately, for you, I didn’t have to create a completely new remote which required a new pairing/binding. So I can’t comment on how that’s supposed to work.
1 Like
I am there too.
Do you have a hgi80 or the diy hardware version?
Indeed it has, entities reliably come back as available, thanks!
I was also having trouble faking a temperature sensor using 0.30.9. After creating the fake device, the binding command fails with an unknown error. The logs do contain the error, but unfortunately I lost the logs of home assistant, because apparently logs role over when rebooting… but it should be easily reproduced.
I went back to using 0.22.40 and I was able to bind a fake sensor to the evohome controller. I used number 03:123456, as proposed on the wiki, by doing the following:
- Disabled caches:
restore_cache:
restore_schema: false
restore_state: false
- Put the new faked device ID in my schema as the sensor for zone 00 and added the device ID to my known list:
zones:
"00": {sensor: 03:123456}
known_list:
[truncated]
03:123456: {faked: true} # faked huiskamer temp sensor.indoor_outdoor_meter_1856<--This is my BT temperature sensor.
Somewhere during this process I rebooted the HA system. I believe it was now, but I’m not 100% sure…
- Created the device using a service call:
service: ramses_cc.fake_device
data:
device_id: "03:123456"
create_device: true
-
Go to the installer menu and zone configuration screen of the appropriate zone, select the wireless sensor option for the temperature sensor, acknowledge the warning given on the screen.
-
Started binding using the service call:
service: ramses_cc.fake_device
data:
device_id: "03:123456"
start_binding: true
-
Binding was confirmed on the screen, but the temperature reading was replaced by an hourglass symbol as it isn’t fed any data at that moment.
-
Now for the next tricky part. The WIKI isn’t completely clear on the automation as it uses climate entities which use a syntax which is on my system already taken by the official Evohome integration, so I went trial and error on this, and failed multiple times before in the end I finally managed to pull it off. I changed the wordings a bit for my situation and I added some comments marked with a “#”. these comments should NOT be included in your automation.
-
Go to the section to create a new automation, choose the bare one. In the next screen select the 3 dot menu, top right and chose the edit as YAML option:
alias: Woonkamer update fake temperature sensor #Enter your own name
description: >-
When the faked temperature sensor updates, pass the temperature to ramses_cc as if it
was from a zone sensor. Then update the downstream entities. # or make your own description
trigger:
- platform: state
entity_id: sensor.indoor_outdoor_meter_1856 #This is the entity of the sensor you are using to record the temperature (zigbee, BT, ZWave, etc)
action:
- service: ramses_cc.put_zone_temp
data:
entity_id: climate.ramses_cc_01_245354_00 #The example in the WIKI mentions a climate.kitchen entity. I was thrown off by this as I still have the "official" Evohome integration running. So this slot "climate.woonkamer" for me, is taken by an Evohome entity which will return an error in the logs that the entity is not available. It should be replaced with the Ramses entity for the zone you want to replace/fake the sensor for.
temperature: "{{ states(\"sensor.indoor_outdoor_meter_1856\") | float }}" #again, this is the entity of the sensor you are using to record the temperature (zigbee, BT, ZWave, etc)
- delay: "00:00:01"
- service: homeassistant.update_entity
data: {}
target:
entity_id: sensor.03_123456_temperature #This is the entity of the faked sensor you created. In my case 03:123456, results in an entity called sensor.03_123456_temperature.
- service: homeassistant.update_entity
data: {}
target:
entity_id: climate.ramses_cc_01_245354_00 # And again: The example in the WIKI mentions a climate.kitchen entity. I was thrown off by this as I still have the "official" Evohome integration running. So this slot "climate.woonkamer" for me, is taken by an Evohome entity which will return an error in the logs that the entity is not available. It should be replaced with the Ramses entity for the zone you want to replace/fake the sensor for.
mode: single
-
Save the automation.
-
Monitor if the automation is triggered when you heat up or cool down the sensor. If you see it’s triggered, check your detailed system logs if you get any errors about entities not being available. If not, stare at your Evohome control panel in suspense until the hourglass updates into a temperature reading… ( Oh and once working, don’t forget to put back the caches to enabled.
Some observations about 0.30.9:
- Binding service call errors out. 0.22.40 works, see above post.
- I believe it’s best practice to remove the “appliance_control” section when you don’t have an OTB, but from my observations, behavior of the integration becomes more erratic. For instance the schema can become unavailable, data can become unavailable from valves/sensors and the status of my controller fault entity can become unavailable (01:245354 active_fault). Granted, most of the time they come back, but they can also become unavailable for hours at a time. Any insights in this?
- Lastly, any insights on the HCF82 entities being unavailable and giving errors in the log?:
Also, “03:255542: # Thermostaat zone 05 Kantoor” is a HCF82 temperature sensor/thermostat without manual temperature setting from Honeywell. It shows up in the logs. but the entities in HA never become available.
#2nd edit
I also found some error messages related to 03:255542:
Logger: ramses_rf.protocol.message
Source: runner.py:188
First occurred: 20:15:33 (5 occurrences)
Last logged: 22:15:31I 107 03:255542 --:------ 03:255542 30C9 003 0106E0 < Corrupt payload: Packet idx is 01, but expecting no idx (00) (0xAB)
I 108 03:255542 --:------ 03:255542 30C9 003 0106D6 < Corrupt payload: Packet idx is 01, but expecting no idx (00) (0xAB)
Thanks for your extensive explanation. i am going to try.
One question: I can download (ao) version 0.22.3 or 0.21.4. Not 0.22.4. Is your statement of 0.22.4 correct?
Yes, I believe it’s a beta version though, and I have the show beta versions slider enabled in HACS.
Maybe one of the other versions, like 0.21.4 works as well. It’s just that I didn’t try that one
If anyone can provide a packet log that includes a real (not faked) remote binding to a fan, or a sensor binding to a fan, can you please post here, or PM me:
- I am only interested in successful bindings of real devices (not faked)
- I am only interested in HVAC (Itho, Orcon, Nuaire, or other)
- I will need all packets for 5 seconds either side of the binding
- please include the exact make / model of the devices
- please include an
10E0packet from each device, if you can
The packet code to look for in the log is 1FC9.
Thanks. Rolling back to 22.40 worked, I now have all my valves using fake sensors.
A few days ago my setup with Ramses stopped working without any changes made. Trying to get it working again but no luck in the past few days.
I’ve updated to 0.30.9, deinstalled, installed etc but with this version running into two errors which I can’t seem to get rid of. This is directly on restart. Running the latest home assistant.
2023-12-24 23:21:31.322 ERROR (MainThread) [custom_components.ramses_cc] There is a problem with the serial port: Transport did not initialise successfully
2023-12-24 23:21:31.324 ERROR (MainThread) [homeassistant.setup] Setup failed for custom integration 'ramses_cc': Integration failed to initialize.
Where do I need to go to solve those?
My setup:
ramses_cc:
serial_port: /dev/ttyACM1
packet_log: packet.log
ramses_rf:
enforce_known_list: false
My packet.log:
2023-12-24T23:06:20.699260 # ramses_tx 0.30.9
2023-12-24T23:06:55.625075 000 I --- 18:072965 63:262142 --:------ 7FFF 015 0010018C9DDD623D76302E33302E39
2023-12-24T23:07:30.378584 000 I --- 18:072965 63:262142 --:------ 7FFF 015 0010018C9DDD623D76302E33302E39
2023-12-24T23:08:05.133593 000 I --- 18:072965 63:262142 --:------ 7FFF 015 0010018C9DDD623D76302E33302E39
2023-12-24T23:08:39.882815 000 I --- 18:072965 63:262142 --:------ 7FFF 015 0010018C9DDD623D76302E33302E39
2023-12-24T23:21:28.143884 # ramses_tx 0.30.9
2023-12-24T23:22:02.979592 000 I --- 18:072965 63:262142 --:------ 7FFF 015 0010018C9DEB3B0776302E33302E39
2023-12-24T23:22:37.982191 000 I --- 18:072965 63:262142 --:------ 7FFF 015 0010018C9DEB3B0776302E33302E39
2023-12-24T23:23:12.487052 000 I --- 18:072965 63:262142 --:------ 7FFF 015 0010018C9DEB3B0776302E33302E39
2023-12-24T23:23:47.237849 000 I --- 18:072965 63:262142 --:------ 7FFF 015 0010018C9DEB3B0776302E33302E39
Still no success
Logger: ramses_rf.protocol.transport
Source: runner.py:188
First occurred: 10:26:10 (9 occurrences)
Last logged: 10:42:36
Impersonating device: HCW:001234, for pkt: 1FC9| I|63:262142, NB: HGI80s dont support impersonation, it requires evofw3!
Impersonating device: HCW:001234, for pkt: 30C9| I|03:001234, NB: HGI80s dont support impersonation, it requires evofw3!
Impersonating device: RND:030123, for pkt: 1FC9| I|63:262142, NB: HGI80s dont support impersonation, it requires evofw3!
Seems to be a hardware problem? In domoticz I was able to fake a device.
Do you have a HGI80, or a dongle running evofw3?
If it is an evofw3, it has auto-detected incorrectly, which interests me…
- can you Tx at all? (if a nanoCUL, have you set the right baud-rate)?
If it is a HGI80, then impersonation support is non-existent, although you can do faking in a limited fashion.
To be clear - Domoticz did not do impersonation with a HGI80, only faking.
- a HGI80 simply cannot change the source address of the packets that it transmits