What

The webhmi server (OMJSON) should send a clientID variable back to the Client.

Why

A webhmi client needs to know its so it can "take" resources and potentially do other smart things with the PLC

WriteResponse currently can contain variables with the incorrect type representation. For example if you have a variable num of type UDINT.

{
  "type": "write",
  "data": {
    "num": 52,
}
{
  "type": "writeresponse",
  "data": {
    "num": 52,
}

as it should but...

{
  "type": "write",
  "data": {
    "num": "52",
}
{
  "type": "writeresponse",
  "data": {
    "num": "52",
}

This is incorrect, the write response as the server should always respond with the the value and the correct type. I would expect:

{
  "type": "write",
  "data": {
    "num": "52",
}
{
  "type": "writeresponse",
  "data": {
    "num": 52,
}

Describe the bug

The jsonWebSocketServer FUB reports error 50004 when a Lux client first attempts to connect. The ErrorString reported is THAT$'s NOT POSSIBLE. The issue only appears intermittently, and appears to primarily occur after doing a clean, rebuild, followed by an offline install. Note that this has only been tested/seen in simulation.

When the issue first appears, the jsonWebSocketServer.ClientInfo[0].ClientPort is continually incrementing, which shows the the ws connections are getting closed or dropped, and being re-established.

To reproduce

Follow the LPM bootstrap guide here: https://loupeteam.github.io/LoupeDocs/tools/lpm/guides/bootstrapping-a-project-with-lpm.html

Expected behavior

The client should connect automatically when the HMI is started, and the ClientPort should keep a fixed value. There should be no error on the FUB.

Additional information

Happens with version 1.4.0 of OMJSON.