Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Official 4.7 Beta Release Thread
#1
This thread is not for discussion, so please don't post here. It is for official 4.7 beta release information.

This thread is intended to provide an always updated indication of the latest available unreleased (beta) version of the product, for those folks who are interested in trying out the latest and greatest or who are desperate for some feature that has been added in preparation for an upcoming release.

A link will be provided to that most recent version, plus a 'confidence factor' from 0 to 100, indicating our belief of its level of readiness for use (which of course is also based on reports from you guys who used the previous one.) And there will be a list of bugs/fixes included since the last official release.

Beta releases will be in the .900 range. So the betas for 4.7 will be in the 4.6.900 range, to distinguish them from formal 4.x.x releases already released or possible 4.6.x follow-up releases before 4.7 is out.

--------------------

NOTE that 4.6 is the last version to support XP/Vista. 4.7, and hence the betas leading up to 4.7 now have Windows 7 (and equivalent server side version) as the minimum supported version. This was announced a year and some months ago, where we said the first version to come out after the beginning of the fourth quarter of 2014 would drop support for XP and Vista. It may continue to work on XP/Vista for a while yet, just by luck, but probably not for too long.

-------------------

NOTE that as of 4.6.915 we have a new self-extracting installer. It's not a Zip file anymore. It's just an executable. Just double click on it to run it. It will first self-extract out the real installer extractor and run that. You can then indicate if you want to extract to a specific directory, or just let it pick a temp directory. Either way it will then extract all of the files and run the CQC installer. The extracted installer image can be reused if you want. Just run the CQCInst.exe program. You don't have to run the self extractor every time you want to run the installer. Though I've not tested it yet, I think that the extracted image should be runnable from a shared directory so that you can extract it once and run it from each client. Give it a try. You'll need to run it as Admin.

-------------------

We now support encrypted connections to the web server, for both HTTP and Websockets. This requires setting up some certificates on the machine where the Web Server lives. Here is the beginnings of a guide for all this stuff:

http://www.charmedquark.com/Web2/Downloa...de_4_6.pdf

-------------------

Latest Version: 4.6.920
Confidence Level: 98
Download Link: http://www.charmedquark.com/Web2/Downloa..._6_920.exe
Dean Roddey
Software Geek Extraordinaire
#2
I just posted 4.6.900. It's essentially 4.6.0 but with the addition of an early cut of the V2 ISY driver for folks to play with if they want. Given that there's hardly any change from 4.6.0, it should be just as stable.

There's still plenty to do to on the ISY driver, but it should be basically working and provide access to lights, relays, motion sensors, and locks (though the latter are non-V2 because they are write only and V2 locks have to be readable.) No scenes, no thermos, and no handling of button presses on keypads yet. I'm just throwing it out there to let folks comment on it and tell me if I'm fundamentally OK or not.

The changes are (most of these are in 4.6.0 as well since most of them were back-ported)
  • The CML URL class isn't over-ridding the FormatTo method, from the base Formattable class, so it cause an exception if that is called on it.

  • The floating point round method, when rounding up, doesn't check the fractional part. It just moves upwards, even if the fractional part is zero.

  • Update the GEM driver to use the Net-48-Time format. This is an easy change since it just requires adjusting some offsets, and it allows some other products that use the Net-48-Time format to simultaneously poll the GEM. Apparently the GEM doesn't support a format per-connection, so if the driver changes it (which it was, to the Net-32 format) it would break those other things.

  • The Z-Wave driver's auto-configuration is incorrectly associating nodes with themselves, instead of with the VRCOP. Doh!

  • The Yale Real Living lock requires that the association and configuration command classes be marked secure, which isn't being done currently, so association and config commands don't work on it.

  • There were some bugs in the InvokeCmd handling of the V2 Z-Wave driver, which was causing some of the association commands not to work.

  • Add a PrintTo command to the CML XML parser that takes an anchor and a text output stream, and formats out the text. This makes it much easier to output XML content for persistence or debugging.

  • Provide an initial cut at a basic V2 ISY driver.
