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
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
Read More...
Hi Jasem,
Yes, unless I've made any mistakes, it is fully compatible with the INDI protocol.
Cheers
Bernard
Read More...
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
www.indilib.org/developers/deveioper-man...dard-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.
Read More...
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
Read More...
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 indipydriver.readthedocs.io development at github.com/bernie-skipole/indipydriver and the package can be obtained from Pypi. Hope it's of interest.
Read More...
The indi protocol does allow blobs to be enabled/disabled, - normally on the indiserver port, giving the option of using an out of band solution. I've implemented this by sending the appropriate enable/disable command from the client via MQTT, and applying it at the remote end. So if disabled (the default) blobs will not be published to MQTT.
Read More...
Tried ok with blobs generated by simulated telescope/ccd, but not specifically tested large blobs for size. It's on my list to create test drivers to exercise the package, so I'll bear that in mind, thanks. I did find when reading an input stream in Python I got asyncio.LimitOverrunError exceptions so I read data in chunks of 32K at a time, but that had nothing to do with mqtt.
Read More...
Hi, just completed a Python project sending INDI protocol over MQTT, and storing data to redis, see
indi-mr.readthedocs.io
, together with a web client that displays the redis stored data allowing control of the attached instruments. The web client is documented at
indiredis.readthedocs.io
So far only tested with simulated drivers, I'd be interested in any feedback from anyone who cares to try them out.
Read More...