Yes You Can Create WISER Alerts Using Microsoft’s Power Automate

All users of WISER Tracking systems are, fundamentally, generating a stream of real-time location data of where tracked objects are and when. How that data is used, however, may be different depending on the particular use case. That data can be passed to any number of WISER’s apps, third-party software, and in-house integrations. In this article, I will show one small example: how to use Microsoft’s Power Automate to send email notifications if the server goes offline. This is easy to modify, for example, to perform some action when a tag enters a geofenced zone, stays in a zone for too long, or any number of other properties change.

Data generated by the WISER Server can be handed off to other software either by writing to a shared database or by interacting with the Server’s APIs. (Application programming interfaces or APIs are any kind of formalized connection between computer software.) This article will focus on using an API, but it is possible to do all the same tasks by interacting with a shared database.

You can try the API right now. The following command will reach out to our office’s cloud-hosted tracking mesh and query its status. If the server is online, it will return its status as a JSON message. (JSON is a way to structure information as named values.) Open Windows Powershell or Windows Terminal and copy and paste in the following:

Invoke-RestMethod -Method Get -Uri "http://trackmystuff.net:3101/wiser/api/arena/status"

Or on Linux or Windows Command Prompt later than Windows 10, type the following:

curl.exe -X GET "http://trackmystuff.net:3101/wiser/api/arena/status"
Windows Powershell
Linux bash or Windows Command Prompt on later than Windows 10

But this interface is for robots, and we are not robots. We will want some kind of automation to read this information and present it to us humans. There are many automation tools that can be used “serverless” and “stateless”. Stateless means the script runs quickly and does not use any resources between runs. Serverless means it can be run in the cloud without managing servers. The cloud service spins up processing power only as needed. These take care of server management and can easily scale as needed while keeping costs lower than maintaining a dedicated server all the time.

The heavyweight examples are AWS Lambda and Azure Functions. For fastest response for web apps there’s Cloudflare Workers and Deno Deploy. And then there are several that provide a “low-code” interface like Zapier, Microsoft Power Automate, and IFTTT. There are also some local open-source alternatives like n8n (a low-code environment like Power Automate) and Node-RED. Many companies already have a Microsoft subscription and run Power BI, so Power Automate is a natural choice.

A Microsoft Power Automate “Flow” is essentially a script written primarily with a Visual Programming Language that runs serverless and stateless. (Flows can also be run in Desktop mode on a dedicated PC. You can technically leave Flows running for days, but that’s not the intended purpose.) Power Automate is a “low-code” interface. It is not “no-code” because some equations may still be necessary; think Excel’s formulas. LabView is a similar concept used in industry. I find visual programming languages become more difficult than traditional programming languages for all but the simplest tasks. But for simple tasks, they are fast and can help limit coding mistakes.

If you went to primary school after the push to teach programming languages but before Python was cool, you may have learned Scratch, here controlling LEGO Mindstorms.

Most “stateless” scripts are composed primarily of two parts, a trigger, and one or more actions. Most also have a little bit of data processing between the two. The trigger might be given manually by a user or be event-driven by the WISER server, some other software, or just a timer. The action may be, for example, to send an email, edit tag properties, or generate an Excel sheet of tags meeting some criteria.

I want to send an email and Teams message if our office tracking mesh goes down. The trigger is a 5 minute timer; it will run every 5 minutes. The first action will be to check the status of the server, and parse the JSON it returns. The second action will be to send an email if that status is bad. That looks like this.

The condition checks both the tracking key in the body of the JSON, and also that the API returns HTTP status “200” for success. If the server is offline, the API would fail and return “404.”

But this would be annoying, as it will blindly run and send another email every time it runs! We need some way to save the state of the system to reference next time the flow runs. We can save the state to a file or database. In this case, I will use Microsoft Lists, which is a more modern version of a Microsoft Access database, that is shared in a Sharepoint. Each time the script runs, it will first check if the returned status is different than the previous status.

I first create a Microsoft List called ServiceMonitor. It may hold any number of different pieces of information. I create an Item unhelpfully called Arena, which is the trackmystuff.net arena status, and add a column called “Status” that we will read and write from the flow.

The flow will start to get complex, so I initialize and create several variables to track what is going on. These are not strictly necessary, but it help keeps the flow easy to read. I read the last state from the ServiceMonitor List, and also store its ID to a variable, so that we can re-write it later.

Next, I check the state of the arena. Here is where the “low code” starts to fight back. The API request will fail if the server is offline, which causes the block to fail, and would interrupt the flow. I do not know a simple way to handle this. I create a Scope I call “Try” that may fail, and another Scope called “Catch” that will run if Try fails and set the CurrentState variable to “offline”. Then the following block needs to run if “Catch” was either successful or skipped.

These little green, red, and gray dots are doing a lot of heavy lifting.

I then have a similar conditional block similar to before where I now compare the CurrentState and LastState variables. If they are different, I perform actions such as send email and send Teams chats.

Importantly, it now has one more task: to write back the current state to our List.

So, now we have what we want. If we run the Flow, Power Automate will email and Teams chat only when the status of the server changes. I can make similar Flows to alert when a tag enters a zone or has a low battery.  It’s important to set up alerts like this for specific events like zone entry. This is because the passivetag endpoint will return all of the data for all of the tags, which is too much data. For only a single tag, that response looks like:

{
        "id": 30011,
        "report": {
            "alternateid": "JN 45667",
            "arenaid": 2,
            "battery": 2.9167624,
            "error": 0.09999999999999998,
            "id": 2187130,
            "location": {
                "x": 1149.9934356407084,
                "y": 561.9498451338927,
                "z": 12
            },
            "numAnchors": 5,
            "tag": 30011,
            "timestamp": 1758724049417,
            "zones": [
                {
                    "id": 2
                }
            ]
        }
    },

We can instead reach out to the endpoint, but limit the fields to only the ones we care about, and filter to only the ones that meet some criteria. So to get all the tags in zone ID #2, we query

Invoke-RestMethod -Method Get -Uri"http://trackmystuff.net:3101/wiser/api/passivetag?fields=id,report:zones&zone=2"
"id": 30011,
        "report": {
            "zones": [
                {
                    "id": 2
                }
            ]
        }

Or to get all the low batteries, we query,

Invoke-RestMethod -Method Get -Uri"http://trackmystuff.net:3101/wiser/api/passivetag?fields=id,report:battery&report:battery_below=2.8"

Likewise, our Flow action can make a POST query to make changes, for example, to delete a tag’s name and associated work order number. Our WISER REST API reference documentation lists all of the endpoints available.

Hopefully this gets you started on how you can use a tool like Microsoft Power Suite to set up alerts and better use location type data. There are so many other ways to do this too. I also made a step-by-step video tutorial on how to the set up the “mesh down” alert. And if you’re interested in learning more about WISER systems and how to leverage its data please don’t hesitate to reach out or fill out a form.


If you are interested in talking with someone from WISER about how we can help at your facility, please feel free to reach out. You can contact us via our website, email, or phone.


Watch it on Youtube