Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
5.1.0 followup releases
As is almost always the case we'll end up doing a small number of non-beta followup release (5.1.1, 5.1,2, etc...) to take care of any small issues that come up and add some smaller features that we can safely get into place. This thread is for discussion of those. I'll reserve a few responses after this for the official release posts, and the rest can be discussion.

Once we've accumulated a reasonable set of fixes, and folks have blessed in real world use, I'll do official versions to post.

Latest version: 5.1.4
Dean Roddey
Software Geek Extraordinaire
  • Except in a clean install, the 'install mode' panel is the first one seen, and you shouldn't be able to go back from there.
  • In the transition to 5.x, I tossed the 'start time' stuff from the 'every X minutes/hours/days' type scheduled events, because it just confused people. However, some folks were using that to make them happen at specific minutes within the hour or specific hours within the day. So, put this back, but in a more understandable way. Now, the every x hours one has an 'on minute' option, and the every X days one has an 'on hour' option. And store that info in a better way than before so that this start time can't 'creep' forward.
  • Add an 'initial mute' attribute to the web cam widget, to set the initial audio mute state when it comes up. And add a new SetMute command to change the mute state dynamically after it's created.
  • For practical purposes, do the same as above but for volume in this case. It'll be desirable to be able to control the volume dynamically in many cases.
  • The new web cam widget confused things a bit wrt to full screen/kiosk mode. It would steal activation and focus. So the pointer might not hide correctly, and the IV window itself may not have focus after loading a template that includes web cam windows and going straight to full screen/kiosk mode. The latter would mean that hitting Ctrl-Shift-F1 to get out of FS mode wouldn't work until you clicked on the IV window itself to get the focus back there.
  • The packaging dialog doesn't protect itself from a template that references images that don't exist. Instead of just skipping that image, it gets an error and doesn't create the package.
  • When we load a driver (server or client side) we have to update the current driver config with the latest driver manifest info, in case anything has been changed, which it will often be even if the manifest itself hasn't changed. The versions for share libraries changes with ever major and minor CQC version, and those need to get updated from the manifest info or such shared libraries will fail to load (since they'll reference a previous CQC version's versions of those things.) The new Admin Intf wasn't doing this because it used to get that info from the running driver, which had already done this. Now it gets it from the driver config data stored on the MS, sot it needs to do this updating itself.

  • The data type selection for static widgets should support the drop down menu in the attribute editor, instead of making you type them. Also the 'use range' attribute isn't providing the drop down either.
  • The static slider is incorrectly redrawing if you set its value in OnPreload. It should just store the value for later use since if it redraws then it will not have been moved to its final position and will redraw in the wrong place. And the same for static volume knobs, checkboxes, and progress bars it turns out.
  • The static progress bar was incorrectly suppressing the set value command in OnPreload, when it's fine to do that. It just saves the value for later use. However, the reason it probably didn't allow it was to make sure the fill bar bitmap masks get created correctly, so we have to make sure that happens as it should whether or not any initial value is set before it first draws.
  • Make some more tweaks to the IV's startup to try to find the balance between getting fullscreen/kiosk mode on startup to work, and preventing things like web cam helpers being in the initially loaded template from causing issues.
  • If the loading of the GC-100 port config by CQCServer fails on startup, which isn't likely but could happen in some unusual circumstance, CQCServer doesn't continue to try to load it, which would leave any GC port based drivers unable to open their serial ports. So periodically check to see if we've not ever loaded any config and retry it. All CQCServers are notified when changes are made to the GC-100 port config, so they always see those (if they are currently running.)
  • Move the Z-Wave Leviton driver over to the new Z-Wave Plus C++ language headers, so that we can access the newest stuff. It's sort of tricky and a pain because things have been renamed and obsoleted a lot and we have to be sure we are using the same stuff in the new headers.
  • Because of the fact that driver configuration was moved to the MS, when you edit field triggers (in the driver monitor tab) if there were old triggers defined, for fields that no longer exist, that would cause the attempt to save changes to triggers on that driver to fail, because it would complain about fields that no longer exist. The AI now removes all invalidated triggers when you edit, so that this won't happen. And, to be even safer, CQCServer will ignore non-existent fields in any uploaded trigger changes.
  • Rework the Web Server's (server side) Websocket engine. We are going to be moving the RIVA server functionality to the web server, and the way it currently works isn't remotely up to that level of throughput. So rework it to work like the RIVA server does currently, along with the really nice improvements made just a bit back, that allow it to be more tolerant and more smoothly deal with simultaneous input and output traffic. This also will push more low level details of message handling down into the Websocket engine, whereas in the current RIVA system it's much more exposed because the RIVA server shares a lot of that implementation with the C++ RIVA client.
  • Validate the the above changes still work for a regular CML web socket handler before we move forward with the new RIVA stuff based on it. That will insure that it's a basically sane foundation on which to start to build, and it means we can get back to doing bug fix drops again while we continue to do the RIVA migration, since the existing functionality is back happy again.
  • The msgs logged by the event server when you mark a scheduled or triggered event as 'log always' were not consistently putting the replacement token for the event name into the msg, so the event name wasn't always logged.
