MakerAPI Relative Commands

JasonJoel · June 17, 2021, 7:06pm

As an absolute statement? VERY often. To me the better question might be how often does it need to be wrong to matter. The answer is almost never "never".

There are few (I would argue NONE, but am trying to not speak in absolutes) home automation scenarios when the difference between 99.9% and 100.0% materially matters.

The underlying hub, network, communication, power, etc aren't even as reliable as that.

But I need to quit arguing subjective items, there really is no point. Y'all do your stuff how ya want. For me, building the cache in the integration on start, then updating the local cache with the POST events works very, very well.

dcaton1220 · June 17, 2021, 7:42pm

We'll have to agree to disagree but IMO, correctness always matters. If you wrote code under my watch, you would have to make a convincing argument that the cost of making sure the data was 100% correct was not feasible. And in some cases, it isn't but we start by trying to make it so, and only allow exceptions when absolutely necessary.

What if you fall down the stairs because the bulb doesn't go on that 1 time out of 1000? Or your heat tape doesn't go on when your cached data said the temp was 40 when it was really 30? And your water shutoff failed because your cached data said it was already closed .

That 0.01% could really suck, even if it's statistically unlikely. There's always Murphy's Law to contend with.

Agreed, which is why I won't trust it with anything that really matters far as life safety and property protection go.

I understand the point you're trying to make though.

JasonJoel · June 17, 2021, 7:45pm

You can play the what if game all day.

I guess if you are that conservative you better have redundant hubs too - right? Oh wait, you can't make hubitat redundant.

You must also have redundant bulbs in case one burns out too - right? And redundant switches? And redundant power feeds to your house?

I work in life and death industrial environments. I know what fail safe looks like, and how to evaluate risk. Nothing my Hubitat does is risky. And the data inside of Hubitat, or outside, will EVER be 100% correct.

So pick how "correct" is good enough for yourself.

I do agree that where is is "reasonable" to put in the effort to make data correctness more reliable, people usually do. Everyone will decide what "reasonable" means for themself.

bravenel · June 18, 2021, 3:24pm

This is easily done with an RM rule. Create a rule with Local Endpoint as trigger. The action adjusts the dimmer. It is also possible to pass a value into the rule through the URL, and then use logic to decide what to (e.g. how much to adjust by, which dimmer, etc). Note that you can't pass a device-id into a rule; the devices have to be pre-selected within the rule.

This is not a Maker API function. Maker API is an interface only: It exposes device commands. But, since there is no adjustDimmer command to expose, Maker isn't the right tool for this. But, Maker isn't the only way to hit an endpoint. If you need an agent to apply logic and calculation, then RM is the tool for that.

giudicistefan · June 18, 2021, 8:47pm

Can this be set up such that the device and the amount are passed by the http request and processed by one rule? If one rule could parse the device Id and amount to change and handle it, that would be a swell solution. If I need a separate rule per each dimmer, we're back to inefficient workarounds.

bravenel · June 18, 2021, 8:54pm

More or less. RM still needs to have each of the dimmers that might be changed selected in actions. It is possible for a parameter in the GET string for the endpoint to carry something that indicates which dimmer, and the amount to adjust by. Logic in the rule would then take that parameter apart into its two components, and act accordingly. How many dimmers total are you talking about? The one thing that RM can't do that Maker API does (at least as of now) is the device lookup from the deviceId. You can still use the deviceId, but a cascade of IF-THEN... would figure out which dimmer to apply it to (interesting possible feature enhancement to do the reverse lookup).

I haven't looked at this in quite some time. If you give me about half an hour, I'll create an example for you that shows how to do it for multiple dimmers.

bravenel · June 18, 2021, 9:23pm

Here is how this works:

First of all, we need to create an encoded string for the GET url parameter for the device and amount to adjust. This is an arbitrary encoding, and I just use "device:adjust", i.e, colon separation. The rule is going to get that string in %value% when the endpoint is hit, and it takes 3 steps: pull out 'device', pull out 'adjust', change adjust into an integer for a subsequent Adjust Dimmer action.

Here is what the GET against the endpoint looks like (this string can be found when the end point trigger is created, and then edited to add the parameter between the word trigger and ?):

http://192.168.0.45/apps/api/22259/trigger/myDev:12?access_token=8exxx..

So this string myDev:12 is the parameter that will be in %value%. myDev could just be the deviceId of the intended device, and 12 is the desired adjustment value.

Now, here's the base rule:

What would need to be done is to replace my single Adjust Dimmer action with a sequence of IF-THEN testing the value of the dev local variable, that holds the deviceId. Like this:

IF(dev = Dimmer1) THEN
   Adjust Dimmer1 by %adj%
ELSE-IF(dev = Dimmer2) THEN
   Adjust Dimmer2 by %adj%
...
END-IF

That's the basic scheme, and should work for your use case. Details left to you... Such as if using deviceId, then you'd need each IF or ELSE-IF to test for the correct deviceId of the corresponding dimmer to adjust.

Alternatively to the cascading IF-THEN-ELSE-IF approach, since there is only a single condition to test and a single action to run, you could use Simple Conditional Action instead, like this:

IF(dev = Dimmer1) Adjust Dimmer1 by %adj%
IF(dev = Dimmer2) Adjust Dimmer2 by %adj%
...

I tested this and it works as expected.