Add INDIGO Support

[rumengb]

Please add INDIGO support: http://www.indigo-astronomy.org If you need any information and help please let us know.

[mworion]

Hi rumengb,

Would be happy to switch from INDI to INDIGO as INDIGO is backward compatible to INDI. I need a python only implementation for an INDIGO client. If there is one available, please let me know.

Michel

[polakovic]

Pls. check this: https://github.com/taxelrod/indigo_cffi

[mworion]

Hi Peter, already seen. But this is a python wrapper around the C++ implementation. Is this available on all platforms as binary wheel? In my case all should be installable with pip without having the need of starting a compiler (as it seldom succeeds on the users base). In INDI it is not the case as I did a pure python implementation of INDI. And that's not a good point doing that for many frameworks. Any ideas about this ? Michel

[Ruediger3]

I would also deeply appreciate native INDIGO support, since I am running:

-Unihedron SQM -Pegasus UPBv2 -MGPBox

via INDIGO

[mworion]

Rüdiger,

Indigo normally should be backwards compatible with Indi in a degradation mode. So normally you should see the devices.

Michel

[rumengb]

Hi the trouble is that INDI has no standard properties for AUX devices and basically every paricular auxiliary device has its own set of properties. On the other hand we have standard properties for all classes of auxiliary devices: Powerboxes, general purpose input output devices devices etc in Indigo. On the other hand INDI changes the standard property set so we can not maintain the property mapping even for more standard devices like Domes for example. In other words nowadays compatibility is maintained on protocol level but not on property and device level. Which means that devices may not be seen if they are not classified as we classify them (interface item of the info property), and may not have the same properties at all. The good news is that you can use your INDI code unchanged to communicate with INDIGO, but only relay on different properties for those devices...

Rumen

On Fri, May 22, 2020, 5:09 PM Michael notifications@github.com wrote:

Rüdiger,

Indigo normally should be backwards compatible with Indi in a degradation mode. So normally you should see the devices.

Michel

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mworion/MountWizzard4/issues/25#issuecomment-632712673, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE5EZBKAH2KITZFSW5YKWD3RS2BS5ANCNFSM4MYECIVQ .

[polakovic]

Hi Michel, the main difference between INDI and INDIGO is, that while an INDI the driver is always a separate process talking to the client side with a quite ineffective XML protocol over pipes or sockets, INDIGO driver is a dynamic library loaded into the server (or client) process, connected to a software bus and called at procedure execution speed. Pipe or network protocol is implemented by protocol adapter connected to the same bus. This gives INDIGO a performance gain (about 1000x faster than INDI) and also higher flexibility (multiple network protocols, etc).

So if you want to use FULL INDIGO, you need full bus implementation and I doubt it is possible to do in python effectively. That's why INDIGO_CFFI is just python wrapper over native C code. Full binary packages are available for 32/64 bit Intel/ARM Linux and for macOS. Client part of the library (no drivers) is also available for Windows. If it is sufficient, you probably can bundle it with a python code and that's it.

If you want just talk to remote INDIGO server, you may use some protocol client implementation. We have one in JavaScript (a part of webGUI) and one in C# (a part of ASCOM bridge), both talking JSON protocol. It is quite straightforward, you can find source code here:

https://github.com/indigo-astronomy/indigo/blob/master/indigo_server/resource/indigo.js (single server access)

https://github.com/indigo-astronomy/indigo_ascom/blob/master/indigo/Indigo.cs (multiple server access with bonjour discovery)

Unfortunately, we don't have such code in python, because nobody from our team develops in python. But you may use also any INDI client, including that python one. INDIGO server will detect it and fall back to XML protocol v1.7 used by INDI. Nevertheless, the performance is degraded, specifically for BLOB transfer. If you know how to modify the code to speak XML protocol v2.0, it will improve performance (with 2.0 protocol only the URL is transferred instead of BLOB in BASE64 encoding and pulled by client when needed over http).

You can find protocols description here:

https://github.com/indigo-astronomy/indigo/blob/master/indigo_docs/PROTOCOLS.md

Another level of complexity is semantics of the properties as Rumen mentioned. But if you want to write your own python, it is not an issue.

Peter

[mworion]

Thanks, this helps in understanding. Adding the support in my python Indi implementation still keeps the problem of different properties. So that has to be addressed anyway. But as result as a single person doing this beside work means another framework (not from protocol, but for each device the properties) to be maintained. This effort will kill me. No clue how to dress this. Somebody has to maintain the device properties on both sides in a table if they are not the same.

Michel

[rumengb]

