Page 1 of 1

Feature Request: HTTP Post support.

Posted: Sat Aug 10, 2019 6:39 pm
by xannor
Would it be possible to add the ability for the HTTP push service to use POST as well. This would allow the meteobridge to participate in webhooks, as that spec requires post support. Bonus points for allowing to template the post message, but just supporting an empty post message and using the current query parameter system is good enough for most systems.

Re: Feature Request: HTTP Post support.

Posted: Sun Aug 11, 2019 2:53 am
by admin
Can you please outline what weather network can be supported by that, which cannot today?

Re: Feature Request: HTTP Post support.

Posted: Sun Aug 11, 2019 4:55 pm
by xannor
Not for weather networks, but for the add-on push services. All I am interested in is the ability to specify a POST request instead of a GET request with the HTTP push service. A lot of software and sites (i.e. home assistant, discord, IFTTT, github, etc) now support using web hooks, which are basically a quazi REST service where a server/client/etc can HTTP POST data either via query string or POST message contents provide a "push" event to that service, usually because the urls are long, controlled by the service, and not publicly published, no security auth is needed since you have to know the url to push and typically you cannot guess it.

The use I would like to use it for is with Home Assistant so I could have the meteobridge periodically push solar data for an automation to act upon (HA uses automations for its webhooks.) right now I work around it by having the GW1000 use the ha address as a custom ecowitt push, but I then have to parse out the sensor data I want, and I have to use NGINX to "proxy" the request to the URL HA expects from the URL the GW1000 expects.

The bonus was to be able to craft the POST message body using your template system instead of relying query parameters in the URL, but that would be much more complicated to implement and most webhook systems can process query parameters as easily as a message body, so POSTing an empty message body would work just as well for most needs.

Hopefully this explains what I am requesting better.