WS v2, StreamDeck Plus WS Socket not Stable

[n61ab]

I installed your update v2 to use with my StreamDeck Two+ Dials. Thank you for the update.

At first, all was good. But, when I created a new SD profile and copied the Dial to the second profile, the WS Socket connection disconnected.

I could not get "Reconnect" even after removing the second profile/dial.

A new connection was made with a new Web Socket path (a new configuration node).

I repeated the new profile and copy button, and the same problem with WS Socket disconnecting.

StreamDeck buttons work just fine; the problem is isolated to StreamDeck Dials.

Alan Blind

[ybizeul]

Thanks Alan,
@pakerfeldt did you experience something similar ?

[pakerfeldt]

Sorry for late reply. I've been on vacation.

I just created a new profile. Copied one of my WSProxy dials from my main profile and pasted it in the new profile. Both are still working fine. Cannot seem to reproduce this issue.

[n61ab]

pakerfeldt

Thank you for taking a look. I moved my Node-Red to a different device; now everything appears good.

Sorry for the false alarm.

Alan

[n61ab]

Well, I spoke too soon. I was able to create the issue on the second Node-Red instance.

I built three dials, each with a WS path and configuration node. Good so far.

On the fourth dial, again with a unique WS, the Web Socket connected just fine at first. Then when I moved to a second profile on the SteamDeck, the Web Socket disconnected, as expected. The problem was, when I returned to the profile, with dial four, the Web Socket refused to re-connect. Nothing I did would get it to re-connect.

Then, I removed the Node-Red configuration node for the problem WS path and built a new WS path, all was good again, up to when I changed the SD profile, then the problem repeats.

The other SD dials continued to work just fine.

The SD Buttons all work great, in all combinations. The Web Socket refusing to reconnect is isolated to Dials.

Alan

[pakerfeldt]

I'm not entirely sure what I do differently but I cannot seem to reproduce.

This is what I did. Added a new page on my default profile. Added four new dials with path streamdeck1, 2, 3, 4. All with the same IP (to my Node-RED instance). Added four new websocket in nodes in Node-RED. All of which are using its own dedicated path as configured previously. Now if I switch back and forth between my pages in the default profile I can see how the nodes gets connected and disconnected in Node-RED as expected.

Now, I also created a new profile. Copied one of the dials from the default profile. When I'm on the new profile, the related websocket in node shows Connected. When I jump back to the default profile. All nodes show connected. If I switch to a completely separate page (with no websocket dials) they all turn disconnected in Node-RED. Then back connected when I go back to the correct page again.

So, all in all. I can't really seem to reproduce this. FWIW, I'm running Node-RED v2.2.2 and node-red-contrib-websocket 0.1.0.

[n61ab]

Patrik The only difference is I am running Node-Red v3.0.2. I am using the WS node that comes with the base Node-Red. Are you using a "contrib" Web Socket node? Or maybe it is my Node-Red flow? I do not think it would matter to the WebSocket connection. FYI, if you want to take a look, I have attached my "base" flow I built to demo all the SD+ inputs. I put each button's "context" and "device" values into the flow context with the ID as the key. I then use the ID to retrieve the context and device to build the JSON object. I use this same method for all my buttons. Alan

…

On Fri, Feb 24, 2023 at 8:50 AM Patrik Åkerfeldt ***@***.***> wrote: I'm not entirely sure what I do differently but I cannot seem to reproduce. This is what I did. Added a new page on my default profile. Added four new dials with path streamdeck1, 2, 3, 4. All with the same IP (to my Node-RED instance). Added four new websocket in nodes in Node-RED. All of which are using its own dedicated path as configured previously. Now if I switch back and forth between my pages in the default profile I can see how the nodes gets connected and disconnected in Node-RED as expected. Now, I also created a new profile. Copied one of the dials from the default profile. When I'm on the new profile, the related websocket in node shows Connected. When I jump back to the default profile. All nodes show connected. If I switch to a completely separate page (with no websocket dials) they all turn disconnected in Node-RED. Then back connected when I go back to the correct page again. So, all in all. I can't really seem to reproduce this. FWIW, I'm running Node-RED v2.2.2 and node-red-contrib-websocket 0.1.0. — Reply to this email directly, view it on GitHub <#28 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANLEVKZC2W7PJ7UN7DHCJPDWZC4CVANCNFSM6AAAAAAVAODACM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[n61ab]

