"Dummies" questions on how to get started with Maker API

[rocketwiz]

So now I've got CSS mostly in tow time to have a look at Maker API. I have a few noob questions on how to get started with maker api:

1. How would I manually inject data into HE via Maker API for experimenting? With the eventual intention of getting data in from other sources.
2. How can I then access this data within HE. As an example using my fav virtual omni sensor can I access this data via one of the attributes (both numbers and text).

The short of it is how do I get data/commands into maker api in a form that can be accessed by the various virtual devices? Unfortunately there is no beginner/dummies guide to help one like myself!

[sburke781]

I'm pretty sure I send the rpi temp back via maker api to a virtual temperature device. I'll dig out the detail later tonight.

[sburke781]

If your keen you can look at the curl command from my post about the rpi temperature

Raspberry Pi Temperature Device

I was interested in keeping an eye on the temperature of my new Raspberry Pi4, so setup a "simple" solution (took me a while to get my head back around some Linux concepts I have used for about 4 or 5 years now). The general steps were: On the HE hub: Setup a virtual temperature device in HE, noting the device Id Install and configure Maker API or use an existing install Add new virtual temperature device in the list of devices in Maker API Copy the example command URL from the Maker API s…

I'll post more details on the HE side later.

[sburke781]

As a start for those looking at the Maker API app, there is the documentation page:

Maker API

My basic understanding is that the three main use cases for Maker API are that it allows external systems to:

• Have notifications pushed from the HE hub for events occurring involving devices nominated in the Maker API App
• Calling the HE hub to retrieve (pull) information about HE devices, and
• Execute commands made available through a device's driver

I'm by no means an expert, and have simplified this immensely in my list above. I'm sure others could elaborate on more nuanced use cases or correct anything I have said so far.

In terms of my use of Maker API, I predominantly use it for exporting temperature, humidity and power readings for my various sensors and smart plugs from HE to Influx DB / Grafana in my raspberry pi for analysis and inclusion in my dashboards in the form of charts. I've posted about this in various threads, happy to provide links / details to anyone who wants more info, but essentially, when a device I care about has an event triggered, such as a temperature change, this information is automatically sent to a URL endpoint of my choosing, available to consume by the application on the other end.

Here's a few screenshots and info on this setup. These screenshots are of the Maker API app already installed on my HE. Most, if not all, of these same settings are part of the screen displayed when installing the Maker API App.

The boring stuff
Probably a good idea to give your app a name representing the purpose for installing it, you can install it more than once, I have a second for use in Tile Master tiles as another exmaple of using Maker API.

Device Selection
What devices do you want to make available to the outside world, both info and control?

External Endpoint
If you want device events sent to an external system, what is the address? In my case this was my Raspberry Pi running (I believe) a Node application consuming these events and storing them in InfluxDB. In a lot of cases this will not need to be populated.

Sample URL's
The App setup screen provides the URL's available to use and some basic instructions on how to use them.

Hope this helps.... Happy to update this post with additional info or corrections if needed.

Just to round off the Raspberry PI temperature use case, take a look at the link in my previous post for the curl command I included in a cron job on my rpi to send the current temperature back via the Maker API app.

Simon

[rocketwiz]

Thanks very much - plenty of things to go over - I did look at the docs (tbh it's quite skimpy and probably assumes a fair bit of knowledge) but progress is always faster when you can dissect and go through actual examples.

PS - I cheated and got my pi temps and other stats via some node red nodes !

[sburke781]

Yeah, I was tempted to send them straight to Influx, but thought both for ease and the option of using them in any HE rules or other automations I would still send them back to the HE hub to only have them send back to the rpi for charting in Grafana. Bit of a round trip but worth it I would say. Much less coding for me...

[sburke781]

I do have a habit of forgetting to original intent of the question...

For my rpi temperature example, the "Raspberry Pi4 Temperature" device shown in my screenshots as one of the devices included in the Maker API setup is a Virtual Temperature Sensor I setup manually through the HE devices screen. From memory that was essentially all I did outside of the Maker API setup, apart from any settings you may want on the device setup such as units of measurement, etc. Then it was all about adding this device to the list in Maker API and sending the temperature from the rpi cron job every minute using CURL.

[sburke781]

I think another thing that may be hard to fathom for some are the possibilities, my uses are relatively mainstream and simple I would suggest, importing / exporting sensor data and control through Tile Master. I believe that others have also used Maker API to integrate with Tasker on their phones, something I would be interested to look at. I would also be interested to hear about other people's uses of Maker API...

[kahn-hubitat]

i want to go in the other direction.. i have wireless tags in our condos in fl to monitor the temp of the wine fridges.. i do get alerts if they fail via url but i would like to actually feed temps into hubitat with a url (i can set whatever urls i like) is it possible to pass the temp into hubitat via maker api to a virtual temp sensor so i can show on my dashboards..

thanks

putting hubs in the rental condos and trying to restrict renters access to them and keeping them running when we are only there for a couple of months a year seems like a pain and overkill.

[sburke781]

Certainly, I do exactly that to feed the temperature of my raspberry pi's, let me dig out the details...

[kahn-hubitat]

another approach would be to try a secondary wireless tag app as i already have one with the condo login to see if i can get the tags into my main dashboard.

[sburke781]

I have a Virtual Temperature Sensor device:

Which I then include in my Maker API install (it's a long Device list, so didn't show this exact device in the screenshot):

You may need to play with some of the settings around local / cloud access, depending on your network setup with the condos.

If you scroll to the bottom of the Maker API App page, you will see the example URLs. If you do have local access, e.g. over a VPN, you can use these to set the Temperature via a HTTP call:

You can copy that string, paste it into the address bar of a browser, replacing [Device ID] with the ID of your virtual temperature sensor device, [Command] with setTemperature, and [Secondary value] with the temperature reading.

[kahn-hubitat]

thanks i was an idiot .. good to know how to do it this way.. i got it working by adding multiple wireless tag apps with different names.. i did have to change machines as when trying to log in for access there is no logout button in the hubitat log in for access page and it was using the same cookie for each one..

[Greenwave]

Is there any way to shorten the local url call? I'm having difficulties entering the long address into another program, it cuts the last 5 digits off. when using "setLevel/55" the last 5 digits of the Access token gets cut. Does the Access token need to be this long, especially for local calls?

I even changed the Hubitat ip address from a 3 figure entry to 1 figure to try to help, but to no avail.
Is it possible to use slimmed down version of the address?

[thebearmay]

Any program that expects a path should be allowing for up to 255 characters (256 if you count the terminating character). MakerAPI path is quite a bit shorter than that.

[Greenwave]

Unfortunately ST have imposed a 100 digit limit on internal web requests, which is highly annoying because it doesn't let me change level with Maker API, I'm 4 digits over!

http://192.168.XX.XX/apps/api/49/devices/64/setLevel/2?access_token=XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXX37cf

[thebearmay]

Could look at something like https://free-url-shortener.rb.gy/ and feed it the piece that is http://192.168.xx.xx/apps/api/49/devices/ which will give you https://rb.gy/hv475o to add the rest of the URL to.

[Greenwave]

@thebearmay

Could look at something like https://free-url-shortener.rb.gy/

Thanks for the idea. I'll give it a go, but would that shortened link work without access to the internet I wonder? Because ST only allows web requests on the local LAN, not outside.

[thebearmay]

Well scrap that idea then... For a local solution you could set up a small web server and run something like one of these 5 of the Best Self-Hosted URL-Shortener Scripts - Make Tech Easier

[bozzman]

If you are only 4 characters away from target, create a short internal host name and replace 192.168.xx.xx with something like 'hub'.