khoih-prog / WebSockets2_Generic

A WebSocket Server and Client library for Arduino, based on RFC6455, for writing modern Websockets applications. Now support ESP8266, ESP32 (including ESP32-S2 Saola, AI-Thinker ESP-12K, WT32_ETH01, etc.), nRF52, SAMD21, SAMD51, SAM DUE, STM32F/L/H/G/WB/MP1, Teensy, RP2040-based, etc. boards, with WiFiNINA, Teensy 4.1 NativeEthernet/QNEthernet, Ethernet W5x00 / ENC28J60 / LAN8742A / LAN8720, ESP8266 / ESP32-AT modules/shields, as well as SINRIC / Alexa / Google Home
GNU General Public License v3.0
81 stars 30 forks source link

MKR1000 and WIFI problem and another problem #20

Closed ghost closed 3 years ago

ghost commented 3 years ago

Describe the bug

I am running the sample program "SAMD-Minimal-Client", but it has a problem when it reaches any WIFI line.

Arduino IDE 1.8.15 Arduino MKR 1000 Installed libraries: WiFiNINA_Generic v1.2.4 WebSockets2_Generic v1.8.5

sc10

Steps to Reproduce

When I compile the sample program I get some strange lines before finishing compilation (ScreenShot sc05.jpg). I have added some lines to the code Serial.prinln ("1") ... (ScreenShot sc06.jpg) to see where the execution of the program goes. As you will see in the screenshot, on the serial monitor, the program correctly detects my MKR1000, but it does not pass the Serial.print (1) line, that is, it remains blocked in WiFi.status () (ScreenShot sc07.jpg) Even if you disable several lines in the program prior to the WiFi connection (ScreenShot sc08.jpg), it always stays blocked, even on the WiFi.begin line (ScreenShot sc09.jpg). You can also see in the screenshots that I have used the firmware check programs and another example program from the Wifi101 library to check the WiFi connection and everything works perfectly (ScreenShots sc01, sc02, sc03, sc04). That is, the problem is when using your library. Am I doing something wrong or is it a bug in your library? Look at all the screenshots.

sc05 sc06 sc07 sc08 sc09

Checks:

CheckWifi101FirmwareVersion

sc01 sc02

WiFiWebClient

sc03 sc04

Thank you very much for your help.

Regards, Jose.

khoih-prog commented 3 years ago

This WebSockets2_Generic Library is not currently supporting boards using WiFi101 shield and library.

I already checked and to provide support to this WiFi101 requires drastic changes in both WebSockets2_Generic Library and some changes in WiFi101 library.

Because of the unpopularity of WiFi101 as well as MKR1000, I won't assign this work with high priority. And it'll take weeks to fix / update. Moreover, I don't have this combination MKR1000 + WiFi101 to test.

I suggest you, if urgent. to use another currently-supported combination, such as ESP32, ESP8266, Nano-33-IoT, or even MKR1000 with Ethernet W5x00/EN28J60.

If you're willing to wait, and test within a week or so, I can speed-up the changes for you to test.

Good Luck,

ghost commented 3 years ago

Hi, The problem is that they are mkr1000 arduinos already mounted on a special circuit, so I have no choice but to use this combination. Yes, I could wait a week and test your new version. :)

On the server we have a socket.io, express and nodejs configuration. I have seen that other products support websockets, but not socket.io. ArduinoWebSockets (https://github.com/Links2004/arduinoWebSockets) supports socket.io, however it does not support the arduino MKR1000. :( Socket.io is based on the websockets protocol, but it is a modified and improved protocol, although not compatible with the websockets standard. Socket.io is mostly used with Nodejs. Do you know if your library is prepared for both the websockets protocol and the improved socket.io?

Thank you very much for all your help.

khoih-prog commented 3 years ago

You can have a look at my WebSockets_Generic Library, based on ArduinoWebSockets and supporting Socket.IO.

For example Generic_WebSocketClientSocketIO_WiFiNINA example.

If OK and you'll spend time to test, I'll add support to MKR1000 and WiFi101 to that WebSockets_Generic Library

ghost commented 3 years ago

Yes. Of course. I will be doing the test of all the improvements that you are producing to your library. :) Do you think you can have a preliminary version in 1 week? Thank you so much for all your help.

khoih-prog commented 3 years ago

Will release tomorrow. Almost done

You can test the Modified WiFi101 library now.

ghost commented 3 years ago

