• 10 dec 2017: forum version update. In case of issues use this topic.
  • 30 nov 2017: pilight moved servers. In case of issues use this topic.
Hello There, Guest! Login Register


Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
http action
#11
What do you think of this:

Imho it would be better if the url is not the id of the protocol but a setting, so we can have multiple devices for the same url, but with different parameters or intervals.

Also I would prefer having separate options for request parameters and content.

I would suggest to make the interval an optional setting of the http protocol and to add a param setting and a device state.

Then let the protocol set its state to "busy" right before it does an http request (in the main thread) and set it to "ready" when the request has finished (in the callback).
That way we don't need a separate TRIGGER device.
Other rules then can act on those state changes.

If interval is defined, the protocol runs automatically on that interval using the method and param settings of the device. The http action then has no effect, just logs a notice if used anyway.

If interval is not defined the action can be used to tell the device to execute once, optionally providing params and method.

http protocol and rules configured for action triggered requests:

We need two devices (one for on and one for off) so other rules can distinguish between both.

Code:
"watering_on": {
"protocol": [ "http" ],
"id": [{
   "id": 1
}],
"url": "http://www.pilight.org/"
"method": "get",
"status": 200,
"mimetype": "application/json",
"content": "state=off",
"param": "",
"size": 9,
"state": "ready"
},
"watering_off": {
"protocol": [ "http" ],
"id": [{
   "id": 2
}],
"url": "http://www.pilight.org/"
"method": "get",
"status": 200,
"mimetype": "application/json",
"content": "state=off",
"param": "",
"size": 9,
"state": "ready"
}

Code:
"switch_watering_on:"{
"rule": {
IF ... THEN http DEVICE watering_on PARAM  state=some_device.state&device=garden
...
}
},
"switch_watering_off:"{
"rule": {
IF ... THEN http DEVICE watering_off PARAM  state=some_device.state&device=garden
...
}
}

in other rule process the result of the action:

Code:
"rule" {
IF watering_on.state == ready THEN .....
...
},

http protocols configured for repeated http requests on defined intervals:

First one runs every minute and does a request for status, second one runs every 5 minutes and does a request for values.

Code:
"status_request": {
"protocol": [ "http" ],
"id": [{
   "id": 3
}],
"url": "http://www.pilight.org/"
"method": "post",
"status": 200,
"mimetype": "application/json",
"content": "status=normal",
"param": "command=get_status",
"size": 6,
"interval": 60,
"state": "ready"
},
"values_request": {
"protocol": [ "http" ],
"id": [{
   "id": 4
}],
"url": "http://www.pilight.org/"
"method": "post",
"status": 200,
"mimetype": "application/json",
"content": "flow=off&soil=dry&temp=16&humi=48&power=ok&mode=pilight",
"param": "command=get_values",
"size": 55,
"interval": 300,
"state": "ready"
}

A different approach could be to drop the interval completely and leave it to the user to use time based rules for that purpose:

Code:
"do_status-request:"{
"rule": {
IF  dt.SECOND == 0 THEN http DEVICE status_request
...
}
},
"do_values_request:"{
"rule": {
IF  (dt.MINUTE % 5) == 0 THEN http DEVICE values_request
...
}
}
 
Reply
#12
(10-15-2017, 07:05 PM)Niek Wrote: What do you think of this:

Imho it would be better if the url is not the id of the protocol but a setting, so we can have multiple devices for the same url, but with different parameters or intervals.
Good point.

Quote:Also I would prefer having separate options for request parameters and content.

I would suggest to make the interval an optional setting of the http protocol
Ofc.

Quote:and to add a param setting and a device state.
What the difference between param and request?

Quote:Then let the protocol set its state to "busy" right before it does an http request (in the main thread) and set it to "ready" when the request has finished (in the callback).

That way we don't need a separate TRIGGER device.
Other rules then can act on those state changes.
True

Quote:If interval is defined, the protocol runs automatically on that interval using the method and param settings of the device. The http action then has no effect, just logs a notice if used anyway.
Yep

Quote:If interval is not defined the action can be used to tell the device to execute once, optionally providing params and method.
Yep

Quote:A different approach could be to drop the interval completely and leave it to the user to use time based rules for that purpose
I don't think that's a good idea.
 
Reply
#13
Yet another idea as an alternative to my original http action proposal.
You said the TRIGGER switch was a good idea, but that you didn't like the RESULT label and I agree.

Now, instead of having a full blown http protocol (which I think is a bit of an overkill), I could create a simple (passive) protocol that combines the functionality provided by the TRIGGER switch and the RESULT label. That way
1. there is no longer need for two devices (TRIGGER and RESULT)
2. we are not "abusing" the label device
3. all request info (size, code and data) is made available to other rules and those rules can be triggered by the device state.

