HTTP

The http integration serves all files and data required for the Open Peer Power frontend. You only need to add this to your configuration file if you want to change any of the default settings.

There is currently support for the following device types within Open Peer Power:

Binary Sensor
Sensor

The option option `server_host` should only be used on a Open Peer Power Core installation!

# Example configuration.yaml entry
http:

Configuring trusted_networks via the `http` integration will be deprecated and moved to `auth_providers` instead. For instructions, see trusted networks. In Open Peer Power 0.89.0 and 0.89.1, you need place the trusted network under both `http` and `auth_providers` if you still want to use trusted networks features. You can remove it from `http` section starting from 0.89.2.

The sample below shows a configuration entry with possible values:

# Example configuration.yaml entry
http:
  server_port: 12345
  ssl_certificate: /etc/letsencrypt/live/opp.example.com/fullchain.pem
  ssl_key: /etc/letsencrypt/live/opp.example.com/privkey.pem
  cors_allowed_origins:
    - https://google.com
    - https://www.openpeerpower.io
  use_x_forwarded_for: true
  trusted_proxies:
    - 10.0.0.200
  ip_ban_enabled: true
  login_attempts_threshold: 5

The Set up encryption using Let’s Encrypt blog post gives you details about the encryption of your traffic using free certificates from Let’s Encrypt.

Or use a self signed certificate following the instructions here Self-signed certificate for SSL/TLS.

HTTP sensors

To use those kind of sensors or binary sensors in your installation no configuration in Open Peer Power is needed. All configuration is done on the devices themselves. This means that you must be able to edit the target URL or endpoint and the payload. The entity will be created after the first message has arrived.

IP filtering and banning

If you want to apply additional IP filtering, and automatically ban brute force attempts, set ip_ban_enabled to true and the maximum number of attempts. After the first ban, an ip_bans.yaml file will be created in the root configuration folder. It will have the banned IP address and time in UTC when it was added:

127.0.0.1:
  banned_at: '2016-11-16T19:20:03'

After a ban is added a Persistent Notification is populated to the Open Peer Power frontend.

Please note, that sources from `trusted_networks` won't be banned automatically.

Hosting files

If you want to use Open Peer Power to host or serve static files then create a directory called www under the configuration path (/config). The static files in www/ can be accessed by the following URL http://your.domain:8123/local/, for example audio.mp3 would be accessed as http://your.domain:8123/local/audio.mp3.

If you've had to create the `www/` folder for the first time, you'll need to restart Open Peer Power.

Files served from the `www`/`local` folder, aren't protected by the Open Peer Power authentication. Files stored in this folder, if the URL is known, can be accessed by anybody without authentication.

Binary Sensor

The HTTP binary sensor is dynamically created with the first request that is made to its URL. You don’t have to define it in the configuration first.

The sensor will then exist as long as Open Peer Power is running. After a restart of Open Peer Power the sensor will be gone until it is triggered again.

The URL for a binary sensor looks like the example below:

http://IP_ADDRESS:8123/api/states/binary_sensor.DEVICE_NAME

You should choose a unique device name (DEVICE_NAME) to avoid clashes with other devices.

The JSON payload must contain the new state and can have a friendly name. The friendly name is used in the frontend to name the sensor.

{"state": "on", "attributes": {"friendly_name": "Radio"}}

For a quick test curl can be useful to “simulate” a device.

$ curl -X POST -H "Authorization: Bearer LONG_LIVED_ACCESS_TOKEN" \
    -H "Content-Type: application/json" \
    -d '{"state": "off", "attributes": {"friendly_name": "Radio"}}' \
    http://localhost:8123/api/states/binary_sensor.radio

$ curl -X GET -H "Authorization: Bearer LONG_LIVED_ACCESS_TOKEN" \
       -H "Content-Type: application/json" \
       http://localhost:8123/api/states/binary_sensor.radio
{
    "attributes": {
        "friendly_name": "Radio"
    },
    "entity_id": "binary_sensor.radio",
    "last_changed": "16:45:51 05-02-2016",
    "last_updated": "16:45:51 05-02-2016",
    "state": "off"
}

Examples

In this section you’ll find some real-life examples of how to use this sensor, besides curl, which was shown earlier.

Using Python request module

response = requests.post(
    "http://localhost:8123/api/states/binary_sensor.radio",
    headers={
        "Authorization": "Bearer LONG_LIVED_ACCESS_TOKEN",
        "content-type": "application/json",
    },
    data=json.dumps({"state": "on", "attributes": {"friendly_name": "Radio"}}),
)
print(response.text)

Using `httpie`

httpie is a user-friendly CLI HTTP client.

$ http -v POST http://localhost:8123/api/states/binary_sensor.radio \
      'Authorization:Bearer LONG_LIVED_ACCESS_TOKEN' content-type:application/json state=off \
      attributes:='{"friendly_name": "Radio"}'

Sensor

The HTTP sensor is dynamically created with the first request that is made to its URL. You don’t have to define it in the configuration first.

The sensor will then exist as long as Open Peer Power is running. After a restart of Open Peer Power the sensor will be gone until it is triggered again.

The URL for a sensor looks like the example below:

http://IP_ADDRESS:8123/api/states/sensor.DEVICE_NAME

You should choose a unique device name (DEVICE_NAME) to avoid clashes with other devices.

The JSON payload must contain the new state and should include the unit of measurement and a friendly name. The friendly name is used in the frontend to name the sensor.

{"state": "20", "attributes": {"unit_of_measurement": "°C", "friendly_name": "Bathroom Temperature"}}

For a quick test, curl can be useful to “simulate” a device.

$ curl -X POST -H "Authorization: Bearer LONG_LIVED_ACCESS_TOKEN" \
       -H "Content-Type: application/json" \
       -d '{"state": "20", "attributes": {"unit_of_measurement": "°C", "friendly_name": "Bathroom Temp"}}' \
       http://localhost:8123/api/states/sensor.bathroom_temperature

$ curl -X GET -H "Authorization: Bearer LONG_LIVED_ACCESS_TOKEN" \
       -H "Content-Type: application/json" \
       http://localhost:8123/api/states/sensor.bathroom_temperature
{
    "attributes": {
        "friendly_name": "Bathroom Temp",
        "unit_of_measurement": "\u00b0C"
    },
    "entity_id": "sensor.bathroom_temperature",
    "last_changed": "09:46:17 06-02-2016",
    "last_updated": "09:48:46 06-02-2016",
    "state": "20"
}

For more examples please visit the HTTP Binary Sensor page.