This question and documentation suggests the versioning for protocols to support updated vendor firmware.
A question regarding versioning strategy of connectors as recommended by Skyline
https://docs.dataminer.services/develop/devguide/Connector/ProtocolVersionSemantics.html
However for minor OID updates we want our protocols to be able to just adapt automatically and deal with it without having to manage more alarm templates for non-production protocol version and without having any dataminer adminstrator interaction to change element protocol versions when a field engineer updates the firmware of the device at all sorts of hours of the day. We just want things to keep working automatically.
An example is from DEVA DB8009 firmware 2.x to 3.x they have introduced a new OID and changed 3 others by a minus 1 of three integers. [ https://www.devabroadcast.com/products/db8009-mpx ]
As the firmware version is available to read in the MIB I'd like to be able to have the OID update automatically to a new OID.
I've got some loose ideas how to start this but am very interested if anyone else has made some simple or creative solution to dealing with minor oid changes across vendor firmware to be able to have the protocol manage itself.
The initial idea I had:
Having the polling group containing the firmware parameter with initial=true and delay the parameter group getting the OIDs above.
All the OIDS above are
srcmain: <OID id="200">1.3.6.1.4.1.35833.30.2.4.*</OID>
backup1: <OID id="201">1.3.6.1.4.1.35833.30.2.4.*</OID>
backup2: <OID id="202">1.3.6.1.4.1.35833.30.2.4.*</OID>
backup3: <OID id="203">1.3.6.1.4.1.35833.30.2.4.*</OID>
Parameters 200-203 have a default value in line with the most common firmware, and backup3 parameter in a group on it's own with a condition to not poll at all if the firmware isn't greater than a certain threshold.
Have a QAction triggered on the firmware parameter to check the firmware version and update parameters 200-203 with the integer that matches the desired OID for that firmware.
Hi Sam,
The method you are suggesting is a correct workaround. By either using a togglebutton or check the version via polling, you can fill the wildcards with the correct OIDs. We use it in a lot of our drivers as a means to support multiple OID versions, but only in the following cases:
- All (or big groups of) affected parameters have the same change in OID. An example would be when all OIDs change from A.B.C.X.Y.Z -> D.E.F.X.Y.Z where the A.B.C. changed but the rest of the number stayed the same. In this case the same wildcard (*) can be reused for a lot of parameters.
- When the amount of impacted parameters is considered low
If the use case does not fit any of these descriptions and there is no particular logic to the OID changes, we are more likely to consider it as a firmware change instead, which leads to a new version according to our versioning strategy
Do note that these rules are not set in stone and the final decision can differ from case to case
That error usually means the OID that it tries to poll is not available on the device.
In this case, although I'm not sure if that's the exact issue, I would already suggest to make the wildcard parameter of type string. A type string should be used since we can use the wildcard for more than a single number in the OID.
This means changing the Interprete > Type to 'string' and Interprete > RawType to 'other'. Apart from that, I don't see anything wrong with the code and it should be checked if the correct OID is retrieved and that OID is available on the device.
Thank you Robin for that reply, I did start working on an update to the protocol and did pretty much what you said
screenshots here: https://internect.net/dma/subOID.png
But I get "Get for srcmain () had error : NO SUCH NAME" in the StreamViewer 🙁
Cannot understand what is wrong. Any ideas?