openHAB + Android = HABDroid

[Victor Belov]

Hi,

Just wanted to share a small video:

http://www.youtube.com/watch?v=i11gZGGwtNo

I decided to write an Android client app for openHAB, cause there is one already for iPhone and I wasn't able to find any activity on such an app for Android on the Internet. If somebody is doing that in stealth mode you still can stop me and convert me into a helper :-)

I've spent about 3 evenings writing this, so this is just a beginning, with basic model and navigation. It is connected to demo openHAB on Kai's site on the video, icons downloaded and cached locally. The app is running on Google Nexus S

No controls yet and I gonna spend a lot of time on making items more beautiful instead of just ugly displaying the "label" field… And I think I need to move to white background maybe...

I didn't check the Android developer license yet, but hope it will permit to publish HABDroid as open source and include into openHAB project!

Best regards,

Victor Belov

[Kai Kreuzer]

Hi Victor,

Excellent!!!

I don't think anybody was working on a Android app in stealth mode, but you!

Sooner or later I wanted to start one as I am an Android user myself. But as I haven't started learning implementing Android apps, that was still something for later… So you can count on my full support and we will definitely help making it an official part of the project.

I think if possible, you should stay with the black background - it is more Android like and if we stick to transparent images, it should hopefully be possible.

Feel free to push the code already to a clone repository. This way you can get early feedback on code and the one or other might already build it himself and test it on other devices.

Best regards,

Kai

--
You received this message because you are subscribed to the Google Groups "openhab" group.
To post to this group, send email to ope...@googlegroups.com.
To unsubscribe from this group, send email to openhab+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/openhab?hl=en.

[Victor Belov]

Hi,

As I never did Android applications too, I would prefer to push the code a little bit later, after I make it a less shame to show :-)

Best regards,

Victor Belov

[Kai Kreuzer]

Haha, ok, understood :-)

But I appreciate that you chose openHAB as the target of your very first Android ambitions :-)

Regards,

Kai

[Pablo Romeu]

Congratulations Victor!!! I did the iOS client and it is a bit painful ;)

I have never programmed an Android App, but if you need any help with REST, do not hesitate to ask me. I am an expert already!!! :)

[Thomas Eichstädt-Engelen]

HI Victor,

although i don't own an Android device (yet) i am very interested to extend the available openHAB client base.

Probably you didn't notice this Android Tutorial: http://www.vogella.de/articles/Android/article.html

Lars' Eclipse-Platform Tutorial is very comprehensive so i assume the Android-Turorial is as good as the Eclipse-Platform thing.

Cheers,

Thomas E.-E.

[Victor Belov]

Hi Pablo,

Yeah, openHAB REST is a little bit tricky on the "how to interpret what you get" side :-)

The main question is how do you decide on whether to take data from the widget, or from item linked to the widget? :-) Cause I think unifying this in both iOS and Android app will make a benefit to users, who use both platforms. Maybe you can tell some words about this? And do you take the whole site map structure of homepage and browse it locally then, or do you request pages individually when user click on certain group widgets?

Another big challenge I'm facing now is to decide either to go with a design where a separate service will continuously fetch data from openHAB and supply datasource to the application, or just make data requests individually from user interface activities...

Best regards,

Victor Belov

[Victor Belov]

Hi Thomas,

Developing for Android is quite easy, after you understand their paradigm. Thanks for the tutorial, will read it anyway - always good to learn!

I'm not an Android user either - I run my life on iPhone, iPad and MacBook. I'm in the middle of the new house buildout, that was one of the main reasons I went into home automation story… And I want to have in-wall touch screens over the house, but I found that existing ones on the market (especially from KNX vendors) are bloody expensive and hardly make functions I need. And they are closed - you can't add anything to them… So for me writing an Android client is part of a bigger project which is an open source in-wall touchscreen panel based on components which are freely available on the market and one can buy them and make the panel DIY and Android OS. But I want to make this panel look good. So I asked a friend of mine, who is an industrial designer, to make some easy pretty design for me. What came out of this is in attached picture, hope you like it. I just finished (at least I think so) with hardware selection process several days ago and now I'm waiting for it to arrive with Fedex from the vendor. The final design will change a bit cause we will get rid of buttons with switching to Android ICS (the initial design was made for Gingerbread). As soon as I combine the hardware I will post a video on how it works. I plan to post the design and 3D models of the enclosure for this hardware as open source, so anybody will be able to order this pieces of plastic from 3D printing services in color and material they like, buy some ready-to-go electronic components, combine all of that together and get a product. That is the main idea, at least :-) The device is going to be a 1.2GHz ARM with 1Gb of RAM, ethernet and WiFi onboard, 7" capacitive multi-touch screen, 800x480 screen resolution, Android ICS.

