I bought a NodOn Octgan zwave controller, to control scenes. I can get it recognized by symcon, I can see the WAKE_UP message arrive, yet symcon keeps showing the the ‚waiting for device to wake up‘ dialog. I was trying with 3.4 first, I figured maybe it works better with 4, I shelled out for a new subscription but no change.
So, what I did: I associated the NodOn controller with the primary controller (Aeon Labs Z-Stick 2) as per the manual. I went to the Z-Wave configurator in symcon; I see a new device with type ‚generic controller‘. I click ‚Create‘, then ‚Configure‘. The device is added correctly to the Location Tree:
I open the device, click on ‚Load‘ next to ‚Device Configuration‘, and then I get the ‚IP-Symcon is waiting for the device to wake up…‘ dialog, which doesn’t go away. According to the manual of the NodOn, I can wake it up by pressing any of the buttons. I do that, yet symcon doesn’t react in any way.
However, if I click ‚Cancel‘ on that dialog and put the serial port, the gateway and the device in debug mode, I do see events when I click one of the buttons on the NodOn:
Sorry to bump, but is there any way to get this to work? I can’t find any mention of COMMAND_CLASS_SCENE_ACTIVATION in the symcon documentation anywhere, am I just out of luck? Shouldn’t the wakeup at least work then?
Do you properly use the „new Console“ from Version 4.0? (The tabs should be at the top now)
Normally you should be able to properly load all the command classes. Afterwards take care of the associations, which you enable the receival of the scene activation messages.
When I click on ‚Show‘ next to ‚Supported classes‘, I get the dialog with none of the checkboxes checked, but at the bottom it says ‚All classes are supported!‘.
On the device ‚main‘ screen, it says ‚Supported classes: 0‘.
When I click ‚Load‘ next to ‚Device Configuration‘, the ‚IP-Symcon is waiting for the device to wake up…‘ dialog shows but nothing happens when I wake up the device. The debug log even says that wakeup messages are received while the dialog is being shown, but they just don’t seem to get processed.
So, I tried with another routing slave (a Danfoss thermostat) and looked at the messages during wakeup. I see that I receive a wakeup, with WakeUpKeepAlive set (if I interpret the symcon log correctly). The NodOn only sends WakeUp. Symcon then sends RequestNodeInfo, after which it receives a message of class MANUFACTURER_SPECIFIC from the Danfoss. RequestNodeInfo is also send to the NodOn, but no reply is received, it seems.
I’m not sure how the wake up sequence is supposed to work and I don’t have my zwave book at hand. Should the NodOn have answered to RequestNodeInfo? Why does the symcon log say that it send RequestNodeInfo, but with length 0? For the Danfoss, it seems that the data of RequestNodeInfo is specified in the ‚Update‘ and ‚NodeClasses‘ that are send with it; but for the NodOn, those are not send (btw the debug log is very confusing - it’s not clear what is send and what is received, and some messages that start with (S) have length 0 and others have a proper length).
Without fully understanding the details, it seems that symcon (when sending a RequestNodeInfo message) sends data along with that message (called Update and NodeClasses in the debug log) when I click ‚Load‘ for all device types I have, except the NodOn. Am I looking in the right direction here?
Somehow the communication with your device does not work properly. Can you try excluding and resetting it completely? Then include it again and try loading the device. It should load 14 classes. (http://www.pepper1.net/zwavedb/device/694) After that you will need to change parameter 3 to 1. This will change the device to properly send the scene activation which IP-Symcon supports at the moment.
I’ve tried several times in various ways - exclude/include, exclude/force reset/include, force reset/include, … but none seem to work. I don’t have another controller so I can’t test whether it’s the device that’s faulty or the software. I guess at this point I’ll just have to send it back.
