openHAB Sencha 2.0 UI showcase

[Mihail Panayotov]

The last two weeks I work on a Sencha 2.0 user interface for openHAB.
A lot is done, a lot remains to be done. This is just a developers
preview version, not a fully working app.


--------------------------- GET THE APP ---------------------------

Here you can see a working demo of the new openHAB Sencha 2.0 UI:
http://m-design.bg/openhab_ui/
A link to download the app is available here: http://m-design.bg/openhab_ui/openHAB_UI.rar


--------------------- APP SPECIFICATIONS ---------------------

The web-app is developed with Sencha 2.0 JavaScript Framework. Sencha
2.0 is in developers preview stage at the moment I write this. There
are a lot of bugs to be fixed and a lot of key functionality still
missing. However Sencha 2.0 is the next big step in mobile HTML5 app
development and that's why I choose it.

The communication between this openHAB UI and the openHAB Core (the
server) is achieved via the REST API and JSONP interface. JSONP allows
cross-domain communication, so the openHAB UI could be hosted separate
from the openHAB Core or it could be even wrapped in a native mobile
app with PhoneGAP for example. Websockets are going to be supported
too.


------------ CURRENT DEVELOPMENT STAGE ------------

At this stage this app is just a "proof of concept". Also Sencha 2 is
in a very early stage too and far from final release. However the
ground is there and is working well for my opinion. The app
successfully builds the Demo sitemap with almost all widgets (still
there are some missing widgets). All UI texts like "back", "home",
etc. are translatable via settings.cfg file in the root dir. There are
also some settings there like default server and default sitemap. The
app can't send commands and receive status updates at the moment.
Please, see may suggestion for a status update REST channel here -
http://code.google.com/p/openhab/issues/detail?id=56


--------------------------- KNOWN BUGS ----------------------------

There is ONE major bug there - the app slows down after 1-2 minutes of
actively using. This is a "heap leak" bug in Sencha 2 and I've
reported it: http://www.sencha.com/forum/showthread.php?163757-PR3-leaves-some-Array-and-Object-data-on-item-removal




Hope you like it :-)

[Mihail Panayotov]

One more thing I would like to add. This is NOT just a tablet UI. I
develop it to be as flexible as possible. So it could be used in a
phone, a tablet or even in Desktop PC and still looks pretty on any
screen size. For example when the UI is seen by a phone it looks
pretty much as the current openHAB webapp - fields in one column. But
when it's seen on a tablet, there is a new panel docked in the left
for additional functionality, for example the whole menu tree could be
there. And when the tablet rotates in landscape mode, the one-column
interface becomes two-column interface for a more beautiful item
placement. When it's seen by a PC it is always in two-column mode and
the left docked panel is shown.

There are also other possibilities like different widget render
depending on the device type. Any idea how to make it as flexible as
possible is more than welcome :-)

[Mihail Panayotov]

I would appreciate people to test it with different devices and post
here screenshots. I'm especially interested in iPhone 4 and 4S to see
how it renders on the hight density Retina Display. Thank you.

[Juanker Atina]

Great news!! Thanks for your work.

I will try it on iPhone 4 and post here some screenshots

Could you please post server URL, user and pass to login?

[Mihail Panayotov]

I haven't exposed an openHAB server to the Internet. Just put the
address of your own openHAB server (you need to download the latest
release of openHAB Core from yesterday). Authentication is not yet
implemented, so you don't have to put a username and password (the
fields are disabled). I'm looking for you feedback and screens :-)

[Kai]

Hi Mihail,

Looks pretty good already and reminds me of the current UI ;-)

I couldn't test yet with any mobile devices, just on my PC with Chrome. But here is some initial feedback:

- I would align the switches/buttons/value texts on the right side of the widget, this would look nicer

- The value on dimmers should either not be shown at all or moved out of the square brackets (at the moment the label is "Dimmer [0 %]").

- Same on the "Group Demo" page for all the group widget labels

- The "All lights" widget has a mapping, thus it should not be rendered as a switch, but as a single button with the label "All off" on it. Same for the one Scene widget.

Some general remark: I very much like it as a replacement of the current UI for smartphones. But for tablets I would expect a different user experience: Having the sliding effect on a two column screen seems awkward and it is not clear what you would want to put in the left panel at all. For a tablet, I prefer having the navigation on the left pane and the widgets on the central pane. Furthermore a toolbar is a nice thing for quick navigation (you could link each toolbar button to a sitemap), see the Sencha 1.0 prototype I had created: http://goo.gl/GpZ4H

May I ask why you didn't took my prototype (at least its concepts) as a basis, but rather started anew from scratch? Is this because the code/stylesheets are not reusable at all or because you are not convinced about the UX concepts I have tried to build into it?

Regards,

Kai

[Mihail Panayotov]

> Looks pretty good already and reminds me of the current UI ;-)

My idea was evolution, not revolution :-)

> - I would align the switches/buttons/value texts on the right side of the
> widget, this would look nicer

Agreed!

> - The value on dimmers should either not be shown at all or moved out of
> the square brackets (at the moment the label is "Dimmer [0 %]").
> - Same on the "Group Demo" page for all the group widget labels

Yes, I know. I just haven't done it yet.

> - The "All lights" widget has a mapping, thus it should not be rendered as
> a switch, but as a single button with the label "All off" on it. Same for
> the one Scene widget.

Yes. As I said not all widget types with all options are implemented
yet. There are other widgets like selection with buttons that has to
be developed (if we want backwards compatibility with the current UI).

> Some general remark: I very much like it as a replacement of the current UI
> for smartphones. But for tablets I would expect a different user
> experience: Having the sliding effect on a two column screen seems awkward
> and it is not clear what you would want to put in the left panel at all.

If it's only the sliding effect, I could make it fading like your
prototype or even make it user configurable.

> For a tablet, I prefer having the navigation on the left pane and the
> widgets on the central pane.

Yes. I saw your idea in your Sencha prototype. This is my vision too.

> Furthermore a toolbar is a nice thing for
> quick navigation (you could link each toolbar button to a sitemap), see the
> Sencha 1.0 prototype I had created:http://goo.gl/GpZ4H

You mean a bottom toolbar? I agree there would be nice to have one,
but I don't think it's a good idea to show buttons to the other
sitemaps. For me one sitemap is one user interface. I don't find logic
to switch between them anytime. Or I'm wrong? Maybe it's better idea
to group widgets by item types and show in this toolbar buttons that
link to these groups. For example "Statistics" will show all charts
from the pages, "Cameras" will show all camera streams, "HVAC" shows
all heating/ventilations and AC devices and so on. This is something
we have to think about carefully and discuss.

> May I ask why you didn't took my prototype (at least its concepts) as a
> basis, but rather started anew from scratch? Is this because the
> code/stylesheets are not reusable at all or because you are not convinced
> about the UX concepts I have tried to build into it?

Well, in fact I took some of the ideas there. But I haven't even tried
to reuse the code because I wanted to start it clean with Sencha 2 and
I'm not convinient with the MVC pattern.

[Kai Kreuzer]

>> Some general remark: I very much like it as a replacement of the current UI
>> for smartphones. But for tablets I would expect a different user
>> experience: Having the sliding effect on a two column screen seems awkward
>> and it is not clear what you would want to put in the left panel at all.
>
> If it's only the sliding effect, I could make it fading like your
> prototype or even make it user configurable.

I think the change only makes sense in the context of moving the whole
navigation over to the left pane. But once this is the case: yes I
would prefer the fading effect there. Also note that in my prototype,
there can be even more than two columns and the user can simply use
the "carousel".

