Myq failing post 0.47 upgrade

Unfortunately I’m not qualified to answer that as I’ve almost exclusively ran it in docker since I started using it.

@turboc I saw that you took the plunge into python 3.6. How is myq doing for you now? Was it still not working prior to 3.6?

It was not working prior to 3.6. It wasn’t working after 3.6 either, till I removed the custom component we were playing with. Now it’s working fine on the standard component. If you want me to help out testing the custom component though, I’m happy to help.

Hmmm. It appears that my MqQ has gone wonky, too. When I see the entity in the UI, there are no longer any controls to open or close it. The cover entity is created, but if I manually call cover.open_cover, the service fails. No errors in home-assistant.log related to MyQ or “cover”.

I recently upgraded from .47.1 to .49.1

Clear your cache. Same thing happened to me.

Thanks. That did the trick! Strange. I can understand the cache causing an issue with display – it’s weird that it also caused an issue calling the service manually. Clearing the cache and calling the same exact service call worked fine.

@lordsiris
I had the same error as @turboc with the KeyError on ‘Devices’ after updating to 0.49.1. I opened an issue on it. https://github.com/home-assistant/home-assistant/issues/8712.

I went ahead and tried the custom component you posted and I’m getting the same python bugs reported by turboc here (Myq failing post 0.47 upgrade - #16 by turboc) which is basically a python typeerror. I’m on Python 3.4.2.

2017-07-29 21:34:54 ERROR (MainThread) [homeassistant.helpers.entity] Update for cover.garage_door_opener fails
Traceback (most recent call last):
File “/srv/homeassistant/homeassistant_venv/lib/python3.4/site-packages/homeassistant/helpers/entity.py”, line 225, in async_update_ha_state
yield from self.hass.async_add_job(self.update)
File “/usr/lib/python3.4/asyncio/futures.py”, line 388, in iter
yield self # This tells Task to wait for completion.
File “/usr/lib/python3.4/asyncio/tasks.py”, line 286, in _wakeup
value = future.result()
File “/usr/lib/python3.4/asyncio/futures.py”, line 277, in result
raise self._exception
File “/usr/lib/python3.4/concurrent/futures/thread.py”, line 54, in run
result = self.fn(*self.args, **self.kwargs)
File “/srv/homeassistant/homeassistant_venv/lib/python3.4/site-packages/homeassistant/util/init.py”, line 302, in wrapper
if force or utcnow() - throttle[1] > self.min_time:
TypeError: unorderable types: datetime.timedelta() > NoneType()

However, despite the errors, I am able to open and close the cover by calling the service through the UI (only open is available since HA thinks its perma closed) or manually. The UI fails to update though. Since I mainly use it for Alexa, I’ll live with this.

The custom component had some issues, especially if not on Python 3.6. It shouldn’t be used and I will go ahead and break the link. Use the standard component and try clearing your cache in the browser.

@alandtse I’ve previously looked into this issue on python 3.4, 3.5 and 3.6 and have been unable to replicate the issue using the standard component in 0.49.1.

The only real change to the standard component recently was adding persistent notifications (notifications that show in the HA gui when something with component config is wrong or it failed to start completely) but no changes in the communications to the myq cloud.

The “Key Error” message in the traceback is basically a result of login not working or a security token not being returned from the myq cloud. I think turboc might have seen the actual return from myq stating the login was invalid. If I intentionally set an incorrect username or password in my config file I get the persistent notification telling me it is wrong, that it needs to be fixed and to restart HA after fixing.

I can manually cause the “-3333” error that turboc mentioned if I send a get device request with an invalid security token.

In other words it’s definitely something related to login, maybe something specific to your username or password.

Try using quotes around the username and password or without quotes if you already have them.

Ok, did an update to 50.1 and moved back to the original component and it’s working again. I’ve made no changes to the configuration file so no idea what could have caused it.

That’s kind of my experience as well. The problem seems to come and go. I think it’s something with the MyQ hub, or their site. How did the 0.50.0 upgrade go in general?

I’ve upgraded to 0.50.1 and, although I don’t see this particular exception, my MyQ platform doesn’t work quite right: the platform state isn’t updated properly, meaning that after the first interaction, my only ability to open/close to cover is to call the service manually.

This is what is happening to me.

Let me make sure I understand the steps to duplicate this.

  1. Restart HA
  2. Does the garage state show the correct state at this point?
  3. If you open /close the garage door at this point using the remote or wall button, does the state update in HA?
  4. Open Garage door using HA (assuming it was closed to start with)
  5. Does the state update to Open at this point?
  6. Can you close the garage door using HA at this point?
  7. If you close/open the garage door using your remote or wall button, does it’s state update correctly in HA?

After Restarting HA everything is ok until you try to open it again.

Actually, after reinstalling HASS.io, the name of my cover changed from ‘cover.garage_door’ to ‘cover.home’ which is the name of the place in the Chamberlain app. But Home-Assistant didn’t know this until a fresh installation.

so is it working correctly now?

Yes it is. You may want to try logging into the app and/or the website, and then restarting HASS first. When I opened my app, it said it hadn’t been updated in 20 or 40 days, I can’t remember which. Now it’s updating correctly. It could just be that I had to re-login on the app/website.

All,

If it’s been a while since updating HA the MyQ stuff changed a number of versions back (can’t remember which) and the name parameter in the cover config is no longer used, so if that’s what configured in the HA site/app it probably won’t appear to work/update. The names of the doors are gathered from the myq cloud based on what they are named in the myq app. Hope that clears up some confusion.