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
I think the fact that the attributes are not updated at the same time lies here:
The MQTT implementation in HA requires to publish two separate messages, one for the state and another for the attributes. I think that what you see is that you first receive the state update, while the attribute update is still to be acknowledged in a second message. Maybe we could fix this by inverting the two lines, but given the async nature of MQTT I think it might still happen that the attributes do not align perfectly.
1 Like
That makes sense and explains what it is actually happening. A workaround could be just to add a small delay before checking the attribute in the automation. But, as told in my first related post, I think it would work just to flush the attribute state after a few seconds, so setting up a trigger according to “control source” state change will definitely work for the purpose.
Yeah, but I think it’s useful to keep the attribute there and not to flush it? Otherwise users don’t see it anymore as a history… Then can still offcourse look in the logs
Perhaps you can create another attribute in order to have two: one persistent and one not persistent. I know it can be confusing, but as long as both options are documented, I don’t see any problem.
1 Like
I agree, I would not implement too much logic inside the sensor itself, better leave it to the consumer of the sensor to decide on what to act.
Maybe a better use case here is the device trigger, to signal that “hey someone unlocked the door here are all the attributes you may need for this event”.
i added the device trigger in beta 23 , can you test it @sesardelaisla
Indeed another way is to use a persistent attribute and a last_control_source attribute
I am open to improve the sensor for your use case, just I would like to discuss this in more details on an appropriate Github issue. IMHO introducing disappearing attributes attached to a sensor is not the cleanest approach, maybe there is a solution that is simpler and we are simply missing at the moment. 
1 Like
That worked!
This is the automation I just tested. Key 01 and Key 02 are RFID keys. “00” code is the one given upon pressing the door opener in the Hik App. “979899100” code is the one I get when using the non-beta stdin command. Different surrounding lights were used for the test:
alias: "TEST: Doorbell RFID"
description: ""
trigger:
- platform: device
domain: mqtt
device_id: 1c1711774ef4a66ee72191a14d4d72bd
type: not closed
subtype: Door 1
discovery_id: Doorbell_Beta door_not_closed_0
condition: []
action:
- choose:
- conditions:
- condition: state
entity_id: switch.doorbell_beta_door_relay_0
attribute: control source
state: "[Key 01]"
sequence:
- type: toggle
device_id: 48bd2a331e299659e75004ce3bda967e
entity_id: light.columna_izquierda
domain: light
- delay:
hours: 0
minutes: 0
seconds: 5
milliseconds: 0
- type: toggle
device_id: 48bd2a331e299659e75004ce3bda967e
entity_id: light.columna_izquierda
domain: light
- conditions:
- condition: state
entity_id: switch.doorbell_beta_door_relay_0
attribute: control source
state: "[Key 02]"
sequence:
- type: toggle
device_id: 4c74a816affd84d2850fb46be36c49cd
entity_id: light.columna_derecha
domain: light
- delay:
hours: 0
minutes: 0
seconds: 5
milliseconds: 0
- type: toggle
device_id: 4c74a816affd84d2850fb46be36c49cd
entity_id: light.columna_derecha
domain: light
- conditions:
- condition: state
entity_id: switch.doorbell_beta_door_relay_0
attribute: control source
state: "00"
sequence:
- type: toggle
device_id: 4c74a816affd84d2850fb46be36c49cd
entity_id: light.columna_derecha
domain: light
- delay:
hours: 0
minutes: 0
seconds: 5
milliseconds: 0
- type: toggle
device_id: 4c74a816affd84d2850fb46be36c49cd
entity_id: light.puerta_izquierda
domain: light
- conditions:
- condition: state
entity_id: switch.doorbell_beta_door_relay_0
attribute: control source
state: "979899100"
sequence:
- type: toggle
device_id: 4c74a816affd84d2850fb46be36c49cd
entity_id: light.puerta_derecha
domain: light
- delay:
hours: 0
minutes: 0
seconds: 5
milliseconds: 0
- type: toggle
device_id: 4c74a816affd84d2850fb46be36c49cd
entity_id: light.columna_derecha
domain: light
mode: single
The only “issue” is that the automation triggers 5-6 seconds after the key or the gate opener command is used, but that is not a big deal. Given how the MQTT entries are updated it is a nice approach! I have tested several times and different situations (same key a few times, different keys, app button…) and it always works so everything is great for me.
As a side note, I cannot set a “door open” type. “not closed” is the option I can set for such. However, final result is the expected.
I do agree with you.
No need to. Thanks! For me, this approach is great. 
Thank you both so much for your prompt responses and feedback! Happy to help with further tests if you need.
1 Like
thnx for sharing, you dont need to use the non-beta anymore for opening doors using the stdin command… The door open command is also part of the beta addon itself, you can just use the switch turn on service now
But, in your example above, you dont use the device trigger i added for the key/badge events?
You use the door_not_open device trigger , thats another alarm event
Let me double check with the right alarm event and will tell you more tomorrow. It wasn’t available in the trigger type/subtype when I tried.
I have opened this issue for reference: Modify device trigger `door_open` · Issue #121 · pergolafabio/Hikvision-Addons · GitHub
The current implementation does not convince me 100%.
1 Like
Hi, from what I can tell, the Hikvision SDK and ISAPI (and iVMS for that matter) do not expose the status of the door reed switch in any straight forward way that could be used like a binary door sensor. Is there everyone else’s experieince and understanding or am I missing something?
I’m thinking through the use of the device_automation triggers, you could create a binary sensor in HA with some logic but it would always be guessing the state based on the triggers and you would never know for sure. Like there is no confirmation I can see of the door being closed after recieving a “door_not_closed” event, so you could infer a door was closed if it was open and then you did not recieve that trigger but if you recieved that trigger, you would have no way of knowing when the door was closed after that. So it seems like it is not worth it.
Does anyone have a good way to use the door sensor attached to the intercom in HA or is it just a case of using another sensor?
Hey , here is a workaround: