Would be really nice to make use of it somehow! Unfortunately I am not skilled enough 
after deplayment it already trows errors, will look in to this. I was hoping somebody here could help.
1 Like
I’ve just ordered my Smart Autodoor Control Panel (they’re currently 20% off as part of Spring sale!) so I’m really hoping someone can get a working integration up soon, or fork and work through the one at kemathy/hassio-omlet-smartcoop-door: Home Assistant integration to monitor and control Omlet Smart Coop Door (github.com) if it is salvagable.
1 Like
So far, I am still using the traditional panel. However, I have made it smart with a Shelly Uni (as described above) and integrated it into Home Assistant. I am now considering purchasing the new Smart Autodoor Control Panel because I want reliable feedback on the door’s status. However, I am not sure if the new panel really offers an advantage. The following questions concern me:
-
My existing panel is connected to a power supply. In the event of a power failure, it loses the current time. Since I open and close it at fixed times, this is fatal. A power failure can cause the door to close during the day. For example, a chicken would be locked up without access to water on a hot summer day. Therefore, I also use a contact sensor for the door. However, its button cell often fails at low temperatures. How does the new smart panel behave? Does it lose the time during a power failure? Or does it automatically get the current time online from an NTP server?
-
How does the panel behave if it has no network access for a period? Currently, I control my hacked traditional panel with a Shelly Uni. The Shelly Uni resets under unclear circumstances and is then no longer accessible via the network. I suspect this happens when the network connection is lost for an extended period. It would be a buying reason for me if the new panel did not show such behavior.
-
Can the new panel still be hacked with a Shelly Uni? Then I could run it on two tracks in case the panel’s built-in functions do not prove to be robust enough.
Hey,
To answer your questions:
-
Yes, the panel will syncronise time via NTP if you’ve configured it to connect to your wireless network. We’ve added functionality in the latest firmware for non-connected users where if there is a power cut and the time is lost, it will revert to light mode to ensure it opens and closes at more appropriate times of day than it might otherwise with a non-set clock (will start counting from midnight when the power is restored)
-
All of the settings are stored on the panel itself, so it will continue to operate via the pre-programmed settings if the internet connection becomes unavailable. Obviously if you’ve set it to Manual, and you’re relying on the app or API to send open/close commands, then those will not be received until the control panel reconnects, but Light and Time mode work as normal
-
We would obviously advise against any electronic modifications to the panel, as this would void your warranty, but obviously the choice is yours. Hopefully you’ll find you’re able to do whatever you’d like with the door via our API - we’re very open to feedback should you find the API doesn’t permit a specific use case you had in mind
1 Like
Well, the expiration of the warranty is a risk that one must overcome if they don’t want to always use technology strictly within the manufacturer’s limitations. I understand that a manufacturer must be very cautious in such matters. Since I can cope with the loss of 50€ and it’s only about low voltage, I plan to extend the smart panel with a Shelly Uni again.
I would like a combination of time control and sunset based on geo-location from Omlet. This makes a lot of sense in practice: In the morning, the coop door should open at a certain time to avoid disturbing the neighbors with the rooster. For me, this is 7:00 AM. In the dark half of the year, the chickens can still go out because I light the run. In the evening, the door should close an hour after sunset, but never before 9:00 PM. This ensures that the door doesn’t close in the summer before the chickens are in the coop. Until 9:00 PM, I light my run with decreasing intensity after sunset.
With the traditional panel, this is already possible if hacked with a Shelly Uni. The Shelly Uni then triggers button presses at the right times, controlled by Home Assistant, to open or close the door. As a failsafe function, I have programmed the panel to open at 8:00 AM and close at 11:00 PM. If Home Assistant doesn’t reach the panel, the chickens won’t be locked up after 8:00 AM or left vulnerable after 11:00 PM. The only issue is power outages. The failsafe function causes the door to open or close at the wrong time. Also, I lack secure feedback on the door’s status.
I think it’s very good that the new smart panel now automatically switches to light mode in case of a power failure. So in the future, I don’t have to worry about incorrect times after power outages. However, I wonder if the panel also switches to light mode when the correct time is restored via NTP. I hope that time control will then take over again.
If there were an integration for Home Assistant for the new API, all the above functions could be implemented without a Shelly Uni. Unfortunately, my programming skills are not sufficient to develop an integration myself.
Overall, I am happy about the extended possibilities and have just ordered a smart panel.
If you have wifi connectivity enabled, then the panel will not switch over to light mode after a power failure - it will wait until the time is resynced via NTP
Today, my smart panel arrived and has already been installed. I can also control it entirely through Home Assistant—without needing a Uni Shelly or a working integration for Home Assistant. Opening and closing are possible via Alexa, and thus also through Home Assistant thanks to the Alexa Media Player Integration. The state of the door is reported by Omlet via a webhook.
Here’s part of my code for you to replicate:
1. Track the state of the door
alias: Chicken Coop Door State
triggers:
- webhook_id: "-abc_1234567890-xyz"
allowed_methods:
- POST
- PUT
local_only: false
trigger: webhook
conditions: []
actions:
- target:
entity_id: input_number.chicken_coop_door_state
data_template:
value: >
{% set state_mapping = {'jammed': 0, 'closed': 1, 'closing': 2, 'opening': 3, 'open': 4} %}
{% set new_state = trigger.json.payload | from_json %}
{{ state_mapping.get(new_state.newValue, 0) }}
action: input_number.set_value
mode: single
To make this work, you must retrieve the appropriate URL from http://homeassistant.local:8123/config/cloud/account along with the token and set up a webhook for “door state” at https://smart.omlet.com/developers/my/webhooks/. Also, you need to create the helper input_number.chicken_coop_door_state in Home Assistant. It requires states 0-4, with these mappings: 0 = jammed, 1 = closed, 2 = closing, 3 = opening, 4 = open.
2. Set up a template sensor in configuration.yaml to convert the states into readable text (for the dashboard)
template:
- sensor:
- name: "Chicken Coop Door State"
state: >
{% set state_mapping = {0: 'jammed', 1: 'closed', 2: 'closing', 3: 'opening', 4: 'open'} %}
{{ state_mapping[states('input_number.chicken_coop_door_state') | int] }}
3. Open and close the door
sequence:
- choose:
- conditions:
- condition: numeric_state
entity_id: input_number.chicken_coop_door_state
below: 2
sequence:
- action: media_player.play_media
target:
device_id: sjbsfdlkbjslgfkbjlskföjbölsfgbllöklö5
data:
media_content_type: custom
media_content_id: Open Chicken Coop Door
- conditions:
- condition: numeric_state
entity_id: input_number.chicken_coop_door_state
above: 3
sequence:
- action: media_player.play_media
target:
device_id: sjbsfdlkbjslgfkbjlskföjbölsfgbllöklö5
data:
media_content_type: custom
media_content_id: Close Chicken Coop Door
description: ""
4. Code for a tile button on the dashboard
entity: sensor.chicken_coop_door_state
name: Chicken Coop Door
icon: mdi:bird
show_entity_picture: false
vertical: true
hide_state: false
tap_action:
action: perform-action
perform_action: script.chicken_coop_door_toggle
target: {}
state_content:
- state
- last_updated
I’m not sure if my solution above correctly indicates whether the door is “jammed”. I couldn’t find any documentation on the states that the webhook for “door state” knows. You can also set up an additional webhook for “Door fault”. This could then accurately set the state “0”. For now, my current solution is sufficient. And who knows, maybe someone will write a proper integration one day.
One small negative experience: for about an hour today, the Omlet app didn’t show the completion of an opening or closing process. However, the actual opening and closing still worked through Alexa. For me, this is a fresh example of why a local integration would be preferable.
Brilliant to hear you’ve been able to get something working in Home Assistant. The door states you’ll see from the webhook are:
unknown - This is on initial setup before calibration, you wouldn’t see this again after calibration
open
closed
opening
closing
calibrating
openstopped
closestopped
The following three will be seen after triggering an action via the API / app, before the door begins to process the command
stopping
openpending
closepending
If you also monitor the door fault webhook event, you’d see the following messages
none - no fault
blocked - the door encountered an obstruction while opening/closing
crush - the crush detection bar was triggered
wiring - no current was detected flowing to the motor when it should have been moving - maybe the cable is damaged / not connected
general - the motor ran for longer than expected without the door reaching the end of travel - might be an issue with the motor / gearbox / drive gear
It’s very unusual that the app would not show the latest status of the door. You should receive a push notification when the state of the door changes, which would also trigger a refresh within the app. You can also refresh the app manually to see the latest status by pulling down from the top. If the status continues to be out of date, please let us know and we can investigate that
1 Like
This has given me the nudge to investigate further.
I’ve taken your templates for the automation and number helper and added the states that @OmletDave listed.
I have configured the webhook on the Omlet site (one each for State and Fault).
I can see that the webhook is triggered when I change the state of the door, but there is an error in rendering the data template. It’s at this point that I’m stuck.
My automation action is:
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,
'stopping': 8,
'openpending': 9,
'closepending': 10
} %}
{% set new_state = trigger.json.payload | from_json %}
{{ state_mapping.get(new_state.newValue, 0) }}
action: input_number.set_value
and the error I see in the system log is this:
Error while executing automation automation.chicken_coop_door_state: Error rendering data template: JSONDecodeError: Input must be bytes, bytearray, memoryview, or str: line 1 column 1 (char 0)
Error while executing automation automation.chicken_coop_door_state: Error rendering data template: UndefinedError: 'dict object' has no attribute 'json'
(The second error is not included in the automation trace error, but the first is.)
The Changed Variables in the trace are:
trigger:
platform: webhook
webhook_id: <my_webhook_id>
json:
token: >-
<my_private_token>
payload:
deviceId: <my_device_id>
parameterName: Door State
oldValue: opening
newValue: open
query:
__type: <class 'multidict._multidict.MultiDictProxy'>
repr: <MultiDictProxy()>
There’s a couple of things that don’t add up. What data is it interpreting as something that’s not a string? Why is there an error involving a ‘dict object’ when I’m trying to access the trigger.json.payload element, not the trigger.query element?
Can someone help point me in the right direction on debugging this?
My script only worked the first or maybe first and second day. After this, I also got the same error. I wonder if Omlet changed something after I published my code. It worked very reliable in the beginning.
I will take a look into this in view days. Bing Chat helped me to write the code (I am not a real coder). I might help to identify the problem, too.
I seem to have got this working…
There’s no need to pipe the webhook payload through a JSON reader if you access the right value directly (newValue).
Automation:
alias: Chicken Coop Door State
description: ""
triggers:
- allowed_methods:
- POST
- PUT
local_only: false
trigger: webhook
webhook_id: <mywebhookid>
conditions: []
actions:
- 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 doorState = trigger.json.payload.newValue %}
{{ state_mapping.get(doorState, -1) | int }}
action: input_number.set_value
enabled: true
mode: single
Note: the -1 in the state_mapping.get() is a default value in case the output from the webhook payload is not parsed correctly. I added this to the sensor as an error state. (States stopping, open pending and close pending are never reported via webhook so are not included above, but are below in case I get the api working).
configuration.yaml:
# template sensor for chicken coop door
- template
- sensor:
- name: "Chicken Coop Door State"
icon: mdi:hoop-house
state: >
{% set state_mapping = {-1: 'Error', 0: 'unknown', 1: 'open', 2: 'closed', 3: 'opening', 4: 'closing', 5: 'calibrating', 6: 'openstopped', 7: 'closestopped', 8: 'stopping', 9: 'openpending',10: 'closepending'} %}
{{ state_mapping[states('input_number.chicken_coop_door_state') | int] }}
I hope this helps other people get their Omlet door’s status into home assistant. At the moment it’s just monitoring of the current state. I’ll come back with any progress I make on controlling the door, but I don’t get much time to fiddle with these things in a normal week 
2 Likes
Many thanks (-:
The modified script works perfectly in my tests. Good idea to repurpose the hoop-house symbol. I hope you manage to use the API for the door control eventually. Until then, I will control the door in Home Assistant via Alexa (see my earlier post).
Hi @OmletDave ,
My app seems to be stuck on closepending even though the door is closed. The API reports this as well (as you’d hope!)
To see if it’s just held up by power saving I’ve switched it to responsive mode and I’ll see what happens.
Update: it sorted itself out, but it did take 15 minutes or so to do so.
The app should refresh automatically if you have push notifications turned on (it won’t if you don’t) - but you can always pull down from the top to refresh it to see the latest status
I’ve now got the API to work. This is quite a bit of setup involving the configuration.yaml file, so it’s not exactly friendly.
- Log onto Developer Console and get yourself an API key.
- Get the device id of your smart door from the Omlet app (or try out the API on the Omlet website to discover it).
- Add the following to your secrets.yaml (or put it in place of the !secret omlet-key in the configuration.yaml
omlet_key: "Bearer <API_KEY>" - Edit your configuration.yaml as follows, replacing the placeholder for device id with your actual device id.
rest_command:
coop_get_configuration:
url: https://x107.omlet.co.uk/api/v1/device/<DEVICE_ID>/configuration
method: get
content_type: application/json
headers:
authorization: !secret omlet_key
coop_get_door_state:
url: https://x107.omlet.co.uk/api/v1/device/<DEVICE_ID>
method: get
content_type: application/json
headers:
authorization: !secret omlet_key
coop_open:
url: https://x107.omlet.co.uk/api/v1/device/<DEVICE_ID>/action/open
method: post
content_type: application/json
headers:
authorization: !secret omlet_key
coop_close:
url: https://x107.omlet.co.uk/api/v1/device/<DEVICE_ID>/action/close
method: post
content_type: application/json
headers:
authorization: !secret omlet_key
template
- sensor:
- name: "Chicken Coop Door State"
icon: mdi:hoop-house
state: >
{% set state_mapping = {-1: 'Error', 0: 'unknown', 1: 'open', 2: 'closed', 3: 'opening', 4: 'closing', 5: 'calibrating', 6: 'openstopped', 7: 'closestopped', 8: 'stopping', 9: 'openpending',10: 'closepending'} %}
{{ state_mapping[states('input_number.chicken_coop_door_state') | int] }}
-
Now restart home assistant.
-
Next we create three scripts. One to get the state of the door, one to open and one to close.
The first is to get the state. This also sets two helpers: input_boolean.coop_door and input_number.chicken_coop_door_state which you’ll need to create before starting.
alias: Coop get state rest script
sequence:
- action: rest_command.coop_get_door_state
data: {}
response_variable: coop_door_state
- if:
- condition: template
value_template: "{{ coop_door_state['status'] == 200 }}"
then:
- alias: Parse data
variables:
doorState: "{{ coop_door_state['content']['state']['door']['state'] }}"
- 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, 'stopping': 8, 'openpending': 9, 'closepending' :
10} %} {{ state_mapping.get(doorState, -1) | int }}
action: input_number.set_value
enabled: true
- action: automation.turn_off
metadata: {}
data:
stop_actions: true
target:
entity_id: automation.coop_door_toggle
- choose:
- conditions:
- condition: state
entity_id: sensor.chicken_coop_door_state
state: open
sequence:
- action: input_boolean.turn_on
target:
entity_id: input_boolean.coop_door
data: {}
- 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: {}
- action: automation.turn_on
metadata: {}
data: {}
target:
entity_id: automation.coop_door_toggle
enabled: true
description: Turns off toggle automation while updating input_boolean
icon: mdi:api
- Next the open script. The script also updates the status via the API.
alias: "Coop open script "
sequence:
- action: rest_command.coop_open
data: {}
response_variable: open_response
- action: script.coop_get_state_rest_script
metadata: {}
data: {}
description: ""
icon: mdi:check
The close script is identical, save the name and the rest_command.
- Here is also the webhook automation which is described earlier in this thread. It’s used to keep the status up to date when the door is manually opened or closed, or if it’s changed via the Omlet app.
alias: Coop Door Get State (webhoook)
description: >-
Updated if omlet app is used, or manual open/close. Disables automated
toggling while the input boolean is updated.
triggers:
- allowed_methods:
- POST
- PUT
local_only: false
trigger: webhook
webhook_id: <MY_UNIQUE_WEBHOOK_ID>
conditions: []
actions:
- action: automation.turn_off
metadata: {}
data:
stop_actions: true
target:
entity_id: automation.coop_door_toggle
- 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
- choose:
- conditions:
- condition: state
entity_id: sensor.chicken_coop_door_state
state: open
sequence:
- action: input_boolean.turn_on
target:
entity_id: input_boolean.coop_door
data: {}
- 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: {}
- action: automation.turn_on
metadata: {}
data: {}
target:
entity_id: automation.coop_door_toggle
mode: single
I’m still figuring out the best way to use these to keep everything in sync between the app, manual use and HA. The input_boolean in some of the scripts is intended to function as a toggle on a dashboard, but I’ve run out of daylight to test that - I don’t want my chickens freaking out at the door opening and closing repeatedly while they’re roosting!
Enjoy!
3 Likes
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.
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.
2 Likes
Many thanks @fishter for sharing what you’ve thrown together thus far!
I’m a non-coder following along but the step I’m a little stumped on is creating the webhook in the Omlet dev environment.
I assume the Event is “Door State”.
What URL and token do you use?
To do this, does it require the use of Nabu Casa or other form of reverse proxy to expose the HA environment externally?
The “Coop Door Get State (webhoook)” stopped working for me again. I tried to debug it with Bing Copilot. The automation is working again for me with this modification of the data template part:
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 if trigger.json else trigger %}
{{ state_mapping.get(payload.get(‘newValue’, ‘unknown’), -1) | int }}
UPDATE: Now it doesn’t even work with the modification above.