It would be great if MakerAPI could handle relative commands, not just absolute commands. E.g. [Device ID]/setLevel/+10
Makerapi is amazing because it opens up so many use cases, some of which might be fairly rudimentary devices that don't play nice with touch screen sliders. I use sliders on my phone via a tasker scene for all my dimmers and it's super fast and easy, but I'm making a control page on my smart watch (fueled by maker api, obv.) where you can select the dimmer by name but then need to use up and down arrows to increment the llevel by 10. It would be great if the url it calls could just say add ten. I could use maker api to pull the status of the relevant device, then use JSON to process it, create a variable for current level of each device, tasks that set each one before sending the command, etc., but that's a ton of extra work to avoid a few extraneous clicks of starting from an assumed 0 every time and just hitting up 7 times to get to 70 regardless of where the lamp started. Shouldn't be too hard to implement relative changes in the api!
That would be interesting - but it would have to be a NEW/DIFFERENT endpoint.
The endpoints are already documented as of type and use, and changing them could break many existing integrations. Sticking a string into an attribute or command of type NUMBER is bad form in my opinion. Hubitat has been GREAT in not breaking existing integrations, so I expect that would continue into this topic.
But, new endpoints could always be made, if they wanted to - of course, to support new functionality.
Hmm...I think it would be pretty straightforward to implement without impacting anything existing tbh. Does secondary value currently even accept negative numbers? If so you can't use + and - as secondary values because lower by 10 would be the same as set to negative 10; if not regular +/- would be fine. If so, you could keep setLevel the same and make a new changeLevel. This could be just limited to makerapi with the makerapi app itself doing the labor of pulling the current value, mathing it accordingly, and sending a setLevel command to do the job, or it could be implemented in the broader hubitat scheme/device drivers as setLevel is. To just do it as a makerapi change that converts it to setLevel before sending the command would honestly be pretty straightforward and not hard to avoid stepping on current functionality at all. Hell, it's basically the same thing I'd be doing with a simple tasker task and json on my own, grabbing the current value, modifying it on my own and sending it back as a setLevel
Says the guy that doesn't know what the internal code looks like.... That said I have no idea, either.
Obviously I'm not against adding features as long as they don't change/break existing use cases. I'm, in general, against modifying existing proven code paths to add new, unrelated features though. Which is why I would rather see it be a new command if done.
But it isn't up for vote, so who cares what my opinion is?
Since you are using an automation tool already, you could interrogate the value using MakerAPI, then add 10 to it, and then ping the updated value back to the device using another MakerAPI call. It's easy. Ok, it takes two calls and you have to do the math. But it ain't exactly hard to do. I'm doing this kind of manipulation and more in a custom dashboard using Javascript and MakerAPI and this approach allows you to do whatever manipulation needed.
Sure, if Bruce added an incremental GET command that does it for us, that'd be cool. However, I wouldn't hold your breath for that
Maker API has a very clear design principal: it's a conduit between the outside world and devices and events within the hub. I didn't write it, and the person who did isn't around to answer questions about his idea, but it's clear to see in the code that all it is is a conduit.
So there is a rubicon that would be crossed when one introduces the idea that Maker API should be more than a conduit, that it should also take on tasks on behalf of the outside system. It seems to me that this quickly becomes a very slippery slope, and is conceptually unappealing.
I think that is also apparent in its use. Since MakerAPI can update the "outside world" of hub events, it should be up to the outside world to keep track of those events. For instance, keeping track that a current dimmer level is 20, so if a +5 level change is desired, send a setLevel 25 to Hubitat.
I love MakerAPI - so much so that I would have been willing to pay extra for it - but no take backs now.
While I acknowledge that I am weirdo, I have to say that I love the fact it is more/less a "dumb" conduit. I like tools that do what I need with the minimum of bulk/overhead/extras - and Maker API does exactly that.
I can do any manipulation or massaging of data externally.
Yes, I mentioned this in my post, I'm doing it locally in other apps too, processing json to poll data before sending commands. But, with many different devices it's a pretty inefficient way of handling a task that could be handled at the source, universally, far more efficiently. I don't see how changeLevel is any less appropriate than setLevel in the big picture. If secondary values can't currently be negative it'd not even require a new function like setlevel/changelevel. Even g-code/grbl knows the difference between G1 X50 and G1 X+50.
Making every user and every iteration of every integration, in multiple steps, poll the hub, use json, store the current level, process it, and send the new absolute value, for every device, to tell the hub to raise by 10% just seems inefficient given the simple relationship between absolute and relative commands on a 0-100 scale. It'd be straightforward and intuitive to users for the api to take [device]/setLevel/+10 and make it work as expected compared to doubling the number of http requests for every action, and making every user figure out how to process rudimentary relative changes for themselves. It's less efficient in terms of effort and in terms of data exchanges, and the more basic the integration, like this watch panel project, the more complicated it gets; it requires like 6 exchanges between the watch, the phone, makerapi, autotools, tasker and back to raise the light by 10, per device.
Most/many integrations cache the current values for attributes, as they get the updates for 'free' anyway with the POST events (still poll everything once on load/restart though to make the initial cache, but that only takes a few seconds with 100+ devices).
So for most integrations there is zero polling, and a single setLevel command back to the hub with the new level (for each device).
Where to stop? I think it's better to separate the manipulation of the data/parameters from the method of 'getting' and 'putting' it.
You can also set up endpoints to run rules. So you could have a rule to increment whatever you like and then run it from an endpoint. It's not what you want but might be a work around for you if you don't want the parameter manipulation logic outside of HE.
When you make suggestions, do I show up with slippery slope fallacy nonsense to try to shoot it down? There are obvious differences between +10 and *10 in practice. The fact that someone is asking for a simple relative change command does not imply they will later ask for obscure barely applicable ways to manipulate data with the api.
I've made a recommendation. It's a more efficient way of doing a very relevant task, that makes it easier on users and even less demanding on the servers. If it wouldn't save you time, you are free to not use it. I don't need other users shooting down ideas that would save me time, energy, and calls to the api, especially when 30 year old systems were capable of relative commands. This isn't obscure, it's built in to plenty of drivers and apps on hubitat and it could easily be built into makerapi as well, it doesn't suggest people will ask for useless relative commands if we grant them useful relative commands, and again, it cuts the number of calls to the api, it's literally more efficient to set up and to use than the current approach.
'it's literally more efficient to set up and to use than YOUR current approach.'
Fixed it. It is not (appreciably) more efficient for all the integrations that already cache current values.
Again, no issue with your request though (assuming Hubitat could do it without breaking existing code paths). I'm just playing devil's advocate on how applicable/widespread this need is. If Hubitat chooses to implement it, no problem for me!
Anyway, no point in beating this dead horse I guess. The request and all opinions, are out there already.
That really isn't good programming practice. In your example, the dimmer itself is the authority, since it and only it knows its true state at any given point in time. Once you start keeping track of the state of something else, you need to make sure what you think is the current state is in fact the actual current state. Sometimes that's not so easy. If the current state changes and you're not notified, your data is wrong.
Sometimes that's not practical of course, and possibly having an incorrect state is an acceptable tradeoff, but it should be avoided whenever possible. IMO.
I would disagree. It should be avoided whenever it matters, not whenever possible. Doing extra work or engineering for little/no return is not good use of resources.
Now, when it matters is subjective, of course.
For my Hubitat data in node-red, if an event is missed once in 10000 times (it is actually much less than that), and my cached values are out of sync.... whoopie.
But how often does the correctness of data not matter? I wouldn't consider the work necessary to make something as robust as possible to be "extra" work, it would just be part of the overall work necessary to do the job. Of course, there's always exceptions.
Maybe it's overkill but I write code for my own personal purposes no differently than I would write an application by the general public.
That said I have no idea, either.
