OH2.5 DHL rules - String Parsing (for License Plates, from Blue Iris and ALPR via MQTT)

Hello all,
It’s been a while since I’ve been active on here. My OH2.5 (openhabian on a RPi 4) system continues to do just fine, and I haven’t had the time to do the full overhaul/upgrade to OH3 that I have planned.
I have installed Blue Iris on my network, and have license plate recognition working via ALPR. The documentation is scant, however I have Blue Iris passing on the only relevant string variable that I can find that includes the license plate - &PLATE - via MQTT

This includes details I don’t want, and the string doesn’t always have a license plate in it. If it does, it is the first portion of the string. Immediately after the plate (or starting the string if there is no plate) is the word ‘on’, which I thought would be useful.

I am wondering what the best approach to parsing strings in OpenHab. My final result that I want is a text object that gets only the license plate number. For example, the below strings are some of what I received via MQTT, (changed plate numbers):

on car:81
AB123C on car:87
on car:88
D4567E on person:89%,motorcycle:68
FG890H on truck:59%,car:58
on person:91
on car:87
AB123C on car:93
on person:64
on person:79
FG890H on car:68
FG890H on car:89

(as you can see, plate recognition is not yet reliable for recognized vehicles - I still need to tweak my motion zones, etc. The number at the end is the deepstack confidence that it is the given object type)

Given that the strings do not have a consistent structure, I’m not sure that transform is ideal.

My use case, other than logging ins & outs should it ever be relevant to look up, is for my gate automation opening/closing for recognized plates.

(the camera doesn’t record traffic off of my property, and notices are prominently displayed, and I believe I am within privacy regulation compliance. The gate is to keep deer out, and there is an unlocked pedestrian gate, so I’m not worried about someone spoofing their license plate to get in. That being said I don’t want the gate to open randomly for whomever chooses to turn around in my driveway or drive up to my gate)

Thanks for your input & suggestions on how to best go about this.

Hey @bdm, good to hear from you. I can’t be of any direct assistance, but @JimT recently posted a tutorial about licence-plate recognition that may be helpful. So, I’m just connecting the dots.

Thanks Russ,
That is certainly another approach to it - unfortunately too different from my current implementation to be of much help (I don’t have a locally hosted openALPR system, and have a couple hurdles prompting me to use the cloud system for now). Having such a detailed and labelled return string certainly looks nice, however. If I eventually get my workhorse linux system up and running reliably again, I may look at putting a docker OpenALPR onto it.

1 Like

Oh, there is a consistent structure though. You either have six capital letters or numbers followed by a space followed by the word “on”, or it starts with the word “on”.

A REGEX is perfect here. And since you can chain transformations you can even filter out those that start with “on” so the Item only ever updates with the license place number.

Something like

REGEX:(^[\d|[A-Z]]{6} on.*)∩REGEX:^([\d | [A-Z]]{6}) on.*

I just typed these in, you might need a REGEX tester to get it right. But the first REGEX will only forward those messages that start with six digits or capital ASCII letters (if you need unicode there’s a different way to do it) followed by a space and the word “on” followed by anything or nothing. So those messages that start with “on” will just be dropped and ignored.

The second one extracts just the six digits or capital ASCII letters and returns that as what to update the Item with.

1 Like

Thanks Rich, that was the seed that I needed.
I did some digging in a regex tester, and came up with this:
^([A-Z0-9]{5,8}) on.*

this should work for all US states and Canadian provinces, including vanity plates, I believe.

Given that I am stuck in OH2.5 and use text-based rules and item files, here is my solution for those following with this task later:


// Camera/Driveway/Gate/Outdoor Items

Group Vehicles  (Home)

String VehiclePlate "Driveway Plates" <none>  (Vehicles)
String BIVehicleString "Blue Iris Vehicle String" <none>  (Vehicles)  {channel="mqtt:topic:DW-Gate_Cam:DW-Plates"}



rule "Convert Blue Iris MQTT Plate stream into isolated plate number"
    Item BIVehicleString received update
    logInfo("camera.rules", "New License Plate Data.  Processing.")
    val newPlate = transform("REGEX", "^([A-Z0-9]{5,8}) on.*", BIVehicleString.state.toString)
	VehiclePlate.postUpdate( newPlate )
	logInfo("camera.rules", "Plate number : " + newPlate)

I briefly tried to use my mqtt channel in the rules directly, avoiding duplicating it as the BIVehicleString item, but ran into too many challenges, so I went with what I know.

1 Like

You don’t need the rule. If you put the chained transforms on the MQTT Channel you can eliminate this rule.