Do you know if the supported version of socket.io in your library corresponds to the supported version of node socket.io (https://www.npmjs.com/package/socket.io)?

ghost commented 3 years ago

You are wonderful, you are a crack. :) I'm going to do tests. I will tell you something.

khoih-prog commented 3 years ago

No idea yet. Many different implementations out there. But if they stick to the Socket.IO standards, it'll be compatible and OK.

ghost commented 3 years ago

You have to guide me a bit to do the tests you need to check that everything works correctly. 1) I overwrite the installation of my standard WiFi101 library with yours. 2) I check that the WiFi101 library examples continue to work.

Do you want me to do something else for now?

khoih-prog commented 3 years ago

Already publish WebSockets2_Generic Releases v1.3.0

Please test with the Forked WiFi101 library and let me know the result.

Thanks,


Release v1.3.0

  1. Add support to WiFi101. To be used with Forked WiFi101 library
  2. Check compatibility with new ESP8266 core v3.0.0
  3. Suppress warnings
khoih-prog commented 3 years ago

I overwrite the installation of my standard WiFi101 library with yours. I check that the WiFi101 library examples continue to work. Do you want me to do something else for now?

Those are enough tests.

ghost commented 3 years ago

First analysis. I have overwritten your WiFi101 library on my computer. I have tried some examples and they still work. :)

With the library manager of the Arduino IDE I have installed your WebSockects_Generic library. I have modified the Generic_WebSocketClientSocketIO_WiFiNINA example for SAMD21. Please tell me if I have done this modification correctly or have to do it differently. When running the example it cannot connect to my WiFi. Look at the screenshots.

sc11 sc12 sc13

Tell me if I should do some other tests. Thanks.

khoih-prog commented 3 years ago

WebSockects_Generic library is not supporting WiFi101. That's why you have the same hanging issue because it tries to use WiFiNINA, instead of WiFi101.

Have to fix in next step, if necessary.

khoih-prog commented 3 years ago

Now, just try the WebSockects2_Generic with normal WebSocket server, to see of WiFi101 is working OK.

Use the examples such as SAMD_WiFi101-Minimal-Client.

There are 7 examples

For SAMD21/SAMD51 boards using WiFi101

  1. SAMD_WiFi101-Client
  2. SAMD_WiFi101-Minimal-Client
  3. SAMD_WiFi101-Client_SINRIC
  4. SAMD_WiFi101-Server
  5. SAMD_WiFi101-RepeatingClient
  6. SAMD_WiFi101_ServerAllFunctionsDemo
  7. SAMD_WiFi101-AdvancedWebServer.
ghost commented 3 years ago

In WebSockects2_Generic now the WiFi works perfectly, thank you very much. In the examples you can modify the lines that show the Local IP so that they show it correctly. Look at the following screenshots:

sc14 sc15 sc16

Thank you very much for your work.

Now I would have to try testing it with a normal websocket server, but I don't have any implementation. I can try to make a nodejs websocket server. I'll tell you something.

ghost commented 3 years ago

Hi Khoi Hoang,

