Omlet Auto Door for Chicken Coop

fishter · October 23, 2024, 1:24pm

The URL is the external URL of your Home Assistant with api/webhook/ and the webhook ID added.
E.g. https://myhomeassistant.example.com:8123/api/webhook/my_unique_webhook_id. This assumes you can reach your Home Assistant on https://myhomeassistant.example.com:8123/

The token you enter on the Omlet website is called a Long-Lived Access Token in Home Assistant. It’s created in your user profile inside Home Assistant. Click on your icon/initials at the bottom left, then Security. It’ll only be displayed once, so make sure to copy it.

fishter · October 23, 2024, 1:52pm

I think Bing is mangling the code a bit.

You’ve got two nested "get"s and I don’t think that’s going to work as you expect.

Try going back to this and see if it starts working again. The indentation is also important.

target:
  entity_id: input_number.chicken_coop_door_state
data_template:
  value: >
    {% set state_mapping = {'unknown': 0, 'open': 1, 'closed': 2, 'opening': 3,
    'closing': 4, 'calibrating': 5, 'openstopped': 6, 'closestopped': 7} %} {%
    set payload = trigger.json.payload.newValue  %} {{
    state_mapping.get(payload, -1) | int }}
action: input_number.set_value
enabled: true

Check the webhook page on the omlet website to see what the incoming data should look like. It’s in the Request field, under the Events heading.
Mine look like this:

{"deviceId":"<my coop id>",
"parameterName":"Door State",
"oldValue":"closing",
"newValue":"closed"}

And from the webhook automation this should be in the payload section of the json generated by the Automation being triggered.
You can find this under Traces (top right from the edit automation page), then Changed Variables in your Coop Door Get State (webhoook) [I’ve just noticed that typooo…]

niwi · October 23, 2024, 7:04pm

The problem still exists.

Data template:

webhook page:

Trace:

niwi · October 24, 2024, 6:00am

I think I found my error. Actually, the automation seems to work as long as it is triggered by a real change of door state. The error messages I got were generated by triggering the automation manually.

@fishter: Do you plan to add other features? I would like to have sensors for door fault and
light level. Others might want to have sensors for battery level and light status. If you are not interested, me and Bing Copilot might give it another try…

fishter · October 24, 2024, 8:33am

Ah, yes, manually triggering the automation will mean it has no payload. I’m sure there’s a way to test it without involving the coop door, but I can’t see how to do it within HA. From a windows command line you can try :

curl -X POST -d "{"deviceId":"<my coop id>","parameterName":"Door State","oldValue":"closing","newValue":"closed"}" -H "Content-Type: application/json" https://yourha.local:8123/api/webhook/<your_webhook_id>/

I assume for Door Fault it would be:

curl -X POST -d "{"deviceId":"<my coop id>","parameterName":"Door Fault","oldValue":"none","newValue":"blocked"}" -H "Content-Type: application/json" https://yourha.local:8123/api/webhook/<your_fault_webhook_id>/

The process for door fault is almost identical to the one for door state:

alias: Coop Door Fault
description: ""
triggers:
  - allowed_methods:
      - POST
      - PUT
    local_only: false
    trigger: webhook
    webhook_id: <your_fault_webhook_id>
conditions: []
actions:
  - target:
      entity_id: input_number.chicken_coop_door_fault
    data_template:
      value: |
        {% set state_mapping = 
          {'unknown':     -1,
           'none':        0,
           'blocked':     1,
           'crush':       2,
           'wiring':      3,
           'moving':      4,
           'general':     5
           } %}
          {{ state_mapping.get(trigger.json.payload.newValue, -1) }}
    action: input_number.set_value
mode: single

