POPP TRV 701721 / Danfoss Ally (zigbee) Driver

🚧 Developers Code Share
66

Yes, that worked. Thanks for the pointer.

I'll give you guys a quick write-up of ActionTiles in a moment. In the meantime is there a way to store an on and off temperature? So the TRV jumps to those temps when the on and off actions are initiated? edit: I can see the off switch reverts to the minimum set value.

I have a use case where I have a less frequently used room that has a rad in it. That rad sits on the same heating zone as then rest of the house. So I'd like to be able to say turn the rad on for the weekend but leave off during the week. Doing that via an on/off switch would be amazing.

Thanks again, seriously appreciate the effort here :slight_smile:

67

One more ask.

Does it make sense to make the thermostatOperatingState state follow the eTRVCallingForHeat state.

If there is anyway to make:

eTRVCallingForHeat: yes = ThermostatOperatingState: heating
and
eTRVCallingForHeat: no = ThermostatOperatingState: idle

edit. I can see the ThermostatOperatingState changing so something is updating it, trying to figure that out.

In addition call you also store the last on/off setting in the state variables?

Then I would be a very happy man!

1 Like
68

That is good to hear.
You could use Hub variables and / or use the Hubitat Thermostat Scheduler app. Thats what I do. When you want to reassert the scheduled temperature you can just use the Set Scheduled Temperatures command to revert to the temperature you want for the time of day. You may need to take the scheduler on and off hold / scheduled too so that the schedule does not override any manual temperatures setting that you want to take priority.

Does it make sense to make the thermostatOperatingState state follow the eTRVCallingForHeat state? It would but the TRVs seems to get stuck calling for heat sometimes combining the two in some fashion has made things more reliable for me.

69

Can you you also store the last on/off setting in the state variables? Possibly but I would keep things simple and use a hub variable if you need to do this (or the Thermostat Scheduler)

70

I have tried different ways of combining Calling for Heat and PIHeatingHeatingDemand. If you want to play about in the driver rather than in an app you need lines 763 to about 775 of the driver code.

71

OK. All good. I can use something else to update the ThermostatOperatingState.

Thanks for the pointer will have a look.

Quick few notes on ActionTiles. Allows me to create a dashboard that I can then display on a tablet (cheap Amazon Fire Tablet). Gives me the ability to do this sort of stuff:

image
image1330×775 94.6 KB

For a thermostat the tile changes status as the ThermostatOperatingState changes. So this:

image

Becomes this when the TRV is actually heating:

image

Nice and visual way of seeing what is going on. Useful in my use case anyway.

1 Like
72

Nice. Not much different to mine...
image
I don't show Off or Heat Mode. As I said before if I turn the TRV off the tiles goes blank

73

Excellent. The real bonus for here is the switch function. Let me have a play and I'll feedback. Thanks again. These are the nice to haves. The fact I have a responsive TRV is awesome, great work on the driver!

1 Like
74

@user3101 I've reverted the driver to the 2.8 version based on the following.

The ThermostatOperatingState does update currently. When you move the TRV set point above the current temp it takes approx 5 mins for the ThermostatOperatingState to change to 'heating'. When you drop the TRV below the current temp the ThermostatOperatingState changes to 'idle' after about a minute. So, all working as expected, just some delay on the status update.

Looks like this is the code in question that does that (line 755):

        if ((device.currentValue("eTRVCallingForHeat") == "yes") && (device.currentValue("eTRVPIHeatingDemand") > 0))
             {
               sendEvent(name: "thermostatMode", value: "heat", descriptionText: "for dashboard thermostat tile wording only ")     // ["auto", "off", "heat", "emergency heat", "cool"]
               sendEvent(name: "thermostatOperatingState", value: "heating", descriptionText: "for dashboard thermostat tile colour only ")  //  ["heating", "pending cool", "pending heat", "vent economizer", "idle", "cooling", "fan only"]
             }
        else {
               sendEvent(name: "thermostatMode", value: "heat", descriptionText: "for dashboard thermostat tile wording only")       // ["auto", "off", "heat", "emergency heat", "cool"]
               sendEvent(name: "thermostatOperatingState", value: "idle", descriptionText: "for dashboard thermostat tile colour only")      //  ["heating", "pending cool", "pending heat", "vent economizer", "idle", "cooling", "fan only"]
             }

