Just release 0.14.12.
All, there is a difference between what the controller believes to be true, and what a device (like a relay) believes to be true.
Thatâs why itâs worth knowing (e.g.) a zone temperature (from a controller) as well as the (measured) temperature from a thermostat (a sensor).
Sometimes they donât match, even though they should (e.g. the controller send relay demand, but the relay doesnât hear that packet)âŚ
I believe I have identified this bug - fix coming.
Just release 0.14.13 - has a fix for relay_demand
Thx its working again.
@zxdavb Can you please have another look at the Stored Hot Water entity, from what I can see the water temperature history is updating noticeably less frequently than the temperature sensor directly associated with the cylinder hot water sensor.
One of the problems is that I donât have a test bed at the momentâŚ
For this, I will need both a HA log and the corresponding packet log.
Just be aware that the way the DHW sensor updates is fundamentally different to a zone sensor.
They were, Iâll add a few things to it when I get time.
I now need to work out the automation to send my aqara sensor temperatures to it.
Maybe this is an helpful hint (based on Sonoff zigbee sensor):
- id: 'attic_north_fake_sensor'
alias: Evohome | Attic north fake sensor
description: Zolder | Kamer noord werk temperatuur bij
trigger:
- platform: state
entity_id: sensor.attic_north_temperature
- platform: time_pattern
minutes: 0
action:
- service: evohome_cc.put_zone_temp
data:
entity_id: climate.zolder_noord
temperature: '{{states("sensor.attic_north_temperature") | float }}'
Added the time pattern trigger, to ensure the tempature stay set as updates are sometimes very few and far between (might be unnecessary).
Thatâs every hour? I would make it minimum every 20 mins, so /20?
You may also need to put in a condition, so that âoddâ values are not send to the sensor (one of mine sends a 0 when it means N/A)
So, 0.14.14 just released - hopefully the last release for a while. The main change is that the HGI80 (or the evofw3-compatible equivalent) is now exposed as an entity.
- the
18:xxxxxx (config)entity contains the configuration - the
01:xxxxxx (schema)entity contains the system schema
You should only need to use the minimal schema from the config entity in your configuration.yaml - let me know if this is not the case.
In the short term, I am thinking of deprecating the BDR modulation_level sensors (they are always 100%, 0% or N/A); you can use the corresponding enabled binary sensor instead (on, off or N/A). Note: any OTB modulation_level sensor will remain.
Iâm now hoping to keep development on hold, until someone asks to use a HGI80 as a zone sensor, or similar (sadly, this will need significant changes to the codebase).
I would be curious what features people may be hoping for?
Please keep reporting bugs!
1 Like
⌠and advanced_override will be deprecated - the system will behave correctly without it.
Thanks for that, Iâve now got it fully working, so Iâll add a few move sensors and see how I go.
Iâve got this running in 3 rooms at the minute, how do I workout if I need a condition in the automation?
The heating side of things appears to be working great for me so far, thank you.
For DHW, I think that the helper text needs updating. A bit of background⌠my ultimate aim is to have an automation that detects whether or not the Evohome heating mode is off or not, and also disable the hot water functionality meaning my immersion can take over and the boiler doesnât need to fire up at all that day. But anyway⌠this following call works just fine:
service: evohome_cc.set_dhw_mode
data:
entity_id: water_heater.stored_hw
mode: temporary_override
active: false
duration:
minutes: 60
But it took a bit of figuring out based on the help information which doesnât mention the need for the entity_id, so doesnât fill it in as example data, and the description also talks about requiring a target which confuses the terminology. This isnât a bug, itâs just something I figured out eventually and if updated it could save other people a lot of time.
I canât get it to add more than 3 fake sensors as I now get this error.
Logger: ramses_rf.protocol.protocol
Source: /usr/local/lib/python3.9/site-packages/ramses_rf/protocol/protocol.py:160
First occurred: 17:58:15 (1 occurrences)
Last logged: 17:58:15
MsgTransport._pkt_receiver(1FC9| W|03:123459): Expired callback
I am about to drop a new version of the code - sorry - this release will have a breaking change: some sensors will disappear, some binary sensors will change their name from enabled to active- this is due to changes deep in the library, and to better reflect the information theyâre providing.
OK, pushed 0.14.15 - lots of improvments, please upgrade & report bugs - sorry for breaking changes:
Changes include:
- DHW service calls no longer require
entity_id(service names may have changed) - thanks @sOckhamSter - there are additional attributes for sensors (e.g.
domain_id,role) - BDR91A sensor entities removed:
modulation_level(superfluous) - BDR91A binary_sensor entitles renamed from
enabledtoactive -
zone.set_temperature()is now always until the end of the current scheduled setpoint - (and because of above) config option
advanced_overrideis now deprecated - remove it from your configuration.yaml
There are new entities:
- schema entity: with current/full schema (what you got), and
- config entity: with recommended schema (what you should put in your configuration.yaml), and filter lists (ditto)
Client library bump:
- Improve transport resilience, evofw3 detection
- less logspam, better log messages, etc.
- improvements to schema fro actuators (BDRs, and OTBs),
- improvements to filtering
- bugfix of nasty bug that could cause evohome_cc to hang
- much better resilience to badness (separate to above)
1 Like
Some regression, I think - chasing now.
just updated from 0.13. one new entity for my evofw3 usb stick beginning wit id 18.
removed the BDR91 modulation level entity, now i have 3 entities 2 are working one with name active and the second with relay demand. I still have a actuator which is not available is this entitie away too? otherwise i will remove it.