Centralite driver - [Exception] Index error? Limits on # of switches?

[SpeedDemon]

Hi,

I've been working today on trying to get the Centralite driver running. I've spent hours editing the _config.csv file and it seems like it's in good shape, but I am getting an "[Exception] Index" error whenever I try to use more than 138 switches. I can't find anything out of the ordinary for the name/load# etc for switches 137, 138, 139, so I have no idea why it is dieing on 138. Is it possible the driver was coded in such a way to have a limit on total loads/switches/scenes?

I have an EleganceXL with 8 load panels (five 24-load dimmers, one High Voltage RB, two Low Voltage RB's). I've defined 192 loads, 322 switches, and 41 scenes in the config file.

When I pull out the switch configurations from 137 on, the driver loads ok and seems to function.

Here's a snippet from the log for when I try to define all the switches:

[SIZE="1"]{
CQCGenDrvS, MEng.System.CQC.Drivers.Centralite.LiteJet.DriverImpl.1974, Status/App Status
<Connect> Writing Switch state objID: 137 objIndex: 136 state: F
}
02/27 19:29:42-Server-PC, CQCServer, CQCDrv_EleganceXL_Thread6
{
CQCGenDrvS, MEng.System.CQC.Drivers.Centralite.LiteJet.DriverImpl.1974, Status/App Status
<Connect> Writing Switch state objID: 138 objIndex: 137 state: F
}
02/27 19:29:42-Server-PC, CQCServer, CQCDrv_EleganceXL_Thread6
{
CQCGenDrvS, MEng.System.CQC.Drivers.Centralite.LiteJet.DriverImpl.2051, Status/App Status
<Connect> [EXCEPTION] Index 138 is invalid for this collection object
}
02/27 19:29:44-Server-PC, CQCServer, CQCDrv_EleganceXL_Thread6
{
CQCKit, CQCKit_DriverBase.cpp.2845, Status/App Status
Driver 'EleganceXL' is trying to connect to its device
}
02/27 19:29:44-Server-PC, CQCServer, CQCDrv_EleganceXL_Thread6
{
CQCGenDrvS, MEng.System.CQC.Drivers.Centralite.LiteJet.DriverImpl.1896, Status/App Status
<Connect> Entering Connect function, Version 1.0
}
02/27 19:29:44-Server-PC, CQCServer, CQCDrv_EleganceXL_Thread6
{
CQCGenDrvS, MEng.System.CQC.Drivers.Centralite.LiteJet.DriverImpl.1898, Status/App Status
<Connect> Older firmware in use.
}
02/27 19:29:44-Server-PC, CQCServer, CQCDrv_EleganceXL_Thread6
{
CQCGenDrvS, MEng.System.CQC.Drivers.Centralite.LiteJet.DriverImpl.626, Status/App Status
<GetMessage>: Msg did not match enumeration, checking flags....
}
02/27 19:29:44-Server-PC, CQCServer, CQCDrv_EleganceXL_Thread6
{
CQCGenDrvS, MEng.System.CQC.Drivers.Centralite.LiteJet.DriverImpl.659, Status/App Status
<GetMessage>: Getting load level flag set.
}
02/27 19:29:50-Server-PC, CQCServer, CQCDrv_EleganceXL_Thread6
{
CQCGenDrvS, MEng.System.CQC.Drivers.Centralite.LiteJet.DriverImpl.1379, Status/App Status
<SetAllFields>: Config file found, reading from config file.
}
02/27 19:29:51-Server-PC, CQCServer, CQCDrv_EleganceXL_Thread6
{
CQCGenDrvS, MEng.System.CQC.Drivers.Centralite.LiteJet.DriverImpl.903, Status/App Status
<ReadFieldsFromConfigFile>: 322 Switch objects, 38 Scene objects, 192 Load objects
}
02/27 19:29:51-Server-PC, CQCServer, CQCDrv_EleganceXL_Thread6
{
CQCGenDrvS, MEng.System.CQC.Drivers.Centralite.LiteJet.DriverImpl.1399, Status/App Status
<SetAllFields> Loaded Switches: 322 Scenes: 38 Loads: 192
}
02/27 19:29:51-Server-PC, CQCServer, CQCDrv_EleganceXL_Thread6
{
CQCGenDrvS, MEng.System.CQC.Drivers.Centralite.LiteJet.DriverImpl.1931, Status/App Status
<Connect> Getting initial load states.
}
02/27 19:29:51-Server-PC, CQCServer, CQCDrv_EleganceXL_Thread6
{
CQCGenDrvS, MEng.System.CQC.Drivers.Centralite.LiteJet.DriverImpl.213, Status/App Status
<Send> Msg sent: [^G]
}
02/27 19:29:51-Server-PC, CQCServer, CQCDrv_EleganceXL_Thread6
{
CQCGenDrvS, MEng.System.CQC.Drivers.Centralite.LiteJet.DriverImpl.590, Status/App Status
<GetMessage>: Msg received [0A0000000002000000430000000000000000200000000000]
}
02/27 19:29:51-Server-PC, CQCServer, CQCDrv_EleganceXL_Thread6
{
CQCGenDrvS, MEng.System.CQC.Drivers.Centralite.LiteJet.DriverImpl.626, Status/App Status
<GetMessage>: Msg did not match enumeration, checking flags....
}
02/27 19:29:51-Server-PC, CQCServer, CQCDrv_EleganceXL_Thread6
{
CQCGenDrvS, MEng.System.CQC.Drivers.Centralite.LiteJet.DriverImpl.666, Status/App Status
<GetMessage>: Getting load states flag set.
}
02/27 19:29:51-Server-PC, CQCServer, CQCDrv_EleganceXL_Thread6
{
CQCGenDrvS, MEng.System.CQC.Drivers.Centralite.LiteJet.DriverImpl.682, Status/App Status
<GetMessage>: Msg type: LoadStates
}
02/27 19:29:51-Server-PC, CQCServer, CQCDrv_EleganceXL_Thread6
{
CQCGenDrvS, MEng.System.CQC.Drivers.Centralite.LiteJet.DriverImpl.393, Status/App Status
<ProcessMessage>: Type: LoadStates Msg: [0A0000000002000000430000000000000000200000000000]
}
02/27 19:29:51-Server-PC, CQCServer, CQCDrv_EleganceXL_Thread6
{
CQCGenDrvS, MEng.System.CQC.Drivers.Centralite.LiteJet.DriverImpl.1950, Status/App Status
<Connect> Getting initial switch states.
}
02/27 19:29:51-Server-PC, CQCServer, CQCDrv_EleganceXL_Thread6
{
CQCGenDrvS, MEng.System.CQC.Drivers.Centralite.LiteJet.DriverImpl.213, Status/App Status
<Send> Msg sent: [^H]
}
02/27 19:29:51-Server-PC, CQCServer, CQCDrv_EleganceXL_Thread6
{
CQCGenDrvS, MEng.System.CQC.Drivers.Centralite.LiteJet.DriverImpl.590, Status/App Status
<GetMessage>: Msg received [000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000][/SIZE]

Another issue I'm wondering about is it seems like the load report coming back isn't large enough to represent all the loads I have. Could this be related to the driver (or Centralite firmware??) being geared for earlier LiteJet hardware where I think some hardware had a max of 2 48-load panels?

Currently I'm using the "Older (4.6 etc) LJ24 or Elegance" selection within the driver. Since the EleganceXL has 7.x firmware, I tried using the "Newer (7.0+) LJ24" option even though it doesn't mention "Elegance". It doesn't resolve this Index Exception issue plus it constantly (every half second) seems to ping the Elegance in an endless loop of:

<GetMessage>:Msg did not match enumeration, checking flags....
<GetMessage>:Getting load level flag set.

Help!!

Thanks

[beelzerob]

The driver is indeed set to a max num of switches of 138. Max scenes 41, max loads 40. And those all double for the LJ48. I'm only *GUESSING* that I set those constants based on information in the protocol doc.

If you want to try, load the driver up into the CML driver harness, and change the 138 to something higher and see what happens.

[SpeedDemon]

The driver is indeed set to a max num of switches of 138. Max scenes 41, max loads 40. And those all double for the LJ48. I'm only *GUESSING* that I set those constants based on information in the protocol doc.

If you want to try, load the driver up into the CML driver harness, and change the 138 to something higher and see what happens.

I just re-read the Centralite protocol doc. It looks like the Centralite protocol supports all the loads/switches I have:

Every 6 digits of that 48-digit ASCII hex # response for load status represents 24 loads, so 192 loads total.

Every 4 digits of the 96-digit ASCII hex # response for switch status represents 16 switches, so 384 switches total.

Per my PM to you though, first I need to figure out why the driver suddenly stopped working entirely last night, constantly repeating a non-Connect message when the port has been proven connected & communicating with the Centralite hardware via Hyperterminal (and had been working for hours up until suddenly hitting this issue!)

[SIZE="1"] CQCKit, CQCKit_DriverBase.cpp.2845, Status/App Status
Driver 'EleganceXL' is trying to connect to its device

CQCGenDrvS, MEng.System.CQC.Drivers.Centralite.LiteJet.DriverImpl.1896, Status/App Status
<Connect> Entering Connect function, Version 1.0 CQCGenDrvS,

MEng.System.CQC.Drivers.Centralite.LiteJet.DriverImpl.1900, Status/App Status
<Connect> Newer firmware in use.

CQCGenDrvS, MEng.System.CQC.Drivers.Centralite.LiteJet.DriverImpl.2044, Status/App Status
<Connect> Device is not connected.[/SIZE]

Thanks again!

[beelzerob]

Hmm. I'll look in the protocol doc I have and see how I came up with those original numbers. I usually have a reason for stuff like that. But I'll post a new version for you to use with the higher numbers so you can experiment with it.

As far as why it's not connecting all of the sudden...assuming you didn't upgrade CQC or make any changes to the CQC centralite driver, then I'd be very surprised if it's a software issue. Historically these issues come down to 1) the cable, 2) an unexpected windows update, 3) the cable. I know you're connecting via another program, but that doesn't always reveal a problem.