Dean Roddey
Software Geek Extraordinaire
#3
Version 4.6.901 is posted. The primary new thing it introduces is the new 'Event Monitor' system. I'll post something separately about that. It also includes the latest ISY V2 driver stuff, so you don't need any of the driver packs I posted earlier anymore. And some improvements to the new V2 Z-Wave driver.
  • Add scene and button press event triggers to the V2 ISY driver.

  • The Brultech GEM driver was updated to use the Bin-48-Time format. That required adjusting most of the offsets into the data block, to extract the right data. The one for amps didn't get updated correctly. It was fixed right in the 4.6.0 drop but not ported forward to 4.6.900.

  • Add support for persistent connections in our HTTP classes. The ISY driver requires this, and I didn't want to have to hack around it as the original driver was forced to. And this capability will be very useful in some other situations in the future. This required also adding support for the chunked transfer format which is often used in persistent connections. And it required coming up with a new 'data source' class that wraps the source of the data that the HTTP engine consumes. The reason for this is that we have to be able to read chunks of data and can read beyond the end of the current msg. That data has to be kept around and read the next time around, and the data stream class handles that. Similarly for outgoing data it buffers up until told to flush the data out. If you pass a data source to the HTTP client it assumes you want a persistent connection and will just use your provided data source and do an HTTP 1.1 type persistent connection transation. If you don't pass a data source, it will do the usual one shot HTTP 1.0 transaction.

  • Add scene support to the ISY V2 driver and correct the handling of keypads (first slot is a dimmer or switch, other slots are buttons.) Also it's not handling relay field writes, which causes the driver to scram and recycle when one is written to. And similar for relays, where the first is the real relay and the rest we treat as LED status fields, non-V2. They are just read only boolean fields in the form LED_xxxx.

  • The V2 validation stuff doesn't include the scene controller device class, so add that file to the list of class description files shipped.

  • Bump the limit on logic server fields to 92, up from 64.

  • The V2 Aprilaire driver checks for end of stream when reading the config file, to see if its hit the end. But, it could have hit the end while reading the last line (if there is no new line after it.) So it should just check to see if the last read line is empty or not to see if it's hit the end. Otherwise, it can skip the final line.

  • Some more refinements for the V2 Z-Wave driver, mostly related to insuring that dimmers and switches correctly deal with incoming reports in more cases (and therefore send appropriate event triggers.) They weren't correctly being dealt with in the off/on field of dimmers as well.

  • Implement a standard strategy in the V2 Z-Wave driver wrt to validating field writes (and insuring triggers get sent.) If the device sends back a known async report when it changes state via VRCOP msg, then the device info file indicates this and the driver waits for that to validate that the write worked. If not, but the unit is readable, then we read back the value from the unit. If neither of those, then we just have to assume it worked and take the written value as gospel and store it. In all cases we store the returned, queried, or written value to the field before we return, so that we'll see it as a change (if it is one) and send the appropriate trigger.

  • Have the SendWOL action command and CML datagram socket class SendWOL method send the command a few times, with a small pause in between, to help make sure it gets seen. An extra one won't hurt anything, and datagrams aren't guaranteed delivery, so it should help make WOL more reliable. If you are manually sending multiples, you can remove that extra stuff now, since it will likely be redundant.

  • Do a basic initial implementation of 'event monitors' which are sort of halfway between drivers and triggered events. The run in the event server, but they run continuously like a driver and can very efficiently watch numbers of fields for changes and react to them quickly, plus do periodic housekeeping processing. We need an action command to pause/resume them, and the extra stuff in the action editor to select them. We need a new tab in the event server configuration dialog on the Admin Intf side to manage them, and the server side infrastructure to support that management interface and to handle starting/stopping them, loading them on startup, etc...

  • The check in the Interface Engine that disconnects recursive initial templates being loaded into overlays (which will cause a recursive freakout) doesn't take into account that we can now have relative paths, so it won't catch a relative path that expands to a recursive path.
