Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Official 5.3 Release Thread
#11
5.2.908
  • A first cut at getting the 'widget palette' window back into the IV editor. This one is based one some new underlying Publish/Subscribe architecture that makes it 'easier' than the old one. At least it makes it less likely to get out of sync as changes are made since it doesn't depend on ad hoc code all over the editor reporting changes to it, it's done at a lower level. Let me know if you see it get out of sync. Fixed a few small things found while doing all of this. Also found some stuff not re-implemented in 5.x that are now on the list.
  • Some tweaks to the Z-Wave driver to see if we can make some unhappy locks, which won't respond to secure messages, start being happy.
  • Some new unit support for the Z-Wave driver, I think four new Leviton switch, dimmer, and outlet type units.
Dean Roddey
Software Geek Extraordinaire
Reply
#12
5.2.909
  • Enable remote port access in the recently newly created C++ driver test harness, so that we can remote debug C++ drivers.
  • Add another layer of security to the remote port server by letting the user selectively expose serial ports. Normally it's not an issue since a port already in use by a driver can't be opened again anyway. But there might be devices on serial ports not currently connected.
  • Split the remote port server client side chat window out of the CML driver IDE, so that it can be used there and in the recently created new C++ driver test harness. Currently the C++ driver can't do chat. It didn't matter before because the old C++ driver test harness was a command line thingy.
  • And re-implement the remote port/chat stuff in both the CML IDE and C++ test harness now.
  • In the new Z-Wave driver, if no unit reports ownership of a field id, the driver will attempt to use the returned null pointer and cause an exception back to the client side.
  • The IV editor's 'Copy Point' menu option (which puts the editor window coordinates clicked on into the clipboard) is using a space between the x/y values instead of a comma. The latter is what it should be doing so that it can be pasted into any place where a formatted point would be used.
Dean Roddey
Software Geek Extraordinaire
Reply
#13
5.2.910
  • If you invoke the Negate action command on a local/global variable that has been created with explicit type boolean, the change in the variable's state doesn't cause the variables value serial number to be bumped so it is not seen as a change in value.
  • The Z-Wave driver's periodic 'are you alive' ping is trying to ping even write only units, which fails.
  • Convert our internal handling of incoming event triggers over to use the new publish/subscribe system, which is a lot cleaner way of doing it and deals with multiple consumers much better.
  • Do a mondo reworking of the Z-Wave driver. A lot of the work being done to gather information units really isn't required in our application. Our needs are quite specialize, so all we really care about is the most basic info: is it a listener or frequent listener or non-listener and can we get manufacturer specific ids so that we can id the unit. Since only units that have had a device info file assigned to them are even used, nothing else matters. So we can drastically reduce the amount of work required. And it means fewer unit states to understand or get through. A LOT of other improvements and fixes were implemented as well while going through the code heavily.
  • The above means that the code to get all the info on a unit, which we still need to be able to do for unknown units so that we can add support (but only upon user request now), needs to be consolidated down from the async scheme to being done within the unit info query from the client intf. This means that the query dialog has to be updated to use a bgn thread because it could take ten or fiften seconds or more on a slow system.
Dean Roddey
Software Geek Extraordinaire
Reply
#14
5.2.911
  • A few issues in the Z-Wave driver that were causing units to get mis-identified and various other weird problems were fixed.
  • The Z-Wave driver now correctly gets names from units when they have been assigned one at the Z-Wave level so it should pick those up as the initial default names instead of using the default assigned names.
  • Various other small tweaks to the Z-Wave driver.
Dean Roddey
Software Geek Extraordinaire
Reply
#15
5.2.912
  • I'd never addressed the issue of the new Z-Wave driver losing connection to the Z-Stick. It wouldn't recover from that. It will now appropriately start trying to reconnect.
  • Locks with battery level reporting may need it to be read, i.e. it doesn't just report it async. The Yale locks are that way so update them to do that.
  • Try to avoid redundant wakeups of frequent listeners by remembering the last time we woke one up, and if it's not been more than couple seconds since the last time just send the message assuming it's still awake. This should speed up doing a series of back and forths with such devices. And that of course means getting them out of the way faster so other things can be done.
  • Lots of small tweaks and fixes and to the Z-Wave driver.
Dean Roddey
Software Geek Extraordinaire
Reply
#16
5.2.913
  • The generic RGBW unit handler of the new Z-Wave driver is not marking the dimmer field as as semantic dimmer, which makes it not get picked up by the auto-config as an available field, it only finds the switch field. And of course it's not fully V2 compliant.
  • When a new interface widget is created by copying an existing one, the parent template pointer should not be copied. This was being done and it caused an error because making changes to that widget's id caused it to try to send out a publish/subscribe message which requires accessing the parent. The parent finds that widget in its list, but it doesn't exist because it's not been added to the template yet, it's just been created.
  • When evaluating states in the IV, this is a recursive process, where each overlay passes it on to its children to test themselves against their current states. But the overlay doesn't apply the operation to itself, so you can't hide an overlay based on states.
  • Something got changed on on the attribute editor recently. When there are attributes that are available or not depending on the value of another attribute, the affected ones get their readonly/writeable state set, but they don't immediately redraw to reflect this.
  • When an action is invoked by a widget, there are now four special local variables that will be available (LVar:CQCSrcWidgetUL, LVar:CQCSrcWidgetUR, LVar:CQCSrcWidgetLR, LVar:CQCSrcWidgetLL, LVar:CQCSrcWidgetCenter) which contain the coordinates of the corners of the area of the invoking widget. This allows you to do things like invoke a popup relative to the invoking widget, even if it is loaded into an overlay. You already invoke a popup with a point to put it at, by just hard coding a point into the command. But that doesn't work if the template is loaded into an overlay where its position will change based on the position of the overlay it is loaded into.
  • Add a new (fourth) parameter to the InvokePopup action command. This one lets you indicate how the popup is aligned relative to the At parameter. You can center it over the point, or put any of the corners at that point. This plus the previous change allows for a lot of flexibility for positioning popups even when the invoking widget is loaded into an overlay.
  • When the tray monitor handles a remote file invocation, it is locking before it tries to force the app ctrl window to the foreground (necessary to do certain things.) It is possible this could somehow cause some sort of deadlock in some circumstances.
  • For some reason the At point of popup/popout invocation is formatted with a space between the x and y values. The editor's copy/point used it for that reason as well. This is not the standard format for a point, so you can't paste it into a point in the attribute editor without adding the comma. So just change it to use a comma. For backwards compatibility also accept the space based version. The same for areas, though those aren't really used too many places currently.
