Premise Zwave sensors

[etc6849]

The changes look good. I was thinking I should wait at least a few weeks while you test the sensors before posting anything in the downloads section.

My plan is to clean up the comments in two weeks. The driver is working great for me, but I'm wondering about one last addition from doc-2392 linked below. DOC-2392 talks about a command length limit of 80 characters for the VRC0P. I don't think the driver checks command length, but maybe it should?!?

I'm thinking about writing a method that would auto truncate the last nodes in a command until command length is below 80 characters. This method would be called only by send command (the sole point of entry to job creation). I'm not a programmer, but I think regex would be a great way to approach this.

A few application notes Leviton came out with for the VRC0P and VRCPG:

http://communities.leviton.com/docs/DOC-2392

and

http://communities.leviton.com/docs/DOC-2394

2394 is a very good doc to read if you haven't. It explains a lot of leviton specific zwave terms.

 

[mhilbush]

The changes look good. I was thinking I should wait at least a few weeks while you test the sensors before posting anything in the downloads section.

I agree. Let's wait a couple weeks to see if any problems are uncovered.

My plan is to clean up the comments in two weeks. The driver is working great for me, but I'm wondering about one last addition from doc-2392 linked below. DOC-2392 talks about a command length limit of 80 characters for the VRC0P. I don't think the driver checks command length, but maybe it should?!?

I'm thinking about writing a method that would auto truncate the last nodes in a command until command length is below 80 characters. This method would be called only by send command (the sole point of entry to job creation). I'm not a programmer, but I think regex would be a great way to approach this.

A few application notes Leviton came out with for the VRC0P and VRCPG:

http://communities.leviton.com/docs/DOC-2392

and

http://communities.leviton.com/docs/DOC-2394

2394 is a very good doc to read if you haven't. It explains a lot of leviton specific zwave terms.

I would be inclined to not send the command to the VRCOP, and throw an error. I'd be worried about modifying the command such that the execution of the modified command would have unintended consequences. I can't think of a specific example, but I'd be inclined to treat this as a black or white condition -- either it's a good command, or it's not a good command.

 

[etc6849]

Good points Mark, Thanks!

After reading your thoughts, I think the safe way to what I'm talking about is to modify the parameters that are passed to SendCommand. New parameters could be something like sBOT, sNodes, sEOT, bPriority, iNodeID.

In this manner, it would be much easier to trim sNodes and this could be done very reliably (I think).

If sNodes' length before or after trimming became zero and the command length (sBOT + sNodes + sEOT) is greater than 80, an error would have to be thrown.

The neat thing is if sNodeIDs is trimmed, SendCommand could automatically send another command out for the trimmed NodeIDs using sBOT + sTrimmedNodeIDs + sEOT, but with some exceptions for group and scene commands (these would be filtered by testing that iNodeID < 232 or whatever the limit is).

I'm not sure of any consequences, but it appears simpler to implement than my first idea. I'll have to do some serious study of the protocol before making this type of change though. The benefit may not be worth the level of effort this would entail too, so I'll think about that. I'm probably one of the few Premise users who use enough nodes to approach this 80 character limit, so I may just choose to live with it and throw an event error only.

 

[mhilbush]

The driver has been running for a couple weeks, and I don't see any changes that are needed immediately. Feel free to post in the downloads section whenever you are ready.

In your post, can you make sure to point out that the sensor functionality has been tested with only 3 devices:
- HomeManageables HM-DW001 Door/Window Sensor (same as Everspring SM103)
- HomeManageables HM-FS001 Flood Sensor
- ACT ZIR000 PIR Motion Sensor

There are a number of things that I will look to do in the next rev:

- Clean up some of the sensor code; nothing too severe - mostly some naming conventions to make code maintenance a little easier

