PLEG + heating + battery thermostat

Plugins & Plugin Development Program Logic (PLEG)
1

Hello…I need some assisting in improving WAF around Z-wave/home automation! ;D

I’ve been running a Z-wave environment for a couple of years now…pretty comfortable in terms of their setup, etc, have automated the lights (table+floor standing via sockets), outside sockets (Xmas lights) and heating. I’ve been a PLEG user for just over a year - great plugin! I’ve also recently looked at MySensors and have this now gateway’d to the Vera and working well…

Unfortunately its the heating side of things that appears to be flakey (as my misses puts it!) in terms of whether it will come on in the morning OR even if it will switch off at night! :-\

There was a recent issue with PLEG upgrade that caught me off guard and added to the confusion whilst I was investigating what’s been happening with the heating side of things. I’ve trimmed down the PLEG scripting to make things as simple as possible to help ascertain what could be causing the problem. Is it possible that actions are not firing if the temperature cannot be set on the thermostat?

The battery thermostat (Secure SRT321 with recent fresh batteries) does appear to lose connection with the relay controller (Secure SSR302) that controls the heating but it does reconnect eventually. Is that sufficient to prevent the heating from coming on when I have a PLEG script that sets the thermostat setpoint temperature (so could fail if not awake - most likely to happen) and to switch the heating on?

Thermostat	SetCurrentSetpoint	NewCurrentSetpoint=21
Heating Controller	SetModeTarget	NewModeTarget=HeatOn

Does the order of these steps matter? If one of these doesn’t succeed, would that prevent the other steps from happening?

I’ve read about the need to setup a script to keep alive the relay controller to prevent it from going to fail-safe mode - but I was under the impression that this was for controlling the hot water? I did enable this script (for ease, implemented it as Luua code) but not sure if this is really needed as it appeared to switch the heating off just after it came on…wasn’t sure if there was some sort of race condition going on here or something else…?

This script is currently disabled but was setup to run every 35 minutes.

local dID = 23 local mode = luup.variable_get("urn:upnp-org:serviceId:HVAC_UserOperatingMode1","ModeStatus",dID) --luup.call_action("urn:intvelt-com:serviceId:HWPush1", "SendMessage", {Msg = "Value is " .. mode}, 25) luup.call_action("urn:upnp-org:serviceId:HVAC_UserOperatingMode1","SetModeTarget",{NewModeTarget=mode},dID)

I’ve attached the PLEG ‘heating controller’ report if that helps…

Thank you for any guidance that you can provide…!

Nutz

2

If you have associated the SSR302 with the SRT321 you should not need to refresh the mode. The SRT321 will do that automatically. You should also not need to use the SetModeTarget action for the SSR302 - again the SRT321 will do that.

All you should need to do is send the new setpoint to the SRT321 whenever you want it changed. When the SRT next wakes up, it will start using the new setpoint. If you find that some changes are getting missed, add a delayed action to your PLEG Action to resend the setpoint after the normal wakeup period of the SRT.

What do you have the SRT321 wakeup set to? I run mine on 240 seconds. I can wait four minutes for a change but not longer.

If the SRT321/SSR302 link keeps dropping out, you will not get reliable operation. Are the two units a long way apart or are there obstructions in the signal path?

Your PLEG Status report is incomplete (truncated). We may be able to help if you print the whole thing to PDF.

3

Thanks for responding. Yes I do have the SSR302 and SRT321 associated and can call upon heat with no issues. I’ll need to revisit this over the weekend and will look to send on a complete PLEG report.

In terms of the SRT321, I have this configured to wake up every 600 seconds - hence the belt and braces approach of the script calling the SSR302 directly to set the setpoint and enable HeatOn - appears to work…

The SSR302 is at the top of the stairs behind a door and the SRT321 is downstairs in the hallway - so not particularly far but the walls are thick so may have something to do with it? To help compensate this, I’ve a z-wave socket plugged in opposite the SRT321 - my thinking that the proximity of this may help as part of the z-wave mesh network…and so be able to pass the message on…may be that thinking is wrong… ???

Also, should these actions be directed at the Heating Controller (the parent) or directly to the ControllerRelay (child)? At the moment, they are being directed to the Heating Controller and it appears to be working…

Nutz

*updated with PLEG report (full)

4
To help compensate this, I've a z-wave socket plugged in opposite the SRT321 - my thinking that the proximity of this may help as part of the z-wave mesh network...and so be able to pass the message on...may be that thinking is wrong..

My experience is that this helps with Vera to SRT321 communications but not with SRT to SSR. It appears to me that the SRT to SSR association requires a direct link.