More info on the WebSocket node version. As is said, I am using NR v 3.0.3. It appears the WebSocket is built into v3.0.3 and a "contrib" for NR v2.x. Perhaps this points to a difference that matters. See these screenshots from my pallet manager: Installed Pallets: [image: Screenshot 2023-02-24 at 9.11.28 AM.png] New Pallet Search: [image: Screenshot 2023-02-24 at 9.10.41 AM.png]

…

On Fri, Feb 24, 2023 at 9:07 AM Alan Blind ***@***.***> wrote: Patrik The only difference is I am running Node-Red v3.0.2. I am using the WS node that comes with the base Node-Red. Are you using a "contrib" Web Socket node? Or maybe it is my Node-Red flow? I do not think it would matter to the WebSocket connection. FYI, if you want to take a look, I have attached my "base" flow I built to demo all the SD+ inputs. I put each button's "context" and "device" values into the flow context with the ID as the key. I then use the ID to retrieve the context and device to build the JSON object. I use this same method for all my buttons. Alan On Fri, Feb 24, 2023 at 8:50 AM Patrik Åkerfeldt ***@***.***> wrote: > I'm not entirely sure what I do differently but I cannot seem to > reproduce. > > This is what I did. Added a new page on my default profile. Added four > new dials with path streamdeck1, 2, 3, 4. All with the same IP (to my > Node-RED instance). Added four new websocket in nodes in Node-RED. All > of which are using its own dedicated path as configured previously. Now if > I switch back and forth between my pages in the default profile I can see > how the nodes gets connected and disconnected in Node-RED as expected. > > Now, I also created a new profile. Copied one of the dials from the > default profile. When I'm on the new profile, the related websocket in > node shows Connected. When I jump back to the default profile. All nodes > show connected. If I switch to a completely separate page (with no > websocket dials) they all turn disconnected in Node-RED. Then back > connected when I go back to the correct page again. > > So, all in all. I can't really seem to reproduce this. FWIW, I'm running > Node-RED v2.2.2 and node-red-contrib-websocket 0.1.0. > > — > Reply to this email directly, view it on GitHub > <#28 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ANLEVKZC2W7PJ7UN7DHCJPDWZC4CVANCNFSM6AAAAAAVAODACM> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >

[pakerfeldt]

Not sure, but your screenshots does not appear in this issue it seems.

Anyway, could you perhaps try installing the contrib websocket package and see it that works differently?
https://flows.nodered.org/node/node-red-contrib-websocket

[n61ab]

Node-Red v3.0.3 will not let me load the 'contrib" web socket, it says there is a conflict. I will build an NR v2 machine and test it, or can you upgrade to NR v3? Either way is fine. May take a few days to build a new NR instance. Alan

…

On Fri, Feb 24, 2023 at 9:28 AM Patrik Åkerfeldt ***@***.***> wrote: Not sure, but your screenshots does not appear in this issue it seems. Anyway, could you perhaps try installing the contrib websocket package and see it that works differently? https://flows.nodered.org/node/node-red-contrib-websocket — Reply to this email directly, view it on GitHub <#28 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANLEVKYRCQIRO22UXV3FPELWZDASJANCNFSM6AAAAAAVAODACM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[pakerfeldt]

I have a modbus package that didn't let me upgrade to NR v3. However, I think they might have sorted that out so perhaps I'm unblocked.

I'm running NR in docker so I can quite easily create a separate instance with just vanilla NR v3 and try this out. Hopefully I get some time in the weekend to try.

