-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WS v2, StreamDeck Plus WS Socket not Stable #28
Comments
Thanks Alan, |
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. |
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 |
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 |
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 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 So, all in all. I can't really seem to reproduce this. FWIW, I'm running Node-RED v2.2.2 and |
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:
***@***.***>
|
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:
> ***@***.***>
>
|
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? |
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:
***@***.***>
|
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. |
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: ***@***.***>
|
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:
***@***.***>
|
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. Maybe @ybizeul would have an idea of why that is? I might be able to spend some time on this eventually, but not tonight. |
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:
***@***.***>
|
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 ? I’ll take a look and update here. |
I have connection issues as well with the plugin. Sometimes it works and sometimes it doesn't. I think it doesn't try to reconnect. Running Streamdeck + with latest software as of todays date, |
Did some more testing and it definitely seems like there is a reconnection issue in play. If I close the stream deck app and relaunch it the ws connects but won't reconnect if the connection is lost. |
I think I'm also running into this issue. If I mess around making/editing buttons in the Stream Deck software, eventually the WebSocket will disconnect. The only way I've found to get it to reconnect is to quit and relaunch the Stream Deck software. I'm running Stream Deck software version 6.3.0.18948, Node Red version 3.0.2 through Docker, and |
Can someone confirm this is only related to StreamDeck Plus ? Or having this issue with regular StreamDeck as well ? |
Yes, I can confirm this issue only occurs on the StreamDeck Plus when using the Node-Red Web Socket Node. I have a StreamDeck XL and a 15 button StreamDeck, both work just fine with your plugin and Node res WebSocket Node. Alan |
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
The text was updated successfully, but these errors were encountered: