Even after reinstalling, I get the same Mysql-Problem - so it doesn’t seem openhabian-related…
But I could not get a karaf-connection so far.
How do you start it?
Michael
If your are on the machine (direct or via ssh):
sudo /usr/share/openhab2/runtime/karaf/bin/client
In this case, please open a new thread and a savior will present himself 
@peter_juenger already gave one right answer. Two other ways:
-
on the machine:
ssh openhab@localhost -p 8101(password:habopen) -
my personal favorite, allowing connections from all interfaces:
sed -e "s/sshHost = 127.0.0.1/sshHost = 0.0.0.0/g" /usr/share/openhab2/runtime/karaf/etc/org.apache.karaf.shell.cfg systemctl restart openhab2.serviceand then logging in via ssh from my local machine (I just realized that this could be part of the openHABian setup)
FYI: install time on Pi3:
Installation finished at Thu Sep 1 10:29:23 UTC 2016 and took 21 min 55 sec (1315 seconds) UI started to work around 8 Mins later
1 Like
Update: your currently installed openHAB version will be shown right when you log in (new installs).
I did not want to miss out answering you on that. When building openHABian, I payed close attention to create an installation and setup routine that - after some testing - can also be independently executed on a normal x86/x64 system (debian/ubuntu). A few steps are still missing to make that a real possibility but it’s on the right track. I will need some more time to refactor a few parts and to build an interactive menu around all of it.
Hi @ThomDietrich,
I just did an openHABian installation. Everything went fine (RPi3), installation time about 15min.
One small comment: I couldn’t open the Portal with the described http://openhabianpi.local:8080, I had to use (just like mentioned in the official docs): http://openhabianpi:8080.
Don’t know if this is a local problem with my environment. In fact, it isn’t much of a problem…But maybe worth to be mentioned…
Regards,
Stefan
Hey @jaydee73,
15 minutes, WOW that’s a nice downlink i suspect 
Local DNS is a pain in the ass to make generalized assertions. From what I know (please correct me if I’m wrong): If there is a dns domain for your subnet, it is provided by your router or interpreted by your operating system. While Windows previously supported the special .local domain, this seems to change. Nowadays usage of .local seems to be the less accepted choice in home subnets. I’ll update the guide to a url without .local. Thanks for pointing that out.
On a side note: I’m a bit old fashioned and always work with IP addresses 
One more question: In the official documentation I can read something about a demo sitemap. But I couldn’t get that demo sitemap started. Isn’t it included in your installation or am I not capable of choosing it?!
Thanks for image !! I´m a Vera/MIOS user evaluating alernatives, including Openhab2.
I´ve just burnt the image, everything seems ok, except the Mios Binding (I´ve configured it with my Vera’s IP) not working and the COMETVISU UI that is not starting … Could it be a problem with the Install feature ?
Thx
Hello @yokokito, problems with openHAB internally (like with bindings) are most probably not openHABian related. Can you please open a new thread in the openHAB 2 category? Good luck!
@jaydee73 how to switch to the demo sitemap is documented here I however would stay with standard and only look at the demo when needed. I have written something about that before:
@ThomDietrich, great idea and execution! Just wondering if you’ve heard about the new https://www.raspberrypi.org/blog/pibakery/ automatic Raspian image development tool? Any thoughts on using that to pre-build the image, including your auto configuration tools? Might make it quicker/easier to maintain, and keep the Raspian releases up to date, as well.
Hey @bartus, I read about it yesterday yes Basically they are doing the same thing as I am doing, just in a graphical way instead of a script file. While this is probably nicer for the end user and for easy steps like preconfiguring Wifi, I see no benefits for the openHABian project in general. Setting everything up is a manageable but long process and doing this in a shell script seems to me the better (because more flexible) approach.
Another aspect: I’m currently in the process of making the scripts more modular. By that it should be possible to use the same logic in your Raspberry Pi setup as well as on a normal Linux (e.g. Ubuntu) installation or in a Virtual Machine. There will even be an interactive menu with optional components ready to install and set up. As you can see, openHABian goes way beyond what PiBakery aims to offer
As it is Stark Trek anniversary day today:
…to boldly go where no man has gone before…
1 Like
Ah yes, keeping it platform-independent is clearly a better idea. Looking forward to using this when I finally make the full switch over to OH2. Thanks again!
1 Like
Hi @ThomDietrich , I’ve been working on something similar for the past few weeks (for OH1), but with a slight different approach (and more specific orientated towards z-wave).
The idea I followed was to propose an image of a completely configured installation. So for an hassle free installation interested people could just download the image and have a working configuration for their PI.
The image is much bigger than yours (3GB) but the time spent for the installation is only for downloading the image and burning it on the SD card. After that, the only thing to be done is plug in the PI and it is running.
So my question, what advantages do you see with your approach compared to the one described above?
Hey @Vincent,
sure thing:
Transparency, openHABian is a Raspbian installation PLUS a clear set of changes every user can work through and understand. I personally would hesitate to install a modified system without being sure about the details. No offense!
Ease of development, The git repository with a few Kilobytes of size is all you need to build the image AND configure the setup process. Changes to the setup are immediately available to users installing a fresh system or as upgrades. No need to build, test and upload a 3GB file…
Ease of usage, Downloading and flashing a 64MB file (directly from GitHub) is quicker and easier. After that, the installation will in return take a few minutes more but in the end it adds up to more or less the same time.
Modularity/Scalability, the openHABian setup script can soon be executed in an interactive menu-driven mode that allows to set up systems beside a Raspberry Pi (PC, VM, …) or providing optional components (like zwave, homegear, knx, mqtt,…)
That said, I like your motivation to work on such a project. Would you be interested in contributing? As I am personally not a zwave user (which has quite a significance nowadays) I would like to know which packages and or settings you would include in an automated setup process!?
1 Like
Hey,
I would absolutely be interested to contribute, but let me first put forward a few arguments of my own:
Transparency : you’re right that one should know what is included in the system. The image I would propose would not so have a modified system, but rather have some modules included (oh, habmin, samba, …) and other modules not included compared to the default installation of Jessie (like the educational packages, or the games). This could be clearly described.
Ease of usage : I think both methods are quite easy
Ease of development : This is clearly in favour of your proposed method.
Modularity : If you can propose this of course, it would be a great advantage.
The only thing I have been struggeling with during the past weeks, is the (classic) installation process itself, were when you had to ‘apt-get’, some installations didn’t succeed, and I had to start all over again (meaning a lot of time wasted). So I thought : give a user the image and he has working PI even without any Linux knowledge.
Maybe it is possible even to propose both ways (for very specific implementations). So a potential user could choose between a working PI without even having to look at it, or a modular installation where he can play with.
What, in my opinion is really important, is an easy wifi set-up, since in the PI 3 the hardware is included. (I don’t know if you have this included already).
So, till now I have been looking at OH1 (since I wanted to propose something combined with the charting solution), and for the moment I have a working configuration which includes (just from memory):
- hamin : needed for z-wave in openhab
- razberry : needed for the controller of the razberry hardware (card plugged onto the PI)
I could give you a much more detailed description (tomorrow) of the installation process (for example : the razberry server has to be stopped in order for habmin to work).
How do you propose to proceed ?
These are a few good points, let me clarify a bit more.
openHABian does that. You download an image, flash it to your sd card and after a few minutes there is a fully working openHAB 2 installation with all the latest versions and preconfigurations ready to use. You could connect to your samba share and the openHAB web pages and start configuring and using your openHAB instance without connecting via ssh once. So to make that clear: the result is exactly the same as with your proposed solution.
If you were to make an image of your sd card after your Raspberry Pi finished booting openHABian for the first time, you would have exactly what you are asking for. An image of a preconfigured Raspbian. 
But why would you even want that? Package versions are going to get old and a 3GB image is harder to transfer and store than a 64MB one.
I already have it working in beta testing, probably gonna release it this evening after some more tweaking
Good point. Are we talking wifi setup before or after first boot? Both are possible I guess but that’s currently not on my todo list as I would recommend an Ethernet connection for 24/7 utilization.
OH1 is not included in openHABian and as it is going to be outdated soon, I’ll probably not bother adding it anymore. Is your charting solution also compatible with openHAB 2? Would be great to integrate your described steps as one optional component.
Yes this sounds good to me. You could provide a Pull Request but it’s probably easier to just send me the steps needed to get your ideas integrated in a new issue, just like this one. Thanks for your effort!
Ok. I will give you a description on github tomorrow. I can even test it if you like.
For the moment the charting was only ready for OH1, with the intention to propose it in OH2 if there is interest.
And concerning the wifi. Personally I have only one ethernet cable available for the moment so wifi would be a plus. And since the hardware is standard included in PI3 it would be a pity not to include this.
The problem with wifi is that the user has to enter his personal configuration to make this work (name, password), which for obvious reasons one can not provide in a standard installation. I was still struggling to find the optimal way to provide this :
- A user can connect with screen and keyboard to the PI to enter this (standard on PI).
- A user can connect with ethernet and login the PI to enter the details (basic use of linux)
- Probably the best way I thought was to provide (develop) some kind of webaccess to allow the user to configure this (without to much hassle)