Best regards,

Victor Belov

[Mihail Panayotov]

WOW, that's sweet :) It's a nice project, Victor! Can you say something about the price? Cause Asus MeMo for example is going to be Tegra 3 and selling on $249, which is more than good. There are even cheaper alternatives like Kindle Fire at $199 (and there are several full-featured Android ICS ROMs for it already).

About HABDroid - big applause! I am the developer of the Sencha Touch based UI (it doesn't have a sweet name yet) and I can help you too to make the communication with openHAB. The REST API is not so hard to understand, the pain is the real-time communication once the interface is built. But I think openHAB will soon provide HTTP streaming that will hopefully solve a lot of fundamental issues.

[Victor Belov]

Hi,

Well, it's no gonna be 249, not possible (yet) with open source hardware… I would say it should be below 500, while big guys sell their in wall touch panels for 1000+… How do you plan to mount Asys MeMo or Kindle Fire on the wall and connect it to power supply, so that it doesn't look ugly, huh? :-) I've only seen mounts for iPad and iPod Touch.

And thanks for your future help! :-)

Best regards,

Victor Belov

[Pablo Romeu]

Hi Victor,

First of all: HAHAHAHAHAAA xDDDDD I had the same problem at the beginning.

After some mails with Kai I understood the point. You have two ways of getting your data: through the rest/items call and through the rest/sitemap. The point is, do you want the openHAB Android client to get the SAME structure as the sitemap? Or you do not care about it?

If your idea is to build a dynamic app, that gets the sitemap from the openHAB server -as I do-, then you need both. In the iOS client I get first the items, and then I get the WHOLE sitemap. I go through the sitemap and assign items to the widgets, if the widget has an item. I did this because I am involved in other project that needs the items list. And, for switch/dimmer/button/rollershutter items you need to POST the value to the item, NOT the sitemap, so you really need the items. I suggest you to have a look at the grammar to understand all the possibilities:

http://code.google.com/p/openhab/source/browse/bundles/model/org.openhab.model.item/src/org/openhab/model/Items.xtext

and the sitemap's grammar.

http://code.google.com/p/openhab/source/browse/bundles/model/org.openhab.model.sitemap/src/org/openhab/model/Sitemap.xtext

To read the values, you have two options. If you read them from the item, you will get raw values like an integer: "5", but if you get them from the sitemap (as I do) you will get the strings ready to be shown, e.g.: "5º C".

To refresh the values, you can just get the whole sitemap. You could get just a branch, but I suggest you to get the full sitemap. It is easier and you get all the updates in one network call.

P.D.: Kai and Thomas, programming Android should be reaaaally easy for you, as it is java! You just have to understand the basic concepts (intents, etc.) and there you are! 

Regards,

[Mihail Panayotov]

Well, it would be ugly, there's no way. But maybe I'll try to cut a frame with a CNC router machine... I have one by me and it's worth a try :) Which open source hardware you plan to use? Something like BeagleBoard / PandaBoard?

[Victor Belov]

Hey,

PandaBoard ES. PandaBoard can also be used. Beagle is not powerfull enough for ICS :-(

Sent from my iPhone

On 13.03.2012, at 13:26, Mihail Panayotov <mish...@gmail.com> wrote:

Well, it would be ugly, there's no way. But maybe I'll try to cut a frame with a CNC router machine... I have one by me and it's worth a try :) Which open source hardware you plan to use? Something like BeagleBoard / PandaBoard?

--

You received this message because you are subscribed to the Google Groups "openhab" group.

To view this discussion on the web visit https://groups.google.com/d/msg/openhab/-/QW-Is8c6aO0J.

[Kai Kreuzer]

> Yeah, openHAB REST is a little bit tricky on the "how to interpret what
> you get" side :-)

Is that a matter of the learning curve or of a bad design? If you have
any feedback on how to improve the REST-API, let me know :-)

