MikeLud1
IPCT Contributor
Full ALPR Database System for Blue Iris!
- Thread starter algertc
- Start date
Vettester
Getting comfortable
- Feb 5, 2017
- 883
- 861
I think I understand from the docs. It’s fairly straightforward.
The meaning of “flag” is kind of different in the ALPR database vs blue Iris, so idk if I would do that one.
Right now literally all it does is put them in a list and turn it red. Kind of a do-nothing remnant from the original release, but maybe will become useful with automation flows/rules or any db sharing. I might change the name of it to something different. My original intent was for it to be a list of vehicles that you know are problematic.
I think I had the database set and not the app. Maybe the database doesn't need to be set?
I think the coordinates for the box might need to be collected also, but I'm not positive (@MikeLud1 ?). There's a macro that can be added to the payload if it is.
I might add some sort of telemetry/usage data reporting that could include the images and share them automatically. I was thinking about this before, just out of curiosity regarding the usage numbers and localities. Could have some proper big data workflows going if it allows people to send the images too.
I would definitely allow an opt-out. I think I'll make it use an environment variable so that it can be in the readme/compose to be more conspicuous for anyone newly installing if the default is to share.
Last edited:
@VideoDad was this your issue also?
For the logs to work, no the database shouldn't need to change, but I have to believe it would break something somewhere if they were different. When I developed the initial release, it was mostly just for myself, so I was very lazy with the implementation (base64 images in the db for ex) and just wanted to get something working that was better than nothing. Now here we are, and it has kind of trickled down into the whole codebase being pretty messy with very inconsistent and unprincipled structure for things. Most of the timezone formatting happens on the client/browser side, so it's not likely that you would notice any difference there. All of the timestamps are in an ISO format that includes the timezone, so in theory, the db should return the correct results even if they are different, but I'm not 100% sure.
Something I did realize when the log time difference was first brought up though, is that changing this timezone will also fix the notification time issue that @Vettester reported several weeks ago. I ended up just commenting out the time in the push notification since your phone shows the time anyway, and I didn't want to add a timezone item to the settings page. Could add this back in if it is wanted.
I'm back to having stream errors after this latest update. Any ideas? It was working yesterday, then I updated in the evening and now my morning plates are failing.
Perhaps my API value changed? Let me check that first.
Edit: Nevermind, it was my API key. So the question is why does it sometimes change. I'm 99.9% sure I didn't change anything. Also, does the API have a "test" way to call it that would basically validate everything about the call but not update the database? That would be helpful to run after each update (or at anytime, for that matter), as a sanity test that connectivity isn't broken.
Code:
0 1/16/2025 4:48:07.276 PM Cam1a Web: 201 Created
0 1/16/2025 4:48:21.360 PM Cam3b Web: 201 Created
0 1/16/2025 5:03:44.303 PM Cam3b Web: 201 Created
1 1/17/2025 8:13:21.245 AM Cam3b Web: No stream: 401
1 1/17/2025 8:38:02.414 AM Cam3b Web: No stream: 401
1 1/17/2025 9:31:29.624 AM Cam1a Web: No stream: 401
1 1/17/2025 9:32:00.773 AM Cam3b Web: No stream: 401
1 1/17/2025 9:53:09.167 AM Cam3b Web: No stream: 401
1 1/17/2025 9:53:38.852 AM Cam3b Web: No stream: 401Perhaps my API value changed? Let me check that first.
Edit: Nevermind, it was my API key. So the question is why does it sometimes change. I'm 99.9% sure I didn't change anything. Also, does the API have a "test" way to call it that would basically validate everything about the call but not update the database? That would be helpful to run after each update (or at anytime, for that matter), as a sanity test that connectivity isn't broken.
Last edited:
I’ll make it log something if the key is wrong.
The repository and the docker builder are meant to ignore my auth and config files so this doesn’t happen, but I kind of screwed it up. Why it only happens sometimes, I have no idea, but I think what is happening is your key gets changed to whatever was on my computer. I fixed the gitignore but I’ll have to look at the dockerignore again.
I’m doing some TPMS testing now with 2x SDRs.
SDRs already run very hot. With 2 of them, the raspberry pi itself, and POE, this is going to need some sort of airflow. I’ve thought through a few designs that would still be water resistant but not airtight, but I’m not loving any of them so far. Looked at other enclosures too with built-in and most are just a lot larger.
Anyone have ideas/suggestions for a clean and compact enclosure/ how to deal with the heat?
SDRs already run very hot. With 2 of them, the raspberry pi itself, and POE, this is going to need some sort of airflow. I’ve thought through a few designs that would still be water resistant but not airtight, but I’m not loving any of them so far. Looked at other enclosures too with built-in and most are just a lot larger.
Anyone have ideas/suggestions for a clean and compact enclosure/ how to deal with the heat?
MikeLud1
IPCT Contributor
What about an aluminum enclosure and use the enclosure as a heatsink. You can use a short USB extension cables and double sided thermal tape to affix the SDRs to the sides of the enclosure,
As an Amazon Associate IPCamTalk earns from qualifying purchases.
That's clever, but what about during the summer? Box outside might get piping hot on its own...
I think it might be hard to avoid needing some sort of fans
I think it might be hard to avoid needing some sort of fans
MikeLud1
IPCT Contributor
You can add some heatsinks to the outside of the box.
As an Amazon Associate IPCamTalk earns from qualifying purchases.
Wouldn’t it still get way too hot inside the box though if it’s sealed?[/url]
Last edited:
As an Amazon Associate IPCamTalk earns from qualifying purchases.
MikeLud1
IPCT Contributor
Heat transfers from hot to cold so the heatsinks on the outside of the box should be colder then the inside of the box and pull the heat out of the box. The only thing is how efficient is it pulling the heat out of the box might be the issue.
As an Amazon Associate IPCamTalk earns from qualifying purchases.
I’m talking about in 90+ degree summer heat though. Yeah that still might be ok for the SDRs but the CPU itself is going to be cooking in the box.
This is very interesting. Can you explain more about how exactly you would implement?
As an Amazon Associate IPCamTalk earns from qualifying purchases.
MikeLud1
IPCT Contributor
Here is how ChatGPT says to cool it, I estimated about 2 watts for the 2 SDRs and 4 watts for the Raspberry Pi 4
For the Raspberry Pi 4 you can use a heat pipe to transfer the heat outside the box
Last edited:
As an Amazon Associate IPCamTalk earns from qualifying purchases.
I do not know exactly what to do. I just ran across this a few months ago and thought of it when I read your thread.
Maybe this will help?
Thermoelectric cooling - Wikipedia
Here is how ChatGPT says to cool it, I estimated about 2 watts for the 2 SDRs and 4 watts for the Raspberry Pi 4
For the Raspberry Pi 4 you can use a heat pipe to transfer the heat outside the box
Hmm alright very cool. I think I'll consult some electrical engineer friends and see if I can get some input and maybe a more professional solution going. It might make sense to take the cases off the SDRs too.
Would be super cool if I got an actual CAD model and made it really clean. Probably still need to use an off-the-shelf housing to keep the cost low, but for the inside stuff.
As an Amazon Associate IPCamTalk earns from qualifying purchases.