Yeah spot on, I’ve updated my post. I somehow forgot to change it back. Fixed by force installing the official 2.11.21 over the EA access.
1 Like
Done the same, however downgrading still having no effect.
HA still saying Unknown error occurred
same here. downgraded to 2.11.21, unkonow error occurred
Same here, the read only user is left over though when downgrading, I assume that’s what the readlive error is. We’ll just have to wait patiently for it to be fixed
EDIT: Looking at github, it looks like its been fixed and merged, hopefully it’ll make it in 2024.3.2
Just updated to Unifi Protect 3.0.22 (official release channel) and home assistant no longer connecting to cameras etc. Suggest not to update protect until the integration is updated.
1 Like
1 Like
With how fickle the integration is, I ended up just adding Generic Cameras pointing at the RTSP and snapshot links. Yes, I lose the person / motion detection, but I don’t end up with random crashes of the integration and it seems to load the snapshots more quickly (and more often).
Once the integration is operational again, I’ll probably keep the Generic Camera one as the primary for images and just use the motion / person detection from the integration.
1 Like
Do you mind sharing an example of your configuration using Generic Cameras ?
Teste the following combinations and both fail to render:
- platform: generic
name: kitchenunifi
still_image_url: http://unifiprotectIP/snap.jpeg
stream_source: rtsps://unifiprotectIP:7441/streamingID?enableSrtp
verify_ssl: false
or simply:
- platform: generic
name: kitchenunifi
still_image_url: http://CAMERA_IP/snap.jpeg
stream_source: rtsp://USERNAME:PASSWORD@CAMERA_IP:7447/STREAM_ID
There is any specific user I need to create in order to make it working ?
Your second one is closest – but the RTSP link needs to be pulled from the Camera Settings page in Protect, with changes to the port and protocol.
the snap.jpeg only comes from the camera, and the rtsp only comes from the protect appliance (and seems to be anonymous). I’ve attached what I configured in the UI.
1 Like
Appreciate. How do u get this options UI ?And I see you have Basic Authentication defined, username\pwd is for a specific user within the UnifiProtect ? or your kept without anything ?
BTW, I managed to fix my integration and udpate to the last Unifi fwm using the following Unifi Protect Integration does not yet support Protect 3.0.10 · Issue #112487 · home-assistant/core (github.com)
If you update to 2024.3.2 it solves the Protect v3.x issue
I can’t, because of other dependencies. The change I did this morning on types.py is the fix included on 2024.3.2
There’s quite a few more changes/fixes but if what you’ve done works for you that’s great
1 Like
I added the “Generic Camera” integration through Settings → Devices & Services → Integrations. Then, after selecting the integration, I clicked “Add Entry” at the bottom.
It says “Basic Authentication” but the u/p info is blank. Those were defaults that I tried first and they worked.
I think it’s only fair to say it solves the Protect v.3.0.x issue. I’ve watched this integration get broken with other releases within the same major release, too.
If you do not like how the library is developed, then why don’t you stop bitching and contribute?
Dude… if it breaks because Ubiquiti sneezes, it’s pretty hard to support. I’m not a python programmer, so I won’t be contributing code – it would just cause you more work.
To be clear, I’m not bitching in a way that expects you to do anything – I’ve found a workaround by using Generic Camera for the image / video stream (which works better even when this integration is working since it grabs the snapshots directly from the camera, and more often). If I need to use the sensors for automations, I just use the Node-RED integration that doesn’t break with every minor change.
I don’t understand how it is that other integrations (Scrypted, Node-RED, probably others) don’t go kaboom at the slightest change, but this one seems to need everything perfect in order to not blow up. In any other API work I’ve done, everything is backwards compatible (unless otherwise stated), and a tool programmed against an older API will work, just without the new features.
The other integrations do not implement half of the features pyunifiprotect does. And most of them are untyped. Just like UniFi Protect is. Javascript tends to keep working even when it is working flat out wrong because it is designed to. There is a reason why there are so many jokes about how Javascript typing works.
pyunifiprotect sometimes has to deal with this as result of how bad Protect can be sometimes.
pyunifiprotect usually breaks for 1 of 3 reasons:
New typing change that Python could not handle (most common one including the most recent one). It is not usually normal in decently made Python code to just pass around strings for everything like Javascript does. You make enums. You validate the values of things. When a new value is added, if you have not actually added the code to be able to handle the new value, it can case issues. It is really easy to reproduce and understand this issue with an example:
from enum import Enum
class Animal(Enum):
CAT = "cat"
DOG = "dog"
Animal("bird")
ValueError: 'bird' is not a valid Animal
Every time this happens, I keep improving all of the enums and types so they can better adapt to unknown values, but there are a lot of values. Other times Ubiquiti just fucks up the values (which leads to the second time).
The second, and also the second most common, reason things break is because Ubiquiti fucks up a lot. Like a lot. There is a reason a lot of people say their software is buggy and unstable. The last time the integration broke from everyone updating to the EA version was because UI completely foobar’d how they were handling UUIDs and Javascript’s shitty typing just allowed them to go with it. In fact, people that did not update to EA did not have this issue because it was fixed in a later EA build so stable never had the issue.
The third, and probably least common, issue is just that Ubiquiti decides to make a breaking change because they can. Because Protect does not have an open API and they can and will do whatever they want with it. Like they completely changed how events worked in 2.11 which completely broken the license plate sensors in Home Assistant because Home Assistant expects sensors to have state. The events started only coming in after they completed which basically left them with no state. 3.0.x actually seems to have reversed this change so the license plate sensors work again.
Just the server version of UniFi Protect (not including the Web app client any of the mobile apps or UI Core or anything else) is over 50,000 lines long. So yeah, sometimes I miss something. Or something I wait a week or two to update pyunifiprotect after an EA version releases, because, you know, I am a human being and have to deal with idiots like you saying how bad I am at everything I do. Or people not blinding auto-updating to EA and then harassing me because their Home Assistant broke.
There is no need for name calling. It’s clear you’re frustrated this week – both with people complaining that the integration isn’t working, as well as with the HA Core maintainers who didn’t see the need to push the change out more quickly.
Perhaps you’re just doing things in a way that isn’t congruent with the way Ubiquiti does things – as you’ve just detailed. Your desire to use enums when that doesn’t align with the source API could be part of the problem. While it is the best practice, it doesn’t lend itself to working with a vendor who makes changes willy-nilly.
Aside from your hubris, is there any reason why you can’t use strings and solve this issue? Or, barring that, include error handling that doesn’t throw up its hands at the slightest issue?
Regardless, most of what you’ve just said doesn’t address why the HA UniFi Network integration doesn’t seem to break. Certainly not as badly as the Protect one does. So perhaps it is an issue in how you’re doing things.
Confirming that HA update resolving the issue.
To be honest I’m very grateful that there is a group of people who has a will to contribute and deliver the plugin. Even if sometimes is broken still gives a lot of value.
It’s open source so we take it as it is.
Many thanks.