×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

well this has put the cat amongst the pidgeons - if it works

  • Posts: 407
  • Thank you received: 74
Hi Patrick,

I had tried that DSLR Ascom a while back - didn't work for me with APT :-)

The Disconnection error also occurs when using the Synscan App (windows) with Remote Ascom. Its onl a problem in that it nearly does a deadly embrace and you cannot do anything else.

Love CDC and have been using it for years :-)
RPI3 Ubuntu 16.04 / AMD desktop Kstars under Ubuntu 16.04 Mounts :azeq6 ,SWAZGoTo

RPI3 Fedora testing out on AMD desktop Fedpra 28 - running kstars 2.9.4 , Indilib 1.7.4 ?????
5 years 1 month ago #35348

Please Log in or Create an account to join the conversation.

  • Posts: 3
  • Thank you received: 0
Hello Radek,
reading your comment on MQTT driver for INDI, I had to register for this Forum!
I am looking for exactly such a driver!
In times of IoT and home automation, it would totally make sense to have some kind of gateway between INDI and MQTT.
My use case would be (for a starter):
A weather station sends its data via MQTT -> (configurable) INDI Driver makes necessary data available to observatory.

This way, no need to write a specific driver for each and every weather station, just have it send its data via MQTT and the observatory could subscribe to the relevant topics.

Unfortunately, I don't have enough coding experience to write something like this - but definitely willing to test such a driver.

Greetings,
Herwig
astrohd.de
clear skies,

Herwig
astrohd.de
5 years 1 month ago #35400

Please Log in or Create an account to join the conversation.

  • Posts: 3
  • Thank you received: 0
Hi stash,

do you have by chance any more info on this ascom wrapper for MQTT, perhaps even a link?

Thank you,

Herwig
astrohd.de
clear skies,

Herwig
astrohd.de
5 years 1 month ago #35401

Please Log in or Create an account to join the conversation.

  • Posts: 983
  • Thank you received: 375
Hi Herwig, welcome to INDI forum!
There are various use cases for INDI-MQTT. What I assumed in my project so far is that INDI publishes status of devices over MQTT. What you're describing is INDI subscribes to MQTT messages from other devices.
As the matter of fact both are feasible but making it work both ways requires lots of work. If community thinks it is worthwhile, a major project should be defined with several contributors. As for now we can make a small step for INDI but giant leap for mankind. Some day we can get there. In the meantime you can use existing weather drivers, including wunderground - just publish your weather data to wunderground and pull them back with the driver.

All the best!
5 years 1 month ago #35419

Please Log in or Create an account to join the conversation.

  • Posts: 407
  • Thank you received: 74
Hi ,

This is not the orig paper which i cant find. I never found the wrapper just references to it :-)

link is here www.google.co.uk/url?sa=t&rct=j&q=&esrc=...Ap_BkIHh-O3IEgw9Ortk

Google IBM cognative telescope network and ibm telescope commander might throw some info
RPI3 Ubuntu 16.04 / AMD desktop Kstars under Ubuntu 16.04 Mounts :azeq6 ,SWAZGoTo

RPI3 Fedora testing out on AMD desktop Fedpra 28 - running kstars 2.9.4 , Indilib 1.7.4 ?????
The following user(s) said Thank You: Radek Kaczorek
Last edit: 5 years 1 month ago by Clive Stachon.
5 years 1 month ago #35457

Please Log in or Create an account to join the conversation.

  • Posts: 554
  • Thank you received: 138
The origins of remote ASCOM are some years ago when we had an ill fated project - ASCOM-X. This was trying to do the same thing - provide a framework for allowing ASCOM style operation remotely and over multiple operating systems.
At its core an ASCOM driver is very simple. Some code withat implements a defined set of properties and methods. This maps well into a text based protocol:
> get RightAscension
< get RightAscension 12.345
> slew 5.432, 15.678
< OK
Other protocols could be defined :)
So, being someone who tends to move into coding too soon, I implemented something like this - and it worked.
But I made one fatal error. I used UDP as the transport method.
It could have been anything - TCP/IP, files, RS232, fax, messengers with cleft sticks, pigeons, the telegraph - anything that can transport text messages.
Unfortunately everyone who commented focussed on the folly of using UDP, with vast explanations of how it couldn't possible work, especially in Windows. This in spite of this all being developed on Windows.

