Http binary sensor now failing with api_password

Configuration
1

I have my Blue Iris camera dvr create an http binary sensor whenever motion is detected. It posts {"state":"on"} to my hassio which is running 0.83.2 at:

https://xxxxx.duckdns.org:8123/api/states/binary_sensor.blue_iris_&CAM? api_password=xxxxxxxxxxxx

I know the api_password above is correct because I can log in with just the api password instead of user name and password like I normally do.

Whenever Blue Iris is triggered, I get the following error in HA:

Login attempt or request with invalid authentication from 192.168.1.xxx
9:56 PM components/http/ban.py (WARNING)

And obviously my binary_sensor doesn’t update with the new status. This has been working for a long time, but I’m not sure with which upgrade version it first started failing.

Can someone explain either how to resolve or how to use a long life token instead of the api_password? I see how to create a token, but I don’t know how to pass it from Blue Iris.

The only thing I currently send from Blue Iris to that url is either {"state":"on"} or {"state":"off"}. Blue Iris seems to only have one life of text that I can send to the url, so not sure how to use the token.

Thanks for any help or suggestions coming my way…

2

Funny you should bring this up, I’ve just been experimenting with HTTP Sensors and Binary Sensors using Long-Lived Access Tokens.

First thing before you start down this new road is that whatever software you are using, such as Blue Iris, must be able to perform an HTTP POST operation and lets you create custom HTTP Request Headers.

Unlike the deprecated API password technique, which was entered in the URL, the token is entered into a custom Request Header that defines Authorization. It will look something like this:

Authorization: Bearer 9x5rtbg248.04hjx754w32cjf

The gibberish after the word Bearer is your Long-Lived Access Token and the real thing is much longer than in the example above.

If the software doesn’t support HTTP POST or won’t let you create an additional Request Header, I honestly don’t know how to deal with that situation.

To make the token, open the Profile section (i.e. click the icon with your initials in the upper left-hand corner of Home Assistant’s menu), scroll way down to Long Lived Access Tokens and click Create Token. Give it a descriptive name (like Blue Iris) then click OK. A long line of text will appear in a popup. Copy it immediately because that’s the last time you will see it. Paste it wherever you need to use it (like Blue Iris).

If you ever want to prevent some software from logging in with that token, you simply delete the token. That’s why it’s a good practice to provide a separate token for each remote software app that accesses Home Assistant. This will let you selectively block access should you ever need to.

3

Check if you have an ip_bans.yaml file in your config folder. Looks like you have ip_bans enabled in config yaml… maybe you got your IP banned?

4

I got lots of those in my log as well, all produced while I was trying to get the correct format of the Authorization header. After I got it right, the device was allowed to connect so its IP was not banned.

Having said that, the same thought had crossed my mind at the time given that the message comes from something ominously called ban.py!

5

Now that you mention it, the other day I "tried’ to use the following in configuration.yaml:

  trusted_networks:
    - 127.0.0.1
    - ::1
    - 192.168.1.0/24
    - 172.30.0.0/16
    ip_ban_enabled: true
    login_attempts_threshold: 10

But it caused so many problems I had to comment those lines out. I was wanting to protect myself before I did some port forwarding while allowing all connections from my lan. I did get several ban messages, but never could find an ip_bans.yaml in my config folder. Just looked again, but still don’t see it. Like I said, I commented out the lines above and rebooted so I assumed the ban was removed?

6

It clears the ban after a successful auth but too many bans in a row and you’re out

Well it is still warning you for some reason… if no ban file it’s not that.

7

Blue Iris has one POST field which I use to identify whether the sensor is on or off. So I put {“state”:“on”} in it or {“state”:“off”}. I just now tried put one very long line with:

Authorization: Bearer xxxxxxxxxxxxxxxxxxx {“state”:“on”}

but that failed. Guess I can’t use a token, and will have to figure out why the api_password won’t authenticate.

8

FWIW, it looks like 6 in a row is still a pass because that’s how many I see in my log within a 2 minute period.

9

My impression is it was deprecated in 0.83.X. I’m still using 0.80 but learning how to use tokens in preparation for an upgrade

10

depends on what you configure in the yaml… but I might have seen it take a couple of extras… don’t remember…

11

I don’t know what entries control the ban mechanism so, safe to say, whatever is the default in the config file is what I have. I’m still running 0.80. Maybe they tightened up the way ban works in newer versions?

Anyway, no ban files found in the config directory so all is good. It took me awhile to figure out how to correctly enter the Request Header into the Automate app (as a Javascript dictionary element, dammit!) and I’m glad I wasn’t banned during the experimentation because that would’ve been extra frustrating!

1 Like
12

Oh wow, I didn’t see that in the release notes.

1 Like
13

Yeah, I don’t think jamming the token into the URL in that manner is valid.

EDIT

Oh wow, I didn’t see that in the release notes.

Don’t quote me. It’s only my impression based on other complaints similar to yours. I also had the impression it was slipped in by mistake in 0.83.0 and then reversed in a subsequent release … but you’re running 0.83.3 so I must be wrong on that count (it appears to be by design). Hopefully a developer can comment and set the record straight.

14

Ooops that was a typo on my part. I’m on 0.83.2.

15

For anyone following along, apparently there is now a work around in 0.83.3 listed here in the Release 0.83.3 - December 3 notes:

Myself, I opted to stop using the http binary sensor and configured Blue Iris to use HA’s MQTT Binary Sensors which seems to work well.

16

I came across this post while studying. Can you give me your example of how you did it with MQTT. I need a binary switch that I can control via http. Maybe that’s for me.

17

In Blue Iris options, under Digital IO and Iot tab
Choose MQTT Configure. Put in your mqtt server ip and port along with the credentials.

Under each camera’s settings, under the Alerts tab, check off the “Post to a MQTT Server” and then configure:

When triggered:
MQTT topic (for example): blue_iris/driveway_cam/state
Post/payload: ON

check the box: “Alert again when trigger is reset”
MQTT topic: blue_iris/driveway_cam/state
Post/payload: OFF

Then in configuration.yaml:

binary_sensor:

  - platform: mqtt
    state_topic: blue_iris/driveway_cam/state
    name: blue_iris_dw
    payload_on: "ON"
    payload_off: "OFF"
    device_class: motion

Edit: I now see that you said switch. I use it for a binary motion sensor. Can you describe how you need this to work?

18

Thank you for the quick and detailed explanation. I have a mqtt server running but unfortunately the camera cannot post mqtt. The camera can only post webhook. Now I have seen that HA understands webhook automation. I will then implement that.