Every year my family hangs a large decorative spider over our doorway for Halloween. This year I decided to make it flash red LED eyes and play a random assortment of spooky sounds (including, but not limited to, bats, chains and the Vincent Price laugh from "Thriller") when trick-or-treaters come to the door. In today's blog post, I'll show how I did it.

The approach

A few years ago, I wrote a post about setting up a motion-activated webcam to trigger license plate recognition with a Raspberry Pi, so I already had a Raspberry Pi and an HC-SR04 ultrasonic rangefinder I could use to detect motion. I initially thought I would only need the Pi for this project, but as I started evaluating the physical constraints of my porch, I realized it would be difficult to mount the Pi in a secure location where it could handle motion detection and also flash the LED eyes. I decided a better approach would be to use an Arduino to detect motion and flash the LEDs, while the Pi would communicate with the Arduino over a serial connection and play Halloween sound effect MP3s.

Setting up the Arduino

I have two red LEDs taped over the spider's eyes that are connected in series to pin 12 on an Arduino UNO. The ultrasonic rangefinder is taped to the side of my porch so that trick-or-treaters have to pass by it before they can knock on my door, and it is connected to pin 9 for the trigger and pin 10 for the echo. The Arduino listens for serial commands from the Pi to measure distance or to flash the LEDs if the Pi determines the reported distance measurement means someone has approached.

Here's my sketch:

//set the pin numbers
const int triggerPin = 9;
const int echoPin = 10;
const int ledPin = 12;

void setup() 
{
  Serial.begin(9600); // Starts the serial communication
  pinMode(triggerPin, OUTPUT); // Sets the triggerPin as an Output
  pinMode(echoPin, INPUT); // Sets the echoPin as an Input
  pinMode(ledPin, OUTPUT);
}

void loop() 
{
  if (Serial.available() > 0) { 
    int controlcode = Serial.parseInt();
    if(controlcode==1)
    {
      //clear the trigger pin
      digitalWrite(triggerPin, LOW);
      delayMicroseconds(2);

      //send a 10 microsecond pulse
      digitalWrite(triggerPin, HIGH);
      delayMicroseconds(10);
      digitalWrite(triggerPin, LOW);

      //read the echo pin to get the duration in microseconds
      long duration = pulseIn(echoPin, HIGH);
      
      //calculate the distance in centimeters
      int distance = duration*0.034/2;
      
      //return the distance to the serial monitor
      Serial.println(distance);
    }
    if(controlcode==2)
    {
      flashEyes();
    }
  }
}

void flashEyes()
{
  //flash 50 times
  for(int i=0;i<50;i++)
  {
    //turn the eyes on
    digitalWrite(ledPin, HIGH);
    
    //wait for 150ms
    delay(150);
    
    //turn the eyes off
    digitalWrite(ledPin, LOW);
    
    //wait for 100ms
    delay(100);
  }
}

Setting up the Raspberry Pi

My Raspberry Pi 2 Model B is connected to the Arduino over a standard USB A/B cable, and it's also connected to a Bluetooth speaker mounted behind the spider. To run things, I have a Python script that sends a serial command to the Arduino to measure the distance every 50 milliseconds. If the Arduino returns a value between 20 and 120 centimeters, the Python script sends a serial command to the Arduino to flash the LEDs, and uses mpg123 to play a random MP3 file.

Here's the script:

import serial
import time
import subprocess
import random
port = "/dev/ttyACM0"

def playsound():
    i = 0
    screamnumber = str(random.randint(1,5))
    screamfile = "/home/pi/halloween/X.mp3".replace("X",screamnumber) 
    subprocess.Popen(["mpg123", screamfile])
 
if __name__ == '__main__':
    s1 = serial.Serial(
      port=port,\
      baudrate=9600)
    s1.flushInput()
    
    #wait 5 seconds before telling the arduino look for motion
    time.sleep(5)
    try:
        while True:
          if s1.in_waiting==0:
            #print('sent request')
            s1.write('1\n')
            time.sleep(.05)
          if s1.in_waiting>0:
            #print('received response')
            inputValue = s1.readline()
            #print('Distance: ' + inputValue)
            if int(inputValue) > 20 and int(inputValue) < 120:
              print('Distance: ' + inputValue)
              s1.write('2\n')
              playsound()
              time.sleep(15)
            else:
              time.sleep(.05)
 
    #quit with ctrl + c
    except KeyboardInterrupt:
        print("script stopped by user")

