Motion sensor hsm100 fail to initialise

Sorry - I’ve not had a chance to look at your updated log as I’ve been heading home after my holiday. I’ll take a look in the next day or two.

Thanks, I am in constant anticipation to see any developments on this thread :slight_smile:
I know from reading the threads that you are quite busy, and probably this time with the release of openhab2

I’ve actually been on holiday in India for the past 2 1/2 weeks - time was a bit short, and internet access often pretty limited… I’m (unfortunately!) home now ;).

1 Like

The problem here is that many messages are being received twice. Unfortunately, we’re receiving the multi-channel capability message twice - the second time adds the command classes back in straight after they were removed! The code to remove the command class is running - it’s just these extra messages that are now causing issues.

I might look at preventing certain classes from being used in multi-channel messages…

Thanks for following up. Let me know if I can do anything on my side (e.g. workaround via some configuration setting)

I want to invoke oh2 within eclipse, with the latest zwave snapshot, in order to debug the problem, so I installed oh2 runtime, and the latest habmin and zwave bindings (from the latest snapshots).
The zwave controller fails to initialize with the following error message

Status: OFFLINE - COMMUNICATION_ERROR zwave.thingstate.serial_notfound

The controller exists and when oh2 is installed without eclipse (i.e. from package, and not from source), it communicates well

ll /dev/ttyACM*
crw-rw---- 1 root dialout 166, 0 Jan 27 22:36 /dev/ttyACM0

What could be the reason to getting this error withing eclipse?

EDIT:
I successfully initialised the zwave controler within eclipse by changing the permissions on the serial port /dev/ttyACM0 (see here)

@chris - have you made changes yet?
I’m asking because I synced againsed the latest zwave binding snapshot (commit 299b9f431d65f3b387b1b4a1501e2c47ed87b616 from 27 Jan)
and I’m not seeing, in the zwave log viewer, the earlier error message “Rejected by the Controller”.
However, the initialisation for the device (node 20) still doesn’t complete.
It doesn’t go beyond Stage advanced to STATIC_VALUES
and I see warn messages such as:

2017-01-28 23:50:58.950 [WARN ] [b.z.i.p.s.SendDataMessageClass:80   ] - NODE 20: Already processed another send data request for this callback Id, ignoring.

The log file is in here

No - nothing related to this.

This error had nothing to do with your issue - it’s just a ‘random’ communication error.

This is perfectly normal - I should reduce this to a debug message.

I’m trying to debug the problem by debugging the zwave binding source.
I can see the device progressing through the stages in snapshot1, but it gets stuck in STATIC_VALUES (before the advancing to the ASSOCIATIONS stage). Every time I wake up the device by pressing the button the block in snapshot2 is repeated.
@chris, if you can direct me as to the logic of the error, maybe I will be able to workaround until you solve the problem properly.

snapshot1

NODE 20: Node advancer - advancing to PROTOINFO
NODE 20: Node advancer - advancing to INIT_NEIGHBORS
NODE 20: Node advancer - advancing to FAILED_CHECK
NODE 20: Node advancer - advancing to WAIT
NODE 20: Node advancer - advancing to PING
NODE 20: Node advancer - advancing to DETAILS
NODE 20: Node advancer - advancing to INCLUSION_START
NODE 20: Node advancer - advancing to IDENTIFY_NODE
NODE 20: Node advancer - advancing to MANUFACTURER
NODE 20: Node advancer - advancing to SECURITY_REPORT
NODE 20: Node advancer - advancing to APP_VERSION
NODE 20: Node advancer - advancing to DISCOVERY_COMPLETE
NODE 20: Node advancer - advancing to VERSION
NODE 20: Node advancer - advancing to ENDPOINTS
NODE 20: Node advancer - advancing to UPDATE_DATABASE
NODE 20: Node advancer - advancing to STATIC_VALUES

snapshot2

