We have moved at community.getvera.com

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

Offline dunked

  • Jr. Member
  • **
  • Posts: 88
  • Karma: +3/-0
Re: Alternative code for handling TRVs (StellaZ and Danfoss)
« Reply #15 on: December 19, 2014, 03:43:32 pm »
I've made the changes to allow preemptive calls and a ton of error checking and meltdown prevention code.
I've updated the first post in this thread and attached the latest version to that along with configuration instructions. I've spent (far too much) time today hammering it by changing all 14 of my TRVs at once with boosts and all sorts, using both wakeup catching and preemptive calls. Both options work pretty well - though I'm in no doubt that wakeups is slightly better if your Vera is responsive enough.
If you're trying the preemptive option then once you reload the Vera the first wakeup of each device is just used to calibrate the timers, so any changes you have set won't start taking effect until the second and subsequent wakeups (but that only happens once on  a reload). You still will get the occasional inevitable retries when the setpoint doesn't take fast enough - but it'll sit and wait if it sees 2 stuck ones until they clear, it also won't send an SP update to a TRV if there's one pending, and if it sends an SP then it won't send another one within 60 seconds if the first one hasn't taken (though they usually take within a few seconds).
Have a try changing offset values (the Danfoss consistent early wakeup was a surpise to me but all 4 of mine do it!). If you don't want to reload the Vera to change offset values you can just run
Code: [Select]
TRV_timer_offset=x in the Test Luup code box and it'll take effect from that point on (until you reload of course)

Good luck - I need to take a short break from coding on Veras as I'm told something called "Christmas" is happening and I need to spend lots of money!

Offline danmiles86

  • Sr. Newbie
  • *
  • Posts: 26
  • Karma: +0/-0
Re: Alternative code for handling TRVs (StellaZ and Danfoss)
« Reply #16 on: December 21, 2014, 05:46:35 am »
Thanks for all your effort on this Dunked.

I have to admit I'm not seeing much difference. Updates to the setpoints are still taking a long time (30mins+) if they ever get through at all. Reading the temperature back still happens once in a blue moon.

There does however seem to be an improvement in the responsiveness of the other devices on the network, I haven't had a massive lockup yet but I have only been using this for a day.

When you get a break from Christmas would you mind letting me know what I should be seeing in the log files and what to look out for as a problem?

Thanks,

Dan.

Offline dunked

  • Jr. Member
  • **
  • Posts: 88
  • Karma: +3/-0
Re: Alternative code for handling TRVs (StellaZ and Danfoss)
« Reply #17 on: December 21, 2014, 12:20:58 pm »
 danmiles86 -

