I've posted 5.2.913. This one has some more Z-Wave improvements. It also includes some new options for popup placement. You've been able, for a long time, been able to provide an 'At' point. The popup would be placed such that its upper left corner is at that spot. The default value is -1,-1 which means just center it on the parent template.
A problem with this is that you have to provide that point at design time. But, if that template ends up being loaded into an overlay, that point you set, which is relative to the origin of the template being edited, will now be most likely wrong. It would only be correct if the template it was loaded into was positioned at 0,0 in the parent template.
So, to allow you to do this kind of placement better, two changes have been made:
New Coordinate Variables
There are now a set of magic local variables which will be set in any action that is invoked by a widget. These will hold the points (at viewing time) of the four corners of the invoking widget, and the center of the invoking widget. They are named:
LVar:CQCSrcWidgetUL, LVar:CQCSrcWidgetUR, LVar:CQCSrcWidgetLL, LVar:CQCSrcWidgetLR, LVar:CQCSrcWidgetCenter
The value will be a point coordinate (in the form x,y), which can be used anywhere a point is required. Since this is gotten at viewing time, it will have adjusted for having been loaded into any overlay, even if nested overlays are involved.
New Alignment Option
There is also now a new (fourth) parameter to the InvokePopup command. It lets you indicate how the popup will be aligned relative to the At point. You can indicate Upper Left, Upper Right, Lower Left, Lower Right, and Center. So, if you want to make the popup show up below a button, and aligned with the left side of the button, you would set the At value to %(LVar:CQCSrcWidgetLL) and set the alignment to Upper Left. So the upper left corner of the popup will be placed as the lower left corner of the button.
If the point is -1,-1, the alignment is ignored and it's just centered on the parent widget. Otherwise, the alignment is used. For backwards compatibility this new parameter will be (in any existing templates) set to Center if the point is -1,-1, and Upper Left otherwise, since that's effectively what used to happen.
Okay so I just updated to 913, unloaded the old zwave driver, deleted the config (C:\Program Files (x86)\CQC\CQCData\Server\Data\ZWaveUSB3S), installed the new driver, then I tried to go into the client interface but I guess it was too soon so I'm getting an error dialog when I try to close the empty client interface tab "Unhandled exception in GUI Thread, No Information Available" I get the same error if I try to close out the Admin Interface, I had to go into task manager and kill it that way. After restarting I still get the same message. I also tried deleting and reinstalling the driver, didn't delete the config the 2nd time and same result. What do I need to do to try to resolve this?
Disregard above. On the master server I unloaded the driver, rebooted the server (1803 installed), deleted the config directory, reloaded the driver, waited a bit, then loaded client side, everything worked as expected.
(time passes while I type this message) Okay, just discovered that I can load the client side driver directly on the master server but not on the machine I had originally performed the update to 913 from. I still get the same error dialog noted above and have to kill admin interface with task manager. However the driver dialog loads as expected. Interestingly the tray app is also not loaded on this machine. I'm rebooting the machine to see if that clears things up.
Update: Reboot did not clear the zwave client driver not loading issue. Tray app loaded as expected.
Okay, now on to the battery devices:
- The 2 Yale locks configured properly without any intervention
- All other battery devices are in a  WaitWakup state, with all of the changes you made, what are the exact steps that need to be taken to get the driver to recognize these devices? Just waking the device up doesn't appear to cause anything to happen.
Just in case others have same issue with "rouge" Zwave units this is my procedure if I delete the config file and re-add Z-stick driver. Not a big deal as I only need to do this when I delete the config file.
Note YBR = (Yellow Blue Red flashing lights come on the zstick)
Before you start the Z-Stick should be flashing YBR. If not pull and reseat z-stick.
Looks like I get stuck in a cycle of 90 seconds of no lights and 5 seconds of lights and driver connected to Z-Sick. In those 5 seconds you can disable a single device.
remove CQC Z-wave Z-Stick driver
remove config  file in the ZWaveUSB3S directory
add Z-Stick driver
Wait 90 seconds (Stuck in Wait for comms resource with no lights on the Z-Stick)
(YBR) Driver Client fills in( most are in GetUnitInfo)
Wait 90 seconds 
(YBR)  disable unit 25 front door lock (fast as you only have 5 seconds)
Wait 90 seconds
(YBR) disable unit 1 master controller
Wait 90 seconds
(YBR) disable unit 32 back door lock
Wait 90 seconds
Driver will now stay YBR flashing so I can make sure Z-Stick has latest network configuration.
Options(Include/Exclude) and sync from master controller.
Wait 60 seconds as Make and models fill in.
Options(Approve New Units)
"easy peasy lemon squeezy"
(05-18-2018, 05:35 AM)batwater Wrote: [ -> ]Okay, now on to the battery devices:
- The 2 Yale locks configured properly without any intervention
- All other battery devices are in a  WaitWakup state, with all of the changes you made, what are the exact steps that need to be taken to get the driver to recognize these devices? Just waking the device up doesn't appear to cause anything to happen.
Remember, wakeup doesn't mean flip the switch or wave your hand. That doesn't wake a device up. For most of these cheap battery powered devices you have to take the batteries out and put them back in. Some of the nicer ones have a button you can push in some sequence to make it wake up for some number of minutes.
That will make the device wake up long enough for the driver to talk to them. If we recognize it, we'll go ahead and try to auto-configure it while it is still awake. Then it will go to WaitApprove. You can then approve it and it will be ready to use.
(05-18-2018, 05:22 AM)batwater Wrote: [ -> ]Disregard above. On the master server I unloaded the driver, rebooted the server (1803 installed), deleted the config directory, reloaded the driver, waited a bit, then loaded client side, everything worked as expected.
(time passes while I type this message) Okay, just discovered that I can load the client side driver directly on the master server but not on the machine I had originally performed the update to 913 from.  I still get the same error dialog noted above and have to kill admin interface with task manager.  However the driver dialog loads as expected. Interestingly the tray app is also not loaded on this machine.  I'm rebooting the machine to see if that clears things up.
Update:  Reboot did not clear the zwave client driver not loading issue.  Tray app loaded as expected.
Fllush the logs, do it and let it fail, then get a lot dump and post it so that we can see what is going on.
Actually at this point I can't get into any driver client from this machine or any machine other than the Master Server.
I wonder if it is due to Win 1803?
05/18 17:44:34-Kitchen, CQCClService, CIDOrbSrvWorkThread_2
{
    CQCKit, CQCKit_ThisFacility.cpp.3522, Failed/Not Found, Error: 6000/0/0
    The CQC Installation Server could not be contacted
      <CQCClService> CQCClService_ClSrvImpl.cpp - 219
}
05/18 17:44:34-Kitchen, CQCClService, CIDOrbSrvWorkThread_2
{
    CQCKit, CQCKit_ThisFacility.cpp.3522, Failed/Not Found, Error: 6000/0/0
    The CQC Installation Server could not be contacted
      <CQCClService> CQCClService_ClSrvImpl.cpp - 219
      <CQCClService> CIDOrb_ThisFacility.cpp - 536
      <CQCAdmin> CQCKit_ClSrvClientProxy.cpp - 155
      <CQCAdmin> CQCIGKit_ThisFacility.cpp - 1090
}
Sounds like it may be the same thing that Bryan is seeing. I have a way to get around it, which will be in the next drop. Int he meantime, I'm guessing that your MS has a mixed case name, maybe with some hyphens in it? If so, just as a quick check, add the name/address mapping to the hosts file on the client (same case as the real name is.) If this makes it work, then you are seeing the same thing.
The thing is, this has to be a bug. Host names are not case sensitive. So I'm not sure what they changed that makes this happen. I hope that they fix it, because it can't be right. Their own docs say the names aren't case sensitive, and it started with 1803, in which they finally removed all of the Homegroup stuff (another step on the way I guess towards NetBIOS going away.) So clearly they changed something, and there doesn't seem to be any documentation that indicates this is how it's supposed to work now.
BTW, you can also test this using ping. Try pinging the server using the actual mixed case name. If it fails, that's definitely the same thing. And we all know that ping should not care what the case is. Then try it all upper case (the NetBIOS style name) and it will probably work.