Feature Request: Device Name and/or serial number for onDeviceUnplug and for unEnumeration events.

<p>Hi,
</p>
<p>I'm using the "onDeviceUnplug" and "onEnumeration" events to publish an MQTT message when a device disappears or reappears.
</p>
<p>In my use case, I want to keep track of expensive software licensing keys and I want to know if one is ever removed. Then send an SMS or e-mail.<br />
It would be a lot easier and more intuitive to use a name / serial number or a nickname vs having to resolve the 4 available parameters
</p>
<p>"$DEVPATH$" "$ADDRESS" "$VENDOR_ID$" "$PRODUCT_ID$"
</p>
<p>I've tried to capture the events in syslog as a workaround but that seems to be going about it the long way around and it gets complicated when log files get archived and new files are started.
</p>
<p>I'd like to know if it is possible to access the actual device "Name" or "Serial number" or even the "Nickname" and pass it as a parameter?
</p>
<p>For instance in the example dmesg below, I'd like to be able to pass the "Product: DT HyperX 3.0" or "iLok and serial number" to the config.ini event line below.<br />
Or, is it possible to pass the Nickname of the device as a parameter to these two events? It seems that $NICKNAME$" is only valid with the rename event.
</p>
<p>Example dmesg snippets
</p>
<p>(1)<br />
[ 6670.699285] usb 1-1.1.3.4: Product: DT HyperX 3.0<br />
[ 6670.699301] usb 1-1.1.3.4: Manufacturer: Kingston<br />
[ 6670.699316] usb 1-1.1.3.4: SerialNumber: 20CF302E2606BF80D1FF32F5
</p>
<p>(2)<br />
[ 8616.430239] usb 1-1.1.3.4: Product: iLok<br />
[ 8616.430254] usb 1-1.1.3.4: Manufacturer: iLok<br />
[ 8616.430269] usb 1-1.1.3.4: SerialNumber: 12345678_12345678
</p>
<p>config.ini
</p>
<p>onDeviceUnplug=/home/pi/onDeviceUnplug.sh "$DEVPATH$" "$ADDRESS" "$VENDOR_ID$" "$PRODUCT_ID$"
</p>
<p>Any thoughts?
</p>
<p>Alain
</p>

#2

Yes thats fine, i can add that in the next server build due out next week..

#3

Thank you for the quick reply. I had another thought that could help broaden the use case.

In my use case and also in an IT environment with asset management software, it would be ideal to publish the details as a single JSON formatted object.

Two examples are shown here. Either is fine but some asset management software may be able to use the additional details in order to pinpoint the exact location of the asset.

Minimum Template
{
"Nickname" : "128 GB Memory Stick",
"Product" : "DT HyperX 3.0",
"Manufacturer" : "Kingston",
"SerialNumber" : "20CF302E2606BF80D1FF32F5"
}

Full Template
{
"Nickname" : "128 GB Memory Stick",
"Product" : "DT HyperX 3.0",
"Manufacturer" : "Kingston",
"SerialNumber" : "20CF302E2606BF80D1FF32F5",
"DEVPATH": "/sys//devices/platform/soc/3f980000.usb/usb1/1-1/1-1.1/1-1.1.3/1-1.1.3.4",
"ADDRESS": "blahblah",
"VENDOR_ID", "0951",
"PRODUCT_ID","162b"
}

Regards

Alain

#4

No thats too specific but i can add the $NICKNAME$ and $SERIAL$ to the "onDeviceUnplug" and "onEnumeration"

#5

Michael,

Again, appreciate the quick response. I was really happy to see you will be adding $NICKNAME$ and $SERIAL$.

I only mentioned JSON because I've seen it used more and more in certain industrial applications with asset performance monitoring software.
It costs the end-user thousands of dollars to pay for device integration but with JSON being used natively, it becomes a trivial matter to configure these devices.

Perhaps a topic for another day.

Cheers!

Alain

#6

I think the JSON formatter is better left to a bash script, rather than being inside virtualhere.

Anyway i added $NICKNAME$, $PRODUCT$ and $SERIAL$ to onDeviceUnplug and onEnumeration events. This is now in version 4.2.9 of the server now available for download

#7

Michael, Thank you very much for the new feature.

I've tested your changes and they worked perfectly for me. I've attached the script that I use to format the JSON message which I then send out to an MQTT broker.
Subsequently, I send the results as an SMS message using node-red.

I had planned on using the $HOSTNAME$ or $ServerName$ variables that are mentioned in the various API docs but they don't seem to be enabled for these events. I did a work around by hard coding the server name into the config.ini for this test on this server and a thumb drive
.
See below.


config.ini (snippet)


ServerName=USB Server 2
onDeviceUnplug=/home/pi/onDeviceUnplug.sh "$NICKNAME$" "$SERIAL$" "$PRODUCT$" "$VENDOR_ID$" "$PRODUCT_ID$" "$ADDRESS$" "$DEVPATH$" "USB Server 2"
onEnumeration= /home/pi/onEnumeration.sh "$NICKNAME$" "$SERIAL$" "$PRODUCT$" "$VENDOR_ID$" "$PRODUCT_ID$" "$ADDRESS$" "$DEVPATH$" "USB Server 2"
DeviceNicknames=Kingston Thumb Drive 128GB20CF302E2606BF80D1FF32F5,0000,0000,24

This script sample shows how to create the JSON formatted MQTT message, capturing and then sending pretty much all of the related variables for the device.

onDeviceUnplug.sh


#!/bin/sh
#
# MQTT Event Handler for VirtualHere Server
#
# Event: OnDeviceUnplug
#
# V1.0
#
# This script is called by the virtualhere server on the event specified in the
# config.ini file usually located here: /usr/local/etc/virtualhere
#
# example event handler line:
#
# onDeviceUnplug=/home/pi/onDeviceUnplug.sh "$NICKNAME$" "$SERIAL$" "$PRODUCT$" "$VENDOR_ID$" "$PRODUCT_ID$" "$ADDRESS$" "$DEVPATH$" "A Hostname String"
#
# The MQTT message is formatted as JSON and is sent to the MQTT broker
#
#
serverTimeStamp=$(date)
nickName=$1
serialNumber=$2
productName=$3
vendorID=$4
productID=$5
address=$6
devPath=$7
server=$8
#
mqttRequest="{\
\"serverTimeStamp\":\"$(date)\",\
\"nickName\":\"$1\",\
\"serialNumber\":\"$2\",\
\"productName\":\"$3\",\
\"vendorID\":\"$4\",\
\"productID\":\"$5\",\
\"address\":\"$6\",\
\"devPath\":\"$7\",\
\"server\":\"$8\"\
}"
#
# Don't forget to change the address and topic for the MQTT Broker to match that on the actual system
#
function mqttIt{
mosquitto_pub -h xx.xx.xx.xx -t /interior/peripherals/svr2/deviceUnplugEvent -m "$mqttRequest"
}
mqttIt

The SMS message I end up receiving looks similar to this.


Kingston Thumb Drive 128GB
Reconnected to
:: USB Server 2 ::
2021/04/19 02:05:43
http://192.168.2.209:1880/ui/#!/2

#8

Thanks! That could be useful for others too...