(05-07-2018, 05:01 PM)bryanb Wrote: [ -> ]Dean,
I disagree. I have tried to move from the old IOS app to the WebRIVA and the experience is just not as good. Mainly because of the reconnect time. It's a good 7-8 seconds to get to a usable point with the WebRIVA interface and only 2-3 seconds with the IOS app. So please don't drop the iOS app.
Bryan
Bryan,
I have 4 iPad 2's up all the time mounted to the walls. With the old IOS app after I rebooted the CQC server(or took an update) I had to run around and check the IOS app to see if it had disconnected and click ok to re-connect at least 50% of the time. With the new WebRIVA I never need to do that. the WebRIVA is by far more stable and reliable.
When I press the CQC shortcut on the IOS home screen my template is up in under 2 seconds. You are right that if there is a disconnect the WebRIVA will go to a grey "Connecting" screen and the old IOS app would just fill all fields with Question Marks.
Maybe Dean can add a startup "-option"   for reconnecting screen color "black" to make it less noticable.  I will trade the Grey vs Question Marks behavior anyday for the much improved reliability.
If your behavior does not match above let me know maybe I can try to reproduce what you are seeing with my iPad WebRIVA so we can resolve your issue.
Thanks
Kevin
I got all the old code for querying all the info about the units, which was spread out and done asynchronously, boiled down to a single, synchronous chunk that can be used for gathering full info for those that we need to get it for in order to add support. That will take a little bit to get through so the info display dialog had to be updated to work in the background to wait for the operation to complete. I think I have that done, plus a bunch of other tweaking and I think all of the old functionality back working again.
Hopefully I can get a drop out tomorrow. I was doing to do it today but distracted by figuring out some issues in the April Windows update that might affect some folks.
OK, I've posted 5.2.910. This is a large reworking of the Z-Wave driver.
BEFORE YOU UGPRADE if using the new driver:
1. Unload the driver
2. Delete the files in [cqc]\CQCData\Server\Data\ZWaveUSB3\ on the machine where the driver is loaded. One of those of course is the config file. The format of that was completely changed and it's not justifiable to try to be backwards compatible on such a big change for drive still beta testing. So we need it to start over.
In the new driver these things are different:
1. There are fewer states, and a lot fewer steps. So it should get up and going a lot quicker
2. It doesn't gather all the info it used to gather. All it really cares about now, except when we want to get full info in order to add support for the unit, is the listening type and can it get the man ids in order to auto-id the unit. So it does no more steps than are required to get that info.
3. On the off chance a non-listening unit is awake, it will make one attempt to talk to it before going to WaitWakeup state. That will sometimes get us there faster as well.
4. At that point it is where it used to get to, of either waiting for a unit to wake up so it can get the info, indicating that it can't get that info because the unit doesn't support it, or auto-id'ing the unit and waiting for approval.
5. When you get unit info for a new unit in order to send us the info file, it doesn't automatically display it, since it doesn't have it yet. There's a now a Start button to start the process. That will ask the driver to do all those queries right then and then return the information.
This was a big reworking. And, though I fixed a lot of things from the original version as I went through it really heavily, it's always possible I introduced some bugs as well. But I think overall this guy should do far better. So give it a shot and let me know how it goes.
One thing we will test is that, when you delete the config file and start from scratch, it will have to get all the data without doing a replication first. This was somewhat iffy on some systems because they have iffy comms and probably too much traffic from multiple Z-Wave controllers and that would make the initial query for basic info unreliable, which throws everything else off. I've tried to work around this, so we'll see how it works.
* I've got a handful of non-ZWave issues on the list but I left them for the next drop since I wanted to get this out there before I started messing with other things.
Dean,
is the "Approve New Units" Option new? I like it. Maybe I just missed it before.
ok removed driver, deleted files in "ZWaveUSB3S" directory, re-installed driver:
some units of identical make/model are coming up "WaitApprove" as "ACT LRM-AS" not sure what make that is
.
I did a re-scan units on  two of the devices:
Unit_9  and unit_B  fixed themselves and went to "WaitApprove"  "Leviton VRMX1"
my Unit_2 came up "WaitApprove"  "Cooper" "RF9540-NAW"
      I did a re-scan on that unit:  It came back as "WaitApprove" Leviton "VRMX1"  should be a Leviton "VRPA1-15A
My unit_C is identified correctly  "VRPA1_15A"  and it identified it correctly.
    I did a re-scan on that unit: it changed to "Wait approve" "leviton "VRMX1".  Now it is wrong since it is a VRPA1-15.
Thanks
Kevin
That's something that used to happen in the old client driver. I wonder if somehow that directory didn't get cleaned out? If you do the Get Unit Info option does it have the Start button?
Approve New Units was always there. I'm not sure how you would have gotten working units without using that before.
(05-10-2018, 04:27 PM)Dean Roddey Wrote: [ -> ]That's something that used to happen in the old client driver. I wonder if somehow that directory didn't get cleaned out? If you do the Get Unit Info option does it have the Start button?
Approve New Units was always there. I'm not sure how you would have gotten working units without using that before.
Yes "Query unit info" seems to work.
If I try one of the units that was wrong 25% of the time I get "The query process failed, you may try it again nif you wish. The reason was "The non-secure classess could not be gotten"
The other 75% of the time it returned(with a Save button)
Name: Unit_9
Id: 9
Listener: True
Freq Listener: False
Man Ids: 1D 602 334
Classes: 
    MLSwitch (1)
    SwitchAll (1)
    SceneAct (1)
    SceneActConf (1)
    Association (1)
    ManSpec (1)
    Version (1)
    Naming (1)
    PowerLev (1)
It's just bad comms to that unit, so that it's not reliable and only works some of the time. Any way you can get the Z-Stick into a better position? How far is that unit from it?
Of course it may also be because you have two other controllers on the same Z-Wave network who may be beating the crap out of it for all we know. That wouldn't help things either.
Could you possibly, just as a test, pause the driver, delete the file again, then pause the VRC0P driver and the Smartthings driver, then resume the new driver and let it go back through the process, then play around with it and see if there's any difference in how it responds?
I found it. It was a sorting problem. I'll get a tweaked version up here in a bit.
Well, there was a sorting problem, but that didn't stop the problem. It seems to randomly choose two each time. The reason it's getting the ACT/LRM-AS is because it's at the 0th position in the man id to device info map I'm sure. I'll look deeper.
OK, I figured it out, something else stupid which was interacting with the sorting error, and which was also making for more work during startup as well, so a good fix all around.
There are some issues with some of Kevin's units but it may be because he's made changes since I last got him to do a replication for me. But definitely units 23, 21, 20, 22, 24 (decimal id) are consistently not responsive and the trace file is a mess of failures on those. Everything else pops up quite nicely now.
Are those actually battery powered ones? I don't remember. The driver is showing them as listeners, but there could be some issue there. If I'm seeing them as listeners when they aren't, that would cause the above. Otherwise they would fail the initial attempt and go to WakeWakeUp. I'm not actually showing any WaitWakeups which leads me to believe that this the case, since I'm guessing you do have some battery powered ones that aren't locks, right?