Has anybody successfully added a “fake” outdoor temperature sensor to their Evohome setup? I’ve got an actual outdoor sensor I’d like to add if possible but I can’t work out how to add it.
I have - but this only works if you have an evohome controller that uses an outdoor sensor - the original black & white model.
Ah OK thanks - mines one of the newer* colour models.
It’s like 6 years old now but not B&W.
Both colour models obtain this information from an Internet API (i.e. you have to have the device connected to the internet).
Yeah it gets the value but I wanted to (if possible) override it with a real local value but it doesn’t really matter having thought some more as I pretty much override everything the controller does and already have local temperature included in my automations, it was more “if I can I will” 
SSM is in stock!
Has anybody has any luck pairing to the Nuaire. I’ve just tried this evening and I’m not having much luck. Any pointers - thanks!
You need to send an 10E0 after the binding is complete.
Or just impersonate and existing switch, if you have one?
I have recently bought a evohome touch with 5 TRV’s (one for each zone) and a BDR91. I would like to configure 6 zones, the 6th zone should be triggered a shelly/tasmota device with a fake sensor. I am reading the wiki and this forum to learn how to do this. @zxdavb has done a great job and I am learning a lot.
I have connected 4 TRV’s to the evotouch. I noticed that one of the TRV has an issue (red exclamation mark on the evotouch). With the home assistant integration using the SSM-D2 I noticed that
the structure of zones and TRV/sensors is quite strange. One zone has two actuators (Room1) and one zone has none (Room3, the room with the red exclamation mark on the evotouch). See the structure below. Should I reset the evotouch and connect the TRVs again?
{
"main_tcs":"01:026398",
"01:026398":{
"system":{
"appliance_control":"13:019795"
},
"orphans":[ ],
"stored_hotwater":{ },
"underfloor_heating":{ },
"zones":{
"00":{
"_name":"Room1",
"class":"radiator_valve",
"sensor":"04:145139",
"actuators":[
"04:145139",
"04:145159"
]
},
"01":{
"_name":"Room2",
"class":"radiator_valve",
"sensor":"04:145175",
"actuators":[ "04:145175" ]
},
"02":{
"_name":"Room3",
"class":"radiator_valve",
"sensor":"None",
"actuators":[ ]
},
"03":{
"_name":"Room4",
"class":"radiator_valve",
"sensor":"04:014773",
"actuators":[ "04:014773" ]
}
}
},
"01:145038":{
"system":{ "appliance_control":"10:123446" },
"orphans":[ ],
"stored_hotwater":{ },
"underfloor_heating":{ },
"zones":{
"04":{
"_name":"None",
"class":"None",
"sensor":"01:111111",
"actuators":[ ]
}
}
},
"orphans_heat":[ ],
"orphans_hvac":[
"37:211856",
"37:213949",
"37:214558",
"37:214577"
]
}
Your config is not strange. It is a valid config, albeit not the config you want.
I understand you want one TRV per room, and each room is a zone…
Simply delete the zone with two TRVs and recreate it.
I’ve created a PR to fix the broken send_packet service. Only problem is the breaking change is descried as a regression bugfix and I’m not sure what the regression was?
I considered it strange because it is not the config I setup by having one TRV for each zone.
Deleting the zone did not solve it, even after a factory reset the same issue cam back.
A second time reconfiguring it from the start did solve it.
I have now been able to link a fake sensor to the zone (evotouch accepts the wireless sensor). However when I try to set the temperature with ramses_cc.put_zone_temp I get the error message that the climate entity does not have the _make_fake attribute which is indeed the case, only the sensor is fake: “Unexpected error for call_service at pos 1: ‘NoneType’ object has no attribute ‘_make_fake’”. The zone was setup with a real TRV and then the fake sensor was added. When inspecting the structure of TRVs and sensors, I see that the fake sensor shows a being an orphan, and the original sensor is still present with the TRV.
What should be the order of creating a zone with which device and sensor when the goal is to create a zone that is switched on with a wifi switch (controlling a pump) and a separate temperature sensor?
And is faking the sensor dependent on a real TRV and should the TRV remain linked to the zone?
Edit: This morning the evotouch reported an error that this zone could not communicte with the temperature sensor.
I’m sorry to have closed your PR. There is an extensively re-written version of the ramses_rf library that fixes the issue you addressed in you PR - please wait for it (in the meantime, you can continue to patch your own version of ramses_cc).
No worries.
Thank you for all your hard work so far. I’ve been using HA + your integration + a nanoCUL to control my heating for the past couple of years without going anywhere near the cloud and it has worked brilliantly.
Please fake a sensor with an address starting with 03:. Please provide the ramses_cc: section of your configuration.yaml here, along with the corresponding section from your automation.yaml.
Please provide some log files.
Having just been through this, also double check the 2nd part of the address you’re using for your faked sensor. It must be between something like lie 03:002000 and 03:020000 (I may not have that exactly right, but there’s a note on the wiki with the correct address range).
My first attempt to fake a sensor with an address of 03:777777 did not go well.
Here is the config and automation. I will PM you @zxdavb the log files.
Confuguration.yaml
# New integration for Honeywell
ramses_cc:
serial_port: /dev/ttyACM0
packet_log:
file_name: packet.log
rotate_backups: 28
ramses_rf:
enforce_known_list: false
# turn on later
restore_cache: true
01:145038: # Temperature control system (e.g. evohome)
system:
appliance_control: 10:123446
zones:
"04": {sensor: 01:111111}
known_list:
18:204301: # ? Active gateway (USB or BDR91, Evohome touch)
01:026398:
03:111111: {faked:true} # thermostat living room (impersonated)
03:222222: {faked:true} # thermostat living room (impersonated)
04:145139: # TRV
04:145159: # TRV
04:145175: # TRV
04:014774: # TRV
01:145038: # evotouch?
13:019795: # BDR91
10:123446: #
# 30:069468 # unknown device
logger:
logs:
custom_components.ramses_cc: info
Temperature automation:
alias: Livingroom impersonation
description: >-
When a temperature sensor updates, pass the temperature to ramses_cc as if it
was from a zone sensor. Then update the downstream entities.
mode: single
trigger:
- platform: state
entity_id: sensor.woonkamer_temperatuur
action:
- service: ramses_cc.put_zone_temp
data:
entity_id: climate.ramses_cc_01_026398_00
temperature: "{{ states(\"sensor.woonkamer_temperatuur\") | float }}"
- delay: "00:00:01"
- service: homeassistant.update_entity
data: {}
target:
entity_id: sensor.03_111111_temperature
- service: homeassistant.update_entity
data: {}
target:
entity_id: climate.ramses_cc_01_026398_00
Thank you for the suggestion.
I did try 03:002000 but it did not work well yet. The temperature sensor ended up as orphan:
"orphans_heat":[
"03:002000",
"04:014793",
"13:019795"
],
Have you read: Home · zxdavb/ramses_cc Wiki · GitHub
Faked devices are the same as real devices…
They have to exist (be faked), and then require binding to the controller.
I did read the wiki (and I am still reading the messages on this forum) and did a start bind of the sensor (and also did create it). The evotouch acknowledges that the binding was successful but in the Schema I do not see that it is.