-
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
sd-output node sends "setState" instead of "setImage" #7
Comments
Thanks for your report. The way it has been implemented is if Title and Image of the node configuration is empty, then it's assumed to be a state change. The 3 lines are actually a "or" option, but I didn't figure out how to present it in a more obvious way. Here is a sample flow to illustrate it, let me know if you think there is a bug :
|
As currently written, I can set the event type to setState and also provide a title, and it's ignored without telling me why. Is it ignored because there can only be one event type and you're limited by the Stream Deck? If so, perhaps instead of having "state" and "title" and "image" as fields, there can simply be "event" and "payload" where the payload is of the type expected by the event. That removes the confusion of having 2/3 of the available fields be ignored and should also simplify your control loop. If you're not limited by the Stream Deck, the best case scenario is to process it on the Deck - if there's an image, set it. If there's a title, set it. If there's a state that is different than the current state set it (or just set it regardless, because it's idempotent). Even if you are limited, perhaps you can hide that. If there are multiple fields, have the sd-output node send multiple messages. Then it truly becomes a convenience node. |
It's a good idea I think. As far as I know, a message can only carry one type of event, but I guess I could make so that multiple messages are sent if multiple fields are set. I agree the current implementation leads to a lot of confusion and needs to be fixed :
|
As long as you clearly document what it does, either option is fine. Personally, I favor the "send multiple messages for me" option because it's less work for the user. In my live streams, for example, I have a multi-state button for muting audio. I want to change the state and also change the title to say, "MUTED." I would like to do this with a single node and a single, combined payload. If I need to update the state based on the successful completion of an action (e.g. only change to the muted image if the source is actually muted), then I would update the title and image and use a single-state button. Any time I interact with a button, I'm going to make at least one change. If I need multiple interactions in one action, I would still like to do the same amount of work with Node-RED (e.g. configure one payload), and have the "send multiple messages" part occur transparently. There's no direct benefit to me having to code multiple messages, other than understanding that multiple messages are being sent. A node that does that for me is my friend. Still loving the project, btw. Last night I set it up to show and update QR codes for URLs during the stream, updating the image on the button to be the actual QR code being shown. It's accurate enough that my phone recognizes the QR code within the button and will open the URL. Out of the 27 buttons that I have configured on my Stream Deck XL for the show, 20 of them are using your project to control Streamlabs OBS via Node-RED. Thank you again for building this. |
That is great feedback ! I just had a revelation, something that I probably thought about while doing this, but forgot. The actual behaviour is that if you have just the state specified, it'll trigger a state change event for the button. That is necessary so people can choose to update the status of the states without actually changing the state that is displayed, or, they can trigger a state change by just changing the state without setting a value. To do what you're doing, I sometimes take a different approach, and try to configure anything that is static directly in Stream Deck, like the title or an icon that represents a state. I set both states in Stream Deck, and then handle the keyup event and if flip the state in the answer, leaving to Stream Deck to change icon and test. The documentation is actually clear about this, as long as you understand Stream Deck SDK, which I shouldn't assume users do
Not a silver bullet, but just some thoughts to consider when redesigning this, which I will ! |
Hello again!
I'm trying to work through the example in the README, but using the sd-input/output nodes instead. It appears that sd-output sends
setState
for anything with an image, but the example usessetImage
. The output node doesn't work unless I use a change node afterward and convert theevent
field back tosetImage
. Bug? Something I'm missing?The text was updated successfully, but these errors were encountered: