In this project you’re going to learn how to build a car recognition system using a Raspberry Pi and Node-RED. For this project we’ll be using a software called OpenALPR (Automatic License Place Recognition) that has an API you can use to identify car plates and car models based on an image.
Source: Car Plate Recognition System with Raspberry Pi and Node-RED
Kashmir Hill filled her home with gadgets to see how much data they would slurp up.
Source: TED 2018: The smart home that spied on its owner – BBC News
VERY GOOD INDEED!
Source: Coinbase Open Source Fund April 2018: Tools – The Coinbase Engineering Blog
Something that may confuse new users of VSCP is the GUID of interfaces. Looking at the interface above the CAN4VSCP driver have GUID set to
FF:FF:FF:FF:FF:FF:FF:FE:B8:27:EB:0A:00:02:00:00
which means nodes connected to this interface will come in with GUID’s
FF:FF:FF:FF:FF:FF:FF:FE:B8:27:EB:0A:00:02:00:01 FF:FF:FF:FF:FF:FF:FF:FE:B8:27:EB:0A:00:02:00:02 FF:FF:FF:FF:FF:FF:FF:FE:B8:27:EB:0A:00:02:00:03 FF:FF:FF:FF:FF:FF:FF:FE:B8:27:EB:0A:00:02:00:04 ....
If we look at the GUID’s if this machine we see that they all start with
FF:FF:FF:FF:FF:FF:FF:FE
As of the spec we know that this is a GUID constructed from an Ethernet address. In this case only four of the six MAC digits is used. The
00:02
is the interface id as set by the VSCP daemon and the last two digits are the nickname id for a connected node.
The problem that can occur here is that the interface digits can be different at different runs of the VSCP daemon. The number is just set when the interface is set up and from time to time this setup can happen in different order. So sometime
00:02
can be
00:03
or even
00:11
One can’t tell beforehand.
This is a problem if one want to use the GUID to identify a node. Problematic as this is just what we want in most cases. To trigger on an event from a specific node in a decision matrix the GUID is the item to filter on. Just as in this case
Here we store a temperature measurement in a variable if it comes from a node with GUID
FF:FF:FF:FF:FF:FF:FF:FE:B8:27:EB:0A:00:02:00:01
and measurement index = 1
If the interface ordinal becomes something else like
00:03
we are in trouble here as the action (store measurement value in variable) will not be triggered.
If we look at the current driver for this setup it is set to
<!-- The can4vscp driver -->
<driver enable="false" >
<name>can4vscp</name>
<config>/dev/ttyUSB1</config>
<path>/srv/vscp/drivers/level1/vscpl1drv-can4vscp.so</path>
<guid>00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00</guid>
<flag>>0</flags>
</driver>
The “problem” is solved by changing the <guid> tag from an all zero value (or not defined) to a valid GUID. If not defined or all zero the VSCP daemon will assign a GUID as of above. But if a valid GUID is set this value will always be used.
In my case I can use
01:00:00:00:00:00:00:00:00:00:00:00:01:02:00:00
as I have some assigned GUIDs. The two LSB’s is still used for the nicknames.
After that change the “problem” is no more and I can filter on the new GUID instead which alway will be the same.