Genesis

HomeDaemon now has partial ZWave Support

21 posts in this topic

Ok, HomeDaemon PRE-V5.0 is now up on my web page at http://www.denninger.net

It includes PARTIAL Z-Wave support using the Leviton interface.

At present only switches and dimmers are supported. As soon as I have more devices, I will see what I can do about integrating them. If anyone would like a particular device supported, and is willing to part with one, let me know. Currently there is no support for things like thermostats nor is any planned, although they're not impossible to handle - I just have no intention of buying one at present as I use a hardwired ADICON protocol solution for HVAC.

It does poll and thus does pick up local changes (e.g. someone hitting a switch) but the delay is variable depending on network size. It attempts not to be TOO big of a pig with the RF, while at the same time making every attempt to keep things "timely."

In addition the HomeDaemon "not if unnecessary" code paths are not yet optimized, so no promises if you try to use them as to the results. Given ZWave's superior handling of transmission this should not be a big deal, even in a fairly large system.

There is still a fair bit of debugging info going into the syslog; this will go away when I'm happy with it.

At present, however, it does appear to be reasonably reliable - and quick.

I'll get the PIRs integrated as soon as I have one here (should be in another week or two), and am working on keypads as well.

No promises on stability - this is definitely beta quality right now.

HomeDaemon is a freely distributable (and usable) home control system designed for the FreeBSD operating system. It also runs on most versions of Linux, but is not officially supported on Linux machines. The software has been around and in active use since 1999.

Share this post


Link to post
Share on other sites

I'm just getting started using Ubuntu. I was wondering if there are any special instructions on getting your software to install on Ubuntu 7.10 and if so could you provide those to me?

Share this post


Link to post
Share on other sites
I'm just getting started using Ubuntu. I was wondering if there are any special instructions on getting your software to install on Ubuntu 7.10 and if so could you provide those to me?

Shouldn't be any special requirements, no.

If it compiles it will run. Note that the HomeDaemon-zwave module has had a couple significant edits put on it today and this is likely to continue - check back OFTEN for the next couple of weeks. There are some subtle timing issues that of course aren't documented, and it also appears that some modules make a habit of launching "surprises" (some post a separate response on the air to UPDATE commands, others do not!)

The Makefile (if you do a "gmake install") will leave configuration files alone and replace binaries, so its "safe" to run more than once.

The only situation that arises with the various Linux implementations is that some of them stuff things in funny places (e.g. header files and such) and as such occasionally there is a problem with compilation failing.

If you're new to Linux and can't fix this but are willing to provide me a login on the box where the software is I can SSH in there and see if I can figure out what's not building correctly if you run into trouble.

