MikeLud1
IPCT Contributor
Full ALPR Database System for Blue Iris!
- Thread starter algertc
- Start date
Yes, I have no problem getting properly labelled plate photos populate into the ALPR file directory however, my database will not populate.
Up until 20 minutes ago I was getting the "null constraint error" however, after reading post #1200 by PeteJ and toggling object detection in the main menu, I'm now getting a "not valid JSON" error. (See both errors in the log below). I have also set my settings to those indicated in post #981.
I'm running the latest BI 5.9.9.92 however, the "not-null constraint" has persisted since previous versions of BI as well.
---------LOG-------------
[INFO]POST /api/plate-reads
2025-10-16, 9:06:25 a.m.
[INFO]Received plate read data: [object Object]
2025-10-16, 9:06:25 a.m.
[INFO]Database connection established
2025-10-16, 9:06:25 a.m.
[INFO][FileStorage] Successfully saved image
2025-10-16, 9:06:25 a.m.
[ERROR]Error processing request: error: null value in column "id" of relation "plate_reads" violates not-null constraint
2025-10-16, 9:06:25 a.m.
[INFO]POST /api/plate-reads
2025-10-16, 9:06:26 a.m.
[INFO]Received plate read data: [object Object]
2025-10-16, 9:06:26 a.m.
[INFO]POST /api/plate-reads
2025-10-16, 9:17:55 a.m.
[ERROR]Error processing request: SyntaxError: Unexpected token ',', ...""ai_dump":, "Image":"... is not valid JSON
2025-10-16, 9:17:55 a.m.
[INFO]POST /api/plate-reads
2025-10-16, 9:17:56 a.m.
[ERROR]Error processing request: SyntaxError: Unexpected token ',', ...""ai_dump":, "Image":"... is not valid JSON
2025-10-16, 9:17:56 a.m.
[INFO]POST /api/plate-reads
2025-10-16, 9:17:57 a.m.
[ERROR]Error processing request: SyntaxError: Unexpected token ',', ...""ai_dump":, "Image":"... is not valid JSON
2025-10-16, 9:17:57 a.m.
[INFO]POST /api/plate-reads
2025-10-16, 9:17:58 a.m.
[INFO]Received plate read data: [object Object]
2025-10-16, 9:17:58 a.m.
[INFO]POST /api/plate-reads
2025-10-16, 9:17:58 a.m.
[ERROR]Error processing request: SyntaxError: Unexpected token ',', ...""ai_dump":, "Image":"... is not valid JSON
2025-10-16, 9:17:58 a.m.
Make sure you have the correct call. Don't put the &JSON in quotes after the ai_dump parameter.
{ "ai_dump":&JSON, "Image":"&ALERT_JPEG", "camera":"&CAM", "ALERT_PATH": "&ALERT_PATH", "ALERT_CLIP": "&ALERT_CLIP", "timestamp":"&ALERT_TIME" }
It looks like your &JSON is empty.
If still having problems, post the exact call you are making.
{ "ai_dump":&JSON, "Image":"&ALERT_JPEG", "camera":"&CAM", "ALERT_PATH": "&ALERT_PATH", "ALERT_CLIP": "&ALERT_CLIP", "timestamp":"&ALERT_TIME" } - This is a cntrl-V of the call I have, seems correct to me.
My detections look like this in Blue Iris:
My ALPR file folder is populating correctly named images:
However, I am still receiving this error:
I have performed multiple clean installs of the DB and Docker images and updated to v.1.09. I'm beginning to wonder if the problem lies in my updated BI version...?
Possibly... Did you try sending yourself an email alert and including &JSON in the message? It should have all the details from the call to the ALPR module. If it doesn't, then something is messed up. Can you add an email and post the JSON contents?
Try using the plate macro instead of &JSON for now. Seems like something changed in CPAI or BI that’s causing issues parsing the AI response. I think this is related to Pete’s issue.
Nothing is wrong with your BI. The output from CPAI is just kind of dense and alpr db needs to be able to handle it pretty dynamically. Will improve next update.
Switching to use the simple plate number for now should get it working. I recommend switching back to ai dump w &JSON once it’s stabilized.
Edit: also thank you for sharing the screenshot showing that the images are being saved. I wasn’t aware that was the case and that’s very helpful.
Seems like the JSON is working. This is the email alert I get:
This is what I'm assuming you mean for the "plate macro"?
{"plate_number":"&PLATE", "Image":"&ALERT_JPEG", "camera":"&CAM", "ALERT_PATH": "&ALERT_PATH", "ALERT_CLIP": "&ALERT_CLIP", "timestamp":"&ALERT_TIME"} ---- Unfortunately, I get the same "Not Null Constraint" error.
I really am impressed by the potential of this DB and apologize for occupying everyone's time troubleshooting.
@avro201 no need to apologize at all. This is part of what the thread is for, and it helps me understand what needs to improve.
Yes, that is what I mean. That looks correct to me. Additional reference available on the docs site and in the GitHub readme. Please try that and report back if it works. I suspect it will get it working for now.
Yes, that is what I mean. That looks correct to me. Additional reference available on the docs site and in the GitHub readme. Please try that and report back if it works. I suspect it will get it working for now.
I didn't notice this part before: "Unfortunately, I get the same "Not Null Constraint" error."
I don't really understand why this is happening and will have to investigate more. The violation of the constraint means that the app is decoding the api request and not getting a plate number out of it, but still getting the other parts, and trying to add a record without the plate number.
So I don't think this is a database issue. The behavior seems correct to not allow it to insert records without a plate number. I think this is an issue with how the api route is working and constructing the records.
The fact that the plate_number option isn't working either is very confusing though. Like I mentioned, there are multiple possible structures for the data that Blue Iris/cpai might send, so that makes it a bit tricky, but it shouldn't be having this issue.
A substantial amount of people have reported similar or related issues, so I think the handler needs a full rebuild.
With that I will add validation checks before writing to the DB and very specific and granular error messages explaining exactly which part broke in the event of an issue.
I don't really understand why this is happening and will have to investigate more. The violation of the constraint means that the app is decoding the api request and not getting a plate number out of it, but still getting the other parts, and trying to add a record without the plate number.
So I don't think this is a database issue. The behavior seems correct to not allow it to insert records without a plate number. I think this is an issue with how the api route is working and constructing the records.
The fact that the plate_number option isn't working either is very confusing though. Like I mentioned, there are multiple possible structures for the data that Blue Iris/cpai might send, so that makes it a bit tricky, but it shouldn't be having this issue.
A substantial amount of people have reported similar or related issues, so I think the handler needs a full rebuild.
With that I will add validation checks before writing to the DB and very specific and granular error messages explaining exactly which part broke in the event of an issue.
You can expand any or all of your macros and save it to a text file on BI. To do this, go to your camera's On Alert tab and create a new action. Select write-to-file as the method. This should show what BI is sending to the ALPR database.
I have included the Docker Desktop Log for when I get a plate detection in the hope it may shed some light. I have highlighted the plate in blue for reference. Changing to "Ai Dump" or "Memo" macros seems to produce the same result. FYI, I have also refreshed the Schema.sql and Migrations.sql files from the repository.
Thanks @PeteJ, I tried what you suggested. I can't see any glaring issues with the BI output but I am by no means proficient at this. (See Below)
Data: &JSON
Data: [{"api":"alpr","found":{"success":true,"processMs":140,"inferenceMs":124,"predictions":[{"confidence":0.9956827958424886,"is_day_plate":true,"label":"9007AA","plate":"9007AA","x_min":1786,"y_min":872,"x_max":2128,"y_max":1110,"top_plates":[{"plate":"9007AA","confidence":0.9957}]}],"message":"Found 1 license plates: 9007AA","count":1,"moduleId":"ALPRYOLO11","moduleName":"License Plate Recognition (YOLO11)","code":200,"command":"alpr","requestId":"7aa88ab8-84c0-4ea1-b8f0-18374db8aedd","inferenceDevice":"GPU","analysisRoundTripMs":686,"processedBy":"localhost","timestampUTC":"Thu, 16 Oct 2025 20:03:09 GMT"}}]
Thanks @PeteJ, I tried what you suggested. I can't see any glaring issues with the BI output but I am by no means proficient at this. (See Below)
Data: &JSON
Data: [{"api":"alpr","found":{"success":true,"processMs":140,"inferenceMs":124,"predictions":[{"confidence":0.9956827958424886,"is_day_plate":true,"label":"9007AA","plate":"9007AA","x_min":1786,"y_min":872,"x_max":2128,"y_max":1110,"top_plates":[{"plate":"9007AA","confidence":0.9957}]}],"message":"Found 1 license plates: 9007AA","count":1,"moduleId":"ALPRYOLO11","moduleName":"License Plate Recognition (YOLO11)","code":200,"command":"alpr","requestId":"7aa88ab8-84c0-4ea1-b8f0-18374db8aedd","inferenceDevice":"GPU","analysisRoundTripMs":686,"processedBy":"localhost","timestampUTC":"Thu, 16 Oct 2025 20:03:09 GMT"}}]
“In no means proficient at this” - well your reports are very helpful and this is the first time I’ve seen anyone post the error with the specific columnar format, so you seem pretty savvy to me.
It seems like this is actually a much more simple issue than I thought. Some people had reported issues on the plate_number column, but this is showing an issue on the ID column, which is the primary key that should be automatically generated by the DB and never be null.
I can fix and release this later today.
It seems like this is actually a much more simple issue than I thought. Some people had reported issues on the plate_number column, but this is showing an issue on the ID column, which is the primary key that should be automatically generated by the DB and never be null.
I can fix and release this later today.
Alright, apologies for the delay. I thought I was going to have time to deal with that, but I was heading out to a wedding yesterday. I just pushed a docker build with the :nightly tag that should fix this. @avro201 can you please test this and see if it fixes your issue?
In the Docker Compose, replace :latest with :nightly. If the fix works, I'll run a couple more tests to verify, then promote it to the latest release.
Looking back through the code, I'm pretty sure I know why this happened, and I'm not even sure how I made the mistake that led to it. A very simple and fundamental DB architectural mistake.
I tried to make sure that this could fix it without messing with existing installations when they update, but it is so challenging to test an app like this since it's self-hosted, and despite being dockerized, everyone's setups are still slightly different.
In the Docker Compose, replace :latest with :nightly. If the fix works, I'll run a couple more tests to verify, then promote it to the latest release.
Looking back through the code, I'm pretty sure I know why this happened, and I'm not even sure how I made the mistake that led to it. A very simple and fundamental DB architectural mistake.
I tried to make sure that this could fix it without messing with existing installations when they update, but it is so challenging to test an app like this since it's self-hosted, and despite being dockerized, everyone's setups are still slightly different.