We have moved at community.getvera.com

Author Topic: Alternative code for handling TRVs (StellaZ and Danfoss)  (Read 29735 times)

Offline dunked

  • Jr. Member
  • **
  • Posts: 88
  • Karma: +3/-0
Alternative code for handling TRVs (StellaZ and Danfoss)
« on: December 17, 2014, 07:30:27 am »
15 Feb 2015 - uploaded v1.5 - loads of changes. just upload this version and reload to install - existing settings should all still work
  • Will now reload quicker if it spots what looks like a stuck queue - this shouldn't cause any more reloads, just spots one that's needed a bit sooner.
  • Loads of changes to pre-emptive timers - now checks the last 5 actual wakeups of a device to guess when the next one will be, handles early or late wakeups better and a few other errors that sometimes crop up. Having said that wakeup catching is by far and away the best way to to. Reminder - setting TRV_timer_offset in the startup lua will turn on preemptive timers (i.e. trying to predict a wakeup in advance - sometimes handy if your vera is a bit slow), deleting or commenting out (--TRV_timer_offset) will use wakeup catching (i.e. when TRV wakes up we check what's needed and do it then)
  • loads more information in the logs
  • support for vera alerts - if you have that installed then when a reload happens you will get notified (with the reason) via that route as well as a log entry
  • More features added to TRV.set_tgt - it still has upto 4 parameters devid,tgt,boost,next_tgt
    • dev_id - the device id of the TRV
    • tgt       - what you want the TRV to be set to next time it wakes up - this can be a value e.g. 20 or a delta e.g. "+x" or "-x" the quotes are needed! this will set the target temp to x degrees above what it is now or x degrees below what it is now
    • boost  - how many minutes you want the TRV to be at this temp. Now has an option to start the boost only when the new setpoint has been accepted. You use a "+x" to set this. e.g. TRV.set_tgt(135,12,20) will set the TRV 135 to 12 degrees for 20 minutes starting from now (so if the TRV doesn't wakeup for another 5 minutes then there will only be 15 minutes left of the boost), whereas TRV.set_tgt(135,12,"+20") (don't forget those quotes they must be there if you use +) will set TRV 135 to 12 degrees starting from when the TRV wakes up and accepts the new SetPoint, so you will always get a 20 minute boost even if it doesn't start for 2 hours!... and in case you're wondering "-20" makes no sense!
    • next_tgt  - what you want the TRV to be set to when the boost ends - now you can miss this value off and it will put it back to what is was when you started
    The occasional use of quotes (") is a bit of a pain - if it's easier you can always use them but not on the device id so TRV.set_tgt(135,"25","10","5") is  fine
    a few examples
    • TRV.set_tgt(135,20) or TRV.set_tgt(135,"20") - set TRV 135 to 20 degrees
    • TRV.set_tgt(135,20,"+30") - boost TRV 135 to 20 degrees for 30 minutes and then put it back to what it is now - the boost will start when the TRV accepts the new temp
    • TRV.set_tgt(135,"-10","+60",5) - boost TRV 135 down by 10 degrees for 1 hour then set it to 5 degrees
  • TRV.setall takes the same parameters (without the device id) as TRV.set_tgt but sets all your TRVs so TRV.setall("+5","+30") will boost all your TRVs up by 5 degrees for 30 minutes.
  • TRV.list_settings(dev_id) - list the current settings (tgt,boost and next tgt) to the log, leave out dev_id (e.g. TRV.list_settings()   ) to list all your TRVs
  • TRV.list_wakeup_history(dev_id) - list the wakeup history (last 10 actual wakeup intervals) to the log, miss out dev_id to list them all TRV.list_wakeup_history()
That's a lot of changes so let me know if you get any problems.
I've tried everything I can think of to get this to work as well as possible (and spent more hours than is healthy staring at Vera logs!). I can't think of anything else I could do to improve it. My TRVs are working better than they ever have with this - though as I've said many times I keep my TRVs on a vera lite of their own. Which may sound expensive but I have 18 TRVs on my system and at ?50 or ?60 each that adds up to a lot, so getting a dedicated Vera lite to make sure they work well isn't a bad investment!

Good luck!
19 Jan 2015 - uploaded 1.4 - fix to a bug introduced in 1.3 (sorry) that caused reloads when using pre-emptive timers - just upload it to the vera and reload to install

16 Jan 2015 - just uploaded vsn 1.3 to the bottom of this post (deleted the older versions to save any confusion) - once again - just upload the new code and reload the vera.

3 Jan 2015 - I've just attached version 1.2 to this post. No major changes just a few bug fixes and some slightly better log messages - how long since last wakeup (very rarely matches the wakeupinterval exactly!) and how long between sending a Setpoint change and it being accepted (if it's more than a few seconds you'll be getting the retry problem!).

No special install instructions - just upload it to the vera and reload - all the existing settings still apply.

==========================================================================

I've had a few folk ask to try the code I developed to try and avoid the drastic slowdown created by the standard Vera way of handling TRVs. I'm finding it works really well (but no promises or liability). You will still get the occasional standard Vera slowdown, but more rarely. And I should point out that I have all my TRVs on a dedicated Vera Lite - that way the occasional slow-down doesn't affect the rest of my devices. I use this on UI5 I have not tried it on UI7 - I don't have that version.
.... and if you do get the mass slowdown just reload the Vera, that'll clear it (until it happens again!) or let the updated code do it for you.
The updated version (V1.1 - 19 Dec 2014) attached to this post has had a load of reliability improvements made to it, both to try and prevent the standard Vera slowdown (e.g. by never having more than 2 updates queued at any one time) and if the usual Vera snarl up (all those retries) happens it should spot it and sit back until it clears - if the problem doesn't go away then the Vera will be reloaded for you which will clear it (that option is disabled by default - but easy to turn on). The other big new feature is that by default it waits until TRVs wake up then changes the setpoint - if you have a lightly loaded or efficient Vera this is the most reliable option - which I use all the time (but remember I have my TRVs on a Vera of their own). But now you can also try a different approach - instead of waiting for a wakeup it will be predicted and the TRV SP change sent a few seconds before it's due to wakeup. So my advice is to try it with the default approach and if that doesn't work for you - i.e. you see too may retries then try the preemptive approach and see which is best. Though either way the new version will stop you having too many retries as it spots them and waits until they've cleared. I'll outline how to turn on / off the new features at the bottom of this post after the installation instruction.

To install and set it up
1). Download the my_TRV_module.lua file attached to this post
2). On the Vera UI go to APPS / Develop Apps - click the "Luup files" link, click the top Choose File button and select the file you just downloaded - double click it - back in the list of files check the "Restart Luup after upload" box and click GO. At this point the file is on the Vera but not being used
3). Click the "Edit Startup Lua" link and paste         require("my_TRV_module.lua")              into the code box on a line on it's own (don't change it - the first character is the r in require and it ends with the right bracket). Click Go, Close the next pop up box and click SAVE
Once reloaded the code is now active on the Vera (if you look in the log you'll see some messages when it starts-up - I use the Info Viewer App to view logs, it's great - you'll find it on the forum)
If for whatever reason you want to stop using this code edit the startup lua again and either delete the require line or add -- (dashdash) to the start of it (Vera will then ignore that line) and save again
4). So now the code is active but no TRVs are using it. If you're going to control a TRV using this technique then don't use another method at the same time - including clicking the + and - buttons in the standard Vera Web page - it'll still work but you'll be using the standard Vera method and bypassing this one. To use this method you need to use LUA scenes to run some code - it's easy, just copy and paste  as follows
5). Make sure you know what the device ids are for each of the TRVs you want to use this for (I'd suggest testing with one to start with to see how you get on). To get the device id for any device click the wrench icon on the device then click settings and you'll see the number near the top left e.g. you'll see Device #33 - the device no is 33 (which is my Study Radiator)
6) To setup and control a TRV using this you'll be getting very familiar with the following code snippet
TRV.set_tgt(dev_id,temp) - where dev_id is the device id and temp is the temperature you want to set it to - so to set my Study Radiator (device 33) to 20 degrees we write TRV.set_tgt(33,20) - the case is important so paste it as is - just change the 33 to whatever your device id is and the 20 to whatever temp you want to set it to.
7). So to create a Scene to set my study radiator to 20 degrees I do the following, Create a new scene "Study Rad to 20" - then click the LUUP tab at the top and in the Code box paste in the single line
TRV.set_tgt(33,20)
Then click "Save Lua" at the bottom - Confirm Changes and SAVE
so now you can run that scene in the same way you do any other, on a schedule, direct from the Vera UI or from a smartphone app like Imperihome on Android (which I use)
To turn the Rad off create another scene - e.g. "Study Rad off" and set the target temp to a low value e.g. TRV.set_tgt(33,5)
If you want to set several TRVS at once (though remember not too many) then create a scene such as "Warm bedrooms" and paste a TRV.set line in for each Rad you want, so in the Luup section for the scene you might have
TRV.set_tgt(10,18)
TRV.set_tgt(12,18)
TRV.set_tgt(13,18)