> To read the values, you have two options. If you read them from the item,
> you will get raw values like an integer: "5", but if you get them from the
> sitemap (as I do) you will get the strings ready to be shown, e.g.: "5º C".

All textual representation should be taken from the sitemap, because
that is the formatted version that can be defined by the user (and if
the user leaves out the [] part in the label, it even means that he
does not want to show a textual representation of the state. The icon
might e.g. be good enough for an open/closed window).
So the "raw data" of the item should only be used to do the
"graphical" parts of the widget, e.g. setting the switch to the right
position, placing the handle of a slider etc.

> To refresh the values, you can just get the whole sitemap. You could get
> just a branch, but I suggest you to get the full sitemap. It is easier and
> you get all the updates in one network call.

That's imho not a good strategy at all! The idea of the REST API is
that you always only display a single page of the sitemap and thus you
should always only poll for changes of this currently visible page
(see the very last example on the REST wiki page). Polling the whole
sitemap causes many more request (as it will also send a response if a
value on another page has changed) and more data transfer
(transferring always all pages instead of the currently visible one).

> P.D.: Kai and Thomas, programming Android should be reaaaally easy for you,
> as it is java! You just have to understand the basic concepts (intents,
> etc.) and there you are!

Right, it is indeed not the technology that kept me away from doing
it, but the lack of time :-)

Regards,
Kai

[Kai Kreuzer]

> Another big challenge I'm facing now is to decide either to go with a
> design where a separate service will continuously fetch data from openHAB
> and supply datasource to the application, or just make data requests
> individually from user interface activities...

You should definitely not only react on user activity - the page
should be automatically refreshed, whenever an item changes its state,
so buttons might be switched automatically if a light wents on,
temperature values are updated, etc.

Pablo cheated here for the iOS UI - he simply sends new requests in a
fixed interval and then updates the widgets accordingly.

The Classic UI and the Sencha Touch UI use the recommended approach:
The so-called long-polling/server-push requests. I just noticed that
this is not yet mentioned on the REST Wiki page (I must have missed to
add this), so the details are only in the issue tracker for the
moment: http://code.google.com/p/openhab/issues/detail?id=46

The idea here is simply that you can do a request for a page of the
sitemap with a special HTTP header, which will cause the server to
suspend the response and only send it once some state has changed on
it. So you can simply send such a request after initially rendering
your page and you know that whenever you receive a response, it is
time to update the page and send the next polling-request. This
reduces the number of requests to a minimum, while ensuring that your
UI is instantly updated upon a change of an item.

You can see this nicely if you use the Classic UI and the Sencha Touch
UI side by side - you switch something on the one UI and you see the
instant update on the other.

Regards,
Kai

[Victor Belov]

Hi,

Yep, that is the right mechanism and I am going with a service then. Does this polling return only events happened?

Sent from my iPad

> --
> You received this message because you are subscribed to the Google Groups "openhab" group.

[Kai Kreuzer]

> Does this polling return only events happened?

It returns exactly the same result as without the HTTP header - the
only difference is the suspension of the response until an event occurs.
So you get always the information of the full page incl. all
widgets/items which have not changed.

If you are interested in getting a streamed feed of change events
instead, you should have a look at this issue:
http://code.google.com/p/openhab/issues/detail?id=62
Oliver is about to finish it, so this feature should be available soon
(Mihail is impatiently waiting for it ;-)).

Regards,
Kai

[Pablo Romeu]

El miércoles 14 de marzo de 2012 20:15:11 UTC+1, Kai escribió:

>
>
> > To refresh the values, you can just get the whole sitemap. You could get
> > just a branch, but I suggest you to get the full sitemap. It is easier and
> > you get all the updates in one network call.
>
> That's imho not a good strategy at all! The idea of the REST API is
> that you always only display a single page of the sitemap and thus you
> should always only poll for changes of this currently visible page
> (see the very last example on the REST wiki page). Polling the whole
> sitemap causes many more request (as it will also send a response if a
> value on another page has changed) and more data transfer
> (transferring always all pages instead of the currently visible one).

