Some thoughts about OpenHAB

[GoogleCodeExporter]

Hi, guys. Just installed OpenHAB and I'm testing it now (without any gear, I 
will order some KNX stuff next week).

It's pretty nice piece of software with HUGE potential. However this is what it 
misses for my opinion:

1. Web-based configuration and administration. Users are not programmers and 
making rules and configuring interfaces must be done in a nice and easy way. A 
nice ajax based UI is essential.

2. About clients - now there is a web-client optimized for iPhone. It follows 
the iPhone's user experience. However this approach is very limiting. It would 
be nice to position and resize the widgets and use own pictures for states 
(ON/OFF, sliders, etc.). Take a look at OpenRemote - it's very close to what 
you're doing, except their strength is in UI design and yours is the rules 
logic and the speed of development.

3. In my opnion you only need ONE client and it has to be web-based. Use Sencha 
for example, it's pretty nice framework. Make it possible the user to build his 
own flexible design just by drag and drop and editing parameters. IT HAS TO BE 
VERY FLEXIBLE! Then wrap it via PhoneGap or another software that compiles 
HTML5 and JavaScript apps to native mobile apps for iPhone, iPad, Android, 
Symbian, Windows Mobile and so on. This way you have one codebase, one client 
to maintain, but you obtain all major mobile platforms and reach the app stores.

Just my 2 cents :)

However, one more time - it's pretty nice software and with some shiny Admin UI 
and powerful interface builder for mobile clients, it has really huge potential 
to be one of the best (if not the best) HA projects out there.

Original issue reported on code.google.com by mishoboss on 28 Mar 2011 at 3:08

[GoogleCodeExporter]

Hi, thanks a lot for your feedback, this is very valuable to us.

Let me try to briefly answer your points:

1. The aim of the openHAB designer is to be user friendly - but also to allow 
expert users to be productive. Hence it concentrates on text files for 
configuration, but brings IDE support like syntax checks and auto-completion. A 
user that knows about KNX group addresses can't be that techno-phobic anyhow ;-)
But I agree with you, to really reach all potential users (that possibly have 
simpler systems than KNX), a web UI could offer an even lower entry level.

