(05-20-2018, 10:29 AM)Dean Roddey Wrote: [ -> ] (05-20-2018, 05:07 AM)batwater Wrote: [ -> ]On ZWAVE:
- You have a typo on the Linear devices, one of them is named Linaer instead of Linear.
- If I manually identify a device I am not getting any activity in the the driver, e.g. I manually added a door sensor and it is not showing an open status when I move the magnet away. Both SmartThings and VRC0P properly show open/close status.
- My ZWAVE stick is continuously cycling between Blue, Orange and Red
- Wired devices respond properly
Keep in mind that, for anything you set up the device type, that has to either be a generic handler, or it has to be one that we have info for but it doesn't support manufacturer id query. You can't set something to some other type that seems to be similar. Did you select a generic handler?
If so, then you have to do any association and config parameter setup. The driver doesn't know what is appropriate in that case. So use the manual configuration dialog to set that up, else the driver will never see changes. Since its battery powered of course that msg will just get queued up and you will have to either wake the device up or wait for it to wake up on its own so that the driver can send the msg. Until that happens, it still hasn't been done.
I selected the specific already defined device handler for the device.  I've woken the device, 2 different ones actually, neither are reporting back any state changes.
3 of my devices are sealed as they are gate sensors and exposed to the elements I have no desire to unseal them to "wake them up."  It would seem to me that activity from the unit, e.g. open, close should cause a wake up event, yes? 
Also how do you delete a device if the wrong handler is selected manually?  Not that I did this but I could see where this might happen.  It would be unfortunate to have to delete everything and start over just for one device.
The Fibaro Door/Temp sensor I sent a while back is not included in the list.  Do you still have that info or do you need me to resend?
What is the make/model? I guess this one doesn't support manspec class, so it went to WaitDevInfo state?
Activity from the unit doesn't wake them up. When they send out state changes they wake up just long enough to send that msg and go back to sleep immediately. There's no chance to talk to them. That can only happen when they actually wake up, which causes them to send out a wakeup msg which means, talk to me know if you have anything to say. If they are sealed, and have no external button to make them do it, then presumably you have to just wait for them to do it themselves, which they will do eventually, though it can be many hours in some cases. Until that happens any setup won't have been sent to the device. Also, if you cycled the driver or CQC while waiting for that to happen, those msgs will be lost. Battery powered devices sort of suck.
If you select something wrong, just force it to rescan. That's what you'd also do if you selected a generic type and later full support was added.
I don't see the Fibaro sensor, so you might have to send it again.
Hmmm, Okay, well I'm trying to generate a new dump for you for the Fibaro door/temp sensor and I did get partially there this morning, the unit is now indicating a status of "NoAutoMat" but I don't have a way to save anything. I think I may have canceled out of doing a save because I thought I had already sent it to you and I was running out the door...
I'm guessing I should just run another query while the unit is awake?
Also, if I choose query unit info and then hit cancel I get an "Unhandled exception in GUI thread 1963689468 is not a valid timer id.
(05-20-2018, 11:17 AM)Dean Roddey Wrote: [ -> ]Activity from the unit doesn't wake them up. When they send out state changes they wake up just long enough to send that msg and go back to sleep immediately. There's no chance to talk to them. That can only happen when they actually wake up, which causes them to send out a wakeup msg which means, talk to me know if you have anything to say. If they are sealed, and have no external button to make them do it, then presumably you have to just wait for them to do it themselves, which they will do eventually, though it can be many hours in some cases. Until that happens any setup won't have been sent to the device. Also, if you cycled the driver or CQC while waiting for that to happen, those msgs will be lost. Battery powered devices sort of suck.
Okay I get that I have to wait but for how long? Last go around before I rebooted this morning was for something like 4 days with no updates showing up on any battery device, something is not right.  I think I mentioned that my z-stick is continuously cycling between Blue, Orange and Red.  So while the wired units and the battery operated locks are operating correctly none of the other battery powered units are.  I'm wondering if I should start over and nuke everything, remove the z-stick from the master controller, and re-do everything?  If I get the same behavior at that point I can open my system up to you for diagnostics.
What version are you on? Even if you maybe restarted before the auto-config messages were sent to battery powered units, they get sent once a day randomly and at some point after that the units would wake up, and those would get sent. But, generally speaking, the only way that it wouldn't be getting the messages is if the associations weren't set.
Of course, battery powered units, being annoying, won't let us directly ask them for association info. But, what you can do is:
1. Pick one of the ones you can open up and force to wake up
2. Enable tracing
3. Go to the manual associations dialog and query the associations (probably group 1 is the right one.) Leave the check box uncheck to indicate that it's not currently awake.
4. Go make it wake up by swapping the batteries. That should let the query get sent
5. Disable tracing and post the trace file.
That will at least let us see the query associations msg. Or, alternatively, if you know one of the ones not responding stays on for some period of time after you swap the batteries. then you can:
1. Quickly go enable trace
2. Do the manual association query of group 1 and check the 'i know it's awake' box
3. Then it should let you send that msg right then.
4. Does it show that the Z-Stick is in the list of associated nodes? If not, what's in there?
5. If not, then it hasn't gotten set.
6. While it's hopefully still awake, for an auto-config, and say it's awake now to send them now
7. Then do the query again and see if the association is set.
(05-20-2018, 06:03 PM)batwater Wrote: [ -> ]Hmmm, Okay, well I'm trying to generate a new dump for you for the Fibaro door/temp sensor and I did get partially there this morning, the unit is now indicating a status of "NoAutoMat" but I don't have a way to save anything.  I think I may have canceled out of doing a save because I thought I had already sent it to you and I was running out the door...
I'm guessing I should just run another query while the unit is awake?
Also, if I choose query unit info and then hit cancel I get an "Unhandled exception in GUI thread  1963689468 is not a valid timer id.
You would have to make it wake up. Hopefully it stays awake for a minute or so. So quickly go do the unit info query. You have to hit Start to start the process. It will do all the queries (if it can) and return the information.
I'll check the timer thing. Probably it never got started if you didn't hit start.
I've done the work, AFAIK, to prevent the driver from sending out event triggers as it sets initial values on fields during their connecting phase. This was pretty brutal and I still need to test it out to make sure I didn't make a mess of things.
And it still won't necessarily stop it if drivers don't get their fields updated before they report connected. In some extreme cases, like the new Z-Wave driver, this isn't practical since gathering field values is all done async (else it could take a long time) and it's messy to even know when they might have finally gotten their values.
But, for the vast majority of scenarios it shouldn't happen anymore.
A lot of testing on the above, and that brought up some other things and working out those, and that brought up some other things and working through those, and I think a few more rounds of that. But it seems to be working correctly. The other stuff I did today, I probably should have let sleeping dogs die, but for whatever reason I did it. I ended up backing a little bit of it out because it was too much for this late in a release cycle. But some good simplifications and consolidations were had by all.
I'll get another drop out tomorrow.
Version 5.2.914 is posted. Once again, because of changes that I can't afford to make backwards compatible before we even release the driver, you will need to delete the config file. So pause the driver, delete the config file, then upgrade. If you delete then update, it will create the file again when the driver stops. So pause, delete, then upgrade.
This version actually has some hard changes, most of them oriented towards trying to prevent driver's getting their initial field values from generating event triggers. This can be annoying. They trigger because the new value is different generally from the default that was in the field upon creation. How they are dealt with was changed in order to provide more control over when they happen.
It can still happen once in a while. If a driver comes up to connect state before he's initialized (or put into error state) all of his fields, and then he stores a value, that will trigger it because the driver is connected and the field is not in error state, so it's impossible to tell that from any other regular field value update. Few drivers would do that. But, still, we can't guarantee it won't happen once in a while on some drivers.
This one addresses the issue of Z-Wave units that support the battery class, but don't report it async, they require that you get it when a wakeup occurs. This requires that the device info indicate correctly that it is of that type, and not all of them will have correctly gotten updated yet, since I don't know for sure which ones it might be. So if you see any not getting battery info, let me know. I verified that the Eco ones do and updated those so they should work right now.
BTW, I realized that the Eco units you don't have to change the batteries to wake them up. Just open and close the case and it sends a wakeup. Changing the batteries makes it send a node info frame, but the driver will ask for one when it gets the wakeup if the unit is in WaitWakeup state. You can still change the batteries and make it go a bit faster, but it's not necessary for those, or at least all the Eco units I have.
Well, the best I can tell about the Schlage lock is that it is a buggy piece of junk. It just doesn't work right. I noticed it's not even a Schlage lock, it's made by some generic Chinese company and branded by Schlage. Half the time it just doesn't respond to anything. I set up the device info so that you can set the type manually, but it doesn't work. It doesn't seem to send any notifications or respond to any queries. Once in a while it responds to a battery level query. One time in many it will get through the device info queries successfully.
I've seen various other complaints out there about these older Schlages. Apparently they were not so great, and I can't see what else to do.
Of course there may be issues because it's not actually in the door and there's something about the actual bolt being int here that causes it to act differently. But, it's not responding to lots of other things besides the door lock state.
It hasn't destroyed my Z-Wave network, but yours is more complex than mine.