Yeah. Half dozen times now. Changed the password to have no special chars. Set the new account as a admin. Still 500’ing. I’ll give it a couple hours and try again. Maybe it’s a backend propagation thing on kevo’s part.
If you switch back to the account that was working, does that still work?
Edit: Also, just want to make sure, you verified that you can login to the website using the new credentials?
Edit 2: More details. First, the eKey does need to be an Admin key. Looks like the API calls I need require admin access. That said, not using an Admin key generates a 401 for me, not a 500.
The only way I can reproduce the 500 is, after logging in, if I go to the Kevo website, go to Kēvo, then mark the device as disabled. I don’t actually see a way to reenable a device in their UI 
I published 1.1.0-b1 (you have to enable beta for the repository, see https://hacs.xyz/docs/faq/beta if you haven’t done this before). This new version has much better reconnection logic for the websocket. For anyone having issues before I’d appreciate checking if, using this new version, you see any log messages of either Lost connection to websocket, retrying or Error on websocket
I’m curious if a.) this new version fixes your issues and b.) if you see any of those log messages so I know WHY my fix fixed your issue 
1 Like
Yup all logged in and I can see the keys
Yes they are admin keys
Older credentials do work.
Several hours later, no change.
I tried following the url in the error message https://identity.unikey.com/account/login (which is slightly different where the web ui redirects https://identity.unikey.com/Account/Login, though i’d hope case sensitivity isn’t a thing) and when i log in there with the new creds i got this: {"error":"invalid_operation_exception","error_description":"The relative page path \u0027AccountError\u0027 can only be used while executing a Razor Page. Specify a root relative path with a leading \u0027/\u0027 to generate a URL outside of a Razor Page. If you are using LinkGenerator then you must provide the current HttpContext to use relative pages.","sub_status_code":""}
And you didn’t use the disable device feature in the web ui? Unfortunately that error message just means “something went wrong”
Validated that the new user can lock and unlock both doors from the webui. Reset the locks. Reset kevo plus. resetup again. Validated again from the web. Same issue.
Ok but I don’t think you answered my question. Did you by any chance use the disable device feature in the web ui? So far it’s the only way I can reproduce what you’re seeing. Also curious if you create another new user if it works or if it does the same? I created a new user tonight and it worked for me so I’m just trying to find a pattern. Like I said, so far using the disable device is the only way I can get the 500 error.
Have not disabled the device on any accounts… FWIW it looks like a successful login just re-adds the device (eg i disabled my iphone and then relogged in).
Adding a new-new user doesn’t solve the issue either. it get’s the same error message/500.
I appreciate the help. I too am trying to understand the pattern. At this point though i’ve deleted added all locks, the kevo plus, tried adding an empty account. It’s weird.
Failed over to my backup internet too, trying to see if it was some sort of IP block. Also didn’t change anything.
Annnnnnd tried using my wifes account [admin], also fails. This is so weird. Only works with my owner level account. 0_o was there anything with the old school integration that would have borked this?
one final interesting troubleshooting point.
I jumped in a python3 repl and using your example code here: GitHub - dcmeglio/pykevoplus: A python3 version of pykevoplus by cseelye and a little fiddling I got it to log in successfully. which results in a notice being sent “a device successfully logged into your account”. I do not get that same notice when attempting via HA.
So login via import aiokevoplus == works
login via ha == fails.
Putting in the wrong password results in Invalid authentication.
The beta has been solid all morning, thanks for the fix! I’ve looked in the logs and strangely enough I don’t see any of the websocket messages you’ve mentioned. Something fixed it and works better but I can’t tell you why. I’m just looking in the HA logs, is there anywhere else?
On another raspberrypi, i spun up a new docker instance of HA, installed HACS, installed your repo, and any/all accounts work…
So there has to be something hanging around from the old integration that’s blowing this up. Could it be the device ID somewhere?
Icons should be working now, the PR was merged and the server caches cleared. If you’re still not seeing them try clearing your browser cache.
Bingo, so you semi-proved my original theory, though since you said you didn’t disable the device id yourself there must be something in Kevo-land that did it for some reason. Basically the reason the python script works is because the python script generates a random device ID every time you run it. I didn’t want to do that in HA because, as you saw, it will send you a push notification whenever it logs in from a new device ID. I didn’t want that to happen on every HA reboot/reconnect/etc. since I thought it’d be annoying. Therefore, on HA I take the unique node ID of the machine (usually based on a MAC) and use that as the device ID. So my first thought was – ok maybe the MAC of your machine is banned by Kevo for some reason? Well that doesn’t make sense because then it should fail regardless off what username you use. But you said the original account works just fine. So it’s some how a combination of the username + device ID causing an issue. I thought I had already asked you this but reading back in the thread I didn’t, did you ever try creating ANOTHER new user and seeing if that one worked? Just kind of curious if something is unique/specific to this one user?
In any case, the bad news is, no idea why that one user/device ID combo isn’t working and I’ll probably never be able to find out since the only way I could really dig in more is to find a way to reproduce it or use your account and obviously you’re not going to want to share the user/password to something that controls your locks, and I wouldn’t want you to!! But the good news is I can come up with a work around. As I said, right now I generate the device ID by doing uuid.UUID(int=uuid.getnode()) so one thing you could try is in your sample Python confirm doing that causes the 500 when you use the username/password from the script – basically KevoApi(uuid.UUID(int=uuid.getnode()) I bet it will recreate the issue. So what I can do is come up with a way to let you override the device ID inside HA with a different UUID. So if a device ID ever gets banned/blocked/whatevered by Kevo, you have a way to generate a new one. This will take me a little bit of time because I need to learn what HA calls an “Options Flow” which doesn’t look too hard, just something I’ve never done before. I probably can’t get to it before Sunday so if you’re able to use a different username in the meantime, that’s probably the best quick solution.
Thanks for helping to debug this though! These things always have a bit of trial and error when you’re working with something that’s undocumented!
So i did go down that path - I tried with my wifes admin u/p (never used in HA before), the original new account, and a 2nd new account, but all failed from my HA node.
On the new test node, all 3 worked.
I did notice that your uuid.UUID(int=uuid.getnode()) was deterministic across installs when poking around and that the function falls back to a standard uuidgen…i just didn’t put 2+2 together >_<
I’ll try tweaking the uuid gen call and nuking the pyc’s - should provide immediate feedback.
Bingo - I tested the hypothesis and tweaked this line
#device_id = uuid.UUID(int=uuid.getnode())
device_id = uuid.uuid4()
Nuked the pycs, restarted, and it let me use the new username. Maybe instead of using the node, use the supplied password? If someone changes their password, they’ll need to reconfigure it anyway. Might not be a terrible user experience.
something like this, where bob dobbs would be user_input['password']
>>> import uuid
>>> import hashlib
>>> uuid.UUID(bytes=str(hashlib.md5('bob dobbs'.encode()).hexdigest())[0:16].encode())
UUID('35643161-3638-6336-6331-383461616462')
OH and thank you for working to debug some random dude on the internets old bluetooth locks <3
I like the idea of hashing the password. That has a side benefit, if some how the device ID gets blocked, there’s a work around to have people fix it, I can just say “change the password” which will give a new hash and could magically resolve their issue.
I just published 1.1.0-b2 with a change to the device id logic, mind letting me know if it resolves your issue?
1 Like
1 Like
Nice! If everyone still seems to think this is working better and keeping the connection I’ll update the release version this weekend.
I had just started testing this integration under HA 2022.12.9 and it was all looking good. Today I updated to HA 2023.1.1 and now I’m getting the following error displaying on the integration tile:
Retrying setup: Timeout while connecting to Kevo servers
It may just be coincidence on the timing so I thought I’d ask here if anyone else is seeing issues with the integration after updating to HA 2023.1
I had also updated the Kevo integration from 1.1.0-b1 to 1.1.0-b2 just prior but it seemed to be working fine.
maybe i’m just misremembering but seems like the kevo app is much more spammy now - everytime HA restart’s it’s telling me someone logged into my kevo account.
just me? going insane?