Version 4 seems to have broken INDI, ASCOM and Voyager

[xthestreams]

Trying to understand how version 4 has broken my existing setup. I lost all control of the dome through TheSkyX, INDI and Voyager to the point that I have tried downgrading to V3.3 which seems to have left me with a shutter that no longer works.

Any chance of fixing V4 so that it's backward compatible?

[NameOfTheDragon]

Firmware version 4.0.0 is now released. No issues were reported during alpha or beta testing so unfortunately it is now too late to reverse any changes without making things much worse for everyone.

In semantic versioning, a major version increment indicates a breaking change so this should be expected (the ASCOM driver has already been updated to accommodate the breaking changes). This was made transparently clear in the release notes

Making a breaking change is not something I did lightly but developers will need to change their implementation anyway to take advantage of the close-on-low-battery feature, which adds new commands and event messages to the protocol. If this is not needed then there's no reason to upgrade the firmware, but it is a much-requested feature and I imagine that most developers will want to support it. Since they will therefore be updating their code anyway, the breaking change should not be too much of an issue. My recommendation for developers would be to check the firmware version upon connecting and adapt accordingly. Compatibility will be maintained if the major version remains the same.

Note: version 4.0.0 of the ASCOM driver (currently in beta, see https://github.com/nexdome/ASCOM/releases/tag/4.0.0-beta.50) works with and requires version 4.0.0 of the firmware. Previous version of the driver will not work with it (again - that's what "breaking change" means).

[NameOfTheDragon]

I have tried downgrading to V3.3 which seems to have left me with a shutter that no longer works.

V4 has different settings which V3 will not be able to understand. In theory when the firmware detects a major version change, it should wipe the settings and reset everything to factory defaults, but if that hasn't worked for some reason you might need to do it manually. See https://github.com/nexdome/ASCOM/wiki/Reset-to-Factory-Defaults for how to do that.

The XBee radios are also a bit prone to getting into a stuck state where the firmware can't configure them correctly. To reset that, turn off both units fully (no USB connections, battery or power supply). Then power on the rotator and wait 20-30 seconds to give it a chance to initialize and select a clear channel, then power on the shutter.

[NameOfTheDragon]

Anecdotal evidence suggests there is now an updated INDI driver that supports v4 firmware.

[xthestreams]

Tim, thanks for the heads up and background - yes, I saw PK's problem and after my experience recommended he downgrade until this was sorted. Thankfully the community at INDIlib were able to rally around and get him back up and running quickly.

Something of a minor rant below, not a shot at the people who donate their time and expertise to open-source, more that in the case of Nexdome, I see this as a supported, vendor managed product and it's not clear from Nexdome's website if this firmware release is a sanctioned, supported and recommended update or if it's a (well-intentioned) fork.

Assuming this is vendor supported - I felt as though the term "breaking change" read more like "breaking news" (as in "this is unexpected, important, timely vs. this will break the stack).

Which leads me to my question?

Is there a way that changes like these (and the great progress they offer - if I get stuck with a shutter open due to dead battery on a rainy night again it will be too soon!) could be better synchronised with the ecosystem that relies on them?

Whilst it was and understandable that internal tables/values would be reset to factory to accomodate the new data structures, it wasn't clear that the protocol itself was not backward compatible (it was clear there were new features - but the reference to "changing some formatting to make it more consistent" wasn't super clear in terms of the implications).

Doing what I thought was reasonable due diligence, I read the V4.0 firmware protocol document when it was initially published I couldn't see anything that indicated existing commands and/or responses were deprecated or even exactly was was different between the two, short of doing a diff which seemed a little excessive for a protocol document where a "what's changed" might have made it obvious that firmware expecting a certain form of response would now no longer work.

I now run Voyager, but am not willing to risk testing V4, as much as I want the benefit of the great new features implemented, because I've lost faith in the integrity of the change management process - nothing on the Nexdome website mentions whether V4 is supported by their "partner" and I'm just not willing to mess about without a clear indication of what is and isn't supported.

From what I could tell, none of the ecosystem partners in the INDI or TheSkyX/X2 world had been informed of what changes to make to ensure compatibility (I can't speak for the ASCOM world, not my thing). Reading the Nexdome website I get the feeling that they aren't even aware of/promoting it, which makes me wonder if it's actually a dead-end or is it supported by the OEM?

Again (and a thousand times), I REALLY appreciate the work that goes into community improvements, this is not a shot at anyone - the Nexdome project is unique in that it's an interesting melange of open-source and private enterprise and it's to be expected that there are differing expectations of the discipline required when making changes for someone who's paid $10,000 for a dome (in Oz dollars/pesos)

[NameOfTheDragon]

I see this as a supported, vendor managed product and it's not clear from Nexdome's website if this firmware release is a sanctioned, supported and recommended update or if it's a (well-intentioned) fork.

@xthestreams

There are some big questions raised there and a GitHub issue is probably not the place to address them. There is a Facebook group and I'm more than happy to have the discussion there if you like.

This release is in the official NexDome-owned repository and is officially sanctioned.

Breaking Change is a term that is well-understood in the software community. We follow the rules of semantic versioning, so the version number always tells you what you can expect in terms of compatibility.

I'm going to close this issue now as the release is about to go public.