here you go:
Thank you very much again … this is cool 
. I’m just waiting to get home to start installing.
1 Like
Pergola.Fabio please tell me about trigger integration
(“Door 1” is not closed) that works when the door is open, can it be made to work when the door is closed (“Door 1” is closed)?
Thank you.
1 Like
I don’t think that event is created by our devices
But @Joao-Sousa-71 has a workaround for that event, maybe @Joao-Sousa-71 can share the final update of his device trigger here with example code?
1 Like
With this integration you can create trigger sensor that will be something like this:
- trigger:
- platform: mqtt
topic: hmd/device_automation/bell_outdoor_101/door_not_closed_0/state
binary_sensor:
- name: 'gate_door_exterior_status'
unique_id: gate_door_exterior_status
icon: mdi:door
device_class: door
state: >
true
attributes:
last_event: "{{ now().isoformat()}}"
@TokarevSergey correct, you have a event generated by the Intercom only when the the door contact is “open” and the event is only fired once ** when the door is open, but unfortunately there is no other (new) event when the door is closed after.
Because of that I had to change the reed switch from a NO (normally open) to a NC (normally close ) and invert the behaviour. So, when the door is closed for the intercom is Open and that will allow a a new trigger since by open the door it will close the magnetic switch that will open again after close the phisical door and fire an new event. It is a bit tricky but it works very well…
I have two physical ways to open it:
a) Using a sonoff relay BasicRFR3 (modified to have a dry contact)
b) The intercom relay than can be enable by the indoor station and/or HA
Here is the sensor final sensor code (if you only have the intercom relay delete the sonoff part)
# Sensor to check the real status of the Outside Door Gate
- trigger:
- platform: state
entity_id: switch.sonoff_1000911d6f
to:
- 'on'
- platform: state
entity_id: switch.bell_outdoor_101_door_relay_0
to:
- 'on'
- platform: mqtt
topic: hmd/device_automation/bell_outdoor_101/door_not_closed_0/state
binary_sensor:
- name: 'gate_door_exterior_status'
unique_id: gate_door_exterior_status
icon: mdi:door
device_class: door
state: >
{% if trigger.platform == 'state' %}
{% if trigger.to_state.entity_id == 'switch.sonoff_1000911d6f' or trigger.to_state.entity_id == 'switch.bell_outdoor_101_door_relay_0' %}
true
{% endif %}
{% else %}
false
{% endif %}
attributes:
last_event: "{{ now().isoformat()}}"
When the door closes the mqtt trigger will change the status to off by returning a false.
1 Like
Understood. I just have wires stretched and there is no way to change the reed switch. You have to buy the sensor separately. and just connect instead. Thank you.
Please tell me, do you happen to have any information on how to bind and integrate KH6320 so that I can use it as an alarm? Thank you.
Thank you.
thats not possible yet, at the moment you can only see this:
I was not able to indentify the correct type/number yet…
Hey, some good news, i fixed the Zone Alarm, i will include in next beta
now i see the Type and the Zone number 
2023-06-28 16:58:08.649 | INFO | mqtt:video_intercom_alarm:262 - Zone Alarm detected on doorbell DS-KH9510-TEST type 0 number 7
2023-06-28 16:58:22.379 | INFO | mqtt:video_intercom_alarm:262 - Zone Alarm detected on doorbell DS-KH9510-TEST type 11 number 2
I need to include proper names etc…
1 Like
Hello Everyone,
Is this integration able to get a card reader ID or number upon swipe? I would like to trigger automations depending on what keycard is used. I have been playing around with some ISAPI commands but I haven’t been able to exactly get what I need.
Yes it does, you will see a number as an attribute on the switch entity when the door opened
1 Like
But use the beta addon! It will be released soon as official version, almost ready
Understood. Thank you so much!
1 Like
I’ve been testing this with a light toggle as an action before using it for more complex things and there is something in the switch behaviour that it is not working as I think it should. Problem is that the “control source” attribute takes some time to be updated. It is just one or two seconds, but it is enough for an automation to think that the card/button used is the previous one instead of the actual one, and this is a security flaw from my point of view if (for example) an alarm disarm is involved in the automation for specific users. I am saying this because the way I had to set the trigger up in the automation was the following:
platform: device
type: turned_on
device_id: 1c1711774ef4a66ee72191a14d4d72bd
entity_id: switch.doorbell_beta_door_relay_0
domain: switch
My first option was the one below. However, it doesn’t work for the purpose in case the same card is used two times in a row because the attribute does not change, so automation is not triggered:
platform: state
entity_id:
- switch.doorbell_beta_door_relay_0
attribute: control source
to: "1234567890"
I am thinking in a workaround which will probably include some conditions and delays in the automation actions, but it will require a quite long automation with different IDs, delays and code exceptions (like the codes returned upon opening the relay with either the Hik App, the beta switch or the current non-beta unlock option through hassio.addon_stdin command. On top of that, you will never be 100% sure whether it is going to be accurate. Having said that, it would be great if:
-
“control source” attribute is removed after a few seconds (i.e.: when switch status goes back to the “off” state). At the end of the day, it is enough for the purpose to be able to detect a change to a specific code and flush such attribute. If this is done, at least there won’t be any risk for the automation to think that a wrong user is swiping its card.
-
The “control source” attribute is refreshed at the same time that the switch relay state is updated, however, I am not sure whether this is an integration problem or a HikVision API problem, so perhaps it will not be possible to achieve this, although perhaps it is possible that the integration waits for the attribute to be updated before changing the actual switch state to “on”.
Apart from this, I suggest to change the attribute ID from “control source” to “control_source” (with no spaces and an underscore). Honestly, I am not sure whether using spaces in IDs is a big deal, but it is the way I always see them and it will may cause an unexpected behaviour under some circumstance.
Perhaps I am missing anything, so please do feel free to suggest another way to do this. If not, it would be great if this feedback is considered for a future addon release. Thanks!
clear, but this automation below… why not check for the state when the switch was turned on, and then grab the controlsource from it?
platform: state
entity_id:
- switch.doorbell_beta_door_relay_0
attribute: control source
to: "1234567890"
Maybe i can create a device trigger, like we do for motion, zone alarms, or door not open, then add a device trigger event for doorswipe ?
I tried this, but problem is that, sometimes, control_source has not updated according to the latest card reading upon condition check, so the previous attribute state is the one taken into account. That is the way it behaves according to my tests. I mean that it seems switch state is updated to “on” and attribute is changed afterwards, not at the same time, so attribute condition check is not accurate. Anyway, I will double-check this and will give you further feedback.
I am not sure whether it will work for the same answer given to your previous quote.
i add this to beta 23 , maybe this works for you?
EDIT: beta 23 online