GoControl - Program Not Functioning

[garciacg]

Hi Michael, the morning R3 ran as expected at 07:00 for 5 minutes. It is scheduled to run again at 19:00 today. At 8:04 I ran R4 manually from the Zone Status page for 60 minutes to see how it behaved and it shut off at 9:04 as expected. From the time I manually started R4 at 8:04, I noticed that R3 began to exhibit a one-minute walking delay and it continues to do so but never starts. I had removed the inhibits yesterday per my previous message. That zone (R3) is scheduled in the program to run again at 19:00 so we'll see what happens then.

Question: Are the maximum valve times still 60 minutes on the GoControl or have you found a way around that? I ask this because I note in the DEBUG log that the GoControl command is for a 30 minute duration even though the timer in mcsSprinklers is set for 60 minutes. HS3 also reports it as a 30 min duration. Something going on under the hood maybe as I would have expected HS3 to shut the valve off after 30 but don't see the CAPI shut off command for a full 60 minutes. All good... just curious.

In Debug: GoControl Parms(2)/Status=7684, Parms(4)/Ref=937

HS3 Log:

May-20 8:04:46 AM

Device Control

Device: Sprinklers Backyard Irrigation Valve to Valve 4 On for 30 min (7684) by/from: CAPI Control Handler

[Michael McSharry]

The 60 minutes is a GoControl/Hardware constraints. If you want to run a zone for more than 60 minutes the easiest option is to enable Round Robin for that Area. So if you want to run a drip system for 3 hours then use 3 round robin cycles with perhaps one minute between each cycle. You could also do it from Program page by explicit times of no more than 60 minutes each. This later approach would not work for ET/Measured control strategies.

The Status=7684 means 60 minutes for valve 4 per the information that I am using. Seems to be correct with a 60 minute run time in the debug log. My guess is the HS info is the log is in error.

The walking inhibit is something that I need to look more into later today. It looks as if the Area 3 time is being shown for Area 2, but it later clears up.

At 8:04 the Area Inhibit was set to be 19:00 "AreaInhibit=||Start 19:00 ||||||" This is Area 2 (R3)
At 8:04:46 the Area inhibit was set to be 9:00 . "AreaInhibit=|||Start 9:00 |||||" This is Area 3 (R4) as part of manual control cycle
At 8:05 the Area inhibit was set to be 9:00 . "AreaInhibit=|||Start 9:00 |||||" This is Area 3 (R4)
At 9:00 the Area inhibit was removed "AreaInhibit=||||||||"

Area 3 has start times of 480 and 540 minutes after midnight = 8:00 AM and 9:00 AM
At 8:03 NextStartTime for Area 3 is 480 minutes = 8:00 AM
At 8:04 NextStartTime for Area 3 is 540 minutes = 9:00 AM

[Michael McSharry]

I suspect you did not have a cycle at 7 PM. Memory of that was lost on the manual cycle transition. This manual mode operation is something that had not been looked into for quite some time. The update is at http://mcsSprinklers.com/mcsSprinkle...19_4_8_HS3.zip

[garciacg]

Correct... I didn't have a cycle at 7pm. I'll run 2_19_4_8 and report back.

Thanks,
Craig

[garciacg]

Running 2_19_4_8 and performed a manual cycle of R4 and then stopped it... both from the Zone Status page. The Run List shows zones R1 - R3 expecting to run at 06:00, 06:05 and 07:00 tomorrow respectively... as they should. The manual cycle transition didn't result in a memory loss. No longer seeing delays from manual activation. So far so good!

[garciacg]

Hi Michael, everything ran as expected. Looks like you nailed it. Many thanks again!

Craig

[Automate]

I'm also running the GoControl z-wave irrigation controller. I just wanted to confirm that it works perfectly with MCSSprinklers. In fact I believe it's the only plugin that supports the GoControl unit at this time.

Thanks!

[SprinklerZ]

