I am using 1.2.9 and would like to create a preset with more than one precondition.
For example:
DeviceID.OUI <> “first OUI”, “second OUI”, 'third OUI"
I have already tried:
DeviceID.OUI <> (“first OUI”, “second OUI”, “third OUI”)
DeviceID.OUI <> “first OUI” OR “second OUI” OR “third OUI”
DeviceID.OUI <>“first OUI” OR DeviceID.OUI <> “second OUI” OR DeviceID.OUI <> “third OUI”
So far I have not been able to make it work.Any suggestions?
Ohh, sorry.
I didn’t realize MongoDB don’t have IN/NOT IN clause.
I see You use that example but should work DeviceID.OUI <> "333333" OR DeviceID.OUI <> "222222" OR DeviceID.OUI <> "111111" on version v1.2.9+20220822165235 work without error.
If You put some SQL or script code put it in quote ``
I do have a few presets for different devices but there are also a couple of them that can use the same preset. So I am trying to bundle them into using the same preset.
Are you using these presets to set values/tags or refresh items? If so, you really want to do this in a provision. Provision scripts give you a lot more flexibility. In our environment I have 3 main provision scripts that support/configured devices that are bridged, using tr-069, and tr-181. Inside the provision scripts is where I do all the generic config, and also any device/mfgr specific stuff.
It should be noted that GenieACS is smart enough to not send a GPV/SPV for a parameter that does not exist. For example, if in your provision script you have declare('InternetGatewayDevice.WANDevice.1.WANConnectionDevice.1.WANPPPConnection.*.X_SMARTRG_COM_AddSynFloodRules', {value: now}, {value: true}); and the device in question isn’t a SmartRG, or doesn’t have that path at all, then the SPV will not execute for that device. Behavior like this makes it much easier to have a few generic provision scripts.
If you are trying to set model specific values, I would not use OUI. OUI’s can and are shared amongst models within a mfgr.
For my use case, I test several different models from different manufacturers. This ACS is not used in our production environment but I would sometimes point a friendly customer device to compare what I see on my lab device.
Some models would throw 9007 errors and I ended up creating separate Provisions and Presets for those that did not work with the default options (inform, etc). It was easier to modify an individual Provision or Preset rather than one long Provision.
If I have to, I can switch to using one long Provision with all the required logic, but I was hoping to continue with my current setup.
Regarding my use of OUIs, I had also tried ProductClass but still the same issue. I am not worried about an OUI being used with more than one model as this is a lab server and I have control over the 20 to 30 devices on there now.