Using Highbyte for the Tulip Machines API the "fancy" way

Show and Tell
1

The current tutorial on how to use HB to push machine data into Tulip is functional but simplistic[1]. It basically forces you to push a single attribute per message. It’s not explicitly documented but implied in the Tulip API docs[2], but Tulip can accept an array of machine attributes:

{
  "attributes": [
    {
      "machineId": "string",
      "attributeId": "string",
      "value": "same data type as the respective attribute"
    }
  ]
}

I cheated and created a top level model with one attribute/instance called attributes referencing a single child model/instance with a static template of the machineId, attributeId, and value reference for the 3 values I’m interested in. This let me massage a HB model instance into exactly the format Tulip requires.

Parent model:

image
image1610×600 25.8 KB

Child attributes model:

image
image1608×738 36.9 KB

My initial use case was mainly as a thought experiement to pull in my local weather data from OpenWeatherMap and publish it to a machine.

Why a machine you ask?

  1. Because it’s cool to say I have a Tulip Weather Machine and can include the current weather in apps.
  2. Because I prefer an event based architecture, the alternative would be either a connector function that runs on each app needlessly hitting the OpenWeatherMap API, probably more than the terms of use allow. OR writing the data to a table and using table aggregations. I’m still thinking that weather history could be useful in the future for AI/ML…

The magic of how this works is you need to create an instance of an instance. Unfortuantely template instance variables do not get passed to child instances currently, but in this case we want the child instance to “replicate” based on the number of attributes we’re pushing into Tulip anyhow so it doesn’t matter.

The parent instance just contains a reference to the child instance (no templating required):

image
image1104×169 7.57 KB

In the child instance we use templating to create an instance for every attributeId and value we want to include in the model.

image
image1553×882 45.8 KB

NOTE: If you’re used to the Tulip Machine API the machineId and attributeId parts should look familiar. The last part of the template is just the JSON reference to the values of interest in the full payload you get from OpenWeatherMap.

I’m currently pulling in temperature, relative humidity, and weather description using a static template but could easily change it over to a dynamic template if I stashed the instance parameters somewhere accessible.

{
    "attributes": [
        {
            "machineId": "CW58YLCJFcW7aeD3d",
            "attributeId": "YzCDuD8GjWWip9WT7",
            "value": 68.85
        },
        {
            "machineId": "CW58YLCJFcW7aeD3d",
            "attributeId": "9anmM2EvjMFa22dWo",
            "value": 47
        },
        {
            "machineId": "CW58YLCJFcW7aeD3d",
            "attributeId": "Y7M3Kfro9CRCTbze9",
            "value": "scattered clouds"
        }
    ]
}

Then I just tie this to a Tulip Output in Highbyte and put the flow together and now all the attributes go in one push. This would allow me to easily scale to any number of attributes. As far as I can tell I should be able to push data for multiple machines if I want.

[1] How-To Send Data to the Tulip Machine API | User Guide | HighByte Account Portal
[2] Tulip API Docs | Tulip

8 Likes
2

This is awesome Richard! Thanks for sharing how you are expanding on the Tulip <> HighByte connection.

@HighByte_Support figured you might want to see this :eyes: