how to use the websocket sink?

[Maingol]

The document in the image says that you only need to fill in the path, not the WebSocket server address, to let eKuiper act as a WebSocket server. However, it turns out that both the path and the WebSocket server address are required fields in the WebSocket sink component. Why is that? The endpoints have also been created, but the WebSocket connection test is unsuccessful. How can I determine the running port of the WebSocket service on eKuiper and whether the WebSocket service has successfully started?

[Maingol]

the ekuiper version is 1.13.4

[Yisaer]

Hi @Maingol

For the weocket sink, eKuiper will create the websocket connection as client side or server side.

For the client side, the rule is defined like following:

The eKuiper will try to connect the target endpoint to create the websocket connection

{
  "id": "redis",
  "sql": "SELECT * from demo_stream where temperature > 50",
  "actions": [
    {
      "log": {},
      "websocket":{
        "addr": "127.0.0.1:8080",
        "password": "/api/data"
      }
    }
  ]
}

For the server side, the rule is defined like following:

The other websocket client need to create the connection at the eKuiperHost:10081/api/data endpoint.

{
  "id": "redis",
  "sql": "SELECT * from demo_stream where temperature > 50",
  "actions": [
    {
      "log": {},
      "websocket":{
        "password": "/api/data"
      }
    }
  ]
}

[Maingol]

I tried this to create a rule:
"websocket":{
"password": "/api/data"
}
but the response is "websocket sink conf path should be defined"

So I tried this:
"websocket":{
"path": "/api/data"
}
and the rule created successfully，but I can only see the log sink when I look up the rule in the rule‘s actions

[Maingol]

@Yisaer

[Maingol]

@Yisaer
Then I removed the log node and checked the rule's action again, and it worked correctly. The final request parameters were similar to this:

"action": [
{
"websocket": {"path": "eva", "format": "json"}
}
]
Because this method uses SQL statement-type rules, I had to set up an in-memory output in my flow diagram. In the end, it worked, but this method required me to build additional SQL rules and an in-memory output component. I kept trying to directly pass data to the WebSocket component in the flow diagram. I used a workaround: first, I filled in both the WebSocket server address and path, then I used the API to get the details of this flow rule. After that, I removed the WebSocket server address from the details and passed the modified result back to the API to update the rule. It worked, and the WebSocket client successfully received the message. The issue was that the backend did not require the WebSocket server address, but the frontend did, causing significant trouble for my testing. Thank you for your help. I have found the problem, but it seems you must admit that this is an indisputable bug. I hope you fix it promptly.