Hi Simon,
Wow - big thanks for your speedy response and the pointers! @sburke781
That is what strikes me - the controlled TRV device does not log any activity at the time that I manipulate the TC Heating Setpoint.
Here is the log of the Thermostat Controller at that time, but NO log of the controlled TRV - so I think the method setHeatingSetpoint has never been called:
app:2392023-10-24 18:47:55.390infohallway radiator setting to idle by setpoint below temperature
app:2392023-10-24 18:47:54.428infoHeating Setpoint for thermController-hallway-radiator: 12.0 from Manual
app:2392023-10-24 18:47:54.345infoController: updateSetPoints(12.0, -)
app:2392023-10-24 18:47:54.338infoController: setHeatingSetpoint(12.0) was called
But when I manually enter heating setpoint on the TRVs own device page, the setHeatingSetpoint method has been called and I see a nice informative log from Jonathan's driver:
dev:4912023-10-24 18:45:00.139debugParse returned [name:heatingSetpoint, value:20.0, unit:Ā°C, descriptionText:eTRV Heating Setpoint]
dev:4912023-10-24 18:45:00.135debugParsing read attr - Desc Map: [raw:3DDF0102010C120029D007, dni:3DDF, endpoint:01, cluster:0201, size:0C, attrId:0012, encoding:29, command:01, value:D007]
dev:4912023-10-24 18:45:00.131debugParse description read attr - raw: 3DDF0102010C120029D007, dni: 3DDF, endpoint: 01, cluster: 0201, size: 0C, attrId: 0012, encoding: 29, command: 01, value: D007
dev:4912023-10-24 18:45:00.117debugParse returned [name:heatingSetpoint, value:20.0, unit:Ā°C, descriptionText:eTRV Heating Setpoint]
dev:4912023-10-24 18:45:00.112debugParsing read attr - Desc Map: [raw:3DDF01020112120029D00730003002, dni:3DDF, endpoint:01, cluster:0201, size:12, attrId:0012, encoding:29, command:0A, value:D00730003002]
dev:4912023-10-24 18:45:00.109debugParse description read attr - raw: 3DDF01020112120029D00730003002, dni: 3DDF, endpoint: 01, cluster: 0201, size: 12, attrId: 0012, encoding: 29, command: 0A, value: D00730003002
dev:4912023-10-24 18:45:00.097debugParsing catchall - Desc Map: [catchall:0104 0201 01 01 0040 00 3DDF 00 01 1246 0B 01 4000]
dev:4912023-10-24 18:45:00.094debugParse description catchall: 0104 0201 01 01 0040 00 3DDF 00 01 1246 0B 01 4000
Funnily enough, the Thermostat Scheduler CAN manipulate the heatingSetpoint of this TRV - here is the log of the Thermostat Scheduler
app:2422023-10-24 19:03:00.363infoHeating Setpoint 18.0 from Time Schedule
and the subsequent log on the TRV
dev:4912023-10-24 19:03:02.527debugParse returned [name:heatingSetpoint, value:18.0, unit:Ā°C, descriptionText:eTRV Heating Setpoint]
dev:4912023-10-24 19:03:02.520debugParsing read attr - Desc Map: [raw:3DDF0102010C1200290807, dni:3DDF, endpoint:01, cluster:0201, size:0C, attrId:0012, encoding:29, command:01, value:0807]
dev:4912023-10-24 19:03:02.517debugParse description read attr - raw: 3DDF0102010C1200290807, dni: 3DDF, endpoint: 01, cluster: 0201, size: 0C, attrId: 0012, encoding: 29, command: 01, value: 0807
dev:4912023-10-24 19:03:01.995debugParse returned [name:heatingSetpoint, value:18.0, unit:Ā°C, descriptionText:eTRV Heating Setpoint]
dev:4912023-10-24 19:03:01.991debugParsing read attr - Desc Map: [raw:3DDF01020112120029080730003002, dni:3DDF, endpoint:01, cluster:0201, size:12, attrId:0012, encoding:29, command:0A, value:080730003002]
dev:4912023-10-24 19:03:01.988debugParse description read attr - raw: 3DDF01020112120029080730003002, dni: 3DDF, endpoint: 01, cluster: 0201, size: 12, attrId: 0012, encoding: 29, command: 0A, value: 080730003002
dev:4912023-10-24 19:03:01.969debugParsing catchall - Desc Map: [catchall:0104 0201 01 01 0040 00 3DDF 00 01 1246 0B 01 4000]
dev:4912023-10-24 19:03:01.966debugParse description catchall: 0104 0201 01 01 0040 00 3DDF 00 01 1246 0B 01 4000
dev:4912023-10-24 19:03:00.356debug asked to set and read heatingSetpoint - my command is: [he cmd 0x3DDF 0x01 0x0201 0x40 {00 0807} {1246}, delay 2000, he raw 0x3DDF 1 0x01 0x0201 {10 00 00 12 00}, delay 2000]
dev:4912023-10-24 19:03:00.351debugmy payload is: 00 0807
dev:4912023-10-24 19:03:00.343infosetHeatingSetpoint 18 celsius; command speed : 00
dev:4912023-10-24 19:03:00.339debugabout to set degrees as: 18.0
Do you happen to see anything obvious?
Is there a difference in the way that the TC calls the setHeatingSetpoint of the TRV as opposed to how the Thermostat Scheduler does it?
Once again - much appreciate your help!
Thanks - re setSupportedThermostatModes .... I will think about that later ... you have probably identifies the issue...
Refer to this post :
Krassimir - that's it! Genius! It works like a charm!
I can now confirm that TC can now control the the Danfoss Ally/Popp/Hive Zigbee TRVs!!
Big thanks to Krassimir, Simon, but especially to Jonathan for all the work on this great driver!
@kkossev @sburke781 @user3101
I added these two lines to the initialize method, then hit Initialize on the device page of each TRV and that fixed it.
sendEvent(name: "supportedThermostatModes", value: ["auto", "cool", "emergency heat", "heat", "off"]) //MMA
sendEvent(name: "supportedThermostatFanModes", value: ["auto","circulate","on"]) //MMA
So the complete initialize method looks like this:
def initialize(){
sendEvent(name: "thermostatFanMode", value: "auto", descriptionText: "Only has no fan")
sendEvent(name: "thermostatMode", value: "heat", descriptionText: "Only has heat mode")
sendEvent(name: "thermostatOperatingState", value: "idle", descriptionText: "for dashboard thermostat tile colour only")
sendEvent(name: "supportedThermostatModes", value: ["auto", "cool", "emergency heat", "heat", "off"]) //MMA
sendEvent(name: "supportedThermostatFanModes", value: ["auto","circulate","on"]) //MMA
def initializeCommands = []
initializeCommands += readBaiscClusterAttributes() // Basic Cluster
// initializeCommands += readTimeClusterAttributes() // Time Cluster
// initializeCommands += readOTAClusterAttributes() // OTA Cluster
// initializeCommands += readPollingControlClusterAttributes() // PollingControlCluster
if (debugLogging) log.debug "initializeCommands(): $initializeCommands"
state.driverInitializedDateTime = new Date().format("dd/MMM/yyyy HH:mm:ss")
if (infoLogging) log.info "JellyGreen's driver for ${device.displayName} initialized"
return delayBetween(initializeCommands,200)
}
@user3101
Jonathan - would you like to add that to your planned changes for the future releases? Thanks again!
Jonathan - may I ask what settings do you use on your TRVs for the eTRVAggressionFactor and eTRVFastResponse?
Any other suggestions on going about other features of this TRV - like Adaptation Run and such? Any best practice you want to share?
I agree it works. I am happy to amend and post in github in due course. What I am not sure about is why it works. I need to think abut that more. Also on "supportedThermostatModes, the TRV only supports heat - I have a slight quarm about adding the full code when it does not do auto, cool. emergency heat etc. ditto supportedFanModes, when it has no supported fan modes. But I guess I just have to get over that!!!
Anyway thank you all.Mark, Simon and Krassimir.
You can experiment leaving just āheatā in the suportedThermostatModes .
I do generally use the FastResponse setting - the valves seemed to take an age to respond otherwise - so esp in main living rooms where I want heat asap if I am cold I use it; less so in bedrooms, where as long as they are ready for bedtime it doesn't matter. Looking at my set up I have a random selection of AggressionFactor 1 and 2. That was trial and error and very subjective, 1 probably overshoots more.
Adaption Run - I ran manually a few times but now just leave it in auto. It seems to work OK and generally stays found. (I had an issue with one very old radiator value with a sticky pin (but that was not the TRV's fault).
So until the last week (when I had to change a hub) I hadn't thought about the TRVs or the driver for quite a few months.
This is very helpful, Jonathan.
Oh - ouch - what happened to your hub?
So AggressionFactor 1 is more aggressive than 2 huh? I thought first that 10 would be the most aggressive....
It feels like my radiators heat up faster on AggressionFactor 1, but do overshoot and 2 seems like they heat up the room too slow, but I need to test it more to be sure.
I am not sure I understand fully how the CallingForHeat attribute works in the TRV. I saw yoir workaround for the "idle" status of the thermostat reflecting the CallingForHeat and the PIHeatingDemand - and that does a good job. But sometimes I have a radiator asking for heat even though the setpoint has been turned down hours ago - see example- current temp is 21.6, setpoint has been 15 for 5 hours or so.
Is it possible that CallingForHeat attribute is called also during Adaptation run and for some time after - and also for some prolonged time after each heating period?
I would like to use the CallingForHeat attribute of the collective of all TRVs to makte a rule to decide whether to turn on the central heating unit and make heat available to the radiators.
Thanks and good luck!
The Spec regarding "Control algorithm scale factor" (my Aggression factor and Fast response) reads:
"Range 1-10 (lower 4 bit allocated to scale factor) Scale factor of setpoint filter timeconstant ("aggressiveness" of control algorithm) 1=5min(Quick) ... 5=30min(Moderate) ... 10=80min(Slow). Bit4=Quick open feature disable. 1=disable. 0=enable
CallingForHeat (in the Spec:Heat Supply Request): Most of my valves do toggle this when I expect, but sometimes this attribute does seem to get stuck - (which can be frustrating) - I had not linked this in my mind to Adaption Run; and I have one valve that sometimes continues to call for heat when it should not despite its adaption run status being found.
So to turn my boiler on and off I use rule machine apps to combine info from CallingForHeat and PIHeatingDemand. This seems to provide a reliable answer to whether the boiler should turn on or turn off. This is belt and braces because most of the time CallingForHeat changes no when I would expect and the PIHeatDemand plummets soon after. But it does give me some piece of mind.
I have read once (about the Hive valves - all but identical) that when first installed they do a very long adaption run (several hours), but I did not observe this and have no idea if CallingForHeat is affected if this takes place.
Well, I'm excited. Sad but true. Winter is here and I'm still messing about with Danfoss and one of those inexpensive Tuya TRV's that I never got working. Then I found this. I happen to have a handful of Hive TRV's in the garage that I'll be finding very quickly. What a result.
I was initially confused about wether or not the supportedThermostatModes had been added to the driver mentioned here and checking the GitHub comments show me they have. v2.8 here I come. To those of you working to get this together, huge thanks!!!!
Working well. Thanks again.
Quick question. As an ActionTiles user I'd like to set the thermostat mode to be off when the 'off' switch is used (and on when the on switch is used).
This would automatically change the tile colour in AT. Any quick pointers on how that might be possible?
Off is not as easy as you might hope. There is no off setting, you just choose a low setpoint. The TRV only has one mode, heat.
So what do you want to achieve? The driver could be edited to pretend the TRV is off, when the setpoint is a particular value....
I am mapping some other TRVs 'anti-freeze mode' to Hubitat thermostatMode 'off'.
The anti-freeze mode typically sets the heatingSetpoint to 5 or 7 degrees C, some TRVs even display 'OFF' on the LCD screen.
@user3101 If I change the Set Temp from the JE device page, my Danfoss shows the selected temperature on the Danfoss device display but I donāt hear the TRV working.
If I the turn the TRV half a degree can hear the āmotorā working.
Itās like the temperature is set from the HE on the Danfoss but the Danfoss doesnāt get the go signal.
Any idea what Iām doing wrong?
Set eTRVFastResponse to yes and eTRVAggessioFactor to 1.
That should speed it up.
Or just wait a while, five minutes or so, they seem to think for ages....
