Getting `Unhandled notification: 4` and `unsupported value type: 0x2` in the log

[zonak]

Currently using the latest 0.0.27 version and I have to say it is working great - a big thank you to @jperkin and his work.

Done some testing with some power switches and dimmers from GE and everything worked with no hiccups.

Today I started testing the Aeon Labs Smart Energy Switch which aside from working as an on/off switch also reports information on power consumption.

Once I added the device I started getting multiple occurrences of the following:

• unsupported value type: 0x2
• Unhandled notification: 4

I though it would be beneficial if I provided some details on this hoping that it can be addressed.

I created a gist that can be found here and contains:

• the output from the test.js script
• the full OZW log
• the zwcfg xml file

Please let me know if I can provide anything else that can help resolve this issue.

[jperkin]

Ok, the 0x2 message should be gone in 0.0.30 now. The group notification will take a bit longer, need to do some reading up on zwave groups and how we should handle them.

[zonak]

Thank you Jonathan - in the process of installing 0.0.29 when I saw this :D (it takes time on a raspberryPi)

Thank you again for addressing these issues - greatly appreciated.

[zonak]

I started working on a sensor and getting a new one:

Unhandled notification: 10

Hope this information helps when you address these issues.

[mrose17]

@jperkin - could you help @zonak on this?

many thanks!

[sja]

@zonak Let me guess, it's a fibaro window/door sensor.

I'm at this problem currently, too. My guess is, that the sensor will notify it's association groups about an value change, which should trigger a fetch of the new values as long as the sensor is not going to sleep. But maybe I'm completely wrong.

[wgiroir]

@zonak I'm seeing the same Unhandled notification: 10 error you saw by in later October. This is coming from Vision Wireless Door/Window Sensor (model # ZD 2102 US).

Did you have any success in resolving your issue?

Thanks!

[zonak]

No luck yet.

[wgiroir]

Sorry to hear you have not solved it but glad to hear I'm not alone. I'll have this on on the back burner until I can git it resolved and I'll submit a push request if I beat you to it.

[wgiroir]

@zonak I have found the root cause of this issue and implemented a temporary fix on my side. I will try to submit a pull request in the coming days

[mrose17]

groovy! many thanks!

[wgiroir]

I may not get a push request soon so I thought I'd pass this on....

If you look in this file https://github.com/jperkin/node-openzwave/blob/master/src/openzwave.cc on line 128 the event is acquired from the openzwave library and thrown up in the queue for node side.

case OpenZWave::Notification::Type_NodeEvent: notif->event = cb->GetEvent(); break;

This is event type 10 which was my issue.

This notification is the pulled off the queue here, line 155. You'll see there is no corresponding switch statement to pick up Type_NodeEvent.

ie, notif->type == Type_NodeEvent (10).

For this notification type, I added this switch statement

            /*
             * A node has triggered an event.
             */
            case OpenZWave::Notification::Type_NodeEvent:

              args[0] = String::New("event");
              args[1] = Integer::New(notif->nodeid);
              args[2] = Integer::New(notif->event);
              MakeCallback(context_obj, "emit", 3, args);
              break;

which allows me to move forward with my development.

This may not solve your issue but it may help you move the ball forward.

Thanks, --Walt

On Aug 21, 2014, at 4:01 PM, Marshall T. Rose [email protected] wrote:

groovy! many thanks!

— Reply to this email directly or view it on GitHub.

[zonak]

Thank you for the update. I came to the same conclusion about the 10-s and the 4-s but wasn't feeling confident to go forward with a PR given my lack of experience with C++.

Hopefully @jperkin will spare some time on it again.

[wgiroir]

The 4 should be working as there is a switch statement for it.

On Aug 21, 2014, at 4:01 PM, Marshall T. Rose [email protected] wrote:

groovy! many thanks!

— Reply to this email directly or view it on GitHub.