Well, The thing is that INDIGO properties are not changing unlike INDI. We do not change properties. So maintaining INDIGO set will not be a problem. We were trying to maintain INDI - INDIGO mapping in the framework for some time until it became impossible. INDI properties are changing not only semantically, which is easily addressed, but some of them mutated to a different types (for example from number to switch) or changed the purpose of their items. So we had to invent complex mapping algorithms to maintain this and we gave up this effort. Bu the way this was one of the reasons INDIGO exists, INDI is maintained together with its fronted Ekos/Kstars and newer versions with Ekos can not work with older INDI and vice versa. Not speaking about third party products, and the results are in Pixinsight dumped INDI in favor of indigo. APT uses INDIGO not INDI. And several prominent professional observatories are using or migrating to INDIGO. So maintaining INDIGO will not be a big deal.

you say: "Somebody has to maintain the device properties on both sides in a table if they are not the same." it is not that easy. in the beginning we did so until INDI changed the type some standard properties and the meaning of their fields. Recently I got a report about INDIGO controlled domes not working with the new Ekos any more (but tey used to work) and I figured out that the dome interface was changed and properties can not be mapped at all. The property set changed. Which was addressed in Ekos immediately and made this change transparent to INDI/Ekos users but causing problems to the third party clients. And sure enough Ekos dome control stopped working with the older indi server. This is what we are trying to avoid in INDIGO. And this is why we can not maintain such a table :(

Rumen

[Ruediger3]

Hello All,

I have tried to connect Unihedron SQM, UPBv2 and MGPBox to MW4 via INDIGO, but I can state there are serious problems and it is not working. My findings:

1. Device can not be reconnected. You have to disconnect device in INDIGO in order to make it available in MW4 again after it was disabled.
2. SQM shows no data
3. UPBv2 shows no data

Conclusion: Either it is not compatible, or there are some issues to fix in MW4 side.

Thank you all!

Cheers Ruediger

[mworion]

Hi Rumen,

I would like to support INDIGO (at least in translating Properties) for important devices. I recognized for example, that the INDIGO Server show some strange DRIVER_INFO.DRIVER_INTERFACEnumbers. The PowerBox shows in my case 4489216 I would expect the interface for Switch / Observing conditions or at least AUX. INDIGO server does it for CCD for example right.

Same to SQM Unihedron driver.

Where is the trick ? Thanks in advance.

BTW: is there an easy way to find out if the Server is an INDIGO server (based on 1.7 protocol?)

Michel

[rumengb]

Hi Michel, and thank you!

4489216 is a decimal bit mask of the interfaces (device types), for AUX devices AUX bit is set and a bitmask of the particular features they have. So in this case 4489216 = INDIGO_INTERFACE_AUX_POWERBOX | INDIGO_INTERFACE_AUX_WEATHER, so this is most likely a Powerbox with temperature and humidity sensor. On the other hand non AUX devices have only one bit set. So if we have a CCD camera with st4 guider port, two separate devices will be presented with interfaces INDIGO_INTERFACE_CCD (decimal 2) and NDIGO_INTERFACE_GUIDER (decimal 4). See the definitions in indigo_bus.h:

/* Device interface (value should be used for INFO_DEVICE_INTERFACE_ITEM->text.value) / typedef enum { INDIGO_INTERFACE_MOUNT = (1 << 0), ///< Mount interface INDIGO_INTERFACE_CCD = (1 << 1), ///< CCD interface INDIGO_INTERFACE_GUIDER = (1 << 2), ///< Guider interface INDIGO_INTERFACE_FOCUSER = (1 << 3), ///< Focuser interface INDIGO_INTERFACE_WHEEL = (1 << 4), ///< Filter wheel interface INDIGO_INTERFACE_DOME = (1 << 5), ///< Dome interface INDIGO_INTERFACE_GPS = (1 << 6), ///< GPS interface INDIGO_INTERFACE_AO = (1 << 8), ///< Adaptive Optics Interface INDIGO_INTERFACE_ROTATOR = (1 << 12), ///< Rotator interface INDIGO_INTERFACE_AGENT = (1 << 14), ///< Agent interface INDIGO_INTERFACE_AUX = (1 << 15), ///< Auxiliary interface INDIGO_INTERFACE_AUX_JOYSTICK = (1 << 15) | (1 << 16), ///< Joystick AUX interface INDIGO_INTERFACE_AUX_SHUTTER = (1 << 15) | (1 << 17), ///< Shutter AUX interface INDIGO_INTERFACE_AUX_POWERBOX = (1 << 15) | (1 << 18), ///< Powerbox AUX interface INDIGO_INTERFACE_AUX_SQM = (1 << 15) | (1 << 19), ///< SQM AUX interface INDIGO_INTERFACE_AUX_DUSTCAP = (1 << 15) | (1 << 20), ///< Dust Cap AUX Interface INDIGO_INTERFACE_AUX_LIGHTBOX = (1 << 15) | (1 << 21), ///< Light Box AUX Interface INDIGO_INTERFACE_AUX_WEATHER = (1 << 15) | (1 << 22), ///< Weather AUX interface INDIGO_INTERFACE_AUX_GPIO = (1 << 15) | (1 << 23) ///< General purpose IO AUX interface } indigo_device_interface;

Some additional confusion may be caused by the type of the DRIVER_INFO.DRIVER_INTERFACE type which is text. So you have to convert it to 32bit integer and check individual bits. Well this is something I do not like but for the sake of INDI compatibility we had to adopt it.

I hope this answers your question :) If you have any other questions please feel free to ask.

Regards, Rumen

On Sat, Jul 18, 2020 at 5:59 PM Michael notifications@github.com wrote:

Hi Rumen,

I would like to support INDIGO (at least in translating Properties) for important devices. I recognized for example, that the INDIGO Server show some strange DRIVER_INFO.DRIVER_INTERFACEnumbers. The PowerBox shows in my case 4489216 I would expect the interface for Switch / Observing conditions or at least AUX. INDIGO server does it for CCD for example right.

Same to SQM Unihedron driver.

Where is the trick ? Thanks in advance.

Michel

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mworion/MountWizzard4/issues/25#issuecomment-660495537, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE5EZBOWSA3DS4UL7U6MPJTR4G2DVANCNFSM4MYECIVQ .

[mworion]

Hi Rumen,

Pegasus UPB, UPBv2, UniHedron SQR (and Camera..) work now. Just with the pity to translate the Properties. So I never could support all devices.

Closing this so far. Thanks for the support. I'll coma back if I move forward.

Michel

[rumengb]

What do you mean by translate the properties? you should not support any particular device but a class of devices. depending on the interface.

[mworion]

Rumen,

I raised the question in INDI to standardize the Properties and Elements addressed. If so does it make some sense to sync it to the INDIGO list as well ? Even though it may be different name for compatibility reasons, but finally a 1:1 list.

Michel

[rumengb]

Hi Michael, The problem is that we have been doing this for years. I mean following the changes in INDI properties and we have a translation table (see https://github.com/indigo-astronomy/indigo/blob/master/indigo_libs/indigo_version.c). The trouble is that INDI properties are so mutable not only in semantically but they change the types and items which made it impossible to follow and map any more. By the way this is one of the reasons we started indigo. Peter was one of the core INDI developers and I was a developer too. We were trying to make properties immutable but the problem is that nobody was on our side and this makes it next to impossible to maintain a third party product that uses INDI. So the truth is that if Jasem needs some property change for Ekos he changes INDI without any notice and all of the sudden all existing software stops working. Even Ekos is incompatible with the previous versions of INDI. Even more what I see in indi is that they started to change property names from capital plus underscore notation to camel case (like SOME_PROPERTY -> SomeProperty). On the other hand in INDIGO properties are immutable so (SOME_PROPERTY will always be SOME_PROPERTY and its meaning and existing items will will not change). In that copying some properties standardized in INDI is not an option for us. First because we already have some standatized properties which we can not change, as many products rely on them. Second because there is no such thing as standard in INDI. Another problem is that there are basically no standard properties for auxiliary devices in INDI. Each driver provides its own set of properties for the same things. This makes indi incompatible with itself in some areas, most prominent being auxiliary devices. On the other hand we have a list of Standard indigo properties here https://github.com/indigo-astronomy/indigo/blob/master/indigo_libs/indigo/indigo_names.h , not well documented which is our fault but we have it, we can extend it but it is too late to change it as several major players on the market relay on it (Pixinsight, APT, Astro tools from CloudMakers etc) and several professional observatories that have their own proprietary clients... So we are open to standardizing some properties, but we are not willing to change or duplicate the ones that we have, but we can adopt the ones that we do not have. Nothing personal and nothing against INDI, it is just that we promised this to all our users and third party software providers. Does this make sense?

Rumen

On Tue, Jul 21, 2020 at 5:20 PM Michael notifications@github.com wrote:

Rumen,

I raised the question in INDI to standardize the Properties and Elements addressed. If so does it make some sense to sync it to the INDIGO list as well ? Even though it may be different name for compatibility reasons, but finally a 1:1 list.

Michel

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mworion/MountWizzard4/issues/25#issuecomment-661890256, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE5EZBKTDI34DHRLEJQSZPDR4WPY5ANCNFSM4MYECIVQ .

[rumengb]

I was trying to find on indi forum where is the topic about this issue but I was unable to find it. Can you please provide a link? Rumen