Events in the new Dev version.

[TomasCorral]

Hi,

In my understanding the new visonic_alarm_panel_state generates one event for each panel change right? No count variable and an array. Event is way simpler to understand this way now.

Also, would it possible to include more data in the new visonic_alarm_sensor_state?

For example tamper does not report tamper closed/open, only when open Door generates an event for open and closed but without any mention to what of them, would it be possible to include some value more info like the old event had?

Since this is not an issue, we can pass it to the discussion tab if you want to.

[davesmeghead]

In my understanding the new visonic_alarm_panel_state generates one event for each panel change right? No count variable and an array. Event is way simpler to understand this way now.

Yes, it rarely happens that there's more than 1 (there can be up to 4 in the A7 message), if there is more than 1 it loops to send each out as an individual HA Event. I think that this is better than complicating the content of the Event, especially when each thing in A7 can be different and not related to each other anyway.

Also, would it possible to include more data in the new visonic_alarm_sensor_state?

This is a tricky one and I've thought about this. The Event contains the Sensor Entity ID and so in all Automations it should be easy to get the state and any of its attributes. This is how the folks at Home Assistant want us to do it nowadays.

I can add to the STATE configuration setting to be able to select more states (including close etc) if you think that would be of benefit but I think that the initial triggering things i.e. open, tamper is the main Event

We should maybe include this when I ask more users to join in with the dev testing on the main forum, do you think it's robust enough to do that yet?

[TomasCorral]

I think its way better that way. They way I done it(and I think almost everyone) with the old events was just reading the first item from the list which 99% of time is the only event. Way better to setup automations now, thx.

Well, I did not know it's supposed to do like that, we should follow that then. I think an event should be triggered when fault conditions clear aswell. For example an event is triggered when device is opened(tamper). But no event is triggered when tamper goes away. For motion its only when motion is detected, not when cleared(this one idk if it should trigger on motion clear tbh). I did not tried to trigger a smoke alarm in one of my sensors to test what events are generated. My point is, if the event should be a trigger to start an automation, we should make the event trigger in more conditions and the automation polls the entity attributes for the conditions or the event has more info.

The Sensor Entity ID in the events takes me to other issue I had with the master that I did test if it's the same in dev yet. Does Entity ID field in the event update if we change the Entity ID trough the UI. In my old automations I had to form my own Entity ID's from the zone field in automations since I changed the entity names.

For me dev seems to be working just fine, I would say its just little improvements that I can try to help if you want. We could maybe add a beta release in github with breaking changes warning and if someone wants to use it and provide feedback they could more easily do that.

[davesmeghead]

For all Entities in HA, when the State of the Entity changes then Events are fired on the Event Bus (internal to HA). All state changes have an Event, both set and cleared.

The User can easily make Entities from Attributes. For example, if the User created an Entity associated with the "Battery" Attribute then an Event would be created for all the State changes of that Battery Entity. In fact, a single Entity can represent Attributes from different sourced Entities, so a single Battery Entity can be created using the Battery Attribute of many Sensor Entities.

In addition, Automations that are triggered on this "positive" Event can create a trigger on the Attribute itself being "reset/clear" back to normal.

The User can also Group Entities to create a common control group, to make it easier, all this is available in the HA UI without using yaml files.

There has always been a tradeoff of what functionality do we put in the Integration and what do we expect the User to do. For most Users, the triggering of an Event when something out of the ordinary happens (tamper being activated, battery low) is enough. to create a prompt for them to do something. For the remaining Users that need more then they can create their own Entities from the Attributes themselves or by creating Automations using templates and Attributes.

To summarise, I do not think we need to add additional Events to indicate when these things go back to normal (are cleared). The State itself is taken care of by HA. In fact using the setting that you did for Magnet/Wired, by setting that to Zero means that the State change represents the actual State.

I'm not sure what happens when you fully rename an entity, I'd imagine that you'd lose the underlying Entity as it's now not in the HA database. I think this is a dangerous thing to do, this is different to giving it a nicname.

Due to the changes that the core team have made in Home Assistant over the past 10 months or so, there are HA Warnings coming up with the Master Release because of deprecated changes. I have fixed these in the Dev Release and I'm reluctant to fix them in the Master, especially as it's been so long. I'm more inclined to just pull the Dev in to the Master as a "big breaking change". I can then continue with the minor Dev updates for the "latest and greatest". I have written down in my notes that the first one of the deprecated things in the Master will no longer work in the August release so I have 2 weeks left to test the Dev release, my plan at the moment is to then Pull that to the Master.

[TomasCorral]

I can agree the attributes triggering automations and remove the need to use the events. That's how I'm doing it, I stopped using events in the new version. I also think most people don't like to use templates, myself included, because entities are not grouped under the device and integration they belong with, something asked a lot to be implemented by HA but we don't have that ability yet.

