Basic question on processing an HTTP POST with multiple Items

As I am thinking through how to build my various python rules I have cases where multiple Items need to be updated before an event can then act on those Item changes. In the past I have had an args array with multiple key:value pairs received and processed. With the REST API I can make REST HTTP Requests to modify single items which means I would need multiple REST Requests followed by the final Action that would trigger the Item Event.

So, the basic question is: Is there a better way to do this? I am thinking about this correctly in the OpenHab world? Perhaps there is a JSON Item I could create and then use a single REST access to update it?

Sorry for the basic question but perhaps others have had the same thought.

I think you’re stuck with one-at-a-time for update or command, that’s how it works internally too.

1 Like

Ok, that’s not big a deal, just wanted to make sure I wasn’t missing something.

You could indeed use that sort of approach. But you’d then need to write a rule to parse that JSON and then ??? If you need to retain these values in separate Items then you’re right back at the starting point needing to update each Item in sequence. However, if you just need those values in that one rule, you could just parse the JSON out into local variables and do what ever it is you need to there.

Be careful with timing though. Item updates occur in parallel. It’s entirely possible to update the Items and post the command to trigger the rule before the Items have finished being updated.

If these are external Python scripts you control, you might want to look into MQTT as an alternative to REST API calls on OH. MQTT is generally lighter weight and it will make your Python scripts be a little more hub independent. MQTT is kind of the lingua franca of DIY home automation.

1 Like

Thanks Rich … yes obviously I need to learn more about MQTT, it’s on my list! :slight_smile:

This is related to my IFTTT use case, and its a little surprising I can’t do a similar thing, such as: receive a standard query string:

Perhaps I am answering my own question, since of course that could go into a String and then be parsed accordingly, but wouldn’t that be handy to be built into OpenHab?

But then what? The individual Items will still be updated individually one after the other. You really haven’t done much of anything here. If OH supported that then your REST API call is slightly simpler but you’ve still not solved your original problem where the Items do not update all at once. No matter how the commands/updates come in, it’s not possible to update a series of Items as a transaction. The architecture is simply not there to support that.

One of the dangers of any framework like OH is that the more you add “wouldn’t that be handy” stuff to an API that already supports doing the same thing in another way is you end up with too many ways to do something and just figuring out which API call to use becomes a problem unto itself. And pushing stuff to OH over the REST API is not a typical use case. Almost all of the time it’s OH that is pull the data or there is a more direct connection to the devices.

Agreed, and I’m happy to do things in another way. The question stems from my current reliance on IFTTT which is not set up to allow a series of REST API calls to update all the information, hence they use a single HTTP query.

I have no requirement to update all the items in a single transaction, I was simply saying that getting all that info in a single transaction would be easier (and is required in the IFTTT case) … obviously I need to move away from thinking about things in the IFTTT context since that isn’t going to work.

Clearly I can easily make a series of REST calls to update several Items and then follow it with an “Apply Changes” event of sorts.

My guess is that I am not doing anything so elaborate that OpenHab hasn’t found a way to do it, it’s just different and I’ll need to learn and understand how to do it the OpenHab way.

Honestly, the massive latency IFTTT introduces coupled with their decision last year to cripple the service for anyone not on a paid plan has relegated IFTTT to niche support in OH at best. It never really was all that popular and it caused all sorts of problems. So I would personally be hesitant to make changes to OH core (which this would require) that only supports IFTTT. A much more compelling use case that OH doesn’t “officially” support is the ability to update or command an Item using an HTTP GET as lots of older devices that do support webhooks only support GET, and even that has met with some resistance from the devs (and me too).

If IFTTT won’t support making multiple calls, then make a single call and package up all your updates into a String. JSON would be best. Then a relative simple rule on the OH side can parse the JSON and update the Items as appropriate. If your JSON is of the format

{ "Item1": "value1", "Item2": "value2" }

You could write a completely generic rule to handle such updates for any Items. As long as the key in the JSON matches an existing Item name.

One approach is to trigger the rule based on changes to all the relevant Items. But set a short timer in that rule, maybe half a second or a second. When the rule triggers, reschedule the timer. When all the Items are done updating the timer will eventually expire and do your calculation there.

1 Like

Agreed and thanks for the other suggestions as well … Yes IFTTT became slower and slower and it’s good that it isn’t supported so I have to rethink things … just a little hassle but I’m sure it will be worth it.

Someone developed a fancy approach to “wait for a set of Items to update”, as you point out even when all the values arrive via some binding in single JSON or Modbus etc. message, it’s not possible to guarantee simultaneous updates of multiple derived Items, or even expect update in any given order.

In truth, you rarely need to go to these sort of lengths.


I accept that another adjust way to approach this would be to make another asset that speaks to your collection of assets. Case, envision that we have an endpoint like /api/sheep/{id} and able to POST to /api/sheep to form a sheep asset.