>> For a tablet, I prefer having the navigation on the left pane and the
>> widgets on the central pane.
>
> Yes. I saw your idea in your Sencha prototype. This is my vision too.

Glad to hear :-)

>> Furthermore a toolbar is a nice thing for
>> quick navigation (you could link each toolbar button to a sitemap), see the
>> Sencha 1.0 prototype I had created:http://goo.gl/GpZ4H
>
> You mean a bottom toolbar?

Yes.

> I agree there would be nice to have one,
> but I don't think it's a good idea to show buttons to the other
> sitemaps. For me one sitemap is one user interface. I don't find logic
> to switch between them anytime. Or I'm wrong?

Yes, it's a matter of taste. I didn't think through the details yet,
but my idea was that you could somehow configure your tablet UI by
using different sitemaps and you are then more or less switching the
UIs, yes. The left navigation pane could be completely different for
each tab and also the content of it. You could imagine that you only
use the "rooms" sitemap on a smartphone, while also having the
"functions" sitemap available on the tablet.

The other option could be that you use the homepage of a sitemap to
determine the different tabs, e.g. one tab per frame on the homepage.
Could be a very valid solution as well.

> Maybe it's better idea
> to group widgets by item types and show in this toolbar buttons that
> link to these groups. For example "Statistics" will show all charts
> from the pages, "Cameras" will show all camera streams, "HVAC" shows
> all heating/ventilations and AC devices and so on.

I wouldn't try to do this automatically, the user/admin should be in
full control of the page definitions here. But doing the "frame"
approach from above, he could do so himself.

> This is something we have to think about carefully and discuss.

Agreed, that's why I started the discussion :-)

> Well, in fact I took some of the ideas there. But I haven't even tried
> to reuse the code because I wanted to start it clean with Sencha 2 and
> I'm not convinient with the MVC pattern.

That was possibly a wise decision as my code was really my first time
with Sencha and you can see this ;-) The point of it was mainly to
show my ideas for a new user experience and it's good to hear that we
are thinking along the same lines here.

Cheers,
Kai

[Mihail Panayotov]

> > If it's only the sliding effect, I could make it fading like your
> > prototype or even make it user configurable.
>
> I think the change only makes sense in the context of moving the whole
> navigation over to the left pane. But once this is the case: yes I
> would prefer the fading effect there. Also note that in my prototype,
> there can be even more than two columns and the user can simply use
> the "carousel".

The solution is simple as I see it. When the device is a phone and
there is no left panel with navigation, then then sliding effect is
applied. This would look natural in phones. When the device is a
tablet or a PC (left panel with navigation, two-column UI in landscape
mode), then the fade effect is applied. Sounds reasonable to me.

About the carousel. What exactly is your idea about it? I see you used
it in the Functions tab. How a user would specify which widget/frame
to which carousel page will go? Or the UI determines this itself by
some logic? Personally I don't see the need of additional carousel
navigation at this stage. I would like to see as much as I can on one
page and do things quickly, instead of sliding many pages with only
two frames with widgets on them. But this is just me, I would like to
know your vision too :-)

> > I agree there would be nice to have one,
> > but I don't think it's a good idea to show buttons to the other
> > sitemaps. For me one sitemap is one user interface. I don't find logic
> > to switch between them anytime. Or I'm wrong?
>
> Yes, it's a matter of taste. I didn't think through the details yet,
> but my idea was that you could somehow configure your tablet UI by
> using different sitemaps and you are then more or less switching the
> UIs, yes. The left navigation pane could be completely different for
> each tab and also the content of it. You could imagine that you only
> use the "rooms" sitemap on a smartphone, while also having the
> "functions" sitemap available on the tablet.

Yes, I see it now. Seems like a good approach to me too.

> The other option could be that you use the homepage of a sitemap to
> determine the different tabs, e.g. one tab per frame on the homepage.
> Could be a very valid solution as well.

This looks reasonable too. And for example only the first frame/tab is
visible by phones, but all are visible by tablets and PCs in the form
of bottom bar tab buttons?
But maybe a sitemap per tab would be more clear logic to the end user?
I will think about this on Christmas ;-)

> > Maybe it's better idea
> > to group widgets by item types and show in this toolbar buttons that
> > link to these groups. For example "Statistics" will show all charts
> > from the pages, "Cameras" will show all camera streams, "HVAC" shows
> > all heating/ventilations and AC devices and so on.
>
> I wouldn't try to do this automatically, the user/admin should be in
> full control of the page definitions here. But doing the "frame"
> approach from above, he could do so himself.

Yes, definitely agreed!

> That was possibly a wise decision as my code was really my first time
> with Sencha and you can see this ;-) The point of it was mainly to
> show my ideas for a new user experience and it's good to hear that we
> are thinking along the same lines here.

To be honest, this is my first Sencha app too :-) But I have some
experience with ExtJS as I worked on a project a couple of years ago,
and have experience with web technologies in general, as this is what
I do for living. My code is not pretty too. At this stage I do things
just to see what and how could be done more efficiently, then I will
think about code prettiness :-)

[Kai]

The solution is simple as I see it. When the device is a phone and
there is no left panel with navigation, then then sliding effect is
applied. This would look natural in phones. When the device is a
tablet or a PC (left panel with navigation, two-column UI in landscape
mode), then the fade effect is applied.

As mentioned before, it is not as easy as deciding what slide effect to use. The whole page appearance will be different - having the navigation separated means that there won't be any "Ground floor" link widget on the content pane anymore etc. Not sure if it is better to "filter" out any pure navigation widgets in the tablet layout, or if the user will construct sitemaps with all (most?) item widgets on the leaf nodes only.

About the carousel. What exactly is your idea about it? I see you used
it in the Functions tab.

Right, the function tab gives an example. It is simply a way to have more widgets on the content pane than what fits on the screen. You have the same today already, with the difference that the user has to scroll up and down and with my suggested carousel it would be right and left.

 

How a user would specify which widget/frame
to which carousel page will go? Or the UI determines this itself by
some logic?

How do you decide right now what goes into the first and the second column? Simply extend this logic to also be able to do a third, fourth and so forth column. Columns 3&4 would end up on carousel page 2, 5&6 on carousel page 3 etc.

 

 I would like to see as much as I can on one
page and do things quickly, instead of sliding many pages with only
two frames with widgets on them.

The carousel should not mean that the content pane stays rather empty because everything is distributed over many pages. As mentioned above, it is a way to be even quicker to access more content, if not everything fits on the screen. And the carousel is much quicker than having to navigate to another page.

 

At this stage I do things
just to see what and how could be done more efficiently, then I will
think about code prettiness :-)

Life should have told you that you will never find the time for the second step ;-)

 

[Mihail Panayotov]

> > The solution is simple as I see it. When the device is a phone and
> > there is no left panel with navigation, then then sliding effect is
> > applied. This would look natural in phones. When the device is a
> > tablet or a PC (left panel with navigation, two-column UI in landscape
> > mode), then the fade effect is applied.
>
> As mentioned before, it is not as easy as deciding what slide effect to
> use. The whole page appearance will be different - having the navigation
> separated means that there won't be any "Ground floor" link widget on the
> content pane anymore etc. Not sure if it is better to "filter" out any pure
> navigation widgets in the tablet layout, or if the user will construct
> sitemaps with all (most?) item widgets on the leaf nodes only.

Yes, I understand this very good. For me now it is pretty easily to
"extract" navigation items from the content and put them on the
navigation panel on the left (if the device is not a phone). I mean to
build the whole navigation tree with nested lists there. This will
work out of the box with the current sitemaps. If you have better
ideas, I would like to hear them.

