Hello,

I'm a college student working with a professor to build a client using Python packages PyIndi-client and Flask that will be capable of controlling hardware mounted to a telescope through http requests. The telescope will be receiving sequences of http requests to automatically take observations through the whole night, so we are not going to be using Kstars or Ekos, or any other GUI. Our hardware is currently plugged in via USB to a raspberry pi 4, on which the client and indiserver are running.

The dust cover he chose to use is the Alnitak Remote Dust Cover, seen here: www.optecinc.com/astronomy/catalog/alnit...emote_dust_cover.htm
The alnitak driver I got from this page: indilib.org/devices/auxiliary/alnitak-flip-flat-flat-man.html, which says to start the indiserver with the driver indi_flipflat.

In the client, one of my methods for testing prints out all the connected device properties. The problem I am having is that the dust cover does not seem to have a property that controls whether the dust cover is open or not. It actually provides a property to control the flat light, which our dust cover doesn't have. Here is the printout:

(test) ubuntu@pi-1:~/client_test$ flask run
Connecting and waiting 1 sec
List of connected devices:
Flip Flat
List of Device Properties:
--Flip Flat
> CONNECTION
SWITCH:CONNECT(Connect)= On
SWITCH:DISCONNECT(Disconnect)= Off
> DRIVER_INFO
TEXT:DRIVER_NAME(Name)= Flip Flat
TEXT:DRIVER_EXEC(Exec)= indi_flipflat
TEXT:DRIVER_VERSION(Version)= 1.0
TEXT:DRIVER_INTERFACE(Interface)= 33792
> DEBUG
SWITCH:ENABLE(Enable)= Off
SWITCH:DISABLE(Disable)= On
> SIMULATION
SWITCH:ENABLE(Enable)= Off
SWITCH:DISABLE(Disable)= On
> CONFIG_PROCESS
SWITCH:CONFIG_LOAD(Load)= Off
SWITCH:CONFIG_SAVE(Save)= Off
SWITCH:CONFIG_DEFAULT(Default)= Off
SWITCH:CONFIG_PURGE(Purge)= Off
> POLLING_PERIOD
NUMBER:PERIOD_MS(Period (ms))= 1000.0
> CONNECTION_MODE
SWITCH:CONNECTION_SERIAL(Serial)= On
> DEVICE_PORT
TEXT:PORT(Port)= /dev/ttyUSB0
> DEVICE_BAUD_RATE
SWITCH:9600(9600)= On
SWITCH:19200(19200)= Off
SWITCH:38400(38400)= Off
SWITCH:57600(57600)= Off
SWITCH:115200(115200)= Off
SWITCH:230400(230400)= Off
> DEVICE_AUTO_SEARCH
SWITCH:INDI_ENABLED(Enabled)= On
SWITCH:INDI_DISABLED(Disabled)= Off
> DEVICE_PORT_SCAN
SWITCH:Scan Ports(Scan Ports)= Off
> SYSTEM_PORTS
SWITCH:/dev/ttyUSB0(/dev/ttyUSB0)= Off
> ACTIVE_DEVICES
TEXT:ACTIVE_FILTER(Filter)= Filter Simulator
> FLAT_LIGHT_CONTROL
SWITCH:FLAT_LIGHT_ON(On)= Off
SWITCH:FLAT_LIGHT_OFF(Off)= Off
> FLAT_LIGHT_INTENSITY
NUMBER:FLAT_LIGHT_INTENSITY_VALUE(Value)= 0.0
> Status
TEXT:Cover(Cover)= Not Open/Closed
TEXT:Light(Light)= Off
TEXT:Motor(Motor)= Stopped
> Firmware
TEXT:Version(Version)= 200
Flip Flat: CONNECTION property defined
* Serving Flask app "condor-flask-client"

See? Nothing about the actual dust cover.

Out of curiosity, I wrote a method to change the status of the non-existent flat light. Strangely enough, the dust cover reported back a success, although nothing changed about the dust cover in real life.

So there's my dilemma. What am I doing wrong? I would really appreciate if anyone could shed some light on this.

That's a different device, so needs different driver (not written yet). It's probably a simple change. What's the VID:PID of this device?

The VID:PID of our dust cover is 0403:6001, obtained by using lsusb.

Ok turn on verbose logging and find out what's the response to the >P000 command which returns the product ID.

You can also use minicom directly to communicate wit the device and type in the above command.. so anyway, report back the product id as returned.

