Device Weirdness.

[Wadenut]

I have a script which is called via several different events to open/close a set of vertical blinds. This method and script has worked for me for years with no issues but lately has been acting up.
Essentially, the script has three entry points, "Open", "Close" and "Toggle". The latter opens or closes the drapes based on their current open/closed condition as determined by a virtual device which tracks the status.

Lately, when the script runs (without error) the Z-Wave module controlled does indicate according to the HS GUI that it has in fact been activated, and the virtual device does track as expected, but the real world Z-Wave module is never turned on nor off.
If however, I activate the device from the GUI manually or by using Event Actions directly (no Script), the Z-Wave module does work properly.

The script (I've only included the Toggle function here):
Note the Virtual Device Values are defined as: "100 = Open, 0=Closed, 10=Closing, 90=Opening". This is not a problem.

Sub Toggle(Parm As Object)
    If hs.DeviceValueByName("Living Room Front Blind Status") = 100 Then
        DeviceAction("Living Room Front Blind", "On")
        hs.SetDeviceValueByName("Living Room Front Blind Status",10)
        hs.waitsecs(15)
        DeviceAction("Living Room Front Blind", "Off")
        hs.SetDeviceValueByName("Living Room Front Blind Status",0)
        hs.SetDeviceLastChange(hs.GetDeviceRefByName("Living Room Front Blind Status"),now)
    Else
        DeviceAction("Living Room Front Blind", "On")
        hs.SetDeviceValueByName("Living Room Front Blind Status",90)
        hs.waitsecs(15)
        DeviceAction("Living Room Front Blind", "Off")
        hs.SetDeviceValueByName("Living Room Front Blind Status",100)
        hs.SetDeviceLastChange(hs.GetDeviceRefByName("Living Room Front Blind Status"),now)
    End If
End Sub


Sub DeviceAction(Device As String, Action As String)
    Dim objCAPIControl As CAPIControl
    Dim DvRef As Integer = hs.GetDeviceRefByName(Device)
    hs.CAPIControlHandler(hs.CAPIGetSingleControl(DVRef, True,Action.ToUpper,False,False))
End Sub

In order to ensure things do work, this morning I've resorted to calling a second event with direct Device Actions as follows. This shouldn't be necessary.

Sub Toggle(Parm As Object)
    If hs.DeviceValueByName("Living Room Front Blind Status") = 100 Then
        hs.TriggerEvent("Activate Front Blind")
        hs.waitsecs(15)
        hs.SetDeviceValueByName("Living Room Front Blind Status",0)
        hs.SetDeviceLastChange(hs.GetDeviceRefByName("Living Room Front Blind Status"),now)
    Else
        hs.TriggerEvent("Activate Front Blind")
        hs.waitsecs(15)
        hs.SetDeviceValueByName("Living Room Front Blind Status",100)
        hs.SetDeviceLastChange(hs.GetDeviceRefByName("Living Room Front Blind Status"),now)
    End If
End Sub

What's changed? The only thing which has changed on my installation related to this would be the conversion from an older Z-Troller Z-Wave controller to a new HS SmartStick.
Currently using HS3 Pro Edition 3.0.0.523 (Windows) and Z-Wave Plugin v3.0.1.261.

Any suggestions?

[Uncle Michael]

I don't have any insights, but I am surprised that you do not need to use CAPI to control to the module. What happens if you do?

[Wadenut]

I don't have any insights, but I am surprised that you do not need to use CAPI to control to the module. What happens if you do?

I thought I was. That's what the "DeviceAction" routine is doing in the first script. I use that in most of my scripts. Which is another weirdness with this particular script. Generally, I'll include this routine using an #Include statement on the first line of a script. so if I ever make a change to it, all scripts are updated. With this script however (and ONLY this one), the #Include statement errors out. It's another issue I've been trying to understand.
Is there a better way to handle CAPI in that routine that I've missed out on?

There are two devices involved in the first script: The "Living Room Front Blind" which is the Z-Wave module, and "Living Room Front Blind Status" which is my current status tracking virtual device (Closed, Closing, Open, Opening). The latter has Value/Status Pairs to match. This was the script I'd used all along, and for whatever reason, now doesn't work for me. In the second script, I call the extra event to control the real Z-Wave device while still tracking the status of the Virtual device in the script..

There are two devices involved here: The "Living Room Front Blind" which is the Z-Wave module, and "Living Room Front Blind Status" which is my current status tracking virtual device (Closed, Closing, Open, Opening). The latter has Value/Status Pairs to match. In the second example, I call the second event to control the real Z-Wave device.

[Uncle Michael]

I thought I was. That's what the "DeviceAction" routine is doing in the first script.

Sorry, I missed the function call. Should have realized that it contained the 'meat'.

If the same function works when called from other scripts, maybe this one has become corrupted.
Have you tried to recreate it from scratch? (Or just force a recompile?)

[Wadenut]

If the same function works when called from other scripts, maybe this one has become corrupted.
Have you tried to recreate it from scratch? (Or just force a recompile?)

Yup. Retyped the entire script from scratch, just in case. This is why I titled the post "Device Weirdness"
Thing is there are Zero log errors. Simply a mystery. I may just have to live with the alternate method.

[Uncle Michael]

Weird indeed.
The only thing I can think of is to start with a working script that uses the function call and performs as you expect, then slowly make changes to it to convert it to the script that doesn't work. If you can find a step the "breaks" the script, that might offer a clue. The only reason to keep going on it, though, is curiosity and stubbornness. If you've got a method to do what you want, just using it instead will be a lot easier.

[Wadenut]

I'm nothing if not stubborn. Even if I do take a break from this one to work on some other, less vexing issues, I will eventually figure it out.

[Wadenut]

I think I understand what's happening with at least the #Include statement in this case. This is going to be long and convoluted.

Long Version:
I still use a number of X10 PalmPad remotes in separate rooms (haven't found any better alternative), controlling in all sixty-seven events so far. I use a single script file for these which contains several subroutines to handle various functions for particular buttons. ON and OFF buttons on each remote trigger individual events giving me the capacity for up to thirty-two functions on each PalmPad. Each button also has an associated virtual device in HS to track it's last use, mainly for display and control on/from HSTouch screens.

The RemoteControl.vb functions are:
Sub Direct(RemoteDevice As String)
' Use to control a device directly by Remote On/Off Button. Does not modify Remote Button DeviceString
' Parameters --- RemoteButtonCode|Room and Device to control
Sub SetInDirect(RemoteDevice As String)
' Use to control a device indirectly by Remote Button. Modifies the Remote Button DeviceString with the controlled Device Name
' Parameters --- Remote Button Code|Room And Device to Control
Sub Enable(RemoteDevice As String)
' Use to Set or Reset the remote button to enable or disable some function. Modifies the Remote Button DeviceString with the controlled Device Name + Enable/Disable
' Parameters --- The Remote Button to Set|String to Display + "Enabled" or "Disabled"
Sub RunScript(RemoteParameter As String)
' Use to run a script with parameters by Remote Control Button. Sets the Remote Button DeviceString as Specified.
' Parameters --- RemotebuttonCode|ScriptToRun|ScriptParameters|ButtonString
Sub RunEvent(RemoteParameter As String)
' Use to execute an event
' Parameters --- Event name to run
Sub Toggle(RemoteDevice As String)
' Use to Toggle the State of a Device. Sets the Remote Button DeviceString to On or Off to reflect the set device new status.
' Parameters --- RemoteButtonCode|Room|Device

I've used this method for at least 15 years now, up until recently under HS2.
With my conversion to HS3 in March, and with the absence of hs.ExecX!0 or hs.Transmit, making the CAPI necessary, I'd used #Include to keep the CAPI functions separate in case I ever made changes, to avoid having to edit many dozens of separate scripts. I did not need to use #Includes for this purpose under HS2.

All of the above routines within my RemoteControl script work fine with the exception of the "RunScript" routine, which I've discovered I only use in a single Remote Control Event -- The Front Blind Toggle (Open if it's closed, Close if it's open) controlled by a single button on the PalmPad remote (P6 OFF in this case).
This routine thus follows this control path:
ButtonPress --> Trigger Event --> Run RemoteControl.vb with parameters (Script to run + parameters to pass to that script) --> Calls the required Script with parameters: Front Blind.vb("Toggle").
This second script is the one in which the #Include statement errors. I've checked, and found the FrontBlind script to be the only instance where the #Include could not be used.
I don't know the first thing of how HS implements vb scripting but it does seem to have this limitation.

Clear as mud?

Short Version:
Using #Include within a vb script called from within another vb script using hs.RunScript or hs.RunScriptFunc does not appear to work in HS3.

As for the Z-Wave module not actually being activated using CAPI within the script, even though HS indicates it has been (the Device Weirdness)... that's another issue. This one, as I've said, reared it's head with the conversion to the SmartStick from the Z-Troller a few weeks ago.