Premise Zwave sensors

[etc6849]

I've been playing with an idea of using the Vizia RF+ switches to perform additional tasks based on the number of presses over a period of time! For example, if a user presses a switch near a door 3 times in 5 seconds, all lights in the home could go off and the alarm system could arm.

Another example is if a user wants to prevent occupancy timers from turning a light off, a home onchange script could watch for manual presses and disable the occupancy timer if a user: turns a light on, then off, then back on (all within in 5 seconds).

Link to topic: http://www.cocoontech.com/forums/index.php?showtopic=18377

(I put the topic there in hopes to gain input from anyone using the VRC0P for this type of thing).

Any thoughts? Should this be something I add to the module and if so would people use it? It's proprietary to Vizia RF/RF+ only...

 

[mhilbush]

1. The SetTamperAlarm only has one parameter, nodeID, but you pass two parameters from OnChangeOnNewData.
2. The default value property defines the defualt value for a device when it's constructed. You don't need the class constructor methods for each device type...

I'd like to send you an update with changes to address #1 and #2 above.
1. Modify SetTamperAlarm to include two parameters, AlarmType and AlarmLevel, both of which are provided by the device
2. Remove the constructor methods; set defaults as you describe above.

Is it safe for me to post a version with just these edits? It will require changes to the sensor device classes, as well as a change to OnChangeOnNewData.

 

[etc6849]

Feel free to post it. I only have two changes to add to the lighting stuff.

 

[mhilbush]

Here it is.

 

[etc6849]

Thanks Mark!

I'm comparing my old file with the lighting changes to yours in notepad++. One strange difference is your Schema XML Version is newer than mine? Any ideas on what the differences are? We should have the same version I thought since Premise hasn't been changed since 2006.

Picture is attached...

I'm sure you already use Notepad++ since you seem very good at programming. In case you don't, Notepad++ is a great tool for editing XDO files without clicking as much (or at least comparing two files by navigating to Plugins->Compare->Compare in Notepad++).

 

[etc6849]

Mark I can add this in for you, unless you're already working on it. Kind of sucks we have to use timers, but oh well.

EDIT: It was very easy to add so I modified it for you. So far this involved several additions under the sensor class. I also added a line of code to SetBatteryLevel to reset battery level alarm if a good value was received and added an event notification for low battery level to alert the user of a bad battery (event notifications show up in Builder after you log in).

One other thing I'm wondering about... Since these sensor devices send a Wakeup Notification event every 4 hours, there is an opportunity to detect if a device has stopped sending Wakeup Notifications, possibly due to a dead battery (not all devices appear to send battery level events) or some other reason.

The Sensor class has a property for tracking the last Wakeup Notification time; however, it's not clear to me how I would detect the absence of a Wakeup Notification event. By any chance, does the module have the ability to periodically (every 30 or 60 minutes, for example) iterate through the list of sensor devices looking for Wakeup Notifications that have not occurred? If detected, it could set a property that could be used to alert the user. Normally, this would be done by a watchdog thread, but I don't know if Premise supports such a thing inside a module.

 

[etc6849]

Here's the new version. I've implemented two new switch properties: LocallyManipulated and LocalManipulations to track manual presses of Vizia RF switches. I also made the changes previously discussed to the Sensor class.

I've also developed a new type of Home object called "LocalManipulations" that binds to the LocallyManipulated switch property (or any boolean property for that matter). The new home object is used to perform some action. I'll post this separate xdo under the downloads section this week sometime.

 

[mhilbush]

I'm comparing my old file with the lighting changes to yours in notepad++. One strange difference is your Schema XML Version is newer than mine? Any ideas on what the differences are? We should have the same version I thought since Premise hasn't been changed since 2006.

Picture is attached...

I have no idea why the versions would be different. I installed v2.1 build 15117. I looked at a couple different xdo files that I've exported, and I'm seeing a variety of version numbers.

 

[mhilbush]

EDIT: It was very easy to add so I modified it for you. So far this involved several additions under the sensor class. I also added a line of code to SetBatteryLevel to reset battery level alarm if a good value was received and added an event notification for low battery level to alert the user of a bad battery (event notifications show up in Builder after you log in).

Thanks for doing this!

 

[etc6849]

Doh! I just saw your post and realized I forgot to change the sensor timer from 15 seconds back to 30600 seconds... Use this file instead or make the change manually. That's what I get for trying to test something when I don't actually have the device I had it set to 15 seconds to check the code...

Thanks for doing this!

 

[etc6849]

same here. I guess it doesn't matter since my system has worked fine and rock solid for the year I've been using it. The file I posted had an even newer Schema XML revision number?!? I modified it from a different PC though.

I have no idea why the versions would be different. I installed v2.1 build 15117. I looked at a couple different xdo files that I've exported, and I'm seeing a variety of version numbers.

 

[etc6849]

Mark,

