SetNodeOn and SetNodeOff not working

[GoogleCodeExporter]

What steps will reproduce the problem?
1. MinOZW program with calls to SetNodeOn and SetNodeOff (see attachment)
2.
3.

What is the expected output? What do you see instead?
See the attached OZW_Log.txt file

What version of the product are you using? On what operating system?
OZW version r653 compiled on VS2010 under 32-bit Windows 7.

Please include the file OZW_Log.txt from your program. Make sure the file
zwcfg*.xml is NOT present.

Please provide any additional information below.

Original issue reported on code.google.com by observ...@gmail.com on 14 Apr 2013 at 9:05

Attachments:

• OZW_Log.txt
• Main.cpp

[GoogleCodeExporter]

This is a side effect of the Basic command class mapping. Review of SetNodeOn 
and SetNodeOff is necessary to determine their usefulness and compatibility 
with Basic mapping.

Original comment by glsatz on 15 Apr 2013 at 2:20

• Changed state: Accepted

[GoogleCodeExporter]

I too found this problem.  I also notice in the log file an issue with the ge 
dimmer.xml config, which is perhaps contributing to the issue?  Unfortunately, 
i can't find documentation on the device configuration to fix at 
http://www.pepper1.net to try to fix it.  

I attach my attempt at turning the switch "off".  

I tried it in both 650 and 656.  I know on/off worked in some earlier version, 
but I honestly don't remember.

Original comment by nicole.l...@gmail.com on 24 Apr 2013 at 2:05

Attachments:

• OZW_Log.txt
• Off.cpp

[GoogleCodeExporter]

I attached the wrong log before.  Here it is.

Original comment by nicole.l...@gmail.com on 24 Apr 2013 at 3:01

Attachments:

• OZW_Log.txt

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Confirm that. On r665 setNodeOn/setNodeOff/setNodeLevel doesnt work. On r639 - 
working.

Original comment by sys.adm.nv@gmail.com on 13 Sep 2013 at 6:44

[GoogleCodeExporter]

I confirm too, i updated to r639 and it's working now.
I'm surprised that this problem is not a priority.

Original comment by ygauthe...@gmail.com on 2 Oct 2013 at 12:17

[GoogleCodeExporter]

setNode* API depends upon accurately mapping to the classes. The challenge is 
that this is not as easy as it sounds (imagine you have a device with 4 
switches on it, which switch should the setNode* functions control?)

So probably more robust if you iterate over the various ValueID's that the 
device exposes and act on those direct rather than rely on the setNode* 
Functions

Try monitoring the ValueAdded Notifications and save whatever ValueID matches 
to what you want to control, and act on the ValueID directly instead. 

Original comment by jus...@dynam.ac on 7 Oct 2013 at 5:30

[GoogleCodeExporter]

Im using standard Fibaro FGD-211. What i should do to enable 
SetNode{On,Off,Level} on latest revisions? 
I stay on the old revision because of this.

Original comment by sys.adm.nv@gmail.com on 11 Nov 2013 at 1:16

[GoogleCodeExporter]

Me too... maybe someone could explain more clearly how to act "directly on the 
ValueID" instead ?
Sorry if it's easy, but i'm not seeing exacly how to do this instead of a 
SetNode.

Original comment by ygauthe...@gmail.com on 11 Nov 2013 at 4:23

[GoogleCodeExporter]

I'll try to post a simplified example on the wiki soon, but if your impatient 
have a look at OpenZWave-control-panel for a working example

Original comment by jus...@dynam.ac on 12 Nov 2013 at 2:58

[GoogleCodeExporter]

I just saw this blog posting that seems like a good starting point: 
http://www.agilart.com/blog/open-zwave

Original comment by jus...@dynam.ac on 12 Nov 2013 at 3:18

[GoogleCodeExporter]

Thank you, i will take a look !

Original comment by ygauthe...@gmail.com on 12 Nov 2013 at 3:25

[GoogleCodeExporter]

I have Fibaro FGD211 dimmer as Node 3. I try to add following lines to MinOZW:

   printf("Enabling light!\n");
   sleep(1);

    int nodeid = 3;
    pthread_mutex_lock( &g_criticalSection );
    for( list<NodeInfo*>::iterator it = g_nodes.begin(); it != g_nodes.end(); ++it )
    {
                NodeInfo* nodeInfo = *it;
                if( nodeInfo->m_nodeId != nodeid ) continue;
        for( list<ValueID>::iterator it2 = nodeInfo->m_values.begin();
 it2 != nodeInfo->m_values.end(); ++it2 )
        {
            ValueID v = *it2;
            if( v.GetCommandClassId() == 0x25 || v.GetCommandClassId() == 0x26 || v.GetCommandClassId() == 0x27)
            {
                Manager::Get()->SetValue(v, 66); //set dimmer level to 66
                break;
            }
        }
    }

    pthread_mutex_unlock( &g_criticalSection );

  printf("DONE!\n");

Nothing changed. No debug zwave lines on screen, no light level change. So... 
It wont works?

Original comment by sys.adm.nv@gmail.com on 13 Nov 2013 at 1:33