With this in mind I can achieve my switch capability by simply creating a virtual switch and then putting a simple bit of logic behind it.

When switch changes to On then set change heating set point to x
When switch changes to Off then set change heating set point to y

So, all good.

75

That is how I have been operating for a while, but perhaps not as impatient as you, especially with one valve that sit calling for heat for a very long time before changing when it should, hence use PIDemand too. I am now using version 3.0
Anyway, hope all works for you now.
Jonathan

1 Like
76

If 3.0 is good enough for you and not just a trial change for me the I’ll go with that too. :joy:

Thanks jonathon. :+1:

77

Not wanting to raise matters again, but screenshot below shows a valve still calling for heat, despite PIHeating being 0. Can sit like this for a long time, hence a blending to define idle or heating.

image
image150×778 11.3 KB

78

Can I ask why you are use the eTRVPIHeatingDemand state (as well as eTRVCallingForHeat) to determine the thermostatOperatingState? My understanding is that this when the TRV is deployed using Hive this setting allows the TRV to turn on the boiler switch, so that the TRV can call for heat regardless of the Hive Thermostat state (boiler will produce heat even if the the room Thermostat is off). Are the TRV's not completely independent of the stat and boiler switch when deployed using Habitat (because the TRV won't know which Stat they might be paired with in a multi-zone set-up? Or am I missing something?

In my use case I simply want to know if the TRV has opened, which would be determined by the eTRVCallingForHeat state, would it not?

I think I might be missing something Jonathon? If not I might play with the code and change this:

   if ((device.currentValue("eTRVCallingForHeat") == "yes") && (device.currentValue("eTRVPIHeatingDemand") > 0))
         {
           sendEvent(name: "thermostatMode", value: "heat", descriptionText: "for dashboard thermostat tile wording only ")     // ["auto", "off", "heat", "emergency heat", "cool"]
           sendEvent(name: "thermostatOperatingState", value: "heating", descriptionText: "for dashboard thermostat tile colour only ")  //  ["heating", "pending cool", "pending heat", "vent economizer", "idle", "cooling", "fan only"]
         }
    else {
           sendEvent(name: "thermostatMode", value: "heat", descriptionText: "for dashboard thermostat tile wording only")       // ["auto", "off", "heat", "emergency heat", "cool"]
           sendEvent(name: "thermostatOperatingState", value: "idle", descriptionText: "for dashboard thermostat tile colour only")      //  ["heating", "pending cool", "pending heat", "vent economizer", "idle", "cooling", "fan only"]
         }

to this:

   if ((device.currentValue("eTRVCallingForHeat") == "yes"))
         {
           sendEvent(name: "thermostatMode", value: "heat", descriptionText: "for dashboard thermostat tile wording only ")     // ["auto", "off", "heat", "emergency heat", "cool"]
           sendEvent(name: "thermostatOperatingState", value: "heating", descriptionText: "for dashboard thermostat tile colour only ")  //  ["heating", "pending cool", "pending heat", "vent economizer", "idle", "cooling", "fan only"]
         }
    else {
           sendEvent(name: "thermostatMode", value: "heat", descriptionText: "for dashboard thermostat tile wording only")       // ["auto", "off", "heat", "emergency heat", "cool"]
           sendEvent(name: "thermostatOperatingState", value: "idle", descriptionText: "for dashboard thermostat tile colour only")      //  ["heating", "pending cool", "pending heat", "vent economizer", "idle", "cooling", "fan only"]
         }

Any thoughts?

