Help on editing existing Driver

[Spot]

I want to dig into the RCS Thermostat Driver again and make a few changes, but want to do it the right way....Last time I was editing the stock Driver and when I made a mistake...I had to reinstall CQC to get things back to normal. 

I am trying to follow the instructions in the documentation, but, since I am relatively new to some of the terminology, I want to make sure that I am doing it correctly. The instructions read:

1. Grab the current manifest, from the Master Server directory indicated above and copy it somewhere local. (This was the Easy Part)
   
   
2. Change the Make and/or Model in the manifest so that it doesn't conflict with the deployed driver. The make/model in the manifest is the unique key for a driver. So you cannot have two drivers with the same make/model. If you are doing a temporary working version of an existing driver, the convention is to add -Dev to the model name to distinguish it. ( Did this by using a text editor on the XML Manifest File)
   
   
3. Change the short description. Either for the new device; or, if doing a temp working version of an existing driver, to also indicate a -Dev or some other change to make it clear when reading through the available drivers which one is the deployed one and which is the development one.  (Text Editor on the XML File)
   
   
4. Change the CML class path. If you are creating a copy of a system driver, just change System to User. If it's one of your own, you are already in User, so create another scope to put it in. Follow the existing convention of a Make/Model based hierarchy. I.e. all of the Denon drivers are under a Denon scope and individual models are under that.
   a. I changed: ClassPath MEng.System.CQC.Drivers.RCS.SerialRS485V2.DriverImpl;b. To : ClassPath MEng.User.CQC.Drivers.RCS.SerialRS485V2.DriverImpl;
   
5. Open your manifest file in the IDE. It will say the class doesn't exist, do you want to create it. Say yes and it will create an empty class.
   - I did this...I did not expect that I had to go to the driver configuration before I would get the message...So I did it several times before I think I got it right.
   
6. Do Ctrl-R to open for read only and navigate to the existing driver and open it. Select and copy the whole thing.
   
   
7. Go back to your new copy and paste the contents in, overwriting the temporary content that was created above.
   
   
8. Copy and paste any helper classes files that are part of the driver and that you are going to modify, to create your new versions of those.
   - I am unsure how helper classes are defined in the code.....
   
9. Update any Import and ClassPath lines to reflect the new locations. Be careful to get this done or you'll be referring still to the original files.
    -This is where I am really unsure.  It seems that some of these are system classes that won't be present in the User directory...so should I change the paths?
   
   Initial Driver Code:
   Class=[NonFinal]   
   ClassPath MEng.System.CQC.Drivers.RCS.SerialRS485V2.DriverImpl;   
   ParentClass MEng.System.CQC.Runtime.CQCDriverBase;
   EndClass;
   
   Imports=    MEng.System.Runtime.CommCfg;   
   MEng.System.Runtime.CommPort;   
   MEng.System.Runtime.MemBuf;   
   MEng.System.Runtime.StringTokenizer;   
   MEng.System.CQC.Runtime.CQCFldDef;   
   MEng.System.CQC.Runtime.V2Helper;   
   
   #BeginDebug   
   MEng.System.Runtime.ConsoleOutStream;   
   #EndDebugEndImports;
   
   I Changed the working copy to (But unsure if it is correct):
   
   Class=[NonFinal]   
   ClassPath MEng.User.CQC.Drivers.RCS.SerialRS485V2.DriverImpl;   
   ParentClass MEng.System.CQC.Runtime.CQCDriverBase;
   EndClass;
   
   Imports=    MEng.User.Runtime.CommCfg;   
   MEng.User.Runtime.CommPort;   
   MEng.User.Runtime.MemBuf;   
   MEng.user.Runtime.StringTokenizer;   
   MEng.User.CQC.Runtime.CQCFldDef;   
   MEng.User.CQC.Runtime.V2Helper;   
   
   #BeginDebug   
   MEng.User.Runtime.ConsoleOutStream;   
   #EndDebugEndImports;
   
   It honestly seems like I am changing paths to some classes that do not to be changed...but my interpretation of the documentation appears to indicate otherwise....
   
   
   I don't want to continue until I get it right...since I don't want to have to reinstall CQC if I screw a driver up....
   
   Thanks for any thoughts...I apologize for my earlier formatting nightmare on the code segment.

[kblagron]

I have a 2009 era RCS system with two ZCV4 control systems communicating via RS-485.  I have never been able to get the shipped version to work - it connects, but drops the connection multiple times per hour.  I am good with one of the user drivers, of which there has been a couple over the years.   I am using the Kirk Kanak V2.1 with almost no issues.  There was a later version that someone wrote that added more features, but I could not get it to work with my system (didn't try hard as the older driver worked).  Dean wrote a V2 driver, and I had similar problems with connectivity, but the V2.1 driver has been steady for 10+ years.

[Spot]

I have a 2009 era RCS system with two ZCV4 control systems communicating via RS-485.  I have never been able to get the shipped version to work - it connects, but drops the connection multiple times per hour.  I am good with one of the user drivers, of which there has been a couple over the years.   I am using the Kirk Kanak V2.1 with almost no issues.  There was a later version that someone wrote that added more features, but I could not get it to work with my system (didn't try hard as the older driver worked).  Dean wrote a V2 driver, and I had similar problems with connectivity, but the V2.1 driver has been steady for 10+ years.

I've been using my TR-16s for a while and had them connected via daisy-chained RS-485.  It was rock-solid for years & then my (prior) HA solution stopped supporting the driver during their version change.  

I have never come across that version of the plugin across the forums.  Is it still available?  I'd like to see what capabilities it has...

I've been able to get the shipped V2 version (after the field-index problem was fixed) to work pretty well with my system.  I do get occasional drops, but I beleive that most of those were due to a bad RS-485 converter.  I'm running a different converter right now & I get some comm resets...but it is preceded by some odd comm behavior on the port.  Therefore, i want to try and figure out the issue.

[Dean Roddey]

You want to change your driver's path:

MEng.User.CQC.Drivers.RCS.SerialRS485V2.DriverImpl;

The others are references to system classes. This insures that you are editing your version of the driver, and not the system one. A given driver may consist of more than one class, so you'd update them all and any of their references to each other. But in this case it looks like it's just a single class.

[Spot]

You want to change your driver's path:

MEng.User.CQC.Drivers.RCS.SerialRS485V2.DriverImpl;

The others are references to system classes. This insures that you are editing your version of the driver, and not the system one. A given driver may consist of more than one class, so you'd update them all and any of their references to each other. But in this case it looks like it's just a single class.

Thanks Dean.

[kblagron]

The link to the build thread for the driver is here:  https://www.charmedquark.com/vb_forums/s...p?tid=3534

[/url]Attached are the driver pack and html.  Since this was written a good while ago, it may not work anymore on the latest system (i.e. was built on a much earlier system and not upgraded over the various versions).  If so, let me know, and I will build a driver pack for the one I have up and running.