NODE 20: Node advancer: STATIC_VALUES - checking MANUFACTURER_SPECIFIC
NODE 20: Node advancer: STATIC_VALUES - checking NODE_NAMING
NODE 20: Node advancer: STATIC_VALUES - checking CONFIGURATION
NODE 20: Node advancer: STATIC_VALUES - checking WAKE_UP
NODE 20: Node advancer: STATIC_VALUES - checking BATTERY
NODE 20: Node advancer: STATIC_VALUES - checking BASIC
NODE 20: Node advancer: STATIC_VALUES - checking NO_OPERATION
NODE 20: Node advancer: STATIC_VALUES - checking MULTI_INSTANCE
NODE 20: Node advancer: STATIC_VALUES - checking MANUFACTURER_SPECIFIC for endpoint 1
NODE 20: Node advancer: STATIC_VALUES - checking NODE_NAMING for endpoint 1
NODE 20: Node advancer: STATIC_VALUES - checking CONFIGURATION for endpoint 1
NODE 20: Node advancer: STATIC_VALUES - checking BATTERY for endpoint 1
NODE 20: Node advancer: STATIC_VALUES - checking BASIC for endpoint 1
NODE 20: Node advancer: STATIC_VALUES - checking MULTI_INSTANCE for endpoint 1
NODE 20: Node advancer: STATIC_VALUES - checking VERSION for endpoint 1
NODE 20: Node advancer: STATIC_VALUES - checking SENSOR_MULTILEVEL for endpoint 1
NODE 20: Node advancer: STATIC_VALUES - checking ASSOCIATION for endpoint 1
NODE 20: Node advancer: STATIC_VALUES - checking MANUFACTURER_SPECIFIC for endpoint 2
NODE 20: Node advancer: STATIC_VALUES - checking NODE_NAMING for endpoint 2
NODE 20: Node advancer: STATIC_VALUES - checking CONFIGURATION for endpoint 2
NODE 20: Node advancer: STATIC_VALUES - checking BATTERY for endpoint 2
NODE 20: Node advancer: STATIC_VALUES - checking BASIC for endpoint 2
NODE 20: Node advancer: STATIC_VALUES - checking MULTI_INSTANCE for endpoint 2
NODE 20: Node advancer: STATIC_VALUES - checking VERSION for endpoint 2
NODE 20: Node advancer: STATIC_VALUES - checking SENSOR_MULTILEVEL for endpoint 2
NODE 20: Node advancer: STATIC_VALUES - checking ASSOCIATION for endpoint 2
NODE 20: Node advancer: STATIC_VALUES - checking MANUFACTURER_SPECIFIC for endpoint 3
NODE 20: Node advancer: STATIC_VALUES - checking NODE_NAMING for endpoint 3
NODE 20: Node advancer: STATIC_VALUES - checking CONFIGURATION for endpoint 3
NODE 20: Node advancer: STATIC_VALUES - checking WAKE_UP for endpoint 3
NODE 20: Node advancer: STATIC_VALUES - checking BATTERY for endpoint 3
NODE 20: Node advancer: STATIC_VALUES - checking BASIC for endpoint 3
NODE 20: Node advancer: STATIC_VALUES - checking MULTI_INSTANCE for endpoint 3
NODE 20: Node advancer: STATIC_VALUES - checking VERSION for endpoint 3
NODE 20: Node advancer: STATIC_VALUES - checking SENSOR_MULTILEVEL for endpoint 3
NODE 20: Node advancer: STATIC_VALUES - checking ASSOCIATION for endpoint 3
NODE 20: Node advancer: STATIC_VALUES - checking VERSION
NODE 20: Node advancer: STATIC_VALUES - checking SENSOR_MULTILEVEL
NODE 20: Node advancer: STATIC_VALUES - checking ASSOCIATION

I’m not really sure what you’re looking for - sorry. The issue is understood as I said above. The WAKEUP class is being removed as it’s meant to, but the device is then resending the MC message that adds the class back again. This is understood - the question is how to resolve this and I have some ideas, but just not so much time to implement it at the moment as there’s a lot of other things to do.

I am trying to make as much progress as I can with my poor zwave knowledge… I have still long ways to go…
So I added a temporary workaround to read the STATIC_VALUES, and the DYNAMIC_VALUES only once.
After manually waking up the device, the node xml file is finally being generated, and the node initialisation is complete :slight_smile: (log file here and xml file here)
For some reason, the Configuration Parameters can not be updated in PaperUI, since the “Save” button is disabled :frowning: Could this be because there is no association group?


The temporary change

