Multi-item item

[GoogleCodeExporter]

In many cases a command result contains data that could feed several items. For 
example the HTTP request to Google Weather returns XML that contains current 
temperature, current humidity, weather condition and a forecast for the next 4 
days. Now if a user wants to get all these data, openHAB has to make a HTTP 
request for every one of these values, which is inefficient.

In that case a Multi-item type could be provided to fetch this kind of results, 
parse them via Transformation services (XSLT, RegExp, etc.) and feed other 
items with values.

Original issue reported on code.google.com by mishoboss on 7 Aug 2011 at 9:26

[GoogleCodeExporter]

Two ideas for item configuration:

-------------- 1-st idea --------------

A Multi item that contains the RAW data and regular items that feed from the 
Multi item via Transformation rules:

Multi Google_Weather { 
http="<[http://www.google.com/ig/api?weather=Sofia,%20Bulgaria&hl=bg:60000]" }

Number Weather_Temperature "Temperature [%.1f °C]" <temperature> (Weather) { 
feeder="Google_Weather:XSLT(google_weather_temperature.xsl)" }

String Weather_Condition "Condition [%s]" <temperature> (Weather) { 
feeder="Google_Weather:XSLT(google_weather_condition.xsl)" }

-------------- 2-nd idea --------------

A Multi item that parses the data via Transformation rules and feeds with 
values other regular items:

Multi Google_Weather { 
http="<[http://www.google.com/ig/api?weather=Sofia,%20Bulgaria&hl=bg:60000] 
feed=[Weather_Temperature:XSLT(google_weather_temperature.xsl)] 
feed=[Weather_Condition:XSLT(google_weather_condition.xsl)]" }

Number Weather_Temperature "Temperature [%.1f °C]" <temperature> (Weather)
String Weather_Condition "Condition [%s]" <temperature> (Weather)

Original comment by mishoboss on 7 Aug 2011 at 9:59

[GoogleCodeExporter]

I was also looking for a way to parse a XML file into multiple items at once.
Sound like a good feature.

Original comment by nicoat...@gmail.com on 18 Nov 2012 at 9:48

[GoogleCodeExporter]

I quickly implement proto type for second idea. Binding implement 
AbstractEventSubscriberBinding.

Example:

Number temperature
Number wind

String feedertest  { 
http="<[http://weather.yahooapis.com/forecastrss?w=566473&u=c:60000:REGEX((.*?))
]", feeder="temperature:XSLT(demo_yahoo_weather.xsl)", 
feeder="wind:XSLT(demo_yahoo_weather.xsl)" }

It seems that only one feeder binding will be called (wind in this case). Is 
this known limitation or do I something wrong? 

Original comment by pauli.an...@gmail.com on 30 Nov 2012 at 7:23

[GoogleCodeExporter]

I tuned my proto type and at least this kind of solution work.

Number temperature
Number wind

String feedertest  { 
http="<[http://weather.yahooapis.com/forecastrss?w=566473&u=c:60000:REGEX((.*?))
]", 
feeder="temperature:XSLT(demo_yahoo_weather.xsl)|wind:XSLT(demo_yahoo_weather.xs
l)" }

22:10:11.264 INFO  runtime.busevents[:46] - temperature state updated to 5
22:10:11.266 INFO  runtime.busevents[:46] - wind state updated to 5

Original comment by pauli.an...@gmail.com on 30 Nov 2012 at 8:16

[GoogleCodeExporter]

Technically, this approach obiously works, but it imho breaks the architecture. 
You are more or less forcing a certain String item to be a temporary variable 
for your binding. This violates two principles:
1. Items should be meaningful by themselves (i.e. being something to 
operate/use/measure, i.e. a part of the HA domain and not the technical 
solution underneath)
2. Bindings are supposed to be stateless - in this solution, they would keep 
some state in this "Item variable".

To solve the issue, I would rather prefer some smarter HTTP binding. This could 
e.g. have some global URIs configured in openhab.cfg (e.g. the weather uri) and 
the binding configs could simply refer to these URIs by id and define an XPath 
expression. The HTTP binding could then decide by itself (e.g. again by a 
"refresh" param in openhab.cfg), how often a certain URI should be polled. 

Just my 2 cents.

Original comment by kai.openhab on 1 Dec 2012 at 9:03

[GoogleCodeExporter]

Hi Pauli,

admittedly i thought nearly the same way you did, but Kai's arguments are 
absolutely valid. From the architectural point of view we would misuse the 
given concepts for our needs.

What i thought about is having a kind of small cache (computing the 
HTTP-Caching headers the right way). When openHAB queries the n'th item with 
the same URL (and the URL is cachable (flag?!)) then it should talk the cached 
value rather than going to the server again.

