• 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
#1
@curlymo,

For quite a while I have been using the http action I created. Over time I enhanced it, and recently I adapted to the current development version. The next step will be to adapt it to the rewrite.

But, before continuing I would like your advice.

In a rule, the current version of the http action can be configured like this:

Code:
IF ... THEN http GET|POST <url> PARAM <parameters> RESULT <generic_label device> TRIGGER <generic_switch device>

PARAM, RESULT and TRIGGER are all optional.

If RESULT is defined, the data returned by the http request is stored in the label field of the generic_label device and the http code in the color field.

If TRIGGER is defined, the generic_switch is switched on when the http request has finished and the generic_label device has been updated. This way other rules can be triggered immediately in order to handle the result of the action, without the need for "polling" the result.

Code:
IF <generic_switch device>.state == on THEN ...

The the generic_switch device can be switched back to off by other rules, but, if it is still on, the action will also do that when it starts, so it is guaranteed that there will always be an off to on transition on completion of the action.

Note.
The generic_label defined as RESULT is intended as a data store and not intended to be displayed in the GUI. But if one would like to do that anyway, remember that the value of the color field is an http result code which is not a valid color code. In that case the TRIGGER can be used to fire a rule that copies the label value to a second label that is displayed in the GUI and set its color as desired.

Code:
if <generic_switch device>.state == on THEN label DEVICE <another label device> TO <generic_label device>.label COLOR <colorcode>

My question is, do you support this approach and could this http action be added to pilight (ofc after reviewing a PR), or do you have other ideas/plans for such an action?
 
Reply
#2
The problem with functions like these are the socket timeouts. You preferably don't want to block the i/o while waiting for responses. And if you are going to opt for non-blocking i/o (which is required anyway), then you need logic that triggers the final action asynchronously.

I would say that this would fit a protocol better? With standard HTTP protocol information like statuscode, response content, mimetype, size etc. And ofc a poll-interval.
 
Reply
#3
I'm a bit puzzled now. We had a discussion in this thread where I proposed my webswitch protocol and you said that an http action would be better than a protocol.

I have implemented both the webswitch protocol (could be renamed to http protocol) and the http action. I am using the webswitch to control my watering system and my surveillance system from pilight, both having a running/stopped state. I am using the http protocol to call gci scripts providing various data from other servers regularly.
 
Reply
#4
I forgot about that thread. The difference is that you made a webswitch protocol and i now think that was not pure enough. A pure http protocol is better with a POST or GET action. I also read that that i proposed a HTTP action, but i then didn't knew what i know now about non-blocking i/o and that's why a protocol is better.

Non-blocking i/o is the same reason why i believe datetime should be deprecated.

Code:
"protocol": [ "http" ],
"id": [{
   "url": "http://www.pilight.org/"
}],
"action": "post",
"status": 200,
"mimetype": "application/json",
"content": "state=on&device=garden",
"size": 100,
"poll-interval": 60

This protocol can be triggered as a POST, GET, or PUT to post content or retrieve content.

An addition http action should be used to coorperate with the HTTP protocol just like the label works for the label protocol.
 
Reply
#5
Not with you yetSmile

Imho a protocol with a poll interval is useful if you wish to do an http request on regular intervals (like the weater protocols do).

But that is not my intention. I want to let a rule do an http request only once when some conditon occurs (Eg. a sensor being activated). So that is more the way the sendmail action is being used. I don't yet see how to achieve this with a protocol with a corresponding action as you describe it.
I understand however that problems can occur if one would run the action too often. That can be prevented by adding a time condition to the rules with http actions. But some kind of queueing mechanism that automaticly enforces a minimal interval between http requests, without letting the http actions fail, would be useful.

Btw. the reason I made the webswitch protocol is to be able to control remote webbased services and see their actual states (running/stopped/pending) directly in the GUI, without the need for addional rules and status labels. But that protocol is activated by a normal switch action and not on an interval either.

So are we talking about different things here?
 
Reply
#6
The http protocol i proposed can either do a GET or a POST. In case of a GET, the content of the HTTP page is stored in the "content" attribute. In case of a POST the "content" attribute content is posted to the website.

With your comparison with the sendmail action. Whenever you trigger that action you cannot do anything with the possible succes or failure. You just don't know if it succeeded besides looking in the log file.
 
Reply
#7
(10-14-2017, 11:28 AM)curlymo Wrote: The http protocol i proposed can either do a GET or a POST. In case of a GET, the content of the HTTP page is stored in the "content" attribute. In case of a POST the "content" attribute content is posted to the website.