edit: I think I see what you mean here. The eTRVCallingForHeat state seems a little unreliable as a why of determining if the eTRV is wanting to do something.

79

PIHeatingDemand is, I am prettry sure, an indication of how open the valve is on a scale of 0 to 100. I think you aree right that "calling for heat" was intended to switch your boiler.
BUT
When I started trying these valves and used "Calling for Heat" to control my boiler switch, I seemed to be getting quite a lot of time when the PIHeatingDemand was 0 and the "Calling for Heat" seems to get stick on 'yes'. For me that means that one radiator in the house was on (the bypass one, which is always on when central heating is on) and hot central heating water was flowing around the house). So I was getting many unnecessary and undesired hours of boiler being on.
So then I tried just using the PIHeatingDemand - so that that too could control when my boiler switched on / off. But that also had times when it would continue to have some demand when my rooms were well above their heatingsetpoint.
So, I tried combining the two. I do this in the driver, as you have seen, but I also do this in Apps and have tried different combinations.
None as simple as I would have liked - but, for me at least, I have got things to work well.
I agree your edit just uses calling for heat" to control idle / heating. If that works for you, then great.

80

Yes, interesting.

My intention here is to use the TRV as a dumb device. If I assume that it's working and reliable, then, if I set the heating set point at 22 and the temp is 10 is will open the valve producing heat, and vice in the opposite direction. So, therefore changing the code to this:

if (device.currentValue("thermostatMode") == "heat")
          {
            if (device.currentValue("heatingSetpoint") > device.currentValue("temperature"))
                //&& (device.currentValue("eTRVPIHeatingDemand") > 0))
             {
             sendEvent(name: "thermostatOperatingState", value: "heating", descriptionText: "for dashboard thermostat tile colour only ")  //  ["heating", "pending cool", "pending heat", "vent economizer", "idle", "cooling", "fan only"]
             }
           else 
             {
             sendEvent(name: "thermostatOperatingState", value: "idle", descriptionText: "for dashboard thermostat tile colour only")      //  ["heating", "pending cool", "pending heat", "vent economizer", "idle", "cooling", "fan only"]
             }
          }

Means that the thermostatOperatingState updates quickly and reliably.

It's a simple answer if you are willing to a) accept the TRV as a dumb device and b) that the TRV is reliable and does what it says on the tin.

The main point for me here is that I have a couple of rads on the primary heating zone, that are distant from the thermostat (which controls the hot water for the rads). And that I choose to heat a room based on other the rad is on/off. I'm not using them to call for heat. Selfish but should work I think.

81

A quick observation, might be of interest to @kkossev

I'm observing in both this use case and another that the Tuya Zigbee devices (in my case model: TS011F and TS0601) don't seem to be behaving well as repeaters. Neither the TRV or a Moes TS0222 seem to work or remain stable behind the Tuya device. I have since during testing put an Ikea Trader in as the repeater and it seems to be bullet proof.

Just an observation.

82

The only repeater I have is ab innr smart power outlet. That doesn't cause me any issues.

1 Like
83

The TS011F Tuya plugs are working very well as Zigbee repeaters (routers) in my environment (including Aqara devices), but everyone has difference experience.

image

If dedicated repeaters are needed to strengthen the Zigbee mesh, I can recommend the Tuya USB powered repeaters - these have very good performance and good feedback from many HE users:

2 Likes
84

@user3101 , Jonathan, thanks a lot for the driver. I appreciate the work you've put into it and find it very useful.

I'd like offer you a beer or two - do you have paypal?

Martin

85

That is very kind. You are welcome - gratis, I wrote it because I wanted these valves to work for me and I had not programmed anything for a long time (may be thirty years!), so I had a bit of catching up to do. I occasionally still tinker with the driver. Your message reminded me to upload the latest version to github. https://github.com/JellyGreen/Public-Hubitat-Code/blob/main/POPP%20TRV%20Trial%20Zigbee%20Driver%20v3.3

1 Like