Coincident value changes and task triggers

[CouchPotatoe]

I have a situation where a plugin is updating several properties associated with a device all at the same time - the source is actually a single Ethernet packet (xAP) that groups values for several associated properties . Think of this as say Artist, Album, Track and Genre that all change at once but obviously are really updated within HB sequentially. What I think is happening is that the HB task associated with a property value change (or same value update) is being triggered before the other associated property value updates have actually happened... and so within the task when I check other parameter values they may not be current. Based on how HB handles task triggering this does this sound likely ?

Obviously this behaviour is correct technically so my next question is how can I work around this . Could I delay a fraction of a second within the task to allow for the other values to update - which will be near instantly ? I'm thinking a delay may not allow these updates to happen due to the way HB handles such things - and there's a potential problem that other parameter updates might trigger other tasks... Unfortunately the order of the parameter value updates isn't predictable with Artist sometimes changing when Album stays fixed or vv , and some values don't change at all. So I really want a mechanism to know that a complete set of related parameter values have all updated and are valid. I guess the plugin could maintain a 'complete' parameter that it always updated last that I could trigger off but is there another way ?

K

[Richard Naninck]

I would say your answer is writing a script. You will find it much more flexible and you can manage delays like they should be. I have found that delays in tasks not always work like you would expect. You could have a task trigger a script and go from there.

[CouchPotatoe]

I had originally thought that the HB internals might not allow the remaining parameters to update until my script relinquished control but it must be possible to just yield (do events) because big scripts like Oslers remain resident / are event driven . I am not sure if this related to it being a formally registered WSC though. I'll see what I can find to read up on script threading and I'll play a bit , I can always just use the task as nothing more than a trigger to the script although I wonder if then I might have to handle multiple overlapping triggers.

K

[ScottBot]

You could also add another Property to the Device that gets set when all of the other Properties have their correct values. The Caller ID plugin does this. It first sets all of the call info Properties and then sets a 'caller info received' (or something like that) Property. This allows a Task to just have a condition to execute when that Property is set to 'Yes', and it can be assured that all of the other properties have been set.

Or if you know the last Property that the Device sets (and it gets set each time), you can have a Task condition to just trigger when that one Property changes.

[CouchPotatoe]

Yes - In the first post I'd mentioned this as a possible change to the xAP plugin, which by nature of xAP device 'schema' has many grouped property values... and so it would be very do-able. Although I used a music example my issue manifested itself with CallerID too (I was picking up the last name rather than the current one). Unfortunately in some applications eg the music example it's not consistent which order properties update in, and therefore not possible to trigger on the last one .