Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Driver info/stats
When right clicking on a Device an info/stats window appears which has all the configuration information for the device.

It also contains version, but I can't get it to update.  Is that the version of the driver when the device was first installed, or the current version?  I updated a driver to fix a bug and also updated the manifest.  I restarted the AppServer (and even rebooted).  The info/stats window still shows the old version!  When I pretend to create a new device, the driver version is correct.

Also, the code is behaving correctly now, so I new it is in fact using the correct version.

Its just frustrating trying to figure it all out sometimes.

Driver manifest info is basically driver configuration. So it's stored away as part of the configured drivers. It would generally only update the manifest info if you do a reconfigure on the driver. Otherwise, the driver could pick up options from a newly updated manifest that have never been given values by the user. That could cause some difficult to deal with weirdness.

When you do a reconfigure, that makes the user go through the configuration process again, and provide valid values for any new driver prompts.

That's why you always also do a reconfigure after importing a driver package for an existing driver, to pick up any new manifest info (and also of course to make the driver cycle and run the newer code.)

The only really weird scenario is for developers, who can change the CML without updating the manifest. On end user systems, they get the new CML by doing a package import, which updates both, then you can do a reconfigure. But a developer can change the CML at any time.

Oh, and also the data server caches manifests. If you just change the file it won't pick it up. That's why usually, if you want to force the manifest to update, you need to generate a package and import it. Package import writes through the data server's cache, so it updates any in-memory version and updates the file version. Otherwise, you will always see the cached version.

There again, only really an issue for developers, who just have to be careful about that difference between CML macros, which are easy to save and change and manifests which are trickier.

So, anyhoo, the short version is:

1. Just changing the manfiest file and saving it won't make the data server pick it up, you either have to cycle the MS service or generate a package and import it
2. The new manifest info will then be available, but any installed instances of that driver will not pick up the manifest changes until you do a reconfigure, so that you are sure that any new prompts are given valid values by the user.
Dean Roddey
Explorans limites defectum
First, I had no idea that you had to "reconfigure" your devices whenever the driver version changes. If that is true, then the release notes should contain a list of drivers that were updated, so users would know which devices they had to reconfigure!

I also think driver version and configuration version should be separated. Maybe the driver could depend upon a certain version of the configuration. This way if you update your driver and it requires a new configuration, it wouldn't start and you could check the logs to find out. Driver version could be in a $Version field, since configuration version is available via Info/Stats.

