Closed GoogleCodeExporter closed 8 years ago
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
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
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
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
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
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
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
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
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
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
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
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
nice, is the code available in you clone?
Original comment by teichsta
on 3 Apr 2013 at 10:24
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:
[deleted comment]
Yes, code is available on my clone.
Original comment by pauli.an...@gmail.com
on 3 Apr 2013 at 2:33
[deleted comment]
[deleted comment]
Original comment by teichsta
on 21 May 2013 at 9:25
Original comment by kai.openhab
on 7 Aug 2013 at 7:18
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
Original comment by kai.openhab
on 11 Aug 2013 at 7:30
Wiki updated
Original comment by pauli.an...@gmail.com
on 11 Aug 2013 at 7:32
Original issue reported on code.google.com by
mishoboss
on 7 Aug 2011 at 9:26