Also, should these actions be directed at the Heating Controller (the parent) or directly to the ControllerRelay (child)? At the moment, they are being directed to the Heating Controller and it appears to be working...

The actions should be directed to the child but, with multi-channel devices, an action sent to the parent usually works on the (numerically) first child.

Concerning your original question about missed events:

You are using single-event PLEG Schedules to trigger setpoint changes. If Vera restarts just before one of these, that event could be lost. A more robust way is to use inclusive Schedules with the OffType set to Interval for the appropriate duration. If Vera restarts, PLEG can restart the timer for the interval and process the missed event.

5

Thanks for the feedback…will look to do some tinkering… 8)

Would it be possible of a screenshot of what this type of schedule looks like within the PLEG schedule configurator? Something like the attached?

Thanks

Nutz

6
Something like the attached?

Yes - just like that but with a longer interval. Your example is set for ten seconds but you would want several hours.

You would also need to change your Condition for the Off events. For example, if you change your On Schedules to turn off after appropriate intervals:

_HeatOff yes (!HeatOnMorn or !HeatOnNight or !HeatOnNightWknd)

7

Hi,

Ok, so I’ve tweaked the configuration and have been monitoring this over the last few days and still things are unreliable. Heating didn’t go off last night and it didn’t come on this morning. Is there further configuration required or are the changes I’ve made wrong? Report status attached as of this morning with no heating.

Thanks

Nutz

8

Is the main heating thermostat the one at the top of Device Properties - HallSetTemp & HallTemp? If so it did not get a new setpoint at the expected time but already thinks the temperature is 22. Interesting that the last change was at 02:01:28 which would be about the time a Z-Wave heal would run - unless you did it manually. If the heal broke it, I would expect to see it showing as unconfigured in the UI.

I don’t think it caused your problem this morning but you don’t need two sets of Schedules now. You can just use the HeatOnMorn, HeatOnMornWknd & HeatOnNight ones. You could remove the off versions which, in any case, do not quite match the opposite of the on ones. Change the Condition _HeatOff to:

_HeatOff !_HeatOn

Also _HeatOn and _HeatOff should not need Repeats on.

9

One totally random thing to try…

I was having all kinds of problems with PLEG scripts not starting when they should, or just behaving really oddly, even after hours and hours of checking and debugging.

In the end it was my ERGY plugin that was causing all the issues. Richard Schaeffer spotted it after going through log files.

So, just in case you have ERGY plugin - delete it and it might just help!

10

[quote=“RexBeckett, post:8, topic:185672”]Is the main heating thermostat the one at the top of Device Properties - HallSetTemp & HallTemp? If so it did not get a new setpoint at the expected time but already thinks the temperature is 22. Interesting that the last change was at 02:01:28 which would be about the time a Z-Wave heal would run - unless you did it manually. If the heal broke it, I would expect to see it showing as unconfigured in the UI.

I don’t think it caused your problem this morning but you don’t need two sets of Schedules now. You can just use the HeatOnMorn, HeatOnMornWknd & HeatOnNight ones. You could remove the off versions which, in any case, do not quite match the opposite of the on ones. Change the Condition _HeatOff to:

_HeatOff !_HeatOn

Also _HeatOn and _HeatOff should not need Repeats on.[/quote]

Hi,

Yes the device Thermostat is the main unit in the hallway and no, I didn’t run any manual heal.

According to the SRT display it appeared to have a connection to the SSR unit although that’s not to say that it may have lost connection overnight and reconnected this morning before I checked.

I’ve tided up the schedules and conditions as you’ve indicated. I’ll monitor how this behaves over the coming days. Updated report status attached.

dominoman - thank you. I don’t run the ERGY plugin so hopefully that can be ruled out - that’s not to say that its possible that another plugin could be causing this. Any ideas as to what I should be looking for in the log files that may hint at causing disruption…?

Thanks guys,

Nutz

11
Any ideas as to what I should be looking for in the log files that may hint at causing disruption...?

If a heal runs at about 02:00:00, you would see a large number of log entries showing it start, progress and end.

If the heating fails to turn on or off, look in the log at the expected times it should have occurred. You should see the PLEG action reported followed by an attempt to send the new setpoint which will normally fail because the thermostat is not awake. Within the wakeup time (usually 4 minutes), you should see the wakeup reported and the CurrentSetpoint change logged. If one of these events is missing, it could help us figure-out why it is failing.

It may help you to look through the log for a successful setpoint change so that you can identify the events.

12

