I have read through the following wiki. http://wiki.micasaverde.com/index.php/Luup_plugin_icons
and have modified a few plugins to display the correct icons which did not work on UI7 or customized some default icons. It all works well when I upload the file in the /www/cmh/skins/default/img/devices/device_states/ folder but when I access the vera remotely, it no longer works.
After digging a bit, somehow the .png files in this folder are also links which point to /mios/www/cmh/skins/default/img/devices/device_states/
I don’t quite understand how this works since their size indicate that they are icon files but winscp shows them as links.
The mios folder seem to contain the actual png file the vera is using when accessed remotely. Unfortunately it is a write only folder in which I can’t seem to be able to upload any file.
You’ve been led astray and come to the wrong conclusion.
The /mios directory is a read-only filesystem which Vera mounts as part of its overlay filesystem. Overlays are an OpenWrt feature that give you the illusion of a completely modifiable filesystem by selectively adding or replacing copies in the read-only version with your own copies in /.
You can’t modify /mios but you can modify the overlay. That’s what you are already doing. That’s why adding files to your own Vera works locally.
When you are accessing the Vera remotely you are not using the icons from your Vera. Instead getvera.com is serving its own directory, essentially the same as what you see in /mios but, naturally, without your modifications. This is by design, and probably with the best of intentions, but it breaks when you are accessing the plugin remotely.
I’m sure that MCV knows about this shortcoming. They haven’t decided to fix it yet.
Well, They are read only so I can’t do anything to them in the read only file system. The links themselves are also read only.
I ended up enabling a web server service on my QNAP to host the icons… It resolves the problem.
Remotely the icons are not read from your local Vera but from Vera’s web server, that is why anything that is not standard does not show remotely. Many have asked to change that. MIOS did hint they may in some future release.
As you found you can use a URL for icons as well and solve the problem that way.
And for using logical links. They do get wiped after a firmware update. For my plugins I store all icons in the UI5 folder and create logical links to the correct UI6 or UI7 location when the plugin loads to fix that.
As a side note I fixed this issue in my altUI plugin to display all plugin icons, even when accessed remotely. The way this works is when an icon is needed in remote mode altUI asks its Vera side counterpart (the Luna plugin) to convert the icon in data 64 format and the altUI client can then display ( and cache it). It gives all icon including state dependent ones correctly.
Of course only valid if you use altUI, as it does not fix the ui7 although it would be interesting to try to store the data64 image format string in the Json instead of the icon name/urn and see what happens… That’s essentially uses the Json file as the container for the icon bit.
Thanks guys. Not sure why mcv did it this way. Ohh well. Now my the next thing I am trying to do is to copy an existing device type so that it can display a different icon set:
my vents are being recognized as dimmable lights and I find it quite annoying. I have created new json and xml files by editing the existing dimmables but when I try forcing a device to use them, it messes all my light switches up (They stop displaying on the UI). I am not touching the device category or subcategory when I do it. Is what I am trying to do even possible?
No. Any given device type has to use the same icon for all instances. If your vents report themselves as dimmers to Vera then Vera thinks they are dimmers and will use the same icons.
You’re not the first to have asked for this feature. Join the dozens who’ve already done so.
Actually technically this is not true. You can add another icon reference to the original json where the category_num and/or the subcategory_num is different than other devices installed on the system. This will display a different icon and is how a BinaryLight device type is able to display a garage door icon.
By the way for those interested in not hosting the icons of their app through their website for UI7, I think I found another workaround. I still have to test it remotely.
It seems that the previous assumption that the problem with the remote access icons stems from the fact that the icons are being displayed by getvera is not exactly the problem. The real problem I think is that getvera does not have access to every folder on the vera box. Putting the icon files at a location were getvera can access them should fix the problem. I believe to have found a folder:
/www/cmh/skins/default/img/icons/
To call out this folder from device json I used the following path: "default_icon": "../../../img/icons/blahblah.png",
It seems to work.
Edit: the “…” are obviously to go one directory level up
Edit2: That folder above is also not readable remotely and is filled with links so I guess I am back to square one with hosting an url icon.
The trick for the binary light worked but unfortunately does not seem to work for a dimmable light. The device simulator pukes an error every time I list out a subcategory_num in the conditions…
I figured a work around for the vents. I just used another supported device type which is in fact better suited to the vents than the dimming lights: The Window Covering device.
Without changing any of the category or subcategory, I just used the xml and json files. Modified the json file to work with UI7 icons, modified the icon and assign the devices to use them and voila…
That indeed works as long as you do not want to use a standard windows covering device as well. And if you change too much in the json it may not work with many of the mobile apps.
Thanks Rene, yes I realize that the more I modify the further away from stock behavior I risk going. So far I am just modifying the icons and I think I picked something which would work even if they are window covering so no concerns there yet.
Best Home Automation shopping experience. Shop at Ezlo!