atadistance

Notes on the Intermatic Z-Wave InTouch PIR Motion Detector - CA9000

29 posts in this topic

good notes. i find the sensor works perfectly so far for simple assocations. have you tried using it for alerting?

Define alerting, please.

What I have working is: walk into the room (in sensor range) and the two lamp modules turn on. After X minutes (as set by the pulse slider), the lights turn off if the room is empty.

I discovered that the PIR modes didn't mean what I thought they did.

In x-minute mode, the sensor is checking more or less continuously. If it senses something, it activates the devices and leaves them on for x minutes. Thus, in pulse mode (where x is a fraction of a minute), the lights go on and off every twenty seconds or so (not quite what I wanted).

It also appears that if you turn a light off manually using the module, after the PIR has turned it on, the PIR does not resend the "on" signal within the x-minute time period.

Share this post


Link to post
Share on other sites

"Alerting" is basically what I want.

That is, the unit sends an "I'm on" on the network (to a controller such as the computer interface?)

This appears to NOT work.

I've attempted associated the unit to itself, and also to the interface. Neither results in anything showing up at the controller.

Oh, it also won't respond to a poll.

So if you want the sensor to actually alert a central control device (e.g. a computer running software that talks to Zwave), it appears you can't. The PIR appears to work only for local control of a scene associated with it.

To say this sucks big bananas would be the understatement of the week.

Share this post


Link to post
Share on other sites

Never mind.

Nothing like hacking the hell out of it to figure out what it wants to "eat".

Its working.

Now if the battery life is REASONABLE, I'll be happy.

Share this post


Link to post
Share on other sites
Never mind.

Nothing like hacking the hell out of it to figure out what it wants to "eat".

Its working.

Now if the battery life is REASONABLE, I'll be happy.

[semi-rant]

This is where the lack of documentation and availability of the z-wave protocol really hurts. Had the official developers kit been more available to you (someone not trying to get rich off the product) then you could possibly have used the Zniffer and documentation to see what was going on in the communication between the two devices. Instead you are left guessing and it ends up taking ten times as long for you to develope an application to a protocol(RXC0P) which is supposed to be open and documented itself.

[/semi-rant]

Share this post


Link to post
Share on other sites

/RANT ON

Well if they think I'm going to BUY documentation on an alleged OPEN PROTOCOL when I give away the software in question they're out of their frapping mind.

Leviton has absolutely zero excuse. They sell an interface, they damn well ought to document each and every command it accepts along with its parameter set, and the state machine that is running inside it.

As I said, I have done this crap for a living now for 20 years, including controllers for satellite earth station equipment (microwave amplifiers, antenna positioners, etc)

What passes for "documentation" in this business (and this is not limited to Zwave - its true of virtually EVERYTHING when it comes to home automation) should result in the so-called "engineers" being strung up by their toenails and beaten with a cane until dead, THEN shot.

I've dealt with this now for more than seven years with various manufacturers and frankly, I'm sick of it. There is not a snowball's chance in Hell that I would ever sell a software package in this space nor would I do a "professional" installation for a homeowner for money, because without full and complete documentation I have absolutely no means of meeting MY standards for a quality, merchantable product.

That doesn't mean that my software doesn't work - it does, and very well.

It does, however, mean that I can't sell it as a commercial product because what I need to be able to do that with what I consider to be a normal level of commercial compentency is simply not available.

It appears that ALL of the vendors and "protocols" in this space, from X10 onward, all think of this as some sort of cute hobbyist TOY.

Well, if that's how Leviton, Intermatic and others see it, that's fine. I'll do what I've been doing - hacking my way to getting the damn thing to work, and then publishing my code, as I've done since 1999. If others find it useful, great.

But the disclaimer will remain - "NO WARRANTY" - and it means what it says, because without MEANINGFUL documentation and support from the vendors involved you have ZERO chance of producing a commercial-quality product.

/RANT OFF

Share this post


Link to post
Share on other sites
Well if they think I'm going to BUY documentation

Unfortunately, you have to pay to see how bad the documentation truly is.

Share this post


