[QUOTE=dty;30812]Look at it from the other direction. If your boiler is taking instructions from the OT bridge, how does the DHW system call for heat? In fact, how does that work in your current setup?
Currently I have a separate Honeywell single zone timer wired into the boiler that manages my hot water.
I also have a solar PV iBoost topping up the megaflo on the rare occasion that the sun comes out.
Interesting, I was under the impression that a boiler would either take its instructions from OT or from conventional wiring, and not both.
Some boilers have a separate hot water demand input which fires the boiler and boosts the flow temperature to maximum (or a pre-set hot water flow temperature independent from the central heating flow temperature) and this usually fires the boiler as well, and can work in parallel with OpenTherm.
It would mean that you always get that high hot water heating flow temperature when there is hot water reheat demand though, regardless of what OpenTherm asks for, although higher flow temperature with simultaneous hot water and heating demand is a problem in general for S-Plan systems.
The 'too much data' doesn't make any sense to me and sounds like a fob-off. According to the Opentherm protocol spec V2-2 which has been made public on a blog site, the Opentherm interface is point to point so the only traffic that the boiler will see is that intended for it (and the protocol doesn't include any sort of address information anyway). As far as the boiler is concerned I can't see how a multi-zoned system would make any difference at all as the controller should simply calculate the total heating load of all the zones and modulate the boiler output, and possibly the pump, accordingly.
I wouldn't expect any more, or different messages, to be involved than in a single zoned system. At the end of the day it is just a boiler which has one simple job - however the rest of the system is configured - which is to provide the amount of heat the controller specifies and control the pump appropriately (if it has one).
In fact that Opentherm document states:
As to messaging rates, the protocol spec specifies the data rate to be 1000b/s (very slow) and that a minimum time of 100ms is required between the end of a response from the boiler to the controller and the next request or command sent from the controller. It is also allowed for the boiler to wait up to 800ms to respond to a command/request. For any boiler control circuitry not built with relays 100ms is an absolute age and should easily be handled with any microcontroller built since the 1970s. Hmm unless it's running Java perhaps.There is only one control value defined - data-id=01, the control setpoint. The control setpoint ranges between a minimum of 0 and maximum of 100. It represents directly a temperature setpoint for the supply from the boiler. The slave does not need to know how the master has calculated the control setpoint, e.g. whether it used room control or OTC, it only needs to control to the value. Likewise, the master does not need to know how the slave is controlling the supply.
I guess the protocol could have been updated to permit faster messaging but it still wouldn't explain how the boiler could see any difference between single and multi-zoned installations. If Intergas or Honeywell aren't prepared to provide more information or explain what the real issue is, it will need someone with an Arduino (or similar) Opentherm monitor to have a look at what messages are sent by the Evohome in an Intergas multi-zone system.
I don't understand why there seem to be so many problems with Opentherm, as, in essence, the main functionality of the interface is trivial - to allow a thermostat/controller to tell the boiler how much heat to produce; all the rest including boiler sensor and status information, fault codes etc. is not required though it may be of interest to a more sophisticated controller. Perhaps the problem is due to the specification not sufficiently specifying the exact behaviour of the boiler in response to commands.
Or perhaps because the spec allows 'Transparent Slave Parameters' whereby the boiler can have settable, but unspecified, parameters of which the controller has no knowledge. I guess it's conceivable this could require a controller to send some special messages for the boiler to function correctly, e.g. to extend the standard. I guess this would allow the boiler manufacturer to declare Opentherm compatibility whilst effectively making it only controllable by equipment made by collaborating manufacturers. It seems a bit of a stretch though and it's hard to see what advantage that would provide.
I agree 100% with everything you said and already said much the same as you in a post a couple of months ago. Seems like a fob off for a bug in the boilers implementation of the OpenTherm protocol. As you say it is a relatively simple protocol so its quite bizarre that so many boilers have problems getting it right.
And as far as who is to blame in the compatibility issue, (Honeywell or the boiler maker) I would have to lean on the side of the boiler maker for two reasons - one is that many boilers do work correctly with Evohome, and secondly OpenTherm is actually a protocol that was designed BY Honeywell, and then made available for others to use. So if anyone is going to get the protocol implemented correctly I think it would be Honeywell with their flagship product!
On the other hand OpenTherm is an optional, afterthought checkbox feature on many boilers, so I doubt they put much effort into making sure the implementation is correct, bug free and robust, especially those brands that actively avoid selling the OpenTherm module for their boilers into the UK market...
If I owned the affected boiler I would be feeling fairly aggrieved at being fobbed off, and one thing is sure - if I was in the market for a new boiler I would only choose one that was known to work properly with Evohome using OpenTherm. I wouldn't buy it on checkbox compatibility alone.
Last edited by DBMandrake; 10th February 2017 at 01:33 PM.
Which was the whole reason for me starting the opentherm/boiler thread.
I think you're right but its not completely clear cut. Protocols such as Opentherm are often well specified as to the exact message formats and content but the behaviour rarely is. A very contrived example is that a controller sets a value on the boiler and then immediately reads it back. The boiler designer for some unknown reason decided that actually applying that value was of low priority; the boiler doesn't get round to doing so by the time the controller tries to read it back and returns the old value to the controller. The controller then throws its knickers in the air as the boiler is 'clearly' not working.
The problem is really down to the the specification not specifying a time limit. Note I'm not saying this is a real issue with the Opentherm spec - it may have an appropriate clause. It's just that it's remarkable (IME) how often that problems arise in what would seem to be quite simple scenarios, because the specifiers don't have a detailed understanding of the issues that may arise - especially when the technology used by the implementors changes and new constraints arise.
Another contrived example might be limitations on duty cycles on electro-mechanical parts to avoid overheating - if the controller has no understanding of them it may try to change operating conditions more often than the boiler will allow, again leading to a stand-off.
That's true for the UK market but my understanding is that it's mandatory in the Netherlands so I'd have thought that Opentherm was much more important there and thus the implementations should be pretty robust. It would be interesting to know how widespread the use of Opentherm control systems is in the Netherlands. And how popular Evohome is over there?On the other hand OpenTherm is an optional, afterthought checkbox feature on many boilers, so I doubt they put much effort into making sure the implementation is correct, bug free and robust, especially those brands that actively avoid selling the OpenTherm module for their boilers into the UK market...
I suppose its possible that Intergas could supply different firmware for the UK market but I'd be surprised if the Opentherm implementation was any different. Thinking about it, I'd not be particularly surprised either given the number of companies who see electronics and firmware as an expensive but necessary evil... Again, I'm not suggesting that Intergas falls into this category!
Dam right, I would too. Trouble is it seems that getting reliable information on which products work well is difficult, hence the value of this, and other, forums.If I owned the affected boiler I would be feeling fairly aggrieved at being fobbed off, and one thing is sure - if I was in the market for a new boiler I would only choose one that was known to work properly with Evohome using OpenTherm. I wouldn't buy it on checkbox compatibility alone.
Hello all, new here.
I am considering the purchase and install of the ECO RF 36 Combi boiler, with opentherm (and price) the main attraction. Is there any follow up to the information in this thread?
I intend to use Evohome to control the whole system.
Thanks
Tony
Hi - as far as I know the situation hasn't changed. The RF Eco copes well with a single zone Opentherm thermostat but still has issues coping with Evohome's multi-zone demands. I suggest that you contact Intergas Technical Support UK for an update.
PS: that is a sizeable boiler; are you heating a mansion?