You don't have to reconfigure your drivers just because the CML changed, it's only if the manifest changed. The CML has to be backwards compatible with previous manifest info (so it will default any driver prompts it knows about but which aren't provided by the user yet because it's an existing installed driver and the user hasn't reconfigured the driver.)

So the driver should continue to work as before. You would only need to reconfigure possibly to pick up some new functionality that the manifest enables. That's something that should be in the release notes and/or in the driver documentation.

So the 'version' is a bit slippery. Not letting the driver start though would be a mess. Since the driver should continue to run, and to use any new features that don't depend on the user making some selection on a newly provided driver prompt, there's no reason to do that. It would just confuse users badly and piss them off.

However, looking at it, the core info should get updated from the new manifest upon either reconfig or upon driver reload (which always happens after an upgrade or cycle of the CQC service on the machine where the driver is running.) So, in that case, the basic, hard coded manifest info should get upgraded to whatever is in the latest manifest file (and new driver prompts will be added as well, but just with default values defined in the manifest.)

The only reason that wouldn't happen, that I can see, are:

1. There was an issue in the new manifest file so it couldn't be parsed successfully
2. You changed either make or model so the two files were no longer considered the same manifest anymore

As long as you don't do those two things, if you:

1. Create a package and import it, in order to get the in-memory manifest info updated
2. Then reconfigure, or unload/reload the driver, or cycle the machine on which that driver is running

Then I would think that the basic info (driver version, CML class path, author, description, all that hard coded stuff, should be updated.
Dean Roddey
Explorans limites defectum
So, reading through that, I feel like I was a bit disjoint in my description, partly due to trying to do that in between brain frying other work. Maybe a better way to approach it would be to just explain the flow of things.

Any time you change the CML, either by editing it directly, or importing a package, if the driver is already running, it's not going to magically stop and start running the new CML. So, most of the time, the reason you'd do a reconfigure is just to avoid having to remove and re-add the driver, which would achieve the same thing but force you to re-enter all of the configuration values from scratch. Doing a reconfigure is equivalent to a remove/re-add, but it keeps the existing configuration options. So it's just a cheap way to get the driver to parse and start running the new CML.

Most of the time, the manifest file hasn't changed, and that's all that the reconfigure is being used for, just restart it so it can run the new CML code.

If the manifest file has changed, then you want CQC to pick up those changes. Typically this is done in one of two ways:

1. The changes come as part of a CQC upgrade, and so everything restarts from scratch. This makes the driver be reloaded from scratch. When that happens, CQCServer (the driver host) loads the latest manifest info (and it always gets the most recent stuff because the whole system restarted and it parsed and cached all of the manifests again) and reconciles it with what is currently configured for any drivers of that same make/model. It will update the static info, and add default values for any prompts that are now present but weren't before.

2. The other way is when the user imports a driver package. In this case, the import process forces the MS to update its in-memory view of the manifest data (which is used for any subsequent loads of a driver of that type, this doesn't update the configuration for any currently loaded and running drivers of that type.) I.e. it gets the manifest list updated so that when you run the driver wizard to load a driver of that type, it will see the new info.

In this case, the reconfigure process does double duty, again when the driver is already loaded and running, because it both starts/restarts the driver, and it forces that above mentioned manifest reconciliation process as well. So when you step through the driver wizard as part of the reconfig, you should see any newly added prompts, and behind the scenes any newly added fixed prompts will be there as well.

The third and least likely scenario is the driver writer. In this case, he can just save the CML and it's now there. So a reconfig is just used to get it to load the new CML for testing (though generally testing in the IDE is better, pausing any really loaded instance of the driver.) If you make a change to a manifest, you have to get it into the in-memory info, which means generate a package and import it, then do the reconfig, to get new CML and macro info and set any new prompts.

If you are testing in the IDE, then starting the session again (which makes you select the manifest again and run through the driver wizard) is the equivalent to importing a package and re-configuring for a live driver. The IDE will pick up CML changes every time you stop/start the driver, but it won't pick up manifest changes unless you restart the session and reload the manifest file.

Anyhoo, hopefully that's a bit clearer.
Dean Roddey
Explorans limites defectum
When I am debugging, something hard, I use the IDE.  When it is something simple, I typically test with my live system.  I just compile my code and pause/resume one of my drivers (never even thought of using reconfigure) and the new code starts running. In this case it was a little weird because I have three furnaces.  I pause/resumed FurnaceB and it started using the new code while FurnaceA and FurnaceC were still running the old code.  This was all expected though and with a little verbosity I was easily able to verify that my improved EXCEPTION LogMsg worked and with one more fix I was done.

I was a not surprised that the Info/Stats dialog didn't accurately reflect the version of code I was running because of manifest caching, but my code has a Version field which made things crystal clear.

However, I was surprised when a FULL Master Server REBOOT did not resolve my Info/Stats page, thus it makes me question whether
1. The changes come as part of a CQC upgrade, and so everything restarts from scratch. This makes the driver be reloaded from scratch. When that happens, CQCServer (the driver host) loads the latest manifest info (and it always gets the most recent stuff because the whole system restarted and it parsed and cached all of the manifests again) and reconciles it with what is currently configured for any drivers of that same make/model. It will update the static info, and add default values for any prompts that are now present but weren't before.
Is actually happening.  Maybe upgrades are different somehow, but simply restarting the CQCServer did not update the static info (version specifically).  The only way I was able to make Info/Stats version accurate was to reconfigure.

I assume this occurred when the Master Server started caching drivers for all servers, but I didn't realized the "reconfigure to get correct version number" implications.

It does go through this process of updating the basic info from the latest when a driver loads up. The only reason it wouldn't is that it couldn't get the latest, or the make/model had changed in the manifest. I guess it's possible the latest info couldn't be gotten. It is done during system startup and it will only wait so long to get the info. It should log something if that happens, but it's probably too late to catch that in the logs now. So it could have just been a not likely but possible 'everyone was too busy' type of deal.

Since the driver should still work even if the manifest doesn't get updated, it doesn't want to hold anything up or stop it from loading.
Dean Roddey
Explorans limites defectum

Possibly Related Threads…
Thread Author Replies Views Last Post
  Driver for Amazon 4k Stick Darrie 3 590 01-15-2022, 02:21 PM
Last Post: znelbok
  CQSL Interface Driver connects but no control NightLight 3 652 10-26-2021, 01:12 PM
Last Post: NightLight
  ClickPLC driver now failing after upgrade znelbok 2 1,033 09-21-2020, 10:48 PM
Last Post: znelbok
  Pentair driver tom 5 2,035 08-02-2020, 11:29 PM
Last Post: kblagron
  Marantz receiver driver (IP) dlmorgan999 6 2,137 05-15-2020, 03:32 PM
Last Post: dlmorgan999
  Variables Driver Client gReatAutomation 4 1,729 04-25-2020, 12:46 PM
Last Post: gReatAutomation
  What is everyone using for weather info? ghurty 11 2,568 04-23-2020, 08:00 AM
Last Post: Dean Roddey
  Reconfig of Driver Causes Built In Triggers to Fire gReatAutomation 2 1,299 03-25-2020, 04:09 PM
Last Post: gReatAutomation
  Lutron RadioRA2 Driver and Lutron Visor Control gReatAutomation 29 11,589 03-19-2020, 01:03 PM
Last Post: gReatAutomation
  Timers Driver / Field Time Image / Seconds gReatAutomation 1 1,202 03-16-2020, 05:48 PM
Last Post: Dean Roddey

Forum Jump:

Users browsing this thread: 1 Guest(s)