How's everything working with the new module? I don't have a zwave sensor yet, so please provide your comments

I think the last thing I'd like to add (this may not help sensors, but is a method we probably need before the zwave locks come out and the new VRC0P) is this:

We need some method of recording failed jobs and which nodes have them. I'm thinking this means I can add a new property to the device class called failed job count. Upon an initialization, discovery or construction of a new device these values would re-zero for every device. An event method would be called to alert the user after 20 failed jobs.

Why is this necessary? Well, the VRI06 dimmer does not return to neutral directly, so it requires the bulb to be working in order for the VRI06 to have control power! If we assume the VRI06 dimmer is Node 9 in the attached picture, the network will become slow to respond unless there's another path such as in the lower picture. Similarly, if the device was a lock and quit responding to the VRI06, an event would be created to alert the user after 20 X002 receipts.

I think after we both test this new version I'm working on, I can post this under the downloads section (unless you have further things to add).

 

[mhilbush]

Sorry for being silent for so long. I came down with a case of the flu after a recent trip...

How's everything working with the new module? I don't have a zwave sensor yet, so please provide your comments

So far so good. I was finally able to test a sensor in a low battery condition (see below).

I think after we both test this new version I'm working on, I can post this under the downloads section (unless you have further things to add).

I have three changes I would like to make:

- I finally was able to test one of the sensors in a low battery condition, such that it would send the low battery alarm. I will need to make a change to Devices.SetBatteryLevel to handle it properly.

- I've determined that some sensors send the WakeupNotification command automatically, and others need to be explicitly given the wakeup interval before they start sending the notification command. I've added three new methods (Devices.SetWakeupInterval, Sensor.OnChangeGetWakeupInterval, and Sensor.OnChangeSetWakeupInterval) and three new properties (Sensor.WakeupInterval, Sensor.SetWakeupInterval, and Sensor.GetWakeupInterval), as well as the necessary changes to OnChangeOnNewData. Question: Is there a way to determine the node ID of the VRCOP? The command to set the wakeup interval has the ability to tell the sensor the node to which the wakeup notification should be sent. It would be convenient to be able to explicitly tell the sensor to send the wakeup notification to the VRCOP.

- As part of the above change, I believe the timer you added should derive its wait time from Sensor.WakeupInterval. I would suggest a factor of 2.5 (e.g. if the interval is 4 hours, the timer would be 10 hours). If you are ok with this approach, it will require a simple change to Sensor.SetWakeupNotificationTimer.

I'd like to test these changes for a bit, then remove some debug statements, then send you a new version. Is that ok?

 

[etc6849]

A 2.5 factor makes sense for a watchdog and is a good idea. I'm stumped on how to get the nodeID of the VRC0P other than manual entry?!? This is a great question, one of us should call Leviton and see if they can forward it to their engineering department. FI sure wouldn't work since you could have many VRC0P's on a single network.

Here's what I have so far... I'm done with all of my changes other than going through the code and cleaning it up a little.

In this version I've made several changes:
-I added a new job count to keep track of job failures for each device and I've added an event to alert the user if a certain device has 5 failled jobs (the total tries would be 5 failed jobs * job retries which defaults to 3).

-I made the event method more generic and moved it up under Devices. I also modified the severity of all events since a failed device or a sensor with bad batteries is a bigger deal then just having a port reset.

-I made extensive changes to Groups for the case of groupID=0. Basically, I rewrote the methods to send one device at a time commands. This increases traffic, but is more reliable. I found out the hardway that if I send a group command to more than 27 devices all and once (i.e. >N1,2,3,4,...ON) the VRCOP will report back E002 since this overflows its command buffer!

-I fixed a small error I had in the dimmer and switch classes (I was calling SendCommand, but didn't specify the last two parameters NodeID and Priority level).

 

[mhilbush]

A 2.5 factor makes sense for a watchdog and is a good idea. I'm stumped on how to get the nodeID of the VRC0P other than manual entry?!? This is a great question, one of us should call Leviton and see if they can forward it to their engineering department. FI sure wouldn't work since you could have many VRC0P's on a single network.

Here are my changes:

- Change "Level" parameter in Devices.SetBatteryLevel from Percent to Number (needed to properly handle 0xFF low battery alarm).

- Changes to support getting/setting wakeup interval:
- Methods: Devices.SetWakeupInterval, Sensor.OnChangeGetWakeupInterval, and Sensor.OnChangeSetWakeupInterval
- Properties: Sensor.WakeupInterval, Sensor.SetWakeupInterval, and Sensor.GetWakeupInterval
- New code in ViziaRF.OnChangeOnNewData to support wakeup interval report command
- Added property ViziaRF.VRCOPNodeID to allow manual entry of the VRCOP's node id. This is needed to support setting the wakeup interval. The ViziaRF class seemed like the appropriate place to put this.
- Changed timer to derive the wait time from Sensor.WakeupInterval.

Mark