Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Official 5.4 Beta Release Thread
  • The Sonos ZonePlayer docs have the wrong info for the backdoor command to query the favorites list, and it should have an example as well to make things easier.
  • The Sonos Zone Player lost grouping ability when the Device Properties service stopped working, because we can't get the device id anymore. However, AFAIK, I think it's the same id that's given to the driver by the user during init (to find that particualr unit.) If so, then we can set the DevId field from that, so let's try it.
  • Implement support for being notified upon any change to the files or sub-dirs of a directory. This will be required for some future functionality. Still need to test it out.
Dean Roddey
Explorans limites defectum
  • My first attempt at implementing directory change monitoring was very wrong, because I didn't realize that the call is blocking, i.e. doesn't return until something shows up. That requires a very different approach with an internal thread that is always blocked waiting for changes, and I/O cancellation to stop it for shutdown. So I created a simple mixin that does the internal processing and calls some virtuals to report changes and problems.
  • Re-implement the original queue-for-later and publish vis pub/sub directory change monitoring classes in terms of the new mixing. But the mixin scheme means other things can directly process such changes without an intermediary if they want to and it makes things easier.
  • Add support to the new Z-Wave driver for th Aeotec Nano-Dimmer (ZW111-A.)
  • Add support to the new Z-Wave driver for the Aeotec Wall Mote Quad (ZW130). Very much done by eye, so could be wrong, we need to see how it goes. It will send out user action triggers on button events.
  • There is a slight bug in the AAC metadata tag extraction code, which would make it always miss the first tag under the ilst main metadata parent tag.
  • We need to add support in the code that gathers device info dumps in the new Z-Wave driver so that it will gather multi-channel end point info for multi-channel devices. There isn't any now since (despite MC being the correct way to handle multi-sensor type things) hardly anything actually used it. Since many manufacturers don't bother to even document the end points we need to figure that out for ourselves.
Dean Roddey
Explorans limites defectum
  • The Aoetec Nano Dimmer just added isn't exposing V2 fields, because I copied its device info file from another one and forgot to remove some stuff. Anyone who had already has any of these recognized should use the unit drop down menu to force them to re-scan and pick up these changes.
  • Take a whack at adding support to the new Z-Wave driver for the Fibary FGMS-001 multi-sensor. It appears to use the same (bad) scheme as the Aeotec ones, so let's try to use the same handler and see if it works.
  • We did a rough by eye implementation of Z-Wave thermostat support, but never actually got to test it out. So got a GoControl (really Linear) GC-TBZ48 thermostat and worked out the issues, and it seems to be working, so that one is supported and we should be able to add other standard thermostats fairly easily moving forward now.
  • Add some thermo specific info to the device info dump files. We need to get the supported modes and fan modes since those things are never usually documented.
  • One of the standard utility dialog boxes that shows a list of values doesn't have the appropriate resizing anchors on the controls. So you can resize the dialog but the contents doesn't adjust. It was noticed on the V2 driver validation results dialog, but would affect anything that uses that helper dialog.
  • Implement bi-directional latching field change triggers, i.e. trigger if the expression goes from true to false or from false to true. So now we have unlatched, unidirectional, and bidirectional latching options.
Dean Roddey
Explorans limites defectum
  • The device info for the new Fibaro multi-sensor added in the last drop isn't quite right. I thought we were configuring it for basic reports for motion, but that's for association group 2. For group 1 it sends notification CC msgs, so update to watch for those.
  • When a unit gets to NoAutoMatch, too much info gets reset, including the supporting CCs that we got during the initial scan of the Z-Stick. The same can happen on a forced rescan request. That causes config/association options to be disabled in the client interface in the per-unit drop down menu because it thinks the unit doesn't support those CCs. It won't necessarily fix units that are already thusly whacked, it may take a replication to do that.
  • I guess the Fibaro FGMS-001 doesn't ever send battery notifications, so I've changed the battery CC to be 'read only wakeup' so that it'll try to read the value when it gets wakeups from the device. Let's see if that works. If you already have one set up you'll need to force a reconfig to pick up this new configuration info.
  • We had a 'stop' command in the connection code of the UPnP media renderer driver (of which Sonos is one instance of that) just as a safety measure to get the devices into a known state. But that causes any playing content to stop if the driver or CQC is cycled, so remove it and see if that's still going to work out ok without being so annoying.
  • There are various issues in the auto-gen if you don't have any weather configured.
  • And the recent change to have variable numbers of weather forecast days, driven by the number reported by the driver itself, caused us to access weather info even if it wasn't configured for a given room.
  • Clicking the X on the IV's action trace will shut down the program since it is a top level window and is not preventing the default action. It should just destroy itself.