> About the carousel. What exactly is your idea about it? I see you used
>
> > it in the Functions tab.
>
> Right, the function tab gives an example. It is simply a way to have more
> widgets on the content pane than what fits on the screen. You have the same
> today already, with the difference that the user has to scroll up and down
> and with my suggested carousel it would be right and left.
>
> > How a user would specify which widget/frame
> > to which carousel page will go? Or the UI determines this itself by
> > some logic?
>
> How do you decide right now what goes into the first and the second column?
> Simply extend this logic to also be able to do a third, fourth and so forth
> column. Columns 3&4 would end up on carousel page 2, 5&6 on carousel page 3
> etc.

Well, now I do it via simple CSS technique. I determine the kind of
the device and the orientation mode and apply the necessary styles.
The idea is this - for example you have 5 frames (I group widgets
without a frame to frames too, so everything is in frames). The first
frame is 4 rows height, the seconds is 1 row height, the third is 4
rows, the forth is 2 rows and the fifth frame is just 1 row. This is
what we have in the current layout:

-------------1----------- -----------2-------------
********************* *********************
********************* ------------3------------
********************* *********************
********************* *********************
-------------4----------- *********************
********************* *********************
********************* ------------5-------------
*********************

It's pretty much like the new Facebook Timeline concept. If we have
this splited to 3 carousel pages, they would look like this:

First page:

-------------1----------- -----------2-------------
********************* *********************
*********************
*********************
*********************

Second page:

------------3------------ -------------4-----------
********************* ********************
********************* ********************
*********************
*********************

Third page:

------------5-------------
*********************


Personally I find the carousel method pretty inefficient. In the first
method you see as much as the device is capable to see (the real
estate of the screen matters). If there is more content that the
device can't fit on one page, there is a scroll bar shown and the page
could scroll up and down.

> > At this stage I do things
> > just to see what and how could be done more efficiently, then I will
> > think about code prettiness :-)
>
> Life should have told you that you will never find the time for the second
> step ;-)

These words pretty much remembers me one of the my ex-girlfriends ;-)

[Mihail Panayotov]

I have done some more work today. You can see the updated demo here
http://m-design.bg/openhab_ui/

I build the left navigation panel and removed the navigation widgets
from the content. It's still not fully working and it's full of bugs,
but the ground is here and tomorrow is a day too :-)

As you can see I added a settings window. There the user could enter
the server address, the default sitemap, to specify what type of
device is this (phone, tablet or PC) and select an interface language.
The device type is recognized automatically, but there may be some
issues with that. For example a cheap china tablet with Android 2.2
has a really good chance to be recognized as a phone. So, I added the
option a user to specify the device type if it's not recognized right.

All these settings are kept in the device itself in a HTML5
LocalStorage, so they are per device settings.

Cheers... I go to drink :-)

[Kai Kreuzer]

Hi Mihail,

looks pretty good on the phone now, I have just tested it with my iPod (4th gen, retina).
On the iPad in contrast, it does not seem to work yet - the content pane is screwed up and nothing happens if I select something on the left navigation pane.
I have attached you some screenshots.

And now: Merry Christmas and take a (short) rest :-)
Kai

[Mihail Panayotov]

> looks pretty good on the phone now, I have just tested it with my iPod (4th gen, retina).

I'm realy happy to hear (read) that.

> On the iPad in contrast, it does not seem to work yet - the content pane is screwed up and nothing happens if I select something on the left navigation pane.
> I have attached you some screenshots.

Yes, I know. I've just "extracted" the navigation links from the
content and put them on the left list navigation. There is a lot more
work to be done before the tablet UI is useful. I just wanted to show
you some progress and to be sure we speak about same things.

>
> And now: Merry Christmas and take a (short) rest :-)

Merry Christmas to you too :-)

[Mihail Panayotov]

