AltHue file locations for openLuup

I’ve been using the AltHue plugin for a long time and it works very well. It is running under openLuup. Version is 1.43 The latest version is apparently 1.44 I tried using the AltUI updater and it didn’t update. I note that all the AltHue files are in /etc/cmh-ludl. It seems they should be in /etc/cmh-ludl/files? Plus I’m missing D_DimmableALTHue1.xml and D_DimmableRGBALTHue1.xml I checked the forum and GitHub but have found no info.

So can you please say where each of these files belong under openLuup:


Thank you in advance.

The /etc/cmh-ludl/files folder contains the /etc/cmh-ludl from the vera from which you would have triggered a get file function through the verabridge. Otherwise, all the plugin files should be in the /etc/cmh-ludl folder if you installed it on openluup directly from the ALTappstore. My installation has all the files you have missing… Do you want me to send them to you? They should be on github

The icon files should go in the icons/ folder in cmh-ludl/.

There should be no need to place them manually if you update either from the Plugins page, or using AltAppStore.

It’s still not clear to me what belongs in /etc/cmh-ludl/files folder and what does not. Should anything be moved to /etc/cmh-ludl?

again the files in the files folder are imports from your vera through the vera bridge. They are being used by openluup only when openluup cannot find them in the parent /cmh-ludl folder. You don’t need to move anything unless you have imported updated files from your vera and want to overrides the ones on your open luup installation. I never had to do any of this.

Ok - all the latest files from GitHub are now in etc/cmh-ludl and the icons in /etc/cmh-ludl/icons. With a restart everything looks much improved.

This seems imply that etc/cmh-ludl/files overrides whatever is in etc/cmh-ludl? Not sure why you would want to do any of this - as you say.

It is actually the opposite. The etc/cmh-ludl files override the subfolder files. The idea behind the etc/cmh-ludl/files/ folder is to host imported files from the vera so that for example you would see the same device icons on openluup as on the vera if openluup did not have these icons to begin with. This is technically how you also import entire plugins from the vera to openluup albeit you would still have to create a plugin device to make use of these plugin files.

For the record, the file loader (used when creating devices) and the HTTP server, when servicing file requests, use this search order:

  local f = open "openLuup/"        -- 2016.06.18  look in openLuup/ (for AltAppStore)
    or open "./"                    -- current directory (cmh-ludl/) 
    or open "../cmh-lu/"            -- look in 'cmh-lu/' directory
    or open "files/"                -- 2016.06.09  also look in files/
    or open "www/"                  -- 2018.02.15  also look in www/

Some XML files are also cached (see the new Console > Files > Cache page) and the cache is tried first before the physical file system. This does mean, as mentioned elsewhere, that a change in a physical file which has been cached will not be seen until the next restart.

During the (long) development of openLuup, I moved away from trying to emulate exactly some of the Vera file structure and revert to a system which tries to contain all the openLuup related files to sub-folders in /cmh-ludl/.

The file server, however, tries to be smart, and some file locations, often requested by AltUI (for example) are aliased to local folders. The icon search paths:

local dir_alias = {
    ["cmh/skins/default/img/devices/device_states/"] = "icons/",  -- redirect UI7 icon requests
    ["cmh/skins/default/icons/"] = "icons/",                      -- redirect UI5 icon requests
    ["cmh/skins/default/img/icons/"] = "icons/" ,                 -- 2017.11.14 

and CGIs:

    ["cgi-bin/cmh/"]     = "openLuup/backup.lua",
    ["cgi-bin/cmh/"]    = "openLuup/sysinfo.lua",
    ["console"]                   = "openLuup/console.lua",
    -- graphite_api support
    ["metrics"]             = graphite_cgi,
    ["metrics/find"]        = graphite_cgi,
    ["metrics/expand"]      = graphite_cgi,
    ["metrics/index.json"]  = graphite_cgi,
    ["render"]              = graphite_cgi,

So it’s a mess, for good reasons, but it’s less of a mess than Vera.

1 Like

Best Home Automation shopping experience. Shop at getvera!

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