I gave up, and the whole thing went into limbo until a couple of years ago when some people developed what you now see. What I think they learnt was that public development of this sort of thing doesn't work.
It could hook into all sorts of other systems, the idea of hooking into INDI looks good. Users with Windows PCs running one of the mainstream astronomy applications could have a RasbPi on their scope that handled all the scope managment, guiding, image acquisition and so on. Another pi to handle the dome and weather.

Then, when they see how easy INDI and the linux system is, they will become converts.
The following user(s) said Thank You: Eric
5 years 1 month ago #35487

Please Log in or Create an account to join the conversation.

  • Posts: 407
  • Thank you received: 74
:ohmy: Mr Ascom - honoured we are :-)

Its funny you saying about UDP as Sky Watcher uses UDP for their connections to the mount from Synscan App and it works.

The UDP problem is lakin to the RS232 hand shaking options DTR/DTS,xon/xoff etc - they were there when hardware was slow and unreliable now things have changed we nearly all just use tx,rx and Gnd. Personally I think "they" were wrong are you were right , UDP would have worked well - but thats "water under bridge".

I guess people get to emotionally tied to their "baby".

IMHO Ascom Alpaca could be a way forward in joining the best from each world as it seems easier to interact with and all we need ,LOL, is a simple translation bridge,
I say this as neither Indi or Ascom will ,in my view, adopt each others protocol's.
RPI3 Ubuntu 16.04 / AMD desktop Kstars under Ubuntu 16.04 Mounts :azeq6 ,SWAZGoTo

RPI3 Fedora testing out on AMD desktop Fedpra 28 - running kstars 2.9.4 , Indilib 1.7.4 ?????
5 years 1 month ago #35506

Please Log in or Create an account to join the conversation.

  • Posts: 33
  • Thank you received: 5
I went through the published Alpaca spec and without trying to be catty it still follows the ASCOM protocol restrictions, which I'm having a hard time buying into in this day and age. Other than that, if the instrument manufacturers buy into Alpaca (I see no reason they would not, I would in a heart beat) when we finely have OS independent instruments.

I haven't used it, but I understand there is a windows sever that uses ASCOM drivers and talks to INDI? If so, that should be a good start on an Alpaca interface for INDI(?).

Back in about 2011 I floated (on this forum I think) an idea for embedded INDI, which is the same basic concept. I'll show my lack of INDI depth, but I thought INDI servers needed to be daisy chained. If that isn't true or there could be a "combiner," that is a way to talk to multiple servers from a single point, the INDI server could move into the instrument now... hint, hint.

Anyway, I've been on board with the web based instrument concept for a very long time... glad to see it finally happening.

2 cents from the cheap seats...
5 years 1 week ago #36618

Please Log in or Create an account to join the conversation.

  • Posts: 407
  • Thank you received: 74
"I went through the published Alpaca spec and without trying to be catty it still follows the ASCOM protocol restrictions" - are you talking Ascom std message protocol or something else - Indi has its own "message protocol std" all client servers have too in my experience?

Having done some testing and even attempted Linux to Windows Ascom Alpaca connection ( it connected no problem) the biggest problem is I hate the Web interface its all over the place and too complicated ,IMHO, for "average Joe". You are expected to know/remember too much IP info and REST is far to talkative IMO (e.g. must I keep getting the temperature - Look at Wireshark output ). Why not use the MQTT model where the user only has to know the Broker IP name or address everything else is Topic and levels - e.g. Main Topic Camera - SiteA/Camera/DSLR/Canon/100d , SiteA/guidingCamera/CCD/ZWO/120mc and we are at least going to be talking - even if the nitty gritty has still to be set up - e.g. Gain,Exposure etc. Maybe RK's MQTT admin program will do all this automatically :-)

Surely its not too much today to expect software to "poll" for servers/clients to find out Camera1, Telescope2 ,ServerHub1 etc on SITEA at the press of a single button ( I am not talking DNS here) - at least on a home network (how many will use it across the Internet) and NOT expect a user to set up lots of connection variables (I am not even talking about device variables here just Alpaca) e.g. Device numbers,driver numbers. And those little POP UPS,e.g. chooser and Remote Client windows - you dont see because they are hidden and you didn't notice your task bar just added another widget icon - appalling IMO - Most user unfriendly. OK its early days for Ascom Alpaca and Indi have Serial Assistant etc so maybe there is hope.