So that's setting 3 radiators (devices 10, 12 and 13 all to 18 degrees).
Remember when you run these scenes the effect isn't instant, the Temp Setpoint change will only take effect when the TRV next wakes up
If you look at the logs you'll see messages explaining what's going on when you set a target temp and when a TRV wakes up.
8). To stop using this technique for any individual  TRV and switch off all monitoring from my code for that TRV then set the target to -1 (minus one) e.g. TRV.set_tgt(33,-1) and reload the Vera - there's another back-out plan should something start going wrong - or we get better built-in code
9). Boosts - one of my most used features at home. The TRV.set_tgt routine can take 2 more parameters
TRV.set_tgt(dev_id,temp,boost_mins,next_temp) - which means set dev_id to temp for a number of minutes then set it to another temp, so to boost my study radiator for 30 minutes I create a scene "Boost Study Rad 30 mins" and in the Luup section I add
TRV.set_tgt(33,20,30,5)
which means set device 33 to 20 degrees when it next wakes up and after 30 minutes set it to 5 degrees

Hopefully that will get you going - I'll keep an eye out for any errors that people flag up - though I'll need to know what the log is saying to have any real chance of fixing anything. And remember if it all goes horribly wrong then just delete that "require" line from the Lua startup and this code won't run.

V1.1 changes
Several of the new features need to be turned on or set in the Lua startup box before the require line so paste these lines in and edit as needed - but the defaults all work so you don't need any unless you want to try them

