Custom Ethernet and INDI: no persistent channel?


Jordi Sese
 

Hi all,

Is there anyone using kStars/eKos with an ethernet module?

I have been able to setup an ethernet connection to OnStep using a W5500 card and a Wemos D1 Mini, with a slight modification of the code (basically, specify CS pin - for this ethernet lib needs to be changed to ethernet2 lib - and RESET pin - this in pinmap file). This way, SWS (I have also tried Ethernet AddOn) compile and seems to work fine from the web page, but if I try to connect from eKos using the INDI driver using port 9999, It connects and works at first since it gets almost everything right - except for scope position; after that initialization, nothing seems to work... It is exactly the same behavior than using the standard wifi port (not the persistent one) at 9999... 

For example, when it tries to send Star Aligment command, it gets an error response:
2021-07-16T19:27:39: [INFO] Align Status response Error, response = �+�D(�> 
2021-07-16T19:27:39: [INFO] Getting Max Star: response Error, response = �8�> 
2021-07-16T19:27:39: [INFO] Sending Command to Start Alignment 

Is there anyone using this kind of connection? How do you use it?

Thanks a lot for your help. Regards from Barcelona,

Jordi.


Khalid Baheyeldin
 

When using INDI over IP, you must use port 9998, not port 9999.
Try 9998, and see if it works.


Jordi Sese
 

Hi Khalid, thanks for your response. I insist that this is over ethernet, not wifi...

2021-07-16T22:46:55: [ERROR] Failed to connect to 192.168.1.200@9998: Connection refused. 
2021-07-16T22:46:55: [INFO] Connecting to 192.168.1.200@9998 ... 

In the code the only port initiated is 9999 for ethernet:

cmdSvr.init(9999, 500);

If I change it to 9998, or duplicate the line with 9998 as the first parameter, it connects at that port, but the behavior is the same than the 9999 one...

Thanks for your time,

Jordi.


Khalid Baheyeldin
 

On Fri, Jul 16, 2021 at 06:56 PM, Jordi Sese wrote:
I insist that this is over ethernet, not wifi...
I know that.

There is this code in SmartWebServer/src/ethernetServers/CmdServer.cpp

  EthernetServer cmdserver1(9999);
  EthernetServer cmdserver2(9998);

So it should work in both modes: command at a time and connection closed, and persistent.

Did your modifications affect that part?


Jordi Sese
 

Thanks for replying, Khalid...

This is not my code, so I cannot be 100% sure, but I've searched the files and this class gets only one initialization, and it is at port 9999. 

the init functions starts this way...
  void CmdServer::init(int port, long t) {
    if (port >= 9998 && port <= 9999) {
[...]

and the only call I've found is the one I told you before (SmartWebServer.ino), and there's only one CmdServer object defined at EthernetServsers.h.
cmdSvr.init(9999, 500);

The port only gets available if I duplicate the code for another CmdServer object and I call init at port 9998, etc., but since it is the same code, there is no difference in its behavior...

Please enlighten me since I can't see it; for me there is no persistent channel in the ethernet server...

Thanks again for your time.

Jordi.


Khalid Baheyeldin
 

Then I am not sure anymore ...

Maybe it is this code in src/ethernetServers/EthernetServers.h ?

  #if STANDARD_COMMAND_CHANNEL == ON
    extern WebServer server;
    extern CmdServer cmdSvr;
  #endif

  #if PERSISTENT_COMMAND_CHANNEL == ON
  #endif

Either way, Howard has to enlighten us on what is going on with the persistent channel with SWS when Ethernet it used ...


Jordi Sese
 

Yes, precisely. This is one of the places I've found.

Also in the wiki, it only reads about wifi:
WiFi also has a persistent IP command channel (on port 9998) ... no notice about ethernet.

Ethernet services at port 9999 work fine, since I can use them with SkySafary, but INDI requests from kStars/eKos (what I use the most) seem to need the persistent channel way... 

Anyway, we will wait for Howard to tell us more...

Thanks for your time, Khalid.

Jordi.


Howard Dutton
 

On Fri, Jul 16, 2021 at 05:57 PM, Jordi Sese wrote:
Yes, precisely. This is one of the places I've found.

Also in the wiki, it only reads about wifi:
WiFi also has a persistent IP command channel (on port 9998) ... no notice about ethernet.

Ethernet services at port 9999 work fine, since I can use them with SkySafary, but INDI requests from kStars/eKos (what I use the most) seem to need the persistent channel way... 

Anyway, we will wait for Howard to tell us more...
Exactly correct, not supported yet.  I'll get around to it at some point, probably rewrite the command channel Ethernet code.

Also wonder if we should try switching to all persistent connections (only.)  Perhaps provide 3 or 4 (ports 9996 to 9999.)  One connection per port but with enough ports to make that irrelevant.  My ASCOM driver doesn't care which type, pretty sure the Android App is fine too.


Jordi Sese
 

Hi Howard, thanks for your answer.

I have just tried this small mod of your code (SmartWebServer.ino, setup func); it seems to work with INDI, but I don't know whether it is advisable to do that... No timeout (any connection control?) seems to work... for me

  #if STANDARD_COMMAND_CHANNEL == ON
    VLF("SWS: Starting port 9999 cmd svr");
    #if OPERATIONAL_MODE == WIFI
      cmdSvr.begin();
      cmdSvr.setNoDelay(true);
    #else
      //cmdSvr.init(9999, 500);
      #if PERSISTENT_COMMAND_CHANNEL == ON
        cmdSvr.init(9998, 0);
      #else
        cmdSvr.init(9999, 500);
      #endif
    #endif
  #endif

I will try it for a full session to be sure that it really works...

Thanks for your time,

Jordi.


Khalid Baheyeldin
 

On Sat, Jul 17, 2021 at 05:42 AM, Howard Dutton wrote:
Also wonder if we should try switching to all persistent connections (only.)  Perhaps provide 3 or 4 (ports 9996 to 9999.)  One connection per port but with enough ports to make that irrelevant.  My ASCOM driver doesn't care which type, pretty sure the Android App is fine too.
Good idea.

That would have the added advantage of standardizing the communication protocol, and not having to deal with two protocols, a bit down the road.

Maybe don't use 9999 for persistent, since people will have to go through a transition period with old clients, old controllers, and so on. So maybe make ports 9991 to 9998 be persistent and that is it.

Since the Android App, Stellarium Mobile Plus and INDI are all good with persistent connections, that leaves what? SkySafari? If that is persistent too, then that is the way to go.


Howard Dutton
 

On Sat, Jul 17, 2021 at 03:01 AM, Jordi Sese wrote:
Hi Howard, thanks for your answer.

I have just tried this small mod of your code (SmartWebServer.ino, setup func); it seems to work with INDI, but I don't know whether it is advisable to do that... No timeout (any connection control?) seems to work... for me

  #if STANDARD_COMMAND_CHANNEL == ON
    VLF("SWS: Starting port 9999 cmd svr");
    #if OPERATIONAL_MODE == WIFI
      cmdSvr.begin();
      cmdSvr.setNoDelay(true);
    #else
      //cmdSvr.init(9999, 500);
      #if PERSISTENT_COMMAND_CHANNEL == ON
        cmdSvr.init(9998, 0);
      #else
        cmdSvr.init(9999, 500);
      #endif
    #endif
  #endif

I will try it for a full session to be sure that it really works...

Thanks for your time,
I made a branch of the SWS with the Ethernet persistent channel code as I think it would be done, untested other than it compiles ok.

Who knows perhaps it'd work IDK....

https://github.com/hjd1964/SmartWebServer/tree/experimental


Jordi Sese
 

Hi Howard,

Thanks for your work. Yes, it compiles, but in EhthernetServers.cpp there was a small typo in ethernetPersistantCommandChannel function, when you read cmdSvr instead of cmdSvrPersistant. After that change, it seems to work. I will tell you more when I test it.

Also, just in case you want to add support for ESP8266 Ethernet, those are the other changes I performed for SWS to make it work with Wemos D1 + W5500:
- change ethernet.h to ethernet2.h (with an #ifdef ESP8266) in almost all files in EthernetServers folder
- change W5500_RESET_PIN to D2 in Pins.ESP8266.h
- add a W5500_CS_PIN definition (and set it to D1) to Pins.ESP8266.h and call Ethernet.init(W5500_CS_PIN) just before your Ethernet.begin() in WebServer.cpp
- modify EthernetServers.h to avoid validation error, adding ESP8266 support

Thanks for your time, and regards.

Jordi.

 


Howard Dutton
 

On Tue, Jul 20, 2021 at 10:04 AM, Jordi Sese wrote:
- change ethernet.h to ethernet2.h (with an #ifdef ESP8266) in almost all files in EthernetServers folder
Is that the Adafruit W5500 library?
https://github.com/adafruit/Ethernet2


Jordi Sese
 

Is that the Adafruit W5500 library?
https://github.com/adafruit/Ethernet2
Yes, indeed. It is needed (this or an equivalent) just because it has the init function that allows to set the CS pin (the CS pin needs to be changed from the default; if you don't, it puts the Wemos D1 into programming mode when connecting the W5500 to the default pin). 


Howard Dutton
 

On Tue, Jul 20, 2021 at 12:17 PM, Jordi Sese wrote:
Is that the Adafruit W5500 library?
https://github.com/adafruit/Ethernet2
Yes, indeed. It is needed (this or an equivalent) just because it has the init function that allows to set the CS pin (the CS pin needs to be changed from the default; if you don't, it puts the Wemos D1 into programming mode when connecting the W5500 to the default pin). 
Ok, I pushed those changes to the SWS experimental branch, look them over/test and let me know...

You should look into GitHub if this continues, makes it easier for all. ;)


Jordi Sese
 

Hi Howard,

Great! this time I only had to modify config.h to select W5500 ethernet mode and it connected/worked fine!!!
It's cloudy right now so I cannot test it for a full session, but it looks good to me using it home with the ccd simulator.

Thanks a lot for your help. 

Regards from Barcelona,

Jordi.