I'm disappointed in the standardization of INDI. I found now totally 4 standardization problems between library 1.2.0 (Linux) and wINDI (MSWindows) while trying to connect to the telescope simulators. To activated the scope simulators, I gave the following commands to the server:

SendMessage('<newSwitchVector device="'+INDI_telescope_name+'" name="CONNECTION"> <oneSwitch name="CONNECT">On</oneSwitch> </newSwitchVector>'); {connect to telescope}
SendMessage('<newSwitchVector device="'+INDI_telescope_name+'" name="ON_COORD_SET"> <oneSwitch name="TRACK">On</oneSwitch> </newSwitchVector>');{telescope tracking on}

.I get the following responses:
Linux INDI 1.2.0:
<setSwitchVector device="Telescope Simulator" name="CONNECTION" state="Ok" timeout="60" timestamp="2016-06-11T22:41:56">'#10' <oneSwitch name="CONNECT">'#10'On'#10' </oneSwitch>'#10' <oneSwitch name="DISCONNECT">'#10'Off'#10' </oneSwitch>'#10'</setSwitchVector>

wINDI:
<defSwitchVector device='ScopeSim Telescope' name='CONNECTION' label='Connection' group='Main Control' state='Idle' perm='rw' rule='OneOfMany' timeout='0' timestamp='2016-06-11T22:58:00.6'>
<defSwitch name='CONNECT' label='Connect'>Off</defSwitch>
<defSwitch name='DISCONNECT' label='Disconnect'>On</defSwitch>

Maybe I make an judgement mistake or crucial mistake, but I conclude that four things are differently:
1) Single versus double apostrophe
2) <defSwitchVecto versus <setSwitchVector
3) <oneSwitch name="CONNECT">'#10'On'#10' </oneSwitch> versus <defSwitch name='CONNECT' label='Connect'>Off</defSwitch>
4) And finally line feed characters in Linux. requiring a trim commando.


Can anybody comment, if I'm wrong???

I have Ekos running and the telescope simulator with the command: indiserver indi_simulator_telescope. For wINDI I use the ASCOM simulator for NET.

Kubunti isn't a very pleasant release for me. Resizing gives a black screen requiring a restart (in VMWare). Application Plasma crashes regularly. Responsiveness is poor. Windows popup too slow.

I never tried the VM in VMWare, it runs fine in Oracle's VirtualBox (which is free). The #10 is probably the CR character from Linux. You should use a proper XML parser which would take care of all these issues including single vs. double apostrophes.

Not sure about wINDI sending defXXX, these should be sent upon initial connection with the server.

Hi, what's wrong with these responses?
1 & 4) It is XML based protocol, you can use both single and double apostrophe and be prepared for different formating.
2 & 3) defXXXVector redefines property while setXXXVector just changes value. In this particular case is defXXXVector probably redundant, but you should be prepared to receive it anytime and for any reason. It semantical difference and has nothing to do with INDI standardisation. As far as I know any INDI client can talk to wINDI server now.

Peter

Peter,
First thanks for providing wINDI. It is a great help starting to understand INDI.

XML is totally new for me. I prefer to build my own code rather then using an XML parser.

I agree the W3 standards allows single and double apostrophe, but why this variation? In Pascal the single apostrophe defines the beginning of a string so is cumbersome to process.

I try to find out if the telescope driver is connected. With respect to point 3), this is what I find in the developers manual:
INDI standard properties:
Name: CONNECTION
Type: Switch
Members: CONNECT ( Establish connection to device) DISCONNECT ( Disconnect device)

Compared with the responses:
Response library 1.2.0
<setSwitchVector
device="Telescope Simulator"
name="CONNECTION"
state="Ok"
timeout="60"
timestamp="2016-06-11T22:41:56">'#10'
<oneSwitch name="CONNECT">'#10'On'#10' </oneSwitch>'#10'
<oneSwitch name="DISCONNECT">'#10'Off'#10' </oneSwitch>'#10
'</setSwitchVector>


Response wINDI:
<defSwitchVector
device='ScopeSim Telescope'
name='CONNECTION'
label='Connection'
group='Main Control'
state='Idle'
perm='rw'
rule='OneOfMany'
timeout='0' timestamp='2016-06-11T22:58:00.6'>
<defSwitch name='CONNECT' label='Connect'>Off</defSwitch>
<defSwitch name='DISCONNECT' label='Disconnect'>On</defSwitch>
</defSwitchVector>