reload_when_stuck = true
tells the code to reload the Vera if things start to look really bad (e.g. 10 minutes without a single SetPoint being accepted)
reload_when_stuck = false
will turn if off - or just delete the line - off is the default
SP_queue_limit = 2
how many queued Setpoints we will allow before waiting for some to clear, you can change to a number higher than 2 if you want - but 2 is best (trust me!)
unset_wakeup_limit = 3
if we send a SetPoint to a TRV and it wakes up 3 times without accepting (so we know the TRV is alive and talking) then we'll reload the Vera - if you have reload_when_stuck  = true
max_wait_time = 600
if 600 seconds has passed since the last successful SetPoint update then the queue is probably completely snarled so we reload the Vera (if reload_when_stuck  = true)
TRV_timer_offset=2
this tells the routine to use preemptive calls instead of watching for wakeups the offset is how many seconds before the next wakeup is due to try sending any SetPoint changes - 2 is the default but if you're using this option then experiment with different values until you find one that works for your Vera
Danfoss_timer_offset=10
if you're using Danfoss TRVs - which always seem to wake up at least 8 seconds early then set this value as well - experiment. So just to be clear Danfoss TRVs will use the Danfoss_timer_offset all other types will use the TRV_timer_offset value

so if you want to use all of those options your startup lua would look like
Code: [Select]
reload_when_stuck = true
SP_queue_limit = 2
unset_wakeup_limit = 3
max_wait_time = 600
TRV_timer_offset=2
Danfoss_timer_offset=10
require("my_TRV_module.lua")
« Last Edit: February 15, 2015, 03:38:04 pm by dunked »