Dean Roddey
Explorans limites defectum
  • The secure channel facility is one of those things that we don't push down into the virtual kernel, but it does have some OS specific code. To support long term goals, split that guy in the standard way into platform independent and specific parts, so as to support future portability.
  • Create a new general purpose handler for multi-channel devices that should be able to handle a fairly broad swath of such things, which can be in theory almost any combination of bits thrown together into a single module. Mostly it'll be sensors and such, but we need to make it as flexible as is reasonable, to avoid having to create lots of ad hoc handlers for such things. Not tested as of yet, need to get such a module.
  • Similar to above, create a new handler for non-multi-channel multi-sensor type devices. We created one initial for the Aeon multi-sensors, since those were the first ones of that type we ran into. And we used it for some other devices that worked the same way. But it's not flexible enough and we can't change it now without breaking things. So leave it for now to the few things that use it and create a new, much better one. Later we can convert those and get rid of the old Aeon specific one.
  • By adding a 'desired temp scale' member to the multi-level sensor CC impl, we can get rid of some redundant code that handles converting from whatever scale we get from the module to the one configured by the user. Update the thermostat unit handler to this new scheme, and do the new random multi-sensor handler this way.
  • When we get new config changes from the server side Z-Wave driver, we weave those changes into our current config we are displaying. However, we are updating the display from the incoming data, not the data we store. So, if something happens that changes the data we store relative to what we got, we can display the wrong unit state. This was specifically happening with units coming in WaitApprove status, but due to some error we put the unit into failed state, but we still display WaitApprove (but the approve units option is disabled since not units are actually in wait approve state.)
  • Add support to the new Z-Wave driver for the Fibaro FGDW-002 door/window plus temp sensor. This is the non-multi-channel version that came out later and is non-multi-channel so it uses the above new non-MC sensor handler.
  • The battery CC has an ad hoc 'read access' scheme (it's not readable so notification only, it can only be read during wakeup plus possibly notifications, or it can be read any time.) Looking into formalizing this across CC impls lead to a realization that unit access control was not as well centralized as it could be, and so a reworking was done to do that. Painful at this point, but allows the unit handlers to take another step towards 'set and forget' on the CC impls it creates. It lets all of the 'read on wakeup' move down into the base CC class as well.
  • The Z-Wave driver was incorrectly setting the low temp attribute to the low end of the range, not the configured value, so it would always revert to that low end value for display/editing, even though it was stored correctly.
  • The IDL generator was generating reversed values for the 'non-contiguous' flag of generated enumerations, which would make mappings from bitmapped enums to text come out with the wrong value, and causing some operations on contiguous enums to do a lookup instead of a direct index operation.
  • Set a short timeout on the ORB command that the IV uses to talk to its helper instances. If things are going well, that should never be an issue since they are local to teh same machine. If things are going badly, and the web cam or web browser instance being managed gets itself twisted up in some way, that will prevent the IV from locking up when it tries to talk to the guy.
  • Add a new report to the Z-Wave driver. Unlike the unit info report, which gets info from the actual module, this one looks at what internal stuff got set up for the units and the CCs they create and so forth. This will allow us to catch various types of errors in the field that would otherwise be very difficult to catch.
  • Add support for the Fibaro FGK-10x door/window plus temp sensor. I bought it thinking it was a multi-channel sensor device finally, but again there was an old one that was and new ones that are not.
  • The Sonos ZP driver is not handling writes to the crossfade field, so you can't enable/disable crossfade.
  • The AAC/M4A metadata extraction code has a wee bug in that, if the MOOV atom isn't the first thing after the FTYP, it will fail, because it's not skipping forward past the atom it's checking before checking the next one. In almost all cases it appears to be, at least for music, but we can't assume that.
  • The code in the Z-Wave driver that parses dev info files wasn't resetting the CC impl class on each pass, so that stuff could accumulate if it was the adding to type, such as extra info values. This was mostly benign, but if more than one CC impl used the same key, the latter one would see the first added value from the previous CC.
  • Some of the unit handlers were doing a check to make sure that a report CC impl value change was for an impl they expect, but they weren't accounting for common impls added at the base unit level, such as battery. That could cause them to throw an error if they got a value change from such a CC impl.
  • Add a bunch more safety stuff to the tray monitor's app control stuff, to try to prevent errors when remotely invoking programs, also found a couple small goobers one of which may have been the culprit.
Dean Roddey
Explorans limites defectum
  • The changes made in the last drop to the Z-Wave driver, to rework unit access, failed to get the RGB controller CCs set correctly so you couldn't write to them.
  • The AAC metadata extraction wasn't dealing correctly with the track number atom. It is binary, and can either be one or two ints, with the first one being the track number.
  • In our 5.x UI framework, each window can create up to 8 timers. But, the modal loop creates a timer for itself while it's in the loop to insure it's always getting msgs, which otherwise it might not and get stuck. In the IV, each popup layer is in a modal loop when it's running within the window based version of the IV (not the server based version that is behind the WebRIVA client.) The popups are not separate windows, so each of those comes out of the IV's output window's allotment. It already has created four to do various periodic update operations, so four layers of modals is enough to max it out and you can get a timer creation error. This has been bumped to 32 per window, which should be way more than enough for any reasonable scheme.
  • While we are at it, bump up the maximum number of popups we will allow by a bit up to 8 (base plus 7.) That should be way more than enough for any reasonable interface plus some spare.
  • Provide a ShuffleMode field in the Sonos ZP player. It's a boolean, true enables, and false goes back to normal mode.
  • The issue that we have now with the UPnP device properties service is causing an issue in the driver install wizard which asks for the services that the device provides, but with the issue we have it reports device props but we can't actually get the info so it throws an exception. We need to handle that and not have the rest of the process fail.
Dean Roddey
Explorans limites defectum
  • CQC expressions didn't really get a good treatment in the new HTML docs. Add a page for those to the /Reference/CommonUI section, and add links to that anywhere that they are referred to.
  • The CML FileSystem class didn't get its docs converted over when we made the move to the new 5.x HTML docs.
  • I never implemented the field write handling for the ZWave setpoint CC, so you can't set set points. And there was an issue recognizing the correct incoming set point reports.
  • Get generic support for a basic thermostat with set point(s), so not a formal Z-Wave thermostat by just one that implements MLSensor for current temp, and one or both set points. This is a not uncommon thing.
  • Use the above to add support for the Popp thermostatic valve module.
  • A bunch more conversions of enums to the new compile time safe form.
  • Have the IV's web camera helper process cycle the VLC instance every hour of continuous playback. Otherwise, probably due to the usual flakiness of media codecs, it can get itself into a bind and lock up. Hopefully this will prevent it from doing so by allowing for periodic release of resources.
Dean Roddey
Explorans limites defectum
  • During my recent enumeration exploits I somehow switched the text and name values that the device drivers use to create the standard $whatever fields. Mostly they are the same, but one is TimeOuts vs Timeouts (case of the O is different.) That is breaking some code that looks at that field. Probably best to just change that one to be the same in both cases, then I can get rid of the separate text value always use the name part.
  • Add a wakeup interval to the Popp Thermionic Valve to see if that gets around it not supporting associations. That at least lets us set who to report wakeups to, in theory. And remove associations from its list since it clearly doesn't support it. Force a rescan of these after this release to pick up these changes. Force a wakeup of the device after that, to let queued configuration msgs be sent.
  • Update the IDL compiler to allow for selectively marking enums to be generated in the new, type safe way. So far only the non-IDL generated ones have been available for updating. This also requires updating the IDL code generation to handle generating output for both the old and new schemes, until such time as the conversion over to safe scheme is complete, which will be a fair while. This allows us to do it down to a per-enum basis for safe, incremental progress.
  • If the Z-Wave driver's output queue gets filled, and remains so for 16 msgs straight, then flush it so that we can recover, even though it means loss of out going msgs. Log something to both the logs and the trace file if this happens.
Dean Roddey
Explorans limites defectum
  • There was a bug in the Admin Intf's code for pasting in files. It might have gotten a bad id into the file's cache item. The new safe enum stuff caught this.
  • Have the installer not fail if it can't convert an image or template or such. Collect those errors and display them at the end, with an option to save to a file that will act as a post upgrade check list. Otherwise, a failed conversion of an image can stop the installation, and you do it again and then the next bad images stops it, and so on. It would be best to catch them before we even upgrade but that would be too much, so we catch them during the upgrade process. They will be shown in the final installation status panel.
  • Add a query for supported thermo set points in the unit info dump if we see that the thermo SP CC is supported, so that we can see what set points a unit supports.
  • Another error found by the safe enums. The base driver class checks to see if a field has the required (read or write) access. When a write is done fron the driver itself, it can always write to the field. But this was being incorrectly done before in a way that just happened to work. When changed for the new scheme it started rejected writes to fields even if it clearly writeable.
  • The UPnP A/V Transport service was looking for the wrong value name for the cross fade, so it would never get the value stored.
  • I realized I wasn't being nearly as efficient as I could be with UPnP services. If they are 'evented' then they will send notifications of changes. These are stored in 'state variables' and read from there after that. Any new changes will be reported async and stored again. But, they never send anything unless something changes. So I was continually polling until something changed. Instead, if evented, I can force the values of the first read into the state variables, and not have to poll again since any actual change will get reported async. I updated the A/V Transport and Render Control services to do this, since they are the ones banged on by the Sonos and other UPnP media renderer drivers. If you have a number of them this could significantly reduce network activity.
  • Update the Sonos ZP driver to correctly expose all play mode states, and while in there have it expose the transport state as well in a new field.
  • Try once again to enable SSE2 CPU options, to get more performance (in some cases where the compiler can automatically recognize stuff it can do via SIMD instructions, latter maybe explicitly using some ourself.) There shouldn't be anything out there that CQC is running on these days that would not support them, and it's even the default in Visual C++ for a long time and I was suppressing them because of some really crusty old clients. But that was before the move to Win7 as the baseline.
Dean Roddey
Explorans limites defectum
  • There are various places in CQC where we use an enum to index a bitset object. Now that we have the ability to create safe enums, we can make those safe. But then we need to have safe means to use them with the bit set. So factor out a common base bit set class. Re-do the current class as a trivial derivative of that, and create a templatized one that can work in terms of an enum. The templated output will be very small since 95% of it is in the base class and out of line.
  • Add support (C++ and CML) for the 64 bit version of getting the current millis tick count. The 32 bit one will wrap around every 40'something days, whereas the 64 bit one you'll be dead before that happens, so you never have to worry about wrap around if you are using it to wait for some length of time, often done in drivers or various communications protocols to wait for the other side to respond. You can also use the current time stamp, and most of the time you will, but it can be affected by adjustments to the system clock.
  • Somehow a comma got deleted and what was two numbers became one (too big) number and would cause the creation of an image object to fail in the initialization of the template scaling dialog, so it would cause an exception and not run.
  • If the template scaling dialog should get an error when trying to reload the previous settings, don't let that cause it to fail. Catch that, tell the user that it couldn't be loaded, and continue with default (empty) values that they can set up again.
  • During the recent change to the new standard chunked file format in the data server, we had to update the code that packages up the shipped system images. During that, somehow the lines related to dealing with color based transparency got lost. Not that there are many such, but some really old ones are color based. So the transparency color would show instead of bring transparent.
  • Look at adding the Yamaha CX-A5100 to our list of Yamaha YNC supported devices. This was done by eye, using the provided docs, so it needs to be tried.
Dean Roddey
Explorans limites defectum

Possibly Related Threads...
Thread Author Replies Views Last Post
  Official 5.4 Beta Discussion Thread Dean Roddey 441 41,754 06-15-2019, 02:33 AM
Last Post: Bugman
  Official 5.3 Beta Discussion Thread Dean Roddey 815 151,299 07-05-2018, 12:44 PM
Last Post: Dean Roddey
  Official 5.3 Release Thread Dean Roddey 27 7,910 07-05-2018, 12:44 PM
Last Post: Dean Roddey
  Official 5.2 Beta Discussion Thread Dean Roddey 244 87,644 10-14-2017, 07:57 PM
Last Post: Dean Roddey
  Official 5.2 Beta Release Thread Dean Roddey 13 8,804 10-09-2017, 06:49 PM
Last Post: Dean Roddey
  Official 5.1 Beta Discussion Thread Dean Roddey 453 197,127 05-16-2017, 03:45 PM
Last Post: Dean Roddey
  Official 5.1 Beta Release Thread Dean Roddey 28 19,502 05-12-2017, 05:44 PM
Last Post: Dean Roddey
  Official 5.0 Beta Discussions Dean Roddey 2,019 489,144 11-09-2016, 04:34 PM
Last Post: Dean Roddey
  Official 5.0 Beta Release Thread Dean Roddey 15 13,314 11-01-2016, 10:32 AM
Last Post: Dean Roddey
  How to obtain Beta versions? willsauter 3 3,574 07-15-2016, 04:57 PM
Last Post: willsauter

Forum Jump:

Users browsing this thread: 1 Guest(s)