ZWave Aeotec zwa003 (nanomote) strange behavior

Tags: #<Tag:0x00007f173b4f52f0> #<Tag:0x00007f173b4f5200>

I’ve been banging my head on this problem for the better part of a couple weeks now and can’t get anywhere. I’m going to try and keep this concise but the description is going to sound weird.

OH3 zwave only sometimes gets the id of aeotec nanomotes, does not create xml files for the devices, and does not receive any communication from them even if they are successfully id’d and (I think) initialized.

Full Story:
I migrated from my OH2 native install to OH3 on docker. I copied my security key for the binding over and all my zwave devices handled the migration flawlessly except two: my august lock (half works, but I’ll make a different post on that if I can’t troubleshoot it) and my aeotec nanomote.

When I moved the zwave controller over to OH3 my nanomote didn’t even get recognized by the binding during the search for things to add. All other items were properly identified immediately (or upon one wake-up event) and I added them just fine. The nanomote, which was fully initialized and identified in OH2 and has worked for 9+ months, came up as unknown device and would not resolve.

I know how to wake up the nanomote (I’ve advised people on this forum about waking and initializing this exact device). So, I figured I just had to wake it up more than once to get it recognized. I woke it 2-3 dozen times both with the controller in inclusion mode and not, device plugged in and not, and under no circumstance would the binding get the ID info from the remote. (Interestingly, the online documentation for the device actually lists two wake-ups: the 5 second button press listed in the database doc and a “quick wake-up report” or 2 second button press; I have tried both…numerous times.)

I tried to move the xml over from my OH2 config. When I opened up the zwave folder from my old install there were xml files for all my other nodes, but not this one. The OH2 binding never made an xml for this device but, as I said, the device was configured, properly id’d, and working in OH2. I thought this odd, but was willing to assume that there is much I still don’t understand.

This remote has worked so reliably in OH2 that, fortuitously, I had recently purchased a second nanomote but not included it in my network yet. So, I figured I could test what was going on by adding the second one with my new OH3 setup. The device successfully included and a few wake-ups later it was properly id’d as a nanomote. I added the thing, saw a Request_NIF status on the thing and woke the device again which appeared to complete the process as the Request_NIF status disappeared. I tried to link the channels to some premade items and got nothing from the channels, no response to any button presses and no evidence of activity on this node from the logs even with zwave debug logging.

I checked the OH3 zwave folder for the xml for the newly added remote and again there is no xml file for this device. Files exist for all other nodes but not the nanomote node. Looking at the device itself in the OH UI I saw that it had populated all the correct default values for properties except for lifeline which was blank instead of “controller”. So I tried to change that and couldn’t. Status change message would go out, I’d wake the device, get a message saying the device config had been updated, wait for the polling interval so the controller could read the value directly, and the lifeline field stayed blank. This all sounds like a device that is still, somehow, not fully initialized, so I tried a few more wake cycles and still no lifeline property. Wash, rinse, repeat several times over the course of a few days in case a full network heal fixed the issue and still nothing.

Figuring maybe I messed up the include, I tried again. It is added as a new node, but no matter how many times I wake it up under whatever conditions it will not even get resolved by the binding. I can’t even get back to the point I was at before with it.

I went back to the first device, the one that had previously worked in OH2. I decided that since adding the new device in OH3 had gotten it id’d (at least the first time), I would start from scratch with the original one. I excluded this one, factory reset it, and re-included it. Long story short, it’s stuck at nearly the same point of id’d and initialized but non-functional. The only difference is when the lifeline property appeared blank for this thing I was able to add controller to that property as well as change the low battery alert level (from default 20 to 25).

Still, however, no activity from this device at all when I change the scene and no battery level info either it is just not talking to the controller.

As an added confusion, despite the evidence of the image above, every time I put the controller into inclusion mode, I get the old can’t resolve thingType warning for THIS node:

2021-01-26 21:17:22.466 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 37: Device discovery could not resolve to a thingType! Manufacturer data not known.

These devices have been in the database since 2.5.0.

Alas, I did not think, while I was trying 1000 different things to turn on binding debugging during any of the attempts to include the devices. If it sounds like the issue is the inclusion step, I’m willing to exclude one of them and try it again with debugging, but I’ve done it twice for each of the remotes and gotten the these partial results each time, so unless I’m making the same mistake over and over again, that’s not where the problem lies.

I look forward to someone pointing out the obvious thing I’ve overlooked or absurd mistake I’ve made. Any guidance or suggestions will be gratefully accepted.

OK, that is usually where people go wrong, sometimes you really have to do it so many times it seems crazy


and in the other thread you are saying now same problem with zooz outdoor motion sensor

that is some great digging around for clues, something is up
Create an issue on github, put all of this in the issue

I had been hesitant to do so up to this point figuring it was something specific to my system or the nanomotes. However, seeing the same behavior reported by @DrMett and seeing it myself in a second device, I agree. I’ll open up an issue.

Edit: issue opened here

1 Like

I understand, I think you are on to something thou, post a link to the github issue please
With Chris busy it may be awhile, not sure any of the other developers will mess with it unless we can pinpoint the problem in the code. Know java?

Not enough to do anything but break stuff.

1 Like