Ok, here is when Kai and I disagree. In a mobile device, and in my opinion, using a polling schema, one may prefer to get all the current values in the whole sitemap, and not having to send a new request each time you enter a new page. You get more data in each request but it is barely not much more (some KB), you do not have to request for new values each time you change the page and you save time and bytes of connections overhead.

But the best approach, as Kai says, is to subscribe to the push notifications of the server. Then, there is no point in making requests each x seconds as the iOS client does. I did it this way because the lack of time.

BTW Victor, you will notice that Kai has clear ideas of how openHAB clients should be and it is difficult to convince him, ;)

[Kai Kreuzer]

> Ok, here is when Kai and I disagree. In a mobile device, and in my
> opinion, using a polling schema, one may prefer to get all the
> current values in the whole sitemap, and not having to send a new
> request each time you enter a new page. You get more data in each
> request but it is barely not much more (some KB), you do not have to
> request for new values each time you change the page and you save
> time and bytes of connections overhead.

This is only true with your (cheated!) approach to do updates with a
fixed interval. As soon as you use server-push, it definitely does not
make sense that you get server responses for changes that are not
visible at all (and that are relevant for a page that the user will
never look at). The bigger the sitemap gets, the more this will become
a problem.
Take the example of my "power metering" page: The items on this page
get in average an update every second. While I am on this page, I want
to immediately see these changes, so that I can directly see the
result of turning on a light for example. But while I am on any other
page (e.g. the homepage, which might be opened all day long), I do not
want to have a full sitemap transferred every second - ideally, there
should be no traffic at all as long as nothing changes on the homepage.

> But the best approach, as Kai says, is to subscribe to the push
> notifications of the server. Then, there is no point in making
> requests each x seconds as the iOS client does. I did it this way
> because the lack of time.

Agreed, but this means that when changing the page, you will have to
execute an update request for the next page to display (assuming that
you do not always subscribe for ALL changes, which does not make sense
as explained above).

> BTW Victor, you will notice that Kai has clear ideas of how openHAB
> clients should be and it is difficult to convince him, ;)

That's not true! I can be very easily convinced by good arguments,
have a try :-D

Regards,
Kai

[Victor Belov]

Hi,

I've browsed both threads you mentioned before, but couldn't clearly understand how it gonna look :-)

I believe we need to have push mechanism (long-polling is the easiest way on the client side from my point of view) to deliver all possible events on changes happening with items. You are right that showing dynamically changes happening to switches or values on the screen is cool. I also want it. But there are scenarios where you need to get information about items not on the screen too. Ideally the mechanism of interaction between the application and openHAB should look like getting information on the current state of everything and then using push to get events on changes happening. Changes about everything. Imagine alarm going on. A UI application could react on that not depending on if user is on the alarm page. There are other usage scenarios too… And in the future, if items and site maps will be stored in dynamic persistent storage instead of files and there will be API for adding/editing/deleting them, this push mechanism should also deliver the information about that changes to dynamically change it on client side (and by the way internally in openHAB different subsystems should also get this events to reconfigure). Anyway, I tried the existing mechanism and it didn't work :-) What am I doing wrong? :

curl -H "X-Atmosphere-Transport: long-polling" http://demo.openhab.org:8080/rest/sitemaps/demo/FF_Bath

<title>Error 500 java.lang.NullPointerException</title>

</head>

<body><h2>HTTP ERROR 500</h2>

<p>Problem accessing /rest/sitemaps/demo/FF_Bath. Reason:

<pre>    java.lang.NullPointerException</pre></p><h3>Caused by:</h3><pre>java.lang.RuntimeException: java.lang.NullPointerException

at org.atmosphere.handler.ReflectorServletProcessor.onRequest(ReflectorServletProcessor.java:154)

at org.atmosphere.cpr.AsynchronousProcessor.action(AsynchronousProcessor.java:219)

at org.atmosphere.cpr.AsynchronousProcessor.suspended(AsynchronousProcessor.java:154)

at org.atmosphere.container.Jetty7CometSupport.service(Jetty7CometSupport.java:82)

at org.atmosphere.container.JettyCometSupportWithWebSocket.service(JettyCometSupportWithWebSocket.java:67)

