I would presume so - I don’t have time to test personally.
But how can it happen that he sends random the temperature of 25 degrees?
I don’t know - you haven’t provided enough information for me to take on that question. Maybe you could start with a packet log?
The log_idx is a failure to decode a packet - it won’t cause the behaviour you describe.
I send you a pm
@zxdavb … Yesterday I had evohome_cc & evohome_rf master branches working reasonably well inside HA with a nanoCUL & evofw3. I say reasonably well - all zones , devices etc were discovered fine but there were several missing & late heat_demands & temps from a couple of HR92 TRVs, despite them communicating fine with the controller.
So I backed out evohome_cc & rf out of the HA config & tried evohome_rf bleeding edge branch standalone. Judging by the stdout this worked much better. It appeared to be catching all heat_demands & temps at the right time now. Is that expected, or did I just get lucky with the nanoCUL antenna position when I was moving things around?
Anyway … I tried replacing evohome_rf master branch in the custom_components/evohome_cc directory structure with the evohome_rf bleeding edge branch. With all files in the evohome_rf subdirectory as before. This didn’t go so well. HA log reports
ERROR (MainThread) [custom_components.evohome_cc] evohome_cc v0.4.3, using evohome_rf v0.5.x (bleeding_edge) - versions don't match (this is bad)
And plenty of other errors & no packet log.
Is it possible to get this combination working?
TL;DR - no.
The bleeding_edge branch of evohome_rf is a significant improvement over that currently used by evohome_cc. It will solve many of the current issues we see, an provide opportunity to implement new features…
I will have to refactor evohome_cc (or accept a PR).
OK, thanks for the clarifications.
Well that would be nice … but given current events I can understand why that wouldn’t be a priority.
Keep up the great work. It’s much appreciated.
I have a CM727 which uses BDR91 wirelss relay, as far as I’m aware, the thermostat just sends commands to open or close the relay to ask for heat.
Can your method here allow me to send the equivalent command to call for heat that the CM727 does?
Just found this project, looks good! and very interested in it.
I have already the official evohome integration installed, is this project(custom integration) an addition? Or creates it also climate entities and the end result is that everything is created double?
I’m mostly interested in the heating and heat distribution
It’s a better option then the official integration. When you install it beside the offfical integration, you get double entiteits, as example climate.livingroom_2 including a couple of extra sensors.
So as a follow up question, each restart of the core it has to recapture all the values?
Kr,
Philippe
Thats correct.
When I try to config HACS to use the repostory of evohome_cc I get: “Repostitory structure for master is not compliant”, are there plans to support it?
Yes. If someone is keen, I will accept a PR.
Bought myself a HGI80, will test it this weekend.
Where did you find one - they’re a bit difficult to get a hold of now.
I found one on a 2hand store for 60 euro, can be picked up this weekend.
1 Like
A bargain!
Looks like we’re ready to switch dev from evohome_rf back to evohome_cc for a while:
06:48:37.183 || HGI:Honeywell | BDR:081807-R | RQ | relay_demand | 00 || {}
06:48:37.386 PktProtocol.send_data(RQ|13:081807|0008|00): boff=1, want=RQ|13:081807|0008|00, tout=2021-01-22 06:48:37.486135: RE-SENT (1/1)
06:48:37.411 || HGI:Honeywell | BDR:081807-R | RQ | relay_demand | 00 || {}
06:48:37.424 || BDR:081807-R | HGI:Honeywell | RP | relay_demand | 0000 || {'relay_demand': 0.0}
Here, you see a QoS feature - the RQ is lost to the ether (the relay didn’t pick it up), and evohome_rf can see that, so simply retransmits it (RE-SENT) - which solves the problem.
This will manifest in many ways - no more mising zone names, for example.