Official 5.3 Beta Discussion Thread

[Dean Roddey]

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?

It would be the most likely reason. If you done click one of them on each machine, what do they show as driver status?

On the secondary driver, open the CQC Command Prompt, and do the usual:

CQCNetTest > nt.txt

and post the nt.txt file. That will show us what is going on from the secondary in terms of connectivity.

[Dean Roddey]

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:auseTrigEv(xxxx, True) and EventSrv:auseSchEv(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?

Definitely upgrade to the latest. Lots of small things have been fixed.

I wouldn't do fast pause/resume operations on events. That mechanism isn't meant for that sort of thing, and it's possible that the event server might get out of sync with the actual configuration. When you restart it, then that makes it read everything back out from the master server again and that would get it back into sync until you freaked it out again.

Definitely use a disabling field for something like that.

[IVB]

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?

It would be the most likely reason. If you done click one of them on each machine, what do they show as driver status?

On the secondary driver, open the CQC Command Prompt, and do the usual:

CQCNetTest > nt.txt

and post the nt.txt file. That will show us what is going on from the secondary in terms of connectivity.

rebooting the MS got it back, will try this next time. This is a tiny, atom-based unit that I got for $180 off Amazon, wouldn't shock me if there are other settings somewhere I need to change.

[Dean Roddey]

I put up a build for 5.3. I won't post it for a day or so yet. If you guys want to go ahead and upgrade, go for it. If no one has any issues, I'll post it.

http://www.charmedquark.com/Web2/Downloa..._5_3_0.exe

I did some trailing small fixes, which are:

5.3.0

• The attribute editor, when the ... is clicked for multi-line text attributes, was not enabling the handling of CRs in our standard multi-line input dialog. So you couldn't get new lines into the text, it would just invoke the default button when you hit enter.
  
• The interface engine's update to use the new publish/subscribe method was checking to see if the changed widget had a parent container and calling the publish call on the parent. But it needs to also see if the changed widget itself is the container and call it on itself if so, else we don't get changes to the template itself reported, such as drag resizing and whatnot.
  
• There were a number of issues with the template itself redrawing properly in the editor window when resized by mouse or keyboard or attribute editor. It wouldn't redraw the selection handles correctly. It wouldn't adjust the window size in all cases to contains the new template size and so forth.
  
• If the mouse was over the template while you adjusted the size via Ctrl-arrow keys in the attribute editor, the status bar would not update to reflect the size change because sizes (as opposed to areas that child widgets have) changes were not being published as widget changes.
  
• The new Integra NR676 support didn't include Video1 in the valid video sources.
  
• Forgot to update the About dialog's copyright date.
  
• If you resized a widget via the attribute editor using the ctrl-arrows or ctrl-shift-arrows, it wouldn't correctly update the display so that the selection handles wouldn't get updated.
  
• When I stopped using accelerator keys in the attribute editor in the previous drop (they don't work in dialog boxes), Alt-arrow keys stopped working for adjusting the position of widgets in the attribute editor window, because apparently any alt shifted key is reported via WM_SYSKEYDOWN instead of WM_KEYDOWN. So I need to handle both of those in my core dispatching framework.
  
• And now using any alt-shifted key combos in a window without a menu or accelerator causes a system ding sound. There is no way to get around this that really works. So, the attribute editor now uses Ctrl-arrows as before for changing the size of a size or area, and Ctrl-Shift-arrows for changing the origin. Oh well...
  
• The Omni client side driver's documentation was not updated to reflect the 5.x UI changes.
  

[IVB]

ok will upgrade shortly. Where does the device support for the additional zWave stuff listed above fit into your future plans? No pressure, just curious. I'm contemplating also replicating to my VRCOP and having 2 device drivers, 2 controllers, as right now half my devices aren't supported by the V3.

I'm also going to disconnect the ISY and list it for sale, that will be a nice day. 3.5 years later, ISY V5 is still in *alpha*!

[Dean Roddey]

It was too late to do those for this release. Once I get 5.3 out officially, a couple days at most I think, I can get back to adding new unit support. Nothing disruptive will be done for a bit after the release, since there is almost always an inevitable follow up release to deal with small stuff that wasn't caught during testing. So it'll be safe enough to grab those post-release betas in order to get the new unit support.

[IVB]

ok cool. Sounds like I really should add the VRCOP back in, so I can control all my devices.

[batwater]

Dean, I just upgraded to 5.3 yesterday. Today just deleted everything, factory reset Aeon stick, did a join to my SmartThings hub, getting ad infinitum dialog box stating: "7 is not a valid value for enumeration tZWaveUSB3Sh::EDrvStates"

[batwater]

Okay, I managed to get one of the Linear WADWAZ-1 door units to get properly configured but the driver is not picking up the values properly from the device and showing ??? instead of filling the fields in.

Steps:

1) follow my published VRC0P manual association method to associate WADWAZ-1 to Aeon Stick.
2) Pause the CQC driver
3) Fire up Zentools and trigger a replication (include/exclude button (replication) from CQC does not work)
4) start CQC driver
5) in client side driver enable the device by rescanning the device (I disabled all battery devices not properly working)
6) wake the device up
7) approve device

Here's the trace of me opening and closing the door sensor:

Z-Wave USB3 Trace
, Time: 10:07:53 AM
----------------------------------------------------

10:08:01 - [ZW->DR] - REQ,Msg:AppCmd/0x4,Recvd: 10:08:01)
{
Flags:
Type: Single
SrcId: 3
Class: Basic
Cmd: Set
Bytes: 00 03 03 20 01 FF
}
10:08:01 - [TRACE]- Processing app cmd. Src=3, Class=20, Cmd=1
10:08:10 - [ZW->DR] - REQ,Msg:AppCmd/0x4,Recvd: 10:08:10) 9498MSs
{
Flags:
Type: Single
SrcId: 3
Class: Basic
Cmd: Set
Bytes: 00 03 03 20 01 00
}
10:08:10 - [TRACE]- Processing app cmd. Src=3, Class=20, Cmd=1

[batwater]

Super, I just tried again to replicate from CQC and it worked. Love the consistency... Not pointing figure at the driver, could be SmartThings hub not responding correctly, dunno.