Offline mikee123

  • Hero Member
  • *****
  • Posts: 1521
  • Karma: +18/-11
Re: Alternative code for handling TRVs (StellaZ and Danfoss)
« Reply #1 on: December 17, 2014, 07:47:20 am »
Great work. I have my TRV's set up to be changed with PLEG, where it waits for the next wakeup then sends the new setpoint (taken from another thread here). Is this just a simpler way of doing it or does that work different ? Pretty sure you have been on that thread too, I think we asked you there if you could post your code.

Offline dunked

  • Jr. Member
  • **
  • Posts: 88
  • Karma: +3/-0
Re: Alternative code for handling TRVs (StellaZ and Danfoss)
« Reply #2 on: December 17, 2014, 08:02:12 am »
It's a very similar technique - just with my code I think it's much simpler to use a standard call to a routine that will set temp and do boosts there is no need to set up any Variable containers or similar things. I've been running this with older lashed-up code for a year now with few problems.

I recently re-wrote the whole lot taking advantage of a technique that  @RichardTSchaefer  mentioned in another post - attaching your own variables to devices - which is standard and supported (i.e. not a lash-up).That made me much happier to share what I was doing.

If you want to run my code alongside your existing PLEG routines it should work, to compare and contrast - install my code as described -  it's only when you do a TRV.set_tgt that my code will start monitoring  a specified TRV (and setting the target temp to -1 will stop it monitoring it - after a reload). So as long as your PLEG routines aren't monitoring the same one you could have both techniques running.

Offline dmckenna

  • Full Member
  • ***
  • Posts: 196
  • Karma: +8/-2
Re: Alternative code for handling TRVs (StellaZ and Danfoss)
« Reply #3 on: December 17, 2014, 08:15:56 am »
Thanks Dunked, another TRV mash up. Will surely try yours shortly and report back results.

I'm going to give it a go on my main Vera lite on UI5, then also try it on a new Vera Edge - so long as Santa get's his order right with Vesternet.

Offline dunked

  • Jr. Member
  • **
  • Posts: 88
  • Karma: +3/-0
Re: Alternative code for handling TRVs (StellaZ and Danfoss)
« Reply #4 on: December 17, 2014, 08:20:44 am »
Let me know how (if) it works on UI7. I've not used that yet, and am quite nervous about doing so as I have tons of my own routines and code that may fall apart.

I'm quite nervous that one day I'll find my veras have all been upgraded when I wasn't looking!

Offline mikee123

  • Hero Member
  • *****
  • Posts: 1521
  • Karma: +18/-11
Re: Alternative code for handling TRVs (StellaZ and Danfoss)
« Reply #5 on: December 17, 2014, 08:33:07 am »
It'll be interesting to know how you get on with the Edge. I am considering getting one for testing, and to run my heating from it alongside my Vera 3 (on UI5). Now sure yet though of how these 2 could co exist and share devices etc. A lot to think about before I take the plunge.
But I think over xmas i'll have the time to play with @dunked's code. Looks good. just rewritten all my heating PLEG's to get rid of all my VC's, just finished the work today. With hindsight I should have waited for your code... never mind gives me something to do over the holidays I guess...

Offline dmckenna

  • Full Member
  • ***
  • Posts: 196
  • Karma: +8/-2
