Ha-bridge: echo unable to discover devices when daemon launched by rc.local

Created on 1 Aug 2016  路  10Comments  路  Source: bwssytems/ha-bridge

I've been struggling with diagnosing this problem on my own for two days, so I thought I would run this question by the repo.

Currently running v3.0.0 from the JAR on a Raspberry Pi - I am unable to get any devices to be discovered by the Echo if the JAR is launched automatically though rc.local:

nohup java -jar /home/pi/echobridge/ha-bridge-3.0.0.jar 2>&1 &

Everything works as expected if I run the service on my default pi user manually like so:

java -jar /home/pi/echobridge/ha-bridge-3.0.0.jar

Following another question posted on the ha-bridge Issues related the rc.local file, I have tried some other things such as attempting to run the command as a different user (non-root) to no avail.

Does anyone out there have any recommendations or logging tips that would help me get closer to finding a root cause?

Thank you!

question

Most helpful comment

Alright, now my memory has been jogged on this issue with the pi.

So, this has come up before as people were using the rc.local and calling a script and it would not work. This is due to the way network subsystem is brought up on the pi as it uses the new systemctl to start services. The old style runlevel setup, which rc.local is part of does not get the benefit if knowing the network is fully realized. Use the instructions in the readme file to do this using the unit files as it has the dependency check for network. Otherwise, put a sleep for 40 seconds or see (YMMV) in your rc.local before you call your shell script.

All 10 comments

The command

nohup java -jar /home/pi/echobridge/ha-bridge-3.0.0.jar 2>&1 &

is exactly what I use. Did you set where your db file is located in the Bridge Control tab? My guess is the database of devices you created when run using the command line method is not being loaded when it runs as root using the rc.local method since permissions/paths are relative to user.

@audiofreak9

Thanks for the reply. I did indeed set "Configuration Path and File" and "Device DB Path and File" to full path locations:

/home/pi/echobridge/data/habridge.config
/home/pi/echobridge/data/device.db

I have even tried launching the service with the optional param:

-Dconfig.file=/home/pi/echobridge/data/habridge.config

Also verified that the device.db and habridge.config file do exist in this directory and UPNP IP address is pointing to the correct location.

When run using the rc.local method, can you see and edit the configured devices in the bridge?

@audiofreak9

Yes, all my configurations are there and appear correct.

Additionally, when comparing the log tails between A. Launched by rc.local VS B. Launched by myself I can find nothing different between the two visually.

Maybe you should explore this auto startup method explained by BWS Systems https://github.com/bwssytems/ha-bridge#automation-on-linux-systems

@audiofreak9

Unfortunately I have already tried. My rc.local is currently running ./starthabridge as my default home user like so:

su -l -c "./starthabridge.sh" pi &

This produces the same result..

So, I need to see your configuration file, your startup script and your log output. It seems somewhere along the line it is not getting the proper IP address in one of the configurations for UPNP.

@bwssytems

Thank you for your time, below is the output requested. It should be noted that I have since changed my method of startup from nohp to attempting to launch ./starthabridge.sh as the local pi user. This produced no notable change in behavior.

habridge.config:

{"upnpconfigaddress":"192.168.1.117","serverport":8080,"upnpresponseport":50000,"upnpdevicedb":"/home/pi/echobridge/data/device.db","buttonsleep":100,"upnpstrict":true,"traceupnp":false,"veraconfigured":false,"harmonyconfigured":false,"nestconfigured":false,"farenheit":true,"configfile":"/home/pi/echobridge/data/habridge.config","numberoflogmessages":512,"hueconfigured":false,"halconfigured":false,"settingsChanged":false}

rc.local:

_IP=$(hostname -I) || true
if [ "$_IP" ]; then
printf "My IP address is %s\n" "$_IP"
fi
su -l -c "./starthabridge.sh" pi &
su -l -c "heyu start" pi &
exit 0

starthabridge.sh:

cd /home/pi/echobridge
rm /home/pi/echobridge/habridge-log.txt
nohup java -jar -Dconfig.file=/home/pi/echobridge/data/habridge.config /home/pi/echobridge/ha-bridge-3.0.0.jar > /home/pi/echobridge/habridge-log.txt 2>&1 &
chmod 777 /home/pi/echobridge/habridge-log.txt

habridge-log.txt (LAUNCHED FROM RC.LOCAL):