at org.atmosphere.cpr.AtmosphereServlet.doCometSupport(AtmosphereServlet.java:1217)

at org.atmosphere.cpr.AtmosphereServlet.doPost(AtmosphereServlet.java:1176)

at org.atmosphere.cpr.AtmosphereServlet.doGet(AtmosphereServlet.java:1162)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)

at org.eclipse.jetty.websocket.WebSocketServlet.service(WebSocketServlet.java:80)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)

at org.eclipse.equinox.http.servlet.internal.ServletRegistration.service(ServletRegistration.java:61)

at org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(ProxyServlet.java:126)

at org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(ProxyServlet.java:68)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)

at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:547)

at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:481)

at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:225)

at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:940)

at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:409)

at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:186)

at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:874)

at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)

at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250)

at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149)

at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110)

at org.eclipse.jetty.server.Server.handle(Server.java:349)

at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:441)

at org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:904)

at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:565)

at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:217)

at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:46)

at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:545)

at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:43)

at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)

at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)

at java.lang.Thread.run(Thread.java:636)

Caused by: java.lang.NullPointerException

at org.atmosphere.jersey.AtmosphereFilter$Filter.executeSuspend(AtmosphereFilter.java:827)

at org.atmosphere.jersey.AtmosphereFilter$Filter.suspend(AtmosphereFilter.java:777)

at org.atmosphere.jersey.AtmosphereFilter$Filter.filter(AtmosphereFilter.java:372)

at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1416)

at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1349)

at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1339)

at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:416)

at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:537)

at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:708)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)

at org.atmosphere.util.AtmosphereFilterChain.doFilter(AtmosphereFilterChain.java:155)

at org.atmosphere.util.AtmosphereFilterChain.invokeFilterChain(AtmosphereFilterChain.java:116)

at org.atmosphere.handler.ReflectorServletProcessor$FilterChainServletWrapper.service(ReflectorServletProcessor.java:293)

at org.atmosphere.handler.ReflectorServletProcessor.onRequest(ReflectorServletProcessor.java:151)

... 36 more

</pre>

<h3>Caused by:</h3><pre>java.lang.NullPointerException

at org.atmosphere.jersey.AtmosphereFilter$Filter.executeSuspend(AtmosphereFilter.java:827)

at org.atmosphere.jersey.AtmosphereFilter$Filter.suspend(AtmosphereFilter.java:777)

at org.atmosphere.jersey.AtmosphereFilter$Filter.filter(AtmosphereFilter.java:372)

at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1416)

at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1349)

at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1339)

at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:416)

at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:537)

at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:708)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)

at org.atmosphere.util.AtmosphereFilterChain.doFilter(AtmosphereFilterChain.java:155)

at org.atmosphere.util.AtmosphereFilterChain.invokeFilterChain(AtmosphereFilterChain.java:116)

at org.atmosphere.handler.ReflectorServletProcessor$FilterChainServletWrapper.service(ReflectorServletProcessor.java:293)

at org.atmosphere.handler.ReflectorServletProcessor.onRequest(ReflectorServletProcessor.java:151)

at org.atmosphere.cpr.AsynchronousProcessor.action(AsynchronousProcessor.java:219)

at org.atmosphere.cpr.AsynchronousProcessor.suspended(AsynchronousProcessor.java:154)

at org.atmosphere.container.Jetty7CometSupport.service(Jetty7CometSupport.java:82)

at org.atmosphere.container.JettyCometSupportWithWebSocket.service(JettyCometSupportWithWebSocket.java:67)

at org.atmosphere.cpr.AtmosphereServlet.doCometSupport(AtmosphereServlet.java:1217)

at org.atmosphere.cpr.AtmosphereServlet.doPost(AtmosphereServlet.java:1176)

at org.atmosphere.cpr.AtmosphereServlet.doGet(AtmosphereServlet.java:1162)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)

at org.eclipse.jetty.websocket.WebSocketServlet.service(WebSocketServlet.java:80)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)

at org.eclipse.equinox.http.servlet.internal.ServletRegistration.service(ServletRegistration.java:61)

at org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(ProxyServlet.java:126)

at org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(ProxyServlet.java:68)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)

at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:547)

at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:481)

at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:225)

at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:940)

at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:409)