Re: Alternative code for handling TRVs (StellaZ and Danfoss)
« Reply #6 on: December 17, 2014, 08:41:06 am »
Sure will do re: Edge.

Personally I like the VCs for a few reasons -

a) I can see in one space what all the TRVs are set to - I don't have to scroll up/down etc
b) More importantly, I've got a routine in my PLEG that monitors 'external input' for example if someone changes a TRV using Imperihome, a phone, or even the UI using the standard TRV widget, then I capture that, modify the VC variable and let PLEG do the rest as normal. This way, we're always in sync.

@Dunked - I've had a quick look at your new LUA - it doesn't appear to do anything with polling/ GetCurrentTemp so I guess you're relying upon the regular Vera polling ? Like you say it's working for you, but I suspect that is purely to having this run on a separate Vera instance as opposed to your code doing something clever with ensuring the current temperature is being polled and stored. I'll install your code and give it a go with a few TRVs on my install and let you know


Offline mikee123

  • Hero Member
  • *****
  • Posts: 1521
  • Karma: +18/-11
Re: Alternative code for handling TRVs (StellaZ and Danfoss)
« Reply #7 on: December 17, 2014, 08:46:09 am »
That is the reason I liked the VC's. But I (and not just me) suspect the VC's can cause major problems. I have had problems with devices being very slow to react to commands, up to 30 seconds at times longer, even though they are right next to my Vera. Been told it could be the VC's, and MCV support told someone else to uninstall that plugin. So I took the time to rewrite everything. I now use multiswitches instead. Works as well, but it took a little work to rewrite and rethink my logic. I will now in a couple of days if it made any difference.

Offline dunked

  • Jr. Member
  • **
  • Posts: 88
  • Karma: +3/-0
Re: Alternative code for handling TRVs (StellaZ and Danfoss)
« Reply #8 on: December 17, 2014, 09:26:16 am »
I tend to use a web page that I wrote - with some LUA code behind it to see what my radiators are up to (screenshot attached). I will be rewriting this too when I get some time to work with my new TRV code.
I find it quite handy as it shows the current reported temp (except for Danfoss where it shows "?") the target set in my code, the current setpoint (which changes when the TRV accepts the change)  and how long until the next wakeup for the device - it refreshes every 10 seconds so you get a countdown to  a wake up.

I've actually got the vera itself serving the page (and a few others) but once again it involves some trickery that I'm not sure is standard. So when I've redone it I'll share it. The page looks big - but it's designed to fit best on a smartphone so imagine it on that. On this page you can touch the target and set temp and boosts from the page itself - one of the very few "apps" I've written that my wife actually uses!

Offline dmckenna

  • Full Member
  • ***
  • Posts: 196
  • Karma: +8/-2
Re: Alternative code for handling TRVs (StellaZ and Danfoss)
« Reply #9 on: December 17, 2014, 09:29:37 am »
Hi Dunked - thanks for sharing the code, however, I've tested and it's not working any better than the standard on a SINGLE UI5 Vera install.

Essentially your code tracks a new setpoint set by a scene, then waits for the device to wake up, then sends it. (along with some cool stuff like boost). The problem with this approach is that it is similar to the standard Vera code for setting setpoints ie, it wakes for a wakeup, then sends.  In a busy network, or even one that is not split into TWO Vera controllers as you have done, by the time the SEND gets through the device has fallen back asleep, or some other Z command has inserted itself into the ONE-ONLY Z wave transmission queue.

My results on my single install, using your code to change 1 TRV took three retries @ 4 min wakeup I'm sorry to report.

The code that Mikee and I enhanced on the other thread takes this into account and anticipates the wake up several seconds before it really does wake up, then it sends in ADVANCE of the next wakeup so the two meet at around the right time. This seems to be the only way of getting 95% of transmits though on a busy network.

