Making sockets not a light


Hard on the heels of another poster, I’ve managed to change the icon for some of my sockets to be, well, sockets. They are still using the BinaryLight settings, and Vera still turns them off if you do ‘All lights off’
Is there an alternative device I can make them to be ‘not lights’?




It would appear from examining the JSON static data for BinaryLight1 and img directory that (category number is 3 except where indicated):

Subcategory icon
0 bulb
1 plug-in switch
2 bulb
3 plug-in switch
4 none
5 garage door (house facade )
6 doorbell
7 none
8 none

Subcategory 3 is defined twice in the static JSON file, so I’m guessing here that the first definition would control (testing confirms). Subcategories 4, 7 and 8 are defined as “Refrigerator”, “Valve” and “Relay”, respectively, in the documentation, but have no icon assignments in the static JSON file, so they would display as a gray bulb (the default), with no transition state icon (e.g. bulb appears always off/gray).

The BinaryLight1.json file also has a condition for category 5 subcategory 1, which displays a thermostat; and a condition for category 30, which displays a doorbell.

As it relates to your question, maybe subcategory 0? You’d have to test it.

EDIT: Wait, you want plug-in (socket)… well, after some testing, it looks like subcategory 0 (in category 3) shows a bulb icon with on/off state transition, but is not counted as a “light” for purposes of the dashboard’s all-on/all-off control. But, there does not seem to be an analogue for the plug-in switch/socket icon–both subcategories 1 and 3 are treated as lights by the dashboard.

1 Like

They broke this implementation something like 2 fws ago.
I fixed it in mine, by hacking the JSON.


Thanks, Guys

Set one of my sockets to Sub category zero. Vera still thinks it’s a light.

Oh well. We never use the ‘All on’ function anyway.

@therealdb I assume you had to copy the Binary_Light.xml and json files to something like ‘Binary_Socket’ with the correct values?




Make sure you reload Luup and do a hard refresh of your browser after changing the device category or subcategory.

The file you need to modify is D_BinaryLight1.json, not .xml.


Ahh reloading seems to help :slight_smile:
Now, could you possibly remind me how to force a re-load?

Ahh no. going to 3/0 replaces the plug icon with a bulb, but (seems to) remove(s) it from the all lights. 3/3 gives you the plug icon, but Vera thinks it’s a light :smiley:




yeah. just modify the json and you’re done.

according to this, you’d get

Subcategory icon
0 Switch
1 Bulb
2 Bulb
3 Switch
4 Relay
5 Garaga door
6 Doorbell
7 Valve
8 Relay

and that’s what I modified. just upload this file and you’ll be good to go. (1.8 KB)

in mobile apps they’re still hard-coded, so it won’t make any difference.


nice im gonna try this


Thanks, chap.

I’m curious how this file stops Vera from thinking they are lights?




It doesn’t. It’s the subcategory assigned that does that. So you must, then, make sure that the subcategory you assign has the socket icon, and isn’t a subcategory that Vera thinks is a light (1,2,3).

We already established that functionally, 0 (zero) works–Vera doesn’t handle it as a light–it just has the wrong icon for you (bulb) by default. The file @therealdb uploaded handles the icon change.

One caveat, though… the file in the ZIP is named D_BinaryLight1.json, the same as the system file. To avoid clashing with the existing system file, I would:

  1. Rename the new file D_BinarySwitch1.json (as you had siggested earlier–on the right track);
  2. Upload it using the regular Apps > Develop apps > Luup fiiles uploader;
  3. In any device you want to have display as a socket and not handled as a light:
    • Set subcategory_num to 0
    • Set device_json to D_BinarySwitch.json (your new file)
  4. Reload and hard-refresh.

This will also stick well and not be overwritten by later firmware updates.


Why can’t Vera just fix it so we do not have to go through all these hoops?


fair notice. I usually got them replaced, then see if the firmware has fixed them (I keep posting it to the support after every firmware…) and then upload it again.


they changed it two firmwares ago, if I remember correctly, and never changed it back. I don’t know why, but they’re probably busy working on UI8 and this cosmetic issue is not in their priority list right now. The problem is that mobile apps have also icons hard coded, so this fix involves fixing them as well.

1 Like

Thanks, all!