Pass an event to a plugin from outside Indigo

Actually, at least in the case of apcupsd, the added support is not hard to setup -- copy 2 files to /usr/local/bin

The user must also modify the individual event handlers in /etc/apcupsd. However, there is a simple shortcut here -- create one handler, say commok then just ln (link) it to the other various names. I can put that into a short shell script if there is a need. SInce the name of the handler (must) correspond to the apcupsd event, and I used the same names in the plugin, the command uses `basename$0` and all the handlers can, therefore, be the same (in this case, literally the same inode).

While this approach is actually pretty elegant for one or more instances of apcupsd running on the same server, it does not support events from an apcupsd running on a remote server, though it is possible to run apcupsd locally as a slave for a remote daemon, and that will probably work. OTOH, syslog, while a pain to setup and configure for network logging on MacOS, could get around that issue by forwarding all events to syslogd on the Indigo server.

I think, in the end, the best approach, and one I may implement if there is sufficient use of this plugin, is to maintain a TCP listener thread in the plugin, and then use something like curl to send the events from the handler scripts, simple, straight forward and no need for "glue" files.

syslog would have worked. Mostly I wanted to see if I could get something truly event driven rather than event responsive. I could also have created a little shell script to tail -f | grep <event messages from apcupsd> the log and matching lines into the plugin via IndigoPluginHost.

You realize you can use the ASL API to watch syslog events as they're coming in, right?

That would be a really easy plugin to write, even generically.

Cheers
-- perry

...
You realize you can use the ASL API to watch syslog events as they're coming in, right? That would be a really easy plugin to write, even generically.

Actually, I was not aware of ASL, but I am now. Thanks. It even seems like there is a Python module available that looks like it will run in Python 2.5 (I haven't tested it yet though). I agree, a generic ASL plugin would probably be a very nice addition to Indigo - it would add the ability to trigger on a myriad of events, including presence notification, like Smartphone radar. My todo list or yours

However, in this particular case, I think that for 2 reasons I will still stick with my present plans. 1) I just like the idea of synchronous communications, and 2) using an IP level interface makes it much easier to access the plugin from remote systems.

BTW, I have this working quite nicely now. Though, I am thinking of adding SSL. The issue here is necessity... The event messages consist of a device identifier (currently the deviceId) and an event keyword: e.g... 1234567:commfailure I am not sure if there is much benefit/value in encrypting that message. I will add the ability to limit the IP Addresses that event messages will be accepted from. (Sure wish we had the ability to do visibleBinding on non-empty text).

My todo list or yours

I'll put it on mine. Don't hold your breath though; I've still got several finished plugins that I haven't published yet...

Cheers
-- perry

[jay (support)]

(Sure wish we had the ability to do visibleBinding on non-empty text).

I'm not convinced it's good UI practice to show/hide fields based on text in another field. Enable/disable yes, how/hide though - I've never seen a good example of that working well.

...I've never seen a good example of that working well.

I think Perry noted the case in his original post - the one I referred to earlier in this thread. The example is allowing zero or more textfields to be displayed, for example, collecting a list of IP Addresses.

The first textfield is made visible by a checkbox field being selected. Like "Open IP Socket listener: []"
The second text field is made visible if any data is entered in the first textfield -- essentially visibleBindingValue=".+"
The third field is keyed to the second, and so on for as long as the chain runs.

You would have to be careful when processing the valuesDict in case someone had filled in fields 1 through 6 and then deleted the value from six. In this case, any entries after the first blank field should be ignored.

I'm not convinced it's good UI practice to show/hide fields based on text in another field. Enable/disable yes, how/hide though - I've never seen a good example of that working well.

A basic Macintosh HIG rule is not to rearrange the UI positions dynamically because it defeats user muscle memory. So the "disable, don't hide" rule is a good baseline. There's always exceptions, though; like UI alternatives (particularly since we don't have visual groupings, or radio groups, or... lots of other stuff). In any case, your disable and hide machineries should work exactly the same; it's just too confusing (to your developers) otherwise.

You know, you could pretty much get out of further work by just giving all UI elements a callback. (The callback for a text field would be called when the user tabs out of it.) This (together with the dynamic reload for menus) should allow us to manage UI with sufficient precision (if necessarily, by adding hidden config variables to drive visibility). You are updating visibility/enabled after a callback completes, right?

Cheers
-- perry

[jay (support)]

berkinet: Doing your solution is much better accomplished by having a list field with all your addresses in it (initially empty the first time the dialog is open), a text field and " Add" button to add something to the list, and a "Delete" button to delete the selected address(es) in the list. I believe the Device Factory example plugin illustrates one way to do it.

perry: Perhaps - it's something I've considered. There are some other limiting factors that I can't discuss at the moment though so we have to weigh carefully what we add. I don't believe that for this specific case there is a reasonable use-case. And developers should be smart enough to understand the variance in how disable and hide mechanisms work. And, in fact, have proven that they can figure it out with little trouble.

Yeah... I could do that with lists and buttons. But, it is a lot of work for a plugin that maybe a dozen people will use. I think I'll just punt and use a comma separated list in a single textfield.

However, I would argue that we have already enabled the capability I was asking about in most ConfigUi elements. Lists can be made visible based on the selection made in other lists. If I simply list all the options as binding keys I essentially have the same thing, just with lists instead of textfields, same for checkboxes, etc. The only difference is lists contain known values and textfields do not.

[jay (support)]

Building the list isn't that big a deal - particularly since I think most of the code is done in the device factory example (though I didn't write that one so I'm not positive). But, if it's too much bother and not that important to you then...

[jay (support)]

And, btw, adding it to lists/menus was necessary to enable hierarchical selections without breaking Apple's HIG about hierarchical menus in popup buttons (though I've done it in the actions dialog now). This does not apply to text fields.