- Thread starter Palakis
- Start date
bcoyle
Member
obs 28 and 29 use websokets v5. But there is a compatible v4 style plugin available.You need to search for it.
I am struggling to add monitors to a scene. I can get a list of monitors, I can create a scene item and then set it's transform but the monitor does not display. I can see the monitors listed in the "Sources" panel but In the central bar I just see "[Device not connected or not available]" until I open and close the properties panel (don't have to change anything) and then the monitor display appears exactly as I want it. Can any one advise which calls I need to make to get both my monitors into the scene properly purely via code?
I have exported the "Scene Collection" and the only difference between the JSON files is that the working one has a different Monitor ID in the source settings section e.g.
"monitor_id": "\\\\?\\DISPLAY#DEL415D#5&461e0e2&0&UID4352#{e6f07b5f-ee97-4a90-b076-33f57bf4eaa7}"
instead of this which I gave as the monitor ID
"monitor_id": "DELL U2419H (2)(1)",
Can anyone identify what I am doing wrong?
Just to share it with you, I just ran File Check Integrity, and the OBS was restarted, so the WebSocket Server Settings just appeared after that. So, if it is not necessary to understand it I will understand.
therentabrain
Member
FWIW I believe you can use Advanced Scene Switcher to automate changing stream keys.
does anyone know if its possible to control the specific settings of plugins using web sockets ? or does it just control main OBS functions ? I have installed source switcher plugin... id like to find a way to change the "duration" value in the "time switch" mode, also the "duration" value of the "transition"... i have got web sockets working to do basic scene switching but im trying to understand how to change parameters in filters or if its even possible ?
bcoyle
Member
Hi I don't know if this applies to obs 28+, but in the obs v4 socket api you can use the following command to
TALK TO SOME FILTERS". I use these commands to set opacity.
I don't know if Adv SS will handle these remote commands.
Anyway, hope that helps
"sourceName", SourceName, "filterName", Filtername, "filterSettings", Settings)
"sourceName" =OVERLAY_BLACK
"filtername" = FADE_CONTROL
"settings = {"opacity":0.99}
Sample command string
{"request-type":"SetSourceFilterSettings","message-id":"77,134,OVERLAY_BLACK,FADE_CONTROL","sourceName":"OVERLAY_BLACK","filterName":"FADE_CONTROL","filterSettings":{"opacity":0.99}}
SetSourceFilterSettings
- Added in v4.5.0
Update settings of a filter
Request Fields:
| Name | Type | Description |
|---|---|---|
| sourceName | String | Name of the source to which the filter belongs |
| filterName | String | Name of the filter to reconfigure |
| filterSettings | Object | New settings. These will be merged to the current filter settings. |
Response Items:
No additional response items.
SetSourceFilterVisibility
- Added in v4.7.0
Change the visibility/enabled state of a filter
Request Fields:
| Name | Type | Description |
|---|---|---|
| sourceName | String | Source name |
| filterName | String | Source filter name |
| filterEnabled | Boolean | New filter state |
bcoyle
Member
you're welcome
I'm sending command SetCurrentProgramScene code below. It works, but there's a 2 second delay between OBS websocket receiving the command to it executing it (live log).
I've tried other json websocket commands, like start or stopping stream, and the reaction is immediate.
Anyone encounter this?
{
"d": {
"requestData": {
"sceneName": "Scene1"
},
"requestType": "SetCurrentProgramScene",
"requestId": "99999"
},
"op": 6
}
I've tried other json websocket commands, like start or stopping stream, and the reaction is immediate.
Anyone encounter this?
{
"d": {
"requestData": {
"sceneName": "Scene1"
},
"requestType": "SetCurrentProgramScene",
"requestId": "99999"
},
"op": 6
}
AND after I posted this, i discovered my destination OBS machine had a blank "stinger" file playing on each transition without me seeing it. DOh!
keran_lee
New Member
You don’t actually need a special browser “plugin” on the Raspberry Pi to remote-control OBS — what matters is that obs-websocket (the server) is installed in the OBS host, and the Pi just runs a Web UI (Chrome/Firefox) that connects to that websocket.
If you’re trying to run obs-websocket on the Pi itself (i.e. OBS on the Pi), prebuilt .deb installers are usually amd64 only, so you’ll likely need to build obs-websocket from source for ARM: install build deps (cmake, build-essential, libobs dev headers), clone the repo, checkout the release tag and run a normal cmake/make/install flow.
For the front end (obs-tablet-remote or similar) on the Pi you’ll want a modern Node runtime — update Node (NodeSource or nvm) if the Pi’s distro ships an old version.
If you serve the UI over HTTPS and proxy to the OBS websocket, make sure nginx (or your proxy) forwards websocket headers (proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_http_version 1.1;) so the browser can establish a wss:// session.
The “security ok but browser won’t handle it” symptom is usually mixed-content or insecure ws:// from an https:// page — switch to wss:// or proxy/terminate TLS at nginx to fix it.
To run the Node UI reliably on a Pi, use PM2 or a simple systemd unit so it starts at boot and restarts on crashes.
If you want to avoid heavy Pi builds, the simplest approach is: run OBS + obs-websocket on your desktop (x86), and control it from the Pi browser over the LAN — no compiling, just configure firewall and websocket port.
Finally, if you need to compile on the Pi, double-check your OBS SDK/dev headers version matches the obs-websocket release you’re building — mismatched headers are a common source of build failures.
If you’re trying to run obs-websocket on the Pi itself (i.e. OBS on the Pi), prebuilt .deb installers are usually amd64 only, so you’ll likely need to build obs-websocket from source for ARM: install build deps (cmake, build-essential, libobs dev headers), clone the repo, checkout the release tag and run a normal cmake/make/install flow.
For the front end (obs-tablet-remote or similar) on the Pi you’ll want a modern Node runtime — update Node (NodeSource or nvm) if the Pi’s distro ships an old version.
If you serve the UI over HTTPS and proxy to the OBS websocket, make sure nginx (or your proxy) forwards websocket headers (proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_http_version 1.1;) so the browser can establish a wss:// session.
The “security ok but browser won’t handle it” symptom is usually mixed-content or insecure ws:// from an https:// page — switch to wss:// or proxy/terminate TLS at nginx to fix it.
To run the Node UI reliably on a Pi, use PM2 or a simple systemd unit so it starts at boot and restarts on crashes.
If you want to avoid heavy Pi builds, the simplest approach is: run OBS + obs-websocket on your desktop (x86), and control it from the Pi browser over the LAN — no compiling, just configure firewall and websocket port.
Finally, if you need to compile on the Pi, double-check your OBS SDK/dev headers version matches the obs-websocket release you’re building — mismatched headers are a common source of build failures.