This page last changed on Jan 25, 2015 by aktur.

My controller is running on the edge, which results that it needs sometimes a few seconds to propagate it through the event chain. I would like to be able to prioritise threads and give some sensors (like buttons for my AV from a handheld remote) more priority than for example temperature sensors. The idea is to get better response from interactive human controls as few seconds for execution is at least bit annoying.
Is there any work done in this direction? If not, is this at all possible within the Openremote controller architecture? If yes, can somebody outline how it can be achieved?

I find that a first step would be to review protocol implementations and make sure that they behave nicely and to some common standards. One standard would be that a protocol should not start any thread, or create and connection or generally make no 'noise' unless it have been configured. Another once would be to try to reduce the use of polling techniques. If a temperature sensor make an update at an adequate frequency, anything more the than once a minute is probably already excessive, should not make a difference to system performance.

Posted by toesterdahl at Jan 26, 2015 06:44

enerally make no 'noise' unless it have been configured.

I would go even further here and say that it should be invisible unless it is used in current configuration. I frequently get messages from protocols which I don't use and never will be used. Waste of resources if you ask me. The example is:

2015-01-26 11:24:31,113 ERROR [pool-1-thread-1]: IOException while reading data from ISY-99
org.apache.http.conn.HttpHostConnectException: Connection to refused
        at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(

I don't have ISY-99 device nor is a valid address on my LAN.

anything more the than once a minute is probably already excessive

But still it is cool, for example I have real time readings of power, voltage, current and cosfi from my Smappee device every second. It makes impression when you see it, it shows that energy consumption lives quite actively. So I would still like to pool it every second, however, when a UI request comes I would like it give a higher priority and don't mind to hick the pooling thread for few seconds.

Posted by aktur at Jan 26, 2015 10:37

My OpenRemote<>RaZberry system performance has been drastically improved after I abandoned sensor polling by sending status changes with UDP instead. Even while I have to do a system call to netcat at the RaZberry side JavaScript, and parse the UDPListener messages with a rule at the OpenRemote side. Those messages are only sent by RaZberry if the value has changed!

If UDPListener had an option to directly deal with {sensorname,value} pairs, quite a bit could be gained I think.

I am aware that I can craft my own messages at RaZberry, which won't be the case in most situations. Maybe $mappee developers can be lured into producing something similar

Posted by pz1 at Jan 26, 2015 11:13
Document generated by Confluence on Jun 05, 2016 09:31