Some more work is done. The tablet UI now looks much more complete and
there is the IMAGE widget implemented. You can test it at the same URL
as before (it's in the first post).

About the image widget - I see you have tested a web camera with it
and your camera streams the images automatically. However this is not
my case with any of the live image streams I've tried. They need to
refresh manually. Also we could use the HTML5 video tag for video
streams. So, I think it is better to have different widget for images
and cameras. In the camera widget we have to specify what kind of
source it is, so the UI could determine what tag to use - IMG with
refreshing or VIDEO tag. What do you think?

[Kai Kreuzer]

> Some more work is done. The tablet UI now looks much more complete and
> there is the IMAGE widget implemented. You can test it at the same URL
> as before (it's in the first post).

Looks pretty good, I will do some tests soon and provide feedback.

> So, I think it is better to have different widget for images
> and cameras. In the camera widget we have to specify what kind of
> source it is, so the UI could determine what tag to use - IMG with
> refreshing or VIDEO tag. What do you think?

Agreed, I had the same idea as well. Nothing that I will squeeze into the 0.9.0 release, but it's definitely in for 1.0.0.
Fancy entering an issue?

Cheers,
Kai

[Mihail Panayotov]

> Agreed, I had the same idea as well. Nothing that I will squeeze into the 0.9.0 release, but it's definitely in for 1.0.0.
> Fancy entering an issue?

OK, I will.

One more thing I've just found - on Android devices the live stream
isn't shown at all, neither on your webapp, nor on mine. I will
investigate it, but I think this is due to lack of manual refresh. I
have a similar issue on Chrome when you go to the Widget Overview page
for second time. In Safari everything works just fine and 5 times
faster.

[Kai Kreuzer]

> One more thing I've just found - on Android devices the live stream
> isn't shown at all, neither on your webapp, nor on mine.

I just noticed that today on my new Galaxy Nexus as well :-(

> I will investigate it, but I think this is due to lack of manual refresh.

Or the Android browser does not support mjpeg streams at all. Although Wikipedia claims, that webkit browsers do...

> In Safari everything works just fine and 5 times faster.

Yeah, the whole UI works much better on iOS than on Android. Hope that Google will put some more efforts in improving this…

[Kai]

Works pretty well already, here is some feedback:

- not sure how you should best handle links on images (see the twitter image widget). You currently show the link in the left menu (with a broken image as none is defined) and the picture on the content pane. I think it would be nicer to do an exception in this case and leave the link on the picture itself, so that the content pane changes if the user selects the picture. What do you think?

- no right-alignment of states yet

- navigation pane might be a bit too narrow (see line breaks on the "Group Demo" page)

- alignments of label & states are not right - states are shown a few pixel further down

- The title bar behaves a bit strange in tablet mode: If you go to "first floor", it shows "First Floor" left and "Main Menu" right. If you then go to bathroom, you still have "First Floor" left, but "Main Menu > First Floor > Bathroom" right. I would suggest to completely remove the left part of the title bar (in tablet mode only; for phone mode, it is the only one available and working as expected).

- I do not like this default Sencha background green on an activated switch. I prefer some dark blue shade (as you can see in my tablet rototype).

- I somehow feel it unnatural to have the frames distributed across the columns horizontally first. I would prefer the filling to be done column per column (just like a newspaper). E.g. on the widget overview, I would expect the "Discrete Widgets" to be beneath the "Binary Widgets" as this is how it is displayed on a phone, and not besides them. This would then naturally lead to carousels, if there are more than 2 columns.

- It's not sending any commands yet, but I guess you know that already ;-)

[Mihail Panayotov]

> Works pretty well already, here is some feedback:
> - not sure how you should best handle links on images (see the twitter
> image widget). You currently show the link in the left menu (with a broken
> image as none is defined) and the picture on the content pane. I think it
> would be nicer to do an exception in this case and leave the link on the
> picture itself, so that the content pane changes if the user selects the
> picture. What do you think?

In fact I was thinking to have both - link on the picture and link in
the left menu. This way if you have more subgroups bellow the picture,
you will see it's further tree on the left pane. However I have some
troubles about this approach from technical level to make a logical
link between the two objects. I miss some Sencha nested list APIs :-)

> - no right-alignment of states yet

Yes, this one goes to the category of the final touches which I always
left to the end :-) But I'll do this today.

> - navigation pane might be a bit too narrow (see line breaks on the "Group
> Demo" page)

Unfortunately I can't predict the texts length users will use. I
better think about a more nice multi-row formatting of the buttons
there.

> - alignments of label & states are not right - states are shown a few pixel
> further down

This one is from the Sencha Framework. There are also many other tiny
issues. I guess they will polish the styles before the final release
of 2.0.

> - The title bar behaves a bit strange in tablet mode: If you go to "first
> floor", it shows "First Floor" left and "Main Menu" right. If you then go
> to bathroom, you still have "First Floor" left, but "Main Menu > First
> Floor > Bathroom" right. I would suggest to completely remove the left part
> of the title bar (in tablet mode only; for phone mode, it is the only one
> available and working as expected).

Yes. The left title is the title of the nested list. It shows the
current list (i.e. the current submenu). This may be different from
the current page you are. If you noticed, you can navigate through the
left pane without changing the current content page if there is no
content on the navigated pages. So, your left menu could point to a
different submenu than the current content page belongs. That's why
there are two titles there - one for the navigation, and one for the
content. I agree it could bring confusion, so I accept any suggestions
and ideas how we could better this.

> - I do not like this default Sencha background green on an activated
> switch. I prefer some dark blue shade (as you can see in my tablet
> rototype).

I am thinking about a whole template system instead. In fact I already
started to work on it. Later I will upload a new version of the UI and
you will see. I still think about the best way to bring themes to the
users and even more - to make them create their own themes and share
them with the other openHAB users if they want. The biggest problem is
to provide the necessary "framework" to create flexible, pretty, and
bullet-proof themes and not sacrifice mobile performance. This topic
has really HUGE potential and it's very important to the end users!

> - I somehow feel it unnatural to have the frames distributed across the
> columns horizontally first. I would prefer the filling to be done column
> per column (just like a newspaper). E.g. on the widget overview, I would
> expect the "Discrete Widgets" to be beneath the "Binary Widgets" as this is
> how it is displayed on a phone, and not besides them. This would then
> naturally lead to carousels, if there are more than 2 columns.

Yes, I understand your concerns. But I find it very difficult to be
done and not an optimal solution to use the screen space. It is
difficult because you never know on what device it will be seen. You
have to dynamically measure the screen real estate (and that's is
difficult too, because you have to take the screen DPI too and as far
as I know you can't do this with just web-technologies) and rebuild
not only the current page, but also all other horizontal carousel
pages on every change, for example on orientation change (because the
number of widgets that will fit is different from the landscape mode).
So far I do the layout by simply using some nice CSS techniques and
left the browser do the rest. However I will definitely think about
this layout, but so far I think it will bring more troubles than
benefits.

> - It's not sending any commands yet, but I guess you know that already ;-)

Yes, not reached that point yet. I wait for the PUSH technologies in
openHAB and I will make the communication at once as one of the send
methods is going to be websockets.

[Mihail Panayotov]

As promised, a new version of the UI is uploaded. All (known by me)
widgets are already there. Also the widgets are right-aligned, as we
have spoken. You can see the first steps in the themes support. It's
very far from completion, so don't judge the look... it's just a
changing background by now :-) I have something in my mind about the
"themes framework", but I have to read a little bit more before we
speak about this.

I wish to all the openHAB developers, contributors and users one
wonderful new year (let's hope it's not the last one ;-))! Cheers :-)

[Kai Kreuzer]

Thanks for the right alignment, that looks nicer indeed! But something got screwed up - the label now has only about 30% space of the widget while the status text has 70%, which cuts almost every label text.

I like your theme approach, if you find good places to hook for such themes, it can become a nice playground for web designers ;-)

Have a good start in 2012 as well!

> --
> 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.
>

[Kai]

> - It's not sending any commands yet, but I guess you know that already ;-)

Yes, not reached that point yet. I wait for the PUSH technologies in
openHAB and I will make the communication at once as one of the send
methods is going to be websockets.

In order not to block you on this, I have just merged Olivers websocket/comet implementation (see issue 56) into the default repo branch.

Note that I didn't really test it myself yet, but according to Oliver "You can use the REST API as before, but if you add the HTTP-Header "X-Atmosphere-Transport" the request will be suspended."

Let me know how it is working and best leave any problems directly as a comment on issue 56.

[Mihail Panayotov]

A new version is uploaded here - http://m-design.bg/openhab_ui/openHAB_touch.rar
Please, unrar and put the contents in <opeHAB_dir>/webapps/touch/
(actually it doesn't matter the last folder name).


CHANGES SINCE LAST VERSION:

1. No longer uses JSONP interface. Instead it uses regular AJAX calls.
JSONP was chosen because it's cross-domain and this allows the webapp
to be hosted separately from the openHAB core. This would make
possible to compile the webapp into a native mobile app for devices
that doesn't support webkit (e.g. Windows Phone 7). As JSONP was
dropped because of it's nasty drawbacks, websockets are going to be
supported and will be used for cross-domain communication.

2. The app now sends commands.

3. The app now refreshes widget's states real-time, without rebuilding
the whole page, using HTTP long-poll.

4. Many tiny bug-fixes and improvements.


Please, note this is just a developers preview. There are many bugs
that I'm aware of and probably there are many more which I don't know.
So, test it and report anything you see as wrong.

[Kai Kreuzer]

Thanks for this update, it seems to work pretty well already. Nice to see the server-push in action (although I do not like the reported OOM errors…)

I have one major concern: Although Sencha Touch 2.0 is supposed to be much better on the UI performance than version 1.0, it still feels a bit sluggish on iOS and VERY sluggish on Android. Even on a Nexus Galaxy with Android 4.0, it is no nice experience, have a look yourself: http://www.youtube.com/watch?v=j09bHYpoipk

Are you confident that the final version 2.0 will be any better than that?

Regards,

Kai

[Mihail Panayotov]

> I have one major concern: Although Sencha Touch 2.0 is supposed to be much better on the UI performance than version 1.0, it still feels a bit sluggish on iOS and VERY sluggish on Android. Even on a Nexus Galaxy with Android 4.0, it is no nice experience, have a look yourself:http://www.youtube.com/watch?v=j09bHYpoipk
>
> Are you confident that the final version 2.0 will be any better than that?

WOW, it's just awful... I test it on Galaxy S with Android 2.3.4 and
it is perfect. I have read that Sencha team complains about the
Android 3.0 and 4.0 browser, but I didn't thought it's that bad.
However they admit they have more work to do on Android UX, so I'm
pretty much confident they will make it look right for the final
release. Please, remember Sencha 2.0 is not even in alpha stage yet.

About the iOS, on what device you test and what iOS version. I test it
on iPhone 1-st gen with iOS 3.0 and beside the fact it's very slow
(it's 5 years old hardware), everything renders just fine. Could you
make a video for the iPhone UX too?

[Kai Kreuzer]

Could you make a video for the iPhone UX too?

Here you go:

iPhone 4S: http://www.youtube.com/watch?v=ntaGOCqlXHo

iPad2: http://www.youtube.com/watch?v=oRLGZog2jIA (sorry, its rotated…)

[Mihail Panayotov]

> Here you go:
> iPhone 4S:http://www.youtube.com/watch?v=ntaGOCqlXHo
> iPad2:http://www.youtube.com/watch?v=oRLGZog2jIA(sorry, its rotated…)

It's like a night and day compared to the Android 4.0 experience! I'm
really happy to see it behaves like this on iOS. It has some minor
issues, but they are due to me and will be fixed soon.
Meanwhile I have posted the Galaxy Nexus video to the Sencha forums,
hoping on some answers. You can see it here -
http://www.sencha.com/forum/showthread.php?173021-Android-4.0-ICS-user-experience
I hope you don't mind.

[Juanker Atina]

Coming back from holidays, happy new year¡

I've tried the sencha UI on Chrome (pc), iPhone 4 and Android 2.3.5
(on a HTC Desire HD) and it works pretty well (nice work there¡)

Some questions.

- It works well on android, not as well as iPhone, but it's ok.
Anyway, it's much better than on your videos, Kai.
- Cam images don't work on Android (i've read this before on this
thread)
- It would be great if you could make the item names more readables
(more visible text)
- Bulb icon doesn't change if i switch on the light, right?

I will test all UI with commands and send you some feedback.

Regards.

> hoping on some answers. You can see it here -http://www.sencha.com/forum/showthread.php?173021-Android-4.0-ICS-use...

[Kai Kreuzer]

> - Bulb icon doesn't change if i switch on the light, right?

This should work with the latest version, which sends commands, see my videos.

Regards,
Kai

P.S.: But Mihail, PLEASE remove this terrible green background color
on the switches asap! ;-)