Dean Roddey
Software Geek Extraordinaire
Reply
#17
5.2.914
  • To provide a workaround for an issue that Bryan has seen since the 1803 Win10 update, update all of the code to use a single host name query for all network operations. Create a separate one that gets an 'OS level' name, which in our case would be the NetBIOS level name, mostly just for diagnostic purposes. Update CQCNetTest to display both.
  • Update the one query created above to look for a CID_DNSNAMESTYLE environment variable. It can have the values Lower or Upper to cause the name reported back to the program to be upper or lowered cased. This is to perhaps help with the problems (hopefully interrim problems to be fixed by MS) that showed up for some folks with the Spring 2018 updatupdates (version 1803.) Some folks can only get lower case names to be resolved and some only upper case. If not set, it just returns the name as the OS API returns it, which seems to be as entered by the user when setting the host name. You would typically set this in the system section of the environment on servers, which is also secondary servers, or any machines running things like the tray monitor or using the IV's remote control interface, i.e. anything that is going to register server side functionality for other CQC machines to access. You would need to restart the machine or restart the CQC service and the IV/TrayMon programs to get them to pick it up. In the CQC installer, you can set whatever case for the MS name you want, so on a pure client (IV, no remote control) there's no need for it.
  • In the Insteon ISY driver a dual outlet/button device of type 2.57.xx should be treated as two lights, not a light and a button.
  • Do the work required to suppress event triggers while the driver is starting up and getting its initial field values. This is annoying and it only happens because the new value is always different from the non-value that was there before. This was pretty brutal, but should do the job.
  • The new Z-Wave driver's unit info query isn't initializing the id of the timer that it uses to monitor the background querying of the unit info. So, if you never hit Start and just cancel, it tries to destroy the time (since the id has a bogus, non-zero value in it) and gives an error.
  • For the new Z-Wave driver, it's quite difficult to follow the convention that all fields should be updated by the time the driver comes online, because of its async nature. But, at least add some processing at the end of the connect process to give them a reasonable chance to get a value. This also will, in conjunction with the event trigger suppression stuff above, help limit its generation of event triggers on startup of the driver. Initialize the fields to error state so any not yet set will be in error. It will make it takes longer to connect though.
  • It looks like some of the battery powered units don't report battery levels, they expect you to read them during a wakeup. So we need to be able to mark battery CCs on a per-unit basis such that it knows it needs to do this. That's something that's not been dealt with yet. For now the Eco ones we know work this way, so their device info has been updated to reflect this. Other may need to be as well, we'll have to see.


* If you are using the new Z-Wave driver, pause the driver, delete the config file, then upgrade. I had to make some changes that I can't (for a beta) justify making backwards compatible. Sorry about that.

* On the one above that is for getting around an issue in the 1803 version of Windows, the best strategy is to lock out updates (which you can do for up to 35 days) and wait for MS to fix this issue, then update. But, if you already have and are having issues, then it may allow you to get around them.
Dean Roddey
Software Geek Extraordinaire
Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  Official 5.3 Beta Discussion Thread Dean Roddey 639 34,849 Yesterday, 01:46 PM
Last Post: Dean Roddey
  Official 5.2 Beta Discussion Thread Dean Roddey 244 44,240 10-14-2017, 07:57 PM
Last Post: Dean Roddey
  Official 5.2 Beta Release Thread Dean Roddey 13 4,753 10-09-2017, 06:49 PM
Last Post: Dean Roddey
  Official 5.1 Beta Discussion Thread Dean Roddey 453 108,185 05-16-2017, 03:45 PM
Last Post: Dean Roddey
  Official 5.1 Beta Release Thread Dean Roddey 28 11,468 05-12-2017, 05:44 PM
Last Post: Dean Roddey
  Official 5.0 Beta Discussions Dean Roddey 2,019 280,976 11-09-2016, 04:34 PM
Last Post: Dean Roddey
  Official 5.0 Beta Release Thread Dean Roddey 15 9,644 11-01-2016, 10:32 AM
Last Post: Dean Roddey
  Official 4.7 Beta Release Thread Dean Roddey 21 10,133 04-23-2015, 04:20 PM
Last Post: Dean Roddey
  Official 4.7 Beta discussion thread Dean Roddey 295 52,972 04-23-2015, 04:19 PM
Last Post: Dean Roddey
  4.6 Official Beta Discussions Thread Dean Roddey 514 70,093 11-04-2014, 03:57 PM
Last Post: Dean Roddey

Forum Jump:


Users browsing this thread: 1 Guest(s)