To enable serial communication, I am using the pySerial module. I should also note the logic for playing a random MP3 assumes that there are five files in the same directory as the script that are named 1.mp3, 2.mp3, etc. Using a different number of files would require changing the upper bound value on line 9.

Happy Halloween!

This is the fifth and final post in a five-part series on how I integrated a Raspberry Pi with Microsoft Dynamics CRM to recognize contacts using automobile license plates. Although the code samples are focused on license plate recognition, the solution architecture I used is applicable to any Dynamics CRM + Internet of Things (IoT) integration. In my previous post, I showed how to execute the license plate recognition and contact search with JavaScript directly in the web resource. Today I will show how to set up a streaming interface so the Raspberry Pi can take a picture, parse the plate number and trigger the web resource to search for and display a contact without any input from the end user.

The approach

As I described in part 1 of this series, in this approach the Raspberry Pi takes a picture, parses the plate number and writes it to a streaming interface using Socket.IO. A web page or client application picks up the plate numbers from that interface, and then it queries CRM for a contact with the returned license plate number to display the details to the user. Essentially this is just a variation on what I described in my "Creating a near real-time streaming interface for Dynamics CRM with Node.js" series in late 2014.

Node.js code

In part 2 I showed the complete Node.js code to support all the scenarios in this series, but I did not discuss the streaming interface. Basically the streaming interface behaves almost exactly the same as the non-streaming interface except instead of writing the JSON result object in the HTTP response, it posts the JSON result object to a Socket.IO interface.

app.get('/check_plate_stream', function (req, res) {
	//generate a guid to use in the captured image file name
	var uuid1 = uuid.v1();
	
	//tell the webcam to take a picture and store it in the captures directory using the guid as the name
	exec('fswebcam -r 1280x720 --no-banner --quiet ./captures/' + uuid1 + '.jpg',
	  function (error, stdout, stderr) {
		if (error !== null) {
		  //log any errors
		  console.log('exec error: ' + error);
		}
	});
	
	//now that we have a picture saved, execute parse it with openalpr and return the results as json (the -j switch) 
	exec('alpr -j ./captures/' + uuid1 + '.jpg',
	  function (error, stdout, stderr) {
		//create a json object based on the alpr output
		var plateOutput = JSON.parse(stdout.toString());
		
		//add an "image" attribute to the alpr json that has a path to the captured image
		//this is so the client can view the license plage picture to verify alpr parsed it correctly
		plateOutput.image = '/captures/' + uuid1 + '.jpg';

		//write the json to the socket.io interface
		io.emit('message', plateOutput);

		//return a response to the caller that the message was sent
		res.send('message sent');

		//log the response from alpr
		console.log('alpr response: ' + stdout.toString());
		
		if (error !== null) {
		  //log any errors
		  console.log('exec error: ' + error);
		}
	});
});

The triggering mechanism is still a web route, so it can be called in a number of different ways without having to modify the base code. I've written a separate Node.js application that uses an HC-SR04 ultrasonic rangefinder to detect when a license plate moves into view and then call the streaming interface URL to trigger the license plate capture and recognition. The motion detection script is available on GitHub here.

I am running the motion detection script on the same Raspberry Pi as the webcam, but it could easily be run on a separate piece of hardware, too. You could also use the same approach to connect it to any sort of other sensor or input.

Here is a picture of my motion detection rig with my unimpressed Great Dane behind it for scale.

The web resource

The web resource loads the Socket.IO library from a CDN.
<script src="https://cdn.socket.io/socket.io-1.2.0.js"></script>

The web resource then connects to the streaming interface and listens for a message. Once it picks up a license plate number from the streaming interface, it then queries CRM to find a contact just like in part 4.