Having said that the Ascom Remote Client works very well for existing software without changes(just confusing set up's) - so PHD,APT,EQMOD,CDC (in real full blown Alpaca mode) etc all work (up to now in my testing at least ) and I was able to run software across 3 Windows PC's - 2 Mini's and a desktop. - same as Indi. Peter Wilson Well done :-)

So the jury is still out but IMO both Indi and Ascom still need to make their software more user friendly so that set up is semi automatic and less complicated (hidden) without IP knowledge IMHO. I.E remove the initial steep learning curve so I don't hear "that's doing my head in" or "mind blowing" etc from users :-)

Its not knocking all the hard work developers do (thank you) but maybe the direction/priorities and remembering most users are not (and should not need to be) IT savvy developers :-)

Of course if all the manufactures got together and had a OS Independent standard message protocol that would be a hallelujah moment (wont happen) . :-)

I will now get back under my stone and wait for the flack - LOL
RPI3 Ubuntu 16.04 / AMD desktop Kstars under Ubuntu 16.04 Mounts :azeq6 ,SWAZGoTo

RPI3 Fedora testing out on AMD desktop Fedpra 28 - running kstars 2.9.4 , Indilib 1.7.4 ?????
5 years 1 week ago #36622

Please Log in or Create an account to join the conversation.

  • Posts: 33
  • Thank you received: 5
Stash, No flack from me, I agree.

Thx,
5 years 1 week ago #36632

Please Log in or Create an account to join the conversation.

  • Posts: 4
  • Thank you received: 1
Hi all,

Some of you may be interested in this :

Pylpaca (ASCOM Alpaca API micro-framework for Python)
github.com/T0T4R4/pylpaca

I'm smiling a bit when I see people questioning of the performances of a REST API versus an XML based one...

I would also argue that questioning the "network load" becomes obsolete these days.

ASCOM is indeed very easy to use, and even to create drivers on. I've gone through both ASCOM and INDI, and the only thing I can say is that Alpaca brings ASCOM to the linux world, which was the major drawback in the past.

As far as I read some people here are still playing in the Linux-vs-Windows primary school courtyard thing. So retrograd way of thinking...

If indeed some could build a layer on INDI to follow the Alpaca API definitions, then it would make the life easy for everyone, if not it'll be uip to the software makers like Patrick to talk both layers, which is sad...

Cheers

T0t4r4.
The following user(s) said Thank You: Chris Rowland
5 years 3 days ago #36962

Please Log in or Create an account to join the conversation.

  • Posts: 4
  • Thank you received: 1
[Attention Flak]

Hi @Stash,

The ASCOM REST Server and the Alpaca API are two completely different thing.

The Alpaca API are specifications only, and purely written with openess in mind in order to allow the spread of the ASCOM protocol cross-platform.
In that mindset, the API has been VERY well defined , although *you* may think it's a bit verbose, REST is the most spread approach used in the IT industry these days when building web APIs.
It's simple, easy to build and to query.
Literally NO-ONE gives a damn about network traffic these days (as in... people open wireshark maybe what... once a year?) whether it's at home (2000mbps) , or the web (100+mpbs home connection, 500mbps work connection).

The ASCOM Rest server, on the other hand, was just released in January (so alpha alpha stage), but is not something that *users* will see. This has to be configured once and only, and after that, we forget about it.
Users talk to the devices via the API, that's it. Compared to setting up Indi servers / drivers, it's damned easy.

You mightalso have forgotten the Alpaca Management API, which I think makes the use of the rest server interface obsolete.
That said, the ASCOM rest server UI is minimalist and perfect for what it needs to be doing.

The only missing bit is that it should be running as a windows service, if possible, and i've got to check with Peter if that's in the pipeline as it's not rocket science to make it so. There is one nuget package which does it all.

T0t4r4
Last edit: 5 years 3 days ago by Mathieu Clerte.
5 years 3 days ago #36965

Please Log in or Create an account to join the conversation.

Time to create page: 1.181 seconds