How to seperate two RESTful API's

Configuration
1

I’ve split one API in two pieces because I want to have two different scan intervals. Both work when I remove one of the two but if I have both active then I get strange results without any error in the config. How do you seperate / tell the system that one rest API is finished and that it’s a new link? Below the code how it is now but it only works for one of the two so I’ve disabeld the bottom one.

Some additional info:
in the configuration.yaml file I only have the following link (rest: !include rest.yaml) direct to the rest.yaml file of which the content is pasted below. Don’t think that will be the problem else neither of the APIs would work.

- resource: http://192.168.25.11/get-sensors
  scan_interval: 1
  sensor:
    - name: "Luchtvochtigheid woonkamer"
      value_template: "{{ value_json.response.thermometers[0].hu }}"
      unit_of_measurement: "% "
    - name: "Waterverbruik"
      value_template: "{{ value_json.response.energylinks[0].s2.po }}"
      unit_of_measurement: "L"
    - name: "Bruto elektra verbuik"
      value_template: "{{ value_json.response.energylinks[0].used.po }}"
      unit_of_measurement: "W"
    - name: "Netto elektra verbruik"
      value_template: "{{ value_json.response.energylinks[0].aggregate.po }}"
      unit_of_measurement: "W"
    - name: "Gasverbruik per uur"
      value_template: "{{ value_json.response.energylinks[0].gas.lastHour }}"
      unit_of_measurement: "m3"

#- resource: http://192.168.25.11/get-sensors
#  scan_interval: 60
#  sensor:
#    - name: "Water dagtotaal"
#      value_template: "{{ value_json.response.energylinks[0].s2.dayTotal }}"
#      unit_of_measurement: "L"
#    - name: "Elektra saldo dag"
#      value_template: "{{ value_json.response.energylinks[0].aggregate.dayTotal }}"
#      unit_of_measurement: "kWh"
#    - name: "Elektra verbruik dag"
#      value_template: "{{ value_json.response.energylinks[0].used.dayTotal }}"
#      unit_of_measurement: "kWh"
#    - name: "Gas dag"
#      value_template: "{{ value_json.response.energylinks[0].gas.dayTotal }}"
#      unit_of_measurement: "m3"
#   - name: "Luchtvochtigheid woonkamer dag"
#      value_template: "{{ value_json.response.thermometers[0].hu }}"
#      unit_of_measurement: "%"
2

Does the resource URL allow, and ignore, query strings? You could perhaps use:

resource: http://192.168.25.11/get-sensors?scan=fast

for the first one and

resource: http://192.168.25.11/get-sensors?scan=slow

for the second?

3

Unfortunately not, it’s GET only. Gives an overview of all sensor data on the moment of the scan. Must be possible to have multiple RESTful API’s though?

4

None of those sensors look like they need the ridiculously fast update interval of 1 second. This is going to cause needlessly high cpu and network usage.

5

You are right, but that’s not the point of the question. I’ve changed the actual usage to 10sec now but I still only need a much longer interval for the sensors that measure daily use. 600sec is fine. What I can’t find anywhere is how to seperate the two or how to vary the scan_interval between the two. If I start again with platform: rest then I get an error. How does it work if you have two different RESTful API sources? Must be some way to end the first API and start the next one.

6

I think you missed what @Troon meant: You can effectively set up the same endpoint twice (i.e. define 2 resource sections) by passing nonsense GET parameters, if that endpoint will ignore those parameters. Each of these can have their own scan interval. It’s a trick.

1 Like
7

Give them prime number scan intervals. That way they will never overlap.

1 Like
8

@parautenbach, thanks you’re right I missed that one. Tested it and unfortunately no difference. The strange thing is that when I uncomment the second (slow scan) one then it seems to totally skip the first one. The same time it doubles the sensors on the second one:
Knipsel

9

and thanks @tom_l for the tip on the prime numbers. Don’t know it it’s a problem if there are two simultaneous requests but better safe then sorry.

10

I have had issues with colliding restful requests from the same resource in the past. The second one would get no response while the first was being replied to. Primes was how I solved it.

11

I’ve tried that as well. 13 for the short scan and 600 for the long one. The only time they run simultaneous is the first run. No luck unfortunately, still getting the duplicate sensors and totally skipping the first block with the 13 second scan. If I look at the refresh of the second block that should have 600sec scan then it looks like that sensors are being updated every 13 seconds.

12

Look at the last_updated attribute of each sensor under the developer tools to be sure.

13

For small values of “never”, yes. Coprime intervals will overlap at x·y intervals of course: every 7,800 seconds in the example here, ignoring the fact that 600 isn’t prime. Like the cicadas.

Another trick I’d try, if the query string one didn’t work, might be to add a port number to the URL on one of the requests:

resource: http://192.168.25.11:80/get-sensors

Short of trawling through the code, the behaviour looks as though the system is indexing the sensors by the resource, so you need to find a way to separate them.

14

More ideas:

Set up an nginx (reverse) proxy on the host that serves that API. Create two distinct endpoints that both point to the actual API. I would go for this.

More involved, I think, but nonetheless: If that host has 2 NICs, you could have two IPs.

15

I never thought of using prime numbers for REST updates, I just always stuck with 300 seconds for most and knew that it caused a problem periodically. Using primes makes sense; it pays to read comments just to pick up little useful tidbits.

16

I’ve now changed both to prime numbers but same result, next I’ll check the reverse proxy. It is strange that there is no way to seperate the two API’s with code. I don’t know enough about the code yet to understand why but with other programming languages there usually is a way to end one part and start the next one.