Author Topic: Questions on ZWave source code  (Read 45857 times)

kinman

  • Regular Poster
  • **
  • Posts: 23
    • View Profile
Re: Questions on ZWave source code
« Reply #45 on: December 28, 2007, 04:44:57 am »
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

  • Regular Poster
  • **
  • Posts: 23
    • View Profile
Re: Questions on ZWave source code
« Reply #46 on: December 28, 2007, 04:50:33 am »
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

  • Regular Poster
  • **
  • Posts: 23
    • View Profile
Re: Questions on ZWave source code
« Reply #47 on: December 28, 2007, 05:08:01 am »

kinman

  • Regular Poster
  • **
  • Posts: 23
    • View Profile
Re: Questions on ZWave source code
« Reply #48 on: December 28, 2007, 05:36:33 am »
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

  • Addicted
  • *
  • Posts: 552
    • View Profile
Re: Questions on ZWave source code
« Reply #49 on: December 28, 2007, 06:03:35 am »
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

  • Alumni
  • wants to work for LinuxMCE
  • *
  • Posts: 962
    • View Profile
    • My LinuxMCE User Page
Re: Questions on ZWave source code
« Reply #50 on: December 28, 2007, 06:13:21 am »
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
The only intuitive interface is the nipple.  After that it's all learned.
My other computer is your windows box.
I'm out of my mind.  Back in 5 minutes.
Q:  What's Red and smells like blue paint?

A:  Red Paint.

totallymaxed

  • LinuxMCE God
  • ****
  • Posts: 4660
  • Smart Home Consulting
    • View Profile
    • Dianemo - at home with technology
Re: Questions on ZWave source code
« Reply #51 on: December 28, 2007, 01:36:30 pm »
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.
Andy Herron,
CHT Ltd

For Dianemo/LinuxMCE consulting advice;
@herron on Twitter, totallymaxed+inquiries@gmail.com via email or PM me here.

Get Dianemo-Rpi2 ARM Licenses http://forum.linuxmce.org/index.php?topic=14026.0

Get RaspSqueeze-CEC or Raspbmc-CEC for Dianemo/LinuxMCE: http://wp.me/P4KgIc-5P

Facebook: https://www.facebook.com/pages/Dianemo-Home-Automation/226019387454465

http://www.dianemo.co.uk

ddamron

  • Alumni
  • wants to work for LinuxMCE
  • *
  • Posts: 962
    • View Profile
    • My LinuxMCE User Page
Re: Questions on ZWave source code
« Reply #52 on: December 28, 2007, 01:43:02 pm »
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
The only intuitive interface is the nipple.  After that it's all learned.
My other computer is your windows box.
I'm out of my mind.  Back in 5 minutes.
Q:  What's Red and smells like blue paint?

A:  Red Paint.