Version 5.2.915 is posted. The big change in this one is that you now have an indication in the Admin Intf. when there is a change in any given tab. It will show an asterisk after the top text line if there are changes. There will be a little delay sometimes, since we don't want to be abusive or anything. It would be optimal if every bit of code just reported somehow that it had changed its data in some way, but that's not practical. So it has to just ask the active tab on an ongoing basis, has anything changed, has anything changed, BTW, has anything changed? We do know when you save of course so it will update immediately on save to get rid of the asterisk.
Anyhoo, this is a small but important improvement that was really missing so far, which will make using the AI considerably nicer.
(03-29-2018, 10:29 AM)jkmonroe Wrote: [ -> ]Dean, now that z-wave is out in testing, do you think you can take a look at adding Hue Dimmer support?   
It's been a couple of months.  Anywhere close to being able to look at this?
(05-27-2018, 09:00 AM)Dean Roddey Wrote: [ -> ]The only thing I can think of is that SmartThings is overwriting the associations or something. We need to see what associations are set on these guys. Most of them, if you take the batteries out and put them back in, will stay awake for a little while. Do do one close by, then go back and use our manual associations dialog to query the associations for group 1. Have it up and ready to go and you should be able to get it before it goes back to sleep. The Ecos typically will stay awake for a minute or so.
If the Z-Stick is in the list of associations then we should be getting talked to.
Also of course just enable tracing and let it sit for an hour or so. Then close it and send me the trace file. We can see if any of them are talking to us.
I am testing with a Linear WADWAZ-1 door sensor. In order to get it to change from a WaitWakeup state to WaitApprove (or whatever it is) I had to do a manual query unit info on the device after I had woken it up. It came back with the info then I canceled out. At that point it went to the WaitApprove state and I could approve it which I did and then I did a save. At this point the unit is properly recognized.
I then went in as you state above and looked at the associations after waking it up and running a query. The zwave stick showed up in group one as being associated.
All good so far, well, mostly...
I then went to the driver tab and looked at the unit status, all I get is ??? for the 3 fields, battery, internal and external sensor.  
I can confirm that the VRC0P is properly seeing the status change of the sensor.
I emailed the log, it ran for an hour. During that hour 9 battery powered devices reported back per the SmartThings Hub logs.  I can list which ones they are if that is useful.
Is there anyone else using SmartThings as a primary that is testing the new ZWAVE driver?
Something is just not right...
In the not so intuitive category...
How does one cause an update from the master controller to reflect a new device? I am am reluctant to click on the Include/Exclude function and start it with the master controller as this is the method I used to exclude the stick when I started over. I don't want to start over, I just want to update for a new device.
BTW, updated to .915 this morning, like the * on the Admin tab to reflect need to save, nice!!!
You just include again. Put the master into include mode and do Include/Exclude. Which one happens is purely a function of what mode the master is in. We don't get to indicate we want to do one or the other. We just go into include/exclude mode and the master (if he is in one of those modes) will tell us which one it is. If it's an include, and we are already included, then we just get our Z-Stick's list of nodes updated, which tells us there are new (or removed) nodes.
What is the node id of the Linear unit you were messing with?
Node ID #3.
Emailing device info for a Yale YRD226 lock.
So, looking through that, there's some interesting stuff. Lock node 6 reported battery level and state for a while, then it stopped responding altogether for a long while. Well, actually it responds to a request for a nonce, but never responds to the request that was then sent.
There are plenty of async notifications from unit 3, whatever that is.
There is not a single wakeup in there, so no units ever sent us a wakeup, at least not during this trace, which is an hour long. That's not necessarily impossible, often the wakeup period is pretty long. But you'd think that at least one of them would have. Still, in order to for that to happen, they have to have gotten the config msgs and gotten the association set. Until that happens, the association will not be set, so we'll never see any wakeup.
It's a bootstrapping thing that may be biting you. What we really need to get a trace of is you doing a wakeup on one of the units that is not in WaitApprove state yet. So do that.
1. Reset the trace then enable it
2. Make one of the units wakeup that is not in Wait Approve
3. Then close the trace and post that
Lock ID #6 was off line when I replaced it (that might have been during my trace, sorry), it's now back together and sitting on a table, it's eating batteries so I replaced it with the new unit I just sent you the info on.
Emailed the trace on a WADWAZ-1 door sensor unit id # 0x1B
There was nothing from that unit. What did you do to wake it up? Did you take the batteries out and put them back in?
I saw you add the new lock back in and that all went fine. Can you flush the trace, lock it, then unlock it, then close the trace and post that? I just want to see what it uses to send lock state changes. That's one of those stupidities of Z-Wave, there are all these different ways it can do it and there's no way to know without just trying it.
(05-29-2018, 10:23 AM)Dean Roddey Wrote: [ -> ]There was nothing from that unit. What did you do to wake it up? Did you take the batteries out and put them back in?
I saw you add the new lock back in and that all went fine. Can you flush the trace, lock it, then unlock it, then close the trace and post that? I just want to see what it uses to send lock state changes. That's one of those stupidities of Z-Wave, there are all these different ways it can do it and there's no way to know without just trying it.
I took the cover off, that's all I had to do the last time to get it to show up, didn't have to pull the battery.  I'll pull the battery this time and send again. Trace emailed.
On the new lock, it's not showing anything in the trace when I lock / unlock, there's no device file for it yet.  Old lock is ID #7, new lock is ID # 0x39 and it's in a GetUnitInfo state (which is what I sent you via email)
I did unlock / lock new lock while trace was running.  Also did a lock / unlock on other old (not replaced, sorry confused the 2 locks) yale lock, ID #6. I am having trouble with the message getting through, the lock locked but did not unlock, had to do that manually.
Uhg, didn't hit post before I ran my errand, well, you got the email a while back with the trace, here's the info...