This page last changed on May 01, 2013 by pz1.

It seems that OpenRemote is spending a lot of the system resources on polling. The HTTP protocol by its nature typically has very short polling intervals in order to improve responsiveness of the controlled devices. I have seen polling examples of one or two seconds or even less. For light switches which mostly are operated only in terms of hours, this is quite wasteful. Indeed if switched on via a panel a response in the order of a second is highly desirable. But if the switch is manually operated or falls off automatically, at least for me a feedback after half a minute or so is quite acceptable.

I am presently experimenting with Z-Wave switches operated via Razberry using the HTTP protocol. The switch on/off commands do return a null value. As I can control the Razberry side of the command I can return the actual status value. Unfortunately the HTTP call is unware of device it is controlling, so it can not pass this value on (afaik).

From my perspective of a user of the protocol it would be nice if the HTTP protocol had an attribute where I could select a sensor which would be immediately updated with the returned value of the on/off or any other command.

Does this line of thinking make sense as a generic solution?

(Sorry, I am not a programmer so I can't do a test implementation within the OR framework)
Pieter

It makes sense and was mentioned somewhere else before.
Use the return value of an action command to update the sensor without having the need for an extra status command.
I will create a Jira issue for it, so we don't forget about it http://jira.openremote.org/browse/ORCJAVA-337
This does not mean that it will be worked on soon

Posted by mredeker at May 02, 2013 20:30

Great, I hope someone finds the time to implement this, so more precious computer resource can be spent on real smartness.

Posted by pz1 at May 02, 2013 20:49

Following the ORCJAVA-337 suggestion it may occur that a sensor is being updated from multiple http calls.
At least that is how I read it. If the sensor update remains restricted to only one command, it would not really help solve my problem. That is updating a sensor directly from a http command, as well as using a separate http call for updating its status in a polling loop.

So maybe a better, more generic approach seems to allow the selection of multiple commands to update a single sensor.

Or rephrased in terms of using Designer, the idea is:

1) Make a command that polls the status of a device every so many minutes.
2) Make the command that switches a device on/off also return the the status value of that device.
3) Make a sensor where you can select both commands 1) and 2).

Would also be easier to maintain as well.
Thoughts?

edit1: I am aware that a sensor based on http requires it to have a polling interval set. (Some other protocols don't) For an on/off switch command, polling seems a not so good idea

Posted by pz1 at Jun 04, 2013 13:35

I think the combination of possibilities with lower level transport protocols which are not dedicated to automation (HTTP, TCP, UDP, etc) are, if not endless, at least sufficiently high in numbers that continuing adding various scenarios to the implementations themselves is not useful. Providing generic means to combine requests in other ways (ad-hoc automation protocols if you will) would be the generic solution I'd go for here.

Posted by juha at Jun 19, 2013 00:45

Does this mean that you also oppose to the idea to add the option to update a sensor directly from http etc. commands, in the spirit as it is now available for the shell execution command?

Posted by pz1 at Jun 19, 2013 09:37

I'm not opposing anything, just saying it might be worth to spend the effort on a different kind of solution.

Posted by juha at Jun 19, 2013 10:10

From discussions with Marcus I got the impression that the shell execution command was a first example of how you guys intended to continue with the other 'standard' commands. I was not aware of the distinction in the OR concept of protocols dedicated to automation, and protocols not dedicated to automation.
I agree with you that a wild proliferation of functions on these protocols should be avoided, on the other hand commands and sensors bound to each other in the OR model. For a binary switch, the existence of a binary status is a necessary criterion. So the 'opportunistic' update of a sensor from these commands imho is not that way out.

That being said I am curious about more detail on how you see me combine requests in other ways. If that means that for example in the RaZberry application I have to continue to rely on polling, the RaZ-OR would scale badly.
So please enligthen me.
Pieter

Posted by pz1 at Jun 19, 2013 11:00

As far as I am concerned there is no longer a need to pursue ORCJAVA-337 for the integration with RaZberry.
It is in essence part of a polling approach, which from a performance point of view is not desirable. In the extreme, a switch that is used only a few times per year still needs 1 second polling intervals for acceptable UI feedback.
A better approach would be if RaZberry, on an event at that side, could push (sensorname,value) pairs to a listener at the OR side.

Posted by pz1 at Oct 24, 2014 20:24

Having this would make it possible to create dynamic URL calls, for example for sites where from= and to= are needed. Like in Smappee Get Consumption API call https://smappee.atlassian.net/wiki/display/DEVAPI/Get+Consumption
I've made it possible through rules+shell+curl, but it is quite complicated and certainly for advanced users only.

Posted by aktur at Oct 26, 2014 11:38

Good to see there is a need for it. I only meant to say it is not critical for me anymore.

What I badly need is the option to let my RaZberry directly update the value of any sensor by basically sending a {sensorName,value} pair. With that I do hope to avoid excessive polling.

Posted by pz1 at Oct 26, 2014 12:49
Document generated by Confluence on Jun 05, 2016 09:32