15 Feb 2015 - uploaded v1.5 - loads of changes. just upload this version and reload to install - existing settings should all still work
[ul][li]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.[/li]
[li]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)[/li]
[li]loads more information in the logs[/li]
[li]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[/li]
[li]More features added to TRV.set_tgt - it still has upto 4 parameters devid,tgt,boost,next_tgt
[list]
[li]dev_id - the device id of the TRV[/li]
[li]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[/li]
[li]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![/li]
[li]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[/li]
[/list]
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[/li]
[list]
[li]TRV.set_tgt(135,20) or TRV.set_tgt(135,“20”) - set TRV 135 to 20 degrees[/li]
[li]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[/li]
[li]TRV.set_tgt(135,“-10”,“+60”,5) - boost TRV 135 down by 10 degrees for 1 hour then set it to 5 degrees[/li]
[/list]
[li]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.[/li]
[li]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[/li]
[li]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()[/li][/ul]
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
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")
