Motion sensor hsm100 fail to initialise

Are you sure - this is definately not the case for other devices that have this function, and as I stated earlier, my understanding of the the zwave protocol doesn’t allow devices to change this flag without being excluded and included into the network.

This is a very strange device then. How do you actually know this - is it documented somewhere or is this just your assumption? As above, I would expect the device to need to be excluded and re-included to change the status of the listening flag. I might be wrong, but this is the case for other devices I know of, and consistent with my understanding of the protocol. I’m happy to be corrected though if you have a document that states otherwise.

Have you done this yet?

This is my understanding. How will the device magically differentiate from being connect to battery or main power? In this link the battery connection is simply rewired to main power, just to avoid power drainage. No other magic (such as device mode suddenly changes to “listening”) is mentioned there
The manual states, the way to control the listening / not- listening mode (by setting the flag, and not e.g. by magically recognising that the battery connection is now rewired to a main source):

Setting Stay Awake to a non-zero value will cause EZMotion+ to always be awake.

It also talks about the flag being preserved after exclusion (but as I mentioned before in here, after I excluded and reincluded the device, the value didn’t stick)

Stay Awake is NOT set to the factory default (0) when EZMotion+ is Excluded (reset) from the Z-Wave network.

The only documentation in the manual regarding listening/not-listening mode is the line that I mentioned above.

which is what I did in here, but the value didn’t stick

Yes, in here

The magic of electronics I guess. Certainly this is how the Aeon devices work - they detect the power source - it’s not hard to do…

I’m not sure then - to me, this device isn’t working as per my understanding of the ZWave standard if it can change the listening flag without being excluded. I might send an email to my contact in Sigma to check.

I’m not saying that it changes the listening flag without being excluded. All I know is that I’m not sure what is going on, and so I’d like to hook habmin into a openhab within eclipse, find and set a breakpoint in the place where it is being reported “listening” and go from there, but I need help to get there first :slight_smile:

I am now able to run habmin within eclipse. Summary of steps is in here. Next, I’ll add the zwave binding…

I now run zwave binding (2.0.0-SNAPSHOT) (addressed in this discussion thread), together with habmin (org.openhab.ui.habmin_0.1.6.jar) within eclipse.
I added the hsm100 zwave device (Z-Wave Node 34: EZMotion Express Wireless 3-in-1 Sensor).

Paper UI.Configuration.Things and Habmin.Configuration.Things both:

  • Show the device with icon Online (img1)
  • Respond immediately to changes in the device. When the battery is taken out from the hsm100, the icon changes to Offline (img2), and when the battery is reinserted the icon changes to back Online (img1).
    The log file shows that “init node thread finished” (snippet1)

But there is no xml file for node 34 in userdata/zwave/ (xml files are generated for other zwave devices, e.g light switch - node 19) (snippet2)

Does this indicate that the initialisation of the hasm100 is complete or not?

img1

img2

snippet1

   2336:2016-11-26 21:55:33.097 [DEBUG] [b.z.i.protocol.ZWaveController:386  ] - NODE 34: Init node thread start
   2366:2016-11-26 21:55:33.206 [DEBUG] [.b.z.i.p.i.ZWaveNodeSerializer:136  ] - NODE 34: Serializing from file userdata/zwave/node34.xml
   2370:2016-11-26 21:55:33.208 [DEBUG] [.b.z.i.p.i.ZWaveNodeSerializer:139  ] - NODE 34: Error serializing from file: file does not exist.
   2376:2016-11-26 21:55:33.216 [DEBUG] [p.i.ZWaveNodeInitStageAdvancer:188  ] - NODE 34: Starting initialisation from EMPTYNODE
   2388:2016-11-26 21:55:33.217 [DEBUG] [p.i.ZWaveNodeInitStageAdvancer:287  ] - NODE 34: Node advancer - EMPTYNODE: queue length(0), free to send(true)
   2389:2016-11-26 21:55:33.218 [DEBUG] [p.i.ZWaveNodeInitStageAdvancer:344  ] - NODE 34: Node advancer: loop - EMPTYNODE try 1: stageAdvanced(false)
   2390:2016-11-26 21:55:33.218 [DEBUG] [p.i.ZWaveNodeInitStageAdvancer:349  ] - NODE 34: Node advancer: Initialisation starting
   2391:2016-11-26 21:55:33.218 [DEBUG] [p.i.ZWaveNodeInitStageAdvancer:1148 ] - NODE 34: Node advancer - advancing to PROTOINFO
   2393:2016-11-26 21:55:33.218 [DEBUG] [p.i.ZWaveNodeInitStageAdvancer:344  ] - NODE 34: Node advancer: loop - PROTOINFO try 0: stageAdvanced(true)
   2394:2016-11-26 21:55:33.218 [DEBUG] [p.i.ZWaveNodeInitStageAdvancer:358  ] - NODE 34: Node advancer: PROTOINFO - send IdentifyNode
   2395:2016-11-26 21:55:33.219 [DEBUG] [p.i.ZWaveNodeInitStageAdvancer:254  ] - NODE 34: Node advancer - queued packet. Queue length is 1
   2397:2016-11-26 21:55:33.219 [DEBUG] [b.z.i.protocol.ZWaveController:476  ] - NODE 34: Init node thread finished

