I have a EMS bus gateway that I’m willing to give away.
It is the older ESP8266 version, running the older firmware. I’m told it can be upgraded with a ESP32 chip relatively easily:
If you’re interested, PM me: all I ask is for someone to consider paying for postage.
I’m trying to fake a sensor for an existing zone with an hr92, I have already 1 zone with a fake sensor for a fee years but don’t remember how i did it.
I’m in the zone and have tried the button temperature sensor and then Remote sensor, pressed then the call fake device service in ha, but that pairs nothing. Did the same with rf device button and no succes eighter. Is this good of do I have to delete the zone and and the hr92 and a fake temp sensor?
Have you read here: Create new page · zxdavb/ramses_cc Wiki · GitHub
If the answer isn’t in there - let me know.
The other option is: there is a bug in the code, so perhaps:
Yes I read that, but the evohome part is not in it so maybe I do something wrong there.
I’m using 0.21.5 and this code:
service: ramses_cc.fake_device
data:
device_id: "03:256006"
Edit: saw in the wiki that i need to add the new id firts to the know list, but still no luck.
But then I get this in the log: The device id does not exist: 03:256006
Deleting zone didn’t help, hopefully my schema is still good.
Found in this topic the how to for facking, this is What I did, and that is not working with the new id what I’m using in the know list.
Tried it with the known list disabled but stil not working and this fault in the log:
The device id does not exist: 03:256006
So i think i tried now everything, mabe someone else can try it?
but looks like a bug.
Post the ramses_cc: section of your configuration.yaml
Should it not be
data:
device_id: "03:999999"
create_device: true
This is my configuration.yaml
ramses_cc:
scan_interval: 60
restore_cache:
restore_schema: true
restore_state: true
serial_port: /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0
packet_log:
file_name: packet.log
rotate_backups: 7
ramses_rf:
enforce_known_list: true
01:155341: {}
# system:
# appliance_control: 13:189740
known_list:
01:155341: # Controller
04:008512:
04:070150:
04:070154:
04:070160:
04:073460:
04:108167:
04:108169:
04:108171:
04:108173:
13:189740: # BDR91 Ketel
18:203293: {class: HGI} # nanoCUL
03:256005: {faked: true} # BME680 Kantoor
# 03:256006:
shall try it tommorrow
is start_binding also needed?
a few years ago both where not needed.
Oke, i have it working now, first indeed you need te create the device with the code:
service: ramses_cc.fake_device
data:
device_id: "03:256006"
create_device: true
The you set your evohome in pairing mode for the remote sensor, and than you send the start pairing code:
service: ramses_cc.fake_device
data:
device_id: "03:256006"
start_binding: true
on the evohome screen you now see a succesfull pair message.
After that i changed my configuration.yaml know list with the new sensor
known_list:
03:256006: {faked: true}
The did a reboot, but schema was not updated so i could not use the service ramses_cc.put_zone_temp, as stated in the wiki i then changed:
ramses_cc:
restore_cache: false
After a reboot schema was still not updated, so changed:
ramses_cc:
restore_cache: false
restore_schema: false
After a reboot now the schema was good and i could use the service ramses_cc.put_zone_temp
I guess you were looking at the wiki, after the edits I made last night?
It is still a WIP - I wonder if you have identified a typo - I will check it.
Don’t forget to put this back:
ramses_cc:
restore_cache: true
or:
ramses_cc:
restore_cache:
restore_schema: true
restore_state: true
Yes, already done that.
But i had this in my config:
ramses_cc:
restore_cache:
restore_schema: true
restore_state: true
So i changed first state to false, i see now what is in the wiki is for both so that was my bad.
Indeed i did read the updated wiki, maybe the creating and binding is a good addition to it.
Actually, thinking about your experience, and the number of HA restarts needed, I am going to change a few things around to improve the UX.
Sensor faking is one of the highlights of ramses_cc - so we want it to be easy.
If you know how to do it, it’s not difficult. And 2 reboot it’s doable.
It’s still a hobby for me 
I must be doing something silly. Can someone please confirm that this logger config should give me decoded messages in home-assistant.log. I’m getting output for protocol and transport, but no decoded messages.
logger:
default: warn
logs:
# homeassistant.core: debug
# ramses_rf.devices: debug
# ramses_rf.entity: debug
ramses_rf.message: info
ramses_rf.protocol: info
ramses_rf.transport: info
# custom_components.ramses_cc: debug
# custom_components.evohome_cc.sensor: debug
They are:
ramses_rf.dispatcher: info # messages Tx/Rx at app layer - usu. the logging you want (no RQs for readability)
# ramses_rf.protocol.protocol: info # packets Tx/Rx at upper (serial) layer (SENT/rcvd)
# ramses_rf.protocol.transport: info # raw frames Tx/Rx at lower (RF) layer (incl. RSSI)
Thanks. Have updated the troubleshooting Wikki page.
Thanks: I have tweaked it a little.
ramses_rf.protocol.protocol and not ramses_rf.protocol
ramses_rf.protocol.transport and not ramses_rf.transport
… and regardless of that, the one you want is usually:
logger:
logs:
ramses_rf.dispatcher: info
I’ve just had a OTB installed, and I’m trying to understand how it operates. Looking at the decoded packets I cannot see how the controller tells the boiler what temperature to operate at. I’d appreciate it if someone could shed some light on this. Thanks