I’m pretty sure it should be in there. That's odd. Maybe try to docker compose pull it again?
Full ALPR Database System for Blue Iris!
- Thread starter algertc
- Start date
I’m pretty sure it should be in there. That's odd. Maybe try to docker compose pull it again?
MikeLud1
IPCT Contributor
@algertc maybe also have the IP address in the payload so if users have more then one server the ALPR Dashboard knows what server the payload came from.
{ "plate_number":"&PLATE", "Image":"&ALERT_JPEG", "camera":"&CAM", "ALERT_PATH": "&ALERT_PATH", "ALERT_CLIP": "&ALERT_CLIP", "timestamp":"&ALERT_TIME", "IP Address":"192.168.1.21:81" }
Shit yeah I was almost gonna do it that way and didn't because it would be storing duplicate data over and over, but that's a good point. I'll change it.
The only problem I see with that is if anyone ever decided to change the IP address, all old records would be hardcoded to the original IP.
Maybe the settings could allow for setting up a table of BI instances (ID, IP address). By default, if not specified on the call, it would be the default instance, otherwise you could pass the specific ID for an alternate instance.
MikeLud1
IPCT Contributor
Oh shit. I just did a pull and now I see the option, but I am no longer getting anything into the DB, and the previous entries from the live view are gone (they still exist from the DB view).
The API key did not change in the UI, but I re-copied it anyway.
I see this in the log:
2/13/2025, 3:11:17 AM [ERROR] Error fetching plate reads: error: column pr.bi_path does not exist
I am going to download the schema and migration again, and do another pull to see if it fixes it.
Update: Nope, that didn't fix it. nothing is being logged after the pull.
Update2: The requests are definitely making it to the Dashboard app:
app-1 | POST /api/plate-reads
app-1 | Received plate read data: {
app-1 | plate_number: '6AYU542',
app-1 | Image: '/9j/4AAQSkZJRgABA
...
Last edited:
TheWaterbug
Known around here
TheWaterbug
Known around here
How do we tell postgres to add the new columns? Or does that happen automatically?
Automatically. You just need the newest version of the migrations.sql file. If u use the update script it will get it automatically.
Is anything else in the logs? How about the log tab within the app?
This shouldn’t make any difference in JSON, but it’s possible that blue Iris might be parsing it weirdly: try removing the space after the colon in the payload to be like the others. I vaguely remember encountering an issue at one point that may have been caused by that.
So like: “ALERT_PATH”:”&ALERT_PATH”, “ALERT_CLIP”:”&ALERT_CLIP”
Okay, I figured it out. I pulled the migration.sql file using wget instead of curl -O, so it included a bunch of html. With the correct file, it's working now. And the link to BI works. Also, thanks for fixing the arrow key binding, it was driving me nuts.
glad it’s working now. Either of those should work though. Were you on the raw page that just has the file displayed?Okay, I figured it out. I pulled the migration.sql file using wget instead of curl -O, so it included a bunch of html. With the correct file, it's working now. And the link to BI works. Also, thanks for fixing the arrow key binding, it was driving me nuts.
If you just navigate to the file in the repository, that’s a web page and trying to download that directly downloads an html file. Clicking the little button at the top right of the file that says “raw” will display the raw file instead of displaying it in the html page. That’s the link to the actual file. As a backup, you can also always just click download on it in the browser then move it.
I'm running it on a remote system, so I just ssh to it and do it from the command line, cut and pasting the url for the file. It was a careless mistake, I usually take a look at the file before I do anything with it.
I added it previously to the tracker.
Ah, that's it, thanks! I remembered reading about this somewhere... Gave it an upvote.
I had to change &ALERT_CLIP to &ALERT_DB to ensure the URL points to the exact moment in the clip where the alert begins.
I believe this is because my LPR CAM is set to continuous recording, so the URL needs to reference both the clip and the exact timestamp within it. Since Blue Iris splits files even in continuous recording mode, the clips are still present but quite long, so if we only reference the clip in the URL, then it can point far from the alert itself.
I'm not sure if &ALERT_DB works as a general solution, including for cases where there is a separate clip of each alert, so the clip itself starts exactly when the alert occurs.
Can someone with such setup please test this?
So can I add "Motion Type" (&TYPE) to the database? And maybe put the confidence in the row as well?
For example, I have a zone B and zone C (left and right respectively). When a car goes by, I have BI report via MQTT.....
Plate detected: 2US673 Probability: 65% MOTION TYPE Motion_B>C
That said, I am having huge issues with my motion..... Not sure it is related to this thread.... Maybe I'll add it to another ALPR thread.
Vettester
Getting comfortable
- Feb 5, 2017
- 921
- 902
I have continuous + alert set. I didn’t think this created separate files but maybe it does? My continuous splice every hour and when I open an alert it just goes to that point at full resolution. If + alerts creates full separate files even with bvr, that seems like kind of a waste of space. I’m sure BI Ken probably had a reason if that’s the case, but would seem odd to me.
If just switching the macro works for you, I’d just keep it like that. Makes no difference on the app side and will work how you want it to. Thanks for noting though, I’ll add it to the readme.