Global Property Manager

[jay (support)]

This simple plugin allows anyone to add arbitrary properties to any device object. Properties are different than states - they are somewhat hidden bits of information that can be used by Python scripts or other Plugins. For example, if you have a script that needs to be able to connect a device to another Indigo object (like an Action Group), then in the past you'd have to store it somewhere else like a file. With global properties, you can add extra properties to a device that can be accessed by your script.

A couple of things to keep in mind: scripts can't add/change/delete these properties (for security purposes) - they are read-only. You must use the Plugins->Global Property Manager->Manage Device Properties... menu item to add/edit/delete the properties. Next, to access the properties from your script, you'll need to access them this way:

Code: Select all

# First, get the device
myDevice = indigo.devices[DEVICEIDHERE]

# Next, get the props - we use the ID for the server for this particular set of properties
theProps = myDevice.globalProps["com.indigodomo.indigoserver"]

# Finally, access the value of the property. Use the get method here so that you can later test for None in case the property doesn't exist on the device
myPropertyValue = theProps.get("someKeyHere", None)

You can download it from the File Library. This plugin requires Indigo 6.0.19 or later.

Because there is no way to segregate keys in this global space, I recommend that you prefix your keys with some combination of letters that is somewhat unique to your particular usage. I'm working on a script called Low Battery Notification (which I'll publish later separately), so I'm naming my keys with the "lbn" prefix, which will help distinguish them from other properties. It's just a suggestion of course, but it'll help eliminate naming conflicts.

[kw123]

I have version .20 and yosemite.

tried to use the menu plugin/Global ../ manage feature.

None of my 20 devices I tried had any entry as property (z-wave dimmer, my own plugin devices, instead devices....)

which devices should have a property?

thanks

Karl

[jay (support)]

None will show by default because only properties added through this plugin will show.

[richo]

That's what I just wanted to ask for as a feature request. You guys are really faster then light


Sent using Tapatalk

[richo]

Is there any possibility to add the same property to a couple of devices in one step ?

Also it would be good to allow for changing at least the value from the script...

[jay (support)]

Is there any possibility to add the same property to a couple of devices in one step ?

It would be possible (though a bit tricky). I'll make a mental note (don't hold your breath though) or someone can offer a patch the the current plugin to do it.

Also it would be good to allow for changing at least the value from the script...

Yeah, that would be nice. Changing those values directly won't happen soon because of how we sandbox plugins. An action (which could also be scriptable) could be added to the plugin for editing values though. Another mental note and another offer of accepting a patch to the plugin that would add it...

[dduff617]

do i understand correctly that these properties can be written to from via the plugin UI but are read-only from scripts?

if so, may i ask why was the plugin designed that way? is there some other mechanism that one could use that would allow a trigger or script to update arbitrary property values on devices?

[RogueProeliator]

if so, may i ask why was the plugin designed that way?

As Jay said previously in this thread -- Changing those values directly won't happen soon because of how we sandbox plugins. Plugins cannot change another plugin's properties; this is a very good, normal design for keeping plugins segregated.

is there some other mechanism that one could use that would allow a trigger or script to update arbitrary property values on devices?

I plan on adding an action to this plugin shortly that will allow updating the value (via script or standard Action UI) as I have a direct need to do so. I'll submit the patch for it for inclusion in the main download when complete.

Adam

[dduff617]

As Jay said previously in this thread -- Changing those values directly won't happen soon because of how we sandbox plugins. Plugins cannot change another plugin's properties; this is a very good, normal design for keeping plugins segregated.

that makes sense, but there's a view that GPM provides (or at least could provide) a public playground, separate from all plugin-specific protected sandboxes. ... and in so doing open up capabilities for utility scripts and such that are not themselves full-blown plugins. this is my angle (in case it wasn't obvious).

I plan on adding an action to this plugin shortly that will allow updating the value (via script or standard Action UI) as I have a direct need to do so. I'll submit the patch for it for inclusion in the main download when complete.

that sounds great and is what i had in mind when i asked the question. adding a method to the plugin was a direction i considered going myself, though i don't have much experience with the nuances of the plugin development system. anyway, i will be happy to test it out.

thanks.

[jblackburn]

Hi,

In the same way, I've an issue with a plugin I’ve developed. During the process, I’ve changed an ID number of a menu type field in the “PluginConfig.xml”. All devices already created keep the old “ID” and gave errors because the plugin doesn’t find the new “ID” field. If you create a new device, Indigo will attribute the new ID... Instead of deleting and recreating all devices, is there a quick way to force the device to update to the new “ID” description? Can we use this same procedure for the plugin as for the device?

Thanks!

Joël

[RogueProeliator]

Instead of deleting and recreating all devices, is there a quick way to force the device to update to the new “ID” description?

You can just edit the device and re-save it (will have to re-select or enter the value again, though). Alternatively, you can handle this in code by doing the necessary changes via Python using the IOM Device call of replacePluginPropsOnServer.

Adam

[jay (support)]

Usually changes like this happen in the deviceStartComm() method - you look at the device that's about to start up and see if it's configured properly. If not, you can just fix it there. We do this in a variety of plugins by versioning each device instance - then we can just look at the instance version number and if it's an older device we can update it before we start it up.

[FlyingDiver]

Usually changes like this happen in the deviceStartComm() method - you look at the device that's about to start up and see if it's configured properly. If not, you can just fix it there. We do this in a variety of plugins by versioning each device instance - then we can just look at the instance version number and if it's an older device we can update it before we start it up.

Jay - I've been looking for some code examples on how best to do this, but can't find any. Can you share some code for implementing versioning?

Never mind, found http://forums.indigodomo.com/viewtopic. ... omm#p99070

Thanks!

jeo

[DaveL17]

I believe there's a bug in the validation routine for key values in the Global Property Manager plugin:

Code: Select all

import re

def validateKey(key):
    p = re.compile('\A(?!XML)[a-z0-9]+$', re.IGNORECASE)
    return bool(p.match(key))

def validateKeyNew(key):
    p = re.compile('\A(?!XML)[a-z]+$', re.IGNORECASE)
    return bool(p.match(key))

x = 'A'
y = '1A'

print validateKey(x)
print validateKey(y)
print
print validateKeyNew(x)
print validateKeyNew(y)

Which yields:

Code: Select all

================================================================================
Jul 27, 2016, 8:37:12 AM
untitled text 6
--------------------------------------------------------------------------------
True
True

True
False

I must admit that I don't really understand regex that well, but my simple patch seems to solve the problem.
Dave

[jay (support)]

True - but your solution also fails because it doesn't allow any numerics. XML keys can't start with a number, but they can contain a number (or hyphen, period, underscore). I think this is the correct XML validator:

Code: Select all

def validateKey(key):
    p = re.compile('\A(?!XML)[a-z_][a-z0-9_\-\.]*$', re.IGNORECASE)
    return bool(p.match(key))

However, I'm not positive that Indigo's XML validator is in fact that precise. So, to keep the current validation and to make sure it doesn't start with a number, I think I'll go with this:

Code: Select all

def validateKey(key):
    p = re.compile('\A(?!XML)[a-z][a-z0-9]*$', re.IGNORECASE)
    return bool(p.match(key))

This says that it can't start with XML (in any case combination), the first letter must be alphabetic, and then any combination of alphanumerics.

v1.0.2 is available in the File Library.