After a vera reload the first thing you should see in the logs is some startup messages (in green if you're using info viewer) like this (though they're not green here)
Code: [Select]
12/21/14 16:49:26.379   luup_log:0: --MC-- ======================== TRV.init RUNNING ========================  using catching wake-up <0x2bc4b680>
50   12/21/14 16:49:26.379   luup_log:0: --MC-- TRV.init The Setpoint Queue Limit (SP_queue_limit) is set to 2. This limits how many z-wave Setpoint changes can be in the queue <0x2bc4b680>
50   12/21/14 16:49:26.380   luup_log:0: --MC-- TRV.init The Maximum Wait Time (max_wait_time) is set to 600 seconds. If a Setpoint has not been accepted in this time then a reload may be triggered <0x2bc4b680>
50   12/21/14 16:49:26.380   luup_log:0: --MC-- TRV.init The Unset Wakeup Limit (unset_wakeup_limit) is set to 3. If a device wakes-up 3 times after a Setpoint has been sent to it without accepting the new Setpoint then a reload may be triggered <0x2bc4b680>
50   12/21/14 16:49:26.381   luup_log:0: --MC-- TRV.init This Vera will be reloaded (set by reload_when_stuck) if the limits (above) are breached. They indicate that the z-wave queue is stuck so either we reload or wait (potentially for a long time) for it to clear <0x2bc4b680>
50   12/21/14 16:49:26.413   luup_log:0: --MC-- Added callbacks for Lounge Back Radiator(7) <0x2bc4b680>
50   12/21/14 16:49:26.413   luup_log:0: --MC-- Added callbacks for Lounge Front Radiator(8) <0x2bc4b680>
50   12/21/14 16:49:26.414   luup_log:0: --MC-- Added callbacks for Corridor Radiator(11) <0x2bc4b680>
50   12/21/14 16:49:26.415   luup_log:0: --MC-- Added callbacks for Bathroom Radiator(12) <0x2bc4b680>
50   12/21/14 16:49:26.416   luup_log:0: --MC-- Added callbacks for Spare Room Radiator(14) <0x2bc4b680>
50   12/21/14 16:49:26.416   luup_log:0: --MC-- Added callbacks for SC Bedroom Radiator(15) <0x2bc4b680>
50   12/21/14 16:49:26.417   luup_log:0: --MC-- Added callbacks for SC Bathroom Radiator(16) <0x2bc4b680>
50   12/21/14 16:49:26.417   luup_log:0: --MC-- Added callbacks for Study Radiator(33) <0x2bc4b680>
50   12/21/14 16:49:26.418   luup_log:0: --MC-- Added callbacks for Dining Room Front Radiator(35) <0x2bc4b680>
50   12/21/14 16:49:26.418   luup_log:0: --MC-- Added callbacks for Dining Room Back Radiator(37) <0x2bc4b680>
50   12/21/14 16:49:26.419   luup_log:0: --MC-- Added callbacks for Playroom Radiator(41) <0x2bc4b680>
50   12/21/14 16:49:26.420   luup_log:0: --MC-- Added callbacks for Kitchen Radiator(29) <0x2bc4b680>
50   12/21/14 16:49:26.420   luup_log:0: --MC-- ======================== TRV.init ENDED took 0.04 seconds ========================