Since caching implementations are the one of the most error prone 
implementations we must be very careful here.

Regards,

Thomas E.-E.

Original comment by teichsta on 3 Dec 2012 at 9:00

[GoogleCodeExporter]

hopefully somebody else did the work already:

http://hc.apache.org/httpcomponents-client-ga/httpclient-cache/apidocs/org/apach
e/http/impl/client/cache/CachingHttpClient.html

Original comment by teichsta on 3 Dec 2012 at 9:14

[GoogleCodeExporter]

I also agree, Kai's argument is pretty undisputed.  Architectural point of 
view, this problem is not only on http binding. To help binding development, it 
could be handy if architecture could somehow also support temporary storing or 
data pipes between different bindings. Meaning that some of the binding could 
only provide data exchange (http, tcp, ip, file, sql, etc) and other bindings 
to parse data to items (like feeder proto type).

CachingHttpClient sound very usable and it should solve this problem very well. 

Original comment by pauli.an...@gmail.com on 6 Dec 2012 at 3:25

[GoogleCodeExporter]

I'm glad this topic got some life after a year and a half of solence :)

I agree with Kai's point. It breaks the architecture. But it's a solution, and 
it's logical from a user point of view, I think. The smarter HTTP binding would 
work for HTTP communication only. What about the other general protocols like 
TCP/UDP/Serial? They need this as much as HTTP needs it. So, I don't think HTTP 
Caching is a nice solution.

Original comment by mishoboss on 7 Dec 2012 at 3:17

[GoogleCodeExporter]

This discussion is more or less the same of what has already been discussed 
here:
https://groups.google.com/forum/?fromgroups=#!searchin/openhab/tcp/openhab/aqy2E
B21Sks/U_HogqM-_WQJ
https://groups.google.com/forum/#!msg/openhab/TVmobwk-frs/mlkA2qnarR0J

This means that we should add a new layer that we could call something like 
"transport bundles". This will mean a bigger architectural change, which I am 
not opposed to, but which I think is complicated to get right and shouldn't be 
done in a rush - and especially not by forcing it into the current architecture 
(by misusing items).

Original comment by kai.openhab on 7 Dec 2012 at 9:15

[GoogleCodeExporter]

A little bit different approach to this problem is something I suggested long 
time ago. Developing an API for defining communication protocols. Imagine the 
only thing you have to do to support a new protocol is to define it's scheme in 
a XML file.

Original comment by mishoboss on 8 Dec 2012 at 12:09

[GoogleCodeExporter]

Because changing to CachingHttpClient seems to bigger task, I tested Kai's idea:

openhab.cfg:
http:weatherCache.url=http://weather.yahooapis.com/forecastrss?w=566473&u=c
http:weatherCache.updateInterval=60000

my.items:
Number temperature { 
http="<[weatherCache:10000:XSLT(demo_yahoo_weather_temperature.xsl)]" }
Number windSpeed { 
http="<[weatherCache:10000:XSLT(demo_yahoo_weather_wind_speed.xsl)]" }

Change is rather small to the binding, so could this be temporary solution 
before "transport bundle" layer is implemented?

Original comment by pauli.an...@gmail.com on 31 Mar 2013 at 5:28

[GoogleCodeExporter]

nice, is the code available in you clone?

Original comment by teichsta on 3 Apr 2013 at 10:24

[GoogleCodeExporter]

Hello,
attached you will find three additional xsl files for the weather forecast.
Feel free to implement it.
Regards Ansgar

Original comment by abode...@gmail.com on 3 Apr 2013 at 11:31

Attachments:

• demo_yahoo_weather_forecast_low.xsl
• demo_yahoo_weather_forecast_high.xsl
• demo_yahoo_weather_forecast_text.xsl

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Yes, code is available on my clone.

Original comment by pauli.an...@gmail.com on 3 Apr 2013 at 2:33

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Original comment by teichsta on 21 May 2013 at 9:25

[GoogleCodeExporter]

Original comment by kai.openhab on 7 Aug 2013 at 7:18

• Changed state: ReadyForReview

[GoogleCodeExporter]

Thanks! Code is included in changeset 
https://code.google.com/p/openhab/source/detail?r=ff4ffd3dfaf8582eec64f1c8011814
82e88dce28.

Pali, may I ask you to update the HTTP binding wiki page accordingly?

Original comment by kai.openhab on 7 Aug 2013 at 8:45

• Changed state: Implemented
• Added labels: Version-1.3.0
• Removed labels: Version-later

[GoogleCodeExporter]

Original comment by kai.openhab on 11 Aug 2013 at 7:30

[GoogleCodeExporter]

Wiki updated

Original comment by pauli.an...@gmail.com on 11 Aug 2013 at 7:32