wINDI
<defSwitch name='CONNECT' label='Connect'>Off</defSwitch>

equals

<defSwitch>
<name>'CONNECT' </name>
<label> 'Connect' </label>
Off
</defSwitch>

Library 1.2.0
<oneSwitch name="CONNECT">'#10'On'#10' </oneSwitch>'#10'

equals

<oneSwitch>
<name>"CONNECT"</name>
On
</oneSwitch>

So one use defSwitch and the other oneSwitch. Look like I have to make flexible code around the word Switch. So it is difficult to check if the connection is on. Why not simply connection="On" ??

For Knro,
VMWare has been very reliable for me, running several Linux virtual machines. It must be Kubuntu.


Han

Hi Han, oneSwitch is nested into setSwitchVector and defSwitch is nested into defSwitchVector, it is correct. In case of INDI 1.2 value of CONNECTION property is set, in case of wINDI it is (among other) redefined, but it is a semantical difference.

I think that it is a bad idea anyway, but if you want to write your own XML parser, you have to implement it with its full complexity. You can't expect that servers will use some subset understood by your client or to produce char-by-char identical output.

Peter

Peter, wait...

Look at this topic INDI, new in the HNSKY planetarium program

Oleg, what exactly do you mean? Peter

This topic is a descendant of INDI, new in the HNSKY planetarium program , because Han can't solve the problem with INDI in his software HNSKY for LINUX

That I understand, but my answer is still true The difference between INDI 1.2 and wINDI response is in this case semantical.

IMHO, in any case, Han needs our help...

Oleg, I fully agree

Han, the recommendation from both Jasem and me was to start with XML parser (probably SAX-like). This will help you to solve syntactical issues, but for most parsers some kind of hacking will be necessary anyway. Each message is XML "document", parser should not close the input stream once end of document is reached. I did it couple of times with different parsers in different environment, the easiest way is to wrap input stream into some kind of virtual stream and to inject any top level tag on the very beginning.

INDI protocol specification is available here: www.clearskyinstitute.com/INDI/INDI.pdf . It is not request-response protocol, once property change is requested by newXXXVector message, any number of defXXXVector or setXXXVector messages can arrive, in any order, asynchronously, immediately, later or never. Client should contain "model" of remote device to interpret such messages in event driver manner. Unfortunately, there is probably no easier way how to do it, trust me.

Btw, ON_COORD_SET doesn't work as you suppose. Setting TRACK On means, that mount should continue tracking once next *_COORD request will finish.

Peter

Peter,

My problem is that I use one single source (FPC &Lazarus) for both Windows and Linux versions of my program. So if In Linux and MSWindows elements differ, I'm lost:

setSwitchVector versus defSwitchVector
oneSwitch versus defSwitch

I fixed now the detection of telescope_connection=on in a few lines of code. I'm simple looking for 1) "'SwitchVector', then 2) "CONNECT", then 3) </' and if the word On is between the "CONNECT" and </' , the telescope connection is On. Maybe primitive but it works. So for the moment, I will not follow the recommendation of parser.

The reason for tracking command was that the ASCOM simulator didn't accept a slew commando without the tracking On.

Question, in the past (2010) there was a discussion of an EQUATORIAL_COORD_REQUEST. I can't find anything in the current documentation. Does it still exist? Nothing in the INDI standard properties.

An other remark. I noticed using (w)INDI, that every second or so, a new position is send from the telescope simulator ASCOM...NET. This because there is a small noisy variation in the RA value. I assume this is done by purpose in the ASCOM simulator? Therefore for testing I also used the POTH hub which is steady. I have noticed (as mentioned) that INDI is event driven and if therefore, I keep the old values in case there are no event. In is different compared with the ASCOM interface where you can ask every second or the data. So there is currently no need for EQUATORIAL_COORD_REQUEST, but it could be handy.

HNSKY works now with (w)INDI and INDI library 1.2 (server & indi_simulator_telescope). Which servers are more to test?

Later: FPC, the Free Pascal Compiler has several units for XML processing including a parser. However for the few commando's, it looks for me overkill.

Han