when you run the TRV.set_tgt command (probably via a scene) you should see something like this in the log
Code: [Select]
luup_log:0: --MC-- Have set Study Radiator(33) to 15
then when the TRV next wakes up you should see entries like this
Code: [Select]
50   12/21/14 16:57:52.933   luup_log:0: --MC-- ========================TRV.wakes_up - Study Radiator(33)  237 seconds since last wakeup======================== <0x2ba4b680>
08   12/21/14 16:57:52.934   JobHandler_LuaUPnP::HandleActionRequest device: 33 service: urn:upnp-org:serviceId:TemperatureSetpoint1_Heat action: ctrl_chr[36;1mSetCurrentSetpointctrl_chr[0m <0x2ba4b680>
08   12/21/14 16:57:52.934   JobHandler_LuaUPnP::HandleActionRequest argument NewCurrentSetpoint=15 <0x2ba4b680>
06   12/21/14 16:57:52.934   Device_Variable::m_szValue_set device: 33 service: urn:upnp-org:serviceId:TemperatureSetpoint1_Heat variable: ctrl_chr[35;1mSetpointTargetctrl_chr[0m was: 20 now: 15 #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0 <0x2ba4b680>
02   12/21/14 16:57:52.935   ctrl_chr[33;1mZWJob_SendData  UPDATE MANUAL ROUTE 160=(nil)ctrl_chr[0m <0x2ba4b680>
50   12/21/14 16:57:52.936   luup_log:0: --MC-- TRV.process_wakeup just transmitted Setpoint of 15 to Study Radiator(33) - 1 Setpoint changes queued <0x2ba4b680>
02   12/21/14 16:57:52.937   ctrl_chr[33;1mZWaveNode::Wakeup did a poll for 160 475 seconds interval 10800 existing (nil) heal (nil)ctrl_chr[0m <0x2ba4b680>
02   12/21/14 16:57:52.937   ctrl_chr[33;1mZWJob_SendData  UPDATE MANUAL ROUTE 160=(nil)ctrl_chr[0m <0x2ba4b680>
02   12/21/14 16:57:52.939   ctrl_chr[33;1mUPDATE MANUAL ROUTE2 160=(nil)ctrl_chr[0m <0x2be4b680>
02   12/21/14 16:57:52.939   ctrl_chr[33;1mZW_Send_Data node 160 NO ROUTE (nil)ctrl_chr[0m <0x2be4b680>
06   12/21/14 16:57:53.042   Device_Variable::m_szValue_set device: 33 service: urn:upnp-org:serviceId:TemperatureSetpoint1_Heat variable: ctrl_chr[35;1mCurrentSetpointctrl_chr[0m was: 20 now: 15 #hooks: 1 upnp: 0 v:0xd5c4c8/NONE duplicate:0 <0x2ba4b680>
50   12/21/14 16:57:53.043   luup_log:0: --MC-- ==================== TRV.SP_change -- Setpoint accepted for Study Radiator(33) to 15 - 0 Setpoint changes queued <0x2ba4b680>
The 3 key lines in there are the --MC-- lines first showing the device has woken up, then showing the transmit of the new Setpoint and finally the Setpoint accepted message - the stuff in between those lines is Veras own messages reacting to the change. - that particular radiator is a Danfoss (2014 model) with wakeup interval set to 240 and polling at the default 10800 seconds (as the Danfoss TRVs don't report actual temp so I don't bother changing the polling).
For a StellaZ with wakeup at 240 seconds and polling at 240 seconds it looks like this
Code: [Select]
50   12/21/14 17:03:42.673   luup_log:0: --MC-- ========================TRV.wakes_up - Lounge Back Radiator(7)  242 seconds since last wakeup======================== <0x2ba4b680>
08   12/21/14 17:03:42.673   JobHandler_LuaUPnP::HandleActionRequest device: 7 service: urn:upnp-org:serviceId:TemperatureSetpoint1_Heat action: ctrl_chr[36;1mSetCurrentSetpointctrl_chr[0m <0x2ba4b680>
08   12/21/14 17:03:42.674   JobHandler_LuaUPnP::HandleActionRequest argument NewCurrentSetpoint=14 <0x2ba4b680>
06   12/21/14 17:03:42.674   Device_Variable::m_szValue_set device: 7 service: urn:upnp-org:serviceId:TemperatureSetpoint1_Heat variable: ctrl_chr[35;1mSetpointTargetctrl_chr[0m was: 16 now: 14 #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0 <0x2ba4b680>
02   12/21/14 17:03:42.675   ctrl_chr[33;1mZWJob_SendData  UPDATE MANUAL ROUTE 133=(nil)ctrl_chr[0m <0x2ba4b680>
50   12/21/14 17:03:42.676   luup_log:0: --MC-- TRV.process_wakeup just transmitted Setpoint of 14 to Lounge Back Radiator(7) - 1 Setpoint changes queued <0x2ba4b680>
02   12/21/14 17:03:42.677   ctrl_chr[33;1mZWJob_SendData  UPDATE MANUAL ROUTE 133=(nil)ctrl_chr[0m <0x2ba4b680>
02   12/21/14 17:03:42.692   ctrl_chr[33;1mZZZ-POLLING H1,F1,/1/0ctrl_chr[0m <0x2be4b680>
02   12/21/14 17:03:42.693   ctrl_chr[33;1mZW_Send_Data node 133 NO ROUTE (nil)ctrl_chr[0m <0x2be4b680>
02   12/21/14 17:03:42.843   ctrl_chr[33;1mZW_Send_Data node 133 NO ROUTE (nil)ctrl_chr[0m <0x2be4b680>
06   12/21/14 17:03:42.962   Device_Variable::m_szValue_set device: 7 service: urn:upnp-org:serviceId:TemperatureSensor1 variable: ctrl_chr[35;1mCurrentTemperaturectrl_chr[0m was: 19 now: 19 #hooks: 0 upnp: 0 v:0xd58750/NONE duplicate:1 <0x2ba4b680>
02   12/21/14 17:03:42.964   ctrl_chr[33;1mZW_Send_Data node 133 NO ROUTE (nil)ctrl_chr[0m <0x2be4b680>
02   12/21/14 17:03:43.083   ctrl_chr[33;1mZW_Send_Data node 133 NO ROUTE (nil)ctrl_chr[0m <0x2be4b680>
04   12/21/14 17:03:43.203   <Job ID="107" Name="pollnode_wake #133 4 cmds" Device="7" Created="2014-12-21 17:03:42" Started="2014-12-21 17:03:42" Completed="2014-12-21 17:03:43" Duration="0.525974000" Runtime="0.520660000" Status="Successful" LastNote="" Node="133" NodeType="ZWaveThermostat" NodeDescription="Lounge Back Radiator"/> <0x2ba4b680>
02   12/21/14 17:03:43.205   ctrl_chr[33;1mUPDATE MANUAL ROUTE2 133=(nil)ctrl_chr[0m <0x2be4b680>
02   12/21/14 17:03:43.205   ctrl_chr[33;1mZW_Send_Data node 133 NO ROUTE (nil)ctrl_chr[0m <0x2be4b680>
06   12/21/14 17:03:43.292   Device_Variable::m_szValue_set device: 7 service: urn:upnp-org:serviceId:TemperatureSetpoint1_Heat variable: ctrl_chr[35;1mCurrentSetpointctrl_chr[0m was: 16 now: 14 #hooks: 1 upnp: 0 v:0xd5c4c8/NONE duplicate:0 <0x2ba4b680>
50   12/21/14 17:03:43.293   luup_log:0: --MC-- ==================== TRV.SP_change -- Setpoint accepted for Lounge Back Radiator(7) to 14 - 0 Setpoint changes queued <0x2ba4b680>
So there's more Vera stuff happening for a StellaZ as that reports temp but you can see the SP still gets accepted within around 0.5 seconds after it was sent
and when a TRV wakes up but there is no change needed you'll see
Code: [Select]
50   12/21/14 17:10:55.333   luup_log:0: --MC-- ========================TRV.wakes_up - Corridor Radiator(11)  483 seconds since last wakeup======================== <0x2ba4b680>
50   12/21/14 17:10:55.333   luup_log:0: --MC-- TRV.process_wakeup - Corridor Radiator(11) no changes made <0x2ba4b680>

let me know what you see in your logs.
I'd advise just trying it with one TRV to start just to keep it easier to diagnose what's going on. and try turning off any other plugins you might have running such as data collection routines or PLEGs just so you get the Vera running with as little as possible to test things out. Some plugins can do a lot of stuff and keep the Vera so busy that it's always playing catch up and can't react to the wakeups in time. I've tried with this to make it as efficient as I can so it does as little as possible on a wakeup to have the best chance of sending the new SP before the TRV goes back to sleep. 

Offline dali

  • Sr. Newbie
  • *
  • Posts: 31
  • Karma: +0/-0
Re: Alternative code for handling TRVs (StellaZ and Danfoss)
« Reply #18 on: December 26, 2014, 03:17:39 pm »
@dunked: Are you on ui5? I've just had an email conversation with Aaron B, the main luup developer at Vera. He said that ui7 works as we're all expecting it to; it will try to send a command once to battery operated devices, and then wait for a wakeup before trying again.

Offline slajgaj

  • Full Member
  • ***
  • Posts: 176
  • Karma: +2/-13
Re: Alternative code for handling TRVs (StellaZ and Danfoss)
« Reply #19 on: December 26, 2014, 03:47:16 pm »
Under UI7 not working :(

Offline dmckenna

  • Full Member
  • ***
  • Posts: 196
  • Karma: +8/-2
Re: Alternative code for handling TRVs (StellaZ and Danfoss)
« Reply #20 on: December 27, 2014, 05:33:22 pm »
@dunked: Are you on ui5? I've just had an email conversation with Aaron B, the main luup developer at Vera. He said that ui7 works as we're all expecting it to; it will try to send a command once to battery operated devices, and then wait for a wakeup before trying again.

Santa bought me an Edge !! Will get it up and running soon and report back on the whole TRV stuff....I know what to look for ;-)

Offline slajgaj

  • Full Member
  • ***
  • Posts: 176
  • Karma: +2/-13
Re: Alternative code for handling TRVs (StellaZ and Danfoss)
« Reply #21 on: December 28, 2014, 05:46:53 am »
I tested under UI5, work GREAT, but i have not working under UI7 Vera Edge :(
If you have an idea, please send me reply :)
« Last Edit: December 28, 2014, 01:24:35 pm by slajgaj »

Offline dunked

  • Jr. Member
  • **
  • Posts: 88
  • Karma: +3/-0
Re: Alternative code for handling TRVs (StellaZ and Danfoss)
« Reply #22 on: December 29, 2014, 04:59:40 am »
All - sorry I do not have UI7 so have not tested it all using that version.

Not sure how much help I can give on that but if anyone wants to show what is says in the logs I'll have a look

Offline dunked

  • Jr. Member
  • **
  • Posts: 88
  • Karma: +3/-0
Re: Alternative code for handling TRVs (StellaZ and Danfoss)
« Reply #23 on: December 29, 2014, 05:07:18 am »
Quote
I've just had an email conversation with Aaron B, the main luup developer at Vera. He said that ui7 works as we're all expecting it to; it will try to send a command once to battery operated devices, and then wait for a wakeup before trying again.

If that's correct and UI7 will only try once to communicate with a sleeping device then that's a major step forward - UI5 tries 5 times to communicate and that's a real problem as it slows down everything else.
Before trying my code on UI7 I'd be tempted to test the built in UI7 TRV handling as one attempt may be something we can live with, without the need for any extra code?
If anyone can confirm that it does work ok natively on UI7 then I might be tempted to try an upgrade to UI7 or get an Edge myself.

Offline bigzippy

  • Newbie
  • *
  • Posts: 19
  • Karma: +0/-0
Re: Alternative code for handling TRVs (StellaZ and Danfoss)
« Reply #24 on: December 29, 2014, 06:09:28 am »
Quote
I've just had an email conversation with Aaron B, the main luup developer at Vera. He said that ui7 works as we're all expecting it to; it will try to send a command once to battery operated devices, and then wait for a wakeup before trying again.

If that's correct and UI7 will only try once to communicate with a sleeping device then that's a major step forward - UI5 tries 5 times to communicate and that's a real problem as it slows down everything else.
Before trying my code on UI7 I'd be tempted to test the built in UI7 TRV handling as one attempt may be something we can live with, without the need for any extra code?
If anyone can confirm that it does work ok natively on UI7 then I might be tempted to try an upgrade to UI7 or get an Edge myself.

You know it's not going to work! Anything that "works" on Vera is only an illusion!
BZ

Offline slajgaj

  • Full Member
  • ***
  • Posts: 176
  • Karma: +2/-13
Re: Alternative code for handling TRVs (StellaZ and Danfoss)
« Reply #25 on: January 03, 2015, 12:38:12 pm »
Does not working native on Vera UI7
And your code with too...nothink 😁😁

Offline dunked

  • Jr. Member
  • **
  • Posts: 88
  • Karma: +3/-0
Re: Alternative code for handling TRVs (StellaZ and Danfoss)
« Reply #26 on: January 03, 2015, 02:38:59 pm »
I've just attached a slightly updated version in the original post - details in that (but don't get too excited).

I'm going to try and turn this into a plug-in - I've always wondered how those work. That way it'll be more standard.

I've been slowly moving my TRVs away from my Heating Vera back to my main Vera 3 - and so far it's going pretty well - I now have 12 TRVs and a ton of other devices working quite nicely.

My main reason for moving them in the first place was that when the Vera starts doing it's 5 retries on the Vera no other z-wave commands get through, and if another TRV starts doing 5 more retries just after the first one then you're screwed for quite a while until it all eventually clears (could be 10, 15 or 30 minutes) or you reload.
So here are the lessons I have learned when doing this.

1). Danfoss LC TRVs need to have a SetPoint sent every time they wake up - which means the Vera will send one even if it hasn't changed - that's still the case with the newer 2014 firmware version. So there's a not insignificant chance that one will be just a little too slow and you'll get hit with the retries and everything else will stop - even if you haven't done anything - which is really frustrating! So don't have all your Danfoss LCs waking up every 240 seconds - that's just increasing the chance for trouble - I have mine set to 600 seconds (and some even longer) - at least with the Danfoss LCs you can manually change them if you're in a hurry.
2). StellaZ TRVs don't have this problem  so you can set them to 240 seconds without problems.
3). If you're not using the code I posted at the start of this thread then don't try to make too many TRV changes at once - if one misses then the next one will miss too and you'll get the cascade effect and nothing will work for quite a while. If you are using my code then at least it will try to prevent setpoint changes getting missed and stop sending any more until it settles down.
4). StellaZ TRVS report actual temperature - but only if they are polled - All my StellaZ have wakeup and polling set to the same value (often 240) and I see regular temperature changes without any problems. I do note that others have had problems with this and the only difference I can see is that I'm using the code posted which checks the SP every time a TRV wakes up (which I'm guessing also does a Poll). 
5). Try not to load the Vera too heavily with extra plugins and features, if you've got some clever data collection routines or complicated things running then there's a fair chance that they might be running just as a TRV wakes up and make it get missed giving you the dreaded retries.

By way of a benchmark my main Vera 3 now has
6 x Danfoss 2014 LC TRVs
1 x Danfoss older LC TRVs  (I have another one of these but it never seems to work properly so I've uninstalled it)
5 x StellaZ TRVs
1 x NorthQ Power Meter
1 x RFXTRX controller
2 x minimote
7 x Aeon Labs multisensor
4 x Everspring motion sensors
14 x Fibaro Dimmer switches
9 x Door sensors (mostly Fibaro)
4 x Various mains switches

so a fair amount of stuff being managed and it's all working pretty well - just imagine how much simpler it would be if MCV fixed the code for SetPoint changes to battery devices :)


Cheers..




 

Offline slajgaj

  • Full Member
  • ***
  • Posts: 176
  • Karma: +2/-13
Re: Alternative code for handling TRVs (StellaZ and Danfoss)
« Reply #27 on: January 04, 2015, 04:10:28 am »
Thank you Dunked!
You are the BEST!

For your lua code work for me ALL valve! (Danfoss, Stella Z)

« Last Edit: January 04, 2015, 03:55:58 pm by slajgaj »

Offline dali

  • Sr. Newbie
  • *
  • Posts: 31
  • Karma: +0/-0
Re: Alternative code for handling TRVs (StellaZ and Danfoss)
« Reply #28 on: January 04, 2015, 05:08:59 pm »
Hold on slajgaj, in another thread you said that you had the same problem I had, that you couldn't even include the Stella. And now your saying that this works perfect. If it's working, please explain how you got them included.

Offline Wiebe

  • Newbie
  • *
  • Posts: 5
  • Karma: +0/-0
Re: Alternative code for handling TRVs (StellaZ and Danfoss)
« Reply #29 on: January 05, 2015, 08:51:13 am »
The latest version seems to work with UI7 (1.7.481). I'm using it with one Danfoss.

(I'm having problems with five additional Danfoss TRVs, but that seems to be unrelated to this code. I will post a separate thread for that.)