Indigo Domotics

jay (support) wrote:

Opened then closed the plugin prefs dialog (no changes) and got this:

Code: Select all

   MyQ Error                       Error in plugin execution UiClosed1:

Traceback (most recent call last):
  File "plugin.py", line 222, in closedPrefsConfigUi
  File "plugin.py", line 409, in getDevices
ValueError: invalid literal for int() with base 10: ''

Same for trying to lock/unlock...

Actually, it's just similar:

Code: Select all

   MyQ Error                       Error in plugin execution ExecuteAction:

Traceback (most recent call last):
  File "plugin.py", line 280, in actionControlDevice
  File "plugin.py", line 491, in changeDevice
ValueError: invalid literal for int() with base 10: ''

Were there existing MyQ devices? Before or after they were recreated? I haven't been able to reproduce that error.

And this is now repeating:

Code: Select all

Feb 19, 2017, 2:25:50 PM
   MyQ Error                       Error in plugin execution runConcurrentThread:

Traceback (most recent call last):
  File "plugin.py", line 94, in runConcurrentThread
  File "plugin.py", line 409, in getDevices
ValueError: invalid literal for int() with base 10: ''

   MyQ Error                       plugin runConcurrentThread function returned or failed (will attempt again in 10 seconds)


Will disable for now.

It was an old one - but I first switched it to an X10 device (so all the myq settings would go away) then switched it back to a myq device.

BTW, when you create a new device the only thing configurable is the sensor - how does it know how to identify the door?

New version is working fine for me. Thanks so much!

(Was a little confused initially that it created a garage door opener device by default. Once I figured that out, all was good.)

blysik wrote:

New version is working fine for me. Thanks so much!

(Was a little confused initially that it created a garage door opener device by default. Once I figured that out, all was good.)

Wait, what? I'm confused...

jay (support) wrote:

It was an old one - but I first switched it to an X10 device (so all the myq settings would go away) then switched it back to a myq device.

BTW, when you create a new device the only thing configurable is the sensor - how does it know how to identify the door?

It gets the name of the door from the MyQ servers (plus the MyQ unique ID). I had to fiddle that code a little because I had at least one user that didn't use unique names.

The devices really need to be deleted and let the plugin create new ones. You should never need to create new devices manually. I know that's not the norm for Indigo. I guess I could redo it to cache the known devices and let the user create them the normal way.

jay (support) wrote:

blysik wrote:

New version is working fine for me. Thanks so much!

(Was a little confused initially that it created a garage door opener device by default. Once I figured that out, all was good.)

Wait, what? I'm confused...

This is in the original announcement of the plugin. The plugin automatically creates devices for all known MyQ openers. The user doesn't need to. But I could never figure out how to prevent it. See my other comment as well.

I had the same errors as Jay, after renaming the existing MyQ device and changing it to X10. However, I went ahead and deleted it (painful due to how many actions groups called it) and everything is working fine now.

Thank you!

JP

FlyingDiver wrote:

It gets the name of the door from the MyQ servers (plus the MyQ unique ID). I had to fiddle that code a little because I had at least one user that didn't use unique names.

The devices really need to be deleted and let the plugin create new ones. You should never need to create new devices manually. I know that's not the norm for Indigo. I guess I could redo it to cache the known devices and let the user create them the normal way.

Ah. I was confused because you mention above that the device had to be recreated - so that's what I was trying to do...

I'd highly recommend that you follow the normal Indigo pattern - only create a device when the user goes through the standard new device creation steps/experience. It's a fundamental process that every Indigo user learns early and to do otherwise is pretty jarring. It's a bit like those old ports of windows (or java) apps to the Mac where it just feels wrong. There are some places where we do it, but that's only when there are dependent devices (airfoil speakers on an airfoil instance) or multi-function devices (multi sensors which have motion, temp, humidity, etc). But the user starts the process the same way by creating a new device so it still follows the UX pattern.

It would also solve the problem that anyone doing this upgrade is going to have to deal with: editing ALL locations where the door device is used. The process is much easier if the user can just "fix" the device that's already there (thereby preserving all dependencies) vs having to go to all dependent locations to change them to use the new device.

Just some thoughts...

Yeah, I was always a little concerned about doing it that way. I'll revamp it for the next release.

FYI

tried 7.1.6 - seems to work status wise

Deleted old sensor items and added new

GBear wrote:

FYI

tried 7.1.6 - seems to work status wise

Deleted old sensor items and added new

Likewise, I'm having good results from 7.1.6. Haven't tried 7.1.7 yet.

I haven't installed this plug-in yet, because I just saw it in the announcement sent out about all the Indigo plug-ins. But I have one question: does it support fingerprint recognition the way the native app does? Otherwise, do you have to login each time?

Also, has anyone integrated this with Alexa?

Thanks.

kennybroh wrote:

I haven't installed this plug-in yet, because I just saw it in the announcement sent out about all the Indigo plug-ins. But I have one question: does it support fingerprint recognition the way the native app does? Otherwise, do you have to login each time?

Also, has anyone integrated this with Alexa?

Thanks.

The plugin uses your MyQ website login information, it saves the username and password in the plugin preferences. Since it represents the opener devices as locks (locked == closed), if Alexa does locks then it should work.