The device can look like this:
Code:
"http_device": {
                        "protocol": [ "generic_http" ],
                        "id": [{
                                "id": 1
                        }],
                        "size": 2,
                        "code": 200,
                        "data": "OK",
                        "state": "ready"
                },

Rule:

Code:
IF ... THEN http GET|POST <url> DEVICE http_device MIMETYPE <mimetype> PARAM <parameters>

DEVICE is optional and can be omitted if the result of the http request is irrelevant.

MIMETYPE is only required for POST requests.

PARAM is optional

What do you think?
 
Reply
#14
What is the data posted?
 
Reply
#15
The data to be sent with the request is in the PARAM argument of the action.

In case of a GET it is automatically appended to the "url" parameter of http_get_content and in case of a POST it goes into the "post" parameter of http_post_content.
 
Reply
#16
@curlymo,

After playing around with various ways to realize the http functionality, my personal conclusion is that using a full blown http protocol that handles both request triggered on interval and request triggered by an action is like using a sledgehammer to crack a nut.

The only time I needed requests triggered on interval was for my garden watering system and those requests are only required in summer. So I am using the http action in rules that call it repeatedly only when necessary.

Since we we both were not enthousiastic about the use of a generic label to store the result of the http request, I implemented a new version of the http action and added a generic protocol like I proposed in a previous post. 
I have been using it for some time now and imho it is perfect Smile .

The config for the device looks like this:

Code:
"http_response_device": {
            "protocol": [ "generic_http_result" ],
            "id": [{
                "id": 1
            }],
            "mimetype": "text/html",
            "size": 4,
            "code": 200,
            "data": "test",
            "state": "ready"
        },

and a rule triggering the http action and one ore more rules acting upon the resiult:

Code:
IF ... THEN http GET|POST <url> [PARAM <parameters>] [MIMETYPE <mimetype>] [DEVICE <http_response_device>]

IF http_response_device.state == ready AND http_response_device.code == 200 THEN ....

PARAM (=data sent with the request) and MIMETYPE are optional. If you want to use the result of the http request in rules, DEVICE must be defined, otherwise it is also optional.

If you approve of this approach, I will make a PR for it.
 
Reply
#17
I think each call of the http action should always trigger an http_device update in which the returned http response is stored.

I would also suggest a generic action called set so the http_device can be updated without having to call the action.
Code:
IF .. THEN set DEVICE http_device OPTION mimetype TO text/html
IF .. THEN set DEVICE http_device OPTION data TO ?foo=bar AND set DEVICE http_device OPTION size TO 30

And while i'm thinking of this, it could also replace the label action:
Code:
IF .. THEN set DEVICE label_device OPTION label TO foo bar
IF .. THEN set DEVICE label_device OPTION color TO foo bar
 
Reply
#18
Quote:I think each call of the http action should always trigger an http_device update in which the returned http response is stored.

OK, I will make DEVICE mandatory.

Quote:I would also suggest a generic action called set so the http_device can be updated without having to call the action.

The values in the http device are those of the latest response of the http action and are a consistent set. What would be the use of allowing users to update individual values? 

Quote:And while i'm thinking of this, it could also replace the label action

Yes, if we decide to create a set  action, why not use it for labels as well. 
In that case, I would suggest however to do that completely separated from the PR for the http action and the http device.
 
Reply
#19
The set action is just something i was wondering about Smile

Love to see that http device PR. First do the device and a new PR for the action.
 
Reply
#20
OK, I will make those two PR's asap.

Happy new year (prettige jaarwisseling Smile )!
 
Reply
  


Possibly Related Threads...
Thread Author Replies Views Last Post
  _VARSTORE_ set action fourty2 1 665 05-19-2019, 09:07 PM
Last Post: curlymo
  skipping overridden action switch do1eh 2 494 01-19-2019, 05:25 PM
Last Post: do1eh
  action: Pushbullet bazb 24 10,335 01-04-2018, 08:38 PM
Last Post: curlymo
  action: pushover Niek 36 16,229 12-03-2017, 11:13 AM
Last Post: Alex
  action: file Niek 14 3,630 06-23-2016, 04:02 PM
Last Post: Niek
  action: switch Niek 54 18,747 03-31-2016, 06:24 PM
Last Post: jjj
  action: program bazb 16 7,379 03-31-2016, 09:14 AM
Last Post: Niek
  action: toggle Niek 1 2,381 02-19-2016, 03:04 PM
Last Post: Joeks
  action: dim terrar 10 5,625 08-13-2015, 05:13 PM
Last Post: terrar
  Event action sipcal to make a voip phonecall pieterd 7 3,988 05-15-2015, 05:47 PM
Last Post: koos147

Forum Jump:


Browsing: 1 Guest(s)