You’ll need an input_helper number (chicken_coop_door_fault) and add a new sensor to the configuration.yaml (in the same section as the coop_door_state sensor:

  - sensor:
    - name: "Chicken Coop Door Fault"
      icon: mdi:alert
      state: >
        {% set state_mapping = {-1: 'Error', 0: 'none', 1: 'blocked', 2: 'crush', 3: 'wiring', 4: 'moving', 5: 'general'} %}
        {{ state_mapping[states('input_number.chicken_coop_door_fault') | int] }}

If I get some more time I’ll have a look at the other features. Light on/off isn’t useful for me as I don’t have one, but light sensor could be interesting.

niwi · October 24, 2024, 9:18am

Thank you! The light sensor was quite easy to add. But I wonder, how useful it will be. Currently, it shows 100% percent, while the autumn sky is clouded. I guess it is too primitive for controlling more than just the coop door. Currently, my coop run light is controlled by the mathematical sun set. If the light sensor will be sensible enough, I might use it for turning on the run light in the afternoon or evening.

Here is the code:

sensor:
  - platform: rest
    name: Chicken Coop Light Level
    resource: https://x107.omlet.co.uk/api/v1/device/abcd12345
    method: GET
    headers:
      authorization: !secret omlet_key
    scan_interval: 300 
    value_template: '{{ value_json.state.door.lightLevel }}'
    unit_of_measurement: '%'

OmletDave · October 24, 2024, 10:05am

The light sensor on the control panel is designed to give a good resolution around the brightness levels where customers would be interested in the door opening and closing. Because of this it will reach 100% well before what you might consider to be a bright midday level of sunshine. I wouldn’t advise using it for things outside of this range.

niwi · October 25, 2024, 9:16am

You are right about the resolution during daytime. I tried the sensor for almost a day and here is the result:

Unfortunately, even around dusk, the sensor is still not very sensible. Between 6.30 pm and 9 pm, the revel is at 1%, although my run light runs between sunset and 8 pm at 100%. Between 8 pm and 9 pm my lamp is slowly changing from 100% to 0%, still the sensor constantly stays at 1%.

Still, the sensor could be useful for some automations. I keep my rats away from the feeders and waterers using an electric fence energizer. This should only run when it is too dark for the chickens to eat or drink, of course, for their protection. The door status alone is not sufficient because a chicken might occasionally spend the night outside while I’m not home. Currently, I rely on the mathematical sunrise and sunset with a generous offset. With the sensor, I could more accurately determine when the electric fence energizer should be active. I’ve noticed that sometimes rats take advantage of the times when the energizer isn’t running but the chickens have already retreated.

niwi · October 25, 2024, 9:56am

fishter:

Here’s a further addition which helps create a toggle button you can put on a dashboard.
First, an automation that triggers when an input_boolean changes state:

alias: Coop door toggle
description: >-
  Toggle the door, but only if it's "open" or "closed". This avoids multiple
  colliding open/close commands.
triggers:
  - trigger: state
    entity_id:
      - input_boolean.coop_door
conditions: []
actions:
  - choose:
      - conditions:
          - condition: state
            entity_id: input_boolean.coop_door
            state: "off"
          - condition: state
            entity_id: sensor.chicken_coop_door_state
            state: open
        sequence:
          - action: script.coop_close_script
            data: {}
        alias: Confirm toggle is "close" and the door is "open"
      - conditions:
          - condition: state
            entity_id: input_boolean.coop_door
            state: "on"
          - condition: state
            entity_id: sensor.chicken_coop_door_state
            state: closed
        sequence:
          - action: script.coop_open_script
            data: {}
        alias: Confirm toggle is "open" and the door is "closed"
    alias: Check toggle, only send command if door is "open" or "closed".
mode: single

This checks that the door is either closed or open. If it’s any other state then nothing happens.

For me, it’s not working to adjust the state of the door with this automation after manual operation to the toggle. This leads to needing two clicks on the dashboard to adjust the door state. It seems that the conditions:

- conditions:
    - condition: state
      entity_id: sensor.chicken_coop_door_state
      state: open

or

- conditions:
    - condition: state
      entity_id: sensor.chicken_coop_door_state
      state: closed

are never met (I checked in trace). I suspect this is because the automation is triggered multiple times while the door opens or closes. I couldn’t identify the exact reason, and changing the mode from single to always didn’t help.

I solved the problem by removing the control of the toggle from the automation. Now, the toggle is controlled by an additional automation that is triggered differently:

alias: Chicken Coop Door Toggle Sync
description: ""
triggers:
  - trigger: state
    entity_id:
      - sensor.chicken_coop_door_state
    to: closed
  - trigger: state
    entity_id:
      - sensor.chicken_coop_door_state
    to: open
conditions: []
actions:
  - action: automation.turn_off
    metadata: {}
    data:
      stop_actions: true
    target:
      entity_id: automation.coop_door_toggle
    enabled: true
  - choose:
      - conditions:
          - condition: state
            entity_id: sensor.chicken_coop_door_state
            state: open
        sequence:
          - action: input_boolean.turn_on
            data: {}
            target:
              entity_id: input_boolean.coop_door
      - conditions:
          - condition: state
            entity_id: sensor.chicken_coop_door_state
            state: closed
        sequence:
          - action: input_boolean.turn_off
            target:
              entity_id:
                - input_boolean.coop_door
            data: {}
    enabled: true
  - action: automation.turn_on
    metadata: {}
    data: {}
    target:
      entity_id: automation.coop_door_toggle
    enabled: true
mode: single

Of course, it would be nicer to have everything in one automation. If it actually works for you with just one automation, I’d appreciate any ideas on what might be wrong for me.

fishter:

The input_boolean is used as a simple toggle on the dashboard. This is a bit rough and ready:
type: horizontal-stack
cards:
  - type: entity
    entity: sensor.chicken_coop_door_state
    icon: " "
    state_color: false
  - show_name: true
    show_icon: true
    type: button
    tap_action:
      action: toggle
    entity: input_boolean.coop_door
    hold_action:
      action: toggle
    show_state: false
    name: Toggle
The key part is the tap_action and hold_action settings for the button card. This will change the value of the boolean and thereby trigger the automation.

Everything I’ve used above is a standard part of HA. There are no add-ons, specific integrations or mods required. I think it’s a nice illustration of what HA can bring together. The next step is to make it local control only, but that requires co-operation from Omlet to make that a possibility.

If anyone has any advice on all the above automation, scripting then please feel free to make a critique. This is my first real foray into HA automation, so if I’ve made some basic errors or missteps let me know.

Here is an alternative way to control the door by the dashboard with a tile:

type: tile
entity: sensor.chicken_coop_door_state
state_content:
  - state
  - last_changed
tap_action:
  action: perform-action
  perform_action: input_boolean.toggle
  target:
    entity_id: input_boolean.coop_door
icon_tap_action:
  action: perform-action
  perform_action: input_boolean.toggle
  target:
    entity_id: input_boolean.coop_door
name: Chicken Coop Door

grafik

Every time you click on the tile, the door toggles. I prefer this solution because it gives me also the information when the status of the door changed and a tile takes less space.

UPDATE:
I just found two typos in the code for the sensor “Chicken Coop Door Fault”. The original code from fishter was:

- sensor:
    - name: "Chicken Coop Door Fault"
      icon: mdi:alert
      state: >
        {% set state_mapping = {-1: 'Error', 0: 'none', 1: 'blocked', 2: 'crush', 3: 'wiring', 4: 'moving', 5: 'general', 6: 'end of travel'} %}
        {{ state_mapping[states('ínput-number.chicken_coop_door_fault') | int] }}

In the last line, there is a í instead of an “i” and a “-” instead of a “_”. The corrected code is:

- sensor:
    - name: "Chicken Coop Door Fault"
      icon: mdi:alert
      state: >
        {% set state_mapping = {-1: 'Error', 0: 'none', 1: 'blocked', 2: 'crush', 3: 'wiring', 4: 'moving', 5: 'general', 6: 'end of travel'} %}
        {{ state_mapping[states('input_number.chicken_coop_door_fault') | int] }}

fishter · October 25, 2024, 3:43pm

Thanks! I edited my original post to remove the typos.

niwi · October 25, 2024, 7:02pm

I might have found two more errors here:

alias: Coop Door Fault
description: ""
triggers:
  - allowed_methods:
      - POST
      - PUT
    local_only: false
    trigger: webhook
    webhook_id: <your_fault_webhook_id>
conditions: []
actions:
  - target:
      entity_id: input_number.chicken_coop_door_fault
    data_template:
      value: |
        {% set state_mapping = 
          {'unkown':     -1,
           'none':        0,
           'blocked':     1,
           'crush':       2,
           'wiring':      3,
           'moving':      4,
           'general':     5,
           'endoftravel': 6
           } %}
          {{ state_mapping.get(trigger.json.payload.newValue, -1) }}
    action: input_number.set_value
mode: single

unkown → unknown (but I think this is not important for the functionality of the code)
Is there really a condition “endoftravel”? In OmletDaves list from Oct 16 this was part of the “general” condition.

BTW: I am writing an automation that will notify me, if any door fault happens in the evening. Even if the problem can be solved by itself (e.g. a chicken blocks the door for some time but finally moves away) fault can still be a hint that a chicken might be on the wrong side of the door at night.

jayburkard · November 1, 2024, 5:46pm

Hey there! I’m assuming you guys don’t want to make the board configuration too public but I was considering flashing esphome to the esp32 on board and playing around - is any of that pinout information available? The API is great but I’m really looking for a totally local solution. Have used your door for years on 2 coops, just bought the upgraded control module and was happy to see an esp32 on it.