Dean Roddey
Software Geek Extraordinaire
  • Add a fixed prompt to the RA2 driver manifest, indicating the 'system type' is RA2. Create a new V2 manfiest for the same driver that covers Caseta and sets that prompt to indicate it is a Caseta. The Caseta has a much more restricted feature set, so we need to know which type of system we are talking to. We could just create a separate driver, but it would involve a lot of redundancy.
  • And update the RA2 driver to support the Caseta, which has a number of quirks and limitations.
  • The Admin Interface's main frame window is not resetting itself as the target for hot keys when it is activated. So, if you bring up a secondary frame, like the action trace, then go back to the AI, it loses the ability to process hot keys, so things like Ctrl-S don't work anymore.
  • An error in CQCServer's handling of accepting newly editing triggers was causing only the last trigger edited to be really stored in the live trigger list. Since we now read back the live stuff when editing, to get rid of any out of date triggers, that was also causing issues when editing making previously set triggers appear not to be set.
  • Replace the room config client component in the licensing info with the new Web RIVA component, in preparation for the upcoming new stuff. And remove the old room config stuff from the installer image, which will be replaced with the new stuff when it's ready for a first view.
  • On the license info tab, change the 'Register' button to say 'Load License', since that's more obvious what it does.

  • The SetViewBorderClr() command, which sets the background area around the template itself to a specific color, doesn't force a redraw so the new color only shows up if the window is resized or has to be redrawn.
  • In the attribute editor during the original creation of it, in the list of types that by default support in-place editing, I left out floating point. So you can't edit a floating point number in attribute editor unless it's some special case one that the containing code overrides and handles itself.
  • Though we did a lot of work to let variables handle mixed numeric types in action math operations (add, sub, mul, div) the action editor itself will reject anything except a signed value because the parameter info for those commands indicates it must be a signed value. That made it impossible to pass in floating point values. So add a 'Number' parameter type that will accept any type of numerical value for those parameters. They can use the CML style suffixes to force numbers to be a specific type where needed.
  • The CML engine and the action engine use a 'numeric constant probe' method provided by the CML engine, to check strings to see if they represent a valid number to be parsed. In the testing of the above Number parameter type, a number of shortcomings were found in it, so it was improved and simplified. This could have caused the action editor not to catch bad numeric values when you save the action, which would then later fail when it ran and the text was actually converted. Add a bunch of unit tests for this method to make sure it is happy and stays that way.
    You could in theory have had bad constant values in CML code that slipped through and now will cause an error, but eventually those would actually get converted to numbers and would have failed there, so it's pretty unlikely this will break any CML code that wasn't already broken, unless that code never actually got run. All of the CML tests and shipped drivers are compiling without any issues. If it should happen, the fixes will be trivial.
  • Update the file selection dialog (the one that lets you select back-end resources via the single data type version of the browser tree) so that it allows for relative paths (where that is supported, currently just templates.) It can now provide an option for the user to return the path either full or relative, and it can take an incoming relative path and expand it out to get the previously value selected as the default, so that it's much easier to use relative paths now.
  • Update the nest driver to support the new thermostat Eco mode, which previously would have shown up as 'Unknown' because the driver didn't understand it. It also now shows the Eco mode set points when in Eco mode, and the normal set points otherwise. You will need to re-do your permissions for the CQC driver since the permissions it requests now include the Eco info. See the Nest driver page to remind yourself of how that is done. Once you have generated the new token, do a reconfigure on the driver and provide it with the new token.
    Previously this driver would attempt to fake the missing set points (the Nest doesn't accept a high set point when in heat mode or a low when in cool mode) so it would just save field writes until the mode changed back to heat-cool. But now there are Eco mode set points that cannot be written to at all. So now the driver will just reject an attempt to set a set point that is not currently available. So you may want to have an event on such screens that will enable/disable set point changing widgets based on the current mode. Ultimately you can only set the normal mode set points (i.e. when not in Eco mode.) And you can't set the cool set point when in heat mode, or the heat set point when in cool mode. Since most folks are usually in Eco or heat-cool mode, that latter probably isn't much of a concern. Sort of sucks but they just don't want to play like a normal thermostat.
  • Add the defined Nest 'structures' to the Nest driver, just a single field currently that shows the away/home status for that structure. This will allow you to trigger things on a change in the home/away state.
  • The IV should react to screen resolution changes when in full screen mode and keep itself full screen. Since we can't do full screen by just setting our main window to maximized state anymore, it won't automatically stay full screen, we have to resize ourself.
  • The installer didn't originally delete all of the scheduled/triggered events out of the config repo when they were moved out to separate files for 5.x. They were left as a backup. Later code was added to remove them, but that was within the code that was checking for a pre-5.x to 5.x upgrade, and of course by then that upgrade had already occurred, so the code never got run for folks who were already on 5.x. So make sure those are gotten rid of, since they can take up a good bit of space.
  • Add the 'next run time' display for sunrise/sunset scheduled events
Dean Roddey
Software Geek Extraordinaire
(reserved 3)
Dean Roddey
Software Geek Extraordinaire
(reserved 4)
Dean Roddey
Software Geek Extraordinaire
So, Bryan pointed out that cameras generally have microphones, and that if the web cam widget allowed that audio to be played, that it could also serve in functions such as baby monitors and things like that.

If the guy has a mic, and it's enabled on the camera, it does send the audio. In the 5.1.0 release, I'm actually must juting it immediately upon starting playback, since obviously for many purposes you wouldn't want the audio playing out of your viewer client, and I just assumed that would always be the case. But clearly there are applications for the audio as well.

So, I've added a new 'Initial Mute' attribute to set an initial mute, defaults to True to mute it, but you can change that to control the initial mute state in force when the camera widget starts up. And there's a new SetMute command to change the mute state dynamically (using a button probably in must cases.) You'd have to use separate mute/unmute buttons since there's no current mute state available in a way that would be able to drive a check box type widget's state.

Of course at some point later, if there's also a speaker available and the camera device handles in incoming media stream that it sends to the speaker, we could allow you to send to the camera as well, allowing for things like front door intercom type scenarios. I already have a basically working RTP library that I've tested sending audio to VLC player. This was something I was working on like a year ago or more but abandoned it to work on other things. So it probably wouldn't be a lot of work to get to that point. I'm not sure what the differences are though between RTP and RTSP.
Dean Roddey
Software Geek Extraordinaire
Well, you could use a static check box. Just make sure it's initially set to the same state as the initial mute state of the web cam widget. Then just set the web came mute to match the state of the static check box as you toggle it.

Crazily, I must made all those changes, which were pretty substantial, and it all worked perfectly the first time. That's suspicious.
Dean Roddey
Software Geek Extraordinaire
I added a volume attribute/command for the camera widget as well. Again, it's not a field or variable value, but you can just create a static slider. You know what the initial volume is going to be, since you set it as an attribute. So just, OnLoad, set the static slider to that. Then just update the camera widget's volume when the slider moves.

Because you are controlling a software player there on the same computer, not the volume of the actual camera, you can just put a SetVolume command in the OnDrag of the slider, and get basically real time volume control as you drag it, which is nice.

If the player isn't current running, due to the stream not being available, the helper program will just store the last set mute and volume values and apply those when it is able to get the player engine running, or any time it has to restart it. The widget also does the same, so if it restarts the helper program, which it does every couple hours just to insure that weirdness doesn't accumulate, then it will re-apply the last set values to the new helper instance.
Dean Roddey
Software Geek Extraordinaire
5.1.1 is posted, link in the first post. I put it in the beta area. It's not really a beta per se, but it probably won't be an actual released version either, so I don't want to pollute the main installer area. I'll likely accumulate more fixes before doing an official release.

This one should address the stuff that has come up since the 5.1.0 drop, and some small improvements as well. No need to get it unless you are experiencing one of the issues fixed or want to try the new bits.

Web Cam Widget

The new bits are mute and volume control for the new web cam widget. You can't get those values from the widget, but you can set them, and you can configure the initial values on the widget at design time. So, you know what the initial values are going to be. Therefore the strategy is:

1. Create a static check box for mute, and a static slider for volume. For the slider set the type to Card and the range to 0 to 100.
2. In OnLoad, set the check box and slider to match what you know are the initially set values you configured
3. Then just update the widget's mute/volume to match changes made by the user via the button and slider.

Because the volume being controlled is the volume of the media engine, not of the camera, you can actually put a SetVolume command in the OnDrag and it will keep up. So you can get 'real time' volume control as you move the slider.

There were also some issues with Kiosk mode and pointer hiding that were caused by the new web cam helper, which should be taken care of of now. It wouldn't always hide the pointer when going straight to full screen kiosk mode (using the command line options.) And the IV window would not end up with the input focus, so it wouldn't see Ctrl-Shift-F1 requests to exit full screen mode until you clicked on the IV window to get it the focus.

Scheduled Events Improvement

The other new thing is that for 'every x hours/days' type scheduled events, you can control what minute within the hour and what hour within the day that it runs.

Client Side Driver Fix

When a driver is loaded, client or server side, the current configuration is supposed to be updated with the contents of the latest manifest file for that driver. This picks up newly added prompts and things like that. It also updates the versions for C++ driver DLLs. On the Admin Intf side, that got lost because it used to get the driver config from the actual running driver, which already had those updates. Now it gets it from the MS, which doesn't, and it wasn't doing the update. So any C++ driver that had a client side driver and any shared DLLs (between the server and client) would fail to load the client side driver tab because it was trying to load the wrong version of that shared DLL.
Dean Roddey
Software Geek Extraordinaire
5.1.1 introduced an oddity -- My main instance of the interface viewer is running via RDP on a 1920x1200 resolution screen. After upgrading on IV start the IV appears to flash full screen and then clips to something like 1200x600. I am running fullscreen and kiosk mode as this is a touch client. I don't have another screen that is that high a resolution so I can't tell if the interface definition is damaged or if it is something else.

I reverted to 5.1.0 by copying the backed up directories and without reboots or anything the whole template draws successfully.

I saved the 5.1.1 system so if a file is needed I have them all.
Mark Stega

Possibly Related Threads...
Thread Author Replies Views Last Post
  A 4.3 followup release candidate Dean Roddey 11 1,362 06-02-2013, 07:24 PM
Last Post: Dean Roddey
  4.2 Followup Releases Info Dean Roddey 131 6,302 11-28-2012, 08:36 PM
Last Post: Dean Roddey

Forum Jump:

Users browsing this thread: 1 Guest(s)