method to list the available firmwares to be used with upgradefirmware. #709
Conversation
|
@sujithhanwha what do you mean with official? Do you want to support release candidates or similar versions? |
|
|
Like the approach. Only suggested change is to default the API to released versions which the customer can use with guaranteed functionality. Not sure whether we want to promote distribution of unofficial aka beta software as for some companies betas may only be provided after signing some special agreement. Due to this I suggest to change the option to |
Agree with your suggestion and have updated the flag accordingly. Please review. |
| </xs:element> | ||
| <xs:complexType name="FirmwareInfo"> | ||
| <xs:sequence> | ||
| <xs:element name="FirmwareName" type="xs:string"> |
There was a problem hiding this comment.
Is this intended to be the version or more a friendly name? Maybe Version is more appropriate name.
There was a problem hiding this comment.
Is this intended to be the version or more a friendly name? Maybe
Versionis more appropriate name.
@cpiette-gen , Agree, version is more appropriate will update it to version.
doc/Core.xml
Outdated
| <section xml:id="_Ref276040130"> | ||
| <title>GetAvailableFirmwares</title> | ||
| <para>This operation retrieves a list of available firmware versions for the device.</para> | ||
| <para>The returned list contains firmware information including name, description, and optional information about the release date, whether it is a beta version, and whether it is a bridge firmware essential for upgrade or downgrade. The firmware names returned can be used with the <emphasis role="bold">UpgradeFirmware</emphasis> operation.</para> |
There was a problem hiding this comment.
Reading this and the UpgradeFirmware call, it is unclear to me how the device (or client?) has to handle Bridge Firmwares. I've seen devices where bridge firmwares are partial firmwares, where the device is essentially not functional, and simply expects a further upgrade to a "real" firmware. In those scenarios, I would expect that UpgradeFirmware handles those seemlessly for the user.
Scenario 1
I am on firmware 1.23
There is version 2.00 available, but it requires a bridge firmware 1.99
GetAvailableFirmwares list 2.00 as available. And UpgradeFirmware to 2.00 will automatically fetch 1.99, install it, then install 2.00 as the user requested. This step by step process would be implemented by the device itself (and any necessary supporting services from the manufacturer) without intervention from the User.
Is that scenario correct? Am I expecting too much from the device? What are the other options?
Scenario 2
I am on firmware 1.23
There is a version 2.00 available, but it requires a bridge firmware 1.99
GetAvailableFirmwares list 1.99 available only, flagged as bridge firmware. 2.00 is not available (the device can't jump to it directly)
The user will UpgradeFirmware to 1.99, and since the bridge firmware was enabled, it will be expected to immediately query GetAvailableFirmwares again, find 2.00 and then upgrade to it immediately, as the bridge firmware is not expected to be fully features (but will at the very least need to connect to the uplink for example?)
I'm curious about which scenario is the expected one, we don't seem to require one of them (but I feel we probably should). We're partial to scenario 1, as it is much more straightforward. But I'm wondering what the manufacturers think about it?
There was a problem hiding this comment.
@jmelancondev , my original idea was more aligned with the Scenario 2 (though its not explicitly mentioned in the description and that was the intention behind providing is latest flag also). Scenario 1 is also not bad, we can discuss this in next telco.
| <xs:documentation>The release date of the firmware version.</xs:documentation> | ||
| </xs:annotation> | ||
| </xs:element> | ||
| <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> <!-- first Vendor then ONVIF --> |
There was a problem hiding this comment.
is the ##any to be added at the end i.e after IsLatest attribute?
6 participants
Provides a device‑side method for listing available firmware, serving as an alternative to the cloud‑based getAvailableFWImages in the CloudIntegration specification.
Please review.