No support for ANY of the STATUS REST API calls?

[Jibun-no-Kage]

No support for ANY of the STATUS REST API calls?

For example...

GET /version Requests the general information about the currently active ProPresenter instance. GET /v1/status/layers Requests the status of all available layers. GET /v1/status/stage_screens Requests the status of the stage screens. PUT /v1/status/stage_screens Sets the status of the stage screens. GET /v1/status/audience_screens Requests the status of the audience screens. PUT /v1/status/audience_screens Sets the status of the audience screens.

I am trying to issue via button on StreamDesk, the ABILITY to enable and disable Audience_screens and Stage_screens. Via curl for example the following will enable and disable all audience screens in PropP...

curl -X 'PUT' \ 'http://localhost:50001/v1/status/audience_screens' \ -H 'accept: /' \ -H 'Content-Type: application/json' \ -d 'true'

curl -X 'PUT' \ 'http://localhost:50001/v1/status/audience_screens' \ -H 'accept: /' \ -H 'Content-Type: application/json' \ -d 'false'

[paulstec]

Have you tried to accomplish what you need with the Generic HTTP Requests module?

I know it's not documented for production use. However, I find it useful when I want one of those API calls implemented quickly.

The only slowdown has been a few of the API calls have bugs that can be reported to Renewed Vision.

[Jibun-no-Kage]

Yes... I got that working part way... get this.... I can TURN ON the audience and stage screens via the direct API call via the generic module. But I cannot TURN OFF the audience and stage screens... using the SAME URL but data as TRUE for ON and FALSE for OFF.

If I do a direct curl.... say from Windows or Linux CLI, on and off works as expected, but via the generic module only ON or pass true, works! It is not the ProPresenter API its self, since the direct curl works. So it appears the generic module is doing something odd? Why would just changing the data value make that big a difference?

These work via curl...

Turn On... curl -X 'PUT' 'http://192.168.1.34:50001/v1/status/stage_screens' -H 'accept: /' -H 'Content-Type: application/json' -d true curl -X 'PUT' 'http://192.168.1.34:50001/v1/status/audience_screens' -H 'accept: /' -H 'Content-Type: application/json' -d 'true' Turn Off... curl -X 'PUT' 'http://192.168.1.34:50001/v1/status/stage_screens' -H 'accept: /' -H 'Content-Type: application/json' -d false curl -X 'PUT' 'http://192.168.1.34:50001/v1/status/audience_screens' -H 'accept: /' -H 'Content-Type: application/json' -d 'false'

As I noted above, the turn off requests fail in http generic module in companion. Literally identical to turn on requests, same exact URLs, just data field set false versus true. Weird parsing error?

Log... I setup 4 buttons Audience On, Audience Off, Stage On, and Stage Off, just to test. The off buttons generate the errors seen below...

               log: You can view older logs in the configuration folder

24.06.30 11:44:59 Surface/Handler/streamdeck:A00SA4182LGUSI: Button 1/0/1 pressed 24.06.30 11:44:59 Surface/Handler/streamdeck:A00SA4182LGUSI: Button 1/0/1 released 24.06.30 11:45:00 Surface/Handler/streamdeck:A00SA4182LGUSI: Button 1/0/2 pressed 24.06.30 11:45:00 Surface/Handler/streamdeck:A00SA4182LGUSI: Button 1/0/2 released 24.06.30 11:45:02 Surface/Handler/streamdeck:A00SA4182LGUSI: Button 1/1/1 pressed 24.06.30 11:45:02 Instance/Wrapper/http: HTTP PUT Request failed (Response code 400 (Bad Request)) 24.06.30 11:45:02 Surface/Handler/streamdeck:A00SA4182LGUSI: Button 1/1/1 released 24.06.30 11:45:03 Surface/Handler/streamdeck:A00SA4182LGUSI: Button 1/1/2 pressed 24.06.30 11:45:03 Instance/Wrapper/http: HTTP PUT Request failed (Response code 400 (Bad Request)) 24.06.30 11:45:04 Surface/Handler/streamdeck:A00SA4182LGUSI: Button 1/1/2 released

Body field, i.e. data sent with URL...

[paulstec]

Guessing that the "false" in the body is not being interpreted as false.

Will give it a quick test on my system.

[paulstec]

Got it. In the Companion button body put "true" or "false". Be sure to include the quotes.

[greyshirtguy]

The existing code uses an undocumented API that is deprecated internally at RenewedVision. It's getting a little buggy and they told me they won't be fixing some of the bugs I shared and to move to the new API... Rather than mix nice new API with old buggy API - I am making a new module that uses new API... It's in the works now (I hope to have a rought working module in next month)

In the meantime, yes, you can achieve anything using the generic HTTP module and triggers for feedback.... And yeah - sending false took me a few tries to get right too!

This is opensource, so if anyone else wants to add the new API to the old module (and support it) - they can !...

[Jibun-no-Kage]

@greyshirtguy ... in a word WOW! Might nothing here the API versioning? Just for reference.

@paulstec ... Thanks! Nice catch. That was it! I tried 1 and 0, and I think single quotes, not sure if tried double quotes. But might have fat fingered it at some point. That true worked without quotes... really had me wondering.

Thanks Guys! Greatly appreciated!