RegisterStatusChangeCB -- change a device status/value without CB?

[The Keeper]

Hi there,

I've implemented a full RegisterStatusChangeCB handler, and have been successful in trapping device changes and acting upon them, but I have an interesting corner case that I'm trying to work through. I have a few legacy devices that are being monitored by a microcontroller, and then an ASCII string is emitted when that legacy device toggles.

What I am trying to figure out is how I can update the status and value without RegisterStatusChangeCB even knowing about it. What ends up happening now is:
- legacy device changes and ASCII is emitted
- ASCII received, COM port script updates virtual device state via HS calls
- virtual device state update from COM port script causes RegisterStatusChangeCB to be called
- RegisterStatusChangeCB script detects virtual device change and causes ASCII to be emitted
- the ASCII emitted to microcontroller tells the legacy device to change its state to what it was already just changed to

Fortunately the loop stops there, because the legacy device is already at this new state, but this is a lot of unnecessary extra work, and could create a race condition.

CAPIControlHandler is the default mechanism for updating the virtual device, but that obviously will cause the CB to be executed.

I also tried SetDeviceValueByName and SetDeviceStringByName, but that also causes the CB to be executed.

Does anyone know if there is a way to set the device value and status "silently"?

Thanks,
Chris

[alexbk66]

In my plugins (not script) I use UpdateFeatureValueByRef (for devices in my plugin) and SendControlForFeatureByValue for other devices.

[Michael McSharry]

hs.SetDeviceValueByRef(dvRef,value,trigger) is one form of updating HS device where the trigger parameter is set false if Value CB is not desired. When doing the equivalent with String rather than Value the third parameter only affects if LastChange property is updated automatically or not. It is not clear what CB you are using in your logic, but it seems it is the String callback and setting DeviceString does not have provisions to control the trigger.

As Alex indicated HS does have provision to ask a plugin to control hardware and when the hardware responds the plugin then updates the HS status. Since you are working with virtual rather than plugin devices I do not think this mechanism applies, but I could be wrong. The scripting method of interest is CAPIControlHandler, but in the end you still will need to get the HS DeviceString updated and then the CB will occur.

I have similar issues that you see when working with the CB. My general strategy is to remember if I initiated the change and then ignore the callback otherwise treat the callback as a request for me to do something with it.

[The Keeper]

In my plugins (not script) I use UpdateFeatureValueByRef (for devices in my plugin) and SendControlForFeatureByValue for other devices.

Interesting, I've been scripting for quite a while, and I also don't see it in the HS3Help, but that's one I'm not familiar with. Does it work on regular HS devices, or just ones associated with a plug-in?

Thanks,
Chris

[The Keeper]

I have similar issues that you see when working with the CB. My general strategy is to remember if I initiated the change and then ignore the callback otherwise treat the callback as a request for me to do something with it.

Thanks for the reply Michael, that actually gave me an idea of how to work around this.

Rather than try to convince RegisterStatusChangeCB that it should ignore the change, have the virtual device set to values that represent "RxdOn"/254 "RxdOff"/255. RegisterStatusChangeCB can do what it's supposed to do -- if the new value is 254, it would do the CAPI control to "On", and then it can easily be set up to ignore when the OldVal is 254 and the NewVal is 100. The only time the 254/100 or 255/0 combos would be seen is when the device locally changed state, and user requests would simply be 100/0 or 0/100.

Thanks for the nudge in the right direction!

Chris