I got a Reolink E1 Zoom camera which I have integrated with Home Assistant using the official integration. Now I am playing around with possibilities to control the camera using buttons in a dashboard.
I have added buttons to pan the camera to the left and to the right. The problem is that when I press the buttons the camera pans correctly to the left and to the right, but with just one short press it always goes the full left (or full right), ie almost 180 degres.
So, is there any way to control the panning of the camera so it pans in smaller steps?
The yaml code for the picture glance card looks like this:
I found the below video, seems like the ONVIF integration is better to control the PTZ for Reolink cameras (he mention this around 6:00 into the video). So I used ONVIF instead.
Yeah I am pulling the video feed via webrtc and achieving ptz control via onvif. Onvif does have the video feed, but it is more laggy. I also added shortcut buttons to different ptz presets. Hereās my code if it helpsā¦
No. In the code I shared thereās a ptz section, with up/down/left/right/in/out. The presets was just a nice bonus as I can achieve most the views I want with one press. I still have full manual control too.
I had this same issue. I got around it by creating a script with two variables. One for the camera pan button and one for the pan stop button. I called the pan button, then a delay, then the pan stop.
sequence:
- action: button.press
metadata: {}
data: {}
target:
entity_id:
- "{{ camera_direction }}"
- delay:
hours: 0
minutes: 0
seconds: 0
milliseconds: 200
- action: button.press
metadata: {}
data: {}
target:
entity_id: "{{ camera_stop }}"
alias: Pan Camera
description: ""
fields:
camera_direction:
selector:
text: null
name: Camera Direction
description: PTZ button to press
required: true
camera_stop:
selector:
text: null
name: Camera Stop
description: stop button to press
required: true
I made an outomation, one trigger per camera triggered whenever any of the ptz buttons have been pressed for 100 ms.
Then in the actions I made a choose blok, one option for each trigger (camera) and the action is to press the stop button of that camera.
This way I adjust the behavior of the ptz buttons all over then from the dashborad I just call the button press action of the ptz buttons, these are then stopped after 100 ms or whatever time I want to set per camera.
Thanks everyone in this thread for sharing their great suggestions.
I have tweaked @ghassanās suggestion a bit more to easily extend to mulitple cameras - still requires adding all buttons to the automation but no need to have separate rules for separate camers:
Basically I cut off the name of whichever button was pressed after the last underscore and put āstopā in that place. As long as the button names stay consistent in the integration, this should hold.
Just wanted to share a small contribution to this excellent thread.
First of all, thanks to @bconway for the idea of calling a script directly from the picture-glance card configuration (super clean UX), and for the initial script approach. Also thanks to @Kirkebakke for the template code that derives the matching _stop entity from the direction button entity ā thatās the key piece that makes a single reusable script possible.
Using both ideas, I put together a single Picture Glance card + a single script (camera_pan_tilt). The gestures are:
Tap ā short nudge (direction press + short delay + stop)
Hold ā longer movement (direction press + longer delay + stop)
Double-tap ā continuous movement (single direction press, no stop)
A note about time delays: unfortunately (as far as I can tell) Reolink doesnāt expose a āmove N stepsā or similar parameter. So we end up using delays to approximate āstepsā. This works well, but the best delay values are very dependent on the whole setup (HA hardware, VM/container, load, network latency, etc.). That also means the delay values appear many times in the card YAML, which is a bit annoying.
One possible workaround is to define delays as input_number helpers and reference them from the card. That would make tuning much easier, at the cost of adding more HA components for the same purpose (and therefore more to maintain). I havenāt implemented that version (yet), but itās an option.