diff --git a/src/main/java/org/openhab/binding/zwave/internal/protocol/initialization/ZWaveNodeInitStageAdvancer.java b/src/main/java/org/openhab/binding/zwave/internal/protocol/initialization/ZWaveNodeInitStageAdvancer.java
index ccf46c0..0bcf755 100644
--- a/src/main/java/org/openhab/binding/zwave/internal/protocol/initialization/ZWaveNodeInitStageAdvancer.java
+++ b/src/main/java/org/openhab/binding/zwave/internal/protocol/initialization/ZWaveNodeInitStageAdvancer.java
@@ -131,6 +131,8 @@ public class ZWaveNodeInitStageAdvancer implements ZWaveEventListener {
     private ArrayBlockingQueue<SerialMessage> msgQueue;
     private ArrayBlockingQueue<SerialMessage> msgQueue;
     private boolean freeToSend = true;
     private boolean stageAdvanced = true;
+    private boolean firstTimeStaticValues = true;
+    private boolean firstTimeDynamicValues = true;
 
     private static final int MAX_RETRIES = 5;
     private int retryCount = 0;
@@ -754,6 +756,17 @@ public class ZWaveNodeInitStageAdvancer implements ZWaveEventListener {
                     break;
 
                 case STATIC_VALUES:
+                    if (node.getNodeId() == 20) {
+                        if (firstTimeStaticValues) {
+                            logger.debug("Setting firstTimeStaticValues to false");
+                            firstTimeStaticValues = false;
+                        } else {
+                            logger.debug("firstTimeStaticValues is false. Skip STATIC_VALUES");
+                            logger.debug("NODE {}: Node advancer: STATIC_VALUES - queued {} frames", node.getNodeId(),
+                                         msgQueue.size());
+                            break;
+                        }
+                    }
                     // Loop through all classes looking for static initialisation
                     for (ZWaveCommandClass zwaveStaticClass : node.getCommandClasses()) {
                         logger.debug("NODE {}: Node advancer: STATIC_VALUES - checking {}", node.getNodeId(),
@@ -1016,6 +1029,17 @@ public class ZWaveNodeInitStageAdvancer implements ZWaveEventListener {
                     break;
 
                 case DYNAMIC_VALUES:
+                    if (node.getNodeId() == 20) {
+                        if (firstTimeDynamicValues) {
+                            logger.debug("Setting firstTimeDynamicValues to false");
+                            firstTimeDynamicValues = false;
+                        } else {
+                            logger.debug("firstTimeDynamicValues is false. Skip DYNAMIC_VALUES");
+                            logger.debug("NODE {}: Node advancer: DYNAMIC_VALUES - queued {} frames", node.getNodeId(),
+                                         msgQueue.size());
+                            break;
+                        }
+                    }
                     // Update all dynamic information from command classes
                     for (ZWaveCommandClass zwaveDynamicClass : node.getCommandClasses()) {
                         logger.debug("NODE {}: Node advancer: DYNAMIC_VALUES - checking {}", node.getNodeId(),
@@ -1137,6 +1161,13 @@ public class ZWaveNodeInitStageAdvancer implements ZWaveEventListener {
             // If there are none, then it means we're happy that we have all the data for this stage.
             // If we have all the data, set stageAdvanced to true to tell the system that we're starting again, then
             // loop around again.

I’m not sure what PaperUI does but it shouldn’t be linked to association groups in any way. Have you tried HABmin?

I had some problems to use the latest habmin snapshot. I get the following build errors in the “Problems” pane in eclipse

Description	Resource	Path	Location	Type
Plugin execution not covered by lifecycle configuration: org.eclipse.tycho:tycho-compiler-plugin:0.24.0:compile (execution: default-compile, phase: compile)	pom.xml	/org.openhab.ui.habmin	line 15	Maven Project Build Lifecycle Mapping Problem
Plugin execution not covered by lifecycle configuration: org.eclipse.tycho:tycho-packaging-plugin:0.24.0:build-qualifier (execution: default-build-qualifier, phase: validate)	pom.xml	/org.openhab.ui.habmin	line 15	Maven Project Build Lifecycle Mapping Problem
Plugin execution not covered by lifecycle configuration: org.eclipse.tycho:tycho-packaging-plugin:0.24.0:validate-id (execution: default-validate-id, phase: validate)	pom.xml	/org.openhab.ui.habmin	line 15	Maven Project Build Lifecycle Mapping Problem
Plugin execution not covered by lifecycle configuration: org.eclipse.tycho:tycho-packaging-plugin:0.24.0:validate-version (execution: default-validate-version, phase: validate)	pom.xml	/org.openhab.ui.habmin	line 15	Maven Project Build Lifecycle Mapping Problem

Ok - I’ve no idea what that is. Have you tried resyncing the HABmin repository? If so, I’m not sure why you’d get this…

I’m trying to add habmin, but all the bindings have garbled names (e.g. afTuI Binding) do you know why?

You can’t add extensions through the UI when running in Eclipse. These are random names for testing.

So I cannot run habmin via eclipse?
I can see habmin (img1) but when I click on it I can not add the zwave binding? (I can only see the hue, NTP, YahooWeather bindings (img3))

img1

img2

img3

Sure you can run HABmin via eclipse - but you need to install the source, or the jar, directly. It can’t be managed through the UI since there’s no framework to manage extensions.

Since I already have the zwave code and jar, can you instruct me how to add them directly? should I right click on the habmin project and add it somewhere there?

Sorry - I’m not sure. You would go to File | Import, but I’m not 100% sure which option after that as I always work with source.