1. A POST can also return content (it depends on the website wether POST or GET is required and if any useful content is returnend), so I guess we would need two different "content" attributes.

2. Content (parameters) to be passed on to the website can be device values so the action must be able provide the (request)content to the protocol.

3. Having a poll interval seems to indicate that your http protocol is intended to run in a loop and only execute when the interval has passed. If that is the case, how to deal with subsequent rules triggering actions while the protocol is waiting until the interval time has passed?

Three possiblities I thought of:

a. Having a different http device for every different http action in the rules (which in fact would make the whole idea of a protocol/action combination useless and "bypass" the protection of the polling interval)
b. Having a queueing mechanism in the protocol
c. Adding a "ready" device option to the protocol that the the subsequent action(s) can check and loop until it is true (will require a locking mechanism I guess)

4. Subsequent http actions will make the http protocol update content, status and such. So when other rules need to to things based on the result of a specific http actions, there is no way to know for which one the data is relevant

5. Your proposed http protocol doesn't have a state. So rules cannot be triggered by it and will have to "poll" the status and content.

(10-14-2017, 11:28 AM)curlymo Wrote: With your comparison with the sendmail action. Whenever you trigger that action you cannot do anything with the possible succes or failure. You just don't know if it succeeded besides looking in the log file.

With the comparison with the sendmail actionI just meant the way it is being called in rules.

Unlike the the sendmail action, the http action has the RESULT and TRIGGER options. The tigger tells when the http is completed and the result provides both content and statuscode.
 
Reply
#8
1. True, but in this case a 200 code would be sufficient right?
2. Hence the HTTP action.
3. The point is that you don't want to rely on the result.
a. The http protocol would normally handle GET requests at a certain interval. So, when the protocol ran, it triggers the events and based on it's attributes a rule get's evaluated. Just like any other protocol.
b. An event http action can either trigger a http protocol POST or GET, but can't wait for the result. This happens asynchronously. So, there must be another rule that should handle the outcome of the HTTP POST or GET as soon as it's available.
4. Thus, you should have multiple HTTP protocols for each goal.
5. Why not, the label device also doesn't have a state, but those work fine in the rules as well. The eventing library is trigger by protocol attributes, a state is just one of those attributes.

Your last comment describes the exact issue. You cannot wait for the result of an HTTP GET or POST action inside the same rule.
 
Reply
#9
(10-14-2017, 02:20 PM)curlymo Wrote: 1. True, but in this case a 200 code would be sufficient right?
2. Hence the HTTP action.
3. The point is that you don't want to rely on the result.
a. The http protocol would normally handle GET requests at a certain interval. So, when the protocol ran, it triggers the events and based on it's attributes a rule get's evaluated. Just like any other protocol.
b. An event http action can either trigger a http protocol POST or GET, but can't wait for the result. This happens asynchronously. So, there must be another rule that should handle the outcome of the HTTP POST or GET as soon as it's available.
4. Thus, you should have multiple HTTP protocols for each goal.
5. Why not, the label device also doesn't have a state, but those work fine in the rules as well. The eventing library is trigger by protocol attributes, a state is just one of those attributes.

Your last comment describes the exact issue. You cannot wait for the result of an HTTP GET or POST action inside the same rule.
1. No, if the website is designed to accept only POST, but returns data, we may need it to know what the website actually did when it succeeded. That could be some status or values it acquired.
2. True
3. No, not in the rule that triggers the action itself.
a. I don't want that the http requests are executed mulltiple times at intervals. I just want to have the http request executed once when some event occurs and do things with the result as soon as it is available, but not inside the rule that triggers the action.
b. I know it is asynchronous, but isn't that what the callback is for?
4. So you can still have multiple http requests in a short time.
5. Never realized that. Always thought it only worked for devices with a state and for labels.

Last point. Again, ofc. the evaluation of the result must be done in other rules than the one that does the request. That is what the RESULT and TRIGGER are for. These are intended only to be used in other rules.
 
Reply
#10
1. We can also POST the data in "content" and replace it with the respons once sent.
3a. This can still be a poll-interval, but can also be user triggered.
3b. Yes, that's why we have the callback.
4. That's not the issue, as long as you don't have blocking requests.
5. Now you know Smile

Additionally,
I must say the switch trigger is a good idea, i just don't like the label device.
 
Reply
  


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

Forum Jump:


Browsing: 1 Guest(s)