I have made a small standard websocket server based on the nodejs websocket library (https://www.npmjs.com/package/websocket). The connection to the WiFi is successful, the connection to the server is also correct, but when it try to use the server's websocket the following error occurs: "Specified protocol was not requested by the client"

Also, as you will see in the screenshots, warnings are produced when compiling the arduino program. Look at the following screenshots:

sc19

Server: sc17

Client: sc18

Server Source code:

var WebSocketServer = require('websocket').server;
var http = require('http');

var server = http.createServer(function(request, response) {
    console.log((new Date()) + ' Received request for ' + request.url);
    response.writeHead(404);
    response.end();
});
server.listen(8080, function() {
    console.log((new Date()) + ' Server is listening on port 8080');
});

wsServer = new WebSocketServer({
    httpServer: server,
    // You should not use autoAcceptConnections for production
    // applications, as it defeats all standard cross-origin protection
    // facilities built into the protocol and the browser.  You should
    // *always* verify the connection's origin and decide whether or not
    // to accept it.
    autoAcceptConnections: false
});

function originIsAllowed(origin) {
  // put logic here to detect whether the specified origin is allowed.
  return true;
}

wsServer.on('request', function(request) {
    if (!originIsAllowed(request.origin)) {
      // Make sure we only accept requests from an allowed origin
      request.reject();
      console.log((new Date()) + ' Connection from origin ' + request.origin + ' rejected.');
      return;
    }

    var connection = request.accept('echo-protocol', request.origin);
    console.log((new Date()) + ' Connection accepted.');
    connection.on('message', function(message) {
        if (message.type === 'utf8') {
            console.log('Received Message: ' + message.utf8Data);
            connection.sendUTF(message.utf8Data);
        }
        else if (message.type === 'binary') {
            console.log('Received Binary Message of ' + message.binaryData.length + ' bytes');
            connection.sendBytes(message.binaryData);
        }
    });
    connection.on('close', function(reasonCode, description) {
        console.log((new Date()) + ' Peer ' + connection.remoteAddress + ' disconnected.');
    });
});

Any other tests you want me to do, you tell me.

Thank you.

(Edit) New investigations: If on the server I accept any protocol by modifying the following line: var connection = request.accept ('echo-protocol', request.origin); to var connection = request.accept (null, request.origin); the connection is successfully established.

With your library, can you use a specific protocol to communicate with the server?

Look at the following screenshots: sc20 sc21

However, I have observed a problem. When using extended characters (Spanish), for example ñ, ó, ... that are in the middle of the sentence to be sent, the connection is blocked, and this is the fault of:

void onMessageCallback(WebsocketsMessage message) 
{
  Serial.print("Got Message: ");
  String sss = message.data();
  Serial.println(sss);  // <<<< From what I have investigated the problem is in the Serial.println () 
        // Do you make any internal variation of the string received from the server? 
}

void loop() 
{
  client.poll();

  delay(3000);

  c++;
    String numero = (String) c;
    String WS_msg = c + String(" España: Hello to Server from ") + BOARD_NAME;  // **España contains ñ**
   // However, if I send the following:
   // String WS_msg = c + String(" ñ: Hello to Server from ") + BOARD_NAME; 
   // everything works correctly, although it also contains the character ñ 
   // Keep in mind that the same string that is sent to the server, the server sends it back to the client.  
  client.send(WS_msg);
}

Do you have any idea how to solve this problem?

Thank you so much for all your help.

khoih-prog commented 3 years ago

Good news that you can find your way out from now on.

You can try this sophisticated SAMD_WiFi101-Client_SINRIC example and control your device from Amazon's Alexa Voice control and Sinric or SinricPro phone app.

For Spanish character issue, you have to ask on some forums how to solve as I don't have experience with Internationalization.

Now I would have to try testing it with a normal websocket server, but I don't have any implementation.

You can use the SAMD_WiFi101-Server example, or the similar one written for other boards, to create a test WebSocket Server.

ghost commented 3 years ago

However, for now I cannot use it with our server, since as I mentioned it works with socket.io. Now, when you have made the compatibility of WebSockets_Generic I will test if it works with our server with nodejs + socket.io

Very interesting what you tell me about control through Alexa and SinRic. I'll keep it in mind in case we need it. :)

To control an industrial encoder, speed measurement by sections, etc ... do you have any library recommendations? Also, I have seen that you have very interesting libraries, if I want to prevent the sending of information to the server from interrupting in any way the data that is being received from the encoder, could one of your plugins be used for this?

Thank you very much for all your help.

khoih-prog commented 3 years ago

Now, when you have made the compatibility of WebSockets_Generic I will test if it works with our server with nodejs + socket.io

I'll put this in my very long bucket lists

  1. WebSockets_Generic + WiFi101
  2. WebSockets2_Generic + Socket.IO

In the mean time, you can try to merge the code with Socket.IO-client Library to see if OK.

To control an industrial encoder, speed measurement by sections, etc ... do you have any library recommendations?

Try to use my SAMD_TimerInterrupt, especially

  1. ISR_RPM_Measure
  2. RPM_Measure

These examples are using ISR and won't be interrupted by other low priority tasks.

ghost commented 3 years ago

Ahhh .... I thought you told me that by tomorrow you would have a version of WebSockets_Generic + WiFi101, that is what I had understood, for that reason I had been so happy, however, if it is not possible in all ways you I appreciate your efforts.

khoih-prog commented 3 years ago

Possibly I told you WebSockets2_Generic + WiFi101, not WebSockets_Generic + WiFi101 as this is not in my mind at all. A typo (missing 2 ??)

khoih-prog commented 3 years ago

I'll try finish WebSockets_Generic + WiFi101 next week as this is much simpler to do than last WebSockets2_Generic + WiFi101

ghost commented 3 years ago

Ohhh ... that would be wonderful ... thank you so much 👍

khoih-prog commented 3 years ago

I'm closing this issue now as there is nothing more to do here on this enhancement. Please open the new issue in WebSockets_Generic to be consistent.