The 60 minute limit is not a hardware limit. The Z-Wave command for the run time is a 16 bit number of seconds. That's over 18 hours per valve.
The limit must be in the software.

[garciacg]

SprinklerZ... I think you are right, and I believe the issue is software between HS and the GoControl and not the plugin. When the Irrigation Valve device is created on joining the ZWave network, it creates device Value/Status pairs only for 5, 10, 20, 30 and 60 minute intervals for all of the 15 irrigation valves. Based on the Value pairs setup in HS after the joining process they look something like this. I've omitted the 20 and 30 minute pairs for brevity, but the logic is the same:

Values for Valve On for 5 minutes have a base of 1280 (valve 1 is 1281, valve 2 is 1282 and so on up to 1295)
Values for Valve On for 10 minutes have a base of 2560 (twice the 5 minute base ... starting at 2561 and so on)
Values for Valve On for 60 minutes have a base of 15360 (six times the 10 minute base... starting at 15361 and so on)

Logic would suggest that a 120 minute timer base should be twice the 60 minute base (15360 X 2 = 30720). Under that assumption, Valve 5 On for 120 minutes should be 30725 (30720 + 5). So I created a Value/Status pair in the Irrigation Valve Status Graphic with Value = 30725 and Status = "Valve On for 120 min"). When I ran the valve using that pair, it ran for 2 hours and then shut off. So clearly the GoControl valves can handle > 60 minute runtimes and my brute force method confirms it. I would think that if a plugin could create Value/Status pairs in real-time and then call them via CAPI, one might have unlimited control of the GoControl up to its true maximum run time based on the 16-bit number..

Craig

[Michael McSharry]

On my next plugin update I can extend the run times to take advantage of this knowledge to 4 hr which will be 61440 on the counter. I could actually just set the counter the desired run time or perhaps a minute past rather than then next power of 2. Dynamic VSP definition is also possible, but that would tend to interfere with the native UI setup by HST for the device.

[Michael McSharry]

The idea of dynamic addition and removal of VSP to extend the range of the GoControl functionality is a good one. Unfortunately it does not appear that other plugins (or likely user scripting) will be able to do this. This capability is provided to the HS UI and to the Zwave plugin. The following code always returned a fail status when trying to add another VSP. I did not try to edit an existing one and then restore after use, but I suspect that the same protections are built in for this function as well.

In the HST documentation they provide a method DeviceVSP_PairsProtected ... "To check to see weather the device value/status pairs are protected, which applies to devices owned by plug-ins."

            Dim vsPair As HomeSeerAPI.VSPair = hs.DeviceVSP_Get(iRef, nValue, HomeSeerAPI.ePairStatusControl.Both)
            If vsPair Is Nothing Then
                If Not GoControlVSPDictionary.ContainsKey(sDC) Then
                    GoControlVSPDictionary.Add(sDC, nValue)
                End If
                vsPair = hs.DeviceVSP_Get(iRef, 0, HomeSeerAPI.ePairStatusControl.Both)
                If vsPair Is Nothing Then
                    vsPair = New HomeSeerAPI.VSPair(HomeSeerAPI.ePairStatusControl.Both)
                    vsPair.Value = 0
                    vsPair.Status = "Off"
                    vsPair.Render = HomeSeerAPI.Enums.CAPIControlType.Single_Text_from_List
                    Dim bSuccess As Boolean = oHS.DeviceVSP_AddPair(iRef, vsPair)
                End If
                vsPair.Value = nValue
                vsPair.Status = "Valve " & oRain8.Valve & " On for " & iDuration.ToString & " mins"
                Dim bSuccess As Boolean = hs.DeviceVSP_AddPair(iRef, vsPair)
            End If

[garciacg]

You were reading my mind as I was getting ready to start digging in to this too. Too bad there isn't a way to unprotect the pairs. But I guess that would defeat the whole point in protecting them to begin with ;-)