Dean Roddey
Software Geek Extraordinaire
#4
OK, let's try 4.6.902, which included the missing new DLL that 901 didn't have. Sorry about that.
Dean Roddey
Software Geek Extraordinaire
#5
And once again a 4.6.903, which fixes an issue with triggered events getting loaded up. So I think this one is fully happy.
Dean Roddey
Software Geek Extraordinaire
#6
4.6.904 is posted, which is mostly just some more behind the scenes working towards encrypted connections, but I needed to get some other things fixed as well, so I needed to put up another drop.
  • When a web site sends a chunked transfer, it usually doesn't send a content length, because it doesn't know what it's going to be (the reason it's doing a chunked transfer to begin with.) We figure out what the length is by reading in the chunked data. So just force a content length header line in ourself in that case, to make things easier on the clients. Sometimes there is a content length header, but it's been mangled by some intermediate processing that perhaps changed the size, or chunked it after the fact.

  • Add a new method to the CML HTTPClient class, which is a better way of figuring out the encoding of the returned content. You pass the output headers and the raw body content buffer data. It will first look for a content type header line with an explicit encoding, and return that. If not, it will do some other probing to try to figure out what the encoding is. It may not yet find all possibilities, but it's better than the current ParseTextEncoding() that just works on the HTTP content type header line. It is FindTextEncodng(hdrlines,content,contlen,encodingtofill). So you pass the header lines that you got back from the HTTP exchange, the content buffer, and content length, and a string to fill with the encoding. It returns True if it decided on an encoding, else False (in which case the output string is empty.)

  • Take another round of incremental improvements on the HTTP stuff, moving towards support for encrypted connections, as required for the upcoming HTML5 client (and for Websockets support in general.) This isn't stuff visible to users but another important step towards rearranging things in preparation for making that change, so that it won't be such a big undertaking all at once. It's mostly oriented towards allow for encrypted variations of the abstracted data source classes used by the HTTP system to read/write data.

  • The HTTP trigger driver got broken a bit during the recent HTTP related changes, so that was fixed. And, I also realized it could be made to respond a lot faster, so hopefully the break was worth the improvement in response I found while fixing it.
Dean Roddey
Software Geek Extraordinaire
#7
Version 4.6.905 is posted. It has quite a few smallish improvements, but mostly it's to get support for encrypted connections in place for our web server. By default, if you just upgrade, this will not be enabled. It requires putting in place the appropriate certificates and keys, and most folks won't want to bother with that, at least not initially. I'm writing up a guide for what needs to be done and I'll post that either later tonight or tomorrow, probably tomorrow at this point given the time.

