Using this plug-in on openLuup


This plug-in is fully functioning on openLuup. One little caveatincase you run openLuup on a raspberry PI with Jessie. You have to set the value of the setting “Harmony Hub communication time out” to 30 seconds and not the default 5.

This is because of an issue with the Jessie LUA Socket module. having the default timeout may cause issues when starting a complex and long running activity.

Cheers Rene

Getting an error in my linux log: localhost rc.local[787]: ls: cannot access ‘/etc/cmh-ludl/D_HarmonyDevice6_.’: No such file or directory

There are no “D_HarmonyDevice6_.” files in the altui store download. However, the plugin is functional and does not seem to throw any errors within altui itself.


The plugin needs to create unique versions of the device files so that on a Vera the buttons can be displayed as configured. However, for ALTUI the details are red from the configuration variables directly so it does function on openLuup without those. So this is why those files are not in the App store.

Cheers Rene

Ok thanks. Can one test for the installed platform and then conditionally bypass the unneeded code. If it’s a simple fix, I’ll write an If statement to ignore the code throwing the error.


I do not know why your system generated the warning or why the files are no longer there. Did you do a reinstall? A simple fix is to empty the value from the Version variable and reload. This will force a regeneration of all needed files.

Cheers Rene

This may, perhaps, be an issue if your system is not actually running in /etc/cmh-ludl/, for example, if you created the cmh-ludl/ directory in your home RPi directory.

If so, you may find the missing file there.

So I cleared the variable, and as you can see from the dates of the files in the screenshot, the plugin reloaded. What I’m seeing is that there is a D_Harmony6.json and an Xml file in the directory, however there are no a “D_HarmonyDevice6_.” files. I’m also now getting a D_HarmonyDevice12_. error in the linux syslog file.

I’m guessing that you’re creating the device files D_Harmony6.json and xml on the fly, but are not creating D_HarmonyDevice6.json and xml, yet there is an inadvertent call to such files. A typo perhaps in the calling code.

Anything in the /files directory?

No, there are no files in the “files” subdirectory.

Hi Buxton,

The plugin will create the files the moment you have configured the plugin and the child devices. I have no idea what checks are being done on your system so it looks for things at start up in the rc.local. It has nothing to do with the plugin it self.

Cheers Rene

OK thx Rene.

Just a couple of things and I’ll let this alone.

First, this is a great plugin. Reading through the code I can see a great deal of effort went into understanding how harmony structures its data and in turn, how to use that data in a Vera environment. Mind warping for the uninitiated.

Second, I was concerned about the error because I’m using the Harmony plugin to bring up surveillance camera images (from my NVR) on my television in the event of a security incident. Now trusting security to anything vera has been widely discussed in the forums, so I won’t go there, but for the particular type of functionality I have in mind, I find it appropriate and given that I’m not able to spend tens of thousands of $ on security, using vera for some aspects of home protection is well worth the effort. So I was essentially trying to button down anything that could be problematic-- in calling the log error to your attention.

I believe the offending code is this: “os.execute('ls -A1 ‘…HData.f_path…‘D_HarmonyDevice’…HData.DEVICE…’_. > '…tmpfile)”

The shell out is throwing an error because, at this point in program execution, the shell is not seeing any files to list. One possible kluge would be to create a tmp file with the desired attributes in the given directory just prior to the list. This would ensure some data to place into the “tmpfile.” But I’m not a big fan of tmp files because of their klugeiness so perhaps there is a better way to account for a nil return value on the list. :stuck_out_tongue:

Anyway, just my two cents for what it’s worth.

Again, great work here, and thank you so much for your effort on this plugin.

Ok, now I think I understand what you are referring to. This is actually a bit of intended code to cleanup the files that are created for the child devices you had previously configured that are since deleted from the UI. As you probably know Vera will not clean up any obsolete files and they are pressed for disk space. Hence a routing to cleanup what is no longer in use. If you do not have any of those child devices a system log may indeed pick up the ‘error’ message, but it is expected behavior.

Cheers Rene

You might want to consider using the LuaFileSystem module ([tt]lfs[/tt]) instead of [tt]os.execute()[/tt]?

[tt]lfs.dir() [/tt]gives you a directory iterator, and the built-in Lua [tt]os.remove()[/tt] can do the delete. This should certainly avoid unexpected error messages.

But you probably know this already!

Hi akbooer,

As you know there is always room for improvements. Time is the problematic factor though :wink:

Cheers Rene