snippet2 - no xml file for hsm100 (node 34)

ll /home/avner/openhab2-master/git/openhab-distro/launch/home/userdata/zwave/
total 28
drwxrwxr-x 2 avner avner 4096 Nov 26 22:02 ./
drwxrwxr-x 4 avner avner 4096 Nov 26 21:55 ../
-rw-rw-r-- 1 avner avner 4782 Nov 26 21:57 node14.xml
-rw-rw-r-- 1 avner avner 5140 Nov 26 22:02 node19.xml
-rw-rw-r-- 1 avner avner 1296 Nov 26 21:55 node1.xml

I can’t see anything in the logs showing any communication with the device, and there’s no XML, so initialisation almost certainly isn’t complete.

I thought that an Online icon means that the device finished initialisation (since the hsm100 does not show the specific Unitiialised icon).

Moving on, I forced the zwave binding to recognise the hsm100 to be not-listening by applying a minor code change (see snippet1). After this the device shows as not-listening (see img1).
(My hope in doing this is that by setting openhab to recognise the device as not-listening it will not send messages that will get lost, and that with pressing enough times on the device I will awake it as much as needed to complete the initialisation)

I then run openhab in debug mode and I’m looking for the message pair (see snippet2) but the second message (completion) never appears. I press the device numerous times to wake it up but the initialization still doesn’t complete. The log file can be found here.

snippet1

cat org.openhab.binding.zwave/src/main/java/org/openhab/binding/zwave/internal/protocol/serialmessage/IdentifyNodeMessageClass.java
...
        boolean listening = (incomingMessage.getMessagePayloadByte(0) & 0x80) != 0 ? true : false;
        if (nodeId == 34) { // avner
            listening = false;
        }
        boolean routing = (incomingMessage.getMessagePayloadByte(0) & 0x40) != 0 ? true : false;
...

snippet2

NODE 34: Node advancer: Initialisation starting
NODE 34: Node advancer: Initialisation complete!

img1 (note that the Routing is still on although I think that since the device is battery based it is not routing - but I assume this does not affect the initialisation. Also, the Frequently listening is set to false)

No - the online not linked to the low level initialisation of the zwave device at all.

No - it won’t impact THIS device, but it will likely stop other devices in your network from working properly!

While this is fine for interests sake, you really need to stop this device from reporting incorrectly that it’s a mains powered unit. Even if you get this device initialising, I think it is fundimentally unlikely to ever work well no matter what you do to the binding.

I completely agree. I don’t illusion myself that a kind of hack will solve the problem at a whole. I am just trying to workaround the initialisation not completing, cause this is driving me crazy for almost a month now! (I tried everything else except to connect main power which I’ll do soon…)

I still have hard to understand how replacing the power source feeding through the same contacts (there isn’t another socket for main power) can be detected easily, but I’m not challenging you. I’ll get to it … (this is somewhat problematic long term, as I am plannning to use the device in a place without main power source)

The opposite, no? The device is battery based but advertises itself as listening (a feature associated with main power). I’m trying to convince the zwave binding to think that it is not-listening i.e. not main power unit.
Regardless, I get your message that tweaking the reporting is a cause for trouble.

While I can sympathise, my concern is that you might get the initialisation working, but then find that this device is causing other problems. As the listening flag is a protocol level flag, the controller will still think that it is permanently listening and available for routing and there is no way to solve this (as far as I know anyway). You might spend another month trying to sort that…

Well, the Aeon device definately does it, but it’s not fed through the same contacts - it has a USB power input.

