openLuup: Turn-key Images & Linux (Aptitude) Guide

Plugins & Plugin Development openLuup
181

My bad, I just glanced and saw tmp (busy day @ work)… Yes, I concur that eventuality will occur so it’s best to periodically offload backups (zway and AltUI/OL) to remote storage. Or perhaps seek an external SSD for mission critical systems (this won’t alleviate the /var/log written to by both AltUI and Zway).

[quote=“vosmont, post:180, topic:191587”]Hello CudaNet

pi@openLuup:/var $ df
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/root        7546488 1036356   6177280  15% /
devtmpfs          218416       0    218416   0% /dev
tmpfs             222688       0    222688   0% /dev/shm
tmpfs             222688    4492    218196   3% /run
tmpfs               5120       8      5112   1% /run/lock
tmpfs             222688       0    222688   0% /sys/fs/cgroup
/dev/mmcblk0p1     61384   20328     41056  34% /boot
pi@openLuup:/var $ ls -l
total 102440
drwxr-xr-x  2 root root       4096 Sep 20 06:25 backups
drwxr-xr-x  8 root root       4096 Feb 26  2016 cache
drwxr-xr-x 31 root root       4096 Mar 14  2016 lib
drwxrwsr-x  2 root staff      4096 Jan  7  2015 local
lrwxrwxrwx  1 root root          9 Feb 26  2016 lock -> /run/lock
drwxr-xr-x  6 root root       4096 Sep 20 06:25 log
drwxrwsr-x  2 root mail       4096 Feb 26  2016 mail
drwxr-xr-x  2 root root       4096 Feb 26  2016 opt
lrwxrwxrwx  1 root root          4 Feb 26  2016 run -> /run
drwxr-xr-x  4 root root       4096 Feb 26  2016 spool
-rw-------  1 root root  104857600 Feb 26  2016 swap
drwxrwxrwt  2 root root       4096 Aug 18 22:37 tmp
drwxr-xr-x  8  501    80      4096 Feb  2  2016 webif
pi@openLuup:/var/log $ ls -l
total 7288
-rw-r--r-- 1 root root       0 Sep  1 06:25 alternatives.log
-rw-r--r-- 1 root root   18698 Aug 18 23:41 alternatives.log.1
drwxr-xr-x 2 root root    4096 Sep  1 06:25 apt
-rw-r----- 1 root adm    16026 Sep 20 19:27 auth.log
-rw-r----- 1 root adm    54409 Sep 19 06:25 auth.log.1
-rw-r----- 1 root adm     1912 Sep 11 06:25 auth.log.2.gz
-rw-r----- 1 root adm     2644 Sep  5 06:25 auth.log.3.gz
-rw-r----- 1 root adm     1986 Aug 28 06:25 auth.log.4.gz
-rw-r--r-- 1 root root  292042 Feb 26  2016 bootstrap.log
-rw------- 1 root utmp       0 Sep  1 06:25 btmp
-rw------- 1 root utmp     384 Mar 12  2016 btmp.1
lrwxrwxrwx 1 root root      17 Mar 12  2016 cmh -> /home/pi/vera/cmh

It seems that the logs

/var/log/z-way-server.log
/var/log/cmh/LuaUPnP.log
/home/pi/vera/cmh-ludl/LuaUPnP.log

are not written in RAM. It could quickly dammage the SD card ?[/quote]

182

Hi,

I just installed the Debian virtual box version of Openluup. It was very easy and I had everything running in less than 5 minutes. Thanks a lot! :wink:

The only issue I seem to have is not being able to login as root. I need to reconfigure the time zone settings in Debian as they are 7 hours off from my time zone. Therefore my time based scenes are obviously a bit inaccurate.

I use terminal on osx to login to my openluup session with ssh. The user name test and password ‘openluup’ work fine but I when I try to login as root the password ‘openluup’ is not correct.

Can you pls confirm the password is correct for the user ‘root’? Or is there any other way to reconfigure the time zone settings?

183

Morning,

Are you attempting to login as root at the console or via SSH ? If via SSH (via PuTTY) then use the command ‘su’ and enter your sudoer password ‘openluup’. You can then confirm by performing the command ‘whoami’ and it should respond with root. Unfortunately with the latest Win10 update, it has blocked access to my Vbox installation. I’ll have to install the latest Vbox in order to confirm (actually I believe I still have an install at work so I’ll check when I get into the office).