When I get home i can take a look at what the driver is trying to use after it says its using the newer firmware. Are you sure the config file is still available? Have you tried rebooting the system altogether?

[SpeedDemon]

Hmm. I'll look in the protocol doc I have and see how I came up with those original numbers. I usually have a reason for stuff like that. But I'll post a new version for you to use with the higher numbers so you can experiment with it.

As far as why it's not connecting all of the sudden...assuming you didn't upgrade CQC or make any changes to the CQC centralite driver, then I'd be very surprised if it's a software issue. Historically these issues come down to 1) the cable, 2) an unexpected windows update, 3) the cable. I know you're connecting via another program, but that doesn't always reveal a problem.

When I get home i can take a look at what the driver is trying to use after it says its using the newer firmware. Are you sure the config file is still available? Have you tried rebooting the system altogether?

Thanks for the offer to update the CQC driver! Fingers crossed.

I just figured out why I lost connectivity. It was on the Centralite MCP side. Apparently when doing some configuration changes last night (via the Centralite software) to get certain Load changes reporting so that CQC could pick them up (I'm still not sure if that is working properly yet by the way), the 3rd-party-communications checkbox defaulted back to "Off". Re-enabling and re-sending that to the MCP got the CQC driver and the MCP talking again. Interesting that the setting will halt driver communication, but it had no impact on using that same comport with Hyperterminal for using some basic protocol commands.

[beelzerob]

Ok, give this a try. Assuming you're using the release version, then importing this will give you a (Dev) version of the same driver.

I'll be curious if this works. My limitations were correct for the LJ system, but a little low for the Elegance. The Elegance should be able to handle 384 switches, 192 loads and 256 scenes for a single system (which is what this driver supports). The driverpack below has these higher limits in it. I think that might break stuff for LJ owners, so if this works then I'll have to make a little updated to handle the Elegance separately as far as these limits.

[SpeedDemon]

Ok, give this a try. Assuming you're using the release version, then importing this will give you a (Dev) version of the same driver.

I'll be curious if this works. My limitations were correct for the LJ system, but a little low for the Elegance. The Elegance should be able to handle 384 switches, 192 loads and 256 scenes for a single system (which is what this driver supports). The driverpack below has these higher limits in it. I think that might break stuff for LJ owners, so if this works then I'll have to make a little updated to handle the Elegance separately as far as these limits.

Awesome, looks like it's working (assuming the info below isn't an issue), no issues connecting now with the full 300+ switch/192 load list! Thanks much.