[n61ab]

ThanksSent from my iPhoneOn Feb 24, 2023, at 9:45 AM, Patrik Åkerfeldt ***@***.***> wrote: I have a modbus package that didn't let me upgrade to NR v3. However, I think they might have sorted that out so perhaps I'm blocked. I'm running NR in docker so I can quite easily create a separate instance with just vanilla NR v3 and try this out. Hopefully I get some time in the weekend to try. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[n61ab]

Patrik After more testing, the problem does not appear to me to be related to the NR or WebSocket revision. I think there is a conflict between the dials and the buttons, causing the Web Socket not to reconnect. Please remember that there have been no issues with the SD button Web Sockets re-connecting. I found there are subtle differences between dials and buttons. My first observation was a difference in the status message structure....an extra "payload" in the dial string, for example. This would not affect our WebSocket problem, but I point out subtle differences between SD dials and buttons as a trend. I found with only SD dials; there were no Web Socket connection issues. As expected, when I changed to an SD page or profile without a dial, that dial's WS connection would disconnect. Then, when I returned to the page/profile with the dial, the WS connection would re-connect. All Four dials, same IP, each with a different WS path.....all good. Same as your observation. Next, I added an SD button to the same page/profile as the dials. When I cycled from/back to the profile/page with the dials and button, the Web Socket for three of the four dials would not reconnect. The button did reconnect. Again, the dial Web Socket connections seemed "hung up." I had to remove and install a new WS path to make a new connection for the dials. Alan.

…

On Fri, Feb 24, 2023 at 9:45 AM Patrik Åkerfeldt ***@***.***> wrote: I have a modbus package that didn't let me upgrade to NR v3. However, I think they might have sorted that out so perhaps I'm blocked. I'm running NR in docker so I can quite easily create a separate instance with just vanilla NR v3 and try this out. Hopefully I get some time in the weekend to try. — Reply to this email directly, view it on GitHub <#28 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANLEVKYLRJ7QV33VRFMDLGLWZDCRTANCNFSM6AAAAAAVAODACM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[pakerfeldt]

Alright. I think I know what's going on, but I don't know how to fix it, simply because I'm not accustomed to the source code yet.
The problem is that Dial 1 seem to share WS resources with the button on row 0, column 0. Dial 2, share WS resources with button on row 0, column 1. Dial 3 on row 0, column 2 and Dial 4 on row 0, column 3. I.e. dials seem to conflict with the four buttons on the first row.

Maybe @ybizeul would have an idea of why that is? I might be able to spend some time on this eventually, but not tonight.

[n61ab]

Patrik Yes, you have it! I confirmed with a test. I placed four dials and one button on the same SD page. Whichever column I place the button on, it "blows out" the dial's WS re-connect in the same column! The other three dials, with no buttons in their column, are OK. Alan

…

On Fri, Feb 24, 2023 at 1:56 PM Patrik Åkerfeldt ***@***.***> wrote: Alright. I think I know what's going on, but I don't know how to fix it, simply because I'm not accustomed to the source code yet. The problem is that Dial 1 seem to share WS resources with the button on row 0, column 0. Dial 2, share WS resources with button on row 0, column 1. Dial 3 on row 0, column 2 and Dial 4 on row 0, column 3. I.e. dials seem to conflict with the four buttons on the first row. Maybe @ybizeul <https://github.com/ybizeul> would have an idea of why that is? I might be able to spend some time on this eventually, but not tonight. — Reply to this email directly, view it on GitHub <#28 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANLEVK7T72TH5WT3YFOO5SLWZD74DANCNFSM6AAAAAAVAODACM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[ybizeul]

Great job guys ! So I’ll take a deeper look later, but if I understand correctly, dials and button shouldn’t share the same WebSocket ?
Unique WS urls are maintained in an array and referenced for each button or dial, and I thought it wouldn’t be an issue but maybe it is…

I’ll take a look and update here.