Charmed Quark Systems, Ltd. - Support Forums and Community

I got a letter from the Chamber of Hot Chicks today saying I've been officially removed from their contact database.

I just upgraded from 916 - 919 (been on vacation) when the machine that had all of my Sonos drivers restarted (I rebooted due to OS patches as well) only 1 of the Sonos drivers actually started, the others remained red. I let it sit for 5 minutes and it remained the same. I restarted the CQC services on the machine and they all came up. The master server was up and running when this happened.

Also, with the new zwave driver turned off the week that I was on vacation my locks had zero battery drain. So even though the locks were registered and approved with the driver they were getting the life drained out of them whilst the driver tried to reconcile the other battery devices that were not recognized.

If you were rebooting after OS patches my guess is that CQC came up before everything (like UPnP) was ready. Do you have CQC set up for delayed start? It's probably a good idea to do that. That's the default now, but it used to not be available on Win7 so older systems are often still on non-delayed start. Even on delayed start it might still be possible after a bigger OS upgrade reboot that we might still come up early, but generally that should work, since it will wait for key stuff to come on line first before starting the delayed ones.

If the locks were in ready state, there was nothing going on with them but the 10 minute inactivity ping, and a considerably longer battery check. So presumably even that is too much for them. I'll adjust that so that it's maybe an hour ping for those types of frequent listener units. If they can't handle 24 pings in a day without draining the batteries that would be pretty sad. We do need to have some idea if units are responsive so that we can warn about it before you actually try to use it and it doesn't work.

I've reworked the Z-wave driver to do a graduated timing scenario. Both for when it's trying to move up through the states to get to ready, and once ready in the periodic poll it does for listeners. It'll start with a fairly quick retry of 15 or 30 seconds, and on each failure will increase that until it hits a fairly long period, such as 30 or 60 minutes for battery powered units. That way, we get a handful of reasonably quick retries at the start or after a failure, to try to get something if something is forthcoming, then slightly longer in case it's just some temporary glitch, and finally just an ongoing quite slow period just in case it should come back to life.

So we have a reasonable chance of getting what we need without giving up too quickly, without waiting a long time just because it might have had a hiccup but otherwise is responsive, and then eventually not to use up undue battery in an ongoing way if something is really interfering with communications (it's there and seeing our msgs, and therefore we are waking it up, but we never see the response so we keep waking it up.)

That should be a pretty good compromise.

And each CC can set a default poll interval that will be used after any good response (or async) as the next time to check. So the above progressive timeout is for when things aren't going well, and the default is used when things are. So those that don't need to poll often can set it to hours, but if something goes wrong, the above kicks in and we try to recover quickly as we can if that's going to be possible.

I've been running various scenarios today to test the stuff above and refine it. Basically just always trying to recover as quickly as reasonable when possible, but stop using battery quickly when not. It's starting to work pretty well. It's a pretty slow and tedious process with a lot of waiting involved, but hopefully by later today I can get a new drop up with these changes.

Not quite going to get a new drop out tonight, but it's getting pretty well honed now. I'm just doing scenarios then going through the trace carefully to make sure that it looks like what should be happening is happening. I'll do a bit more testing tomorrow and get a drop up.

OK, 5.2.920 is posted. This one has a lot of improvements to the Z-Wave driver, some of which were discussed above, and others related to those issues. So it should be better about recovery, quicker when it's possible, and minimizing battery usage when it's not. And various other general improvements. So give this guy a try. Note your battery levels and check them in a day or so and see how they are doing.

It also has some RA2 driver thermostat support fixes.

OK, I got my updated audio interface in place now, and it's vastly better than what I had before. I ended up undoing the big re-do that I did the other day to try to get the computer away from the audio gear, since clearly the problem was the final unbalanced run to the back of the computer to get into the sound card. Now it's USB to the computer and all the analog audio connections are balanced, so there's no hum with the computer in the rack. And how I have external analog speaker and headphone volume controls, which is very nice. And the audio interface provides its own analog local monitoring so no possibility of latency as when going through the computer and back out.

Anybody get a change to try the latest Z-Wave driver? It should be well worth the upgrade. It's got a lot of improvements.

Not yet, work is interfering with fun, maybe this evening...