Hi, I’ve just started using Home Assistant, which I run on an x86. I’ve now gotten the SkyConnect stick, which I initially want to use to communicate with TRVs. Currently, I am looking at getting the Danfoss Ally. When browsing the available information, several questions came up that I couldn’t fully answer yet:
I found a HACS integration “danfoss_ally” that integrates the TRVs via the Danfoss gateway.
** Am I correct in assuming I do not need the gateway if I have a Zigbee controller like the SkyConnect?
** What are the advantages of integrating the Danfoss gateway instead of single TRVs?
If I understand the information on this page Danfoss Ally Radiator Thermostat 014G2461 Zigbee compatibility correctly, there are lots of exposed parameters via Z2M while Danfoss Ally eTRV entities suggests that only minimal information can be gotten via ZHA.
** What would be the best way to configure my SkyConnect and HA instance to communicate with the TRVs?
** Are there any advantages to Z2M or ZHA currently? I found lots of contradicting information, possibly due to both integrations changing over time. What would you recommend for a relative newbie to use?
Assuming these are zigbee (and not wifi) controlled devices, you can usually get away from the requirement of using any 3rd party hubs or integrations at all, as long as HA can pair with it then operate it correctly.
Pairing is usually not an issue, if you follow the manufacturers instructions to get it into pairing mode, then listen for that device in HA, and it should pair.
Whether or not it then ‘works’ depends on whether or not the TRV conforms to the zigbee spec properly. Even if it does not, there are converters (Z2M) or Quirks (ZHA) that can be used to make the device work.
ZHA is considered the more modern approach as compared to Z2M, but both have pro’s and cons.
Usually, it seems Z2M has better device support (for the non standard stuff), but in my experience, ZHA isn’t far behind.
ZHA is built directly into HA, whereas Z2M needs an external addon. Pro’s and cons to both approaches.
Tbh, unless you have a specific reason to, I’d suggest ZHA as a starting point.
At first, welcome to the HA world. I was too in a very similar situation than yours when i bought my first Danfoss Aly. Looking at it online, i could see that it exposes tons of information that i could use to automate the radiators.
At first, i didn’t purchase the gateway from Danfoss simply because i wasn’t sure it’s gonna work with my other zigbee devices and i didn’t want another app on my phone to control the radiators. I went with a generic SONOF Zigbee bridge in which i flashed Tasmota on in order to make it a generic zigbee gateway and be able to connect all my devices.
After paring the Danfoss with the Zigbee Bridge, i noticed that i have only a couple of entities in HA. Therefore, i opened a thread here asking for help (Danfoss Ally eTRV entities). It seems, that the entities that it exposes, are the only ones you need.
If you are able to control the temperature from HA, that’s all you will actually do. With ZHA, there is no switch to turn off the radiator, but, reducing the temperature to minimum actually turns the radiator off. You cannot utilize the build-in open window sensor but you can have a contact sensor on your window (external). I don’t believe the Build-in sensor will be reliable to be honest simply because it relies on the temperature of the room. If it feels that there is a sudden drop in the temperature, it feels that a window is open. I assume that it will take some time to “feel” the drop in temperature simply because it is located next to the (warm) radiator. An external contact sensor will be more reliable and much faster.
Speaking about the build-in temperature sensor i believe it is quite good even if it is next to the radiator. I have an external temperature sensor on the other side of the room (5 meters away) and they have 0.5 degrees celcius difference (the external sensor shows lower temperature) but this might be actual because of the location. My conclusion is that built-in sensor is accurate.
At the end of the day, the automations you build using the temperature is the key. Yes, you may need a couple of more devices depending on what you want to do but overall i am very satisfied from the TRV.
You do need a Zigbee gateway implementation solution (e.i. software) like either Home Assistant’s built-in native ZHA integration or Zigbee2MQTT (Z2M) (add-on or stand-alone application which communicate via MQTT) that uses the Zigbee Coordinator (e.i. the Home Assistant SkyConnect radio adapter).
ZHA and Zigbee2MQTT have different pros and cons as Zigbee gateway solutions and as you suspected, those pros and cons have and continue to change over time as both solutions continue to be actively developed. You can read about such on Reddit and watch YouTube video but much of the information often outdated relatively quickly.
Perhaps most important is that while with only a few limitations, most devices should in theory be able join/pair directly to any Zigbee solution regardless of brand and manufacturer, but because the Zigbee specifications allow for manufacturers to add custom non-standard features/functions to new products that are impossible for developers to predict and add support for in advance, (which is one of the readon why commerical hubs only whitelist their own brand of devices that have been tested and confirmed working) thus users of all and any Zigbee solutions that is not from the original manufacturer need to be aware that not all functionality will always be supported out-of-the-box and devices that use custom “manufacturer-specific extensions ” to add functions and features not included in the standard Zigbee specifications will need device-specific code in the form of Zigbee device handlers/converters that decode/translate all custom features for them to fully work. For ZHA and Zigbee that process is described here → https://www.home-assistant.io/integrations/zha#how-to-add-support-for-new-and-unsupported-devices and https://www.zigbee2mqtt.io/advanced/support-new-devices/01_support_new_devices.html respectively. To summerize the basics, since the developers can not buy and test every Zigbee device out there themself, you as the end-user who want to use a specific new device need to buy and test joining/pairing that new device yourself to the Zigbee solution you want to use before then submit a device support request with device signature + diagnostics information in order for the developers to decode/translate that data and be able to add those custom parameters and attributes in a new custom device handler/converter that is specific to that new device. So if a device that uses custom “manufacturer-specific extensions ” to add new non-standard functions and features is supported in one Zigbee solution but not another then that simply means that an end-user and a developer have not yet collaborated to create a new custom device device handler/converter for that specific device in that Zigbee solution.
Out-of-the-box support for custom features/functions in new devices + always getting the latest firmware updates from the official source are usually the main benefits of using the manufacturer’s commercial Zigbee gateway/bridge/hub with their own branded devices.
The main downside to that (other than having to maintain different brand hubs in multiple apps) is that manufacturer’s own Zigbee gateways/bridges/hubs normally only support their own brand of devices, and Zigbee heavily relies on mesh networking using indirect routing over Zigbee Router devices in the Zigbee network to achieve better range and coverage, so optimally you want to keep all your Zigbee devices on the same Zigbee network if possible to get good range and coverage.
Zigbee radios have very short range and poor wall penetrating signals to its network mesh technology and Zigbee Router devices is the key to a stable Zigbee network, and that will not work well in practice if you need to use a different Zigbee gateway/bridge/hub for each brand of devices that you buy if you only have a few devices connected to each and spread out those far away. See these tips which apply to all Zigbee solutions (even proprietary Zigbee gateways/bridges/hubs ) → Zigbee networks: how to guide for avoiding interference and optimize for getting better range + coverage
I think that is a perfect example where the user who wants that specific function exposed in ZHA for this product would need to submit a new “device support request” issue to the ZHA Device Handlers repository on GitHub for ZHA developers to be able to add/update a custom “quirk” to a future version of the ZHA integration.
Wow, thanks for all the detailed information, that helps a lot!
@michaelkrtikos : Thanks for the input. I read your thread and it seems that temperature and battery status can be read and a temperature goal set, which seems to be enough indeed. @Hedda Thanks for all the general information on Zigbee, will check that out and then dive into it