(BTW my home has been running on this package since '99 and has over 300 events in the control file, a Leopard in the family room for touchscreen control, and all HVAC, Pool and Spa equipment operating off hardwired ADICON modules. Temperature sensing is done via a small custom OpAmp board behind LM34s that go into the ADICON analog input module. ZWave looks interesting mostly because it solves the bugaboo of X10 - lack of reliable transmission and status reporting....)

Share this post


Link to post
Share on other sites
Shouldn't be any special requirements, no.

If it compiles it will run. Note that the HomeDaemon-zwave module has had a couple significant edits put on it today and this is likely to continue - check back OFTEN for the next couple of weeks. There are some subtle timing issues that of course aren't documented, and it also appears that some modules make a habit of launching "surprises" (some post a separate response on the air to UPDATE commands, others do not!)

The Makefile (if you do a "gmake install") will leave configuration files alone and replace binaries, so its "safe" to run more than once.

The only situation that arises with the various Linux implementations is that some of them stuff things in funny places (e.g. header files and such) and as such occasionally there is a problem with compilation failing.

If you're new to Linux and can't fix this but are willing to provide me a login on the box where the software is I can SSH in there and see if I can figure out what's not building correctly if you run into trouble.

(BTW my home has been running on this package since '99 and has over 300 events in the control file, a Leopard in the family room for touchscreen control, and all HVAC, Pool and Spa equipment operating off hardwired ADICON modules. Temperature sensing is done via a small custom OpAmp board behind LM34s that go into the ADICON analog input module. ZWave looks interesting mostly because it solves the bugaboo of X10 - lack of reliable transmission and status reporting....)

I'm not sure if you've gotten past the issues raised on your other thread, but it appeared as if you'd not replicated the network onto the Leviton controller. I've written a driver for CQC (charmedquark.com) and can perhaps add a few other insights.

If you've named your devices with the Leviton master controller, you can get the names using the >?NN command, after you've set up an initial node association with a >Nxxx. I loop over the devices with a >?Nxxx to get the level, then issue a >?NN to get the name. Don't bother setting up a big association list and then expect to get all the names with one query. It just doesn't seem to work consistently. One by one with delays between seems to work best, with retries for those that give errant or no responses. Sometimes you'll get a data reply before the <X000 ack, for example. As for setting names using >NN, I've never been able to get that to work. The delimiter character is not documented, and only a couple of characters seem to get set as the name and these don't seem to get pushed back to the master controller anyway. I just program the names with the Leviton master controller and then query them.

It also seems that some messages from the controller are CR terminated, while some are CRLF terminated.

The broadcast all-on/off commands (>N,ON) work intermittently. I found it better to build a list of all lighting nodes and create a group. Then issue an on or off command to the group. Note that when you create your group (>GSxxx) you'll get an undocumented <M000 ack. Also undocumented is the number of groups one can create. I've created group #999 successfully, but have no idea if there is a limit on the total number of them that can be created.

The BR and DI commands do not return a status of the new level, you have to send the, I think, >ST command. Also, append a ,UP to all lighting control commands except BR and DI to broadcast the new data to the rest of the network.

The >FI commands do work to identify nodes belonging to a particular device type. Try:

>?FI0,016,xxx for switches and

>?FI0,017,xxx for dimmers. The xxx is not the nodeID, its a 1-based index of devices of that type. Continue incrementing the index until you get a <X010 reply indicating no device of that type found at that index counter, Then start over at 1 with the next device type. When you find a device you'll get a <Fyyy reply where yyy is the nodeID. This way you can build a list of nodeIDs of a particular device type.

Share this post


Link to post
Share on other sites
I'm not sure if you've gotten past the issues raised on your other thread, but it appeared as if you'd not replicated the network onto the Leviton controller. I've written a driver for CQC (charmedquark.com) and can perhaps add a few other insights.

No, its been replicated. It appears that some modules (plug-ins, specifically) do not report as they should under many circumstances, including UPDATE commands and the "FI" commands. Hmmmm....

If you've named your devices with the Leviton master controller, you can get the names using the >?NN command, after you've set up an initial node association with a >Nxxx. I loop over the devices with a >?Nxxx to get the level, then issue a >?NN to get the name. Don't bother setting up a big association list and then expect to get all the names with one query. It just doesn't seem to work consistently. One by one with delays between seems to work best, with retries for those that give errant or no responses. Sometimes you'll get a data reply before the <X000 ack, for example. As for setting names using >NN, I've never been able to get that to work. The delimiter character is not documented, and only a couple of characters seem to get set as the name and these don't seem to get pushed back to the master controller anyway. I just program the names with the Leviton master controller and then query them.

It also seems that some messages from the controller are CR terminated, while some are CRLF terminated.

Yes, I noticed that, but it doesn't bother my code.

The broadcast all-on/off commands (>N,ON) work intermittently. I found it better to build a list of all lighting nodes and create a group. Then issue an on or off command to the group. Note that when you create your group (>GSxxx) you'll get an undocumented <M000 ack. Also undocumented is the number of groups one can create. I've created group #999 successfully, but have no idea if there is a limit on the total number of them that can be created.

The BR and DI commands do not return a status of the new level, you have to send the, I think, >ST command. Also, append a ,UP to all lighting control commands except BR and DI to broadcast the new data to the rest of the network.

I don't use those so it doesn't really matter in this particular case. If I want a given level, I command it...... so shouldn't get nailed there.

I also don't like scenes/groups in general - there's no real good reason to use them from my point of view. I prefer a discrete approach as it means I can track and report each individual command. Since the system keeps all state internally in a shared segment scenes/groups screw this up pretty badly, as correlation risk (the unit thinks something different than the definition file) gets out of hand. I prefer not to run into that.

The >FI commands do work to identify nodes belonging to a particular device type. Try:

>?FI0,016,xxx for switches and

>?FI0,017,xxx for dimmers. The xxx is not the nodeID, its a 1-based index of devices of that type. Continue incrementing the index until you get a <X010 reply indicating no device of that type found at that index counter, Then start over at 1 with the next device type. When you find a device you'll get a <Fyyy reply where yyy is the nodeID. This way you can build a list of nodeIDs of a particular device type.

Will... thanks.

I've put a couple of pretty significant timing-related edits on the code in the last day or two, adn this is likely to continue for some time as I find new "gotchas" - there are a bunch.

I hate manufacturers who build state-dependant devices but can't be bothered to include a state diagram in their documentation. What passes for "documentation" in this industry is absolutely laughable; I've been doing embedded control for a very long time and if I ever delivered something like this to my customers they would cut my head off.

Share this post


Link to post
Share on other sites

Ooook!

A bunch of additional edits went on the code today... I found some more "fun" from the interface that was pissing off the state machine in the code.

I think its stable now. We'll see.

Share this post


Link to post
Share on other sites

No edits last two days. Code appears stable, although I have some new device classes and manufacturers coming next week to integrate which may play havoc with that....

Share this post


Link to post
Share on other sites
Intermatic CA9000 PIRs now supported.

Congrats! Sorry you are having to go through so much trouble to figure things out. I wish I knew more about the RZC0P so I could help but I don't. Keep up the good work.

Share this post


Link to post
Share on other sites
Intermatic CA9000 PIRs now supported.

Congrats! Sorry you are having to go through so much trouble to figure things out. I wish I knew more about the RZC0P so I could help but I don't. Keep up the good work.

Share this post


Link to post
Share on other sites

I wish there was some damn documentation on the device classes, potential responses, etc.

This "hide the ball" crap and the amount of work it requires to code for something when you literally have to bash the information out of the device the hard way, then trap it, is total and complete BS.

As I've complained about before, I've been writing embedded control software for 20 years, and what passes for 'documentation' among devices like this is disgusting. Someone needs to take these manufacturers out, line them up, and then waterboard all their engineers and "marketing" people for a few weeks straight until they get a clue.

I went through a "light" version of this with ADICON; they supposedly "document" their protocol for the Leopard and their 422-driven modules but there are all sorts of "surprises" - even today (several YEARS after the original module was developed) there is code in my software that complains about undocumented (and unknown) frames coming on a regular basis from the Leopard - an async data stream for which there is no documentation among the claimed things the device can send you.

Leviton and the ZWave people in general should be ashamed of themselves. I'm used to this sort of "non-support" of so-called "Standards", but it still pisses me off.

If manufacturers expect people to support their stuff, they need to get off their butts and start documenting their interfaces!

Share this post


Link to post
Share on other sites

Ok, next one - Wall-Mount "Controllers"

You know, the 5-button "discrete" controllers that Leviton (and I assume others) sell?

Yes, those.

I have managed to get them to talk. Kinda.

Here's what I know at this point -

Once the unit is integrated and you use the HAI association to set a route path to the PC interface, you get the following for a button press:

<N006:145,000,029,012,000,001

Unit Type -- -- --- Btn State

<N006:145,000,029,012,000,002

The second one is for an "off" press.

Ok, so far so good. The "up and down" buttons flash the last button you pressed RED, and send nothing.

But - how do I SET the button state? That is, I'd like to be able to CONFIRM a button press by turning the LED on (or off), or have the controller do so as a "status" flag.

There is, of course, zero documentation on how to do that.

Anyone know what has to be sent to these beasts to make this work?

These will take a bit to get integrated into HomeDaemon, as I have to redefine a few things to cover the concept of "subunits" - and that gets a bit dicey the way the code is structured for a number of reasons having to do with "just once" events (e.g. trigger only on the button press, and only one time)

I think I can get around that, likely by forcing these types of units to be specifically declared once for each "subunit" (that is, a special "type" which causes multiple entries in the index table) but I have to think about it a bit. This is similar to how the X10 wall controllers work - they actually are separate "devices" for each button.

Does anyone know how to manipulate the LEDs on the controller?

Thanks in advance!

Share this post


Link to post
Share on other sites

OK, PRE-7 is now up which "supports" the in-wall controllers.

Kinda.

It will handle button presses but not the LEDs, since there's no damn documentation on how to turn them on and off!

Bastidges.

Anyway, it is what it is. There's a nasty rant in the documentation for ZWave now - don't read that README file if you don't like 4-letter words. I ain't removing it until the manufacturers step up and start documenting their stuff!

This is working remarkably well - the X10 "de-integration" from the base code will likely be done this weekend, and the code will then be posted as 5.0-BETA and ultimately, after a week or two, the "BETA" will be removed.

Share this post


Link to post
Share on other sites
these guys allude to some control funcions over here http://www.elec-solutions.com/docs/motor_c...User_Manual.pdf

not sure if it will help.

Cool device. This is the much-anticipated DC motor control from ESI. I'm tempted to get one just to try all the commands.

Let's see if we can figure out how to talk to it using the Leviton RZC0P. For the examples below, let's assume that we are talking to node 4.

When the DBMZ sends a Node Info Report, it reports itself as a Basic Slave device with generic support for Multilevel switch,

specifically supporting the Multi-position motor class.

>?FI003,017,000  //basic class 3 (slave), generic class 0x11 (multlevel switch), specific class 0
<F004            //node 4 (the first instance in the network of the specified type
//Note:  I don't know the code for "multi-position motor", try plugging in numbers in the "specific class" field until you get a response and let us know

4. COMMAND_CLASS_CONFIGURATION Commands

There are 3 configuration parameters accessible via the COMMAND_CLASS_CONFIGURATION.

Each parameter is a single byte, and can only contain the value of 1 or 0.

Sample commands:

To check unit calibration state, send CONFIGURATION_GET, 1. Return is a 0 or 1. (0=not calibrated, 1=calibrated)

>N4SE112,5,1                 //configuration, get, calibration state
<N004:112,006,001,001,000    //configuration, report, calibration state, size: 1-byte, not calibrated
<N004:112,006,001,001,001    //configuration, report, calibration state, size: 1-byte, calibrated

To check unit motor direction state, send CONFIGURATION_GET, 2. Return is a 0 or 1. (0=motor direction normal, 1=reversed motor direction)

>N4SE112,5,2                 //configuration, get, motor direction state
<N004:112,006,002,001,000    //configuration, report, motor direction state, size: 1-byte, motor direction normal
<N004:112,006,002,001,001    //configuration, report, motor direction state, size: 1-byte, reversed motor direction

To check unit tilt feature state, send CONFIGURATION_GET, 3. Return is a 0 or 1. (0=tilt feature not enabled, 1=tilt feature enabled)

>N4SE112,5,3                 //configuration, get, tilt feature state
<N004:112,006,003,001,000    //configuration, report, tilt feature state, size: 1-byte, tilt feature not enabled
<N004:112,006,003,001,001    //configuration, report, tilt feature state, size: 1-byte, tilt feature enabled

To initiate calibration sequence, send CONFIGURATION_SET, 1, 1, 1.

>N4SE112,4,1,1,1             //configuration, set, forward direction, size: 1-byte, calibrate

To set motor direction to reversed and calibrate, send CONFIGURATION_SET, 2, 1, 1 (if already reversed, then no action).

>N4SE112,4,2,1,1             //configuration, set, reversed direction, size: 1-byte, calibrate

To return all settings to factory default, send CONFIGURATION_SET, 1, 129, 1.

>N4SE112,4,1,1,1             //configuration, set, forward direction, size: 129-bytes, calibrate

(That last one is a bit strange since the size (or number of arguments) must be either 1,2,or 4 bytes. Perhaps this forces an error condition, resulting in a reset to factory settings.)

5. COMMAND_CLASS_BASIC Commands

A BASIC_GET will return a motor position value between 0 and 99, or 255.

A value of 255 means the motor is not calibrated, and cannot report a valid position. (The Motor LED will also be red)

A BASIC_SET 0 will move the shade of a properly calibrated motor to the fully closed position.

A BASIC_SET 99 or 255 will move the shade to the fully open position.

Sending BASIC_SET 255 to an un-calibrated motor will also cause it to move to a limit.

Sending a BASIC_SET X (where X is 1 to 99) command to an uncalibrated motor will result in no motion.

The Status LED will blink red to indicate an error condition.

Sample commands:

To move shade to 50%, send BASIC_SET 50.

>N4SE1,1,50                  //basic, set, move shade to 50%

To check current shade position, send BASIC_GET. The return value is 0 to 99.

>N4SE1,2                     //basic, get
<N004:001,003,050            //basic, report, shade positin 50%

6. COMMAND_CLASS_SWITCH_MULTILEVEL Commands

A MULTILEVEL_SWITCH_GET will return a motor position value between 0 and 99, or 255.

A value of 255 means the motor is not calibrated, and cannot report a valid position. (The Motor LED will also be red)

A MULTILEVEL_SWITCH_SET 0 will move the shade of a properly calibrated motor to the fully closed position.

A MULTILEVEL_SWITCH_SET 99 or 255 will move the shade to the fully open position.

Sending MULTILEVEL_SWITCH_SET 255 to an uncalibrated motor will also cause it to move to a limit.

Sending a MULTILEVEL_SWITCH_START_LEVEL_CHANGE with parameter 1, bit 6 clear, causes the position value to increase and the shade opens regardless of the calibration status.

Sending a MULTILEVEL_SWITCH_START_LEVEL_CHANGE with parameter 1, bit 6 set, causes the position value to decrease and the shade closes regardless of the calibration status.

The values of the Ignore Start Level bit (parameter 1, bit 5) and the Start Level parameter (parameter 2) are ignored.

However, for compatibility with other Z-Wave devices, the Ignore Start Level bit should be set to 1.

Sending a MULTILEVEL_SWITCH_STOP_LEVEL_CHANGE at any time will stop the motor.

Sample commands:

To move shade to 50%, send MULTILEVEL_SWITCH_SET 50.

>N4SE38,1,50                 //multilevel switch, set, move shade to 50%

To check current shade position, send MULTILEVEL_SWITCH_GET. The return value is 0 to 99.

>N4SE38,2                    //multilevel switch, get
<N004:038,003,050            //multilevel switch, report, shade position 50%

To force a shade open (regardless of whether the motor control is calibrated), send MULTILEVEL_SWITCH_START_LEVEL_CHANGE 32.

>N4SE38,4,32,0               //multilevel switch, start level change, direction open (00100000 - Ignore Start Level bit 5 set, bit 6 clear), Start Level (ignored)

To force a shade closed (regardless of whether the motor control is calibrated), send MULTILEVEL_SWITCH_START_LEVEL_CHANGE 96.

>N4SE38,4,96,0               //multilevel switch, start level change, direction close (01100000 - Ignore Start Level bit 5 set, bit 6 set), Start Level (ignored)

To stop the motor, send MULTILEVEL_SWITCH_STOP_LEVEL_CHANGE

>N4SE38,5                    //multilevel switch, stop level change

7. COMMAND_CLASS_SWITCH_ALL Commands

The Factory default setting for SWITCH_ALL is ALL_ON and ALL_OFF commands disabled.

Send SWITCH_ALL_GET to get the SWITCH_ALL_ON and SWITCH_ALL_OFF status.

>N4SE39,2                    //switch all, get
<N004:039,003,000            //switch all, report, ALL_ON and ALL_OFF disabled (factory default)

Send SWITCH_ALL_SET 0 to disable SWITCH_ALL_ON and SWITCH_ALL_OFF commands.

>N4SE39,1,0                  //switch all, set, ALL_ON and ALL_OFF disabled

Send SWITCH_ALL_SET 1 to enable SWITCH_ALL_OFF commands only.

>N4SE39,1,1                  //switch all, set, enable ALL_OFF only

Send SWITCH_ALL_SET 2 to enable SWITCH_ALL_ON commands only.

>N4SE39,1,2                  //switch all, set, enable ALL_ON only

Send SWITCH_ALL_SET 255 to enable both SWITCH_ALL_ON and SWITCH_ALL_OFF commands.

>N4SE39,1,255                //switch all, set, enable ALL_ON and ALL_OFF

Send SWITCH_ALL_ON

>N4SE39,4                    //switch all, ALL_ON

Send SWITCH_ALL_OFF

>N4SE39,5                    //switch all, ALL_OFF

8. COMMAND_CLASS_POWERLEVEL Commands

Send POWERLEVEL_TEST_NODE_SET, 2, 0, 0, 100 to have this node send 100 test frames at maximum signal strength to node 2.

>N4SE115,4,2,0,0,100         //powerlevel, test node set, blast node 2 (cool!!!), power level (0=max??), test frame cnt 0 (MSB), test frame cnt 100 (LSB)

When the test completes, node 2 sends a POWERLEVEL_TEST_NODE_REPORT back.

If a single message is acknowledged, the test passes.

The last 2 parameters represent the number of test frames acknowledged.

<N002:115,006,004,002,000,000  //powerlevel, test report, test node 4, status: test in progress, # of frames acked 0 (MSB), # of frames acked 0 (LSB)
<N002:115,006,004,001,000,100  //powerlevel, test report, test node 4, status: test success, # of frames acked 0 (MSB), # of frames acked 100 (LSB)
<N002:115,006,004,000,000,000  //powerlevel, test report, test node 4, status: test failed, # of frames acked 0 (MSB), # of frames acked 0 (LSB)
<N004:115,006,004,000,000,000  //powerlevel, test report, test node 4, status: test not a nodeID, # of frames acked 0 (MSB), # of frames acked 0 (LSB)
//Note:  the document isn't clear about which node reports when the test FAILS

It is also possible to query for the results of the last test by sending a POWERLEVEL_TEST_NODE_GET.

>N2SE115,5               //(to node 2) powerlevel, test node get

Send POWERLEVEL_SET, 5, 60 to set node to power level 5 (mid-level power) for 60 seconds.

>N4SE115,1,5,60          //powerlevel, set, power level 5, timeout 60

Send POWERLEVEL_GET to find out what power level is being used by a node

>N4SE115,2               //powerlevel, get
<N004:115,003,005,059    //powerlevel, report, using level 5, remaining time 59

9. COMMAND_CLASS_MANUFACTURER_SPECIFIC Command

Send MANUFACTURER_SPECIFIC_GET.

The return message should be 0x00, 0x33, 0x52, 0x50, 0x30, 0x32

This shows the ESI product data as Manufacturer ID: 0033, Product Type ID: “RP”, and Product ID: “02”.

>N4SE112,4                             //manufacturer specific, get
<N004:112,005,000,051,082,080,048,050  //manufacturer specific, report, mfgID1 0, mfgID2 0x33, product type1 0x52, product type2 0x50, product ID1 0x30, product ID2 0x32

10. COMMAND_CLASS_VERSION Commands

Send VERSION_GET. The returned message is 0x04, 0x02, 0x06, 0x01, 0x01, 0x5A.

This represents Library type 4 for basic slave device Protocol Version 2 Protocol Sub Version 6

Application Version is the Z-Waveâ„¢ processor code version (currently 1)

Application Sub Version is the motor processor code version (currently 1)

>N4SE134,17                        //command class version, get
<N004:134,018,004,002,006,001,001  //command class version, report, lib type 4, protocol version 2, protocol subversion 6, app version 1, app supversion 1
//Note:  I don't know about the "0x5A" mentioned above; the message only has 5 parameters

Share this post


Link to post
Share on other sites

BTW, the PIR "sleep" appears to work. HomeDaemon will now go out and attempt to set this on any device declared as a PIR when it starts up, which SHOULD stop the battery drain problem.

Maybe.

Share this post


Link to post
Share on other sites

Ok.... current code up there now not only sets the PIRs for "be nice to the battery" but also polls for battery level once an hour and displays it in the CGI output, AND can be tested as an event if any item for which battery is reported is under 15% (but more than 0%)

This will allow you to do something like send an SMS message, hit an alert, etc, and should prevent you from getting a dead battery without being told about it first.

Share this post


Link to post
Share on other sites
Ok.... current code up there now not only sets the PIRs for "be nice to the battery" but also polls for battery level once an hour and displays it in the CGI output, AND can be tested as an event if any item for which battery is reported is under 15% (but more than 0%)

This will allow you to do something like send an SMS message, hit an alert, etc, and should prevent you from getting a dead battery without being told about it first.

That's really cool. If you keep this up you may end up with one of the most complete software controllers available. I still have yet to install your software on Ubuntu tho. Maybe I'll mess with that later today.

Share this post


Link to post
Share on other sites

Well there's nothing particularly complicated about supporting device classes other than being able to figure out how to talk to them, and the documentation set simply sucks.

Or, in some cases, the alleged parameters are simply ignored although the raw function appears to work.

For example the PIRs. Supposedly you can set the 'sleep' interval. Uh huh. Set it to whatever you want, but it doesn't change the reporting interval.

My biggest issue with some of this is going to be finding actual devices that I want to integrate and getting an example of them to test and put into the system. As an example the "blind controller" sounds interesting, but I don't know that I'll ever be willing to buy a few of them for the purpose of integrating them.....

I know some people like the idea of thermostats - I might actually buy one of those some day, but then again, perhaps not. We have a 2-stage system here that I currently manage using discrete relays and LM34 temperature sensor ICs (ADICON stuff) and most of the thermostats are, frankly, quite archaic in terms of their functionality compared to what I've got coded (albiet in an event set that spans some 50 items in the list!), or are simply SILLY expensive (I saw one that had the functionality but was north of $300! Who the hell are they trying to fool with THAT one?) The other nice aspect to my "hardwired" setup is that it is easily adaptable to work with dampers (e.g. multizone, one source HVAC) and the like if you want, as multiple temperature sensors are trivial to support, and in addition IF the system goes down it drops the "enable" relay automatically and an old-fashioned $40 wall-mount thermostat takes over (critical in freezing climates where loss of central control could freeze your pipes!)

I'd love to find wall outlets in ZWave (and posted a query on this) but so far, no dice - update - ok, there are some, but only split duplex - one controlled. Barf; most places where I want this, I want BOTH outlets controlled.

BTW, if you're tracking the code for installation make sure you keep up with the version changes. I keep finding "surprises" (due to the lack of documentation and thus behavior that I don't expect emerges) and as a consequence new versions get posted VERY frequently right now.

This is not the norm; for most of this package's life it has been pretty stable with updates and changes made only infrequently. It appears that for the next several weeks to months this is not going to be the case due to the "document through trial-by-fire" method.

The "X10 optional" changes were made but I'm not happy with them; there will be one more major revision to the codebase when that is completely split out into its own module. I expect that to be complete soon.

Share this post


Link to post
Share on other sites

Ok, latest status....

V5.0-BETA-5 is up on the CURRENT link.

Significant changes:

1. Zwave's parameters are now in a configuration file so you don't need to recompile things. Specifically, whether or not you want PIRs initialized and if so, to what, along with some of the scale factors and battery monitoring levels for battery-operated PIRs.

2. A number of internal state-machine changes were made to the ZWave code, the event processor, and the shared memory manager. These all have had the impact of improving performance significantly, catching a couple of potential race conditions and "de-fanging" them, etc.

3. Subunits for ZWave devices (up to 4, for wall controller "button fields" as but one example) are now supported. Note that while wall controllers are fully supported as "button fields" the LED status indicators are not, as I've not been able to get any documentation on how (or if) you can control them programmatically. However, their use as a "button field" device means you effectively have EIGHT "scenes or commands" you can set from a Leviton "4-device" controller, NOT four. That is, the "off" side of a button doesn't have to do the opposite of the "on" side - each side of each rocker can have any function you'd like under programmatic control. This is VASTLY more powerful than the "scene" system where you have only four "on and off" states.

4. X10 support is now fully modular; if you don't want X10 you no longer need Dan Lancini's code at all, nor do you need to start the X10 module. Of course you can't attempt to do X10ish things if you don't have X10 loaded.....

5. There is no attempt to pick up device names or the like from the wire. You have to define the devices in the events file before you can use them, along with their type. This means you also still do need a "master" programmer (you can't do it all from the PC interface.)

The performance of Zwave devices under this build is incredible. It is VASTLY superior to anything X10 can offer both in the fact that it can react to local changes (e.g. its polled) AND that it has other functionality available such as the quite-tight PIR integration.

It appears that some devices will send a HAIL to the controller if they are locally modified - but not all. That is, if you go up to a wall switch and change the level, at least the Leviton Vizia-RF ones, and they're associated with the HAI interface, they will send a generic HAIL to the controller. This is good as it can then result in an immediate status poll to find out what state the device is in. However, not ALL devices send this notification - in particular, the plug-in "Intermatic" modules DO NOT and thus there is no way for the interface to know that they have been locally modified. This also does not appear to always reliably result in timely status reports to local control events... even though it should, there are apparently times when an immediate ">?Nx" sent back down the line does not cough up a state in response. I'm still looking into the "why" on that one, because from what I can see, it SHOULD result in an immediate status update. It may be that I need to instead execute an "UP" (update) in response to a local-control event - I'm still looking into why I don't get back what I'd expect in this circumstance.

Note that as a BETA there is still a fairly significant amount of debug logging going on even at the normal syslog level in the ZWave module. This will go away when there is a formal 5.0 release.

Assuming I don't find any nasties in the next couple of weeks, 5.0 should be formalized and then branched so development will go into 5.1, and the excess logging will disappear.

Enjoy.

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