Examining IoT in the Physical World

I recently spent some time beta testing Meraki’s new cloud-managed smart automation button the MT30. Let’s look at MT30’s capabilities and where you might be able to apply this to your physical spaces.

Meraki’s MT30 is similar to other sensors in the MT product line. MT sensors are Bluetooth low energy devices which communicate back to the Meraki cloud through the Bluetooth gateway functionality built into the MR wireless access point or MV smart camera. Onboarding a new sensor follows the standard Meraki flow of claiming the device, adding the device to a network and simple configuration via dashboard or API. 

The MT30 is unique among the product line in that user input (via its prominent button) relies on physical interaction to drive data to the cloud. Other sensors, such as the MT10 (indoor temperature and humidity sensor) and the MT14 (indoor air quality sensor), collect streaming data with no expectation of user interaction. The MT12 (indoor water leak sensor) and MT20 (indoor door open/close sensor) are closer in nature; they provide state data but are not as flexible as the MT30.

Meraki simplified the creation of automation workflows for the MT30 with a step-by-step wizard within the “environmental sensors” dashboard section. Creating an automation simply requires the user to give their automation a name, select the sensor they want to utilize, their desired trigger (any press, short press, or long press for the MT30) and an action to perform.

Meraki also anticipated several use cases in the available actions that require no external components, such as notifications (both email and SMS), a camera snapshot and the “toggling off” or “toggling on” of a SSID or switchport.  

It’s easy to imagine use cases for scenarios that can be implemented immediately. 

A button paired with a camera can act as a spot check monitor system. In this instance, the MT30 could indicate to a security desk that someone is ready to be let into a secure entry point and trigger a camera snapshot from an MV smart camera for identity verification, the way many IoT doorbell systems function. 

SSID toggling is a great way to allow a non-technical person or someone who you may not wish to grant dashboard access to shut off the guest network at the end of the day to reduce possible attack surfaces for hackers. 

Switchport toggling can be utilized to make your environment greener by shutting off power over ethernet (PoE) consuming devices on demand or even to reset the port on that one flaky network device that you’re forced to keep on the network for some reason above your paygrade.    

While Meraki’s anticipated applications are great, they also provide two mechanisms that, with an appropriately configured backend system, can widen the possibilities of what can be done with a button.

Meraki allows webhook configuration right in the rule creation wizard, making it very easy to send data to a receiver that can further drive intent-based actions. Meraki’s webhook receiver configuration in the “network-wide alerts” section provides options for a server name, URL, shared secret (for increased security) as well as a payload template with several “canned” versions for services such as WebEx, Slack and Microsoft Teams. 

To “catch” the webhook, administrators might use something like ServiceNow in order to integrate into existing automation workflows. Alternatively, a very simple receiver can be custom written in a language like Python leveraging the flask library, which allows the administrator to build any integration or workflow they could conceptualize. While the simple reception of the webhook might be enough to trigger an automation flow, additional context (such as the button press type or the message, both shown in the image below), can be leveraged for more precise or nuanced actions.

MQTT is a lightweight, publish-subscribe, machine-to-machine network protocol that uses a server called a broker to receive and route messaging accordingly. Depending on the environment, MQTT may hold a significant advantage over webhooks, because all messaging can be passed on a local network without the need to expose anything to the internet, as in the case with a webhook.  Additionally multiple Meraki products, such as the MR access point and MV camera, support telemetry output via MQTT, much like the MT sensors.

MQTT works with the concept of topics which allows clients to share information. Details on the MQTT protocol are a bit beyond the scope of this post, so I suggest reading the Eclipse Foundation man page to learn more. The image below shows an example of the MQTT topic that would provide all information about the MT30 sensor with a MAC of D6:DD:A3:CE:D9:C0 belonging to the Meraki network L_523D93959031703598. A client subscribed to this topic would also receive any information for items lower in the hierarchy, giving lots of flexibility to consume as little or as much data as desired.

Much like webhooks, performing automation workflows requires a tool to be setup to consume MQTT messaging and take action once the desired conditions occur. Again, complete customization could be accomplished in Python using the paho-mqtt library but other solutions exist in products such as Node-Red, StackStorm and even the popular home automation platform Home Assistant.

MQTT payloads differ slightly from those seen with webhooks, but as you can see in the example below, topics contain information such as RSSI strength from heard BLE gateways, the button press type and duration, battery percentage, USB power state and other items. Again, this context gives a large amount of flexibility to build simple or complex automation workflows without ever needing to punch a hole in the firewall and expose a server.

For those already invested in the Meraki ecosystem, the new MT30 is a compelling way to bridge physical world triggers into automation workflows. The available automation tasks and customization options via webhooks or MQTT give administrators a nearly endless set of use cases for a smart button.  Why not add a camera and notification-based security solution, a cost savings mechanism to turn off specific PoE devices before leaving for the day, a way to launch a cascade of startup or shutdown events like starting up a product demo, or even just a button to unplug the break room toaster?

Story by Colin Vallance, a principal technical architect for CDW with a focus on automation/programmability. In his role, Colin is responsible for the development of solutions and services to meet the ever-changing needs of customers as well as driving best practices and adoption of automation and programmability internally. Colin has been at CDW for more than a decade, first as a delivery engineer and then as a technical lead, before becoming a technical architect. He holds a CCIE Wireless, various certifications from Cisco, Aruba and Meraki as well as U.S. patent 10,789,846.