This page last changed on Sep 28, 2011 by dberenguer.

We're trying to add a HTTP RESTful interface to a new Home Automation software called HouseAgent (http://www.houseagent.nl). It's basically a multi-platform automation core with an open interface for adding new plugins and creating events. It's very compact and lightweight and there are some good synergies between this application and OpenRemote IMO.

OK, once the new RESTful interface in place, we'd like to monitor some variables from OpenRemote. We know that http requests can be configured from the on-line designer but what about the http responses? What does OpenRemote expects to be a valid response for let's say a temperature value or a switch button state? Which format should follow these responses?

Thanks in advance for your help

Daniel.

It expects string values with no markup. For switches these are 'on'/'off' – for sliders (e.g. temperature) they're integer values (no decimals). For labels you can return any arbitrary string, e.g. '23.4 C'.

Posted by juha at Oct 10, 2011 03:42

Thanks Juha!

I've been looking into the OpenRemote code and it shouldn't be too difficult to make some changes in the HTTP protocol in order to accept full strings (decimals and units included). The fact for not accepting decimals, is that a requirement for sliders and labels or is it just an temporary limitation in the HTTP protocol? For the latest case, would you accept some humble contribution? (ex: full strings, user regex, etc)?

Posted by dberenguer at Oct 10, 2011 07:33

Patches would be very welcome, especially on the HTTP protocol.

The read() implementation should return values according to the datatype (via SensorType enum) of the sensor that is bound to it. So for sensor type 'Switch' it should indeed be on/off, for sensor types 'level' and 'range' they should be integers (this is the datatype sliders use on the panels), for 'custom' sensor type, it is ok to return an arbitrary string (this can be bound to a label).

User regex etc also welcome – some of these have been implemented for other protocols, some are already in other work branches which you can base your patches on if you'd like.

I'll need to run but go ahead and send your patch or I can later point to some of the existing examples in SVN if necessary.

Posted by juha at Oct 10, 2011 09:01
Document generated by Confluence on Jun 05, 2016 09:30