startup bug and question.

[FlyingDiver]

On first install, got this error:

   Virtual Garage Door Error       Error in plugin execution startup:

  File "plugin.py", line 396, in startup
type: key loggingLevel not found in dict

   Started plugin "Web Server 2023.1.0"

Line 396 should be:

        level = self.pluginPrefs.get('loggingLevel', 'INFO')

Or similar.

Now the question - is there a reason you're specifying all the different possible relay types in the code, rather than just checking that the Indigo device is of type "relay":

  for dev in indigo.devices.iter("indigo.relay"):
      do something

[papamac]

Hi Joe,

Sorry, I'm just learning how to use GitHub messaging and I released my original comment prematurely. Please re-read my revised comment:

As we both know, the Indigo server initializes the pluginPrefs dictionary using the default values in the PluginConfig.xml file in the plugin bundle. The question is, when does this happen in the global plugin initialization sequence? Because pluginPrefs is an instance attribute, we know that it cannot occur until after the Plugin class is instantiated and the Plugin.init method is called. I erroneously assumed that the xml initialization occurred in the subsequent call to the superclass PluginBase.init method:

indigo.PluginBase.__init__(self, pluginId, pluginDisplayName,
                                   pluginVersion, pluginPrefs)

Clearly, this was not true because the reference to self.pluginPrefs['loggingLevel'] failed with a key not found error. This was only a problem on the first execution of the plugin after install because on subsequent executions the pluginPrefs dictionary is initialized from the Indigo database (presumably in the indigo.PluginBase.init call). I chose to solve this problem by removing references to the pluginPrefs from the init method and then adding a startup method in VGD v1.2.1:

def startup(self):
        """
        Setup THREADDEBUG logging and subscribe to device state changes.
        """
        self.indigo_log_handler.setLevel(NOTSET)
        level = self.pluginPrefs['loggingLevel']
        L.setLevel('THREADDEBUG' if level == 'THREAD' else level)
        L.threaddebug('startup called')
        L.debug(self.pluginPrefs)
        indigo.devices.subscribeToChanges()

This approach works on first and subsequent executions and has the advantage that the default loggingLevel actually comes from the xml file and not from a hard-coded statement in init.

On the second question, I do not use the indigo.relay enumeration because it excludes a number of deviceTypeId's (digital output devices, EasyDAQ devices, et al) that are useful as VGD activation relay devices. I prefer to know exactly what device types are allowed.

Thanks for your interest in VGD.

David

[FlyingDiver]

Actually, I'm not sure that's exactly right. If the plugin has been run before, and the preferences file has been created, then it's read during the superclass init. If it's not, then the config file isn't read until the config dialog is presented. Which is supposed to happen immediately on first start, but I'm not sure if it's before the startup routine or after. And I'm not sure that always happens when it's supposed to. I never depend on it. So I always use the .get() to make sure I don't get an exception on any dict that I didn't create in my own code.

Matt or Jay would have the definitive answer on this.

[papamac]

Hi Joe, I did some more research/tests and confirmed your analysis. I was totally wrong! The xml file is only used by the configUi and never sets the pluginPrefs directly. If run previously, a preferences file is read by the superclass init and used to fill self.pluginPrefs. If it is a first time run, self.pluginPrefs will always be empty…even in the startup method. The server may force the configUi to execute, but it doesn’t seem to happen all the time. Anyway, you proposed the only workable solution. Thanks for your help. I will upload a new VGD 1.2.2 with the correct fix later today.

Thanks again,

David

[FlyingDiver]

You're welcome.

Now, about that search for the relay type devices....

[papamac]

I made a list of the "indigo.relay" devices in my system. It included all of my relay devices except the EasyDAQ device. Unfortunately it also included about 30 on/off switches that are not used as relays. My list of deviceTypeId's also includes many of these as well due to user requests for additional devices. Anyway, I think that I prefer to explicitly control the supported devices list forth relay and sensor devices.

BTW: Are you using or do you plan to use VGD? If so, I hope that it works well for you. Let me know if you have any suggestions.

David

[FlyingDiver]

I'll probably use VGDO when I wire up either the ratgdo or a shelly relay. Haven't decided which I'll do yet. I also only have one tilt sensor on each door, so I might need to get a couple more. Depends on how well it works with just the one.

[papamac]

I recommend using a closed sensor and an open sensor. Using only one sensor works fine for normal opening/closing, but will not detect/report obstructed opening/closing.