I‘m currently working on a web based administration for openhab. It will be based on https://cockpit-project.org/
My intention for this (as an system administrator) was to allow standard users to maintain their openHAB server from any mobile or pc browser without the need for technical knowledge.
There is still a lot of work left but it has already a lot of cool things by default. Like network management, update management log inspection and an web based terminal.
Beside i developed already a service and Branch management to switch between stable, test and milestone builds. As next i will implement a log viewer and a web based backup functionality.
Have you considered integrating your interface with openHABian rather than to reinvent the wheel ? It already does all of that and much more on CLI. All it is missing is a web frontend.
That’s essentially because our focus is on functionality and noone has built any so far. See this open issue.
@mstormi yes i thought about this. It was a quite hard decision because it would be really easy just to call the CLI for this.
But there are two arguments against this.
The CLI is not able to give me the current configuration. So i have to query this anyway. Or is this possible with the CLI?
I want to keep a better linux support. At the moment all debian based systems with apt are supported.
It would be great to merge the CLI and the cockpit to avoid duplicate work. But at the moment i don’t see how we could achieve this. Do you have an idea?
I don’t fully understand that question. It’s working stateless so there is no need to store any “current configuration”.
Install routines are “twin mode” capable: you (as a user) can run them in interactive mode, but we have put substantial efforts into recently that you can also run them in unattended mode.
That is what is used during unattended install as a big batch but you can also call them one by one.
In that case the routines take their input from /etc/openhabian.conf (which is just another bash input file that gets sourced on startup, effectively setting all parameters as env variables).
So if you want to you can use that as a config storage to store your web input to.
When you want to trigger a routine from the web, you can pass arguments by setting env variables.
On Linux support, what’s your point ? We support all debian systems, too. It’s running on x86.
There’s restrictions that not every function and 3rd party tool works on every system, but that is mostly
because of hardware related and other low level stuff like e.g. kernel modules.
It’s a lot of work to develop and mature code and to test against various HW and OS variants.
And it’s even a hell of a LOT more efforts that need to go into supporting users.
You must do that if you want them to keep using your tool. Please don’t underestimate that.
Have a benevolent look at the openHABian code please to find out if you can integrate it with your cockpit and let’s join forces.
cc @ndye
@mstormi I was not aware that the openhabian is also supported on other debian based systems. Then I will definitively use openhabian for this.
I have to say great work from your side thank you for this. This will make my life much easier.
There are just two questions left on my side, maybe you can help me here as a starting and i will figure out the other stuff then.
I run as a test the command “sudo openhabian-config unattended nano_openhab_syntax” on a ubuntu 20.04 based system where i installed openhabian from github short before. I would expect that this will run the nano package for openhab. But this triggered a full installation. Hostname etc are changed and there was also some downgrade of OH3 to OH2 with java 8 installation. I think I’m making something wrong on calling the CLI. Can you advise?
Has the openhabian-CLI also a parameter to show the current configuration of the system like “sudo openhabian-config unattended status samba_setup” to display the current state of this package. So output would be e.g. “configured” or “not configured” or in best case some detailed config output.
On a Webpage I find it quite important to show the user the current config so that he is aware what he changes. If this is not possible I will check your bash files to figure out how to read the current state. (Updating the state I will definitively relay on the openhabian-CLI.
You must not run the main script. It only has a single parameter (unattended) that’s why it started full installation.
Create a stub script, copy the relevant initialization part from /opt/openhabian/openhabian-setup.sh (line 77 to source the other scripts, essentially) then call the routine you want from there.
Include the debugmode part, setting that will show you every command that’ll help developing.
No. There’s a number of places in the code to check this, though.
See helpers.bash for a number of available checkers plus openhab.bash for is_openhabX_installed()
I’d suggest you create is_XXX_installed() bash routines for every major component you want to display state for (it does not really make sense for every menu option).
Look for ‘dpkg -s’ in the code it checks if a debian pkg is installed, configured and active. Eventually additionally check for some file or config line that openHABian creates when it installs a component to be sure it was done by openHABian and not just the pkg from the OS installation.
Thanks again for your help. I will try your advise the next days and if I‘m successful I can share a fist beta version if you are interested how this will look.
I had the same mind like you. I thought webmin would be perfect for this. But webmin is for sysadmins and at the end to complex for a normal user. A web page must be self explained to be accepted by normal users.
And the development of custom plugins in webmin is not possible for me. I have no knowledge in php.
Cockpit runs on react with javascript and server side code is called with a predefined api.
@mstormi so I was able to run the first commands with the openhabian-cli. Thanks for this. It is woking great whn you knwo how to use it
At the moment there is still a lot missing. But the branch management, service details and also a log viewer is already included. If you are interested you can already have look at it.
I uploaded my current work and installation instructions here:
@mstormi so just a small status update if you are interested.
The whole “Apply improvments” section is already included. It was so easy due to the openhabian-cli. It is great.
Additionally the tool has now an integrated update functionality to check on page load for updates and inform the user. So there is no need for a manual update.
thanks I will have a look at the contribution guide. At the moment I think an integration is to early. I will probably create a new forum post in some days to introduce the new ui. This is still a minimal version with less features than on openhabian at the moment. Also it needs some more testing to keep quality up.
When the ui is then stable enough for an integration we need to think about how to realize this. Probably it makes sense to keep this in another repo and just add some bash functions to the openhabian menu and unattended mode so that this feature can be installed as well and is maybe a default component on new openhabian installations.
It does not make sense and will only confuse users if you release it as a standalone tool in the first place then move over to openHABian. That’ll also be more work than to build it as an openHABian extension right from the beginning.
So do you want this to become part of openHABian or not?
I agree with Marcus. If you start out with it being separate it is going to be frustrating for users when you finally do add it to openHABian. Not only is it jarring but it can cause them a bunch of extra work. If you can start with it integrated with openHABian from the start then it’s much easier to transition from the testing version to the released version.
From this perspective I agree with both of you. A later migration to another repo might confuse some users. I think I have enough features integrated for a first pull request. Just need to do some cleanup.
If I have openHAB2 and openHAB3 installed on the same system. What is the best way to check if openHABian is currently configured to control openHAB2 or openHAB3?
At the moment I check if openHAB2 is installed. If not openHAB3 will be used. But this is a bad implementation and needs to be changed. Probably I could ask git which openHABian branch is currently used. But I’m wondering if there is a better approach to check this?