Hope that helps,
Cuda

[quote=“jcsv75, post:182, topic:191587”]Hi,

I just installed the Debian virtual box version of Openluup. It was very easy and I had everything running in less than 5 minutes. Thanks a lot! :wink:

The only issue I seem to have is not being able to login as root. I need to reconfigure the time zone settings in Debian as they are 7 hours off from my time zone. Therefore my time based scenes are obviously a bit inaccurate.

I use terminal on osx to login to my openluup session with ssh. The user name test and password ‘openluup’ work fine but I when I try to login as root the password ‘openluup’ is not correct.

Can you pls confirm the password is correct for the user ‘root’? Or is there any other way to reconfigure the time zone settings?[/quote]

184

Hi Cudanet,

Thanks for the quick answer. I am trying to login via SSH (OSX terminal or Putty give the same results). To configure the correct time zone locale for Debian I believe I should use the command: dpkg-configure locales. But unfortunately this doesn’t seem to work as per error below. ???

Powered by openLuup(AKbooer) and AltUI(Amg0). Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Sun Oct 9 11:03:24 2016 from 192.168.1.12 test@openluup:~$ su dpkg-reconfigure locales No passwd entry for user 'dpkg-reconfigure' test@openluup:~$ su dpkg-reconfigure locales

Btw, In the meantime I have managed to create myself another problem and now openluup won’t start anymore. I tried to restore a previously saved user_data.json file via WinSCP but also in this case I need the root permissions. So for both issues it looks like the best option would be to retrieve the root password.

Thanks so much and sorry for the trouble.

cheers,

Jacques

185

You must first enter su at the command prompt, the system will then prompt for the sudoer password. Once performed, you can then perform the following to enter the tzdata GUI.

dpkg-reconfigure tzdata

[quote=“jcsv75, post:184, topic:191587”]Hi Cudanet,

Thanks for the quick answer. I am trying to login via SSH (OSX terminal or Putty give the same results). To configure the correct time zone locale for Debian I believe I should use the command: dpkg-configure locales. But unfortunately this doesn’t seem to work as per error below. ???

Powered by openLuup(AKbooer) and AltUI(Amg0). Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Sun Oct 9 11:03:24 2016 from 192.168.1.12 test@openluup:~$ su dpkg-reconfigure locales No passwd entry for user 'dpkg-reconfigure' test@openluup:~$ su dpkg-reconfigure locales

Btw, In the meantime I have managed to create myself another problem and now openluup won’t start anymore. I tried to restore a previously saved user_data.json file via WinSCP but also in this case I need the root permissions. So for both issues it looks like the best option would be to retrieve the root password.

Thanks so much and sorry for the trouble.

cheers,

Jacques[/quote]

186

That helped! Thanks a lot. I am back in business.

Final question: Can the SU command also be used with WinSCP to restore the user_data.json file in case needed?

187

You are very welcome…

Are you unable to copy over the file (via WinSCP) due to permissions or is it a concern that the file must be written as root ? Copy the user_data.json file into the /etc/cmh-ludl directory and it should show the owner as ‘test’. You can then jump over to PuTTY and start the instance (be sure to close out any running instance; e.g. id=exit).

Final question: Can the SU command also be used with WinSCP to restore the user_data.json file in case needed?
188

I had indeed permission issues with Winscp as user ‘test’. I couldn’t overwrite the old user_data.json file. Then I deciced to start from scratch and reloaded the vbox image. Now everything is working perfect! Thanks again.

189

I suspect the user_data.json was owned as Root and yes, you won’t be able to overwrite the file. When that happens, just PuTTY into the instance and change to Root (e.g. su) and then you can rename/remove the file. Once renamed/removed, you can then move over the backup user_data.json file using WinSCP.

190

Hello,
the weave service seems to have moved to remote.it
the problem : my antivirus (Avast) fires alarms on this site (Infection BV:Tsunami-AM[Drp])

Have you got the same problem ?

191

Vosmont,