I havea question about visonic_alarm_panel_state tho, what does event_valid and event_time fields mean?

I did noticed that in the dev version if an entity id is changed the event is generating with the right entity id. Something that master version did not do. I can now change entity ID's and events will work if I end up using them.

I will continue to use dev version cuz im already migrating my automations. Whenever you end up merging I will start using HACS again.

[TomasCorral]

Also the integration is not generating events for closed window sensors, only when opened. In one of my comments I said it was generating and I'm 99% sure it was. Whats the intended behavior to expect here?

[davesmeghead]

I have just updated the Dev release and the wiki

I also think most people don't like to use templates, myself included, because entities are not grouped under the device and integration they belong with, something asked a lot to be implemented by HA but we don't have that ability yet.

Agreed ... but that's the way it is

I havea question about visonic_alarm_panel_state tho, what does event_valid and event_time fields mean?

event_valid is simply a boolean validity and has been removed event_time has also been removed as all events in HA get a "time_fired"

All events include the alarm panel entity id and the panel number. Sensor Events also include the sensors entity id

Also the integration is not generating events for closed window sensors, only when opened

I've include the STATE event to be generated when a magnet/wired sensor is closed. This is new, it didn't do this before, only on opened. To be true to the HA rules I should not create a STATE event on a sensor being triggered as this is already created from the entity state change anyway, but it currently does.

On Developer Tools listen to the events and let me know what you think.

[davesmeghead]

Hi, I'm thinking of changing the Panel and Sensor Events again and cutting them down significantly as most of the info is easily retrieved using the built in HA Events as the Panel and Sensors change state, with their attributes changes. I've been experimenting and I can get 2 events for the same thing, one that I generate and the other is from an HA built in Event. I used multiple web browser windows connected to HA, each listening on the different Events. So this is not consistent.

What triggered my thoughts is when you said about the magnet sensor being closed, this is easily achieved using the built in Event. This is what I experimented with, opening and closing a door (if the neighbours saw me they'll think I've gone mad).

I'll leave the log events (visonic_alarm_panel_event_log_entry and visonic_alarm_panel_event_log_complete) and the command success/failure Events (visonic_alarm_command) as they are, but the panel (visonic_alarm_panel_state) and sensor (visonic_alarm_sensor_state) events I'm thinking to strip them back to only what is not available using the built in HA Events.

Dave

[davesmeghead]

So I've spent a few hours today cutting down the content of the Panel and Sensor Events, uploaded new Dev release and wiki to go with it.

I've also moved your code, I hope you don't mind. It was one of the less important things on my todo list but since it was changed anyway I thought I'd get it done. The sensor timeout shouldn't be in the low level code that interfaces with the panel, so I've moved it in to client.py with the timeout in binary_sensor.py. This makes it more generic, one of my goals was to remove or move as much of the config settings from the low level panel interfacing. Dave

[TomasCorral]

I am on vacations now. I haven’t been home for some days and did not test the changes yet.

In my tests using the entity attributes to trigger events seem to be working just fine. One thing I noticed is that visonic_alarm_panel_state event does not clear the event field. So for example tamper occurs, then an event is triggered and event field says that. If I then open a window there is an event triggered with ready=false but the event field remains the tamper from last event. Is it the supposed? I guess not since wiki mentions:

Note that if event is:

• "None" then no specific event/action has taken place
• not "None" then a specific event/action has taken place, as indicated by the value

I think that focusing on entities for automations is a good way. I think that entities should have the attributes that fit their type. For example motion smoke water etc have Zone Open attribute. There’s some confusion between open/tripped/triggered etc. Maybe add a table in wiki for each sensor type explaining how each attribute works.

But I think cutting some events and adding more/better attributes to entities should allow anyone to make automations using the attributes like you mentioned. In the logs you seem to be able to identify sirens/keypads/keyfobs, you could maybe create some entities for that as well, idk what info you can get from the alarm and if someone finds it useful to be worth your effort.

To be clear, I’m not rly trying to enforce anything. It’s more like feedback but only from one user, it might not represent everyone.

When Im back home I will test the changes and the new events.

[davesmeghead]

Hi, The issue about the event field is a bug, I'll check on it thanks for telling me

You'll notice that a PIR/Camera does not include the open attribute anymore, any further changes you'd like to the attributes for each sensor type then just let me know.

The problem with sirens, keypads and keyfobs is that the panel tells me what it has but then there is no further status messages or changes, so I concluded that there's no point in creating Entities for them, as they wouldn't change. All the alarm panel states, including "triggered" is part of the alarm_control_panel Entity.

Lastly, thanks for the feedback, it's appreciated, and have a good vacation.

[davesmeghead]

I've pulled the Dev across to the Master so I'll close this Issue

[TomasCorral]

I am using new version now. No problems with the new events. Mainly using attributes now and creating more automations. Would you be interested in adding some of my automations to wiki examples?