I notice the driver is always generating repetitive activity in the log, starting with:

[SIZE="1"]<GetMessage>:Msg did not match enumeration, checking flags....
<GetMessage>:Getting load level flag set
<LoadNumtoFieldId>:Searching for load num xxx
<LoadNumtoFieldId>:Comparing loadID 001 to targetID xxx
<LoadNumtoFieldId>:Comparing loadID 002 to targetID xxx[/SIZE]

Basically it will repeat that last line until it has incremented up to xxx. Then it says:

[SIZE="1"]<LoadNumToFieldId>: Found field ID yyy (level) and yyy-1 (state) for load number xxx
<ProcessMessage>: Setting load xxx (yyy):0 state (yyy-1): F[/SIZE]

After that, it moves on to a new load and the process starts over.. So it's basically going through nearly 200 loads and for each load, counting from 1 to the load #..

Just wondering what it's doing, if it's a concern that "msg does not match enumeration", and, using some actual #'s, why it's saying it "Found field ID 332 (level) and 331 (state) for load number 158".

If this is all normal, efficient operation and you're pressed for time, just let me know and I won't worry about it

Thanks again!

[beelzerob]

Those messages should only be coming out if you have the driver verbose set to something other than Off. Hopefully that's the case.

[SpeedDemon]

Those messages should only be coming out if you have the driver verbose set to something other than Off. Hopefully that's the case.

Correct. Just wanted to make the messages stating "msg did not match enumeration" and all the constant load comparisons/assignment type messages were normal & not a bad thing.

Thanks!

[beelzerob]

Ya, that's just debug help.