Update Blue Iris alert settings for Blue Iris 5

[efirestone]

I noticed some of these settings have changed since BI4, and also that the &TYPE macro that was previously mentioned doesn't actually work since it inserts things like ONVIF or DIO as the type value, rather than Motion.

Alternatively we could probably simplify the setup procedure by having the code look for all of the different source types (like ONVIF and DIO) rather than Motion and leave the &TYPE in the instructions.

[elad-bar]

Hi, thanks for the work, I will take the readme parts relevant but setting the type as hard-coded instead based on &TYPE is worng, will explain why:

• ONVIF and DIO by design are not supported, I can add them but it's not releavnt for setting it hard-coded in the BI
• Motion event in BI5 - when no zone available will send MOTIONA, when the event of motion is being identified from another zone it will replace the A with the zone letter
• Component is handling it by looking for type begings with MOTION and not exact match, so it's covered

Please let me know if you would like to:

• update the readme accordingly
• have additional events as additional binary sensors

thanks!

[efirestone]

Ah! Good to know. The root issue for me is that I have the motion detection set up on the camera hardware itself, which then shows up as an ONVIF event in Blue Iris. Whether those events get grouped into the existing motion sensor entity or are discrete doesn't totally matter to me. If they're discrete I could see it being slightly annoying to have all of those sensor show up if you're not using ONVIF or DIO, so maybe there's a way to only create them after those events are first seen in MQTT? Or offer a config setting to opt into them in the integration.

The other alternative I could see is to have a single "motion" sensor entity with an attribute of something like "trigger_type". That setup feels simpler to me for what I suspect is the common use case where people care about any sort of motion/audio/presence, but don't actually care what the detection method is. For those that do care about separating out audio, that should be a pretty simple template sensor in HA (but would require slightly more work for that case). This would also be a breaking change of course since the audio entity would disappear.

I'll update this in a bit to go back to using &TYPE (which is great; it's simpler), and I'm curious about your thoughts on how to best show the other sensor types.

[elad-bar]

Released new version with external & dio support, now you can choose which sensors to create motion or external or having both of them (to use with different functionality)

2020-07-17

Implemented enhancements:

• Added ability to set stream type in integration's options (Originally was hard-coded), Default=H264, initiated due to #75
• Upgrade pre-commit to 2.6.0
• Fix pre-commit errors (F541 f-string is missing placeholders)
• Added support for External and DIO events (Related to #74)

Note: All camera will have 2 additional sensors, to disable use integration's options

[efirestone]

Amazing! That seems like the ideal usage. Will try it out tonight.