[ANSWERED] Refreshing Plugin States

[jay (support)]

Matt beat me to it - if you think there's likely to be changes frequently, then versioning each instance is the way to go.

could you expand on versioning?

how do you do it and how does it work ...

Yes, I would keep a device property that is the version of the instance. If you then add or change the properties or states in an update, then you would update the version constant hard coded in the plugin. The startComm method would then check to see if the device instance is a legacy/older one compared to the hard coded constant, in which case it can call stateListOrDisplayStateIdChanged() and do any other needed updating (including bumping the version number to the newest one).

I guess I'm not understanding this fully. Is stateListOrDisplayStateIdChanged() completely rebuilding each device instance whether it needs to or not, or is it only making changes where there are differences between the instance and Devices.xml? I was thinking that the method would load the props from the xml file and compare that to what was presently in the device's props.

Regardless, I'm going to reduce the way I rely on this method since it seems to be using more horsepower than I realized.

Just out of curiosity, what is causing your plugin states to get out-of-sync... are you making state updates outside of the main plugin/device class or something? Or keeping two copies of states around? Seems like for "version changes" you should only need to do checks upon device startup and states themselves, if modified completely within your plugin, shouldn't get out of sync... ? This isn't a criticism, but a serious question to see if I have overlooked any potential issues in my own plugins.

Adam

[matt (support)]

could you expand on versioning? how do you do it and how does it work ...

Is psuedo code (actually more like incomplete python code) I do something like this:

Code: Select all

kCurDevVersCount = 4

inside deviceStartComm:
   instanceVers = int(dev.pluginProps.get('devVersCount', 0))
   if instanceVers >= kCurDevVersCount:
      return   # optimization: bail out since dev is already up-to-date
   if instanceVers < 1:
      # make changes to device to get it up to version 1, including calling stateListOrDisplayStateIdChanged if needed.
   if instanceVers < 2:
      # make changes to device to get it up to version 2, including calling stateListOrDisplayStateIdChanged if needed.
   if instanceVers < 3:
      # make changes to device to get it up to version 3, including calling stateListOrDisplayStateIdChanged if needed.
   if instanceVers < 4:
      # make changes to device to get it up to version 4, including calling stateListOrDisplayStateIdChanged if needed.

    # now that it is up-to-date, change the version property to the latest
    props = dev.pluginProps
    props["devVersCount"] = kCurDevVersCount
    dev.replacePluginPropsOnServer(props)

The idea here is to have logic that starts with the oldest changes and heals, or brings up-to-date, the device instance until it is up to the current version counter (kCurDevVersCount). By structuring the logic with the oldest healing first, it should be able apply the updates in the correct order so that even really old objects can be healed.

Whenever a change is made to the device instance structure or states, you increment kCurDevVersCount up 1 more and then add logic to deviceStartComm to handle the migration. We use this same basic technique internally in Indigo Server for all the database objects as we make major version changes.

Hey Adam - no worries at all, bud. I use this method solely to address instances where I add new states to existing device types. A great example is the recent update to the WUnderground plugin where I added rain and snow forecast amounts to the 10 Day Forecast device definition. It's my understanding that the best way to ensure that existing devices get the new states is to call this method.

Dave

[matt (support)]

I guess I'm not understanding this fully. Is stateListOrDisplayStateIdChanged() completely rebuilding each device instance whether it needs to or not, or is it only making changes where there are differences between the instance and Devices.xml? I was thinking that the method would load the props from the xml file and compare that to what was presently in the device's props.

Regardless, I'm going to reduce the way I rely on this method since it seems to be using more horsepower than I realized.

It doesn't destroy and re-instantiate the device. It just tells the Indigo Server that the state list might have changed, so Indigo re-queries the plugin for the state information (found in the devices.xml file). For that there is some interprocess communication that has to occur between the plugin -> server -> plugin and then back the other direction. It is generally fast, but still worth adding some logic to only call it in deviceStartComm if the state list (devices.xml) has really changed. Note it doesn't do anything with the device's pluginProps – only the states.

It doesn't destroy and re-instantiate the device. It just tells the Indigo Server that the state list might have changed, so Indigo re-queries the plugin for the state information (found in the devices.xml file). For that there is some interprocess communication that has to occur between the plugin -> server -> plugin and then back the other direction. It is generally fast, but still worth adding some logic to only call it in deviceStartComm if the state list (devices.xml) has really changed. Note it doesn't do anything with the device's pluginProps – only the states.

Thanks Matt - that makes sense to me. I'll look at building in some versioning into future updates to further reduce the overhead of my plugins. Really appreciate the detailed explanation!

Dave

I didn't realize I was creating such a complex thread, but I'm glad I did because it answered both of my questions about approaching state changes as well as not over taxing the program with the plugin to do it.

When it comes down to it, I'll approach plugin scripts the same as I do with my .NET and Obj-C programs, check the version and do my updates as needed.