at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:186)

at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:874)

at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)

at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250)

at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149)

at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110)

at org.eclipse.jetty.server.Server.handle(Server.java:349)

at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:441)

at org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:904)

at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:565)

at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:217)

at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:46)

at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:545)

at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:43)

at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)

at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)

at java.lang.Thread.run(Thread.java:636)

--
You received this message because you are subscribed to the Google Groups "openhab" group.

To post to this group, send email to ope...@googlegroups.com.

To unsubscribe from this group, send email to openhab+unsubscribe@googlegroups.com.

[Kai Kreuzer]

Hi,

But there are scenarios where you need to get information about items not on the screen too. Ideally the mechanism of interaction between the application and openHAB should look like getting information on the current state of everything and then using push to get events on changes happening. Changes about everything. Imagine alarm going on. A UI application could react on that not depending on if user is on the alarm page. There are other usage scenarios too…

I agree that there are scenarios where you want the UI to be informed even if it is not related to the current page. I do not agree that this should all be done through the sitemap&item REST API. Actually, I was thinking about introducing a notification API. You could send notifications from rules and others can subscribe to any sent notification. This could be any UI, the XMPP connection or whatever. This way, the user defines once on the server side what kind of notifications he wants and what kind of severity they have. If you start trying to do this in the UI (take your example where the alarm goes off - how would the UI know that this is a special item it should launch a popup message for?) you would have to configure this somewhere in the UI and you would end up with a lot of logic there - and the user would have to do the same for all other UIs as well.

And in the future, if items and site maps will be stored in dynamic persistent storage instead of files and there will be API for adding/editing/deleting them, this push mechanism should also deliver the information about that changes to dynamically change it on client side (and by the way internally in openHAB different subsystems should also get this events to reconfigure).

This would yet be another new resource on the REST API - again, it imho does not make sense trying to do this with the currently available API. 

The current (sitemap) API is designed for providing information about pages and delivering updates for them - nothing more and nothing less.

Anyway, I tried the existing mechanism and it didn't work :-) What am I doing wrong? :

curl -H "X-Atmosphere-Transport: long-polling" http://demo.openhab.org:8080/rest/sitemaps/demo/FF_Bath

There seems to be a bug if you do not specify the format you wish the response in. Try instead:

curl -H "X-Atmosphere-Transport: long-polling" -H "Accept: application/json" http://demo.openhab.org:8080/rest/sitemaps/demo/FF_Bath

Regards,

Kai

[Mihail Panayotov]

I agree that there are scenarios where you want the UI to be informed even if it is not related to the current page. I do not agree that this should all be done through the sitemap&item REST API. Actually, I was thinking about introducing a notification API. You could send notifications from rules and others can subscribe to any sent notification. This could be any UI, the XMPP connection or whatever. This way, the user defines once on the server side what kind of notifications he wants and what kind of severity they have. If you start trying to do this in the UI (take your example where the alarm goes off - how would the UI know that this is a special item it should launch a popup message for?) you would have to configure this somewhere in the UI and you would end up with a lot of logic there - and the user would have to do the same for all other UIs as well. 

Yes, this is the right way doing this. I'm personally waiting impatiently for this API. Also the API for item and sitemap management (and implementing remote editing in the Designer via this API), and also a FILE REST API that will allow to get list of files and dirs of a given path and read and write to a specific file. This will unleash a lot of new functionality. Ahhh, can't wait! :-)

About the philosophy of the clients dealing with status data. What I did in the Sencha UI is this:

1. On startup the app loads the whole sitemap data (all pages) and builds and array of objects that it will consume easily later. It also builds the whole nested tree menu on the left side if the app is viewed on tablet or PC.
   
2. On every page change the app builds the page widgets from the array we built on the app startup. This is done without any new server request, and thus you see a smooth page transition without any delay. Then it sends a normal (not suspended) request to retrieve the current item statuses for the current page only. Right after the result is received and item statuses of the page are updated, the app sends a suspended request (long-poll) and waits for changes.
   
3. On changes received, it updates all widgets on the page and makes a new suspended connection again. This repeats until the page is changed.
   
4. On new page change, the app cancels any previous suspended requests and all from point 2. repeats for the new page again. 
   