[Mihail Panayotov]

> Coming back from holidays, happy new year¡
>
> I've tried the sencha UI on Chrome (pc), iPhone 4 and Android 2.3.5
> (on a HTC Desire HD) and it works pretty well (nice work there¡)

First, happy new year and thank you for these tests and feedback.

> Some questions.
>
> - It works well on android, not as well as iPhone, but it's ok.
> Anyway, it's much better than on your videos, Kai.

Unfortunately there is nothing I can do about this. Android OS seems
to be a little bit unfriendly to HTML5 apps using CSS3 animations.
Especially Android 3 and 4. Of course I have an idea how to workaround
this an bring the iPhone experience on Android, but first I have some
tests to do.

> - Cam images don't work on Android (i've read this before on this
> thread)

Same as above - nothing I can do about. It's all up to the browser (if
you open with Safari, it works like a charm). However in general you
don't want to play your CCTV cameras as images sequence, but as a
streaming video. That's why we will add support for streaming video in
a HTML5 video tag.

> - It would be great if you could make the item names more readables
> (more visible text)

Yes. I'll fix it soon.

> - Bulb icon doesn't change if i switch on the light, right?

Everything has to work if you use the latest version from here:
http://m-design.bg/openhab_ui/openHAB_touch.rar

> I will test all UI with commands and send you some feedback.

Thank you!

On 10 Ян, 19:28, Kai Kreuzer <k...@openHAB.org> wrote:
> P.S.: But Mihail, PLEASE remove this terrible green background color
> on the switches asap! ;-)

Kai, the idea of the template engine I want to create is to let
everyone create their own color scheme, so once it's ready you could
make whatever you want :-) But for now I will make it blue, as I see
green is definitely not your color ;-)

[Juanker Atina]

I've downloaded last version from this link http://m-design.bg/openhab_ui/openHAB_touch.rar

But it doesn't work. I can't set the server url and it returns a
server connection error.

Any idea?

[Kai Kreuzer]

Did you deploy it on the openHAB jetty (i.e. unrared it to
${openhab.home}/webapps/touch)?
You can then access it at http://localhost:8080/touch and it should work.

Quoting Juanker Atina <juan...@gmail.com>:

>> On 10 ??, 19:28, Kai Kreuzer <k...@openHAB.org> wrote:
>>
>> > P.S.: But Mihail, PLEASE remove this terrible green background color
>> > on the switches asap! ;-)
>>
>> Kai, the idea of the template engine I want to create is to let
>> everyone create their own color scheme, so once it's ready you could
>> make whatever you want :-) But for now I will make it blue, as I see
>> green is definitely not your color ;-)
>

[Juanker Atina]

Ok, it was my fault. Never mind.
I have some issues:

1. I'm working with two sitemaps at the same time:
1.a If i choose the second sitemap on startup, a server connection
error is prompted. However, it loads the sitemap.
1.b While working with the second sitemap, several server connection
occurs. Especially if i press the "back" button. However, all items
seem to work well. (note: i don't see these errors while working with
first sitemap)


2. I'm working with two devices at the same time (iPhone and Chrome
running on a PC)

I have six switches and i'm trying to change them on iPhone and see
changes on Chrome. First changes are well synchronized, but after a
while, the Chrome interface stop refreshing changes. Any thing i do on
iPhone is not refreshed on Chrome.

I'm going to try it with all my items in the same frame (i have
sixteen sensors) with real updates and commands from my setup. So i
will update this point.


3. Working with Groups on sitemap

I have defined a switch item to stop all group items at the same time:

Switch item=Light mappings=[OFF="Switch off all"]

It works fine (commands being sent) but it doesn't show the label,
while in the original UI i could see "switch off all".


4. Minor issues

As i said before, i think it will be better to have more space for the
item names. But i know it's a hard decision, as you could have text
items that would need space, too.

I have uploaded some screenshots of touch UI on my iPhone, you could
check the space problem there.


5. Spanish Translation
I know it's quite simple to translate right now :) but here you can
copy spanish translation

http://pastebin.com/JkwqLpLz



It's all i can see until now, but i will continue testing. Nice work
Mihail¡

On 11 ene, 12:29, Kai Kreuzer <k...@openHAB.org> wrote:
> Did you deploy it on the openHAB jetty (i.e. unrared it to
> ${openhab.home}/webapps/touch)?

> You can then access it athttp://localhost:8080/touchand it should work.

[Juanker Atina]

the three screenshots (i can't post imageshack urls here, um...)

http://goo.gl/GWL3D
http://goo.gl/i8Cd8
http://goo.gl/Nt46R

> > You can then access it athttp://localhost:8080/touchandit should work.

[Mihail Panayotov]

Hi Juanker, thank you for the review and the spanish translation :-)
I reply you from a phone and the answer will be short :-)


Some of the issues you mentioned (and these I see on the screenshots)
are known by me and will be fixed soon (3-4 days). I'm curious about
the problems with your sitemap. If it's not a problem for you, could
you send me this sitemap and the corresponding items file to my mail?

Thank you one more time for your comments.

[Mihail Panayotov]

------------------------------ NEW VERSION
--------------------------------

A new version is uploaded here - http://m-design.bg/openhab_ui/openHAB_touch.rar

----------------- CHANGES SINCE LAST VERSION ------------------

1. Widgets optimized for small screens with low resolution. If the
horizontal space is limited, some of the widgets can flow vertical as
needed. This is especially useful for texts and selections rendered as
buttons.
2. Many CSS tweaks for better user experience. (blue switches,
Kai ;-) )
3. Better group items handling. Now group items update their text
labels as well in the left navigation pane in "tablet mode". The title
is updated too. (there is a openHAB bug here that I will report now)
4. Reduced heap memory usage. However this bug stays -
http://www.sencha.com/forum/showthread.php?163757-PR3-leaves-some-Array-and-Object-data-on-item-removal
5. Bug fixes


Have a nice evening.

[Juanker Atina]

First impressions: nice¡

