I have managed to interface Indigo with MiCasaVerde's Vera 2 Z-wave controller/server. This posts my efforts to date in case anyone is interested.

Background:
My X10 gear is slowly failing and needs to be replaced. Insteon is not available in Australia, and I have been anxiously watching Z-wave for some time now. I thought if I start getting Z-wave devices I could use the Vera server as an interface to Indigo while I hope for someone to write an Indigo Z-wave plug-in. I may have jumped a little early, but it is working for me.

Some thoughts about Vera:
I now realize how much I love Indigo. We don’t praise Matt and Jay enough. Thank you Gentlemen. In comparison Vera is very limited (e.g., no variables, not user friendly - and that’s putting it mildly, no customization like control pages, etc). Additionally, while Z-wave may be trying to make device identification and installation simple, it is surprisingly convoluted (although that may just be a Vera issue). I get that Z-wave is very powerful, and beautifully fast, and will be a wonderful platform, however with Vera it is not for the feint-hearted.

Some thoughts about Z-wave:
I cannot wait for full implementation and wide-spread user adoption. This is an amazing technology. It appears (to myself as a beginner) to be incredibly powerful, super fast and the products available already show great promise. For example, I have motion sensors that also send variable light readings and current temperature settings. I couldn’t have done that easily with one device using X-10 (at least not what was available in Aus.). The only downside is that right now I think it is quite expensive (but I’m sure that has more to do with Australia being such a small market). Given the incredibly detailed attributes of a Z-wave device I now understand why this may take Matt and Jay considerable time to implement (which I hope/presume they may do one day).

I’m sure that this could be put into a plug-in or automated more elegantly, but I have a small system and am still learning. Essentially I am using URL and RESTful calls between both parties. I have teased this apart over some time, my technical language may not always be correct, and I do not profess to be an expert so comment gently. I am willing to learn. I’ve tried to be thorough, so this is long. It is very early days, but here is what I've done so far:

I haven’t explained all the conventions of Vera (e.g. Luup, etc) because I’m assuming that if you have Vera, you are at least familiar with the concepts, if not how to use them. Besides, I'm not that familiar with them yet either.

Initial Vera setup:
1. Setup as per instructions.
2. Set your network DCHP to reserve an address for Vera. We will need to reference the same IP address every time (that is, hard code it in scripts below) We could probably use Bonjour names but I haven’t investigated that yet.

Setting up a device in Indigo:
Keep your existing X-10 device descriptions in Indigo. It is essentially just a dummy device so I have only used the most basic of model types (e.g. Lamp module, etc). This is really just a place to keep the status of devices and sensors so that Indigo can send commands to Vera. Give or keep its X-10 address (usual rules apply, i.e. unique). I also add the Z-wave ID in the description (e.g. Z-wave ID 22). More on IDs later.

Indigo sending commands to Z-wave devices
1. Create a trigger for each state and for each device. That is, a light will have On, Off and Brightness, an appliance will have On and Off triggers.
2. For convenience I have put mine into their own “Vera devices” triggers folder.

On trigger example - 

Trigger pane: Type: Device State Changed,
Device: “Office lights”, On/Off State, Becomes On

Condition pane: Always

Actions: Type: Execute script (embedded AppleScript):

Code: Select all

do shell script "curl \"http://192.168.0.6:3480/data_request?id=lu_action&output_format=xml&DeviceNum=13&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=1\""

Note: IP address is Vera, the DeviceNum is the Z-wave device ID (I’ll tell you where to look later), and the newTargetValue=1 means On, newTargetValue=0 is Off. Note the serviceId is ‘SwitchPower1’


Off trigger example - 

Trigger pane: Type: Device State Changed,
Device: “Office lights”, On/Off State, Becomes Off

Condition pane: Always

Actions: Type: Execute script (embedded AppleScript):

Code: Select all

do shell script "curl \"http://192.168.0.6:3480/data_request?id=lu_action&output_format=xml&DeviceNum=13&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=0\""

Brightness example -

Trigger pane: Type: Device State Changed,
Device: “Office lights”, Brightness level, Has Any Change

Condition pane: Always

Actions: Type: Execute script (embedded AppleScript):

Code: Select all

do shell script "curl \"http://192.168.0.6:3480/data_request?id=lu_action&output_format=xml&DeviceNum=13&serviceId=urn:upnp-org:serviceId:Dimming1&action=SetLoadLevelTarget&newLoadlevelTarget=" & brightness of device "Office lights" & "\""

Note: the DeviceNum is the Z-wave device ID. Also the serviceId is different here i.e. ‘Dimming1’.

Additionally, I have Z-wave motion sensors that do light and temperature so I have created a variable for each child device/sensor reading (e.g. Office_light_levels).

That’s all you need for Indigo (I think).

For Vera:

Create the Vera device:
1. Create all your devices and sensors as required by Vera.
2. Open the Advanced tab for the device and look for the id. It should be directly below the ‘device_file’ entry. Don’t be confused by id_parent or altid.

Create Vera ‘On’ trigger for motion sensors:
Commands tab: Make sure all ‘Commands’ are not ticked. We want Indigo to control these, not Vera.
Events tab: Add an event. Device is your sensor (note the ID code)

Type: A sensor is tripped

Name for the event: Whatever is useful for you

Tripped?: Yes
Timers: Not applicable
Luup:

Code: Select all

os.execute('curl -X PUT --digest -u username:password -d isOn=1 "http://192.168.0.3:8176/devices/Office%20motion%20sensor"')

Note: IP here is IndigoServer.

This command sends an On event to Indigo using RESTful commands. Note the username and password is the IndigoServer user and password. I don’t like hard-coding passwords, but I don’t know that I have much choice in this situation. Besides, I’m comfortable with my network security.


I also added the Luup line below to update the variables I’ve created to store light levels in Indigo. Z-wave is supposed to poll the device for updates regularly, this just helps it along.

Code: Select all



local lul_lightLevel = luup.variable_get("urn:micasaverde-com:serviceId:LightSensor1","CurrentLevel", 19)
os.execute('curl -X PUT --digest -u username:password -d value=' .. lul_lightLevel .. ' "http://192.168.0.3:8176/variables/Office_light_level"')

IP address is IndigoServer. 

’19’ is the Z-wave device id for the light sensor (which is different to the parent motion sensor)

Create Vera ‘Off’ trigger for motion sensors:
Identical to On but changed ‘Tripped?’ to No (not gramatically logical but hey?) and change the RESTful isOn=1 to isOn=0.

Remember that every time you make changes to Vera devices, LUUP code etc you have to ‘SAVE’ the database (top right button between search and help - below the time)

You will have to force Vera to update Indigo on a regular basis for sensor information like light level and temperature. I assume you could poll each device for it’s status and other items, but I haven’t bothered yet, I’m trusting Indigo will remain accurate as my main server.

Create timed scene to poll sensors:
Commands tab: Make sure all ‘Commands’ are not ticked. They don’t apply here.
Events tab: Not applicable here.
Timers: Add timer. Interval based, every X minutes.
Luup: this code for light sensors

Code: Select all

local lul_lightLevel = luup.variable_get("urn:micasaverde-com:serviceId:LightSensor1","CurrentLevel", 10)
os.execute('curl -X PUT --digest -u username:password -d value=' .. lul_lightLevel .. ' "http://192.168.0.3:8176/variables/Office_light_sensor"')

and repeat for each sensor you have. In this example ’10’ is the Z-wave device ID of the specific sensor (remember, it’s not the parents ID, being the motion sensor. Light and temperatures are child devices that belong to the motion sensor parent).


I hope I haven’t left anything out and this may be of some use to someone. It’s definitely a PITA at the moment, but I have to admit that it’s worth it for the speed gains I’m getting over X-10.

If anyone can improve this or has more relevant experiences please let me know.

(edit: formatting)

Wow. Very impressive work there mate

I have one small suggestion that may help performance a bit. Instead of using real X10 devices as the place-holders for your Z-wave devices, take a look at the Meta device plugin. The main advantage of the pseudo device over an X10 device is that Indigo does not have to transmit any X10 commands when the device is operated. You can also attach actions (like the curl commands) directly to the on and off states and that might save a trigger or two.

Right now the plugin only supports relay type devices. But, that was mostly because until I read about your Z-wave interface I couldn't see the need for a pseudo dimmer. Adding a dimmer type would not be very much work so, if this works for you, let me know and I'd be happy to add dimmer device support.

Thanks Berkinet. Will definitely dig deeper into your Meta plugin. I was wondering if such a beast existed. And yes, dimming would be great (in this particular scenario).

I have installed and had a VERY fast tinker. Please excuse me, but I haven't ventured into the world of plugins yet, so I don't know their limitations. I created a device for an amplifier/speaker pair I have connected to an on/off only z-wave device. I converted the triggers to action groups for use by the new meta device.

I'm assuming this is by design, but should I lose the state of the device in the Indigo devices list (ie. no on or off icon) and the manual buttons below to turn the device on or off are also missing. So can I only turn on or off programatically? I have a control page icon representing the speakers and the device action was to toggle the device. Will that work using the Meta plugin? Do I still treat the control page speaker icon/device as a device and use Control Light/Appliance - if so, the new meta device is not in the list of available devices. I hope that makes sense.

Thanks for you suggestion and your help.

When a plugin defines a device, it has several types of devices to use as the base model, Relay, Dimmer, Thermostat, and Custom. Plugin Device types based on existing native Indigo device types will have the same UI elements as the base model. However, Custom device types have no visible UI appearance, and for that reason, also do not appear in the Indigo-Touch app. Custom devices can, of course, appear in Control Pages.