This release involved a lot of changes to the HTTP infrastructure, so of course I might have introduced some goobers somehow, though it appears to be solid and HTTP based drivers I've tried are doing fine.
  • The web server needs to set a small linger interval because of the way HTTP works, i.e. the server sends and then closes the socket, so without a little linger time the socket can be shut down before the response is fully sent, and the other side sees it as a lost connection while waiting for the response. Do the same with the HTTP trigger driver

  • Take a whack at adding Z-Wave module support (for dimmers, on/off and motion sensors) to the ISY V2 driver. It's basically a matter of recognizing them, since they use a completely different family of type identifiers. Currently the driver doesn't even make such a distinction, so update it to look for Insteon and Z-Wave families and then for the specific types in those families that we map to CQC device classes.

  • There is an issue in the Z-Wave V2 driver where a dimmer marked as a generic multi-level (i.e. not a light dimmer) will get an empty field name for the on/off field, and that will cause the registration of the fields to fail, so the driver won't come online.

  • Add device info files to the Z-Wave V2 driver for generic write only switches and dimmers. These should work for most non-association reporting switches and dimmer modules. It will mean though that they will not show up as V2 enabled fields because those have to be readable.

  • Bump the report interval for the Aeotec DSB05 multi-sensor up higher. It's eating through batteries relatively quick at the current 4 minute report rate. That means that it'll now take up to 8 minutes after the driver coming on line for it to get the three multi-level sensor values (if you run the auto-config, any existing setup won't be updated automatically.)

  • Take a first whack at adding support for encrypted (TLS 1.0/1.1) connections to our web server. This will require setting up certificates and installing them appropriately, because that's part of how TLS works. So this means you can use https:// type URLs and for websocket connections you can use wss:// connections. Note that the initial HTTP request that runs the javascript that invokes the websocket connection doesn't technically have to be HTTPS, though it appears to need to be for practical purposes in some browsers.

  • Debugging websocks CML handlers in the macro workshop can use either encrypted or unencrypted connections, however to use the encrypted connection you will have to set up a certificate for your internal web server machine, which will be different from the one you'll use for connecting to your system from outside (since certificates are specific to host names.)

  • Update the installer to support a new HTTPS port option for the web server. It will default to the standard 443 upon upgrade, which is what you want unless you have another web server and need to force CQC to an alternative port. If so, you should do a fully custom install and change it. It will default to not enabling HTTPS when upgrading existing systems, since it requires doing the certificate work and most folks won't want to have to do that before they upgrade.

  • Restore the display in the variables driver to show the formatted time stamp when a time field is selected.

  • The new V2 Z-Wave driver's support for thermos was pretty sketchy because of not really having any to test against, so work on that now that there's one available. It's a specific type of thermo, but it will allow me to get all of the code working correctly, such that others can be supported by just getting their device info files right. Add support for the Trane 400BB3NX thermostat.

  • Our attempts to automatically recognize the VRCOP is not working, and it will just as likely pick up the USB stick, so remove it for now, so that the user will have to do it and hopefully get it right.

  • When CQCServer comes up, it should not add paused drivers to the name server. That is where programs get the list of active drivers, and they shouldn't see paused drivers. Only the Admin Interface should see them, so that it can resume them, and it doesn't use the name server to get that info. Live pause/resume was doing the right thing, but upon restart any paused drivers show up as available, when they really aren't and it can cause problems or at least wasted effort.

  • Add category 134 to the support Z-Wave unit types in the V2 ISY driver, scene switches. This was done without any testing, so hopefully it works correctly.
Dean Roddey
Software Geek Extraordinaire
#8
Version 4.6.906 is posted. The primary change in this one is that we now support secure connections on both the client and server side. So the web server can accept https connections, and the HTML client support can access https based resources.

Also there is a new "SMTP Secure" type for e-mail accounts to be able to send e-mail to server that require TLS encryption. This should be typically the 587 port, which is designated for a particular type of connection negotiation that our client support uses. For gmail you will probably have to enable the 'less secure applications' option in the security settings in order to send mail, otherwise it'll get rejected. If you see a 5.7.14 error in the logs with the message being a URL of the 'continueLogin' type, then that apparently is the two phase access, and we can't login to that for sending e-mails.
  • The CQSL repo no longer adjusts the path of internal media files (the music files it rips) to match the path by which the repo is exposed. That used to be done in the process of reading in the .mitem files, which no longer exist (it's all in one big database now.) So, when those files got dropped, that functionality was lost. Add it back, which now just requires a quick scan of the database to update any music paths and writing the database back out, done immediately after a load of the database.

  • Update the ISY driver so that the recent addition of Z-Wave type 134 modules map to dimmers instead of switches.

  • Add a new statistics cache item for open sockets. Unclosed sockets are one of those silent killers that can bring down a system, so being able to diagnose such issues in the field will be very useful.

  • Do a lot more refinement to the recent HTTP changes, all related to upgrading to support pesistent connections and encryption of connections. And do some more refinement of the secure channel support as well, to add client side support to it.

  • Now that we have client side secure channel support, update our SMTP support to support secure (TLS) connections. It requires port 587 style connections (where they start off unencrypted then upgrade to secure if the server supports it.) A new "SMTP Secure" option was added to the CQC e-mail account configuration, to select this secure type connection.

  • Now that we have client side secure channel support, update our client side HTTP support to allow for https: connections. If you do a non-persistent connection, and use an https:// URL, a temporary encrypted connection will be made for you. If you are doing a persistent connection, then you must create a data source to pass in across calls. A new Secure parameter was added to the setup method to indicate secure or not. This is a breaking change but the only thing using this stuff yet is the new ISY driver which was updated.

  • Update the ISY driver to add the new Secure parameter on the data source used to maintain a persistent connection with the ISY for event notification. This was added to allow for secure persistent connections, though it's false in this case since it's not secure.
Dean Roddey
Software Geek Extraordinaire
#9
Version 4.6.907 is posted. The primary change in this one is the arrival of the first actual 'event monitor' implementation, which supports the Thingspeak data logging system. Details below after the change list.
  • The change to the Brultech GEM to support the 48Time format got the offset for the counters wrong.

  • Implement the first real event monitor, which supports logging CQC field data to ThingSpeak. It uses a configuration file that will let you define up to four channels with up to 8 fields each. It will monitor the fields and update any that have changed about once every thirty seconds. This being the first practical one, it drove the addition of more functionality to the event monitor system based on this initial experience.

  • The addition of type 134 Z-Wave units to the ISY V2 driver seems to have not done right, and it was added to the Off/On type instead of Dimmers.

  • Implement a new System::HTTPGet command. It takes a URL and a number of seconds to wait. It also takes an optional output variable which will return any text if the GET returns a text format. If the command fails, the output variable will instead contain a failure reason. If you leave the output variable blank it will not return any text. The URL must be valid and fully qualified (i.e. starts with http:// or https://). If there's any possibly ambiguity because of special characters, they must be escaped or the URL parse will fail.


The ThingSpeak event monitor setup is:

Name: Some name you want to give the event monitor
Macro: MEng.System.EvMons.ThingSpeak.EvMonImpl
Params: Just one for now, which is the name of the config file to load, for example ChannelCfg or MyCfgFile or whatever.

The config file tells the event monitor what channels you want to post to and what fields are to be posted for each channel. Here is a sample one:

Code:
Info=
    Version=1
    Lat=35
    Long=-80
EndInfo

Channel=CQC Testing, B8HO68A02MXKDAIG
    ADIO.AIO#In_1
    ADIO.AIO#In_2
    ADIO.AIO#In_3
    ADIO.AIO#In_4
    ADIO.AIO#In_5
    ADIO.AIO#In_6
    ADIO.AIO#In_7
    ADIO.AIO#In_8
EndChannel

You can have up to four channels, and each channel can have up to 8 fields. The first line of each channel provdes a name for logging purposes slash human consumption, and then the write key for that channel (which the driver needs in order to post the data.) Each line within the channel block must be one field in the standard moniker.field format.

The first block indicate the config file format version, currently 1, and the lat/long of the info being logged. Remember west and south are negative numbers! I guess I could make it smarter and, if not provided, it will just use your CQC system coordinates or something, but I'd have to make that data available to the event monitors.

The file must be [cqc]\CQCData\MacroFileRoot\EvMons\ThingSpeak\xxx.Cfg, where xxx is the file name you provided in the event monitor parameter setup mentioned above.

Every thirty seconds, any channel which has had at least one field change since the last post will do a post of the changed data. It only posts the changed fields, so it's pretty efficient.

Give your thanks to Mike Potts, who bankrolled this effort.
Dean Roddey
Software Geek Extraordinaire
#10
Version 4.6.908 is posted. It's basically just smallish fixes and updates and improvements. A number of goobers in the CQSL repo were fixed.

I moved up to Visual C++ 2013 for this release. I think I got all of the library support stuff right. If not, then most likely the installer will die when you try to run it. It may have worked for me because of the libraries getting installed when I installed the new VC++. Let me know if that happens, and I'll re-package it with another library I think I didn't need, but I may have been too aggressive in my pruning.

  • Implement the formal session termination stuff for the secure channel support. It hasn't been done yet since it's not absolutely necessary, but we want to be polite.

  • Have the installer validate the certificate info string provided. For now it would require duplicating the parsing code down in the secure channel facility. Break it out to a separate helper method instead so that it can be used from multiple places.

  • A stupid search and replace error occurred in the auto-gen configuration stuff, causing the 'add a thermo' dialog box to reference a non-existent and cause an exception. This prevents you from adding any new thermos.

  • Add some more verbose mode logging to the WMP-based metadata retrieval stuff, so that we can diagnose better what is happening when metadata is not correctly retrieved.

  • When the client applications were moved over to use their own local configuration repository files in the ProgramData area, the CQSL repo manager wasn't updated, so it's still trying to use the configuration server, which will not be present in a client only configuration. So update it to do the right thing. It was opening the file, but not using it.

  • Update the ISY V2 driver to be able to use the Notes field of the node configuration in the ISY, to allow the user to provide some extra configuration beyond what the ISY provides. For now, it the only one is to indicate that a relay should be treated as a light switch, since it's really running a light.

  • The CQSL Repo driver got a breakage a bit back during all of the changes related to how media is detal with. When it's accepting media files, the initial packet for each file indicates the media type. It calls a method to get that initial packet and extract the data out and return it. But the output parameter that indicates the incoming media type was not getting set. Hard to imagine how it even ever worked. The worst case would be that it's valid, but the wrong media type, which I think could cause a system exception in some cases.

  • Upon moving up to Visual C++ 2013, errors about alignment started showing up, basically not gonig away unless every class that used or included another class that used, a cache alighment pragma in the header to be allocated via a class specific new/delete that used aligned allocations. This obviously wasn't remotely practical, so readdress the issue and go back through the docs to validate that we can get rid of those pragmas and do so.

  • In the CQSL repo, when new ripped files are uploaded, they are first put into a temp directory and then moved to their final location when all the data has been validated. If the target directory doesn't exist, the move will fail. This mostly affects folks starting a new repo, but might also if you get enough rips to make it create a new ItDat\xxxx directory, if the repo doesn't create that one. So just check the path and make sure it exists before doing the copy and create it if not.

  • Artist names that have an ampersand in them tend not to find any cover art in the CQSL repo manager, whereas changing them to the word 'and' instead does. So just go ahead and replace any amps with 'and' in the artist name before we search.

  • Sometimes the WMP metadata service doesn't return track titles. We end up with track items in the list, but with no names. So it looks like the track list is empty. If this happens, force in default names (Track 1, Track 2, etc...) so that the user knows that they are there, but the names were just not provided.

  • If we get an album artist metadata value (which isn't empty), take it instead of the regular artist name, to help with scenarios where there may be slightly different artist names per track but an overall album artist has been provided. That will avoid it becoming a 'various artists' collection.
Dean Roddey
Software Geek Extraordinaire


Possibly Related Threads...
Thread Author Replies Views Last Post
  Official 5.3 Beta Discussion Thread Dean Roddey 101 5,359 5 hours ago
Last Post: NightLight
  Official 5.3 Release Thread Dean Roddey 0 382 10-17-2017, 07:13 PM
Last Post: Dean Roddey
  Official 5.2 Beta Discussion Thread Dean Roddey 244 20,418 10-14-2017, 07:57 PM
Last Post: Dean Roddey
  Official 5.2 Beta Release Thread Dean Roddey 13 2,697 10-09-2017, 06:49 PM
Last Post: Dean Roddey
  Official 5.1 Beta Discussion Thread Dean Roddey 453 57,329 05-16-2017, 03:45 PM
Last Post: Dean Roddey
  Official 5.1 Beta Release Thread Dean Roddey 28 6,686 05-12-2017, 05:44 PM
Last Post: Dean Roddey
  Official 5.0 Beta Discussions Dean Roddey 2,019 155,384 11-09-2016, 04:34 PM
Last Post: Dean Roddey
  Official 5.0 Beta Release Thread Dean Roddey 15 7,517 11-01-2016, 10:32 AM
Last Post: Dean Roddey
  How to obtain Beta versions? willsauter 3 1,569 07-15-2016, 04:57 PM
Last Post: willsauter
  Official 4.7 Beta discussion thread Dean Roddey 295 35,594 04-23-2015, 04:19 PM
Last Post: Dean Roddey

Forum Jump:


Users browsing this thread: 1 Guest(s)