aarrghhh!!! >:( >:(

It appears that my Veralite has decided to change the IP address that I had originally set for it…and it now has disappeared off the network. I was able to work out (via the router) as to what IP it now has and due to the poor layout and information provided on the Vera network configuration page, I accidentally changed the IP settings within the LAN area of the web page (reading on the web, a trap a few others have fallen into!). Bugger.

I had no luck in being able to do the 192.168.81.1 trick and connecting a laptop to the Vera directly (who has laptops now with built in RJ45 network ports!? - fortunately my daughter has one!) so had to do a full reset. Once this was completed, the 192.168.81.1 trick worked. Having changed the static IP back to what it was and restarting the Vera, all appears to be ok.

Next step, to restore from a previous backup…decided to restore a backup from a couple of days ago (just in case anything that had changed recently screwed things). Restore completed but now I just have a Vera blue screen…no web page content at all. Bugger.

I guess I’ll need to repeat this again and head down the full factory restore…something that I was trying to avoid… >:(

So I guess I’ll need to revisit this heating stuff again…WAF severely impacted!!

Nutz

13

It’s best to always leave devices (not just Vera) at the default settings which is usually a DHCP address received from the Router.

Then login to the router … See the address … and make it a permanent reservation … so the device always gets the same IP address.
Actually I change the address so it’s easier to find the list of “Reserved IP Addresses” and those that are dynamic. I try to give everything an reserved IP address … Phones, Tablets, Tvs, AV equipment …

Then it’s easy to tell if there is a NEW device on my network …

14

Update.
I’ve been able to rebuild/configure the Vera - was fortunate to be able to restore to a previous backup that the Vera had taken previously so luckily nothing lost…

The most recent changes that were suggested by RexBeckett appeared to have worked…the heating was reliably coming on and off at the expected time. This has been working for a number of weeks…until the last couple of days. I wonder if this is to do with the battery in the thermostat…although it still has some life in it, I’m wondering if this could have an effect to the reliability of the connection between the thermostat and the control unit - it has occasionally started again to lose signal (as previously mentioned).

What I don’t understand is why given the latest configuration changes that a loss in signal between the thermostat and the controller is enough to throw it out - these changes are on the Vera - it doesn’t really care what the temperature is in the hallway - if the heating has been on for 3 hours in the morning, it should switch off.

This morning for example, the heating came on at the correct time but I’ve had to switch it off manually because it was still on after the expected close time - status report attached.

It’s these teething issues that kind of make this home automation stuff frustrating…

Thanks

Nutz

15

The _HeatOn and _HeatOff Conditions fired at the expected times. It seems that the thermostat did not receive the updated setpoint. This can be caused by a low battery in the 'stat. It could also be caused by the usual Z-Wave communications problems.

You could try adding a second back-up action for these Conditions to resend the setpoint after an interval longer than the 'stat’s wake-up time. So, if the wake-up is four minutes, add a delayed action to send the setpoint again after, say, five minutes. The second action should not cause any issues if the first one was successful but it could catch situations where it has failed.

16

Hi,

Is this what you mean - see attached?

The thermostat is set to wake up every 10 minutes, so I’ve created additional schedules that start: Time + 10 mins + 1 minute (just in case).

Thanks

Nutz

17
Is this what you mean - see attached?

Not really. You have set up a backup Schedule. Some people have found this to be beneficial if they are losing timer events due to Vera/Luup restarts but it will not help if you are losing Z-Wave commands.

My suggestion was to add a delayed action to your existing PLEG Action. Right now you have an Immediate action to set the thermostat setpoint. If you add a delayed action (with an eleven minute delay) that repeats the setpoint setting, it will act as a backup if the first one gets lost.

18

Think I may need some further assistance on this…

I’ve created a ‘self trigger’ timer that I believe will start when _HeatOn is scheduled to fire and will repeat after 11 minutes until _HeatOn is true. This was based on an example that you’ve documented (PLEG basics PDF). It didn’t work as no heating came on this afternoon so something not right…! :-\

Nutz

19

Does not look like the _HeatOn or _HeatOff were called to start the timer.

We can’t see the whole report … it’s clipped horizontally.
It’s best to print the Window using a PDF Printer (Google Cute PDF).

Also you do not need to create a 1 Minute periodic timer … thats what NOW is!

20

Ahh, not again! I did checkout Cute PDF and it turns out the Mac already has this built in… :wink:
(wanted to remove licence number before distribution…although suspect that is unique to my Vera only)

Anyway, latest status report attached. Heating didn’t switch itself off last night nor come on this morning…so I’ve obviously broken something… Any help appreciated…!

Nutz