I have tried multiple approaches to get HG and HA Bridge to start on reboot and every time HA-Bridge tries to start as an enabled service, it fails to find port 80. If I log in to command line as PI after reboot, HA-Bridge will start with no issues on port 80. HG starts fine every time on port 8090.
The log shows homegenie started, then trying to start HA Bridge but failing on port 80, then seemingly finding the listener is not working? Eventually closing HA Bridge.
I even changed the name of the HA Bridge service to zha-bridge.service as I read somewhere the services were started in alphabetic name, but that made no apparent difference.
Dec 14 14:08:35 raspberrypi homegenie[364]: homegenie started.
Dec 14 14:08:35 raspberrypi dhcpcd-run-hooks[457]: wlan0: starting wpa_supplicant
Dec 14 14:08:35 raspberrypi systemd[1]: Started Login Service.
Dec 14 14:08:35 raspberrypi systemd[1]: Started WPA supplicant.
Dec 14 14:08:35 raspberrypi systemd[1]: Started LSB: Run HomeGenie.
Dec 14 14:08:35 raspberrypi systemd[1]: Reached target Network.
Dec 14 14:08:35 raspberrypi systemd[1]: Started HA Bridge.
Dec 14 14:08:39 raspberrypi java[472]: 2020-12-14 14:08:39,497 [Thread-0] ERROR com.bwssystems.HABridge.HABridge - Could not start ha-bridge webservice on port [80] due to: Cannot assign requested address
Dec 14 14:08:39 raspberrypi java[472]: 2020-12-14 14:08:39,499 [Thread-0] WARN com.bwssystems.HABridge.SystemControl - Error pinging listener. Network is unreachable (sendto failed)
Dec 14 14:08:39 raspberrypi java[472]: 2020-12-14 14:08:39,503 [Thread-0] WARN com.bwssystems.HABridge.HABridge - {“control”:“stopping”}
Dec 14 14:08:39 raspberrypi java[472]: 2020-12-14 14:08:39,526 [main] INFO com.bwssystems.HABridge.upnp.UpnpSettingsResource - Description xml service started…
Dec 14 14:08:39 raspberrypi java[472]: 2020-12-14 14:08:39,539 [main] WARN com.bwssystems.HABridge.upnp.UpnpListener - UPNP Listener exiting as reinit or stop requested…
Dec 14 14:08:39 raspberrypi java[472]: 2020-12-14 14:08:39,539 [main] INFO com.bwssystems.HABridge.HABridge - Going to close all homes
I am familiar with similar tools but not specifically systemd. I need to understand how to do exactly what you suggest, start one service before the other intentionally. I thought I read that systemd decides to do them alphabetically which is why I renamed the HA Bridge service zha-bridge.service, but that made no difference. How do I force one to start before the other?
Yes, I created a simple shutdown script to run before poweroff.
#!/bin/sh
Since these 2 programs actually run independently of each other, I thought starting HG first was the best order, then HA. Obviously HA uses HG to complete the calls/commands, but it runs independently. Manually, I can start/stop either one in either order and they both work fine. It was just at reboot where it seems like port 80 isn’t available at the moment HA wants to use it?
Assuming you have nothing else installed on your RPI other than HG and HA Bridge there’s no reason why HA Bridge won’t start on port 80 other than the fact that when HG starts first it will always check the availability of port 80 even though it’s redirected to a different port. Possible collision between the two services.
That’s why I suggest putting a sleep instruction into your HG service file to ensure HA Bridge is fully up and running before HG attempts to start.
I’ve always started HA-Bridge first as it requires port 80 to work correctly with Alexa and have had no problems.
Since HG checks port 80 availability first I suspect the pi os isn’t releasing port 80 before HA-Bridge tries to use it.
If you really wish to load HG first do as @Petediscrete suggests it should work, it makes for a slower load (however not by much)
A 30 second sleep command as I suggested. That can be adjusted accordingly depending on the users preferences.
HG polls all available ports starting at port 80. Depending on port response speed HA Bridge will see this port interrogation as port 80 in use and will shutdown its processes.
I don’t use HA Bridge but as it’s a server it will act as any other server. Adjustments can be made to its service daemon to reflect possible conflicts in a similar way to HG service daemon.
OK, so I can appreciate starting HA first and have no problem doing that, but from what you guys are saying, the ONLY apparent way to force this is to introduce the HG delay into the .service. I did some more investigations and this seems to be the way to force dependencies rather than try delay techniques. I will give it a try. Thanks for your input.
Copy the file to /etc/systemd/system and perform the modifications on the copy. This file will completely override the file in /usr/lib.
Create the file /etc/systemd/system/smb.service.d/local.conf. The contents of the file should be something like the example below. This selectively overrides the “Requires” and “After” options in the vendor provided service file.
Each of these (including modifying the file in /usr/lib) offers advantages and disadvantages. The best choice may depend on the service and the nature of the modifications.
While it may work, it is not sufficient to only add the “After” option (see [Unit] Section Options). “After” controls order, but not dependencies. If dirsrv.target is not started in some other way, specifying an order will not start it. Use of the “Requires” or “Wants” option will force dirsrv.target to be started.
The main objective is to get the HA Bridge up and running on port 80 prior to any other service attempting to access it while its not in use. You can assign a port in the HG UI but HG is known to grab the next available port. If port 80 is not available that’s your issue resolved.
There are many ways to achieve this. In fact both of the services could be launched from one single service daemon.
If you haven’t already examined the contents of the HG service daemon I suggest you do so. You can tailor it to your own requirements. The HA Bridge service daemon is quite basic and can also be adapted to your own needs.
Either way once both services are behaving as they should you’ve achieved your goal.
Pete, I have been searching in vain for the homegenie.service daemon and cannot find it in the normal locations! I know it has to be somewhere because I can still stop/start it with systemctl, but I’ve been looking in all the normal locations /etc/systemd/system, usr/local/bin/homegenie and I simply don’t see it. Not sure what happened. I don’t recall actually creating it so I am assuming it was done during the standard install. systemctl status shows this, but it hasn’t helped me locate the .service???
What I don’t quite understand however is how the systemctl works to start a .service file called homegenie.service when I don’t find that service either in /usr/local/bin/homegenie/ or anywhere else? I don’t know how to edit the homegenie.service object if I can’t find it?
ls -ltr on /usr/local/bin/homegenie/ shows no symbolic link to a homegenie.service file anywhere. What directory should I be looking for the actual homegenie.service file in?
I am missing something very basic and it really irritates me that I can’t find the answer. Appreciate your help.
Pete, I’m not quite sure why you sent me to an explanation of how systemd works and the systemctl commands that are available. That does not really help explain where the homegenie.service file is located.
I’ve poured over many threads trying to understand where the .service file is including a response you posted here. I’ve looked in this location and I currently can’t find my homegenie.service file there. My files are listed at the end of this entry…
In order to start HomeGenie automatically each time we need to create a homeseer.service file
sudo nano /etc/systemd/system/homegenie.service
This brings you into the Raspbian file editor. Just copy/paste the following onto the top line of the screen
[Unit]
Description=Homegenie Server
After=network.target
Pete, nevermind I found the homegenie.service under /run/systemd/generator.late/homegenie.service. Not sure how it got here and if I can remove it or move it. Your article above did nothing to identify this location…
I wasn’t posting that link to identity the location of your service daemon. I was purely pointing to how the HG author constructed his service daemon with the forerunner of systemd.
HG is now 7 years old but retained the old service daemon file system
A much simpler Systemd service file could be deployed to launch HG. I’m sure you’ll figure it out yourself.
But Pete, that wasn’t an answer to my basic question What directory should I be looking for the actual homegenie.service file in? Answering that basic question with “I don’t know” would have been more productive to start with.
Regardless, I now understand that the current installation of HG creates a file in /etc/init.d/ named homegenie. In the current version of the Rasberian PI OS, if no specific homegenie.service file is found in the normal locations like /etc/systemd/system or /usr/local/lib/systemd/system the systemd will auto-generate a homegenie.service file and place it into /run/systemd/generator.late/ on EVERY REBOOT. This means it can be found by systemctl for start/stop purposes, but it gets recreated each time the OS is rebooted.
Now if you happen to follow one of the many threads on this site or others that suggest creating your own homegenie.service in /etc/systemd/system/ like Petediscrete suggested in the past, then your copy would override any systemd generated copy of homegenie.service that might exist in /run/systemd/generator.late/
Be aware: There is also a hierarchy of which directory gets looked at first so if you ended up with 2 copies of homegenie.service, one in /etc/systemd/system and one in /usr/local/lib/systemd/system, the one in /etc/systemd/system would take precedence.