2. Your might have seen that I had a very detailed look at OpenRemote even 
before I started the openHAB project (see 
http://kaikreuzer.blogspot.com/2010/02/positioning-openhab.html). And yes, I 
decided to put the focus on the server/integration/automation part instead of 
the UI. I prefered to have a decent UI that works well for many cases but with 
as little setup efforts as possible. Having to use a hosted online UI design 
tool and clicking around with the mouse for every single widget (as in 
OpenRemote) and then in the end seeing that the export is just not working at 
the moment drove me nuts... So rather less flexibility, but quick results and 
no dependency on an external "cloud"-service.

3. Think early 2010, when I started the project. There wasn't much around like 
Sencha, PhoneGap etc. I actually did a test of an early Sencha beta version on 
my iPod (1st gen) and it was many times slower and less smooth than the WebApp 
framework. The mobile UI technologies (and devices!) are evolving so fast that 
I think it was a good strategy to design openHAB in a way that you can build 
different UIs on top; so although one technology might be enough at some point 
in time, you might want to change this technology sooner or later. So again my 
focus on the server side meant here that I didn't want to try building the 
fanciest UI+designer myself - I rather considered building a bridging-bundle 
for OpenRemote (or any other UI projects that are out there) so that their UI 
designer could also be used for openHAB.

I have taken the freedom and changed the issue type from "feature" to "other". 
If you want to join in and implement a shiny admin UI for openHAB right away, 
I'll of course change it back immediately :-)

Original comment by kai.openhab on 28 Mar 2011 at 4:33

• Added labels: Type-Other
• Removed labels: Type-Feature

[GoogleCodeExporter]

Hi, Kai, I remember you from the OpenRemote forums. I have also been one of 
participiants in the discussions and even modified some code to work with my 
Arduino project. I'm actually one of the persons in the OpenRemote discussion 
about Arduino you point in on the blog - Mihail Panayotov.

I'm like you very dissapointed about the OpenRemote project. It has really huge 
potential to be really great HA software. However it evolves very slow and the 
rule engine is still in the TODO list. If you merge somehow the two projects, 
it will be really nice.

About the UI builder. OpenRemote has many mistakes in that scope. I don't like 
the "cloud" approach too - import, export, sync and broken XML. The better 
approach is what you have done. However I still think a web admin is more than 
neccesary. It just has to read and write to the configuration files, without 
installing a special GUI software for that. Imagine you want to run openHAB on 
SheevaPlug or another plug computer or FritzBox or anything else that don't 
have GUI and monitor attached. Right now you can't or you have to copy the 
configuration folder, make changes and upload it again (I do it this way right 
now).

At least think about more flexible UI design via config files. Right now you 
have one widget per row. It is decent design for small screen devices, but it's 
ugly and space wasting design for tablets. Think about adding parameters like 
X, Y, Width, Height, background images. It's not neccesary to make drag and 
drop and shiny UI builder, text editor is just fine (for now), but make it 
capable of bilding more advanced UI designs. 

Original comment by mishoboss on 28 Mar 2011 at 8:27

[GoogleCodeExporter]

About the proposal of making the shiny UI, it is exactly what I do. The only 
thing is that Java is not my favorite labnguage and may have some troubles. 
However I have pretty good expirience in PHP, JavaScript, CSS and JS frameworks 
like ExtJS (Sencha is in fact reworked ExtJS for touchscreens). So, if  I have 
some free time (and this is exactly what I don't have right now), I will start 
developing such an interface for openHAB. 

Original comment by mishoboss on 28 Mar 2011 at 8:54

[GoogleCodeExporter]

Hi Mihail,
You are right, the remote access is a weak point for the moment, especially for 
embedded devices. For the moment, I open the config folder as a network share 
(or possibly via ftp) and then use the designer directly on this share so that 
I do not have to copy config files around.
So offering the config files in an editor on the web would solve this, but it 
is not at all user friendly (no IDE support anymore etc.) And there are many 
different files to edit, so you would need a directory browser there as well.
I was already considering to offer some built-in remote access to the 
configuration directory, which could then be used by the designer to access a 
remote host. But this has not yet been of any priority to me.

You are absolutely right about the limited flexibility of the row-based UI 
approach. I just noticed that I didn't clearly mention this on the homepage 
yet, only the roadmap (http://code.google.com/p/openhab/wiki/Roadmap) says a 
sentence about this: The current UI is only meant for smartphones, I agree that 
the space of a PC-browser or a tablet screen is not used efficiently at all. So 
for these use cases I plan to build a second, Sencha-based UI. I have actually 
just ordered an iPad 2, so I will soon require the new UI for it :-)
So if your experience is on the UI framework side, it would be great if we 
could cooperate on this new UI - I am all for it. I have just entered issue 24 
to work on this.

Original comment by kai.openhab on 29 Mar 2011 at 7:56

[GoogleCodeExporter]

Hi, Kai. Let me think about the Admin UI. I think there's a way to make it 
web-based, but also to check for syntax errors. Yes, it would need directory 
browser. However I don't imagine it like regular directory tree with dirs and 
files to edit. It has to make logical sense to the user in the home automation 
scope. 

Give me some days to complete the project I'm working on and I'll make some 
research and think about this.

Original comment by mishoboss on 29 Mar 2011 at 9:55

[GoogleCodeExporter]

Ok, thanks!

Original comment by xthirtyn...@gmail.com on 29 Mar 2011 at 10:20

[GoogleCodeExporter]

I can't stop thinking, even I have a lot of work to do ;)

I was thinking why you choose that data-model for the sitemap files? Maybe 
because it's native C syntax and Eclipse can do syntax checks and formats it 
nicely. However I think it's not optimal for parsing.

What about JSON? It's very easy parsable with JavaScript and Sechna/ExtJS can 
feed it's components directly with JSON data. It would make the hard things 
less hard and building the UI and UI builder will be a lot easier. And I think 
JSON is more understandable for non-programmers too. What you say?

Original comment by mishoboss on 29 Mar 2011 at 11:50

[GoogleCodeExporter]

I don't think you're gonna succeed in syntax checks for a web-based editor.
The data-model is a DSL, the parser automatically created by Xtext - so in 
Java, the content is directly available as an EMF model. The only chance I 
might see to get a web-based syntax check is to use GWT for it, but I am new to 
that.

So as a quick solution, I only see a standard text editor as an option.

Original comment by xthirtyn...@gmail.com on 29 Mar 2011 at 12:50

[GoogleCodeExporter]

the eclipse orion project could be a solution as well 
(http://www.developer.com/open/eclipse-launches-orion-browser-based-web-developm
ent-tool.html).

We could simply deliver the "complete openHAB-ide" as plugin (veeeery simply 
spoken). Don't know if that is possible, but it could be worth thinking about.

If i understood the project correctly there are searching for real world 
usecases ... :-)

Original comment by teichsta on 29 Mar 2011 at 12:58

[GoogleCodeExporter]

As far as I understood Orion, it is built from grounds up and in no way 
compatible to any existing (IDE addon) plugins.
But I could imagine that the Xtext guys are looking at implementing Orion 
support for Xtext, so maybe this becomes available some when in the future. But 
I am afraid that a SheevaPlug might be a bit overloaded to run Orion on it just 
for openHAB configuration....

Original comment by xthirtyn...@gmail.com on 29 Mar 2011 at 1:10

[GoogleCodeExporter]

< But I am afraid that a SheevaPlug might be a bit overloaded 
< to run Orion on it just for openHAB configuration....

sounds like a good argument ;-)

