method to list the available firmwares to be used with upgradefirmware. by sujithhanwha · Pull Request #709 · onvif/specs

sujithhanwha · 2026-01-20T07:55:59Z

Provides a device‑side method for listing available firmware, serving as an alternative to the cloud‑based getAvailableFWImages in the CloudIntegration specification.
Please review.

ocampana-videotec · 2026-01-20T14:00:53Z

@sujithhanwha what do you mean with official? Do you want to support release candidates or similar versions?

sujithhanwha · 2026-01-24T01:16:07Z

@sujithhanwha what do you mean with official? Do you want to support release candidates or similar versions?
We could also list non official firmware some thing like customized FW or Beta FW with some fix etc., that was the intention.

HansBusch · 2026-01-27T11:50:17Z

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 IncludeBeta and write in the text that beta versions may not be available for devices via this channel. Similarly I suggest to invert the property Official to Beta as by default firmware should be released.

sujithhanwha · 2026-01-28T00:37:58Z

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 IncludeBeta and write in the text that beta versions may not be available for devices via this channel. Similarly I suggest to invert the property Official to Beta as by default firmware should be released.

Agree with your suggestion and have updated the flag accordingly. Please review.

cpiette-gen · 2026-01-28T19:21:22Z

+			</xs:element>
+			<xs:complexType name="FirmwareInfo">
+				<xs:sequence>
+					<xs:element name="FirmwareName" type="xs:string">


Is this intended to be the version or more a friendly name? Maybe Version is more appropriate name.

Is this intended to be the version or more a friendly name? Maybe Version is more appropriate name.

@cpiette-gen , Agree, version is more appropriate will update it to version.

melanconj · 2026-01-28T19:25:36Z

+      <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>


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?

@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.

venki5685 · 2026-02-05T04:19:20Z

+							<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 -->


is the ##any to be added at the end i.e after IsLatest attribute?

xs:any is fine here, as it must be part of the sequence.

kieran242

@sujithhanwha I have reviewed this PR via the rendering engine and GIT and don't see any major issues.

I further agree with this functionality and believe it will be a very useful feature for both NVR and cloud.

I am providing an approval now based on my comments. If there should be further needed changes then I will re-review.

HansBusch · 2026-04-14T07:51:45Z

+							<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 -->


xs:any is fine here, as it must be part of the sequence.

…ailablefirmwares

HansBusch · 2026-04-15T11:33:21Z

Thanks for the quick fix, now the schema compiles nicelyl

HansBusch · 2026-04-21T09:57:01Z

+      <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 version, description, and optional information about the release date and whether it is a beta version. The firmware versions returned can be used with the <emphasis role="bold">UpgradeFirmware</emphasis> operation.</para>


Suggest to change
The firmware versions returned can be used with the <emphasis role="bold">UpgradeFirmware</emphasis> operation.
to
The firmware version strings returned shall be valid parameters of the <emphasis role="bold">UpgradeFirmware</emphasis> operation.

Updated this. Please check.

HansBusch · 2026-04-21T09:59:52Z

+        <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 version, description, and optional information about the release date and whether it is a beta version. The firmware versions returned can be used with the <emphasis role="bold">UpgradeFirmware</emphasis> operation.</para>
+        <para>The device shall list only firmware versions that are valid upgrade or downgrade from the current firmware version. If none of the returned firmware versions have the IsLatest flag set, the client may call this operation again after completing a firmware upgrade to obtain an updated list of available versions.</para>


Unclear what happens if the device is on latest firmware. Should that entry be returned or an empty list? If latest shoult be returned as well the previous sentence with valid upgrade/downgrade needs to be rephrased. Otherwise the empty result case needs to be stated.

Updated this, please check.

HansBusch · 2026-04-21T10:00:56Z

+							<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 -->


Suggest to add an optional item for link to release information like release letter.

added this optional ReleaseInfoUri param.

HansBusch · 2026-04-24T12:44:42Z

Thanks for the quick update.

kieran242

@sujithhanwha re-reviewed the PR and still was happy with the content.

ocampana-videotec · 2026-05-11T06:58:23Z

@sujithhanwha I just merged #769 into your branch. Please check that everything is ok.

method to list the available firmwares to be used with upgradefirmware.

82f7b9c

response updated to provide more information about the firmwares

296ba40

sujithhanwha added 2 commits January 24, 2026 10:25

description updated to match with the wsdl

7b2c4d8

Only Official flag updated for better clarity

16a1c61

Includeunofficial flag to Includebeta and description updated

52819eb

cpiette-gen reviewed Jan 28, 2026

View reviewed changes

melanconj reviewed Jan 28, 2026

View reviewed changes

firmwarename changed to firmwareversion

f0808c7

venki5685 reviewed Feb 5, 2026

View reviewed changes

ocampana-videotec modified the milestones: 26.06, 26.12 Feb 5, 2026

ocampana-videotec added IPR needed 26.12 WG_enh labels Feb 5, 2026

sujithhanwha added 2 commits March 10, 2026 14:12

bridge firmware concept removed and old firmware note added

c198b74

update according to f2f feedback

8829c21

kieran242 approved these changes Mar 31, 2026

View reviewed changes

HansBusch requested changes Apr 14, 2026

View reviewed changes

removed xs:any and xs:anyAttribute from request and response of getav…

d9108d8

…ailablefirmwares

HansBusch requested changes Apr 21, 2026

View reviewed changes

enhancement based on review comments

a738b24

HansBusch approved these changes Apr 24, 2026

View reviewed changes

ocampana-videotec mentioned this pull request May 5, 2026

Adapt explanatory text of firmware upgrade. #769

Merged

kieran242 approved these changes May 8, 2026

View reviewed changes

Adapt explanatory text of firmware upgrade. (#769)

d522dbd

Conversation

sujithhanwha commented Jan 20, 2026

Uh oh!

ocampana-videotec commented Jan 20, 2026

Uh oh!

sujithhanwha commented Jan 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

HansBusch commented Jan 27, 2026

Uh oh!

sujithhanwha commented Jan 28, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Scenario 1

Scenario 2

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kieran242 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

HansBusch commented Apr 15, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

HansBusch commented Apr 24, 2026

Uh oh!

kieran242 left a comment

Choose a reason for hiding this comment

Uh oh!

ocampana-videotec commented May 11, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

sujithhanwha commented Jan 24, 2026 •

edited

Loading