Attachments:

• OZW_Log.txt
• Main.cpp

[GoogleCodeExporter]

On the screen I see:

--- stripped ---

2013-11-13 17:33:0.981 Node003, Removing current message
2013-11-13 17:33:0.981 Node003, Query Stage Complete (Dynamic)
2013-11-13 17:33:0.981 Node003, AdvanceQueries queryPending=0 queryRetries=0 
queryStage=Configuration live=1
2013-11-13 17:33:0.981 Node003, QueryStage_Configuration
2013-11-13 17:33:0.981 Node003, QueryStage_Complete
2013-11-13 17:33:0.981 CheckCompletedNodeQueries m_allNodesQueried=0 
m_awakeNodesQueried=0
2013-11-13 17:33:0.981 CheckCompletedNodeQueries all=0, deadFound=0 
sleepingOnly=1
2013-11-13 17:33:0.981          Node query processing complete except for 
sleeping nodes.
2013-11-13 17:33:0.992 mgr,     Manager::WriteConfig completed for driver with 
home ID of 0x00ce20b2
Enabling light!
Done
SOF: 39 ACK Waiting: 0 Read Aborts: 0 Bad Checksums: 0
Reads: 39 Writes: 22 CAN: 0 NAK: 0 ACK: 22 Out of Frame: 0
Dropped: 0 Retries: 0
2013-11-13 17:33:1.992 
***************************************************************************
2013-11-13 17:33:1.993 *********************  Cumulative Network Statistics  
*********************
2013-11-13 17:33:1.993 *** General
2013-11-13 17:33:1.993 Driver run time: . .  . 0 days, 0 hours, 0 minutes
2013-11-13 17:33:1.993 Frames processed: . . . . . . . . . . . . . . . . . . . 
. 39
2013-11-13 17:33:1.993 Total messages successfully received: . . . . . . . . . 
. 39
2013-11-13 17:33:1.993 Total Messages successfully sent: . . . . . . . . . . . 
. 22
2013-11-13 17:33:1.993 ACKs received from controller:  . . . . . . . . . . . . 
. 22
2013-11-13 17:33:1.993 *** Errors
2013-11-13 17:33:1.993 Unsolicited messages received while waiting for ACK:  . 
. 0
2013-11-13 17:33:1.993 Reads aborted due to timeouts:  . . . . . . . . . . . . 
. 0
2013-11-13 17:33:1.993 Bad checksum errors:  . . . . . . . . . . . . . . . . . 
. 0
2013-11-13 17:33:1.994 CANs received from controller:  . . . . . . . . . . . . 
. 0
2013-11-13 17:33:1.994 NAKs received from controller:  . . . . . . . . . . . . 
. 0
2013-11-13 17:33:1.994 Out of frame data flow errors:  . . . . . . . . . . . . 
. 0
2013-11-13 17:33:1.994 Messages retransmitted: . . . . . . . . . . . . . . . . 
. 0
2013-11-13 17:33:1.994 Messages dropped and not delivered: . . . . . . . . . . 
. 0
2013-11-13 17:33:1.994 
***************************************************************************
2013-11-13 17:33:4.101 mgr,     Driver for controller /dev/ttyUSB0 removed

Original comment by sys.adm.nv@gmail.com on 13 Nov 2013 at 1:37

[GoogleCodeExporter]

It could be two issues here:
1) There is no matching Value in your comparison. Put some debug statements in 
your inner loop to make sure you are actually getting a valid ValueID

2) You exiting the app immediately after doing the setValue. This probably 
won't give OZW enough time to actually send the command.  (OZW is multithreaded)

I suggest we take this discussion to the mailing list, as it now has nothing to 
do with the setNode* issues originally reported. 

Original comment by jus...@dynam.ac on 13 Nov 2013 at 2:43

[GoogleCodeExporter]

One more issue to consider. In the call, Manager::Get()->SetValue(v, 66), the 
number 66 isn't typed. If (for example) the compiler defaults to 
ValueID::ValueType_Int and the value needs to be ValueID::ValueType_Byte, the 
call will fail and return false. You can find out the real type of the value 
with a call to v.GetType() in your code.

Original comment by observ...@gmail.com on 13 Nov 2013 at 3:13

[GoogleCodeExporter]

Hello,

I confirm that this way is working for a binary switch on Fibaro Wallplug : 

pthread_mutex_lock(&g_criticalSection);
for( list<NodeInfo*>::iterator it = g_nodes.begin(); it != g_nodes.end(); ++it 
) {
    NodeInfo* nodeInfo = *it;
    if( nodeInfo->m_nodeId == Node ) {
        for( list<ValueID>::iterator it2 = nodeInfo->m_values.begin();it2 != nodeInfo->m_values.end(); ++it2 ) {
            ValueID v = *it2;
            if( v.GetCommandClassId() == 0x25){
                Manager::Get()->SetValue(v, Level != 0);
                break;
            }
        }
    }
}
pthread_mutex_unlock(&g_criticalSection);

Original comment by ygauthe...@gmail.com on 17 Nov 2013 at 9:01