Since the Meta Device plugin creates devices based on the Relay base model, its devices will have a UI appearance.

Hope this answers your question.

Nice job gregconnors - if you can combine that with berkinet's meta plugin that would be great. Perhaps he can help you convert the do shell script calls to native Python http requests/responses - if there are POST or GET calls to the Vera that would return the status of a device then you could update status that way - maybe berkinet can add some kind of polling status update to the meta plugin such that when it's time to update the device's state it can call a script.

Our intention is to support Z-Wave directly in Indigo (either built-in like INSTEON or via a plugin). As you point out, doing Z-Wave right (so that it's just as easy or easier to deal with as INSTEON) is going to be a non-trivial amount of work (adding the advanced INSTEON linking was a non-trivial amount of work as well). We will not implement something that, in our opinion, doesn't live up to our ease-of-use standards since that's one of the main factors that sets us apart from other home automation vendors (thanks for noticing BTW).

So, while it is our intention to support Z-Wave it's going to take us some time to get it right.

gregconnors wrote:...yes, dimming would be great (in this particular scenario)....

Ok, I have added support for dimmer devices to the Meta Device plugin. Check out the Meta Device topic (linked below) for more information. Note that for brightness levels if you want to send the brightness setting to Vera, you will need to get the brightness level of the device in a script command. There are two (Python and AS) examples posted on the Meta Device announcement page. As for controlling the meta device in a script... you can treat it exactly the same as a standard X10 device.

and then Jay wrote:...Perhaps [berkinet] can help you convert the do shell script calls to native Python http requests/responses...

Sure, let me know. The key is the urlib module.

and then Jay also wrote:...maybe berkinet can add some kind of polling status update to the meta plugin such that when it's time to update the device's state it can call a script.

I am not exactly sure what you are suggesting here. The plugin can already call an Action Group on any change, and that Action Group can contain a script (as you noted above). Can you say a bit more about your suggestion?

Add the ability to refresh the status of a meta device (because of an external change) via a script that you call periodically. For instance, in your proliphix plugin, you probably have some periodic task that polls your thermostat to get it's current information and then updates the states accordingly. You could do something similar for a meta device - execute a "refresh" script periodically.

Haven't thought it through much more than that really though so there may be things that make it more complicated.

jay wrote:Add the ability to refresh the status of a meta device (because of an external change) ...

Got it. I was under the impression the Vera could push out the changes synchronously via Indigo's RESTFul API. Let's see what gregconnors has to say when the sun comes up down under.

Yeah, apparently it can - but you apparently have to write some Luup scripts to do it. It would be kinda nice if you didn't have to use yet another programming language...

But, as a general feature, I think it would add useful functionality to your plugin. IMHO.

Morning gentlemen.
At this stage I have only coded the on and off triggers for the Z-Wave motion sensors. I have also created the 5 minute polling of light and temp levels for the same motion sensors. For device states I have relied on if I set turn it on using Indigo then I trust it has stayed on. As you can imagine that's not very thorough, and I'm not always in sync, but it's simple.

I think it should theoretically be possible to create triggers/events in Vera that 'broadcast' device states as they change, or the 5 minute polling scene could work if you created a RESTful code for every device to send back to Indigo. More investigation required.

Sadly, I think that given this is a shoe-horned solution, it doesn't really matter which side I do the coding in, a substantial amount of coding is required. The trick is to make it as simple and logical as possible.

If I'm interpreting Jay correctly, if the Meta device plugin or similar could periodically 'pull' the state from Vera (in this case via URL call), that would a least allow me to keep all my code in Indigo. Vera really is awkward. That being said, I am grateful MiCasaVerde have opened up the URL access to allow just this sort of thing.

At this stage the hardest thing I've found is finding/reverse engineering the URL codes for Vera. I will look into the ease of pulling device states from Vera manually to see if it can be done. I'll let you know what I find.

I really appreciate the suggestions.

I would assume that the same basic process you posted for updating Indigo on changes in the Z-wave motion detectors would work with Z-wave switches as well. Of course I know nothing about Vera or luup. In any case, I think that getting Vera to update Indigo automatically would be the best way to go. If you can keep the two systems closely synchronized, then you can probably treat Vera as a black box/protocol converter and manage everything in Indigo.

As for adding polling to the Meta Device plugin... I am inclined to not do that right now. Two reasons: #1, There are too many possible communications channels to support: web based, IP, serial, and too many variations. One of the things that works for this plugin is its simplicity and I'd like to maintain that. #2. It is really simple to just create an Indigo scheduled action to do "whatever" and then update the meta devices in that action. For example, every 5 minutes run a script that polls the Vera server for device status.

At the same time, I would be very interested in helping you with this project... I may be looking for a similar solution where INSTEON is not available. So, let me know if you need help in Python scripting and using the Meta Device plugin.