Best way to disable a device’s on/off button, and make that known/visible via the UI?

Hi

I have some z-wave plugs sockets that I’m using to monitor their power usage (watts), and I’d like to disable the power button so no one can turn them off accidentally via the UI, but part of doing that - I’d like to do it in it clear in the UI that the power on/off option is disabled ? (Still controllable via code, just not via the UI)

Now, I assume the best way to do start this, would be is by creating a new D_BinaryLight1.json , and changing the following “Command” section, so that the power on SetTarget is also 0 rather than 1

							"Command": {
								"Service": "urn:upnp-org:serviceId:SwitchPower1",
								"Action": "SetTarget",
								"Parameters": [
									{
										"Name": "newTargetValue",
										"Value": "1"
									}
								]
							}, 

But what can I do to make it clear that the on/off in UI button is disabled?

I’d ideally like the backgrounds of that switch to be a different colour, e.g purple or something so it stands out. It must be possible, as I’ve seen Nest Protects, and zwave locks with a red background to show via the UI if their unarmed/armed or locked/unlocked UI - so I assume it must be possible ?

Please let me know what your thoughts are on how best to achieve the above - I’m assuming the UI piece is something javascript based which is an area I’m not familiar with at all, so really hoping someone can help…

so that the power on SetTarget is also 0 rather than 1

Setting the value to “0” in your private static JSON file will turn the lights off, not keep them on. I think you mean to use “1” there.

There is a built-in mechanism for disabling controls in the UI through static JSON. I do not know how this would look or operate (or even if it operates) with the multi-state (on/off) button control used for BinaryLight. But, here’s how it may be done, nonetheless:

The Conditions section of the static JSON file, which usually follows the Control array, is an array of conditions and commands that can enable and disable other controls. It is an array of objects with keys Trigger, Target and Action. Start with the easy ones:

The Action key may be either enable or disable. The Target is the value of the ControlCode for the control you want to enable/disable. For D_BinaryLight1.json that would be power_off.

The Trigger section has the most complex formatting, but should be straightforward in principle. It sets up the actual condition(s) under which the Action should take place on the Target control. Here’s what I believe it should look like for your goal:

		"Control": [
			{
				... existing Control section data -- don't change this part
			}
        ],
		"Conditions": [{
			"Trigger": {
				"Operands": [{
					"Service": "urn:upnp-org:serviceId:SwitchPower1",
					"Variable": "Status",
					"Value": {
						"Equals": "1"
					}
				}]
			},
			"Action": "disable",
			"Target": "power_off"
		}]
		... rest of the file

The hardest part of making this change will be placing it correctly in the file. In the 7.32 latest Beta (5350) version on my Plus. In that version of the file, the Control section begins at line 281 and ends at line 336. This seems to be unchanged from many, many versions prior, so you should see the same if you’re on 7.31. Line 336 is a right square bracket ] on a line by itself. Append a comma to this line, and then copy-paste the Conditions section given above only, placing it after that ], line. You can check your work by pasting the entire file into jsonlint.com.

Then do all the ritual things: save the file with a distinct name, upload it to the Vera, modify a device to use it, reload Luup, hard refresh your browser. You may also need to turn the device off and on once to get it to “stick” for the first time.

Juice may not be worth the squeeze, because it simply may not work with the multi-state button control, and your simple approach of changing the value only may be just fine. But the exercise may be interesting, and at least now it’s a bit documented and can be applied to other things, so offered as an alternative.

Edit: If multi-state button disable doesn’t work this way, it may just be that the multi-state button as a whole needs to be assigned a ControlCode. It doesn’t have one; the control codes are on the substates, but not the parent. Then that new control code would be used in as the Target for Conditions. But today is not my day for this, have much else on my plate.

Thanks @rigpapa

Yep, sorry, I have no idea where my head was at there, as I meant 1. :joy:

Do you think the disabling control is necessary, what if I just do the above, wouldn’t that hopefully create a sort of dummy switch ? If so, then, all I’d like to do is change the background of the switch too, from Green to maybe a purple. - is all that done in a file called shared.js ?

1 Like

That will probably work fine. The simplest solution is usually the best, as long as it behaves within the bounds of WAF.

More likely, it’s in CSS and attempts to change it are going to have widespread and unintended results (like, all switches purple). This is one of the reasons I recommended the Conditions approach, because it visibly greys-out controls and gives you :no_entry_sign: cursor feedback on them… when it works.

Best Home Automation shopping experience. Shop at getvera!

© 2021 Ezlo Innovation, All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules