I’ve written a number of device handlers for devices that support the Z-Wave Protection command class. The basic principle is to protect a device against unintentional control (e.g. by a child), typically by disabling any physical buttons (or requiring a special sequence to be input first). This is common in devices such as relays, dimmers, power outlets, etc. (V2 of the Protection command class also supports protection from wireless RF commands).
Anyway, it got me thinking that it might be useful for SmartApps to be able to control protection states in devices. E.g. A user might want to prevent devices from being turned on or off at particular times of day. It might also be useful to control protection based on beacons or presence, which would offer a way to allow a device to only be controlled when a certain person is present or not present.
Here, I’m using the same terminology as the Z-wave command class, but if similar functionality exists for Zigbee or other types of devices, then it could be generalised. E.g. localProtectionMode could equally be called physicalProtectionMode or childProtectionMode.
I think the basic idea is very good but you’re Going to run into some challenges implementing this because in the Z wave concept, it specifically applies to devices which have local manual control over electrical current. So you have to process the command in the device, or you won’t get a lockout at the manual level. (BTW, I would call this “childproofing” rather than “child protection” as I think it fits better with current industry terminology.)
With the second version of the protection command class, the Z wave terminology began using “local operations” to refer to the manual operation of the device.
Anyway, my point here is that there isn’t anything the hub can do to prevent a plug-in pocket socket from responding to a manual button press except to use the protection command if that pocket socket supports it. You can’t create the same effect in the cloud. You can’t add this capability to a device that doesn’t already support it. Because what you are controlling is the device’s response to a local physical button press.
The Linear/GoControl PS15 pocket socket is a good example of a Z wave classic device on the market now which supports the protection class. There’s a button on the front of it. Normally, pressing that button manually turn the device on or off. But you can use the protection command set to change it so that the device will ignore The local button press.
So again, I think the capability is a great idea, I just want to make sure that people understand that this has to do with local physical manipulation of a device, so it’s not a capability you can add just through cloud processing.
I agree, it’s important to highlight that this capability relates to a physical property of the device and can’t be emulated in software on the hub. This capability would therefore only be relevant for devices that actually support this behaviour (i.e. Z-wave Protection command class, or equivalent for Zigbee if it exists).
I don’t see how that in itself will cause any more challenges to implementation than any other capability which relates to a physical property of a device.
Also, I agree Child protection is not a great term, so I would favour just “Protection”, as the function equally protects from unintended actions by adults.
The challenge is just how to let the developer know that that capability is not available for that particular device. But maybe you just leave that up to people to figure out for themselves given appropriate documentation.
I’m still not sure I understand the point you are making. I mean, one could equally say that for any capability, e.g.: the challenge of the battery capability is just how to let the developer know that that capability is not available for that particular device.
One has to assume that a developer knows the fundamental physical capabilities of the device they are writing a device handler for.
Fair enough. My first reaction was just that a lot of people are not going to know that this capability is a local device feature. But maybe they will.