Loading and parsing the whole sitemap data on a given short interval is an ugly cheat. Sorry, Pablo :-) I don't even like how suspended requests are implemented right now, and it's not only me. That's why Oliver works on a new streaming API (http://code.google.com/p/openhab/issues/detail?id=62) that will use HTTP streaming and websockets and a new data format for the statuses.

About items that you want to update, but they're not on that page, it is a bit of problem. I have such a scenario on the Sencha Touch UI. Imagine you are on the tablet interface with the left navigation tree menu. You open some page, but you navigate to a submenu that consists of only group items (i.e. button widgets). The app renders these button widgets on the left side tree menu, not on the content pane, so you will continue to see the page where you were, but on the left menu you are on another page. The app is made to continue receive status updates for the seen page, no matter where points the left menu. But the left menu doesn't receive status updates any more, because it is actually an another page... This is a nasty problem that has its solutions, e.g. you send another requests for the left navigation to update it.

[Pablo Romeu]

El viernes 16 de marzo de 2012 10:19:34 UTC+1, Mihail Panayotov escribió:

Loading and parsing the whole sitemap data on a given short interval is an ugly cheat. Sorry, Pablo :-) I don't even like how suspended requests are implemented right now, and it's not only me. That's why Oliver works on a new streaming API (http://code.google.com/p/openhab/issues/detail?id=62) that will use HTTP streaming and websockets and a new data format for the statuses.

Hahahahaaa No problem. When I programmed this, there were no suspended requests in openHAB, so I had to do something instead. 

[konfro...@elektroschaefer.info]

Are there any news,
or a code base/hosting? I don't have that much time,
but would do my best to help out and get the app at least to
a similar level like the "iphone app.

[Victor Belov]

Hi,

It takes some time. Last weeks I had much less time then I expected, but it is progressing. The main activity that is opening pages of site map and then polling them using long-poll technology is basically ready and tested. Most of important widgets are working. I decided to go with a visualization only app now, so it doesn't have any background services, all jobs are done inside user interface activities. Most of utility jobs, like caching icons loader are also in the place.

The last 2 things I want to do before posting the code to repository is making on/off switch work and finishing configuration activity. I plan to post the code next weekend and will be fully open for community commitments!

Best regards,

Victor Belov

--
You received this message because you are subscribed to the Google Groups "openhab" group.

To view this discussion on the web visit https://groups.google.com/d/msg/openhab/-/r4x7Kd_SN10J.

To post to this group, send email to ope...@googlegroups.com.

To unsubscribe from this group, send email to openhab+u...@googlegroups.com.

[Victor Belov]

Hi,

Just wanted to do a small update on HABDroid. I finished the code for what I wanted but found some crazy bug in openHAB long-polling response which breaks the UI. As soon as we resolve it and I check it - I will publish the code. Just wait a little bit! :-)
For now HABDroid supports browsing the whole sitemap with most of widgets and sends on-off commands to switches. Updates use long-polling so it works almost realtime when displaying item changes.

Sent from my iPad

[konfro...@elektroschaefer.info]

Great! :) Thanks for the update!

Am Donnerstag, 5. April 2012 22:20:44 UTC+2 schrieb belovictor:

Hi,

Just wanted to do a small update on HABDroid. I finished the code for what I wanted but found some crazy bug in openHAB long-polling response which breaks the UI. As soon as we resolve it and I check it - I will publish the code. Just wait a little bit! :-)
For now HABDroid supports browsing the whole sitemap with most of widgets and sends on-off commands to switches. Updates use long-polling so it works almost realtime when displaying item changes.

Sent from my iPad

[Thomas Eichstädt-Engelen]

btw: as you know Kai and me have been to L&B 2012 (in Frankfurt, Germany) and we saw some "interesting" wall touch panels as well :-)

The "best" thingy was by TCS. A 7" display with ugly thick black frame and Android 2.3 (4?) as OS. The sell it at ~1000€ as you stated already. We countered that an iPad is half as expensive but outmatches this device in any respect. The answer was:"yes, but you have to buy a new iPad every three years and our device will be used more than ten years" ... one of the best arguments i've ever heard for selling low-grade hardware for high-end prices.

In other words: keep us informed how things are going!

Cheers,

Thomas E.-E.