I have been really please. But I have two gripes. First, telling them to control the room temperature via the External Sensor Thermometer setting was not successful - there is chatter on the internet about this being a software glitch. But they do work well using their own internal sensor (surprisingly sensitive to vertical or horizontal orientation setting). Second, you may want to play about with the Fast Response Setting and the Aggression Factor setting.
The POP valve (I have three) is the same as a Hive one (I have five), which is much cheaper, if still available.
Give one a try and see what you think ....
Hi @user3101 /JellyGreen,
Big thanks for implementing this amazing driver - the features are well thought out and reflecting all capabilities of the device - awesome! This would make my smart home complete - if it worked fully.
I have found to have 2 major problems with this driver:
- I find it impossible to install the drivers on one of my POPP Zigbee TRVs - in fact - I cannot even pair the device for as long as your driver is installed. After pairing the TRV seems to be crashing and going back to the maintenance mode. If I remove the driver code, then I can pair the TRV and get it installed as a generic Device and then change to built-in LUX Zigbee Thermostat driver - then it works again.
- for another device that I did manage to install the driver on and make it work, I get all the readings and very useful event logging and can manipulate the setpoint via the device page and dashboard - all seems to work great - EXCEPT I cannot manipulate the heating setpoint via the Thermostat Controller 2.0 app. The changes of the Thermostat Controller that should be controlling the TRV, have no effect on the TRV's setpoint with this driver.
Thermostat Scheduler works ok if I control the TRV device directly there and not via the Thermostat Controller. But that beats the purpose of the TC - as a composite device that controls several radiators based on an external temperature reading.
Could you think of anything that I could do to fix these two issues?
Again - much appreciate your hard work on this driver - I am at awe thinking of how much work must that have been.
Regards,
Mark
@user3101
I seem to have resolved the problem with not being able to install the devices with your driver on. Yesterday I was struggling with it all day, today I tried again from scratch and it worked. Not sure what I did differently.
I still cannot control the TRVs via the Thermostat Controller. I can manipulate the heating setpoint on the device UI page, dashboard and via the Thermostat Scheduler - but not via TC.
Hi Mark,
Thanks for your message.
On point 1, I have not experienced any such problems and wonder whether you have an different release of the POPP valve. My only thought on this is whether you could resolve it by 'commenting out' the footprint line in the driver (add // at the start of the line). I can't see what else could link the driver to the hub during pairing. I was unaware of any maintenance mode on the TRVs, I have not met that.
On Point 2: I have eight of these rebadged Danfoss TRVs. Three are POPP and five are Hive. All work every day with the Thermostat Controller app. So I don't think this is a driver issue. (Is the Thermostat Controller set on Hold? Does it link to the TRV and set the heating set point when you press the 'Set Scheduled Temperature' button? I will screen shot one of my Thermostat Controller implementations...... What version of the driver are you using? I think the latest is 2.7. In the very early version I did not implement the Thermostat capability, but I added this pretty early on with version 2.0.
image|690x431
It does also work using variables for the temperatures.
Let me know how you get on ...
Jonathan
Hi Jonathan,
The installation/pairing issue seems resolved. I will install on all my other TRVs today and let you know if I run into it again. Thanks for the tip about commenting out that one line - I will try it if I hit that problem again.
Regarding not being able to control the TRVs via Thermostat Controller:
Your screenshots are from the Thermostat Scheduler - not the Thermostat Controller.
Thermostat Schedular works great - nothing wrong with that.
But I cannot make it work in the Thermostat Controller 2.0 app.
I use that functionality to create a virtual master thermostat for each room to control multiple radiators via a single dashboard tile. I have been able to control my POPP TRVs through that app with LUX Zigbee Thermostat driver (though that one only partially implements the features of this TRV and has many other quirks).
Any ideas why that would be?
Once again - big thanks for the work on this driver and for your speedy response!
Regards,
Mark
Ah, I should have read more closely ...
I have not used the Thermostat Controller App (my rooms are not big enough to have two radiators Haha).
However I have just implemented the Thermostat Controller on one of my TRVs.
It does seems to work! Screen Shot below (perhaps not reliably)
It seems that sometime there is a need to refresh the Thermostat Controller page, to see the latest Current States in the Thermostat Controller page; other times no refresh required.
The POPP TRVs can only Heat... They will not let the heatingSetpoint exceed the eTRVMaxHeatSetpointLimit ... nor the heatingSetpoint be lower than the eTRVMinHeatSetpointLimit ...
So when I force the temperature to reduce (here to 12) in the Thermostat Controller, the TRV heatingSetpoint changes (to 12) but the box in the Thermostat Controller Heat still reports the old value (here 23)!.... This updates if you try changing it again or if you toggle controlled to free and back again....
So I think the Thermostat Controller is reading the heatingSetpoint too quickly for the TRV to have updated to the new heatingSetpoint ...
Nothing I can do about that ...
Do let me know if you have other thoughts.
Hi Jonathan,
Thanks for looking into it and for sharing the screens, but I am still not convinced it actually works in your scenario as intended.
Sorry for the long story below - I am trying to provide you with all the relevant info here so we can come to the bottom of it.
First - I know the Thermostat Controller page does not update the Controlled Thermostats section after you changed the heating Setpoint - that you have to refresh that page manually. But that is just a cosmetic issue. I am monitoring the actual setpoint on the TRV's own page.
But I think the screenshots that you sent me do not actually show it working.
Is it possible that you were increasing and decreasing directly the heating setpoint of the "Study TRV" (via your 2nd row middle dashboard tile) and not the actual Heating Setpoint of the Thermostat Controller (as seen on your first screenshot, middle screen left bottom)?
How Thermostat Controller (TC) is intended to work is that you link the radiators ("slaves") to the TC ("master") and from then on you only change the central Heating Setpoint of the TC (TC page - section Controlling Thermostat/Heating Setpoint) and not the TRVs (Controlled Thermostats) - TRVs setpoints get automatically populated by the TC once you lock them as Controlled on the TC's page.
Also - there is more logic behind it then simply copying the setpoint of the TC onto the TRVs. See the Control Offset (default 2.0 degrees - also visible on your first screenshot).
When you change the TC Heating Setpoint to 23, TC sees that it needs to heat the room and sets the TRVs to 23 + 2 (control offset) = 25 degrees. When you went down to 12 degrees, the TC should have set your Study TRV to 12 - 2 (control offset) = 9 degrees.
Your test results would only make sense if your Control Offset was set to 0.0 and that does not seem to be the case.
On your first screenshot the TC Heating Setpoint is 20.0. The Study TRV heatingSetpoint is 23.0 - matching your dashboard and the Controlled Thermostat section. Hence - the TC Heating Setpoint had no impact on the TRV setpoint - it is not in control. It seems you only manipulated TRV setpoint directly.
On your second screenshot I cannot see the TC Heating Setpoint (cropped), but I assume it was also unchanged - 20.0 degrees. I see that you have changed the TRV setpoint via the dashboard to 12.0 and it has correctly updated on the Study TRV page - and after a refresh - also on the TC page/Controlled Thermostats. However - that has nothing to do with TC's main functionality - to automate the setpoints of the "slave" TRVs based on the "master" TC (Controlling Thermostat) Heating Setpoint.
You can see how that logic works on your virtual thermostat that you also added to the TC, but left it "free". If you lock it "Controlled" and manipulate the TC's own Heating Setpoint below under Controlling Thermostat, you will see that the virtual radiator will react and the physical Study TRV will not (not even after a delayed page refresh).
There is a much better explanation on how TC works on it's documentation page - here.
@user3101
But I suspect there is still some capability missing from your driver, Jonathan, that the Thermostat Controller needs in order to write the heatingSetpoint to it. Perhaps one of the things you commented out or just added pro-forma as required, but assumed they are not used?
@kkossev @sburke781
Simon and Krassimir - could we bother you with this for a moment? Jonathan has put together a very complete and thorough driver for these common zigbee TRVs (Danfoss/Popp/Hive). The only rub is that we cannot manipulate the heatingSetpoint of the TRVs on this driver via the Thermostat Controller. No useful hints in the logs either.
When you look at Jonathan's driver code - could you maybe see what capability is missing in the driver that TC needs to be able to automate TRV setpoints?
Here is Jonathan's driver code:
The only workaround I found for the time being is to add a dummy virtual TRV to each room's TC alongside the controlled physical TRVs and then create a rule to copy the heatingSetpoint from the dummy TRV to the physical TRVs whenever it changes. This works, but is ugly seems like a lot of clutter that is more difficult to support.
Big thanks to you all!
Regards,
Mark
The inclusion of the Thermostat capability and the setHeatingSetpoint method (command) are what I expect are needed, however, from what I can see, the setHeatingSetpoint method does not update the heating set point attribute on the device. Not sure if this is part of the issue.
I also notice there is some logic to make sure the set point is within the right range. Perhaps try turning on info logging and seeing what comes out when you try to change the set point.
I was changing the heating set point in TC Controlled Thermostats box, and watching it change about a second later on the TRV device Current States and on the dashboard. Then I would hear the TRV changing its set point. So there is a working link.
I agree agree that I have been unable to change the heating set point in TC Controlled Thermostats box using the heating setpoint in the Controlling Thermostat box. I have now achieved this with the virtual thermostat ... I am not sure that this is a driver issue ... it may be but I am not sure what commands TC is trying to send to the TRV...
I also agree that the TC does not add or subtract the TC Control Offset ... , I am not sure that it should ... but TC is not changing the controlled heating set point at all ... I have never needed to use TC and I am not familiar with it, despite reading the Hubitat info page.
These TRVs only have a Heat mode, - my driver manufactures an artificial Idle Operating State (around line 750 if I remember) when it is not calling for heat and HeatingDemand is minimal - this was to make my dashboard go red when heating and grey when not.
I suspect that I cannot help any further and that you may have reached the limit of the control that is possible on these TRVs or, at least, the limit of my understanding. The whole zigbee spec for these TRVs is online so from that you may determine whether there is any way for you to move forward...
Good luck ...
Jonathan
@MarkM - The logging is quite good in the driver, so my suggestion would be to turn on info logging and see what comes out when you perform the various actions you are trying. I haven't done anything with zigbee stuff myself, so not sure if some of the commands do the work of setting the Current State Attributes, which is why some of the logging outputs would likely help. Looking at the logs alongside the devices Events will likely help as well.
Hi Jonathan,
Hang in there just a bit longer if you can, please - I think we are very close to finding where the problem is. I am so sorry to bother you with all this, but it seems to me you have done so much amazing work on this driver - it would be a real shame if we could not use the driver to its full potential together with the smart automation capabilities of HE Thermostat Controller.
Thermostat Controller is just such useful capability of Hubitat - I think other users will be asking about that in future too - I just wish I was more technically capable myself to help with the code...
But with Simon's pointers - I think we can get very far quickly - he is the thermostat guru here.
Yes - but that section of the TC page (Controlled Thermostats) works like a remote view and manual setting of the actual TRV setpoints directly - that section shows only the subjects of the TC's control - the slaves. And yes - you can directly change their setpoints there manually, but that does not prove there is a working link between the TC master setpoint and the physical TRV setpoints being controlled. The master setpoint fields for automation are further below - in the Controlling Thermostat section.
That's the point - TC does not change the controlled TRVs' heatingSetpoint at all. Like Simon mentioned above - it might have something to do with how the setHeatingSetpoint method is implemented in your driver. Did you use any other thermostat drivers as reference when building this one? I am not a coder and rewriting code on my own is beyond my skills, but I could help you compare with other implementations.
I saw that - quite clever. It does not impact the behavior we are talking about here though - I commented it out and TC behaves the same.
I don't believe that - you have already implemented all there is to implement on these. Now it comes down to only find a quirk in how you have done it as opposed to how other standard drivers are implemented - it is probably a very small detail.
Could you please please have another look and maybe spar with Simon here? He knows the Thermostat Controller inside out... Anything I can do to help you gather more data or any other way how I can help?
I don't see the supportedThermostatModes JSON in the "POPP, Danfoss, Hive TRV Zigbee Driver v2.7" driver ...
This is a screenshot of my Tuya thermostats driver:
Three log screenshots to follow.
First screenshot is the log generated by manually changing the HeatingSepoint in the controlled thermostat box for Study TRV. dev:41 is the Study TRV and the zigbee command is sent and changes the TRV HeatingSetpoint.
This second screenshot is the log generated when the TC Controlling HeatingSetpoint is changed manually to 21oC. I note that no log from dev 41. but the TC app (app:269) tries to set the Study TRV to idle (may be an issue here, because the only option in the TRV is Heat).
This is the log generated on the same basis when the set point is reduced to 12oC. Again Study TRV is being set to idle but the virtual TRV set points are being changed too.