I'm sorry, I'm still fairly new to linux, and I'm still in the process of learning to use it proficiently (have to start somewhere). Your previous reply is confusing to me. Isn't the Product ID just the second part of the pair of values returned by lsusb? So the PID of our dust cover would be 6003 if that's the case. I've also never used minicom before (I actually never heard of it until you mentioned it in your comment) so I'll have to learn to use it before replying with the product ID. Again, sorry that I'm such a novice.

No this is like model id returned by the device itself, it's not related to libusb. The libusb VID:PID are just generic FTDI chipsets IDs and not related to the actual device internally. So you either need to enable verbose logging before you connect and then check to see what the response is, or use minicom and type that command directly to get the response. Once I know the response, I can modify the driver to take that into consideration.

Does this help?

[ 4.837184] usb 1-1.1.3: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 6.00
[ 4.845963] usb 1-1.1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 4.853574] usb 1-1.1.3: Product: Flat Fielder
[ 4.858086] usb 1-1.1.3: Manufacturer: Optec Inc.
[ 4.862859] usb 1-1.1.3: SerialNumber: A844DJ8W

Hey Jasem,

So I have been trying to get the product ID with the >P000 command you mentioned earlier. I have been looking for references to the >P000 command, and how to use it, but I haven't found any documentation anywhere. Is there a place where there are more detailed instructions on these commands or how to use them? I've found that it's easy to enable verbose logging when I run the indiserver (using -vvv) but when it's running there doesn't seem to be a way to issue commands to it from the command line, because the command line won't take arguments until the indiserver is stopped. Again, we aren't using Ekos due to the nature of our client. We have not tried to use minicom so that may be why we are still stuck. Using minicom also seems strange to me because it is used as a serial port communications program but our devices are connected by serial bus, not serial ports. Our dust cover is connected by USB to the CCD we are using, which in turn is connected by USB to the raspberry pi where our client and indiserver are running. Would either of those details make a difference when using minicom? Thanks.

AFAIK, Alnitak uses a USB to serial chipset like all their other products so it gets assigned a serial port. You have two options:
1. Enable verbose logging in Ekos (check my signature) for Auxiliary devices and then read from the log the response to >P000 command.
2. Use minicom and execute the command there directly and read the output.

Hey Jasem, finally got it to work. The command returned *P98

Thanks for the info, please git pull and test. You should see a new driver "Alnitak Remote Dust Cover".

Hello again Jasem,

I did git pull from the indi repo and tested by running $ indiserver indi_flipflat

This time around, the output from my flask app shows this:
List of Device Properties:
--Flip Flat
> CONNECTION
SWITCH:CONNECT(Connect)= Off
SWITCH:DISCONNECT(Disconnect)= On
> DRIVER_INFO
TEXT:DRIVER_NAME(Name)= Flip Flat
TEXT:DRIVER_EXEC(Exec)= indi_flipflat
TEXT:DRIVER_VERSION(Version)= 1.1
TEXT:DRIVER_INTERFACE(Interface)= 33792
> DEBUG
SWITCH:ENABLE(Enable)= Off
SWITCH:DISABLE(Disable)= On
> SIMULATION
SWITCH:ENABLE(Enable)= Off
SWITCH:DISABLE(Disable)= On
> CONFIG_PROCESS
SWITCH:CONFIG_LOAD(Load)= Off
SWITCH:CONFIG_SAVE(Save)= Off
SWITCH:CONFIG_DEFAULT(Default)= Off
SWITCH:CONFIG_PURGE(Purge)= Off
> POLLING_PERIOD
NUMBER:PERIOD_MS(Period (ms))= 1000.0
> CONNECTION_MODE
SWITCH:CONNECTION_SERIAL(Serial)= On
> DEVICE_PORT
TEXT:PORT(Port)= /dev/ttyUSB0
> DEVICE_BAUD_RATE
SWITCH:9600(9600)= On
SWITCH:19200(19200)= Off
SWITCH:38400(38400)= Off
SWITCH:57600(57600)= Off
SWITCH:115200(115200)= Off
SWITCH:230400(230400)= Off
> DEVICE_AUTO_SEARCH
SWITCH:INDI_ENABLED(Enabled)= On
SWITCH:INDI_DISABLED(Disabled)= Off
> DEVICE_PORT_SCAN
SWITCH:Scan Ports(Scan Ports)= Off
> SYSTEM_PORTS
SWITCH:/dev/ttyUSB0(/dev/ttyUSB0)= Off
> ACTIVE_DEVICES
TEXT:ACTIVE_FILTER(Filter)= Filter Simulator

Note that the flat light property from before is not shown, which stands to reason, but there are no properties relating to the dust cap itself.