Not working in NINA

[Antiath]

NINA doesn't work with your ASCOM driver. It can connect and open the cover fine. But after asking NINA to open the cover, it times out, preventing me from closing the cover.

I ran the driver along with NINA in Visual Studio to investigate this and I think I know what happens. When lauching the driver, NINA has the switch defaulted to Off and the cover is closed by default of course. All is well for now. When activating the switch to open the cover, it does so and NINA starts polling the GetSwitchValue method and it expects it to return a 1 when the switch is ON ( i.e cover open). Your driver outputs the opposite. It happens here :

     public double GetSwitchValue(short id)
        {
            Validate("GetSwitchValue", id);
            tl.LogMessage("GetSwitchValue", $"GetSwitchValue({id}) - not implemented");
            return QueryDeviceState() ? 1.0 : 0.0;
        }

So the solution is simple :
return QueryDeviceState() ? 0.0 : 1.0;
and also
internal static string traceStateDefault = "true";

Maybe a switch driver is not the best option for this application.
Personnaly I would have used a Flatplanel template for the driver, instead of a switch. Even if you don't have an actual flat panel in the cover, the template provides the methods for the motorised part. So you can just leave the flat side in the code and just implement the motor part.
Also I already have a power box occupying the switch part of NINA, so it's not helpful to have to change driver just to move the cover.

[jlecomte]

@Antiath I have been using my driver and my device in NINA for well over a year (totaling about 50 nights) and it has worked very reliably. Others have done the same.

QueryDeviceState() returns true if the cover is open, and false otherwise, which means that GetSwitchValue() will return 1.0 if the cover is open, and 0.0 otherwise. That is the expected behavior.

[Antiath]

Ah yes my bad, ths issue was with the firmware. I had to modify it a bit to accomodate my servomotor who was weirdly turning the opposite way. And I forgot to check change the state variable accordingly to match this. That is corrected and working as expected now. Case closed.

Nevertheless I will probably reuse the code for and port it to a different driver