- There are a couple challenges with these battery-powered sensor devices that I need to accomodate, which in the process might become a positive. Right now, if you try to send a command to a sleeping device, the device will not respond and the VRCOP will report an error. In fact, based on the way reties work, it will try three times and get three errors. Examples of these commands would be RequestBatteryReport, SetWakeupInterval, SetMultisensorAutoreportInterval, SetMotionDetectorOffDelay, etc. Devices are awake only when they are powered on and for a brief time after they send a wakeup notification. Because of this behavior, commands destined to a sensor device should be queued until the wakeup notification arrives, at which point the driver should send all queued commands. And, there needs to be a method to manage the size of the queue (e.g. remove duplicate commands), as these devices can be configured to sleep for a long time. Rather than build this functionality into the driver's job queue, I am thinking that each instance of a sensor device should have its own queue, which can be processed when the device wakes up. I believe this will become even more important with Multilevel Sensors. Let me know what you think.

- We might want to think about changing the structure of the "Node General" section (case 12) of ViziaRF.OnChangeOnNewData. Right now, the case statement operates off the number of parameters in command received from the VRCOP; however, it might be better to work off the command class (i.e. aParms(1)). The processing of each command class can/should determine how many parameters it got/expected. This should make it is a bit more straightforward to add new command classes.

- Finally, I would like to add support for Multilevel Sensors, such as the HM-TS001 Temp/Humidity sensor. This will take some thought, as each ML Sensor can/will report only a subset of the available sensor values. Potential list of values is here: http://code.google.com/p/open-zwave/source/browse/trunk/cpp/src/command_classes/SensorMultilevel.cpp.

 

[etc6849]

From a structure standpoint, it may be easiest to decide which queue will always receive priority use of the VRC0P... I'm thinking the job queue class should always have priority since lighting is something a user will notice a delay in. Before this is done though, I would thoroughly research whether or not a "wake-up" command exists.

If there is a wake-up command, it would be easy to modify the module to first try the command and if that fails, issue a wake-up command automatically followed by the command. Alternatively, one could always issue the wake up command immediately followed by whatever query command is needed (even easier to implement).

Questions about sleep:
My understanding about sensors is that they immediately send a response to the VRC0P upon trigger even if they were initially a sleep... I think your situation is that if a sensor is asleep, it will not respond to non-priority events like battery status queries?

Also, will the sensors still route messages to neighbors during sleep mode (or do the sensors not act as routing slaves)? Do the new Z-Wave locks go to sleep? If so, we may want to include them in this new type of queue since I'm sure we'll want to know battery status.

 

[mhilbush]

From a structure standpoint, it may be easiest to decide which queue will always receive priority use of the VRC0P... I'm thinking the job queue class should always have priority since lighting is something a user will notice a delay in. Before this is done though, I would thoroughly research whether or not a "wake-up" command exists.

If there is a wake-up command, it would be easy to modify the module to first try the command and if that fails, issue a wake-up command automatically followed by the command. Alternatively, one could always issue the wake up command immediately followed by whatever query command is needed (even easier to implement).

Questions about sleep:
My understanding about sensors is that they immediately send a response to the VRC0P upon trigger even if they were initially a sleep... I think your situation is that if a sensor is asleep, it will not respond to non-priority events like battery status queries?

Also, will the sensors still route messages to neighbors during sleep mode (or do the sensors not act as routing slaves)? Do the new Z-Wave locks go to sleep? If so, we may want to include them in this new type of queue since I'm sure we'll want to know battery status.

I don't believe there is a command that will wake up the device. And, from the docs I've seen, whether it is from the wakeup notification report or when the sensor is triggered (e.g. temp threshold reached), the sensor remains awake for only 10 seconds before going back to sleep.

I think the concern about prioritization could be handled, since the queued sensor commands (cached may actually be a better term to describe the intended behavior) still will flow through the main job queue, and could even be assigned a lower priority than other commands. In addition, I would expect the volume of these commands to be extremely low -- partly because there's not a need to communicate all that frequently with the sensors and because the interval between wakeup notification reports is typically long (e.g. the default interval is 4 hours). It's also unlikely that all or most sensors in the network would wakeup at the same time.

Sensors don't act as routing slaves.

I don't know how the locks behave, but it's a very good question. I would hope the locks issue battery level reports or, minimally, a low battery alarm.

 

[mhilbush]

I could use a little advice on how to accomplish something in Premise.

