Feature Requests

Glad you were able to find a solution that worked for you.

Cheers!

I tried your plugin to substitute FantasticWeather. But I can't get any data. This is probably because my API uses OAuth 2.0:

https://developer.srgssr.ch/faq

Is there any way you can implement this?

Thank you

I tried your plugin to substitute FantasticWeather. But I can't get any data. This is probably because my API uses OAuth 2.0:

https://developer.srgssr.ch/faq

Is there any way you can implement this?

Thank you

I took a quick look at the API docs and it looks like that service should work with the existing plugin. Are you using the "Bearer" authentication type?

Yes I tried, but it seems that I have to get the token first and it expires. Not sure how to automate this.

Yes I tried, but it seems that I have to get the token first and it expires. Not sure how to automate this.

Sorry, I should've been more clear. I should have asked if you were using the "Bearer" auth type instead of the "Token" auth type.

Have you tried the API with the Token auth type?

I do not have a token url.

I only have:
CONSUMER KEY
CONSUMER SECRET

Since I only have 50 request per day my testing capacities are limited.

Understood. I didn't write that particular authentication method into the plugin (it was added by @berkinet), but in looking over the code, the plugin asks for the token to be provided by the server and then submits the API call with "?access_token=XXXXXXX" to the end of the source URL. So if the token auth method within the plugin is going to work (it may not work), then the settings would be something like:

URL/Path: "https://URL that requests the actual data you want" (no quotes)

Method: Token
Token URL: "https://URL to obtain the authentication token from the server" (no quotes)
Password: CONSUMER KEY or CONSUMER SECRET

It may be that the token auth method won't work for your source. If that's the case--and if the authentication method your source uses is a universal one--we can see about getting it added to the plugin.

This actually works in Terminal:

Code: Select all

curl -X POST \
  'https://api.srgssr.ch/oauth/v1/accesstoken?grant_type=client_credentials' \
  -H 'Authorization: Basic <"KEY:SECRET"MANUALLY CONVERTED TO base64 >' \
  -H 'Cache-Control: no-cache' \
  -H 'Content-Length: 0' \
  -H 'Postman-Token: 24264e32-2de0-f1e3-f3f8-eab014bb6d76'

curl -X GET \
  'https://api.srgssr.ch/srf-meteo/colors' \
  -H 'Authorization: Bearer MANUALLY ADDED RECEIVED_TOKEN' \
  -H 'Cache-Control: no-cache' \
  -H 'Postman-Token: 56128353-805e-4974-6689-5ef6d86e2d80'


The received token expires.

I don't know how to make it work with the plugin.

Thanks -- that's going to be helpful in figuring this out. I have some IRL commitments today but will look at this asap and see whether this can be done/added to the plugin.

Thanks, please let me know if I can help with testing. I have 50 tries today.

I noticed that the 2022.0.1 version of GhostXML plugin writes to Indigo log every time a Ghost device is getting updated. I have several weather-related Ghost devices that update every 10 minutes, so this adds a lot of log entries.
I can easily suppress this code in the plugin (code line #1412), but I was wondering whether you could add a pref check box in the device config to suppress log entries for simple 'device updates'.

The quick fix would be to up the plugin logging to "Warning Messages" which would suppress device update messages. You might miss a few other standard messages, but with this plugin, "device updated" messages are the lion's share for sure.

I have a device that needs certain http headers sent in the API request to process the request properly.

The feature request would be a field in the device config to specify headers.

I looked at the code and was trying to hack in the headers, but I must not be finding the proper code section. My device does not use authentication (Authentication:None in the configuration). It looked like the request code was on line 1027 ("proc = requests.get(url, timeout=5)") . I tried adding headers here, but this did not result in the headers being sent.

@Automaton - is it a public API that I can test against? Please post here or DM the details.

It'll likely be towards the end of the week before I can take a look at this, so no rush.

It is not a public API, it is an API on Yamaha MusicCast devices. This describes the Events section, below:

11.2. Conditions
When a request header from an external application contains fields shown below, a Device issues events of status changes. If no event is required, do not include the specified fields:
X-AppName:MusicCast/XXX
X-AppPort:YYY
*Here XXX stands for an application version, YYY shows event receiving port.
Following is an example of MusicCast CONTROLLER:
X-AppName:MusicCast/1.40(iOS) X-AppPort:41100
Event notification timeouts in 10 minutes if no further event request is sent from an IP address set as event receiving device. If another request is made within 10 minutes of previous request, the timeout duration is reset and extended.
Event receiving port will be overwritten if a different port number is sent as a request by the registered device using X-AppPort.

In my code that calls the API, the headers look like this:

Code: Select all

# Headers to enable UDP status broadcast
   headers = {'X-AppName':'MusicCast/1.71', 'X-AppPort':'41100'}
   response = requests.request("GET", url, headers=headers, data=payload)