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.
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!
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.
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
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.)
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.
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.)
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!