The device is discovered and identified correctly as a Minimote.
However, after a few wake-ups, while it does receive the NIF, it doesn’t seem to be going beyond that? It’s not even clear to me whether its doing anything with the NIF. Seems odd (at least to me) that the receipt of the NIF is appearing in the log file before the WAKEUP notification is logged. But maybe that’s normal. I also see that the NIF contains an unsupported command class (COMMAND_CLASS_ASSOCIATION_COMMAND_CONFIGURATION). Could this be causing a problem?
I’ve just updated the binding (link still at the top of this thread). Two points to note -:
This version now has the “new” DEAD node code merged.
The filename has changed to version 2.4-SNAPSHOT
There are still a couple of issues I will try to merge in the coming days, but if there are no major complaints with this version in the next week or two, then I will merge this into master.
Hi Chris, I have been frequently updating my zwave binding from this thread without any major issues. I just tried out the new version of the binding you posted and now see issues with node availability. About 1/3 of my nodes show as offline, I have approximately 60 mains devices and 1 battery device (Yale deadbolt). I can post a log file, I just need to first update my logging config for zwave to write to its own file as I have other noise in the main log.
Right now, I have only two dead nodes. So, it appears to sort itself out with time. These nodes will eventually wakeup and raise from the dead. I’ve seen no loss in functionality due to this. After a restart, devices of all types can show up dead. After a day or so, the mains piowered devices are alive and some battery devices are dead. Give it a few more days, and they seem to all get sorted, for the most part. I have not been able to identify anything in the logs, but it seem to be related to battery devices going to sleep and being marked as dead. Right after a restart, it looks like mains devices are being marked dead due to the amount of traffic.
I think one of the most important things to do in preparation for the merge is to find a prominent place in the zwave docs to educate people on the need for deleting Things. Not just for the upgrade, but for updating Thing definitions that have been changed. Maybe this would fit in the Device Database section, but it’s kind of buried.
I also see in the logs that the WAKE_UP_INTERVAL_GET is not working. I suspect this may be the reason why it’s not progressing through initialization?
WDYT?
@5iver I see you made the change to the Minimote database entry. This is what appears to be causing the WAKE_UP_INTERVAL_GET to fail during initialization (i.e. I don’t think the Minimote supports this transaction).
I made that change, but WAKE_UP_INTERVAL_GET was failing before this was done. I thought there was more progress made with this, but it looks to have just stalled out. This PR did not resolve the issue, and appears to have made it worse, so maybe it should be rolled back? What’s odd is that there must be another change involved, because I was able to initialize minimotes after this PR was put in.
If you’re ok, I’d like to change it back to NOGET, then see what happens. I don’t know if this is the reason why the devices aren’t initializing, but it will remove one variable.
Interesting. Have you been able to initialize it (after deleting thing AND node.xml) with the latest dead node handling code?
I have three Minimotes. Two of them are white ones with the numbered buttons. Those will not initialize. One is a black one with the unnumbered buttons. That one initialized successfully. All three report the same firmware number. Which device(s) do you have?
I have the first gen (numbered buttons). I just deleted the Thing, deleted the XML rediscovered, and it came right back up. Maybe I need to restart after deleting the XML? How close is the minimote to the controller when you are waking it up, and have you tried it closer?
Hang on… something’s fishy here. The device works and Habmin shows it as initialized, but no XML was created. Hmmm…
It’s within about 15 feet of the controller. It seems to be communicating fine.
Looking at the HABmin UI, everything looks correct
When I wake it up, I can see the binding receive the NIF
During initialization, I see the binding send the WAKE_UP_INTERVAL_GET, but it gets no response
When I press a numbered button, I see the binding receive the SCENE_ACTIVATION command, but the binding complains about SCENE_ACTIVATION command class not found
Restarted the binding and it came up fine… and XML was there. SCENE_ACTIVATION is properly reported and item linked to the channel is updated. Not seeing the same issue. Charge it up?
I’ll try this proper… delete the Thing and XML, and then restart OH before discovering.
Sorry - I’ve not had the chance to look at this yet as I had to go out last night. I’ll try and take a look tonight.
I think this is normal. The NIF is also used as a wakeup - so the NIF is processed, then the binding sets the device awake.
No - this class isn’t supported, but it isn’t needed (unless you think otherwise?). It’s a strange command class and certainly the fact that it isn’t supported will have no impact on the use of the device.