Original comment by teichsta on 29 Mar 2011 at 1:14

[GoogleCodeExporter]

< But I am afraid that a SheevaPlug might be a bit overloaded 
< to run Orion on it just for openHAB configuration....

Yes, always keep in mind that openHAB could run on small embedded devices with 
limited resources.

That's exactly why I see the structure you use now as not optimal for parsing 
and generating JavaScript UIs. Maybe in the Java world it is a nice structure, 
but mobile UIs are gonna be written in JavaScript and HTML5. So I think a 
lightweight and JavaScript native structure is preferable here.

Do you know this - http://www.appcelerator.com ?
It's pretty interesting thing. It's something like PhoneGAP. It worth a try.

Original comment by mishoboss on 29 Mar 2011 at 3:16

[GoogleCodeExporter]

Remember that openHAB tries to scrictly separate the core from the UI (in 
contrast to e.g. OpenRemote) - the core is OSGi/Java and I do not want any JS 
or HTML leaking into it.
After all, the items and sitemaps can all be served through OSGi services; so 
other "configuration tools" are free to edit and store configurations however 
they like and just serve the result through an OSGi service to the openHAB 
runtime.

Yes, I have heard of appcelerator, but didn't have a closer look at it yet.

Original comment by kai.openhab on 29 Mar 2011 at 3:45

[GoogleCodeExporter]

That said, I have to agree with you. So, you keep the core pure Java, don't 
allow another app to read/write directly config files, and you provide REST 
services (for example) that can interact with the core and read/write to the 
config files. Looks this is the right way of doing it.

Original comment by mishoboss on 29 Mar 2011 at 6:45

[GoogleCodeExporter]

Closing this issue. The idea about adding access to the config files through 
REST will be persued in issue 25.

Original comment by kai.openhab on 17 Aug 2011 at 8:43

• Changed state: Rejected
• Removed labels: Version-later