Closed GoogleCodeExporter closed 8 years ago
Yes, this seems nice.
This is what I think it should have as additional properties:
Sitemap object:
- screen width
- screen height
- screen orientation
- background image
- background color
--------------------------
Widget object:
- width
- height
- X position
- Y position
- border thickness
- border color
- theme color (set a color theme for widget's elements, for example the slider knob)
- state images (set own images for ON and OFF states or other possible states, depending on the widget type)
In fact you could map many CSS attributes as openHAB sitemap meta properties.
--------------------------
New widget ideas:
- Chart widget (it's coming to Sechna from it's big brother ExtJS 4.0)
- Camera widget (simply stream JPEGs or maybe WebM video?)
--------------------------
There have to be a way for showing system messages, maybe in a popup window. A
system message may be that a command can't be executed because the device is
offline or doesn't respond.
The UI framework have to be as flexible as possible.
Another option to consider as good JS mobile framework is also jQuery Mobile.
Original comment by mishoboss
on 29 Mar 2011 at 9:35
[deleted comment]
[deleted comment]
jQuery Mobile would have the advantage to be under the MIT license, not only
GPL. This makes it easier to package it with the EPL licensed Equinox framework.
Original comment by kai.openhab
on 29 Mar 2011 at 3:38
The communication between openHAB and this UI should be done through a REST
interface, see issue 25.
Original comment by kai.openhab
on 29 Mar 2011 at 3:39
Another plus for jQuery Mobile is that it is compatible with more mobile
browsers. Sencha is best experienced on WebKit browsers (iOS, Android).
Original comment by mishoboss
on 29 Mar 2011 at 6:35
Hi, guys. I did some research for best technologies for building a tablet UI
and/or desktop UI. jQuery Mobile is meant only for smartphones with small
screens. It copies the iPhone user experience, i.e. nothing more than the
current openHAB web UI. So, I don't think it is going to be useful if we want a
decent tablet/desktop UI.
This is how I see it:
1. Using some good JavaScript framework with a lot of ready to use widgets
(sliders, buttons, etc.), for example jQuery is perfect I think (ExtJS 4.0 is a
perfect option too, but it is heavier and it's meant for building much more
complex UI than we need).
2. Using HTML5 and CSS3. The default mobile browsers for iOS, Android OS and
Windows Phone 7 have pretty good HTML5 support. However we don't care about the
HTML5 support, because we are going to compile the webapp to native app (read
about this later).
3. User defines his UI widget by widget in the config file. Then here comes two
different approaches:
- 3.1. Building the UI on the client device. The client requests a screen by
REST and the server returns it in XML or even better - JSON. Then the
JavaScript builds the UI on the client device.
- 3.2. Building the UI on the server. The client requests a screen by REST and
the server builds it in ready to use HTML and returns it to the client.
4. Compile the webapp as native app for almost all mobile platforms using
PhoneGap (http://www.phonegap.com/). It is a great open source mobile framework
and compiler that compiles to the 6 most used mobile platforms. And now even
Adobe added support for PhoneGap in Dreamweaver v5.5.
5. Using WebM for camera streaming. WebM is a new open video standard announced
by Google and used in HTML5. Mozilla Firefox 4, Opera 10.6, and Google Chrome
already support it natively and there's a plugin for Internet Explorer. Also
almost all mobile browsers support it. VLC seems to also support WebM, but I
have to check if it can stream it or only play it.
6. Using Highcharts (http://www.highcharts.com) for charts. It is a really nice
jQuery plugin. If using ExtJS 4.0, there's a built-in charts engine there.
I would like to help building a really nice, really up to date and really
flexible web UI for tablets and desktop (and everything with big screen, touch
or not). My brother is a graphic designer and he could help too for icons and
graphics.
Original comment by mishoboss
on 4 May 2011 at 8:58
Hi, thanks for sharing your thoughts :-)
Let me try to comment them as a feedback:
Ok, so jQuery Mobile is no option then, agreed.
1. So you wouldn't go for any existing "touch framework" like Sencha Touch
either? This sounds to me like a lot of work if you want to implement all such
features yourself; I wouldn't dare trying this; but if you (and your brother
;-)) are really motivated to do so, why not?
2. Not sure why you think HTML5 features are not of interest if we would use
PhoneGap; could you elaborate on this?
3. I would go for 3.1. The REST interface could serve the sitemap as JSON and
thus stay UI technology independent as this could be used by other UI
implementations as well.
4. A cool option, but imho it should stay an option as it blows up the release
cycle (getting the apps to the app stores etc.); the UI should also work nicely
as a pure web application without being compiled to a native app.
5. Wouldn't this require the webcam to support WebM? Are there already any such
webcams on the market? In general, I think we should simply use the HTML5 video
element for webcams and leave the format to the webcam (h.264 should work well,
too).
6. Highcharts looks pretty nice, would love to see my timeseries in it; but
first, we will have to tackle feature 21, I'm afraid...
Original comment by kai.openhab
on 4 May 2011 at 12:00
Hi, Kai
1. Yes, every touch framework I see does pretty much the same thing - mimic the
iPhone user experience. I think this is limiting for big screen apps. No, I
don't mean to do everything by myself. There are great JS frameworks like
jQuery that provides ready to use and highly configurable widgets. In fact we
need only slider, button and switch (toggle) widgets, I think.
2. Maybe you misunderstood me. I mean if the webapp is compiled to native app
we don't care about the HTML5 browser support.
3. Yes, I would too. It's a lot of work for a "thin client", but our days the
thin clients have dual core CPU's and at least 512MB memory :)
4. Agreed!
5. In fact I don't have any experience with WebM and the video tag. I have to
go deeper in that.
6. How is going the progress on feature 21? This feature is one of the things I
abandoned OpenRemote ;)
Original comment by mishoboss
on 4 May 2011 at 12:26
1. Well, Sencha Touch does not stick to small iPhone screens - it is very well
suited for tablets (see for example http://touchstyle.mobi/). And in contrast
to a "pure" JS framework it brings many useful things for touch interfaces like
toolbars, headers, menus, overlays, carousels etc. See the kitchensink for a
feature overview: http://dev.sencha.com/deploy/touch/examples/kitchensink/
2. Yes, I indeed misunderstood you :-)
6. Not yet started; we actually had somebody very interested in contributing
(to) this feature, timeline was to finish it during this year (hopefully
earlier); but as I am also very much missing this feature, we should see to get
it started soon.
Original comment by kai.openhab
on 4 May 2011 at 12:52
Sencha Touch works only with WebKit browsers. Like they say "Sencha Touch
allows you to develop mobile web apps that look and feel native on iPhone,
Android, and BlackBerry touch devices".
iPhone, Android and BlackBerry's native browsers are WebKit based. However
Windows Phone (IE), Symbian, Bada, etc. and every 3-rd party browser that is
not WebKit (Opera, IE, Firefox) will not render the UI correctly.
So, I think Sencha is not the best option, though it is a really great
framework.
Original comment by mishoboss
on 4 May 2011 at 1:32
I haven't seen any Windows Phone, Symbian, Bada tablets on the market so far...
And for mobile phone use, we still have the current UI, which supports these
platforms.
The focus should imho be iPad and Android-tablets, so I wouldn't rule out the
use of Sencha Touch. Remember that if you try to do similar things as Sencha,
you might have to restrict yourself to some rendering engine such as WebKit
yourself as your JS code might otherwise become overly complex (or the UI very
constraint as it has to support the different engines).
For users using a PC, it should be a fair assumption that they are also able to
use a WebKit based browser (noting that the title of this issue is "for
tablets", so PC-non-touch-browsers are not in the focus of this issue).
Original comment by kai.openhab
on 4 May 2011 at 1:45
Yes, I know this issue is only for tablet UI. However I have a little bit
different understanding about the client apps. Instead of providing one web app
for phones, another for tablets and another for PCs, I would go with just ONE
web app that is capable of showing highly configurable UIs on every screen size.
I think it is going to be a hell to maintain several different apps, written in
different ways. Also the user expirience is going to be the same on a phone, a
tablet or PC. I think it is doable and it is the better approach.
Imagine that you can build your interface by defining widgets and their
properties like X, Y, Width, Height, StateImageOFF, StateImageON, StateImage4
(or any possibe state), BachgroundColor, Border, BorderColor, Label, etc. With
these "tools" anyone can build any interface for any screen size. There just
has to be one web app that can visualize it on every decent browser.
Of cource this is just my 2 cents :)
Original comment by mishoboss
on 4 May 2011 at 8:52
[deleted comment]
P.S. Besides that, what about HP TouchPad (WebOS), RIM PlayBook and the many
Windows 7 tablets (and who knows what is coming next two years). Going with
WebKit is a bad idea, in fact going with anything that isn't a standard is a
bad idea. I like Sencha too, but... :(
Original comment by mishoboss
on 4 May 2011 at 9:35
HP TouchPad: WebKit
RIM Playbook: WebKit
Windows 7 tablets: Just install a WebKit browser
Have a look at
http://www.tested.com/news/hp-touchpad-vs-apple-ipad-vs-motorola-xoom-vs-blackbe
rry-playbook/1801/
So WebKit actually IS a de-facto-standard on tablet devices and I guess that
any newcomers in the market will have to deal with that fact.
Original comment by kai.openhab
on 4 May 2011 at 9:45
I don't agree with the one-app-fits-all approach. I think Apple proved with the
iOS devices that handhelds (and other touch devices) need totally different UI
approaches - Windows mobile tried for years having a PC look&feel on a phone,
but completely failed with it (luckily). And that you need different UIs for
different screen sizes can be seen by the fact that iPads and Android tablets
require dedicated apps (the apps designed for the phone screen are simply not
adequate).
So you have to deal with three different UIs after all; if you do not restrict
yourself to do it all-in-one, you gain flexibility and can really adapt to
specific needs of the specific UI.
And don't get me wrong: It would of course be nice to use the same UI framework
for phones and PCs as well; but the focus should be tablets and I don't see a
problem in concentrating the efforts on the WebKit engine (see my previous
comment).
Original comment by kai.openhab
on 4 May 2011 at 9:59
Discussions like this are something positive :) However we speak about little
bit different things. Windows Mobile dictated the user interface - small
buttons, small tree menus and so on. My idea is to let the user decide the look
and feel of his interface. Let him build whatever he wants - define screen size
and define widgets size, position and colors. This way if his target device is
a smartphone with 320x240 px resolution, he could build a nice UI that best
fits this size. Then he could build another UI for his 1024x768 px Windows 7
tablet in the living room with bigger and/or more widgets on the screen. You
don't dictate anything, it's all up to the user and his design skills.
All you have to provide is some decent toolset of properties like X, Y, Width,
Height, Color, Label and so on. Then the web app that reads these properties
and builds the UI is just ONE, not three. And you could have absolutely
different UIs for the phone and for the tablet.
Original comment by mishoboss
on 5 May 2011 at 8:14
i think that approach is to low-level.
If we want to reach a broad set of users we _should_ restrict the possibilities
of UI design or in other words we _should_ provide simple templates to easily
create new interfaces. Even me (somehow experienced) are not interested in
building every new page of my visualization from scratch (position the button,
size, style, tweak it) and after all the UI looks ugly again because my
experience is not in UI design.
I think using a framework from a _very_ experienced UI crew should be the first
approach. After that somebody could develop another UI so meet your
requirenments. By the way: do you know commandfusion? It is not HTML5 based,
but it looks very much like what you suggested.
No
Original comment by teichsta
on 5 May 2011 at 8:34
Hi, teichsta. Yes, maybe it is not very easy to build a pretty and useful
interface, but it worth the time spent. It is extremely important for a
domotics system to have highly customizeble interface engine. Once you get that
done, you can always provide some predefined templates or create simple wizard
with NEXT, NEXT, FINISH that generates some basic UI, that could be extended by
modifying the generated code later.
It is not so difficult to be done, but I think it is essential for every
domotics project.
Original comment by mishoboss
on 5 May 2011 at 9:14
I do not see why your requirements are specific to domotics; to me it simply
describes a very flexible and powerful UI framework; so yes, for a framework
user, all what you say makes sense. But I agree with teichsta that for an
openHAB user, this is far too much complexity and it should instead work with
little efforts from the user (just as the current web UI does). So for openHAB
use, you would definitely have to design "restrictive" pre-defined templates.
Having said that, I think if you really succeed in building such a flexible
framework, it will be useful for much more than merely serving as an openHAB
UI. I'd therefore suggest that you develop it independently of openHAB as a
separate project and we then do the linkage through the predefined templates.
This would allow openHAB to concentrate on its core values: Doing integration
of different systems (and offering flexible interfaces to connect different UI
frameworks on top) and providing automation functionality.
Original comment by kai.openhab
on 5 May 2011 at 9:44
Well, now you have to design your openHAB interface too. It just has very
little possibilities to make sophisticated design, because it is meant for
phones, not tablets.
How you imagine the tablet interface? What is going to be configurable?
Original comment by mishoboss
on 5 May 2011 at 11:01
Here's a concept for a tablet interface:
http://knx-user-forum.de/attachments/knx-eib-forum/8490d1269090390-misterhouse-i
pad-native-application-eibpad-concept.pdf
This could imho be a good starting point and it is close to the look&feel of
other tablet apps.
Original comment by kai.openhab
on 5 May 2011 at 4:45
Well, if you ask me, I would go with the OpenRemote/Elve approach. I like to
have full control over how things look like. I like to choose colors, button
images and so on. I want to make it entirely mine.
However this concept looks nice too. They talk about grid size and widget's
position (and I hope widget size too, at least for the camera and the chart
widgets). It seems to give good amount of customization options.
Take a look at this interface just for inspiration, though it's not a perfect -
http://www.mavromatic.com/images/grouse_interface_preview_2.JPG
Original comment by mishoboss
on 5 May 2011 at 5:32
[deleted comment]
You may check Dojo Mobile too when considering the right mobile framework for
the tablet UI. In my opinion it's no worse than Sencha and jQuery Mobile.
Unlike Sencha, Dojo Mobile is truly multi-platform and uses only strict HTML5
and CSS3 (not WebKit specific functions). I tested it with my iPhone 1-st gen
with iOS 3.0 and I must say the animations and transitions run pretty sleek (I
can't say this for Sencha or jQuery Mobile). It runs almost perfect on a PC on
Opera 11 and Firefox 4 too.
In the upcoming Dojo 1.7 there will be charts out of the box. In Sencha they
will be paid as far as I know.
Just my 2 cents :)
Original comment by mishoboss
on 21 Jun 2011 at 4:04
Another option is Adobe Flex 4.5.1 that came out 6 days ago. It builds native
cross-platform applications for iOS devices, Android OS and Blackberry PlayBook
OS (and I bet the next step is Windows Phone 7 support). Seems like the
performance is way better than HTML5. Take a look at this video for a real-life
example -
http://tv.adobe.com/watch/adc-presents/financial-trader-app-for-ios-android-and-
blackberry-playbook/
Original comment by mishoboss
on 27 Jun 2011 at 11:24
Using Dojo Mobile is a great idea. I've used the Dojo Toolkit for some
Enterprise projects. Moreover openHab is a fantastic project. I'm using it for
a couple of weeks now and I'm very intrested to bring this project a step
forward. If you like I can start the developing of a Dojo Mobile based UI. Also
I can start working on a REST Interface as communication Layer and on a
persistance storeage to provide historical data e.g. for charts.
You can find some amazing examples here:
http://chrism.dojotoolkit.org/mobile-0.2/make_samples/dojo-samples/demos/mobile-
gallery/demo.html
Original comment by oliver.m...@gmail.com
on 29 Jun 2011 at 12:55
Hi Oliver,
welcome to openHAB and glad to see that you are going to contribute some very
promising things!
AFAIK Kai is already working on the REST-issue (see
http://code.google.com/p/openhab/issues/detail?id=25), at least there are some
thoughts on how to develop such an interface. Especially the URL-Design would
probably be a time-consuming task because neither kai nor me are experts in
REST. Are you probably?
Dojo seems to be an interesting framework but keep in mind, the most
interesting device to serve currently would be a tablet (especially an iPad).
The working iPhone UI works pretty well and we should not spend resources on
developing the second mobile device UI, shouldn't we?
The persistence storage would be interesting as well! If you don't mind, just
open a new issue and we can discuss all details there!
Looking forward to working with you on the coolest opensource project since
sliced bread ;-)
Cheers,
Thomas E.-E.
P.S.: kai is on vacation currently so he won't be able to comment things in
more detail.
Original comment by teichsta
on 29 Jun 2011 at 2:28
Hi teichsta,
I would recommend a pure HTML / JS WebUI with no jsp parts, so the UI is
completly separated from the server side. On the client side there should be a
page controller which decides how to render the page and which widgets or
portlets to use e.g. different layout for tablets, mobiles and desktops. All
this is possible with dojo and moreover it is PhoneGap compatible, so one can
build native apps for a store.
The REST part could be tricky. I've some experiance with Jersey but I never
used it in an OSGI environment. Since Version 1.2 Jersey added basic OSGI
support. Jersy has some really nice features like Declarative Hyperlinking
(http://jersey.java.net/nonav/documentation/latest/linking.html). I don't know
which REST Framework Kai will use. In Issue 25 Restlet was mentioned, bu far as
I know Restlet is missing some features wich are required for a REST based
WebUI e.g. websocket / comet support. In the latest milstone they added a NIO
extension, which can be used to implement these features. On the other side one
can use Jetty for websocket / Comet support.
There is a great publish / subscribe framework called Project Atmosphere
(http://atmosphere.java.net/) it offers AjaxPush/Comet and websocket support
and it is very easy to use. For the REST part it uses Jersey.
At the weekend I will have a deeper look into the openHab architecture and will
think about possible integration solutions.
Maybe you can point me to some of the things you've allready thought about.
Regards
Oliver
links to
Original comment by oliver.m...@gmail.com
on 1 Jul 2011 at 10:18
Hi Oliver,
thanks for your input, but let's discuss the REST details in the corresponding
issue they are somewhat off topic here :-).
Regards,
Thomas
Original comment by teichsta
on 2 Jul 2011 at 5:31
Hi Oliver,
> I don't know which REST Framework Kai will use
Neither do I! Thanks a lot for your opinion on the REST frameworks, this is
indeed very helpful.
As Thomas suggested, I will continue the discussion on the REST issue
(http://code.google.com/p/openhab/issues/detail?id=25).
Regards,
Kai
Original comment by kai.openhab
on 11 Jul 2011 at 8:31
> I would recommend a pure HTML / JS WebUI with no jsp parts, so the UI is
completly
> separated from the server side. On the client side there should be a page
controller
> which decides how to render the page and which widgets or portlets to use
e.g.
> different layout for tablets, mobiles and desktops. All this is possible with
dojo
> and moreover it is PhoneGap compatible, so one can build native apps for a
store.
This is exactly what I've suggested earlier in this topic :)
> The working iPhone UI works pretty well and we should not spend resources on
developing the second mobile device UI, shouldn't we?
If it was up to me I would go with just ONE app for everything - touchscreen
phones, tablets, PCs, etc. Or at least the app for phones and tablets could be
the same. Every JS framework I see provides tools to deal with different screen
resolutions and orientations.
Also the current Mobile UI isn't perfect, mainly due to the used framework. See
my issue here for more info -
http://code.google.com/p/openhab/issues/detail?id=32
This issue is going to be solved with the REST API you talk about.
And another plus for ONE app is that you maintain only ONE app ;)
Original comment by mishoboss
on 12 Jul 2011 at 8:43
I have created a static prototype with Sencha Touch - please find attached a
few screenshots. I will soon also provide a url, where this can be tested
directly on an iPad :-)
Feedback welcome!
Original comment by xthirtyn...@gmail.com
on 16 Sep 2011 at 10:40
Attachments:
[deleted comment]
The prototype is now available at http://goo.gl/GpZ4H !
So go and use your webkit-based browser or better directly your tablet to try
it out.
Please note that this is a static prototype, so nothing happens if you operate
any switches or sliders (not even the icon updates to the new status).
Furthermore there is a rendering bug on the "Rooms" tab, you need to change
your tablet orientation once to make it render correctly.
This prototype is just meant to give a first impression of how an openHAB
tablet UI could look like based on the Sencha Touch framework. Nothing is
carved in stone yet and the exact features and UI guidelines (vertical
scrolling as on the "Rooms" tab or rather horizontal scrolling as on the
"Functions" tab?) still have to be worked out.
Nevertheless, I think it is a good starting point and I welcome your feedback
and ideas!
After working on this prototype, I have the impression that Sencha Touch is a
good choice for tablet UIs (while it is not well suited if you want to design a
desktop UI), so I think I go further this road.
Kai
Original comment by kai.openhab
on 17 Sep 2011 at 10:18
Hi Kai, nice work¡
We have played with your prototype in chrome, and it looks fine. But i can't
see it in my iPhone (although i can see sencha touch demos, for example).
Any idea?
Original comment by dmora...@gpm.es
on 19 Sep 2011 at 8:58
This UI is really only designed for tablets - I haven't tried it on the iPhone
at all and would need to do many changes in the code to support it (as it would
require a very different screen and menu layout).
Regards,
Kai
Original comment by kai.openhab
on 19 Sep 2011 at 9:24
Thanks for the info, Kai.
It looks truly awesome, specially the alerts and graphs (talking about the
persistence module) as they are new components to the UI.
But, do you think sencha is a good choice?, do you think it will be easy to use
the rest api with this UI?
Regards
Original comment by dmora...@gpm.es
on 19 Sep 2011 at 9:51
Yes, Sencha is really made for getting information via AJAX/REST, so I think it
is well suited for this. Nonetheless, it will mean quite some effort to adapt
the current static prototype to a fully working UI that is fed through REST...
Original comment by kai.openhab
on 19 Sep 2011 at 11:21
Sencha is the best choice up to date. I follow it pretty close, as well as Dojo
Mobile and jQuery Mobile (not suitable at all). I think to build Sencha
interface for openHAB, but I wait for Sencha 2.0 as there are a lot of API
changes there.
> This UI is really only designed for tablets - I haven't tried it on the
iPhone at all and would need to do many changes in the code to support it (as
it would require a very different screen and menu layout).
Sencha provides really flexible layouts that could visualize the content
differently regarding the screen size. I really think that this interface MUST
be suitable for wide range of touchscreen devices, not only for tablets. And
where ends the phones and starts the tablets, when you have the Samsung Nexus
Prime with 4.65" 1280x720 pixels display (a phone) and the Archos 43 with 4.3"
480x854 pixels display (a tablet)? :-)
Original comment by mishoboss
on 31 Oct 2011 at 12:18
looks great on chrome ! I'm already using openhab and old webUI of it, but will
have a motorolla Xoom in 2 days and want to try it there with new UI. Is there
a possibility to have it for testing ? I can help with some development too.
Original comment by ramazany...@gmail.com
on 9 Dec 2011 at 12:37
For testing, you can simply point your tablet browser as well to
http://goo.gl/GpZ4H - it should be immediately available.
I had myself the chance to test the prototype on a Galaxy Tab 10.1 this week -
unfortunately, the result was rather disappointing. While it works quite smooth
on the iPad2 (with the exception of initial loading and orientation changes),
it was dreadfully slow on the Galaxy tab - and when scrolling, the buttons
moved at a different speed than the page background :-(
So not really convincing at all, which made me think that I should reconsider
the choice of the framework again. Unless Sencha comes with updates that solve
these performance issues.
Another interesting framework would be the Vaadin TouchKit, see
https://vaadin.com/add-ons/touchkit. But I doubt that I will find the time to
do another prototype at the moment...
Original comment by kai.openhab
on 9 Dec 2011 at 12:52
do you have your prototype sources in the mercurial?
Original comment by ramazany...@gmail.com
on 9 Dec 2011 at 6:52
regarding performance I think it is better to use Sencha 2.0: "The second big
improvement we’ve made in Sencha Touch 2.0 is Android performance,
particularly when it comes to scrolling and animation"
Original comment by dina.gal...@gmail.com
on 9 Dec 2011 at 8:43
Would be nice if performance would improve on Android. Really lags with Dolphin
Browser, just a bit better with the stock browser
Original comment by honkton...@gmail.com
on 9 Dec 2011 at 8:49
> do you have your prototype sources in the mercurial?
Yes, in the wiki repo:
http://code.google.com/p/openhab/source/browse/prototype/tablet/?repo=wiki
> regarding performance I think it is better to use Sencha 2.0
Sounds promising, I will have a look how easy it is to migrate to version 2.0...
Original comment by kai.openhab
on 9 Dec 2011 at 10:30
I work on a UI based on Sencha 2.0. It runs relatively smooth on iPhone 1-st
gen with iOS 3.0 and great on Samsung Galaxy S with Android 2.3.4. I have a
little more work to do (I hope to be done in a day or two) and I will post here
my work for testing with different devices. Don't expect ready to use
application, it's just a proof of concept.
Original comment by mishoboss
on 16 Dec 2011 at 8:10
Note: This Sencha Touch UI has been released with openHAB 0.9.0 as a preview,
see http://demo.openhab.org:8080/touch/ and
http://code.google.com/p/openhab/source/browse/#hg%2Fdistribution%2Fopenhabhome%
2Fwebapps%2Ftouch.
Original comment by kai.openhab
on 2 Feb 2012 at 9:30
Wanted to try it out on my iPad2 but after asking for sitemap it stays in
"loading..." state forever.
Should the demo work with openHAB 0.9.1?
Original comment by h...@harleyman.lu
on 27 Apr 2012 at 5:01
Original issue reported on code.google.com by
kai.openhab
on 29 Mar 2011 at 7:55