- Group items updates are great, i can see the counter growing as i
change the item status.
- Better texts, as there is more space for item names and item values
(specially text items, that flow vertical)
- Group buttons are rendered nice.
- Nice feeling on iphone (i must say that better than chrome).
- Spanish translation included ;)


Now some issues (with screenshots):

- Text items alignment: http://goo.gl/sAODQ

As you can see, the text aligment on chrome is a messy. Also the item
name (upper left).


- Item names space: http://goo.gl/tYUzc

I think it will be great if items names space could flow vertical, as
the item values do.

- Image items updates on chrome: http://goo.gl/bs5PI

Load page A (has a image item) >> it loads OK.
Navigate to page B (it doesn't matters wich one) >> OK
Go back from page B to page A >> won't load the image item

I can only see this behaviour on chrome.

- Synchronization between devices.

If i switch off all lights on iPhone (3 lights), i can only see one
off on chrome. The same on iPhone works great (switch off all lights
on Chrome, and all lights on Iphone will switch off).

If you navigate somewhere, the chrome unfreezes and updates all items.


Nice work Mihail¡

On 16 ene, 21:07, Mihail Panayotov <mishob...@gmail.com> wrote:
> ------------------------------ NEW VERSION
> --------------------------------
>

> A new version is uploaded here -http://m-design.bg/openhab_ui/openHAB_touch.rar

>
> ----------------- CHANGES SINCE LAST VERSION ------------------
>
> 1. Widgets optimized for small screens with low resolution. If the
> horizontal space is limited, some of the widgets can flow vertical as
> needed. This is especially useful for texts and selections rendered as
> buttons.
> 2. Many CSS tweaks for better user experience. (blue switches,
> Kai ;-) )
> 3. Better group items handling. Now group items update their text
> labels as well in the left navigation pane in "tablet mode". The title
> is updated too. (there is a openHAB bug here that I will report now)

> 4. Reduced heap memory usage. However this bug stays -http://www.sencha.com/forum/showthread.php?163757-PR3-leaves-some-Arr...

[Thomas Eichstädt-Engelen]

+1

On Jan 17, 2012, at 2:51 PM, Juanker Atina wrote:

Nice work Mihail

[Kai Kreuzer]

> (blue switches, Kai ;-) )

Thanks - I love it, what a nice color :-D

The UI is really in a very good shape already, well done, Mihail!

[Mihail Panayotov]

Hi Juanker, thank you for the great beta testing :-)

> - Image items updates on chrome: http://goo.gl/bs5PI

> Load page A (has a image item) >> it loads OK.
> Navigate to page B (it doesn't matters wich one) >> OK
> Go back from page B to page A >> won't load the image item

> I can only see this behaviour on chrome.

Yes, I'm aware of this behavior of Chrome. I have some ideas how to
workaround it.

> - Synchronization between devices.

> If i switch off all lights on iPhone (3 lights), i can only see one
> off on chrome. The same on iPhone works great (switch off all lights
> on Chrome, and all lights on Iphone will switch off).

> If you navigate somewhere, the chrome unfreezes and updates all items.

I think you speak about a group items behavior? If yes, please see
this Issue: http://code.google.com/p/openhab/issues/detail?id=62

[Thomas Eichstädt-Engelen]

Hi Mihail,

On Jan 16, 2012, at 9:07 PM, Mihail Panayotov wrote:

> ------------------------------ NEW VERSION
> --------------------------------
>
> A new version is uploaded here - http://m-design.bg/openhab_ui/openHAB_touch.rar
>
> ----------------- CHANGES SINCE LAST VERSION ------------------

could you please upload the current version as zip-Archive. I've set up a demo-server which is running a unix-distri without having an unrar-command.

Thanks,

Thomas E.-E.

[Kai Kreuzer]

Let us wait with putting on on the demo server until Sunday, when we
do the 0.9.0 release. You will then have it included in the openHAB
runtime distribution zip and won't have to worry about any additional
installations :-)

Quoting Thomas Eichstädt-Engelen <teic...@googlemail.com>:

[Thomas Eichstädt-Engelen]

On Jan 18, 2012, at 11:56 AM, Kai Kreuzer wrote:

Let us wait with putting on on the demo server until Sunday, when we do the 0.9.0 release.

ok!

[Mihail Panayotov]

------------------------ NEW VERSION ------------------------

A new version is uploaded here:
RAR - http://m-design.bg/openhab_ui/openHAB_touch.rar
ZIP - http://m-design.bg/openhab_ui/openHAB_touch.zip

----------------- CHANGES SINCE LAST VERSION ------------------

1. Fixed a bug for not showing linked images on phone mode
2. Widget labels now flow vertical as needed instead of cutting them
3. Images with subpages (linked images) now can be clicked in the
tablet mode too. If there is a further tree below them, the left
navigation displays it.
4. Major refactoring of the left navigation tree for tablet and
desktop mode. Now it behaves more logical, especially the Back button
logic.


Please test and report anything toy see suspicious. Have a nice
evening.

[Juanker Atina]

Thanks Mihail, i've been playing with it for a while and it looks
great.

Some issues :)

- Alignment, everywhere

It looks messy if you have some text items with different lengths. I
think that it will be great to have, IMHO:

a) Vertical aligment: center (in both, values and names).
b) Image wrapping: Item name shouldn't be around the image, they
should have separated columns. This way big text don't go below the
icon.

- Pop-up vertical placement on iPad

I've tested on an iPad (vertically) and the second pop-up menu (like
settings -> theme or settings -> language) appears very close on the
right.

- Tricky bug, changes on Group icon placed on left menu (only on
iPad).

I've seen that group icons placed on menu doesn't change (lights, for
example), but it only happens on iPad.

If i switch on one light, item icon and switch group item change, both
of them. But i can't see changes in group icon on left menu, even if i
refresh the page. It shows one light on (you know (1)), but icon
remains off.


Regards

On 18 ene, 19:24, Mihail Panayotov <mishob...@gmail.com> wrote:
> ------------------------ NEW VERSION ------------------------
>
> A new version is uploaded here:
> RAR -http://m-design.bg/openhab_ui/openHAB_touch.rar

> ZIP  -http://m-design.bg/openhab_ui/openHAB_touch.zip

[Juanker Atina]

Talking about charts and themes...

As i' ve read on issue 21 (http://code.google.com/p/openhab/issues/
detail?id=21)
---------------------------
5. org.openhab.ui.querydata ==> It also uses io.bddd bundle. Returns
all data in JSON or XML format.
- It works as a servlet, but it will be better to work as REST service
(not done).


To use the last bundle (to recover data), there are two services:


url = localhost:8080/query/alerts ==> It returns all traced events in
the last week (doesn't matter which item) ordered by date (it could
feed a "last alarms" service).
url = localhost:8080/query/events/itemname ==> It returns all traced
events in the last week for one specific item (it could feed a flot
graph, we will explain how to use it).
----------------------------

We could make a request to retrieve all events of one specific item,
in json or xml format. So it could be a nice way to play with sencha
charts.

http://www.sencha.com/products/touch/charts/

When do you plan to release this feature (persistence), Kai?


