HomeGenie in Linux is still running on startup with the old init script system when you install first. We need to change this startup process to reflect the Systemd service which has taken over from the init script system and is fully implemented in Debian and Stretch. This shouldn’t be a major issue to implement and the Systemd service is a lot more efficient anyway. Bounz you could probably amend the Linux installation files to reflect this.
if you tell us what needs doing then we can do this… or submit a pr, I can get by in Linux but Windows is my area of expertise… and hg isn’t great as a Windows service either tbh
This is an example of creating a Systemd HomeGenie service on startup. First you need to create the startup file.
sudo nano /etc/systemd/system/homegenie.service
Just copy and paste the text below and save the file.
[Unit]
Description=HomeGenie Automation Server
After=network.target
[Service]
WorkingDirectory=/usr/local/bin/homegenie
ExecStart=/usr/bin/mono /usr/local/bin/homegenie/HomeGenie.exe --log
ExecStop=/usr/local/bin/homegenie/homegenie/homegenie_stop.sh
Restart=always
TimeoutStopSec=90
[Install]
WantedBy=multi-user.target
Now you need to enable the service. Type the following command
sudo systemctl enable homegenie.service
Now you need to start the service. Type the following command
sudo systemctl start homegenie.service
To stop the service type
sudo systemctl stop homegenie.service
To check if the service is running type
sudo systemctl status homegenie.service
This was run on a Raspberry Pi and working directories can vary with each flavour of Linux. You can start/stop various other processes needed for HomeGenie in this file and add delays for loading network resources etc.
I really do suggest if there are any other Linux users on the forum they pitch in and help with this. This example is just basic to show how Systemd in Jessie and Stretch has replaced the current way HomeGenie is loaded on boot. As I said previously the boot files are based around Wheezy and earlier
Its worth reading up on Systemd before proceeding with any changes to the HomeGenie boot method in Linux. I’m not a Windows user but can use Windows and I would not run a HA program on Windows. This is just a personal choice.
3 Likes
The Debian guys are not known for rushing into anything, but I found references of init.d being depreciated prior to 2011. Most of the built in packages still use init.d. However, I have been seeing addon packages use systemctl in a two step install. This allows the user to test run a package before committing to it as a service. A user need not back peddle on packages with conflicts. An example is NodeRed, first released in 2013. NodeRed is distributed as Linux agnostic. With all the variants of Linux, using systenctl is a wise second step to ensure a smooth integration.
r526.tar will install on Raspbian x86 and runs OK. However, the .tar installation goes into the current directory. Unlike the RPi version that goes into /user/local/bin. So, one, HG does not automatically start as a service; two systemctl would be the expected norm as a way to automate start up in the wider Linux platform.
I hope my point is made correctly. The technical merits of init.d vs. systemctl is not the issue. Meeting user expectations is of greater importance. Raspberry Pi unit sales are in the millions now. I don’t have hard data to support, but it appears that RPi and HA are a popular choice. Sadly, between Hackster.io, RasberryPi.org, Instructables, I must see 5-6 adhoc HA projects a day, that could really use HomeGenie.
Last weekend I was working on docker distribution of HG and wrote a number of scripts to make installation as easy as one command line. Installation script checks that docker is installed on the target system and install it if not, asks the user about installation folder (/usr/local/bin/hgbe by default right now), downloads and installs systemd unit description file and start/stop scripts and pulls the latest docker image of HG. Then the user is able to control HG service using systemctl start/stop commands.
As it’s still work in progress you can try it on RPi (or any other ARM platform as I didn’t make x86 image yet):
wget -qO- https://raw.githubusercontent.com/Bounz/HomeGenie-BE/master/Utils/HgBootstrapper/installer.sh | bash
After installation completes you should be able to access HG interface on port 8090.
I tried it with clean installation of Raspbian stretch and it worked fine (but it took really much time on my old RPi 2).
Again, it’s still work in progress, because we need to move all settings and data files away from binaries, and after that, it would be possible to safely update docker installation of HG.
The main advantage of using docker in this case is that user don’t have to deal with all that problems with mono versions, certificate issues and so on. Everything is encapsulated into the docker image.
You are planning on a non docker version too? otherwise I think I might draw a line in the sand at this point.
There is no difference, Docker is just a delivery option. No one stops you from a) using .zip distribution and create service manually, b) use .deb package, c) whatever else (standalone installation scripts, ansible playbooks, etc).
Answering your question - yes, at least you will always have .zip archive with the latest binaries (I’m not sure about Debian package as I don’t see benefits using it).
Btw, what are your cons about the Docker?
Thats cool, so long as there is no difference then thats cool…
I’m not bothered for a .deb either more hassle than its worth.
My ‘issues’ with docker are more that I have a working system currently that I am happy with and dont really want to change tech or add latency unnesarrily - if It was going to deviate from something that works for me and is reliable then I would probably look again about a move to loxone.
Dont get me wrong I will take a look at testing the docker route… but I dont have the time currently 
For reference this is what I currently have within my home:
David,
Your scheme looks really impressive!
If all your systems are up and running - then the new way of distribution should not be very important to you, but for newcomers, it may be useful. We have a lot of posts here on the forum with discussions of different mono versions on different OSes along with a bunch of installation scripts that handles dependencies needed to run HG.
Creating docker image should help to solve these issues, but as I wrote earlier - it’s just another option 
No, I 100% agree with the docker route for 99% of people - but I also think automating the process of building a downloadable img might also be beneficial too as the thought of configuring everything may also put people off.
Yes 10 minutes work for a noob to download an image and image it to an SD card would make most sense. Majority of HA people are running on Raspberry Pi anyway. Wouldn’t get too technical with the details though. Tends to put newcomers off.
1 Like