New j9 Automation Engine Driver

Developer's Corner General Dev Discussions
#1

Hello, I have created a driver for Vera in the j9 Automation Engine (beta codename) software product.

The driver currently supports lighting and thermostats. You can create touch screens and rules to control these devices though Vera.

I’d like to add support for sensors and locks as well but I need to understand how Vera interprets these concepts first. Can anyone answer the following?

  1. What does Vera consider to be a sensor?
  2. Can a light be a sensor or is a special class of device?
  3. Is the schlage considered to be a sensor?
  4. Why would I want to set a sensor? Traditionally a sensor is something read, not set,
  5. Why does the Set Sensor State command have device id’s as parameters?
  6. Is unlocking a door really as easy as using the on/off command? What happens when you send it a level of 10 or 60?

Thanks,
Johnny

http://johnnynine.com

#2

As a start you should look first at the template json file
http://192.168.81.1/cgi-bin/cmh/get_json.sh?file=template_data.json
Then have a look at the java script that generates the web pages: /www/cmh/js/scripts.js

The you’ll need to know also that Zensys publish default devices categories, but manufacturers can create custom devices according to the zwave classes published by Zensys ( a device can report itself as a sensor but can be a thermostat according to zwave classes ).
So a manufacturer can create an 3-in-1 device that can’t be put in a single category and for that we ask that device what command classes it knows and we split it in 3 different categories (in your browser you see it as 3 devices but in the zwave it is only one device).

[code]int ZWaveNode::GetDeviceTemplate(unsigned char cGeneric,unsigned char cSpecific)

switch(cGeneric)
{
case GENERIC_TYPE_SWITCH_MULTILEVEL:
{
if( cSpecific==SPECIFIC_TYPE_MOTOR_MULTIPOSITION )
return DEVICETEMPLATE_Drapes_Switch_CONST;
else
return DEVICETEMPLATE_Light_Switch_dimmable_CONST;
}

case GENERIC_TYPE_SWITCH_BINARY:
return DEVICETEMPLATE_Light_Switch_onoff_CONST;

case GENERIC_TYPE_WINDOW_COVERING:
return DEVICETEMPLATE_Drapes_Switch_CONST;

case GENERIC_TYPE_SENSOR_BINARY:
return DEVICETEMPLATE_Motion_Detector_CONST;

case GENERIC_TYPE_SENSOR_MULTILEVEL:
return DEVICETEMPLATE_Generic_Input_Ouput_CONST;

case GENERIC_TYPE_THERMOSTAT:
return DEVICETEMPLATE_Standard_Thermostat_CONST;

case GENERIC_TYPE_ENTRY_CONTROL:
return DEVICETEMPLATE_Door_Lock_CONST;

case GENERIC_TYPE_SWITCH_REMOTE:
return DEVICE[/code]
Devices that need to be treated in a custom way:

int ZWaveNode::CustomDeviceTemplate(int iManufacturer, int iProductType, int iProduct) { if( iManufacturer==ZWAVE_MFR_RYHERD_VENTURES && iProductType==2 && iProduct==1 /* 3-in-one-sensor */) // todo , this is repeated above return DEVICETEMPLATE_Express_Controls_EZ_Motion_CONST; else if( iManufacturer==ZWAVE_MFR_EVERSPRING2 && iProductType==258 && iProduct==1 ) // Everspring door/window sensor return DEVICETEMPLATE_Door_Sensor_CONST; else if( iManufacturer==ZWAVE_MFR_DUEWI && iProductType==16385 && iProduct==0) // todo this is repeated in CustomDeviceTemplate return DEVICETEMPLATE_Drapes_Switch_CONST; else if( iManufacturer==ZWAVE_MFR_DANFOSS && iProductType==100 && iProduct==1) // todo this is repeated in CustomDeviceTemplate return DEVICETEMPLATE_Generic_Input_Ouput_CONST;

The above is a snipped from our zwave code so you’ll have an idea on how we identify the devices and assign then in a category.

4/5. Arm/Disarm are internal commands. They are used only for creating a scene that has an event which reacts only when the sensor it’s armed. The Zwave device doesn’t know about this, so that it why you send the command to the Security Pluggin and you see those parameter ids.

  1. The lock will ignore the level command. lock/unlock it’s as easy as using the on/off command.