About themes, i've been playing for a while in the sencha kitchen
(http://dev.sencha.com/deploy/touch/examples/kitchensink/) and they
have a demo to switch between predefined themes (cupertino, mountain
view...), with source code attached to grab&use.

Is it hard to include it on this UI, Mihail? It could be a great place
to start with themes.


Regards.

[Kai Kreuzer]

> When do you plan to release this feature (persistence), Kai?

Very sorry for the delay on this, I haven't forgotten about it! At the
moment I am terribly busy getting 0.9.0 out of the door, that's why I
didn't find the time yet to come back to persistence.

Once 0.9.0 is released, the persistence is the next thing for me to
look at. I would also very much like to see results with Sencha Charts
and rrd4j as well.
But for making this framework flexible and reusable for different
charting engines and other use cases (see e.g.
http://code.google.com/p/openhab/issues/detail?id=48), I want to get
the API right, that means that I want to have some group discussions
before putting it into the product.

I definitely intend to have it ( + some charting engines) available in
openHAB 1.0 (which I currently see somewhere around May this year).

Regards,
Kai

[Mihail Panayotov]

-------------------- NEW VERSION ---------------------

A new version is uploaded here:

RAR - http://m-design.bg/openhab_ui/openHAB_touch.rar
ZIP - http://m-design.bg/openhab_ui/openHAB_touch.zip

----------------- CHANGES SINCE LAST VERSION ------------------

1. Fixed a bug with sitemaps load that sometimes shows "No server
connection" error.
2. Fixed a bug with the rollershutter widget under iOS.
3. Made the HTTPS obligatory. It's very important to encrypt the
connection when there is authentication, and in general it's important
this kind of software to work over encrypted connections. Otherwise
anyone could sniff the network and play with your home. It will throw
an error, telling that it is untrusted site. Click "Accept" with no
worries.
4. Added icon and splash screens. However I couldn't see a splash
screen on my iPhone with iOS 3.0. I can't see the splash of the
current openHAB webapp too. Somewhere I read splash screens must be
below 20-25K and the current splash is about 100K.

----------------------------------------------------------------------------------------

Juanker, thank you for the great review again.

> It looks messy if you have some text items with different lengths. I think that it will be great to have, IMHO:
>
> a) Vertical aligment: center (in both, values and names).
> b) Image wrapping: Item name shouldn't be around the image, they should have separated columns. This way big text don't go below the icon.

I agree. I will try to do it tomorrow, but I don't promise.

> - Pop-up vertical placement on iPad

This one is a Sencha issue. I will try to fix it however.

> I've seen that group icons placed on menu doesn't change (lights, for example), but it only happens on iPad.

This one is my fault. I will try to fix it tomorrow, but again - no
promise.


I don't know if I could work during the weekend and Kai wants to
release the 0.9 version on Sunday with this UI as alpha. Please, test
the latest version, so if there's anything more, let me know and I
will try my best to fix it by Sunday.

Have a nice evening.

[Kai Kreuzer]

3. Made the HTTPS obligatory. It's very important to encrypt the
connection when there is authentication, and in general it's important
this kind of software to work over encrypted connections. Otherwise
anyone could sniff the network and play with your home. It will throw
an error, telling that it is untrusted site. Click "Accept" with no
worries.

For demo purposes we usually run without security. Would be nice if there could be  some config you could do on the server side to always allow plain HTTP. No problem having HTTPS as the default setting though.

4. Added icon and splash screens. However I couldn't see a splash
screen on my iPhone with iOS 3.0. I can't see the splash of the
current openHAB webapp too. Somewhere I read splash screens must be
below 20-25K and the current splash is about 100K.

I have the same problem with the splashes with the current UI. Interestingly, the portrait one (http://openhab.googlecode.com/hg/distribution/openhabhome/webapps/images/splash-ipad-v.png) works on my iPad (although it is >250KB), while the landscape one isn't working. The small ones for the iPhone do not work either :-(

If you find a way to manipulate these pngs to be correctly accepted as splash screens, it would be perfect!

let me know and I will try my best to fix it by Sunday.

… by Sunday noon. Leave me some time to do the packaging :-)

Cheers,

Kai

[Juanker Atina]

...i'm so sorry Mihail, out of the office on weekends, so i can't try
anything until monday.

Monday morning i will review and send you all my feedback.

Regards.

On 21 ene, 00:39, Kai Kreuzer <k...@openHAB.org> wrote:
> > 3. Made the HTTPS obligatory. It's very important to encrypt the
> > connection when there is authentication, and in general it's important
> > this kind of software to work over encrypted connections. Otherwise
> > anyone could sniff the network and play with your home. It will throw
> > an error, telling that it is untrusted site. Click "Accept" with no
> > worries.
>
> For demo purposes we usually run without security. Would be nice if there could be  some config you could do on the server side to always allow plain HTTP. No problem having HTTPS as the default setting though.
>
> > 4. Added icon and splash screens. However I couldn't see a splash
> > screen on my iPhone with iOS 3.0. I can't see the splash of the
> > current openHAB webapp too. Somewhere I read splash screens must be
> > below 20-25K and the current splash is about 100K.
>

