openLuup email server

[ArcherS]

I noticed this morning something that have seen in the past but forgotten about.

When I restart the OpenLuup server (in my case an Ubuntu PC) the Vera and Z-way bridges do not get in contact with the corresponding servers, i.e. are shown in red in AltUI. The solution for me is to make a "Relaod Luup engine" and then they are ok. I do not know if it is a general issue or only for my setup.

To be honest it is not much of a problem since OpenLuup is so stable. If and when you restart the server the hazzle of reloading is not that big. In fact I had forgotten about it since it was so long ago I had to restart anything...

The one use case I can think of is that the server gets restarted due to a power outage or something and if you are not at home the system does not fully recover without manual interaction. I my case I have the server on an UPS, but still a thought.

Is this a known issue and is it something that can be addressed somehow? As I said low priority, at least for me.

[akbooer]

Thanks for reporting that. This usually depends on how, and when, your boot code runs openLuup. If the network is not available, or Vera is still down, then it will fail. I never put a retry in to attempt a later connection. Just delaying the startup may help in your case.

[rafale77]

@archers

It's a timing issue. I suppose you are running the z-way-server on the same ubuntu PC as openLuup? If that's the case I think you are auto starting the two servers are services?
The way I handled mine has been to make openLuup start with a z-way-server dependency. z-way-server takes a little bit more time to start than openLuup so it is likely than openLuup is trying to poll z-way through the bridge before the bridge is up. If you need help to set the systemd dependency, let me know. I have my machine start in this order: z-way-server -> openLuup -> habridge & HomeKitbridge.

[ArcherS]

@rafale77 Thanks! In my case the Z-way server is on a Raspberry Pi since I use a Razberry board.

I will have a look at the startup code for OpenLuup. It could be the timing issue that OpenLuup starts before the network is fully up as @akbooer says.

[iRobot]

@ArcherS
That can be done by adding the following lines to your openluup.service file:
[Unit]
Description=openLuup and AltUI Server
Wants=network.target
After=network.target

[ArcherS]

@irobot Thanks for the sugestion, I already have those lines in the systemd.

This is how it looks today:

[Unit]
Description=openLuup and AltUI Server for Vera 3
Wants=network.target
After=network.target

[Service]
Type=forking
WorkingDirectory=/home/USER/cmh-ludl
ExecStart=/bin/bash run_openLuup.sh
ExecStop=/bin/curl http://localhost:3480/data_request?id=exit
[Install]
WantedBy=multi-user.target

Any ideas on adding a delay before the launch of OpenLuup or similar?

[akbooer]

@archers said in Luup reload required after server reboot:

Any ideas on adding a delay before the launch of OpenLuup or similar?

Yes, this should be as easy as adding a delay at the beginning of the Startup Lua.

I am shocked to suggest this, since I always recommend that you should not use this LuaSocket primitive during the running system, but it seems the simplest way, and even appropriate in this case...

local socket = require "socket"
socket.sleep (20)

..or even just:

require "socket" .sleep (20)

[ArcherS]

@akbooer I tried this (but with 10 seconds delay) and it seems to work, the bridges does connect at reboot.
I will keep it in and see if it works or misbehaves in any other way.

[rafale77]

One way to do this is by adding a delay in your service file under [service]

ExecStartPre=/bin/sleep 15

This makes it wait 15sec

[ArcherS]

@rafale77 Thanks, before the ExecStart line I suppose?

That could perhaps be a good solution since it will only delay at initial start after boot.

Two solutions in minutes, again the forum delivers!

[ArcherS]

@rafale77 I tried this way of delaying at startup and it works fine. It does not cause delays when reloading luup which is a clear benefit.

[Donato]

Hi akbooer,

what is the command/script running when I click from openluup console "Utilities -> Reload Luup Engine" ?

I notice that sometimes DY stop sending data to remote system (may be for connection lost) and the data transfer restart after the action "Utilities -> Reload Luup Engine" .

The server reboot is not the solution of the problem.

I have the delay in the openluup service file.

tnks

[akbooer]

Upon receiving a reload command, the openLuup engine exits its scheduler loop and then exits the program with a success code that causes the surrounding openLuup_reload script to loop and re-run the engine.

DataYour uses UDP to send data between its various components, so has absolutely no way of knowing whether a message is received or not.

Sounds like it's a network problem, and perhaps the LuaSocket library isn't coping well with that.

[Donato]

I'll try to re-install the LuaSocket Library but meanwhile I want to schedule a daily openluup_reload.

Are the process actions after a reload command the same as "systemctl restart" of openluup service ?

tnks

[akbooer]

No, it’s not a problem that will be fixed by reinstalling.

I don’t understand your question

[mrFarmer]

Hi Ak,

I did a test on a PI as after a reboot would still require a loop reload. I found this article https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ and put network-online.target in the openluup.service file:

[Unit]
Description=openLuup and AltUI Server for PI
Wants=network-online.target
After=network-online.target

I can see openLuup gets started later and it seems more reliable in my situation.

Cheers Rene