v4.3.5.1 - stable

This forum will contain general news and announcements made by radio42.
User avatar
radio42
Site Admin
Posts: 8295
Joined: 05 Apr 2012 16:26
Location: Hamburg, Germany
Contact:
v4.3.5.1 - stable

Post by radio42 »

Version 4.3.5.0-.1 is out!

What's New?
  • New *[EXEC:{command}] macro function added
  • New REST API Server added to the GPIO Client
  • Various optimizations and smaller bug-fixes
  • stable
New *[EXEC:{command}] macro function added
Syntax: *[EXEC:{controlcommand}]
Parameters: {controlcommand} the control-command to execute
This new macro function returns the reply of a given control-command referenced by a controlcommand.
Example:
*[EXEC:{MIXER_INPUT_VOLUME_GET MIC1}]
Will result to a string containing the reply of the command MIXER_INPUT_VOLUME_GET MIC1, e.g. it will reply 1 if the fader is fully up.

New REST API Server added to the GPIO Client
The GPIO Client application now hosts a REST API server. I.e. you can now use a standard REST API to send commands to ProppFrexx. You configure the base address in the settings. Note, that commands are send to the sub-address '/commands', e.g. http://localhost:8080/commands.
Note, that when you want to run the REST API using a local IP address, the GPIO Client must run with elevated rights as an Administrator (i.e. if you start it automatically from with ProppFrexx ONAIR, thus must run as Admin as well).
The REST API uses Basic-Authentication (needs to be send in the header; the username is always 'ProppFrexx', the password is configured in the settings) and the body (payload) will contain the control-commands to execute. These can either be send as text/plain (e.g. encoded in UTF-8), while each line contains one command to execute - pretty much like the well known TCP interface.
But the body can also be in application/json notation. In this case the body be an array of commands.
For example: ["SHOW_ALERT_WINDOW Test|Message 1", "SHOW_ALERT_WINDOW Test|Message 2"]
The response will contain the reply messages (either one line per command or one array element per command).
phonic
Posts: 327
Joined: 06 Mar 2019 14:45
Re: v4.3.5.0 - stable

Post by phonic »

May I ask more details on the REST API implementation.
Do I assume correctly that the information entered into the URL determines the protocol(http or https), domain and port that needs to be used to access the API? The reason I ask is that the REST API does not enable if anything other than the default "http://localhost:8080" is entered.
User avatar
radio42
Site Admin
Posts: 8295
Joined: 05 Apr 2012 16:26
Location: Hamburg, Germany
Contact:
Re: v4.3.5.0 - stable

Post by radio42 »

What URL did you try?
When you want to enable https - you need to register an official certificate with your Windows system and bind that to your given port address. I cannot provide that for you. If you don’t know how to do this, you need to ask your administrator.
However, note, that https is l my needed for public facing APIs - and I assume, that this is typically not the case here - as such, a classic http address is totally fine.

And yes, typically the host is localist resp. 127.0.0.1, as the REST Server runs locally on the GPIO client, but you can also specify the direct IP of that PC - any other address wouldn’t make sense.
The port number however can be freely chosen!
phonic
Posts: 327
Joined: 06 Mar 2019 14:45
Re: v4.3.5.0 - stable

Post by phonic »

radio42 wrote: 25 Mar 2023 20:27 What URL did you try?
When you want to enable https - you need to register an official certificate with your Windows system and bind that to your given port address. I cannot provide that for you. If you don’t know how to do this, you need to ask your administrator.
However, note, that https is l my needed for public facing APIs - and I assume, that this is typically not the case here - as such, a classic http address is totally fine.

And yes, typically the host is localist resp. 127.0.0.1, as the REST Server runs locally on the GPIO client, but you can also specify the direct IP of that PC - any other address wouldn’t make sense.
The port number however can be freely chosen!
Thanks for your reply. I just did a simple test from a linux server on the same network using curl and basic auth to to the ip of the PC running ProppFrexx. First time with GPIO REST API using the defaults "localhost:8080" and got "HTTP Error 400. The request hostname is invalid." with 127.0.0.1:8080. It did not open the port. I've noticed it needs to have the trailing "/" or it will not enable the server, but using anything other than the localhost loopback IP address it will not enable. maybe I'm not understanding this correctly, but I was under the impression the is just a standard REST API with basic auth and should be accessible on the provided port and interface.
User avatar
radio42
Site Admin
Posts: 8295
Joined: 05 Apr 2012 16:26
Location: Hamburg, Germany
Contact:
Re: v4.3.5.0 - stable

Post by radio42 »

