actionControlGeneral compatibility handling

I just noticed that my plug-in devices have stopped handling status requests properly. Digging back, I realized that I quite slept through the part of the API v1.11 release notes that describe the new actionControlGeneral callback. Apparently nobody really much cares about status update callbacks in my plugins, or at least nobody cared to complain.

The API 1.11 release notes say, "If the plugin does not define the actionControlGeneral callback, then device status request actions will continue to be dispatched to the device specific callbacks." That doesn't seem to work with cyin; It looks like Indigo gets confused because my Plugin (base) class contains a __getattr__ method. Do you by any chance call getattr() to check for presence of actionControlGeneral? Getattr() will always "find" any name in a class that has __getattr__. A better check might be

Code: Select all

 'actionControlGeneral' in dir(plugin)

I'll add actionControlGeneral to my harness and leave the old status handling code for pre-1.11 apps. You may want to keep this in mind next time you add method fallback behavior, though.

Cheers
-- perry

[matt (support)]

Shouldn't your __getattr__ method do a 'raise AttributeError' if the attribute doesn't exist? Not positive, but if it does then I think Indigo's logic to determine if that function exists would work. As to what Indigo is doing in this case, it is a bit complicated because it is actually occurring in C code via the python API and not python source.

Shouldn't your __getattr__ method do a 'raise AttributeError' if the attribute doesn't exist? Not positive, but if it does then I think Indigo's logic to determine if that function exists would work. As to what Indigo is doing in this case, it is a bit complicated because it is actually occurring in C code via the python API and not python source.

You're right that cyin.Plugin should throw AttributeError for a name it doesn't want to handle. Unfortunately, cyin.Plugin reflects xml-specified calls to other objects; it can't figure out where a call should go without looking at the call arguments; and it needs to decide whether to return a Forwarding object (or not) without seeing the arguments. So it always returns a forwarding object that then fails when you call it.

Anyway, it's not a big deal, but I wanted you to be aware of it. If it ever gets to be a major problem, I could scan all the xml files for callback specifiers and make a comprehensive list of allowed names to check against. Meanwhile, I'll pay closer attention to the API release notes.

Cheers
-- perry