Hi, just finished writing a pure python package, indipydriver, with no dependencies, providing a set of classes which can be used to create an INDI driver. Docs available at https://indipydriver.readthedocs.io development at https://github.com/bernie-skipole/indipydriver and the package can be obtained from Pypi. Hope it’s of interest.
2 Likes
hi Bernard,
if I get it right, a client can interact with the device through an indipydriver driver exchanging INDI xml messages. And if you need to serve more than one device to a client then you use the Ipyserver.
I think I’m missing something, but is it possible to have an indipydriver running in an indiserver so that a client like Ekos can connect to both standard INDI drivers and indipydrivers?
Ferrante
Hi,
Nearly right, the IPyDriver class can have multiple devices - and will generate the xml on either stdin/stdout (which makes the driver compatible with indiserver) - or it can generate the xml on a port if the listen() method is called, which means a client can connect without any server - it connects directly to the driver, and hence its included devices.
The IPyServer class is used to connect multiple drivers, (not just devices) and combines their generated xml and serves it on a port - so again a client can connect. However IPyServer is limited to drivers created with this package only.
If you want to mix and match with other party drivers, then you would create an executable driver communicating on stdin/stdout (this driver, as stated above can have multiple devices), You could create as many of these executable drivers as you want - they are all essentially stand-alone drivers. They would act the same as any other driver in that case, and can be served by indiserver. The IPyServer class would not be used.
Hope that helps!!
Cheers Bernard
Hi Bernard,
As you said, I’d like to mix standard drivers on Ekos client with custom drivers in python.
I followed a different approach by chaining the python to the ekos server so that I don’t have to write an executable driver just for communication.
Here are the easy steps if someone wants to give it a try:
- Started Example 1 with pyServer on port 7625. Name of the device is Thermostat as in the example.
driver.listen("localhost", 7625)-
chained this python server with the Ekos one, like in the picture below:
-
Start Ekos.
Still I get an error in the log: Failed to connect to Thermostat. Please ensure device is connected and powered on.
But the temperature updates just fine.
Ferrante
1 Like
That’s really interesting, thanks for trying that out, very nice to see the Thermostat device displayed there!
The connection error log MAY be due to the Thermostat example not having standard properties which EKOS may expect it to have. See
https://www.indilib.org/developers/deveioper-manual/101-standard-properties.html
These are not part of the INDI protocol, but are a convention for naming commonly used properties, so the Thermostat could be given a CONNECTION switch property which it can respond to. I’ll try it out - though it may take me a while to get round to it.
Another point to note, as I’ve been finding a couple of bugs, I’ve been updating indipydriver, it’s now version 1.0.2 available on pypi, so if you’re doing any more experimenting it would be worth getting the latest.
1 Like
This is a very interesting project indeed! Thank you for working on it. I take it this is fully compatible with INDI protocol as is it now?
hi Bernard,
you were right about the connection standard property.
I added this switch to the Thermostat:
# create a switchvector so client can turn on/off connection
connectionswitchmember = SwitchMember(name="CONNECT", label="Connection",
membervalue=thermalcontrol.connectionswitch)
connectionswitchvector = SwitchVector( name="CONNECTION",
label="Connection Control",
group="Control",
perm="rw",
rule = "AtMostOne",
state="Ok",
switchmembers=[connectionswitchmember] )
And the error message is gone. But I know that managing connection properly is more than that: some property like connection itself and connection parameters should be available before connecting, while the others are visible only upon successful connection; more or less what updateparams() function does in the INDI [strike]protocl[/strike] convention.
@Jasem, if I got this right, by expanding this code to fully manage interaction with a client (connection, standard properties etc as Bernard wrote) and feeding the xml directly into indiserver via stdin/stdout (to avoid chaining) would allow the community of python developers to write drivers that interoperates with standard INDI drivers and client like Ekos to connect both drivers.
Hi Jasem,
Yes, unless I’ve made any mistakes, it is fully compatible with the INDI protocol.
Cheers
Bernard
Hi Ferrante,
That’s great, and yes - having defined a property it’s up to your own code to act on it as your instrument requires, and if you want compatibility with astronomical systems the standard properties should be considered.
(At the risk of teaching grandmother to suck eggs) - to make your driver executable would be to include the shebang line:
#!/usr/bin/python3
As the first line of your script, and then give your script executable permissions, and you should be able to pass it straight into indiserver just like any other driver. If you are doing this, then make sure there’s no ‘listen()’ method called in your script, so it’s not trying to use a port, but will use stdin/stdout as indiserver expects.
If there’s any suggestion you, or anyone else, can make to improve the docs at
https://indipydriver.readthedocs.io
I’d be interested, as it’s a rather involved subject, and making it easy to understand is a real necessity.
Cheers - Bernard