Thank you for spending time on this request. I think it will be helpful for others down the road if there is more granularity in how MQTT can be sent.
I do not think it would work well for the camera name in the payload...which you already have...because any new MQTT message overwrites the old message and would be lost
Here is my situation: I have (now) two LPR cameras on the busy street in front of my house and two LPR cams on the driveway coming up to our house. I am trying to use MQTT to relay the driveway tags/saved plate info to announce who is coming up the driveway. If someone were to come up the driveway and a car would then pass that is in my alerts, then the driveway MQTT message would be overwritten by the car on the street and be incorrect. It is a rare possibility, though, so not a huge deal if it cant be easily implemented.
The flexibility of having a camera specific MQTT message would be ideal as I could also have messages related to the street cams that are different from the driveway cams.
What would work is to have an option for adding new MQTT brokers with a specific camera, or multiple cameras or all cameras. Would definitely need the option to pick more than one camera. Then I could change the topic for each camera, say Blue Iris/Street for both my street LPR cams and Blue Iris/Entry for my driveway LPR cams. That way street LPR cams would not fire when driveway LPR cams pick up the correct plate.
I might be able to configure my home automation to save the last few MQTT messages which could also solve the problem.
Not to muddy the waters, but I am sure there are several folks that have face and/or overview cams on their LPR setups. Was wondering if there was a way to capture those images and store them with the plate data in your database. Not sure how we could accept other cam images and how to get the timing down, but it would be awesome for my situation. I have a face cam set up on the driveway that works well in daytime (not so much at night...yet) and I also have an overview cam that works well in daytime and ok at night. Would be awesome to store those caps with the plate data if available. I think I have seen this feature with the paid versions. Just some food for thought.
100% I’m interested and have been planning for faces. Trying to nail this down end to end first, but that’s where I’m heading for sure.
If you could investigate the ability to manage the message history and trigger based on items within the payload, that would be great.
To me, it seems like that’s something that should be happening on the HA side, but I’m not much of a HA user, nor an MQTT expert.
I can add the full functionality to select a topic within the notification configuration, but it’s going to get fairly complicated, as far as the logic goes. What I’m thinking about most is what the default values will be for those with less complex setups.
Had I understood this use case before building the MQTT functionality, I probably would have taken the time to separate broker mgmt from topic management. I knew that was a limiting shortcut when I did it.
Honestly, now understanding how this integrates, I might just nuke everyone’s broker tables and go back and do it right to have the proper structure of brokers and topics under each.
Unless anyone has a major objection to that, I think that’s the best approach.
Apologies for the lack of foresight on this one. It’s quite a bit more challenging to develop and build around a system that I don’t ever personally encounter and thus don’t understand the use cases for.
Anyways, faces excite me majorly, and I’d love to cross reference and integrate them with the vehicles. Absolutely coming next. Not even very difficult to build. Once we’re stable enough on the LPR functionality, I’ll be adding that.
I might be able to crank this one out this weekend, but I’d like to hear from some others and get some confirmation that this is how I should proceed, since this will probably require deletion or retirement of some DB columns, and my DB update approach is still extremely haphazard and doesn’t even seem to be working in the first place.
Even when using a proper ORM with migrations, you still run into a lot of the same problems when publishing an app to be self hosted. If anyone has any recommendations for a better way to manage database update without users losing their data, I’d be very eager to hear.
