Introducing Z-Command

[NeverDie]

Better than 3rd party plugins, it has a REST API that you can use with almost any programming language you're comfortable with. For example, you enumerate devices by simply calling http://[your z-command IP address]/api/devices/{filter?} 
 
{filter?} is an optional string that lets you limit the returned objects by device type, location and name.
 
The list of API's is here:
 
https://z-command.intulon.com/z-command-user-manual/api/
 
We will be creating blog posts about how to create 3rd party applications on different platforms over the next few weeks.

 
I haven't tried it, but this does sound like a worthwhile differentiator.  i.e. Why learn yet another pathetic homegrown scripting language if you can leverage something you already know and that's widely accepted as good?
 
One thing I do wonder about, though, is all the work-arounds that products like HomeSeer claim to have implemented in their device drivers to overcome shortcomings in the way the devices implemented their z-wave drivers.  If the public libraries were enough, then they wouldn't have had any need to do that.  This implies there may be some extra work users would have to do, and unfortunately I don't know how to quantify how much that is, or whether end-users could even do it at all without access to privileged knowledge that, for whatever reason, the device makers haven't made public.  Unfortunately, all this may be nothing more than unverifiable FUD, because how can we ever know if it's true or not, but that's the legend that gets told and re-told.
 
If it would help, I could maybe explain what I mean by way of an example where Vera was apparently granted access to privileged information by Leviton that made Vera's implementation of a certain Leviton device better, and, allegedly, HomeSeer was not granted, and could not get, the same access to information. AFAIK to this day HomeSeer's implementation still lacks some functionality that Vera has for that particular device.  I say allegedly, because that was the explanation given, but again, I have no way of ultimately ever knowing whether it was a case of could-not, or simply would-not, or something else.  I consider it weak evidence, but it's discrepancies like that which, at the margin, make me think there's at least a grain of truth in the legend.  Or, it could be a whole mountain of grains.  Who knows?

 

[intulon]

I haven't tried it, but this does sound like a worthwhile differentiator.  i.e. Why learn yet another pathetic homegrown scripting language if you can leverage something you already know and that's widely accepted as good?
 
One thing I do wonder about, though, is all the work-arounds that products like HomeSeer claim to have implemented in their device drivers to overcome shortcomings in the way the devices implemented their z-wave drivers.  If the public libraries were enough, then they wouldn't have had any need to do that.  This implies there may be some extra work users would have to do, and unfortunately I don't know how to quantify how much that is, or whether end-users could even do it at all without access to privileged knowledge that, for whatever reason, the device makers haven't made public.  Unfortunately, all this may be nothing more than unverifiable FUD, because how can we ever know if it's true or not, but that's the legend that gets told and re-told.

 
Indeed, it takes a bit of work-around to get some devices to work right. With the Z-Command API, you a simplified abstraction layer. All responses are JSON objects. 
 
The API is an on-going effort, new devices will always show up and we will extend functionality on existing ones. Our aim is the make it fun for someone who just want to control a few binary switches while fulfilling the need of someone who needs a complex custom solution.
 
As for device makes keeping some information private - that is always a possibility but it doesn't help the manufacturer if they want mass adoption of their device. What I have seen is poor documentation and un-intuitive protocol interactions.