In any case, the bottom line is that the listening flag needs to change, and my understanding is that since the protocol doesn’t allow dynamic changes, you need to exclude the device to change this.

No - it’s currently incorrectly reporting that it’s always listening which means it’s (incorrectly) reporting it’s a mains device.

But this is the problem - convincing the binding is probably quite easy - but you simply can’t convince the controller (as far as I know anyway). So no matter what the binding does, the controller will still think that this device is mains powered, and it’s the controller that decides routing etc.

Ok, I’m stopping doing code changes and concentrating on changing the listening flag.

Hi Guys,

I have the EZMotion 3in1, which I believe is identical to HSM100. While I have issues with it, I think the only way to set it into being a battery device is through the wakeup variable. There’s no way to detect that it is powered from externally when using the battery connectors for supplying power.

Currently mine is stuck at Node Initialising DYNAMIC_VALUES. I have to have it close to the stick - if I move it away, it will not be seen in logs. The xml is generated.

I had it somewhat working for a while, according to my notes (close to the stick), but then I moved it away from the stick, and only after seeing this thread today, I thought I should give it another go.

What does the listening flag show for your device?

What is the “wakeup variable”?

Devices should report to the controller if they are always listening (ie mains powered) or not - this is done using the listening flag. The problem here is that it doesn’t seem to be possible to change the listening flag to false.

Not sure if it is as easy as to quote the xml (?);

<node>
  <deviceClass>
    <basicDeviceClass>ROUTING_SLAVE</basicDeviceClass>
    <genericDeviceClass>MULTILEVEL_SENSOR</genericDeviceClass>
    <specificDeviceClass>ROUTING_SENSOR_MULTILEVEL</specificDeviceClass>
  </deviceClass>
  <homeId>0xc2f5c852</homeId>
  <nodeId>53</nodeId>
  <version>2</version>
  <manufacturer>0x1e</manufacturer>
  <deviceId>0x1</deviceId>
  <deviceType>0x2</deviceType>
  <listening>false</listening>
  <frequentlyListening>false</frequentlyListening>
  <routing>true</routing>
  <security>false</security>
  <beaming>false</beaming>
  <maxBaudRate>40000</maxBaudRate>
  <nodeInformationFrame>
    <commandClass>MULTI_INSTANCE</commandClass>
    <commandClass>SENSOR_MULTILEVEL</commandClass>
    <commandClass>CONFIGURATION</commandClass>
    <commandClass>WAKE_UP</commandClass>
    <commandClass>ASSOCIATION</commandClass>
    <commandClass>BATTERY</commandClass>
    <commandClass>MANUFACTURER_SPECIFIC</commandClass>
    <commandClass>NODE_NAMING</commandClass>
    <commandClass>VERSION</commandClass>
  </nodeInformationFrame>

Sorry, I must been on another planet. I meant the Stay Awake. Not sure if it really means that the device becomes a listening device though. I remember reading about this when I got it, but many years has passed. It has been working great on my Vera over the years.

Edit: I have Stay Awake at 0.

Thanks - this is the answer… It’s what @Avner can’t get his to show…

Just got my new AeonLab zwave stick gen 5 and checked if the behaviour is different (I was hoping that the problem is in the original zwave controller), but it is the same :frowning:
Still:

  • I cannot get the zwave xml file to be created
  • I cannot change the “Stay Awake” flag (that always shows 0)
  • habmin shows the device as listening.

I want to apply factory reset to the HSM100 but obviously I can not do it via openhab.
Is there another free zwave software that can be installed in Linux (Ubuntu 16.04) that can be used to change the data, or apply factory reset to the HSM100?

The HSM100 manual point to HS2 from HomeSeer but this is an expensive program, and I am looking to apply a one-time factory reset to the device.

You can only do this on the device itself - openhab, or other software, can not do this. Alternatively, you can exclude the device which for most devices will also reset it. Normally there’s a button to do the reset.

The HSM100 manual mentions that

To properly have EZMotion+ included in the routing tables, set 
Stay Awake to a non-zero value, then reset EZMotion+
(Exclude from the network), then add it back to the network.

After I set the “Stay Awake” to non-zero (e.g. 1), exclude and reinclude, the value appears as 0 again…
The manual specifies that valid values for the 'Stay Awake" are 0,-1 but openhab can set only 0 or positive numbers…

Isn’t a positive number a “non-zero” number?

If you want -1, then 255 will be the same if it’s a 1 byte value.