Yes it is - ie. the default address should work fine - you might modify the port as said.

And yes, it uses Basic Auth with the username ‚ProppFrexx‘ and the password specified in the GPIO client. Ie. the auth must contain "Basic ProppFrexx:password" - whereas ProppFrexx:password needs to be base64 encoded.

Any commands needs to be send to the sub-address /commands, eg. to the address: http://localhost:8080/commands

Error 400 however indicates, that your request has no body!
Ie. the body of the request must contain the control-command you POST to ProppFrexx. You can send the command eg. in text/plain. Ie. the command is NOT send as URL params, but as the body of the request.

Here are two sample screenshots using Postman:
Postman-Auth.png
Postman-Body.png
phonic
Posts: 327
Joined: 06 Mar 2019 14:45
Re: v4.3.5.0 - stable

Post by phonic »

No I did not send any commend I was just giving it a first test using curl. I was expecting a auth failure as I did not encode the password. How I know about the base64 and command sub address I will give it another go.

Thanks for your help.
User avatar
radio42
Site Admin
Posts: 8295
Joined: 05 Apr 2012 16:26
Location: Hamburg, Germany
Contact:
Re: v4.3.5.0 - stable

Post by radio42 »

Basic Auth is always base64 encoded. The sub-address and example is now given.
I hope you can now make a test. Else you can try Postman as provided in my pictures… when using 'Curl', the --user param will specify the username:password in clear text format, e.g.:

Code: Select all

curl -X POST http://localhost:8080/commands
   -H "Content-Type: application/json" 
   -d '["SHOW_ALERT_WINDOW TEST"]'
   --user "ProppFrexx:password"
phonic
Posts: 327
Joined: 06 Mar 2019 14:45
Re: v4.3.5.0 - stable

Post by phonic »

radio42 wrote: 25 Mar 2023 23:02 Basic Auth is always base64 encoded. The sub-address and example is now given.
I hope you can now make a test. Else you can try Postman as provided in my pictures… when using 'Curl', the --user param will specify the username:password in clear text format, e.g.:

Code: Select all

curl -X POST http://localhost:8080/commands
   -H "Content-Type: application/json" 
   -d '["SHOW_ALERT_WINDOW TEST"]'
   --user "ProppFrexx:password"
Thanks for your reply.
I'm well up on using curl and accessing APIs over years, but issue I'm getting is the same error no matter what I do: "Bad Request - Invalid hostname" when accessing remotely from another machine.

I have now installed curl on the local windows machine running ProppFrexx, and is workings perfectly as expected and get the response "OK" and the commands are carried out in ProppFrexx, but can't get the same success when accessing from another machine on the same network. I've noticed the server will not start on anything other can the localhost or 127.0.0.1, and entering http://127.0.0.1:8080/ appears to bind to the localhost. Can you not bind to the network interface of the machine using it's IP address: "http://192.168.10.100:8080/"?
User avatar
radio42
Site Admin
Posts: 8295
Joined: 05 Apr 2012 16:26
Location: Hamburg, Germany
Contact:
Re: v4.3.5.1 - stable

Post by radio42 »

When you specify a different address than the localhost, the Windows operation system might block any requests, due to security issues by default.
I.e. you need to run the application (the GPIO client) as an Administrator.
Then it shoud work!

I just noticed, that on some OS a required dll for JSON might be missing - i.e. please currently test with the body in text/plain (and not application/json) - I am just investigating this JSON issue!

Update:
Here is the missing .dll needed for JSON was just added to the v4.3.5.1 update.
phonic
Posts: 327
Joined: 06 Mar 2019 14:45
Re: v4.3.5.0 - stable

Post by phonic »

radio42 wrote: 26 Mar 2023 12:13 When you specify a different address than the localhost, the Windows operation system might block any requests, due to security issues by default.
I.e. you need to run the application (the GPIO client) as an Administrator.
Then it shoud work!

I just noticed, that on some OS a required dll for JSON might be missing - i.e. please currently test with the body in text/plain (and not application/json) - I am just investigating this JSON issue!

Update:
Here is the missing .dll needed for JSON - just unzip the link to the installation directory (I provide an official update soon): https://www.proppfrexx.radio42.com/download/GPIO.zip
Hi,
Yes late last night I thought it maybe a privilege issue with the listener, so I quickly issued netsh http add urlacl ... to resolve the issue for the url and now works fine.
I noticed the json issue as the reply would be "Remotely dispatched", and sent as plain text eg SHOW_ALERT_WINDOW HELLLO!! and got "OK" and worked fine.

Post Reply