Link to post
Share on other sites
It does, however, mean that I can't sell it as a commercial product ...

I get the feeling that we're not supposed to be selling anything related to Z-Wave unless we are official, due-paying members of the club, submitting our products for review and inter-operability testing. Supposedly, that's the only way to guarantee that the average end-user has a good experience.

(This inter-operability model seems to be unraveling at a certain level. I talked to the InTouch people at C.E.S. about the troubles I've had with my CA9000 PIR. They said that I wouldn't have had those troubles if I had also purchased the InTouch base station and remote. More recently, I found that I couldn't add my RZC0P to my network using my Intermatic controller; it was intended that I use the Leviton remote to add the RZC0P. They ought to state on their packaging and on their web pages that these products require other products from the same product family.)

I think we are right where we are supposed to be in the food chain...scavengers. While we'll never be the main course on somebody's menu, we should be thankful that we've found as many crumbs as we have. The RZC0P and its few pages of documentation was a tasty morsel. The ControlThink SDK has been pretty filling as well. And we can be thankful that the big boys have left us some other random scraps to supplement our diet.

We could succumb to our pride, buy ourselves a $5000 skin change, and start swimming in open water, but think of all the rules we'd have to obey - and the pressure to perform. I'm content to live in a hole.

Share this post


Link to post
Share on other sites
I get the feeling that we're not supposed to be selling anything related to Z-Wave unless we are official, due-paying members of the club, submitting our products for review and inter-operability testing. Supposedly, that's the only way to guarantee that the average end-user has a good experience.

The actual rule as I know it is you are not allowed to put the Z-Wave logo on your product unless it has gone through the certification process. I don't think there is anything wrong with writing software and providing it as is. The ControlThink PC SDK and the RZC0P were created and made available to the general public so it's fair game.

...

So we have come to the conclusion that the documenation is not what it should be. I'm wondering if we should collaborate and write our own documentation for the RZC0P and make it available via Z-Wave World and anyone else who wants to host it. My thoughts are to provide code examples in C# VB.net and C++. We would also want to add diagrams and any other figures to more easily depict what needs to happen. Are you up for the task Genesis? I know it's asking a lot since we would basically be doing someone elses job for them but at the same time its nice to be able to help the next guy that comes along.

Share this post


Link to post
Share on other sites

Unfortunately there isn't any way for me to know what's "there there".

Oh, and don't expect the various modules of the same type to behave identically. They don't. The most obvious (but not only) example is that the Leviton wall switches return an extended status on an update, while the plug-in Intermatics ONLY send status back in response to a poll.

Still other devices (e.g. the PIR and the Leviton master) refuse to respond to a poll at all.

So for now my best suggestion if you want to see what I've discovered and implemented is to look at the HomeDaemon-zwave.c module :wacko:

The good news is that it works and the next full release of the software will split out the X10 module (its currently part of the "core", so you pretty much need to run it to use HomeDaemon) so you have the option to use Zwave only for lighting control and leave the X10 drek on the wayside.

With that said, when it comes to "occupancy" the X10 "hawkeye" system still looks like the cheapest and best "bang for the buck"; the Intermatic PIRs are fairly large and while they seem to work well they're also expensive. If you're trying to use them for occupancy sensors (which I do all over my house) sticking those things in every room will make you bleed money.

The converse site, however, is that the response time of the system when you're talking all ZWave devices is blindingly fast compared to the X10 stuff.

Share this post


Link to post
Share on other sites
I'm wondering if we should collaborate and write our own documentation for the RZC0P...

We might want to group all of the threads spawned by such an effort under a new forum heading.

I think we might be able to pull this off if we follow the format used in Leviton's RZC0P programming document, rather than spilling snippets from proprietary documents all over the place. For example, Leviton tells us that a GET command to the multilevel sensor at node 4 is formatted as:

>N4SE49,4

This manner of documentation focuses more on the RZC0P command format than it does on the proprietary command class document from which this information was drawn.

I don't know if we could get away with presenting this same information in a comprehensive tabular format such as:

MultilevelSensor = 49

MultilevelSensorLevelGet = 4

MultilevelSensorVersionGet = 1

BinarySensor = 48

BinarySensorStatusGet = 2

BinarySensorVersionGet = 1

The more information we add to such a table, the more it's going to look like proprietary Zensys information, and the less it's going to look like an RZC0P document.

But trying to present a comprehensive list of RZC0P commands could get messy:

<N004:049,005,xxx,yyy,zzz... -Multilevel Sensor Report

>N4SE49,4 -Multilevel Sensor Get

<N004:049,001,xxx,yyy -Multilevel Sensor Version Report

>N4SE49,1,xxx -Multilevel Sensor Version Get

<N004:048,003,xxx -Binary Sensor Report

>N4SE48,2 -Binary Sensor Get

<N004:048,001,xxx,yyy -Binary Sensor Version Report

>N4SE49,1,xxx -Binary Sensor Version Get

Share this post


Link to post
Share on other sites

<about to be naughty>

From the Leviton RZC0P document:

4.8. FI – find node ID with requested basic, generic and specific properties.

This command allows finding network node ID for the Z-Wave node with certain basic, generic and

specific classes. It maybe used during installation procedure as well to check if a node is in the routing

table.

>[?]Fibbb,ggg[,sss[,III]]

where

bbb – basic class number

ggg – generic class number

sss - specific class number

III – instance number for the device (between 1 and 232).

If any of the class numbers (bbb,ggg,sss) is 0, the command will search for any device.

The instance number (1-232) will reference on the instance in the routing table for certain device.

Basic class and generic class are mandatory fields, specific and instance fields are not.

If specific field is missing it assumed 0. If instance class missing it assumed 1 (the first instance).

Zensys specifies only 4 valid basic classes:

Controller – 1

Static controller - 2

Slave - 3

Routing Slave - 4

For the generic and specific classes refer to the Zensys device class specification. For example switch

device will have ggg=16, dimmer ggg=17, thermostat ggg=8.

After implementing the search found devices will be added to the current group. So you can store the

current group or send any message using this group.

If ‘?’ is set before the command interface it will report back the NodeID found as <Fxxx where xxx is a

node ID for the device.

If no devices have been found to satisfy the conditions an error message will be returned

<E010

If they had permission from the Alliance to publish anything at all, then why did they stop there? Why didn't they give us a full list of generic classes:

generic controller ggg=1, static controller ggg=2, display ggg=6 garage door ggg=7, thermostat ggg=8, window covering ggg=9, repeater slave ggg=15, binary switch ggg=16, multilevel switch ggg=17, remote switch ggg=18, toggle switch ggg=19, binary sensor ggg=32, multilevel sensor ggg=33, pulse meter ggg=48, entry control ggg=64, semi-interoperable ggg=80, non-interoperable ggg=255

(I'm trying really hard like Leviton did to avoid creating anything that might look like a table.)

Share this post


Link to post
Share on other sites

It'd be even nicer if ">Fi" or ">?Fi" worked. All I get back are parser (<Exxx) errors.

Check - its "FI", not "Fi" (gee, shall we doc things correctly? :) )

Share this post


Link to post
Share on other sites

From a discussion on the InTouch Forum:

When you include the PIR, be sure to send it a Wake Up Interval Set frame. If the PIR does not recieve one, it assumes that the controller cannot handle non-listening devices and remains awake all the time.

and

You need to send the PIR a Wake Up Interval Set frame in order for it to go to sleep and wake up periodically. The PIR will wake up every interval and check in with the specified check-in node. Until the PIR is sent this frame, it does not go to sleep because it cannot know when a device will try to communicate with it.

Now that we've seen some RZC0P commands, I finally understand what RedOx meant by "Wake Up Interval Set frame."

So we'd be using the RZC0P to send something like this to the CA9000:

>N4SE132,4,000,000,060,2       //wake up interval, set, seconds MSB, seconds, seconds LSB, Node ID to receive notification

Other Wake Up Interval commands would be formatted as follows:

>N4SE132,5                     //wake up interval, get
<N004:132,006,000,000,060,002  //wake up interval, report, seconds MSB, seconds, seconds LSB, Node ID to receive notification
<N004:132,007                  //wake up interval, notification
<N004:132,008                  //wake up interval, no more information

This whole thing brings up more questions than it answers. If the PIR goes to sleep and wakes up periodically and sends a notification to some other node when the PIR wakes up, why does that other node need to know that the PIR is awake? If the PIR is asleep will it sense motion? Does the PIR wake up immediately when it senses motion regardles of whether the timer has expired? Or does the PIR hold on to the motion event that occurred while it was asleep and wait to notify group members until it wakes up? Is the node that receives the wakeup notification also a member of the group that gets toggled during a motion event. Can more than one node be notified of a wake up event? If the node that receives the wakeup notification is not the same as the group node(s) which receive motion events, What kind of node should be notified of the wake up? What does "no more information" mean? What is the suggested wake up interval if I'm running on batteries?

Share this post


Link to post
Share on other sites

It appears the answers are as follows:

1. If a wake-up interval is set, the unit WILL immediately report if in "Pulse" mode.

2. It does NOT flash the front-panel LEDs if it has been sent a "sleep" interval; it DOES if that's zero.

However, I see no specific check-in frame being sent on the commanded interval. That is, if I set the interval to 60 seconds, I do NOT get a frame from the PIR every 60 seconds, so I'm not quite sure what the actual time delay specified allegedly does, since it DOES wake up immediately and transmit if it sees motion.

Recommended sleep? I guess it depends on the application, if it really does anything at all other than differentiating between zero and non-zero! I am going to attempt using ~5 minute intervals and see if that works reasonably well in terms of battery life while not compromising anything else.

WHY CAN'T THE MANUFACTURERS DOCUMENT THIS CRAP ON THEIR DATA SHEETS?!

Edit: Ok, I'm wrong. It IS sending a 132,7 status on intervals, but the intervals at which it sends it have NOTHING to do with the "sleep time" set. That is, I can set it to 60 seconds, 4 minutes, etc - I still get a frame back at approximately the same interval. Sometimes.

Cute eh?

Here's another interesting item - apparently the PIRs will report their battery state as a percentage. I don't know if this value is bullshit or not, but I'm going to start tracking it and see if it makes sense - if it does, that'll be very nice for knowing when you need to go change them!

Share this post


Link to post
Share on other sites

It looks like Chris Walker answered my questions about the wakeup notification a long time ago.

The wakeup command basically lets a "smart controller" know that the device is awake in case there are any queued-up commands to send. If it doesn't hear anything back, or there's no business to conduct, the device goes back to sleep.

Thanks Chris!

So if you've got control software running on one of your Z-Wave nodes, and if that software ever sends configuration or association or get commands to the PIR in question, then your control software needs to buffer those commands, making sure that the PIR is awake before sending those commands.

The PIR needs to be programmed to send wakeup notifications specifically to the node where your control software resides, and the wakeup interval on the PIR needs to be set to whatever your control software can live with. If you are polling for battery status, then you might want the PIR to wakeup maybe twice as frequently as the polling interval. If you don't have control software, then just pick any node in the network for the PIR to send its wakeup notifications. If your control software never sends PIR commands, then the PIR can sleep for a very long time indeed.

Share this post


Link to post
Share on other sites

The documentation for ACT's ZIR000 is far superior to that of the CA9000. Most of the information we need in order to talk to the ZIR000 using the RZC0P is there. The only information lacking is regarding assigning return routes, but I'm not ready to go that deep anyway.

I bought the CA9000 because I thought the ZIR000 was ugly...

HomeSeer's HSM100 is the other PIR currently available, but the functionality for that unit is locked away inside HomeSeer's software, much like InTouch locked up their PIR's functionality inside the remote/base unit.

By the way, the CA9000 used to be available for sale on HomeSeer's site but is no longer.

Share this post


Link to post
Share on other sites

Gary, what's important to understand here is that what is claimed and what actually happens are two different things. Bluntly, you have to be prepared for "interesting" behavior from these devices.

Specifically, you can set whatever wakeup interval you want, but you will see notifications from the PIR on roughly 20 second intervals, irrespective of what you tell it.

Second, if you send a battery poll, it will get answered, and fairly quickly. Since my code handles async events without problems, whether I get it back synchronously doesn't matter.

Third, the battery life is markedly better with the "sleep" frame set. Right now I'm showing 99% battery on a set of NiMH cells which have a self-discharge rate that likely would render them effectively "dead" within 100 days, and I put them in (fully charged) yesterday. I will put some Alkalines in there once I get a handle on how long NiMHs will run; those are even better as I can recharge them, of course. If I get three months of life on a "charge" then the unit is basically limited by the self-discharge rate on those rechargeable cells. That works.

One other thing - when the batteries get low, if you don't change them, the unit will go "insane" and start sending frames without being prompted - and it won't stop either. And no, they're not battery frames - they're "no more data" frames, punctuated with (sometimes) notifications of motion detected.

Share this post


Link to post
Share on other sites

Ok, after REAMING the folks over at InTouch, I got an answer to the protocol question - a real one.

That shouldn't have been necessary (this stuff should ALL BE DOCUMENTED Mr. Zwave "alliance!") BUT I'll take it any way I can get it.

The code in HomeDaemon has been appropriately adjusted, and now since I have an actual documented description of what's necessary, I can actually claim that these PIRs are supported.

Share this post


Link to post
Share on other sites

Are you allowed to share the details here? This seems to be one of the more complete discussions on the subject and will make a great reference in the future for others that come along.

Share this post


Link to post
Share on other sites

The thread at InTouch Forums is here. Unfortunately, the thread is now locked. I'm afraid things got a bit flamey. I'm kind of ashamed. After all, most of us are in this to have fun. I applaud RedOx for keeping his cool...definitely a class act.

I am pleased that a format seems to be emerging for documenting the commands. The best example so far has been ESI's DBMH document. InTouch seems to have followed suit with the document snippet they published earlier today. Hopefully the Alliance can lend their support to a documentation format such as this that will provide us with the information we need while protecting the proprietary structure of Zensys'command frames.

By the way, Chris Walker over at ControlThink says support for the wake up command class will be coming soon in the next version of the PC Z-Wave SDK. So we Windows programmers will have a way of setting up the CA9000.

Share this post


Link to post
Share on other sites

Well, it got flamey because I do NOT like being jerked around, and that's exactly what was going on.

There is absolutely NO REASON WHATSOEVER to keep "proprietary" the command byte sequences that are used to control a device you sell! None! Period!

How the hell is anyone supposed to program a device to TALK TO this supposed-interoperable "standard" without the documentation?!

There is no purpose to Leviton selling an interface, for example, if there is no available documentation.

Share this post


Link to post
Share on other sites

I don't think anybody is jerking anybody around...yet.

I was able to meet some Z-Wave developers at C.E.S., and they have all been busy fighting a very steep learning curve, with Zensys nursing them along every step of the way, trying to get their products through interoperability and qualification testing.

The InTouch boys at C.E.S. seemed glad just to have a product on the market that worked within their family of devices. They have only just begun to consider the possibilities of people using their individual pieces beyond the product family. The fellow I talked to seemed surprised that I was even trying to get the CA9000 to work without the base.

I think the individual players are just beginning to consider what can be done with the documentation within the constraints of their agreements with the Alliance.

If you want to get jerked around, I know the perfect automation company for you to contact. They've taken what was supposed to be an open wireless standard and totally closed it to outsiders. They treated me like crap at their C.E.S. booth last year, and they were being jerks in real life when I quietly observed them on the plane to the show this year.

My impression of the Z-Wave crowd so far is that they are honest and sincere. Most of them have as many questions about the standard and are stumped as often as the rest of us.

Share this post


Link to post
Share on other sites

Well, I disagree.

Intermatic makes the device. Its their document, not the "ZWave Alliance's".

I can see an argument for them not being able to release someone else's documentation which they have been given under NDA. That not only makes sense, its normal commercial reality.

But their documentation is owned by them.

In reality I think the "Zwave Alliance" should publish all of the docs on the various devices and their command sets. Is not the point interoperability? Well? Do they really mean it or not?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now