I'd like to be able to set a sensor's config parameters by creating some properties and methods for sending the config commands to the sensor. However, each sensor model has its own unique config parameters. For example, the HM-DW001 Door/Window sensor (a.k.a. the Everspring SM103), allows you to set the off delay using config parameter 2 (e.g. >N006SE112,004,002,001,060 would set a 60 second off delay); whereas the HM-TS001 temperature/humidity sensor allows you to set the "temperature trigger on value" using config parameter 2. Problem is that the Sensor class (and any sensor class derived from it -- BinarySensor, AlarmSensor, MultilevelSensor) is a generic class that should apply to all sensor devices irrespective of the device's manufacturer/model (e.g. BinarySensor needs to work for any manufacturer and model of motion detector, door/window sensor, etc.).

So, within module ViziaRF, I'd like to define a separate set of classes for the manufacturer and model of the sensor (e.g. a class for the HM-DW001 door/window senssor, a class for ZIR000 motion sensor, a class for HM-TS001 temp/humidity sensor, etc.). These classes would encapsulate the properties and methods used to set/get the model-specific configuration parameters. This part is easy and I know how to do it.

What's not clear is how a sensor class can inherit from the manufacturer/model specific class. I don't believe that the binding can occur in the class definition of the sensor (because until a specific instance of the class is instantiated, you don't know which model to associate with the device). It needs to occur once an instance of the sensor class has been created under Devices.CustomDevices.ViziaRF.Devices.{instance of sensor class}. And, I also don't think it can be done during device discovery, since the device does not report it manufacturer & model at that time, nor am I aware of a VRCOP command to request that information. It almost needs to be done manually in Premise Builder in a way similar to how you bind a Device to a Home object.

I hope this is making sense. I'll stop here and see if there are questions/suggestions about what I'm trying to do.

Thanks,
Mark

 

[etc6849]

If I understand all this correctly, which I may not since I don't have any of the devices you're talking about, I would have the VRC0P first assign them most generic type of class when it discovers a sensor; e.g. assume it's not manufacturer specific or the most common, but would involve building an entire new class.

After the node ID is discovered, it sounds like the user then should manually "transform" it to the correct type for a specific manufacturer. You'll have to use edit the XDO file directly, but here's how to create a transformable object:
http://www.cocoontech.com/forums/index.php?showtopic=13850&st=0&p=117762&hl=morph&fromsearch=1&#entry117762

I've never tried this, but 123 is very knowledgeable so it should work fine. I think there must be a way to retain the nodeID and device name during this transform. You may want to down the Elk M1 module and study how transforming works.

EDIT another idea:
You might also explore placing all of these special methods and properties that are manufacturer specific into standalone module classes. Then, add an "Object Reference" property to the sensor class. There would then be a multivalue that the user would click on listing the manufacturers/models. You would build onchangescripts that would make a hidden device object of the selected manufacturer/device, then bind it to the "Object Reference" property.

Sensor's methods could then access the methods or properties of the referenced object, but would first check the type of the referenced object.

I never tried this idea either, but it seems like it could also work.

 

[mhilbush]

Thanks. I think I have this sorted out, although I'm not certain it's the most elegant solution.

I can add a child object on the device. The child object contains the manufacturer and model specific config parameters. This approach seems to work, and might even be extended to all devices if there is a desire to set config parameters on other devices (dimmers, switches, thermostats, etc.). If anyone has a better alternative than the approach I took, I'm open to suggestions.

Here's what it looks like:

Devices view


Here's the property page of the HM-TS001 showing three of the 8 supported config parameters.


Lastly, here's how it looks in the Home view:



On an unrelated topic, what do you think about my one suggestion from a previous post:

- We might want to think about changing the structure of the "Node General" section (case 12) of ViziaRF.OnChangeOnNewData. Right now, the case statement operates off the number of parameters in command received from the VRCOP; however, it might be better to work off the command class (i.e. aParms(1)). The processing of each command class can/should determine how many parameters it got/expected. This should make it is a bit more straightforward to add new command classes.

I took a run at making these changes, and I think it will make development easier in the future, especially when it comes to adding support for additional command classes.

 

[Odeen]

Hi guys,

I was wondering if either one of you tested the new module with the (in)famous Intermatic CA9000 PIR. They're cheap and can be powered with an AC adapter. I bought a few and I haven't been able to get them to work with Premise. At best, I have them activating a light switch directly.

Since I bought a few extras for myself, I'd be happy to send one to whoever wants to test it and get it working. It'd be nice to be able to read ambient light level, or check battery status, etc.

 

[mhilbush]

I was wondering if either one of you tested the new module with the (in)famous Intermatic CA9000 PIR. They're cheap and can be powered with an AC adapter. I bought a few and I haven't been able to get them to work with Premise. At best, I have them activating a light switch directly.

Since I bought a few extras for myself, I'd be happy to send one to whoever wants to test it and get it working. It'd be nice to be able to read ambient light level, or check battery status, etc.

From what I just read online about the CA9000, I'd be a little surprised if at least the basic stuff did not work with the version of the ViziaRF module most recently posted to this thread -- assuming of course that you've successfully added it to the network, updated the VRCOP, and created an association to the VRCOP. And, at least for now, if it's a MultilevelSensor it won't work -- I'm adding MultilevelSensor support now. BTW, when I say basic stuff, I mean command classes like Basic (i.e. state change), Wakeup, and Battery.

When you run the ViziaRF module's discovery process, it should be discovered as a BinarySensor and added to the device list. From there you can bind it to a Home object (e.g. motion sensor).

Nonetheless, I would be happy to test one if you wanted to send it to me. If you want to do that, just PM me and I can give you shipping info.

I'm also adding support for configuration parameters. From what I've been able to find online, the docs for the CA9000 are sketchy at best, so I can't see what config parameters the CA9000 supports (e.g. off delay, luminance level, etc.). If you have anything that describes this, please point me to it.

 

[mhilbush]

Thanks. I think I have this sorted out, although I'm not certain it's the most elegant solution.

After a few changes, I'm pretty happy with how this turned out.

Here's what it looks like:

Here's the Devices view.


Here's the property page of the MultilevelSensor showing the selected device model HM-TS001 (chosen from a drop down list).


Here's the property page of the HM-TS001 showing 3 of the 8 supported config parameters (haven't implemented the other 5 yet).


