New Updates:
Support setting valve opening percentage when added to ZBBridge-P, NSPanel Pro, iHost, and ZBBridge-U.
Support setting external sensor, allowing SNZB-02, SNZB-02D, and SNZB-02P to be used as a reference temperature for the TRVZB.
*Currently only supported when added to ZBBridge-P.
*NSPanel Pro, iHost, and ZBBridge-U will be supported in December.
Thank you for the info.
I have a NSPanel Pro and i have seen the “externalSensor” feature a few days.
But i was not able to save the sensor, because it is not supportet in NSPanel Pro.
Hurry up, in november it could bee cold. 
We are working hard on it.
I think this is the first step to make a good heating control.
The temperature control of the TRVZB is, at best, simple control (OPEN / CLOSE). A proper control system (PI or PID controller) should gradually open or close the valve as the actual temperature approaches the target temperature. Since the number of steps required to open or close the valve is known, I don’t understand why such a controller hasn’t been implemented. I assume it’s not due to a lack of computing power. This feature would increase comfort and reduce heating costs. The point about setting the maximum/minimum valve opening in percentages shows me that you have the capability to achieve this.
Support setting external sensor, allowing SNZB-02, SNZB-02D, and SNZB-02P to be used as a reference temperature for the TRVZB.
*Currently only supported when added to ZBBridge-P.
I understand that it is currently only supported when using a ZBBridge-P, but under the hood does the temperature sensor report the temperature directly to the TRV, or do they communicate through the bridge? I’m asking this because I’m curious about the robustness of this solution. What happens when the bridge is offline for some reason?
If you stick a debug node in Node Red connected to a temperature sensor I’m not sure it updates often enough either. Aswell as the route I’d be keen to know if the temperature sensor update frequency is changed and if it is what the effect on battery life is. Also presumably the TRV has to use energy to connect to any Zigbee Network itself and so I would expect a reduced battery life.
In Zigbee you can directly connect one device to another, so for example a Zigbee light switch can be connected to a Zigbee Light Bulb with a reduced latency. I forget what it is called. Don’t know if the coordinator needs to be alive. I don’t think so but am not sure. There is a tab for that in Zigbee2MQTT. I don’t know if it’s possible for them to be using that. It is possible they are.
I’m not sure it updates often enough either
Zigbee temperature sensors which follow the ZCL standard report their measurement periodically AND when the value changes by a configured amount. You’ll see if you check out the Reporting tab in Zigbee2MQTT for a temperature sensor.
In Zigbee you can directly connect one device to another
Yes, and it’s called binding. 
I know the Zigbee T&H sensor will update more often if temperature changes but I don’t think that setting exists for the iHost. I’m not sure the default amount is often enough to operate a radiator. The fact it exists in Zigbee2MQTT means they could theoretically add the ability though, so maybe it could be suggested to them… If you connect a T&H sensor to the iHost, stick a node Red debug node behind it and watch the output it doesn’t seem often enough, maybe behind the scenes if a T&H system is running the radiator they make it more sensitive already… who knows. I think superficially the idea of using a separate sensor is nice but not convinced the reality is so good. I’ve found big improvements where I’ve turned the cal a horizontal from vertical although in some places I’ve not been able to do this and maybe the new method will be helpful.
I currently use Zigbee2MQTT for my zigbee setup. I have Sonoff TRVZB and their T&H sensors for all rooms that have TRVs.
At the moment I use a blueprint within HA to adjust the calibration offset of the TRV to match the T&H sensor. This of course has a reliant on HA being up and running. Would be great to get this natively built into Z2M or the TRV firmware itself.
Also will v1.2.1 be pushed for Z2M users to do OTA updates? We’re currently still on v1.1.5
I agree it would be great if the TRVZB could do this standalone!
I saw a PR where 1.2.1 is added to Z2M’s OTA repository, so it will be available in the next Z2M release, or on the dev branch soon after the PR is merged.
The firmware does not inform via Zigbee when an error occurs. This could be done, for example, with an additional value for the entity “running_state” = “error”.