CCTFG6901G2 is a generation2 hub, that is compliant to this integration.
This part number can manage a boiler (opentherm compliant), it can also manage other heating devices (heating-actuators …), for the radiators it uses iTRVs and roomstats…
If you have a water floor heating system you can add a CCTFR6600 to manage each walve
The gen2 devices are available on the UK site under the Smart Home Category - if you go through the selection wizard it will tell you which one to buy.
If you already have a zigbee network connected to Home Assistant I dont see the benefit of Gen2. Yes, it allows you to manage additional devices, but it appears they have to be Schneider devices. If I was buying today I’d still buy gen1 and a separate matter or zigbee coordinator.
If I’m wrong and it isnt locked down and can act as the zigbee coordinator for any zigbee device gen2 is probably good.
Thanks @LGO44 for the response - very happy to hear that the G2 devices are supported. My concern is two-fold:
I have a floor heating circuit and a radiator heating circuit (separate), plus the hot water. On my current heater, the input temperature to the two is different (~45C for the floor heating, ~60C for the radiator). I guess this “one-channel” device can’t distinguish between two circuits (i.e. to submit a command like “start heating circuit 1 at 60C” - it would just ask the boiler to ‘start heating at 60C’), correct?
I do have an existing Zigbee network (two, in fact - long story), with coordinators, routers etc. The attractive part about the Schneider hubs is that (if I am not mistaken) this integration works via TCP/IP to the hub rather than via Zigbee (so commands can be acknowledged, state can be transmitted etc - stuff that can be problematic with Zigbee).
I’ll probably return the 1-channel device and keep searching for the 3-channel one.
There is a separate Wiser unit for managing underfloor heating. When I installed UFH i didnt see a specific need to spend extra on the Wiser solution and just went with the installers recommended controller.
All i am losing is the ability to manage it remotely, so if i forget to put it in vacation mode it stays on till we get back. So be it.
I dont think the smart timer is significantly worth it for UFH which should be on most of the time anyway. I would be interested to hear the experience of those that went for the Wiser UFH solution.
I think I’ve seen that, but I would rather not complicate the setup even further and/or spend extra for this.
I have today an (archaic) UFH control - wired valves + wall thermostats - and it’s been nothing but trouble. My thinking was to eliminate this altogether (or rather replace with classical on/off mechanical valves and keep them always ‘on’) and control/track the push of heat from the heater itself.
I wouldnt mess with any aspect of my UFH without expert advice. It was painful and expensive enough to install. Definitely a “measure twice, cut once” type of thing.
Hi, I doubt this is anything to do with the HA integration but I wanted to check if this is normal behaviour… I’ve just installed the Wiser thermostat and for some reason it seems to ‘short cycle’ my combi boiler, so it is turning on/off every 3-5 mins while the room is not yet up to temperature.
So in this example the room was at 17.6 and set to heat to 18.5 between 6:30-8:30. For some reason the heating kept turning off even though the target had not yet been reached:
That is the expected behaviour as the room approaches the setpoint. The Wiser system slowly nudges the temperature up by cycling the boiler. The number of cycles per hour for a gas boiler is set at 6, so you could have a 5 on followed by 5 off. Whilst a bit counter intuitative you can reduce the number of cycles by telling the Wiser system you have an oil boiler as this uses 3 cycles per hour.
The Wiser system works on the basis that there is a certain lag between the boiler going off and the temperature achieved as water continues to flow through the radiators for a few minutes whilst the pump continues to run.
Thanks for explaining. I understand the logic, but it still doesn’t seem right to switch it off after just 5 minutes when almost 1 degree below the target (bear in mind it took 2 hours to actually reach the target this way). The radiators barely warm up in that time! I’ve seen it switch off after just 2 minutes even.
Does the system learn at all and improve how it manages this over time?
However my conservatory is heated “Passively” up to 19.5 degrees but when I’m “Away” i have an automation to change it to “Heating” and apply a schedule that’s set it to 7.5 degrees C. This stops me heating it (and the outside world) but stops it freezin, whilst I’m away. There is another automation that reverts this back to “Passive” and the associated settings when “Away” mode is changed back to off
BTW I do this because the Away Mode temp. is above the 7.5 degrees
My view may be a little simplistic on how this actually works under the covers. When the system starts up in the morning and the actual temp is say 3c from the setpoint the boiler will be on 100% of the time, once it gets to about 1c below the setpoint the boiler will start to cycle and the demand percentage drops to 90, 80, 60, etc.
In part I suspect this is because there is a certain latent heat in the radiators and even after the boiler cuts out and subsequently the pump stops the room temp will continue to rise slightly. The system is trying not to overshoot the setpoint.
So with the default gas boiler of 6 on/off cycles per hour each 10 minute period could have a decreasing “on” period as the temp approachs the setpoint. By changing to “oil” you probably have the same total “on” or “off” minutes per hour but they are in larger chunks. So instead of being “on” for 5 minutes it would be 10 minutes but a larger gap until the next “on” period.
I've got a question about data types. If you add a room entity to a room area, and then try and use the area card to display it, it seems to pick up the target temperature as one of the temperature sensors in that area, and averages it together with the actual temperature before it gets displayed. Is it right that the target temperature is being thought of as a 'sensor' and not some type of 'input_number'?
For each HA area you can specify which sensor to use for Temperature and Humidity.
For the rooms where I only have Wiser sensors (either a Roomstat or iTRVs) I select the Wiser Room Temperature sensor.
For rooms with more than one iTRV the room temp is calculated based on average (?) of the iTRVs. If you have a Roomstat it uses only the value from that.
I havent observed any cases of it calculating based on the target temperature.
The HA interface can make it a little tricky to select the sensor you want (or know exactly which one has been selected) especially if you use a mobile interface. If you are seeing anything odd, check on a computer screen, and to be absolutely sure find the sensor you want in the entities list, copy the ID starting with sensor. and then paste it into the Area config page.
Ah yes, that was it - by default (if you don't set a particular sensor) it averages the temp sensors. If you set a particular one, then it's all good. Thanks @dunxd
If you have a Wiser roomstat it is pretty accurate since you can place it somewhere sensible. If you only have iTRVs each is by nature right next to a radiators. In my experience this makes for poor measurement. The Wiser calculation for the room is likely better than getting it directly from an iTRV. The average between two iTRVs likely represents the room temp than one or the other.
I would recommend using the Wiser calculation. It is what is used by Wiser to control the heating and likely the most accurate. Wiser may update the algorithm to be more accurate in future updates.
I have third party temp and humidity sensors in some rooms which are more accurate than the reading based on iTRVs and MUCH lower cost than Wiser roomstats. In those cases I use the third party sensor instead of the iTRV.