New Maker API modes and HSM (THANK YOU!)

THANK YOU HE GUYS!

Two of my biggest requests have been answered! You guys are AWESOME!

3 Likes

I agree!!! these help out a lot and I've already began integration of them!

1 Like

Can I ask for a change?

Modes come across the eventsocket as such:

[2019-04-29 23:48:49] {"source":"LOCATION","name":"mode","displayName":"Home","value":"Night","unit":null,"deviceId":null,"hubId":null,"locationId":1,"installedAppId":null,"descriptionText":"Home is now in Night mode"}

There is no deviceId or any other Identifier provided like there is in the output from Maker API which provides an id

{
"active": false,
"id": 3,
"name": "Night"
}

Can this be updated for the Mode Id to be presented in the eventsocket as the deviceId or another identifier?

I can make the request, but eventsocket is not an officially supported external interface and could change at any time.

I'm aware. I've been having plenty of discussions about it with @chuck.schwer. And the use of eventsocket has spiked your hub sales :slight_smile: So I'm hoping you leave it alone.

Yet you want us to change it, potentially breaking other usage of it. :slight_smile:

Mode's follow LOCATION events, with a specific "name" of "mode" and with a "value" that should match up with the same "name" in Maker API.

Adding a deviceId doesn't really make sense here to match the mode id and could cause overlapping with actual devices that have those ids.

So upon further review, this really shouldn't be done in the deviceid. Will look into other places it might fit.

1 Like

I didn't specifically as for you to use 'deviceId'.

Where's the ID? Those are the only output fields that match to anything in Maker API but the ID is missing. I really don't care what the field is named as long as it's identifiable back to the actual Mode setting. I think others who are integrating would like this as well.

Match it off the name. Unless I'm missing something... It's not like users are going to have 2 modes both called Night.

IF the ID was included in the eventsource then it would make it very easy to then make the HTTP call back to Maker API to change the mode. However with it not being in the eventsource I then had to pull the Maker API output store that then from the eventsource output then match the name. Yeah it works and I have the work around in place but it would just be simpler if the ID was included in the eventsource.....

Hold on, I am trying to understand your example.

You grab the location event off the event socket, meaning the hub activated that particular mode and now you want to take the ID to call MakerApi to activate that mode again? Why? It is already already active.

Or what am I missing?

This is for integration....

Got it! I had to use the name for my Homebridge plugin and store the ID somewhere hidden to set it later, so I hear your reasoning. The example just didn’t make too much sense without seeing the picture. At least to me...

1 Like

Perfectly understandable... I don't make sense to myself half the time :slight_smile:

1 Like

Hey @patrick, did you notice that I wasn't the one requesting changes to the websockets this time? :wink: LOL

2 Likes

Old thread but since it comes back near the top of my google search for "Hubitat set mode" I figured I'd ask here.

Can someone document the mode and HSM REST API? I'm implementing both in my Android app and have to rely on a few different posts to know how to call these.

For example, I'm looking at this thread to implement HSM: How to set the HSM mode using Maker-API

I didn't even know these API's existed until I found this post: MakerApi - Get and Set Modes

I can figure it out by trial and error but it would be nice to have these and anything else added documented in some central location.

It only takes ~5 minutes to figure out, I did it for another integration recently...

But you are correct, it would be better if it were documented in the Maker API documentation.

Thanks for the link to that API. It doesn't really explain how this works for the MakerAPI though IMO.

What really helped was this which I don't think I would have figured out on my own:

Try disarm, armAway, armHome or armNight. armedAway is the status, armAway is the command

I also just noticed a possible bug or at least something worth mentioning to anyone else trying to set HSM values.

The MakerAPI responds with what I would assume should be the 'current' HSM value but it's actually the previous value. Here's what I mean:

GET http://192.168.0.202/apps/api/38/hsm/armHome
DATA:{"hsm":"disarmed"}
  • Notice how the API returned disarmed even though I just set it to armHome?

The weird thing is I get a push notification before the API response which notifies the app that the HSM value was actually updated.

handleDevicePushUpdate: {"deviceId":"ID_HSM","displayName":"Home","locationId":"1","name":"hsmSetArm","source":"LOCATION","value":"armHome"}

Unfortunately, because it's returned before the API response I end up changing the HSM value back to the original value.

I'll end up just ignoring the response to changing the HSM value - but it seems like a bug to me

Ok, I figured it out. I hadn't defined the "Intrusion-Home" HSM setting so when trying to put HSM into that mode - it must have sent out the push alert saying it worked and then rejected it and the response shows the current mode.

A little odd with the push update going out but ultimately just something to note.. you can't change to a mode you haven't configured yet. No way to know that from the app-side of things but not the end of the world either.

image

1 Like