Right now the component is in a preliminary state and only acts as a CAN message logger. The logged data can be fed into a parser which can be found here (also WIP).
The goal is to create a component that can be used to read and control your boiler.
The only hardware requirements for the logger are an ESP32, a CAN transceiver, which can be bought on Aliexpress for a few $/€, and an RJ12 cable.
I only have a sample size of one, but I expect it will work with most modern Remeha boilers/heat pumps, and possibly ones from related brands (De Dietrich, Baxi) as well.
Got an e-mail from a senior tech person at Remeha, explaining their issue with what I published. They were clear in stating that they don’t have issues with hobbyists working on interoperability, only to me publishing specific information that might be harmful to their devices when not used correctly.
I’ve asked if they agree to releasing only a subset of information that is already documented elsewhere on the web, including in their own manuals.
Which would be nice because they really, really should focus on making good hardware and leave software development to people who now how to and care about the results. I own a remeha heatpump and I am not convinced their engineers use their own thermostats.
Update to the story: I’m (slowly) working on a curated list of so-called “data points”, basically sensor values.
These values are extracted from public Remeha documentation, and completely rewritten/reformulated by myself to prevent any further copyright claims.
However, I have abandoned reading the CAN bus of my heat pump because the amount of data that is presented on it is limited. It’s probably possible to extract more information from the devices on the bus, but that will require writing to the CAN bus and I haven’t implemented that at all, nor am I planning on doing so.
I will keep on working on the list of data points and eventually publish it, but just want to give a warning that it will be of limited use, at least with the combination of ESPHome. There is at least one other project that can also benefit from the list, so hopefully that will yield a better working solution for Remeha users.
Hey, thanks for looking in to this. I found out too late (ie after having it installed)t hat my Remeha thermostat can’t be controlled locally, so anyone helping to address that is much appreciated. The project of Pepijn de Vos you linked to seems quite some way along to decoding the messages and being able to replace the eTwist with a locally driven solution. I hope you get there!
I’ve been collaborating with Pepijn on this and implemented an improved parser based on the data that I gathered for my own project. However, the parser isn’t yet fully available due to the aforementioned legal issues.
The main problem with his project is the hardware side. I bought one of his monitor PCB’s but haven’t been able to get it working. Around the same time I was also working on my own CAN project so I mothballed the PCB.
Ah. That’s unfortunate. I was reading a bit on the Remeha site, and it actually says the Elga Ace can be controlled by OpenTherm as well.
I couldn’t really find much about it in the manual or other documentation.
I also found a long thread on tweakers with a lot of info, but I guess you are familiar with that (I assume you are Dutch based on your username) It seems others have tried similar things.
If you hook up an OpenTherm thermostat to the Ace, and restart it, it should pick it up automatically.
I’ve considered going that way, but my installer told me that the eTwist is much better suited as thermostat for the Ace. However, he couldn’t explain exactly why, so it might as well have been Remeha marketing speak.
I don’t know enough about the different types of thermostats etc to judge this but I’m not sure I fully understand that list. I get 4. You need the outside temperature to determine the desired water temperature so you can save on energy if it’s not too cold outside. I don’t quite get what they mean with 2 and why it is in front of 3.
I also think it’s perfectly possible to harness the power of home assistant to make something that is at least as good, if not better than the eTwist. If you are only using a naked OpenTherm room thermostat you probably miss out on things like preheating but I bet that can be programmed better in automations.
TBH I don’t have much beef with the eTwist per se. I had issues with it dropping off my wireless network quite a bit, but I think I solved that for now, and my router was partly to blame. If Remeha gave us a way to communicate directly with the eTwist and cut it off from the outside world I’d happily keep it. But I don’t feel comfortable with a solution that depends on a third party, requires internet access to be controlled from my HA instance and also presents an additional point of entry to my network.
This is exactly my main issue with the eTwist: it cannot be controlled locally.
But it also doesn’t provide a lot of interesting information that’s available, like real-time energy usage, COP, water temperatures, etc. (but such information also wouldn’t be available if you’d use an OT thermostat and something like the OpenTherm Gateway, which is why I’m looking at reading the R-Bus or CANbus).
Yes, indeed if we could have a local solution that unlocks all the available information it would be great! I’ve not dived into the different protocols and types of thermostats yet. But if I understand you correctly the Opentherm thermostat will not have access to some of these parameters? Water temperature would certainly be a very useful thing to keep track of. I’ve had a metering plug connected for a while to monitor energy use in real time but there wasn’t much I was doing with that info. Since the update of the Remeha Home custom integration that gave the energy consumption I don’t need that anymore.
Perhaps some parameters are available over OT, since the protocol documents them (like water temperature), but OT is mostly used for regular boilers, not heat pumps, so the heat pump-specific parameters are most likely not accessible.
I also use a metering plug for my outdoor unit, at the moment mostly for informational purposes, like showing how “hard” it’s working based on its power draw. I just finished my “heating” card to show it:
The green color changes towards red when it’s using more energy.
The gas usage value is coming from my P1 reader (since it’s the only device in the house that uses gas), the power and energy values are based on the metering plug and a utility meter based on it.
The integration also provides the energy usage, but it’s much more coarse (it increases in steps of 1kWh).
Nice card! I found I only really used the daily accumulated energy anyway so I repurposed the metering plug. I would be interested to know what we lose when switching to an OpenTherm thermostat. There’s plenty of options for that, including Zigbee connected ones which I would prefer over wifi.
There’s a difference between “what does the OpenTherm protocol provide” and “what does an OpenTherm thermostat provide”, though.
I’ve used the PlugWise Anna thermostat before I got the Elga Ace, and the amount of information the Anna provided also was pretty limited, even though it was an OpenTherm thermostat.
So if you really want to be able to access everything that the OT protocol offers, you will have to use an OTGW in between the thermostat and the boiler.
