HS is not updating Stargate Flags

[lschweiss]

I'm using HS version 2.2.0.66 and the StarGate plugin version 2.1.2614.17538. The plugin is receiving flag changes from the Stargate, but whenever they are reset (off) on the device status page or via a script command hs.SetDeviceStatus they are unchanged on the StarGate.

It seems this bug was causing problems for others quite a while back. Is there a fix or a workaround?

[Uncle Michael]

I've found that the most reliable way to change the state so SG notices is to use the ExecX10 function.

[lschweiss]

It seems something is not right in the plug-in. Every time I change a flag in my script it is followed by a then macro. The macro is always excuted, flag status is rarely updated. The other way around when the StarGate changes a flag about 50% of the time HS notices. It always seems to work for a while then quit.

I'm not using variables for interaction between HS and SG. Anyone found them to be more or less reliable than flags?

[Uncle Michael]

It seems something is not right in the plug-in. Every time I change a flag in my script it is followed by a then macro. The macro is always excuted, flag status is rarely updated.

How are you determining that the flag status is not updated? I've found that WinEVM often is not aware of the flag change, but SG is. That seems to be what is happening when the macro fires. I believe that when HS communicates to SG, SG thinks it is hearing the input from WinEVM. (SG has no idea that HS exists, HS is just emulating WinEVM as far as I can tell.) So, when SG gets a status update for a flag, there is no reason it would echo it back to WinEVM.

The other way around when the StarGate changes a flag about 50% of the time HS notices. It always seems to work for a while then quit.

I see this occasionally, but certainly not frequently. Probably less than 1%. I've built some redundancy into some of my more critical events to allow for a missed transition.

I'm not using variables for interaction between HS and SG. Anyone found them to be more or less reliable than flags?

I use both. I have no quantitative data for how reliable the variable communication is, but using ExecX10 I've never had something fail in a way that I could attribute it to failure to communicate the device value to a SG variable. (SetDeviceValue is not reliable, however, in my system.)

[lschweiss]

How are you determining that the flag status is not updated? I've found that WinEVM often is not aware of the flag change, but SG is. That seems to be what is happening when the macro fires. I believe that when HS communicates to SG, SG thinks it is hearing the input from WinEVM. (SG has no idea that HS exists, HS is just emulating WinEVM as far as I can tell.)

If I turn flag polling on every time the pole happens the flag(s) that have been toggled by HS are no longer toggled.

I observed the non awareness of WinEVM to things that HS changes. I have started WinEVM after toggling several flags only to realize the flags were no longer in sync with HS.

Is anyone at HS aware of this problem and working on a fix? Variable and flags are necessary means of communicating with the SG. There are not enough X10 devices available to make a virtual flag for each one I need on top of the X10 devices already assigned.

[Uncle Michael]

If I turn flag polling on every time the pole happens the flag(s) that have been toggled by HS are no longer toggled.

I strongly recommend that you keep polling off. It isn't necessary and, as you and others have discovered, it can cause problems of its own. As far as I know, the only devices that require polling are those attached to an expander box.

I observed the non awareness of WinEVM to things that HS changes. I have started WinEVM after toggling several flags only to realize the flags were no longer in sync with HS.

Is anyone at HS aware of this problem and working on a fix? Variable and flags are necessary means of communicating with the SG. There are not enough X10 devices available to make a virtual flag for each one I need on top of the X10 devices already assigned.

I don't believe this is a problem with HS. It is a consequence of the limitations of the SG interface options. I also believe that there is currently no active support for this plug-in. RJ went back to school, I think.

With regard to X10 devices, perhaps I should have been more explicit. You do not need an X10 device code to make a device the target of ExecX10. For example, in my setup, flags I've imported into HS have the 'House Code' [. The commands: hs.ExecX10 "[5", "ON", 0, 0 or hs.ExecX10 "[3", "OFF", 0, 0 will give the same result (in HS) as hs.SetDeviceStatus "[5", 2 and hs.SetDeviceStatus "[3", 3, but for whatever reason, they are more likely to yield a change that will register with SG. To set a value, use the preset dim structure (preset dim values are stored as device values). Again, in my system, SG variable import with the 'House Code' of `: hs.ExecX10 "`50", "Preset Dim", 9, 0 will set the value of `50 to 9.