2016-08-02 10:11:01,166 [main] INFO  com.bwssystems.HABridge.HABridge - HA Bridge (v3.0.0) starting....
2016-08-02 10:11:01,222 [main] INFO  com.bwssystems.HABridge.BridgeSettings - reading from config file: /home/pi/echobridge/data/habridge.config
2016-08-02 10:11:01,730 [main] INFO  com.bwssystems.HABridge.HABridge - HA Bridge (v3.0.0) initializing....
2016-08-02 10:11:01,829 [main] INFO  com.bwssystems.HABridge.SystemControl - System control service started....
2016-08-02 10:11:02,561 [main] INFO  com.bwssystems.HABridge.devicemanagmeent.DeviceResource - HABridge device management service started....
2016-08-02 10:11:02.559:INFO::Thread-0: Logging initialized @5100ms
2016-08-02 10:11:03,204 [Thread-0] INFO  spark.webserver.JettySparkServer - == Spark has ignited ...
2016-08-02 10:11:03,216 [Thread-0] INFO  spark.webserver.JettySparkServer - >> Listening on 0.0.0.0:8080
2016-08-02 10:11:03.234:INFO:oejs.Server:Thread-0: jetty-9.3.z-SNAPSHOT
2016-08-02 10:11:03.524:INFO:oejs.ServerConnector:Thread-0: Started ServerConnector@12b5b3d{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}
2016-08-02 10:11:03.529:INFO:oejs.Server:Thread-0: Started @6122ms
2016-08-02 10:11:04,684 [main] INFO  com.bwssystems.HABridge.hue.HueMulator - Hue emulator service started....
2016-08-02 10:11:04,755 [main] INFO  com.bwssystems.HABridge.upnp.UpnpSettingsResource - Hue description service started....
2016-08-02 10:11:04,772 [main] INFO  com.bwssystems.HABridge.upnp.UpnpListener - UPNP Discovery Listener starting....
2016-08-02 10:11:04,807 [main] INFO  com.bwssystems.HABridge.upnp.UpnpListener - UPNP Discovery Listener running and ready....

habridge-log.txt (LAUNCHED MANUALLY FROM COMMAND LINE):

2016-08-02 10:11:01,166 [main] INFO  com.bwssystems.HABridge.HABridge - HA Bridge (v3.0.0) starting....
2016-08-02 10:11:01,222 [main] INFO  com.bwssystems.HABridge.BridgeSettings - reading from config file: /home/pi/echobridge/data/habridge.config
2016-08-02 10:11:01,730 [main] INFO  com.bwssystems.HABridge.HABridge - HA Bridge (v3.0.0) initializing....
2016-08-02 10:11:01,829 [main] INFO  com.bwssystems.HABridge.SystemControl - System control service started....
2016-08-02 10:11:02,561 [main] INFO  com.bwssystems.HABridge.devicemanagmeent.DeviceResource - HABridge device management service started....
2016-08-02 10:11:02.559:INFO::Thread-0: Logging initialized @5100ms
2016-08-02 10:11:03,204 [Thread-0] INFO  spark.webserver.JettySparkServer - == Spark has ignited ...
2016-08-02 10:11:03,216 [Thread-0] INFO  spark.webserver.JettySparkServer - >> Listening on 0.0.0.0:8080
2016-08-02 10:11:03.234:INFO:oejs.Server:Thread-0: jetty-9.3.z-SNAPSHOT
2016-08-02 10:11:03.524:INFO:oejs.ServerConnector:Thread-0: Started ServerConnector@12b5b3d{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}
2016-08-02 10:11:03.529:INFO:oejs.Server:Thread-0: Started @6122ms
2016-08-02 10:11:04,684 [main] INFO  com.bwssystems.HABridge.hue.HueMulator - Hue emulator service started....
2016-08-02 10:11:04,755 [main] INFO  com.bwssystems.HABridge.upnp.UpnpSettingsResource - Hue description service started....
2016-08-02 10:11:04,772 [main] INFO  com.bwssystems.HABridge.upnp.UpnpListener - UPNP Discovery Listener starting....
2016-08-02 10:11:04,807 [main] INFO  com.bwssystems.HABridge.upnp.UpnpListener - UPNP Discovery Listener running and ready....

Alright, now my memory has been jogged on this issue with the pi.

So, this has come up before as people were using the rc.local and calling a script and it would not work. This is due to the way network subsystem is brought up on the pi as it uses the new systemctl to start services. The old style runlevel setup, which rc.local is part of does not get the benefit if knowing the network is fully realized. Use the instructions in the readme file to do this using the unit files as it has the dependency check for network. Otherwise, put a sleep for 40 seconds or see (YMMV) in your rc.local before you call your shell script.

I just confirmed that abandoning rc.local and moving to registering a custom systemctl service in /etc/systemd/system worked!

Here was the final result of my habridge.service file:

[Unit]
Description=HA Bridge
Wants=network.target
After=network.target

[Service]
Type=simple
ExecStart=/usr/lib/jvm/jdk-8-oracle-arm32-vfp-hflt/bin/java -jar -Dconfig.file=$

[Install]
WantedBy=multi-user.target

This was enabled by using:

sudo systemctl daemon-reload
sudo systemctl enable habridge.service

Cheers and many thanks @bwssytems

Was this page helpful?
0 / 5 - 0 ratings

Related issues

pattont picture pattont  路  5Comments

rmohsenn picture rmohsenn  路  5Comments

sanderlv picture sanderlv  路  15Comments

memojo picture memojo  路  10Comments

smanig picture smanig  路  7Comments