Weaved should still work as of last Friday when I last used it. I’ll check it when I get into the office this morning. However yes - they seem to be pushing towards Remote.It so much so that they won’t even respond to any of my posts or requests for assistance with Weaved (API questions). So I’ve avoided moving over to Remote.It all together. Pretty concerning though that your Viral software is alerting on the site.

Anyone else ?

[quote=“vosmont, post:190, topic:191587”]Hello,
the weave service seems to have moved to remote.it
the problem : my antivirus (Avast) fires alarms on this site (Infection BV:Tsunami-AM[Drp])

Have you got the same problem ?[/quote]

192

Well that was short lived… Seems we can no longer go to Weaved.com - we’re redirected to Remote.It now… If you don’t “convert” your device over to Remote.It then you can no longer access it. No wonder they wouldn’t answer any of my questions regarding the Weaved API (which they claim still works).

@Vosmont, I’m guessing this might be you that addressed this directly with the Remote.It forum (see pic).

[quote=“vosmont, post:190, topic:191587”]Hello,
the weave service seems to have moved to remote.it
the problem : my antivirus (Avast) fires alarms on this site (Infection BV:Tsunami-AM[Drp])

Have you got the same problem ?[/quote]

193

No :slight_smile: it’s not me… but it means that I’m not alone.

This alert is a bit frightening

194

Indeed it is, hopefully they’ll make a correction soon enough.

No :slight_smile: it’s not me… but it means that I’m not alone.

This alert is a bit frightening[/quote]

195

I have a question… I’m currently running ALTUI on my Vera Plus. I’m adding a Raspberry Pi to the mix running OpenLuup. The first time I tried it, I wound up with a big mess of duplicate devices with different numbers all over the place. Should I remove ALTUI from the Vera before I bridge OpenLuup to it or should I be bridging at all? I intend to offload stuff from the Vera to the OpenLuup install once it’s stable. I think I blew it up trying to install the DarkSky plugin on OpenLuup and I’ve given up for the night (no issue with the plugin, it works fine). Will look at it tomorrow but figured someone might be able to steer me in the right direction…

196

There is zero interaction between openLuup and AltUI running on a remote Vera. The only possible confusion is the the remote AltII plugin will be cloned just like other devices. This is easily identifiable by device number, and room number. You only really interact with AltUI through the web interface anyway.

I can’t recall if you described more fully the problem you had, but it should be easily sorted.

197

That is the issue. Everything is getting cloned over and I have multiple elements for each device. Should I remove the ALTUI interface from the Vera or will it make any difference. I noticed that removing ALTUI from the Vera doesn’t remove the elements transfered from ALTUI that show up in Vera’s device list.

Today’s task is to see if I can recover my openLuup install from yesterday. I think I crashed it and I don’t know of any other way to recover it that a reinstall…

198

Yes, that’s what the bridge does…

and I have multiple elements for each device.

…but that doesn’t sound good. You don’t have multiple bridges running to the same machine?

Should I remove the ALTUI interface from the Vera or will it make any difference.

No, don’t touch Vera, that’s what I tried to say before.

I noticed that removing ALTUI from the Vera doesn't remove the elements transfered from ALTUI that show up in Vera's device list.

No, the bridge doesn’t care whether AltUI is installed on Vera or not.

Today's task is to see if I can recover my openLuup install from yesterday. I think I crashed it and I don't know of any other way to recover it that a reinstall....

There’s really almost nothing that you can do to ‘crash’ openLuup. If you have a backup of the previous user_data.json file, or the compressed .lzo file, then you can use this as an input argument to the ./openLuup_reload script… just make sure you have shut down the previous running version with an exit request URL.

Unless you’ve wantonly deleted some files, there’s no need for a new install of the openLuup components. The following request:

http://openLuupIP:3480/data_request?id=altui

will force a download of the latest AltUI image and reset with an otherwise empty system. Clicking on Update against the VeraBridge icon on the Plugins page will install a new VeraBridge and you just need to configure the IP address on its variable page and do a reload.

199

I don’t know what I did, but I have it back up and running now. I deleted the user_data.json file and relaoded it. As for multiple bridges, I don’t think so. It only showed up the one time. I had elements numbered as 10xxx that came from the ALTUI on the vera as best I can tell…

200

Yes, that’s how the numbering should work.