Reinstall of AltUI on OpenLuup, fresh RPI, keeps popping up 'FAIL'

I have an RPI that was running OpenLuup with AltUI. Being unskilled in Linux I broke it pretty thoroughly so have wiped the SD card and am beginning again.

On a fresh install, following this:

I installed openLuup with ALTUI. When I open ALTUI I get a popup that just has “FAIL”

The LUAUPNP.log and LUAUPNP_startup.log don’t seem to show anything relevant.

The popup keeps returning every couple of seconds.

I don’t want to proceed with my config until I get past this point.

Any ideas?

I also see a lot of this going on in the terminal:
tty 2020-06-21 131457

The error message comes from AltUI.
Perhaps @amg0 can help?

It may be a files permission error if, for example, you are running under a different account from the one that you used when you installed (system vs. user??)

at reload time altui cleans up /www/altui/ folder for alto* files. this is normal and harmless but maybe try to make sure the /www/altui/ folder exists and the process used by openluup to do an os.execute() has the rights

but the fail UI message should be different. try to look at the chrome console logs

1 Like

Thank you to @akbooer and @amg0 for your responses.

I will look at the points you suggested. It might have to wait until the weekend.

Query about the install process from the documentation:
Page 6:

Specifically the part screenshot.
It starts with #, so does that mean I should ‘sudo su’ before I run that command?

For context, the cmh-ludl directory I created is in my home (/home/pi/cmh-ludl)


It turns out I’m a doofus. The ‘fail’ was caused by Ghostery (tracking blocker plugin for chrome) ignoring the whitelist when AltUI tries to retrieve the registration details.

As @amg0 stated, this was evident int the chrome console logs.

I still get the ‘failed tty get’ and the ‘cannot remove /www/altui/altui*’ errors but otherwise it seems to work.

Thank you. For the update

Did you Confirm that /www/altui/ folder exists ?
The error is only a warning it is harmless but the folder should exist and the process running openluup should have the right to create and delete files in it

Hi @amg0 thank you for responding.

I installed openLuup under the default user ‘pi’

‘PS - u pi’ tells me that openLuup_reload is running in that user.

The www and www/altui directories have drwxr-xr-x permissions so I understand that means the user pi has write access. (~/cmh-ludl/www ~/cmh-ludl/www/altui are the full paths).

I am not Linux guru so maybe check with Akboer but it is key that from the app ‘s perspective the absolute path exists /www/altui so maybe some links are needed if physically the path is different from that

1 Like

Write access is not the same as delete ?

I guess so.

ALTUI does this at all reloads,
os.execute(“mkdir -p /www/altui ; rm /www/altui/altui*”)

the rm warning is a non issue

1 Like

I know you’re beyond this, but simply ‘sudo’ would suffice


1 Like

Thanks @Catman :grinning:, it doesn’t hurt for me to check. I work in Windows powershell usually (you are permitted to sigh).

My research indicates that it is, but my *nix skills are at kindergarten level.

@amg0 Your post on absolute path hinted at what could be my problem.

I created a symlink from the root to my home folder as per the pic and openLuup and AltUI seem to be working fine now. The ‘cannot rm’ message persists but as amg0 says it can be disregarded.

I’ve created a reactor scene with one action and I’ll see how it goes through the week. If all good, I’ll take a backup of the SD card then start shifting my scenes and automation from the Vera over to the openLuup.

Target is that the Vera is just a zwave gateway and all the automation is on openLuup (along with my largeish mysensors network that is currently on the Vera).

Thank you to all that took the time to offer assistance.

Glad that you have it going, although I’ve never found the need for such a symlink myself. However, my Unix skills seem to be on a par with yours!

Your direction sounds good, it’s how I keep my three Veras up and running for sometimes weeks at a time.

OT for this thread, but where do I set the Lat and Long in openLuup?

My system locale (as in at the operating system level) is set but Reactor thinks I’m in Greenwich. Consequently sunrise/sunset happens 10 hours early :slight_smile:

*************************************************** REACTOR LOGIC SUMMARY REPORT ***************************************************
   Version: 3.6 config 20070 cdata 20045 ui 20130 pluginDevice 6 LuaXP not loaded
    System: openLuup version 200522 on Linux wokopenluup1 4.19.97-v7l+ #1294 SMP Thu Jan 30 13:21:14 GMT 2020 armv7l GNU/Linux; in ./; loadtime 1593243177/1593320750; systemReady 1593320755; ALTUI v2.49b
       Env: Lua 5.1; JSON dkjson 2.5; UnsafeLua=nil/2
Local time: 2020-06-29T14:20:21+1000; DST=0; Greenwich, England UNITED KINGDOM; formats %d/%m/%Y %H:%M:%S
House mode: plugin 1; system 1; tracking off
  Sun data: {"source":"int","civdawn":1593399526,"nautdawn":1593395147,"sunset":1593462041,"nautdusk":1593469259,"stamp":2020181,"latitude":51.48,"astrodusk":null,"longitude":0,"civdusk":1593464880,"astrodawn":null,"sunrise":1593402365}
  Geofence: not running
        RS: 1593244555,1593246277,1593246280,1593246320,1593246324,1593247721,1593248518,1593249338,1593320716,1593320750
        NS: 0:X,1593243960:U


It’s exactly as in Vera. These are system-wide attributes.

luup.attribute_set ("latitude", 42.0)
luup.attribute_set ("longitude", -90.0)

You need,also, to have the locale set correctly at the OS level, but it looks from the above report that it is.

Thanks! I found it in the lua_startup. No idea why I didn’t think to look there before.

All your hard work on openLuup and amg0’s on AltUI is highly appreciated!

Best Home Automation shopping experience. Shop at getvera!

© 2020 Vera Control Ltd., All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules