Charmed Quark Systems, Ltd. - Support Forums and Community

Full Version: Official 5.3 Beta Discussion Thread
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Your file names didn't include the unit ids for the units you got, and I need them for the ones above. I need the ids in order to find msgs related to them in the trace.

But, it appears that either comms are flakey for those, or they incorrectly report that they support something that they don't and we then fail when we try to get it. If you retry a few times do you consistently get the same error? It wouldn't be the first time that a unit reported supporting something and didn't.
what's a unit id?
Each unit has a number that identifies in the Z-Wave network. It should show up in any master controller and it shows up in our driver as well. It's one of the columns in the client interface's unit list.
I was having issues with query info on 2 of the VRI06, but got another one to work. Can't remember which one worked.

VRI06:
9,13,18,20,21,33

GE:
24
As long as one works, that's probably fine. Though sometimes the manufacturer may vary the info in different revisions of a model, generally all instances of a given model should be the same. If you have more than one, maybe get the info on a couple of the happy ones. If they are the same, then probably we are good.
The dump above has one of them, i bought them all at the same time so they should be all the same.
Well, if it ain't one thing, it's another thing... A bit back I got rid of my use of accelerator keys except for top level application hot keys, because they don't work in dialog boxes. I was using them in the attribute editor just to save some work dealing with the raw keys directly. But I changed it over to do that and all seemed well.

But, using alt-arrow keys to change the origin of a widget (when its area is selected in the attribute editor) wasn't working. So I saw that I need to handle WM_SYSKEYXX in addition to WM_KEYXX msgs. So I added that an now that works.

But, I get the annoying boing sound from the system that happens when you do any alt-key combination that apparently doesn't map to an accelerator or menu hot key. I have tried everything to get rid of that to no avail. There are many 'solutions' discussed out there but none of them work.

I've tried to suppress every possible alt- related key event, but nothing works. Somehow the message still gets back to the OS and it makes the sound. Supposedly handling WM_MENUCHAR is supposed to work but it doesn't, and doesn't even called for me.

I may just have to leave it as is for 5.3. I've already made more changes that I should have.
Screw it, I changed it to be Ctrl-arrows as before is change the size and Ctrl-Shift-arrows now controls the origin. It's not worth fighting that. Alt-shifted stuff will just remain for top level menu/accel hot keys.
I updated to 5.2.914 when you updated the ISY driver. That guy works great, but I've been having another serious problem now. My triggered events work great for a few days then they stop working. If I cycle the CQC app shell they'll start working again. I can watch the Event Triggers Monitor and the events show up with the correct source and useract. For example, when I arm my alarm system, the "SecurityArmed" User Triggered Event is supposed to fire. And it does for a few days then stops even though the events keep registering on the monitor. In fact, all triggered events stop working. Scheduled events work fine. I've checked that none of the triggered events are in a "Paused" state even though they really shouldn't have become that way.

A week ago, I updated to 5.2.919 but the problem persists. I'll try 5.2.923 today but I don't see anything in your version notes that makes me believe anything has changed related to triggers.

At the same time as my 914 update, in addition to switching to the ISY driver, I also started pausing and unpausing some of my triggered and scheduled events in my actions (sometimes in rapid sequence with only a 1 second pause) using EventSrv:TongueauseTrigEv(xxxx, True) and EventSrv:TongueauseSchEv(xxxx, True). Could such a pause/unpause mechanism have confused something (even though it's only a small subset of events being paused/unpaused)? I can get around that if you think that's the problem by using the variables driver and some logic. I could also force the CQC app shell to cycle once daily but that's annoying because things like my alarm system start beeping.

How do I figure out where things went weird?
Do you think that networking issue would be the reason a 2ndary server would show fields in black, but the MS shows it in red?

[Image: l9DauKUh.png]