I can see your code working fine as you have testified on a separate Vera network with a separate controller as most of the time the Z network is dormant with nothing in the queue.

Offline dunked

  • Jr. Member
  • **
  • Posts: 88
  • Karma: +3/-0
Re: Alternative code for handling TRVs (StellaZ and Danfoss)
« Reply #10 on: December 17, 2014, 09:53:40 am »
You must have a pretty busy Vera system then if the all of wakeups aren't being caught in time. I've had (admittedly only one TRV) running on my main Vera for a week now to see how it got on and that's behaved reasonably well.
That Vera's got 14 Fibaro dimmers, 9 Motion sensors, 8 door sensors, A NorthQ Power reader, an RFXtrx controller, 2 minimotes and 7 power switches all running on it, with code turning lights on and off, reporting on sensors and updating  a database with power readings every minute and it misses very few wakeups. Though I'm still not going to put all my 13 (now 15 just had 2 more Danfoss delivered) TRVs on it -just because the impact of a single wakeup being missed is to slow the whole system down, which I'm not prepared to put up with.

My code does use the same luup action call to set the SP that Vera uses (your PLEG code must use that too - if not do tell!), but unlike the Vera built in code  I at least wait for wakeup first rather than send it as soon as the user requests a change, but of course if you miss the wakeup it'll fall back to standard Vera behaviour.

I assume you've done a reload since installing the code? (shouldn't actually need one but when I was testing this morning a few TRVs seemed to misbehave until I did that)

Offline dunked

  • Jr. Member
  • **
  • Posts: 88
  • Karma: +3/-0
Re: Alternative code for handling TRVs (StellaZ and Danfoss)
« Reply #11 on: December 17, 2014, 10:40:42 am »
I reckon I could fairly easily to tweak my code to use your -pre-emptive technique instead of catching wake-ups (maybe with a switch to let you choose which option at start-up).

So I reckon if on start-up I check the last_wakeup time for each device and onto that add the wakeup interval I'll get the time when the next wakeup is due - and (if I remember correctly one of your other posts) take 5 seconds off that and set a timer - then when that timer fires I'll run exactly the same routine that I'm now running on a wakeup - except at the end of it I'll set-up another timer for the next wakeup.

.... the excitement builds (except the kids are due back from school any minute!)

Offline mikee123

  • Hero Member
  • *****
  • Posts: 1521
  • Karma: +18/-11
Re: Alternative code for handling TRVs (StellaZ and Danfoss)
« Reply #12 on: December 17, 2014, 11:43:26 am »
If you implement that I think that would be a good idea. In general, I have better results with this method than with the normal send when change. I still occasionally have a 40 minute wait until my Horstman thermostat changes setpoint, which is slightly annoying as 2 out of 7 mornings my bathroom is cold, and the heating comes on once I am done in the bathroom. Not ideal. On top of that I have the other half complaining of why the heating is not coming on... So I am trying to find a solution. I was hoping getting rid of the VC's would make things better, but it has not on the heating side. I would like to try your code once you have adapted it to send before the next wakeup. My StellaZ's on the other hand normally change immediately (after wakeup), occasionally I have a 10 minute wait. (Everything is set to 240 secs wakeup)

Offline dmckenna

  • Full Member
  • ***
  • Posts: 196
  • Karma: +8/-2
Re: Alternative code for handling TRVs (StellaZ and Danfoss)
« Reply #13 on: December 17, 2014, 12:05:29 pm »
On top of that I have the other half complaining of why the heating is not coming on... So I am trying to find a solution.

Upgrade her ?

Offline mikee123

  • Hero Member
  • *****
  • Posts: 1521
  • Karma: +18/-11
Re: Alternative code for handling TRVs (StellaZ and Danfoss)
« Reply #14 on: December 17, 2014, 02:27:01 pm »
Ha ha have thought about it. Told her she might be upgraded. She agreed, and asked how much i would pay her... I decided she has got a little longer...  ;D