Questions on ZWave source code

[kinman]

The Zniffer is not a product. Its only a developer tool to look at signals. Leviton and Lutron announced a settlement this month. No details however.

If the suit is settle and Leviton keeps this "technology", its good for LinuxMCE to support Leviton.

[kinman]

The ZWave stack in LMCE needs some work and it may be possible to license the Leviton technology as long as it supports the Leviton switches only to add to it. Any volunteers to work on it? It may require NDA's etc to be able to work on it.

Is Leviton computer interface compatible with ACT ZCS/ZCU? It seems the Zen-sys document just mention ZCS/ZCU.

[kinman]

Leviton to Pay Lutron in Settlement
http://resmagonline.com/articles/publish/article_2186.shtml

[kinman]

Hi all, I go through the ZWave stack. The structure is not complex as i was though:

Main process
├ZWJobAssignReturnRoute
├ZWJobAssociationSet
├ZWJobConfig
├ZWJobDeleteRoute
├ZWJobInitialize
|├ZWJobGetID
|├ZWJobGetInitData
|├ZWJobGetNodeProtocolInfo
|├ZWJobGetSUC
|└ZWJobGetVersion
├ZWJobPool
|└ZWJobSwitchBinaryGet
├ZWJobReceive
├ZWJobReset
├ZWJobSetLearnMode
├ZWJobSwitchChangeLevel
└ZWJobWakeUp

Some basic objects:
-SerialConnection
-PlutoZWSerialAPI
-ZWaveJob
-ZWaveNode
-ZWJobSendData

The PIR method is complex its two way status feedback:
-wakeupPIRHandler
-alarmPIRHandler

[1audio]

The Leviton module has a serial interface and should look like the generic ZWave device except for some additional special classes that are supported. LMCE doesn't know how to talk to a serial ZWave interface yet. (Hint)

The Pluto ZWave implementation has one serious bug in it- if there is a gap in the node sequence it periodically looses the nodes after the gap and reinstalls them as new nodes. They then need to be reassigned, etc. I have tried to work with Pluto on this with no success. Its not easy to troubleshoot.

ZWave has a lot of additional features that can be supported, including a special command to switch a group of lights in one command as well as support for a lot of stuff that hasn't been made yet.

[ddamron]

Insteon has support for that as well, but here's the catch:

LMCE does NOT have support for that...  Sure, you have groups, and scenarios...
but the DCERouter handles ALL the scenario commands, and preprocesses them into standard commands to each device.

Also, I have yet to find a method to READ scenario information.

Regards,

Dan

[totallymaxed]

Insteon has support for that as well, but here's the catch:

LMCE does NOT have support for that...  Sure, you have groups, and scenarios...
but the DCERouter handles ALL the scenario commands, and preprocesses them into standard commands to each device.

Also, I have yet to find a method to READ scenario information.

Regards,

Dan

Yes... thats a good point. In many situations the DCErouter will preprocess a command to a group of devices eg 6 lights which means that 6 discrete 'on' commands are sent and you see a slight out of phase affect where the lights actually do not go to their 'on' state synchronously. It would be better to exploit the native z-wave/insteon ability to manage groups of devices and send a single 'on' command to the z-wave/insteon group and then let the z-wave/insteon firmware handle the synchronous 'on' command. This better exploits the unique capabilities of the respective z-wave/insteon system and also means that if you use a 'physical' switch or non lmce remote to turn on/off devices or want to still have control of your lighting and other devices without always having to use lmce to send commands to control them then you can. At present if I manually change the state of a z-wave device... lmce knows nothing about it (no state information is handled by lmce currently) and if i use z-wave's group feature also lmce is oblivious to it.

The current Z-wave binary is a very basic driver... we need a more elegant implementation that fully exploits each systems (ie z-wave, insteon... etc etc) feature set in my opinion.

[ddamron]

My Insteon Driver does report state information, but I can only report ON/OFF...
I cannot report a 50% level...
so, if it's on at all, I report ON.

My 2way insteon driver works quite well, given the limitations I'm working with...

Ahh well, room for future expansion... Once LMCE is able to accept STATE information (or we can find a work around)

The Scenario situation, IMHO, is also just as important..  There SHOULD be an option somewhere to 'Preprocess this scenario' YES/NO
if it's NO, the scenario reports a 'special scenario' command to the DCERouter, which then forwards it, without preprocessing it, to the device (or devices) responsible (ie, parent devices, MD's etc)

Regards,

Dan