Lastly, here's how it looks in the Home view with the actual temperature from the sensor.

 

[etc6849]

I think I remember doing something similar with children when I made the W800RF32 module: http://www.cocoontech.com/forums/index.php?app=downloads&showfile=159

Nice work! I didn't use multivalues, but I think this is a great feature. It appears that the VRC0P will discover the device, then later the user can give more specific info if needed.

The "Object Reference" idea from earlier might be able to clean up the code somewhat, but is really very optional. What it would allow for is the ability to refer to a common object name, no matter what the user selects for the child. For example, if the Object Reference is named "SensorDetails", you could reference the user created child from within the sensor class like this: this.SensorDetails.somePropertyOrMethod. I'm not good enough at programming to know if this would make the code cleaner, just a suggestion and probably not worth the effort. You'd still need to create the child, but would make it hidden and set SensorDetails = this.someChildName.

PS: Thanks Odeen for the kind offer and welcome to the Premise forum. I would send the device to Mark as I don't have any need for additional motion sensors at this point and use an Elk M1G for that.

 

[mhilbush]

Nice work! I didn't use multivalues, but I think this is a great feature. It appears that the VRC0P will discover the device, then later the user can give more specific info if needed.

Yes, this is exactly the intended behavior. This way, the sensors work fine "right out of the box". Only if you want to tweak the config parameters do you have to mess with the model specific stuff.

The "Object Reference" idea from earlier might be able to clean up the code somewhat, but is really very optional. What it would allow for is the ability to refer to a common object name, no matter what the user selects for the child. For example, if the Object Reference is named "SensorDetails", you could reference the user created child from within the sensor class like this: this.SensorDetails.somePropertyOrMethod. I'm not good enough at programming to know if this would make the code cleaner, just a suggestion and probably not worth the effort. You'd still need to create the child, but would make it hidden and set SensorDetails = this.someChildName.

You're right. This would make for a cleaner implementation. In fact, I was wondering if there was a way to do this, as I don't like how the model name complicates things. I'll see if I can make this approach work.

 

[mhilbush]

Posting this as discussed in my PM to you.
Mark