I don’t get that error “Data must be padded to 16 bytes boundary in CBC mode” and am able to control my device from HA 0.67.
It looks like it’s something to do with the size of the data when we do the encryption to talk to the Gogogate device.
My username is 5 characters and password and password 17 characters.
Can you let me know how long your username/password is @Chris_Quach and I’ll see if I can replicate the problem.
@antoinevandenhurk we don’t need the UDI since that’s for remote access only, and this integration is local. I couldn’t get remote access working after they did the recent firmware upgrade.
In addition to password errors, I moved over to another RPI3 and received this
Error while setting up platform gogogate2
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/homeassistant/helpers/entity_platform.py", line 82, in async_setup
SLOW_SETUP_MAX_WAIT, loop=hass.loop)
File "/usr/lib/python3.6/asyncio/tasks.py", line 358, in wait_for
return fut.result()
File "/usr/lib/python3.6/concurrent/futures/thread.py", line 56, in run
result = self.fn(*self.args, **self.kwargs)
File "/usr/lib/python3.6/site-packages/homeassistant/components/cover/gogogate2.py", line 46, in setup_platform
devices = mygogogate2.get_devices()
File "/usr/lib/python3.6/site-packages/pygogogate2/__init__.py", line 78, in get_devices
self.apicode = devices.find('apicode').text
AttributeError: 'NoneType' object has no attribute 'text'
Ok, its working now. I added a new user to my gogogate2, with a username of ‘hassio’ and a password length of 14 characters. That seemed to have fixed it
I have created a new user on the GOGOGATE console for Hassio corresponding to the number of characters as indicated by dbroadfoot. Hassio then found 2 entities, so that the doors can now be steered without delay. The corresponding sensors indicate the status with a small delay. With this, I can now generate an alert with an automation.
Just popped in to say great job on this dbroadfoot and those who helped with testing.
Updated to 67.1 last night and was able to quickly add my GoGoGate2 to my configuration with a new 6 char local user and 14 char password (avoiding the padding issue). I’ve also added some automations to warn me if the door is opened at odd hours overnight.
This all means that I’m finally able to get shot of my hacky IFTTT Gogogate recipe with limited hours of control and Tasker based security alerts in case the door was opened at odd hours during the night.
This means I can now get shot of my IFTTT account altogether - the GogoGate was the last component I needed it for.
after using the cover for a week now, a few things I have noticed especially around automation’s.
several of my automations which involve closing the garage/gate seem to be firing correctly, however what ive noticed is that when the cover state is ‘closed’ and an automation fires off to close_cover (close it), and thus attempting to close the garage/when it is already closed. What seems to happen is the garage/gate will then begin to open. Ive tested a few different automation, and it seems both close_cover/open_cover seem to act as a toggle switch.
Ie. If the gate is already open, automation fires to open it… it will close
If the gate is already open, automation fires to close it…it will close
if the gate is already closed, automation fires to close it…it will open
so on… so forth…
Im not sure if this has anything to do with the service call, but using my old IFTTT command line cover didn’t exhibit this behaviour.
Would like to hear if anyone else has this same behaviour when using with an automation ?
Once again, thanks for putting your time into this @dbroadfoot
I can also confirm that the HA native homekit implementation on 0.68 also exhibits the same behaviour when creating an automation from within the apple home app.
Also wondering whether the temperature sensor on the gogogate2 is something that can be exposed as a sensor ?
