Need some help with DynamicOverLoad command

[adamalli]

Yep I mean multiple drivers. I have a mix of UPB lights and Hue lights. So I will need to figure something else out as what you describe is a little out of my knowledge level.

Also do you have an ETA of when you could look into the elk driver as I would like to have a list of my security zones too.

[Dean Roddey]

It's not the Elk driver, I'm pretty sure it's the filtering for only read/write fields, where security zones are read only. I'll need to change that which will require code changes in CQC itself. I'll get it into the 5.3.903 beta drop, but that may still be some days since I'm making significant changes and will then need to test those out before letting it out into the wild.

[Dean Roddey]

It wouldn't be that difficult to do the multiple drivers. You call it once and you end up with two lists in variables, say:

LVar:Fields
LVar:Names

If you then call it again and pass LVar:Fields2 and LVar:Names2, you can then concatenate the lists (with the extra needed comma between the last of the first list and the first of the last list) like this:

Code:

LocalVars::SetVariable
   P1=LVar:Fields
   P2=%(LVar:Fields), %(LVar:Fields2))

LocalVars::SetVariable
    P1=LVar:Names
    P2=%(LVar:Names), %(LVar:Names2))

Now LVar:Fields and LVar:Names have the two combined lists in them, and anything after that is the same as before when you just had the info on one driver.

[adamalli]

Thank you for the example and that helps. Though isn't this going to cause a problem when the field name doesn't match the statefield in the template. In the template I have the UPB driver selected. My understanding is the dynamic overload is matching to the state field in my template. So with this approach wouldn't that cause problems since one of the drivers is not listed in the state field in my template?

[Dean Roddey]

It should be OK. It always looks for the special first field in the list, and then it replaces that with all of the subsequent ones. So it doesn't matter what the replacement values are, they are just being used to replace any widget that references that first value. So, you can add that replacement value easily enough as well, so something like:

Code:

LocalVars::SetVariable
   P1=LVar:Fields
   P2=%(LVar:Fields), %(LVar:Fields2))

LocalVars::SetVariable
    P1=LVar:Names
    P2=%(LVar:Names), %(LVar:Names2))

LocalVars::SetVariable
    P1=LVar:Fields
    P2=Hue.LGHT#Sw_FirstOne, %(LVar:Fields))

So after doing the two lists, push the special replacement value into the start of the fields list. So, in this case, as long as the layout template uses the field Hue.LGHT#Sw_FirstOne, it doesn't matter if the fields lists has entries from multiple different drivers.

As long as you are using V2 drivers, any switch or any dimmer field should work the same and have the same limits and all that.