I’ve been trying to use the UniFi Protect to detect cars that come down the intersection at a property and turn on floodlights using a Shelly, this works most of the time.
Is there a better way to do this?
Here is my current automation:
alias: Camera Intersection Lights
description: >-
Turns all 3 flood lights on at the Camera Intersection if motion is detected on any of the 3 cameras after dark.
trigger:
- type: motion
platform: device
device_id: 2c4de993dfecf07a62eaa84f016f0de7
entity_id: 9f8647435d7f8c1e565d4b782d02e5d4
domain: binary_sensor
for:
hours: 0
minutes: 0
seconds: 0
- type: motion
platform: device
device_id: 902b16e52d7b3a0f847c724a58471a7c
entity_id: 32588db213caa5cbd3d1655c162d5f3a
domain: binary_sensor
for:
hours: 0
minutes: 0
seconds: 0
- type: motion
platform: device
device_id: c5bf1b0c2db95ca7b42e520da8e982ef
entity_id: 92efc73fdd1ee77a15f7f7d48f623e0a
domain: binary_sensor
for:
hours: 0
minutes: 0
seconds: 0
condition:
- condition: sun
before: sunrise
after: sunset
before_offset: "+01:00:00"
after_offset: "-01:00:00"
enabled: true
action:
- type: turn_on
device_id: 4645f5fb90d625dfc23088912589297b
entity_id: 1c808458db452035f62a7e889e32e344
domain: switch
- delay:
hours: 0
minutes: 0
seconds: 30
milliseconds: 0
- type: turn_off
device_id: 4645f5fb90d625dfc23088912589297b
entity_id: 1c808458db452035f62a7e889e32e344
domain: switch
mode: restart
I use Node Red to do the same thing, and it seems to always work. I find it’s easier to debug as well as you can see if one of the nodes isn’t working as anticipated.
Honestly, the better way to do it is to use blue iris and deepstack. And once you do that, you’ll quickly realize you can buy a lot better cameras for a lot less money. I’m currently in the process of getting rid of all my ubiquiti cameras and doorbells right now. Switching to amcrest. Cheaper, better functionality, better images, and much faster notifications.
I can’t say definitively but I have seen unwanted behavior in nodered. Where things sometimes just don’t work right. Like an automation will work, then randomly not, then go back to working. Similar to what you’re experiencing.
I find it to be. Some people find it confusing. Typically each part of an automation (trigger, condition, call service) are represented by a node in a chain. You can jump in at any point of the automation (by adding a debug node) to see what the result is at that point.
To quote myself, looking at the traces for when the automation fails to work would help indicate what’s going wrong. Even the absence of a trace would suggest that the rule isn’t triggering meaning it’s not picking up the device change.
As for using device, I don’t know that I’ve seen it inherently cause problems. Most recommend not using device and using entities instead since they’re easier to update if the device is swapped, removed and re-added, etc.
I had a look the trace for the automation, but it didn’t look like go far enough back, I’ve been having this issue for a few months and only now had the time to have another look at it.
You can change how many traces are stored in the automation. Go to the automation, switch to edit in YAML, and add this just before the “mode” option. Just change the number to how many ever traces you need to catch the problem.
trace:
stored_traces: 10
Should look like this:
@lit-toby I realize I may have come across a bit gruff. My point in trying to trouble-shoot the automation failing is that you’re likely to flip to Node-Red and have the same issues. Since you never really said what part wasn’t working then there’s a bit to figure out. Is the Shelly having connectivity issues? Is the Unifi Protect integration? Are the cameras? Is there a logic problem in the automation (I don’t think it’s this)? Is it truly a problem with using device vs entity? All of these would still be there with Node-Red if they are true.
You have no complaints other than them not working reliably? Interesting point of view, that.
And no one said you had to swap cameras. You can feed your Ubiquiti cameras to Blue Iris. I’ve seen me do it.
All I’m saying is that once you DO that, you’ll quickly realize that Ubiquiti cameras are not all they are cracked up to be, and over time, you’ll find yourself switching to better cameras that cost less money and work better.
But hey, don’t listen to me. It’s not like I’ve already been down that exact same road with 8 Ubiquiti cameras or anything.
I mean, sure I do have a few complaints, they’re overpriced for the specs that you’re paying for, but the UI/UX of the Protect app looks better than the screenshot of Blue Iris I’ve seen from their website, especially to non-techy people.
Yeah, I don’t know much about Blue Iris, so I wasn’t aware you could do that which is why I said swapping wasn’t an option.
I’m aware of better cameras existing that are cheaper, but I like the Ubiquiti’s software, so I use their cameras.
Yeah, I won’t be listening to you, it seems like you just came in here to crap on Ubiquiti cameras.
Yeah, I’ll give this ago before swapping it over to NodeRed.
I’m thinking it’s related to the Protect integration as I’ve seen it just stop working completely.
The Shelly is hardwired with Ethernet, so I doubt there would be any issues there.
I had a play around with NodeRed and really like the node based way of creating automations, so I wasn’t really expecting it to solve the issue, but rather make it easier to improve and debug any issues that arise.
Actually, I came in here with the benefit of experience offering a better solution. But if you’d rather remain headstrong, it’s certainly not going to hurt me at all. It’s quite clear that you are in the midst of a serious case of confirmation bias, so it’s not worth continuing this conversation. When someone is in that position, their eyes will never be opened.
Eventually, you’ll realize what everyone else does, and you’ll think back on this discussion and feel bad. Until then, enjoy your unreliable “solution”.