var piRootPath = "http://192.168.1.112:3000";
var socket = io("http://192.168.1.112:3000");

socket.on('message', function(resultObj){
$("#outputdiv").text("");
if(resultObj.results.length > 0) {
	var plateNum = resultObj.results[0].plate;
	var imgUrl = resultObj.image;
	$("#outputdiv").append("Detected plate number: " + plateNum + "
");
	
	$("#outputdiv").append("<img src='" + piRootPath + imgUrl+ "' width='400' />");
	
	var oDataURI = Xrm.Page.context.getClientUrl()
	+ "/XRMServices/2011/OrganizationData.svc/"
	+ "ContactSet?$select=ContactId,FullName&$filter=lpa_Platenumber eq '" + plateNum +"'";
	
	var req = new XMLHttpRequest();
	req.open("GET", encodeURI(oDataURI), true);
	req.setRequestHeader("Accept", "application/json");
	//req.setRequestHeader("Content-Type", "application/json; charset=utf-8");
	req.onreadystatechange = function () {
		if (this.readyState == 4 /* complete */) {
			req.onreadystatechange = null; //avoids memory leaks
			if (this.status == 200) {
				successCrmCallback(JSON.parse(this.responseText).d.results);
			}
			else {
				errorCallback();
			}
		}
	};
	req.send();
}
else {
	$("#outputdiv").append("No plate detected
");
}
});

If a matching contact is found, it's displayed. Otherwise a failure message is displayed instead.

function successCrmCallback(contacts) {
	if(contacts.length > 0) {
		var contactUrl = Xrm.Page.context.getClientUrl() + "/main.aspx?etc=2&extraqs=&pagetype=entityrecord&id=%7b" + contacts[0].ContactId + "%7d";
		$("#outputdiv").prepend("Contact: <a href='" + contactUrl + "' target='_blank'>" + contacts[0].FullName + "</a><br />");	
	}
	else {
		//otherwise display a message that no contact could be found
		$("#outputdiv").prepend("No contact found
");
	}
	$("#checkButton").prop('disabled', false);
}

The web resource (lpa_checkplatestream.htm) is included in my sample CRM solution along with the contact entity configured to store the license plate number. The sample CRM solution is available in my GitHub repository here.

Demo

Here's the CRM web resource open a new tab. Note there's no button to trigger the plate capture and recognition.

This is the web page used to trigger the plate capture and recognition opened in Chrome.
When using my motion detection script, this page is never shown to the end user.

Finally here is the web resource once it gets the message from the stream and looks up the contact details. If the plate recognition is triggered again, the page will update itself.

Wrapping up

I hope you've enjoyed reading this series as much as I've enjoyed writing it. Through the process of working out the various scenarios I've certainly learned a lot about how the Raspberry Pi can be combined with Dynamics CRM to support novel business processes.

Here are links to all the previous posts in this series.

1. Part 1 - Series introduction
2. Part 2 - Node.js application
3. Part 3 - CRM custom assembly trigger
4. Part 4 - JavaScript in CRM web resource trigger

Do you have plans to integrate your Dynamics CRM system with the Internet of Things? If so, how? Let us know in the comments!

This is the fourth post in a five-part series on how I integrated a Raspberry Pi with Microsoft Dynamics CRM to recognize contacts using automobile license plates. Although the code samples are focused on license plate recognition, the solution architecture I used is applicable to any Dynamics CRM + Internet of Things (IoT) integration. In my previous post, I showed how to trigger the license plate recognition process and then use the extracted license plate number to find a contact in my Dynamics CRM organization with a custom workflow activity. Today I'll show how to execute the license plate recognition and contact search with JavaScript directly in the web resource.

The approach

As I described in part 1 of this series, this approach uses JavaScript to call the Raspberry Pi to take a picture and return the parsed license plate number. Once a license plate number is retrieved, the JavaScript code then queries CRM for a contact with the returned license plate number and displays its details to the user. As long as the CRM end user's computer can access the Raspberry Pi, it doesn't matter if the Pi is visible to the CRM server, so this easily works with CRM Online.

The web resource

A web resource is used so the user can interactively trigger the license plate recognition and open the contact record if a match is found. The web resource also displays the image that is captured by the Raspberry Pi so the user can validate that the license plate number extracted by OpenALPR matches the actual license plate number.

Executing the license plate recognition on the Raspberry Pi just requires making a GET request to the Node.js web page described in part 2 and then parsing the JSON response.

//command to start checklplate action call when button is pushed  
function executeCheckplate() { 
	$("#outputdiv").text("");
	$("#checkButton").prop('disabled', true);
	var checkplateURI = piRootPath + "/check_plate";
    var req = new XMLHttpRequest();
    req.open("GET", encodeURI(checkplateURI), true);
    req.setRequestHeader("Accept", "application/json");
    //req.setRequestHeader("Content-Type", "application/json; charset=utf-8");
    req.onreadystatechange = function () {
        //debugger;
        if (this.readyState == 4 /* complete */) {
            req.onreadystatechange = null; //avoids memory leaks
            if (this.status == 200) {
                successPlateCallback(JSON.parse(this.responseText));
            }
            else {
                errorCallback();
            }
        }
    };
    req.send();
}

Once the response is returned from the Raspberry Pi, the web resource then queries CRM to find a contact, unless no plate was detected, in which case it displays a failure message.

function successPlateCallback(resultObj) {
	if(resultObj.results.length > 0) {
		var plateNum = resultObj.results[0].plate;
		var imgUrl = resultObj.image;
		$("#outputdiv").append("Detected plate number: " + plateNum + "
");
		
		//show the captured plate image
		$("#outputdiv").append("<img src='" + piRootPath + imgUrl+ "' width='400' />");
		
		var oDataURI = Xrm.Page.context.getClientUrl()
        + "/XRMServices/2011/OrganizationData.svc/"
        + "ContactSet?$select=ContactId,FullName&$filter=lpa_Platenumber eq '" + plateNum +"'";
		
		var req = new XMLHttpRequest();
		req.open("GET", encodeURI(oDataURI), true);
		req.setRequestHeader("Accept", "application/json");
		//req.setRequestHeader("Content-Type", "application/json; charset=utf-8");
		req.onreadystatechange = function () {
			if (this.readyState == 4 /* complete */) {
				req.onreadystatechange = null; //avoids memory leaks
				if (this.status == 200) {
					successCrmCallback(JSON.parse(this.responseText).d.results);
				}
				else {
					errorCallback();
				}
			}
		};
		req.send();
	}
	else {
		$("#outputdiv").append("No plate detected
");
		$("#checkButton").prop('disabled', false);
	}
}

If a matching contact is found, it's displayed. Otherwise a failure message is displayed instead.

function successCrmCallback(contacts) {
	if(contacts.length > 0) {
		var contactUrl = Xrm.Page.context.getClientUrl() + "/main.aspx?etc=2&extraqs=&pagetype=entityrecord&id=%7b" + contacts[0].ContactId + "%7d";
		$("#outputdiv").prepend("Contact: " + contacts[0].FullName + "
");	
	}
	else {
		//otherwise display a message that no contact could be found
		$("#outputdiv").prepend("No contact found
");
	}
	$("#checkButton").prop('disabled', false);
}

The web resource (lpa_checkplatejs.htm) is included in my sample CRM solution along with the contact entity configured to store the license plate number. The sample CRM solution is available in my GitHub repository here.

Demo

Here's the web resource open a new tab.

Here's the result after I click the "check plate" button. The contact name is a hyperlink that will open the contact record in a new window.

That's it for today. In my next and final post in this series, I'll show how to set up a streaming interface so the Raspberry Pi can take a picture and parse the plate number, which will then trigger the web resource to search for and display a contact without any input from the end user.

This is the third post in a five-part series on how I integrated a Raspberry Pi with Microsoft Dynamics CRM to recognize contacts using automobile license plates. Although the code samples are focused on license plate recognition, the solution architecture I used is applicable to any Dynamics CRM + Internet of Things (IoT) integration. In my previous post, I showed how I set up my Raspberry Pi to capture images and parse them for license plate numbers. In today's post, I will show how to trigger the license plate recognition process and then use the extracted license plate number to find a contact in my Dynamics CRM organization with a custom workflow activity.

The approach

As I described in part 1 of this series, this approach uses a web resource, a dialog or some other interactive mechanism to call a custom workflow activity that instructs the Raspberry Pi to take a picture and return the parsed license plate number. The code hosted in CRM then searches for a contact with the returned license plate number and displays its details to the user. This requires that the CRM server be able to communicate with the Raspberry Pi, which may be challenging for CRM Online deployments.

Today I'll show how to call the custom workflow activity from a web resource, which will require the use of a custom CRM action so that the web resource can execute the functionality with a JavaScript call.

The custom workflow assembly

Interacting with the Node.js web page just requires making a GET request and then parsing the JSON response, so the approach to working with JSON data in custom workflow assemblies that I've used in several other posts will work great for this.

There are only a few changes required to that sample:

1. Modify the JSON response classes to match the JSON object returned by the Node.js application.
2. Modify the web request to be a GET instead of a POST.
3. Add logic to search for contacts by license plate number and return the contact id as a string.
4. Update the input/output parameters to return the contact, license plate and image details.

The code for the custom workflow assembly is available in my Crm-Sample-Code repository on GitHub here

One thing to keep in mind is that because I wanted to register the assembly in isolation, I had to create a hosts entry for my Raspberry Pi on my CRM application server since sandboxed assemblies cannot make web requests to IP address URLs. Alternatively I could have created an entry on my LAN DNS server.

The custom CRM action

A custom CRM action is used to wrap the workflow assembly so that it can be called from a web resource via JavaScript. The action simply passes a request to the workflow assembly and returns its response to the client.

The web resource

Finally a web resource is used so the user can interactively trigger the license plate recognition and open the contact record if a match is found. The web resource also displays the image that is captured by the Raspberry Pi so the user can validate that the license plate number extracted by OpenALPR matches the actual license plate number.

The web resource (lpa_checkplate.htm) is included in my sample CRM solution along with the custom action, compiled plugin and contact entity configured to store the license plate number. The sample CRM solution is available in my GitHub repository here.

Demo

Here's the web resource open a new tab.

Here's the result after I click the "check plate" button. The contact name is a hyperlink that will open the contact record in a new window.

That's it for today. In my next post, I'll show how to execute the license plate recognition and contact search with JavaScript directly in the web resource.

This is the second post in a five-part series on how I integrated a Raspberry Pi with Microsoft Dynamics CRM to recognize contacts using automobile license plates. As I mentioned in the first post of the series, the solution architecture I used is applicable to any Dynamics CRM + Internet of Things (IoT) integration. In today's post I will show how I set up my Raspberry Pi to handle the basic license plate capture and parsing operations.

Tooling

For this demonstration I am using the following tools:

1. Raspberry Pi 2 Model B running Raspbian (Any Linux distribution that runs on the Raspberry Pi should work with the code I'm showing, but the configuration steps later might be different.)
2. Logitech HD Webcam C615 to take photos
3. OpenALPR to recognize license plates
4. Node.js to provide a web-based interface to OpenALPR (and post to Socket.IO in the streaming interface)

OpenALPR and Node.js both run on Windows, so I think it should be possible to create a comparable solution using Windows 10 for IoT on a Raspberry Pi 2. Also, if you don't have a Pi or comparable IoT device, you can try this out on any system where you can run the software.

Basic Raspberry Pi configuration

Configuring the Raspberry Pi is beyond the scope of today's post, but as long as you have a Raspberry Pi running Raspbian with network access you should be good to go. My Pi is on my LAN with an IP address of 192.168.1.112, and all ports are open.

Camera

I am using a Logitech HD Webcam C615 because I just happened to have one available. Theoretically any Raspberry Pi-compatible webcam or the dedicated Raspberry Pi camera module should work. I am using the fswebcam package to interact with my webcam, and I followed the instructions here to get it working. As you'll see from the captured image at the end of this post, the quality of the images I'm capturing leaves something to be desired, but things seem to be working well enough that I haven't explored different configuration options to improve the quality.

OpenALPR

OpenALPR is the tool that parses images to find license plate numbers. You can download it from GitHub, and follow the directions in the "Easy Way" section here to build and install it. I also should be possible to use Docker as described here, but I haven't tried it myself.

Once you have OpenALPR installed, you can test that it's working using sample images like so:

wget http://plates.openalpr.com/ea7the.jpg
alpr -c us ea7the.jpg

wget http://plates.openalpr.com/h786poj.jpg
alpr -c eu h786poj.jpg

OpenALPR can also be run as a daemon that continually checks a camera stream and outputs detected license plates, but I chose not to use it in this case because the open source version never stops. If you put a license plate in front of the webcam, the open source OpenALPR daemon will just keep returning the parsed license plate number over and over again. I believe the commercial version includes a motion detector feature, but to put together this sample on the cheap, I didn't explore it.

Node.js

Having put together a few proof-of-concept interfaces using Node.js in the past, it was the first thing that came to mind to create a web-based interface to OpenALPR. You could use a variety of other options like Python, Perl, PHP or C# if you prefer, but Node.js made setting up this part of the sample extremely easy.

First you need to make sure Node.js is installed:

sudo apt-get install nodejs

Then you need to install the following modules with npm:

1. node-uuid
2. express
3. socket.io

Node.js code

Here is the complete Node.js code to support all the scenarios in this series:

var http = require('http');
var express = require('express'),
    app = module.exports.app = express();
var server = http.createServer(app);
var io = require('socket.io').listen(server, {log:false, origins:'*:*'})
var uuid = require('node-uuid');
var sys = require('sys'),
    exec = require('child_process').exec;

//allow clients to directly view the images in the captures directory
app.use('/captures', express.static('captures'));

//route for the home page
app.get('/', function (req, res) {
	res.send('home page');
});

//route to handle a client calling node to check a plage
app.get('/check_plate', function (req, res) {
	//generate a guid to use in the captured image file name
	var uuid1 = uuid.v1();
	
	//tell the webcam to take a picture and store it in the captures directory using the guid as the name
	exec('fswebcam -r 1280x720 --no-banner --quiet ./captures/' + uuid1 + '.jpg',
	  function (error, stdout, stderr) {
		if (error !== null) {
		  //log any errors
		  console.log('exec error: ' + error);
		}
	});

	//now that we have a picture saved, execute parse it with openalpr and return the results as json (the -j switch) 
	exec('alpr -j ./captures/' + uuid1 + '.jpg',
	  function (error, stdout, stderr) {
		//create a json object based on the alpr output
		var plateOutput = JSON.parse(stdout.toString());
		
		//add an "image" attribute to the alpr json that has a path to the captured image
		//this is so the client can view the license plage picture to verify alpr parsed it correctly
		plateOutput.image = '/captures/' + uuid1 + '.jpg';
		
		//set some headers to deal with CORS
		res.header("Access-Control-Allow-Origin", "*");
		res.header("Access-Control-Allow-Headers", "X-Requested-With");
		
		//send the json back to the client
		res.json(plateOutput);
		
		//log the response from alpr
		console.log('alpr response: ' + stdout.toString());
		
		if (error !== null) {
		  //log any errors
		  console.log('exec error: ' + error);
		}
	});
});

//route to handle a request for a license plate capture to be written to a socket.io interface
//basically the same as the non-streaming interface except the output gets written somewhere different
app.get('/check_plate_stream', function (req, res) {
	//generate a guid to use in the captured image file name
	var uuid1 = uuid.v1();
	
	//tell the webcam to take a picture and store it in the captures directory using the guid as the name
	exec('fswebcam -r 1280x720 --no-banner --quiet ./captures/' + uuid1 + '.jpg',
	  function (error, stdout, stderr) {
		if (error !== null) {
		  //log any errors
		  console.log('exec error: ' + error);
		}
	});
	
	//now that we have a picture saved, execute parse it with openalpr and return the results as json (the -j switch) 
	exec('alpr -j ./captures/' + uuid1 + '.jpg',
	  function (error, stdout, stderr) {
		//create a json object based on the alpr output
		var plateOutput = JSON.parse(stdout.toString());
		
		//add an "image" attribute to the alpr json that has a path to the captured image
		//this is so the client can view the license plage picture to verify alpr parsed it correctly
		plateOutput.image = '/captures/' + uuid1 + '.jpg';

		//write the json to the socket.io interface
		io.emit('message', plateOutput);

		//return a response to the caller that the message was sent
		res.send('message sent');

		//log the response from alpr
		console.log('alpr response: ' + stdout.toString());
		
		if (error !== null) {
		  //log any errors
		  console.log('exec error: ' + error);
		}
	});
});

//start the server listening on port 3000
server.listen(3000, function () {
	console.log('App listening');
});

If you look at the "check_plate" route starting at line 19, you can see the script does the following things:

1. Generate a new GUID to use in the captured image name.
2. Take a picture with the webcam and save it to the "captures" directory.
3. Execute OpenALPR to parse the image and return the results in a JSON object.
4. Modify the JSON object to include the image path
5. Return the JSON object to the client.

Trying it out

To try out the code, do the following:

1. Save the Node.js script from above as app.js.
2. Upload it to a directory on your Pi.
3. Create a directory called "captures" under that directory.
4. Start the application using the following command: nodejs app.js.
5. Navigate to the URL for the Node.js application from a web browser.

Here's a picture of my testing "studio." The Pi and webcam are sitting on a TV tray in front of an old license plate propped up on a couch in my office.

When I call Node.js from my browser, this is what I see.

This is the JSON response formatted for easier reading.

{
	"version":2,
	"data_type":"alpr_results",
	"epoch_time":1450713975002,
	"img_width":1280,
	"img_height":720,
	"processing_time_ms":2567.216553,
	"regions_of_interest":[],
	"results":[
	{
		"plate":"43C32Y3",
		"confidence":91.097946,
		"matches_template":0,
		"plate_index":0,
		"region":"",
		"region_confidence":0,
		"processing_time_ms":269.342682,
		"requested_topn":10,
		"coordinates":[
		{
			"x":414,
			"y":315
		},
		{
			"x":812,
			"y":319
		},
		{
			"x":812,
			"y":516
		},
		{
			"x":414,
			"y":511
		}],
		"candidates":[
		{
			"plate":"43C32Y3",
			"confidence":91.097946,
			"matches_template":0
		},
		{
			"plate":"43G32Y3",
			"confidence":81.515587,
			"matches_template":0
		},
		{
			"plate":"43C3ZY3",
			"confidence":81.408203,
			"matches_template":0
		},
		{
			"plate":"43C32YS",
			"confidence":80.856506,
			"matches_template":0
		},
		{
			"plate":"43C32Y",
			"confidence":79.70826,
			"matches_template":0
		},
		{
			"plate":"43G3ZY3",
			"confidence":71.825851,
			"matches_template":0
		},
		{
			"plate":"43G32YS",
			"confidence":71.274155,
			"matches_template":0
		},
		{
			"plate":"43C3ZYS",
			"confidence":71.166771,
			"matches_template":0
		},
		{
			"plate":"43G32Y",
			"confidence":70.1259,
			"matches_template":0
		},
		{
			"plate":"43C3ZY",
			"confidence":70.018524,
			"matches_template":0
		}]
	}],
	"image":"/captures/be8da820-a7fc-11e5-a63a-7bb250f23f1c.jpg"
}

Here is the Node.js output from the Raspberry Pi command line.

This is the actual image the webcam captured. The white balance is horrible, but the plate number is clear enough for OpenALPR to recognize.

That's it for now. In my next post, I'll show how to trigger the license plate recognition functionality from a custom assembly in Dynamics CRM.

Today's post is the first in a five-part series on how I integrated a Raspberry Pi with Microsoft Dynamics CRM to recognize contacts using automobile license plates. Although my solution is focused on the use of license plate numbers captured by a webcam, the solution architecture is applicable to any Dynamics CRM + Internet of Things (IoT) integration. Over the course of this series, I will show how I configured my Raspberry Pi and how I built different integrations to use the license plate data in Dynamics CRM.

Background

Last year I was working on a Dynamics CRM project for one of the largest automakers in the world, and I got to thinking about whether it'd be possible to integrate license plate recognition with our CRM system. This would have given dealers a tool so that service advisers could immediately see customer details and service preferences as soon as a car drove into a service bay. My idea never went anywhere, and eventually I moved on to a different company, but I'd still think about it every once in a while.

Then I saw an article last week about open-source license plate reader software called OpenALPR that got me thinking about this again. Because I'd just gotten a Raspberry Pi 2, and I had an old webcam that was just gathering dust in my office, I finally had everything I needed to build a Dynamics CRM license plate reader integration.

The approach

Thinking about this from the perspective of a CRM user who wants to be able to recognize a contact based on a license plate, there are a few obvious elements required:

1. Camera to capture a license plate image
2. Software to parse the license plate number from image (OpenALPR)
3. Code to trigger the license plate number parsing and return results to a consumer
4. Field to store license plate numbers in CRM
5. Code to retrieve and display the CRM contact details

The right way to put these together is less obvious because there are several possible approaches, but none are appropriate in all scenarios. For example, if the CRM user is going to trigger the license plate recognition in CRM, there are at least three potential approaches:

1. CRM custom assembly - Using a web resource, a dialog or some other interactive mechanism, a custom workflow activity or plug-in is called that instructs the Raspberry Pi to take a picture and return the parsed license plate number. The code hosted in CRM then searches for a contact with the returned license plate number and displays its details to the user. This approach requires that the CRM server be able to communicate with the Raspberry Pi, which may be challenging for CRM Online deployments.
2. JavaScript in web resource - Using a web resource, JavaScript is called that instructs the Raspberry Pi to take a picture and return the parsed license plate number. Once a license plate number is retrieved, the JavaScript code then queries CRM for a contact with the returned license plate number and displays its details to the user. As long as the CRM end user's computer can access the Raspberry Pi, it doesn't matter if the Pi is visible to the CRM server, so this easily works with CRM Online.
3. Business logic on the Raspberry Pi - Using a web resource, JavaScript is called that instructs the Raspberry Pi to take a picture and parse the license plate number. Once a license plate number is retrieved, the Raspberry Pi then queries CRM for a contact with the returned license plate number and returns its details to the user. I don't love this approach because it requires extra effort to get the Pi to communicate with CRM, and I prefer to keep the Pi as "dumb" as possible.

If the license plate recognition is triggered via camera motion detection, a physical button or a sensor without direct input from the CRM user, there are at least two potential approaches:

1. Streaming interface - The Raspberry Pi takes a picture, parses the plate number and writes it to a streaming interface using Socket.IO or a similar mechanism. A web page or client application picks up the plate numbers from that interface, and then it queries CRM for a contact with the returned license plate number to display the details to the user. This approach is basically a variation on what I described in my "Creating a near real-time streaming interface for Dynamics CRM with Node.js" series last year.
2. Back-end data post - The Raspberry Pi takes a picture, parses the plate number and posts it to CRM. The data can be posted directly to CRM or use a message queue. This approach is good if a CRM user doesn't need immediate access to the data.

In this series I will show how I built solutions that demonstrate three of the approaches above:

1. CRM custom assembly
2. JavaScript in web resource
3. Streaming interface

As for why I'm not showing the other approaches:

1. I just don't think the business logic on the Raspberry Pi approach is useful here. I'm sure there are times it might make sense, but my hypothetical scenario here isn't one of them.
2. The back-end data post approach is almost the same as the streaming interface, except the Pi posts the data to CRM instead of Socket.IO.

In my next post, I'll show how I set up my Raspberry Pi to handle the basic license plate capture and parsing operations. See you then!