3.5.4-beta.4 "state.dsfVersion" new location

stuartofmt

I noteced that state.dsfVersion was deleted from beta.4 object model. I was using it to validate the version levels for my plugin.

Note that I only use this for SBC. For standalone I use result.[0].firmwareVersion

Since beta.4 - I've switched to boards.[0].firmware version which seems good-enough. My queston is, are there more changes to occur and is there a better indicator? The documentation suggests a brand new key will be introduced for 3.5.

This field is obsolete and will be removed in the future: This field will be removed in favour of a new dsf main key in v3.5 This field is exclusively maintained by DSF in SBC mode and/or by DWC. It is not available in standalone mode

chrishamm

@stuartofmt Are you looking for sbc.dsf.version? The sbc root key is missing in standalone mode.

stuartofmt

@chrishamm said in 3.5.4-beta.4 "state.dsfVersion" new location:

@stuartofmt Are you looking for sbc.dsf.version? The sbc root key is missing in standalone mode.

I had not seen sbc.dsf.version but thanks for pointing it out.

I would prefer to check just one version parameter. So I guess my real question is what is the usual order of precedence. In other words, which aspect firmware / dsf / dwc sets the minimum level for all.

I'm exclusively using rest api calls to interact with the printer

chrishamm

@stuartofmt Well, that version number is fine if you want to check the DSF version. In theory all versions (DWC/DSF/RRF) should be the same, else you get a warning message in 3.5 and later.

stuartofmt

@chrishamm

One version to rule them all! Perfect, thanks.