Welcome to the Cumulus Support forum.

Latest Cumulus MX V4 release 4.4.2 (build 4085) - 12 March 2025

Latest Cumulus MX V3 release 3.28.6 (build 3283) - 21 March 2024

Legacy Cumulus 1 release 1.9.4 (build 1099) - 28 November 2014
(a patch is available for 1.9.4 build 1099 that extends the date range of drop-down menus to 2030)

Download the Software (Cumulus MX / Cumulus 1 and other related items) from the Wiki

If you are posting a new Topic about an error or if you need help PLEASE read this first viewtopic.php?p=164080#p164080

MX Custom HTTP requests

Topics about the Beta trials up to Build 3043, the last build by Cumulus's founder Steve Loft. It was by this time way out of Beta but Steve wanted to keep it that way until he made a decision on his and Cumulus's future.

Moderator: mcrossley

Locked
User avatar
mcrossley
Posts: 14388
Joined: Thu 07 Jan 2010 9:44 pm
Weather Station: Davis VP2/WLL
Operating System: Bullseye Lite rPi
Location: Wilmslow, Cheshire, UK
Contact:

MX Custom HTTP requests

Post by mcrossley »

Steve, I think the custom HTTP requests are GETs, correct?
Any plans to make GET or POST selectable?
If I'm correct I'll add a feature request for this.
User avatar
steve
Cumulus Author
Posts: 26672
Joined: Mon 02 Jun 2008 6:49 pm
Weather Station: None
Operating System: None
Location: Vienne, France
Contact:

Re: MX Custom HTTP requests

Post by steve »

Yes, it always does GETS currently. It wouldn't be too hard to do POSTs as an option, the main complication is how to supply the parameters to Cumulus, as they need to be encoded as name/value pairs rather than the "...?foo=x&bar=y" syntax passed with the URL as with GET. I guess a simple approach would be to specify it in the GET form, and then Cumulus could parse it and split it up into name/value pairs.
Steve
User avatar
mcrossley
Posts: 14388
Joined: Thu 07 Jan 2010 9:44 pm
Weather Station: Davis VP2/WLL
Operating System: Bullseye Lite rPi
Location: Wilmslow, Cheshire, UK
Contact:

Re: MX Custom HTTP requests

Post by mcrossley »

I guess the simplest would be two fields, one for the server address, another for parameters/values, concatenate them for GETs (with a '?' separator), and put the parameters/values in the body for POSTS.

That would break the existing config file entries though.

I'll raise a feature request...
Locked