Unexpected Result From API on Login

Configuration
1

Is anyone else seeing this error message? I have been getting it sporadically since I upgraded to 0.20.1:

The associated log message is status 422 which is not documented on the HA API page, but googles as “Unprocessable Entity - The request was well-formed but was unable to be followed due to semantic errors.”

I was going to post the log entry but it started working again and I can’t find an example. This time a reload of the webpage worked, previously I tried a lot of things up to and including rebooting the HA host to fix it.

2

Did you configure SSL access for HA ?

3

Yes, I am using SSL and it has been working fine up until now, and still does when I am not seeing the error.

4

You should test with SSL desactivated in first to confirm that.
Whern i had this message, that’s coming from my SSL config.

Normally a restart HA (or Stop and start resolve that)…

5

Thanks - I’ll give that a try if I see it again.

6

OK, this is a little nuts - it has started happening again so just for fun I tried to run curl agains the API call it was failing on and got this:

pi@homeassistant:~ $ curl -X GET -H "x-ha-access: <redacted>" -H "Content-Type: application/json" https://<redacted>/api/bootstrap
Latitude and longitude not specified.pi@homeassistant:~ $

I can’t explain why the api thinks it needs lat and long for that particular call, and I am wondering if it is somehow getting confused with a different API call - could this also be related to Locative support breaking?

I also don’t understand why this seems to be transitory, although I can’t fix it this time.

Edit:

I decided to supply it with lat & long and it asked for device id - eventually I had to provide it with all the parameters that locative requires and I ended up with this:

pi@homeassistant:~ $ curl -X GET -H "x-ha-access: <redacted>" -H "Content-Type: application/json" 'https://<redacted>/api/bootstrap?latitude=0&longitude=0&device=yyy&id=iii&trigger=exit'
Setting location to not homepi@homeassistant:~ $

So the bootstrap API call seems to think it is locative! Also, in the locative thread a similar exercise seemed to get me what the bootstrap API call should - so it looks like some wires are crossed somewhere!

7

OK, I’ll stop talking to myself after this …

In the source for Locative, there are the following lines:

class LocativeView(HomeAssistantView):
    """View to handle locative requests."""

    url = "/api/locative"
    name = "api:bootstrap"

This looks like a cut and paste error that occured when moving to the new web infrastructure. To check my theory I changed it to:

class LocativeView(HomeAssistantView):
    """View to handle locative requests."""

    url = "/api/locative"
    name = "api:locative"

After restarting, not only could I log in straight away, but the Locative support is now working!

I suspect that this typo led to the api path getting overwritten, and maybe a race condition during initialization made the results indeterminate.

For now I am happy, I have fixed both of my issues at the same time - I’ll add a comment explaining this to the locative issue…

1 Like
8

This is great, @aimc, as I having the same issue. However, I can’t identify the file you are talking about.

Is this a change easily made if one is not a Python developer? Where is the file that needs to be changed, and what (if anything) has to be done so that “hass” will use it?

Easier than curl, to see the problem you’re talking about, it’s enough to plug the URL into a browser, such as http://localhost:8123/api/locative. The response that displays is: Latitude and longitude not specified.

Many thanks…

9

Hi There -

What version of HA are you running? This was fixed a couple of releases ago - in 0.21 I believe.

10

I just updated it… 0.23.1

11

I’m trying to use the Locative iOS app that finds my Mac as an iBeacon (using an app I found on the web) and update presence.

Running on a Mac (10.11), I’m having real trouble getting any reliable device tracking to work for iPhones. The nmap option is not usable because iOS puts WiFi to sleep and only wakes up periodically. This makes HA think I’m constantly going in and out of the house.

After spending the afternoon getting the bluez to install, I now can’t get HA to load it :frowning:

The Locative solution is my last option!

12

Locative is working fine for me -

To answer your original question, the file I changed was:

/srv/hass/hass_venv/lib/python3.4/site-packages/homeassistant/components/device_tracker/locative.py

The first part of the path will vary depending upon your system however.

13

Thanks, @aimc… Now it’s getting weird. I found the file, and it does appear to be up to date. It does not contain the bad code you indicated above. Nonetheless, if I put the URL http://localhost:8123/api/locative in my browser, I still get the error about latitude and longitude, and the Locative app on iOS also does not register any change.

The “known_hosts” file looks OK. The only obvious differences I see are the I’m running on OSX and Python 3.5. (I’m not a Python developer.)

14

That would be expected behavior - when querying the locative API, it EXPECTS lat and long and is simply telling you they are missing. When the bug was happening, it was giving that error for a completely unrelated screen.

15

Ah, OK… I guess I misinterpreted your earlier post, then. Nonetheless, my Locative app responds correctly to my iBeacon and sends a request to HA, but HA does nothing. I don’t see anything in the log that even suggests it saw the post from Locative.

The Locative app even has a test page where you can test your URL… That yields the same result in HA (no action), and no response ever comes back to the Locative app. (It notifies of either success or failure of the URL post.)

16

Ah… I think I may know why. I read in another post that the guy working on the Locative API has recognized a problem. He says that the automations will work but that the “home/away” badges would not be correct. This is exactly what I was using to test the effect of my Locative app!