> I have the same problem with the splashes with the current UI. Interestingly, the portrait one (http://openhab.googlecode.com/hg/distribution/openhabhome/webapps/ima...) works on my iPad (although it is >250KB), while the landscape one isn't working. The small ones for the iPhone do not work either :-(

[Mihail Panayotov]

I left the security OFF for now. I wanted to make it configurable in
client-side as the other settings options are. But as I use HTML5
LocalStorage to store the settings values, there is no way to access
the local storage data for http://domain.com:8080 from https://domain.com:8443
and vise versa. This of course is made for security reasons. However I
think that letting the user to decide if he wants HTTPS or not on
client-side is not a smart thing. For me the HTTPS is more than
obligatory for this kind of software, especially when using
authentication, but if you want some kind of optioning, it could be
nice this to be related with the openHAB core configuration. For
example if the openHAB security option is ON, set the HTTPS in the
clients. A nice place for accessing this option is the future System
binding (http://code.google.com/p/openhab/issues/detail?id=20).

However the openHAB security option (authentication) and HTTPS are two
completely different things. So maybe a different option in the config
file is needed for HTTPS. But as I said, I wouldn't use this kind of
software over plain HTTP, especially on open public WiFi networks.

Regarding the splashes, I will make some tests today if there is a
little time left.

On Jan 21, 1:39 am, Kai Kreuzer <k...@openHAB.org> wrote:
> > 3. Made the HTTPS obligatory. It's very important to encrypt the
> > connection when there is authentication, and in general it's important
> > this kind of software to work over encrypted connections. Otherwise
> > anyone could sniff the network and play with your home. It will throw
> > an error, telling that it is untrusted site. Click "Accept" with no
> > worries.
>
> For demo purposes we usually run without security. Would be nice if there could be  some config you could do on the server side to always allow plain HTTP. No problem having HTTPS as the default setting though.
>
> > 4. Added icon and splash screens. However I couldn't see a splash
> > screen on my iPhone with iOS 3.0. I can't see the splash of the
> > current openHAB webapp too. Somewhere I read splash screens must be
> > below 20-25K and the current splash is about 100K.
>

> I have the same problem with the splashes with the current UI. Interestingly, the portrait one (http://openhab.googlecode.com/hg/distribution/openhabhome/webapps/ima...) works on my iPad (although it is >250KB), while the landscape one isn't working. The small ones for the iPhone do not work either :-(

[Mihail Panayotov]

-------------------- NEW VERSION ---------------------

A new version is uploaded here:
RAR - http://m-design.bg/openhab_ui/openHAB_touch.rar
ZIP - http://m-design.bg/openhab_ui/openHAB_touch.zip

----------------- CHANGES SINCE LAST VERSION ------------------

1. Removed the obligation to use HTTPS encrypted connection (see
previous posts).
2. Some CSS tweaks for better multi-row label alignment.
3. Fixed a bug with not changing the icon on group items value change.
4. Changed the title from "OpenHAB" to "openHAB"
5. Minified JS file. The file size reduction is about 51%.
6. Deleted some old, unused files.

[Juanker Atina]

Hi there,

I'm playing with volume and radio stations, and while volume works
fine on Classic UI (increasing and decreasing master volume), it
doesn't seem to work as well on Touch UI.

I have a dimmer item

Dimmer Volume "Volume [%.1f %%]"

Working as a slider on my sitemap

Slider item=Volume

Just like openhab demo. Touch UI shows it as a slider, while in
Classic UI i can see two button (up and down).

I also have a rule (drools) that increases and decreases volume, just
like openhab demo

if($event.getCommand().equals(IncreaseDecreaseType.INCREASE))
increaseMasterVolume(10);

but it doesn't work, as command never is IncreaseDecreaseType type.

However, this rule is working if used by Classic UI.


Any idea?

On 22 ene, 14:25, Mihail Panayotov <mishob...@gmail.com> wrote:
> -------------------- NEW VERSION ---------------------
>
> A new version is uploaded here:
> RAR -http://m-design.bg/openhab_ui/openHAB_touch.rar

> ZIP  -http://m-design.bg/openhab_ui/openHAB_touch.zip

[Kai Kreuzer]

> but it doesn't work, as command never is IncreaseDecreaseType type.
> However, this rule is working if used by Classic UI.
>
> Any idea?

Yes, as the Classic UI uses buttons, it sends INCREASE and DECREASE commands.
The Sencha Touch UI uses sliders instead and these sliders send a percentage value once you finish sliding it, i.e. you get a value between 0 and 100 as a command.

Your volume rule will have to deal with that. The demo rules (http://code.google.com/p/openhab/source/browse/distribution/openhabhome/configurations/rules/demo.rules) for the new rule engine do this:

if(receivedCommand instanceof PercentType) {
setMasterVolume(receivedCommand as PercentType)
} else {
if(receivedCommand==INCREASE) increaseMasterVolume(20)
if(receivedCommand==DECREASE) decreaseMasterVolume(20)
}

For Drools, you will have to adapt it yourself.

Regards,
Kai

[Juanker Atina]

Ok, no problem. I thought it was an item issue.

I will rewrite the drools rule and post here for your information.

Thanks¡

On 24 ene, 11:33, Kai Kreuzer <k...@openhab.org> wrote:
> > but it doesn't work, as command never is IncreaseDecreaseType type.
> > However, this rule is working if used by Classic UI.
>
> > Any idea?
>
> Yes, as the Classic UI uses buttons, it sends INCREASE and DECREASE commands.
> The Sencha Touch UI uses sliders instead and these sliders send a percentage value once you finish sliding it, i.e. you get a value between 0 and 100 as a command.
>

> Your volume rule will have to deal with that. The demo rules (http://code.google.com/p/openhab/source/browse/distribution/openhabho...) for the new rule engine do this:

[Juanker Atina]

As simple as this

rule "Volume"
when
$event : CommandEvent(itemName=="Volume")
then
setMasterVolume(Float.valueOf($event.getCommand().toString()) /
100);
end


Now working properly with slider on Touch UI

[Mihail Panayotov]

Just to tell some good news about the Sencha UI. The most significant
issues with this UI are already fixed:

1. Google seems to fixed the terrible Android 4.0 ICS browser issues
on animations (http://code.google.com/p/android/issues/detail?
id=24833). I hope soon there will be available the 4.0.3 version via
OTA for Galaxy Nexus. Kai, I will appreciate to test it when it's out.
2. Sencha fixed the "heap leak" bug (http://www.sencha.com/forum/
showthread.php?163757-PR3-leaves-some-Array-and-Object-data-on-item-
removal). openHAB Sencha UI is updated with the latest Sencha Touch
snapshot and I confirm this bug is no more there. This was the main
obstacle preventing the app from real use in real home environments.
3. I didn't stop working on the app since the 0.9 release, and many
bugs were identified and fixed. Some performance issues were solved
too. I think it is already near a production quality.

Probably next week I will upload a new version for beta testing. I
hope this issue (http://code.google.com/p/openhab/issues/detail?id=66)
is solved by then too.

Regards,
Mihail

[Kai Kreuzer]

Thanks for the update, looking forward to getting the OTA fix of ICS - will do the tests immediately afterwards!

Regards,
Kai

[Kai]

I thought you might be interested in the user experience on the new Chrome Beta for ICS:  http://www.youtube.com/watch?v=XAb1VtCn-Tk

Scrolling looks much better, not as smooth as iOS, but acceptable. And no strange transition effects on it.

But there seem to be still a few bugs - only half of the screen is used and the selection wheels do not really select what the user wants. Not sure if these are bugs of the Chrome beta or of the Sencha framework.

Regards,
Kai

[Mihail Panayotov]

-------------------- NEW VERSION ---------------------

A new version is uploaded here:

RAR - http://m-design.bg/openhab_ui/openHAB_touch.rar
ZIP - http://m-design.bg/openhab_ui/openHAB_touch.zip

----------------- CHANGES SINCE LAST VERSION ------------------

1. Updated to the latest Sencha Touch 2.0 nighty build (increased
stability and many major bug fixes)
2. Fixed a CSS style for phone mode group items
3. Smaller widget heights in phone mode
4. Added an option to disable transition animations (good for low-end
devices)
5. Made the app splash screens work
6. Many tweaks for bettering the user experience


Kai, with this release the app should behave OK on Android ICS Chrome.
Please, do some tests :)

[Kai]

Looks really promising on ICS, a HUGE step forward in comparison to before! But of course still buggy as you will see in my sample videos ;-)

The standard ICS browser now seems to work pretty well - I wonder why, because I am still on 4.0.2 (and the fix you mentioned before is in 4.0.3), see

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

ICS Chrome Beta is similar, although not quite as smooth, and shows some other defects: http://www.youtube.com/watch?v=f6vk-FcvuWc.

Sorry for the poor picture quality, but I cannot film my Galaxy Nexus with my Galaxy Nexus ;-)

[Mihail Panayotov]

Thanks for the videos, Kai. They are in great benefit for me. Looks
relatively good, but there are still no smooth transitions on the
stock ICS browser (4.0.3 solves this problem).


I noticed that after some fast page switching, buttons are no more
active. This happened to me too on Android 2.3. I can't reproduce this
bug neither on iOS, or Windows Chrome and Windows Safari.
Unfortunately the Android browser is a black box and is really a pain
for debugging. Do you know if ICS Chrome has some debuging tools?

[Kai Kreuzer]

> Do you know if ICS Chrome has some debuging tools?

Yes, it comes with a remote debugging feature through USB:
http://whatisandroidphone.org/chrome-beta-for-android-brings-debugging-tools-to-mobile-web-developers/

[Mihail Panayotov]

Nice! Seems I'm going to flash my Galaxy S with some ICS ROM.

On Feb 23, 11:03 am, Kai Kreuzer <k...@openHAB.org> wrote:
> > Do you know if ICS Chrome has some debuging tools?
>

> Yes, it comes with a remote debugging feature through USB:http://whatisandroidphone.org/chrome-beta-for-android-brings-debuggin...

[Mihail Panayotov]

I have upgraded to Android 4.0.3 and the app works like a charm on the
stock browser. The only negative issue I've found is that there is a
big waiting time between clicking on some group item and starting the
page transition animation. I hope this will be resolved soon, as it is
clearly a big Android issue. On Chrome Beta, everything is even
better. However there is this bug of not triggering group button
actions after some page transitions, but I'm going to work on it. In
general the app already seems stable enough on iOS, Android 2.3 and
Android 4.0 devices.

You can expect a new version of the Sencha Touch UI next week.