As we have access to the panel internal settings, I think we should be able to sort out the logic to determine if the siren is sounding or not (Panel Alarm Status + Panel Trouble Status + Internal settings) ?
I’ve uploaded version 0.3.6.1 to Github. There are 2 updates in this release
New Configuration Item
There’s a new configuration.yaml item as follows, with a complete list of string options
siren_sounding = ['Intruder', 'Tamper', 'Panic', 'Fire', 'Emergency', 'Gas', 'Flood']
This is an optional parameter with a default setting (that should work the same as previous releases)
siren_sounding = ['Intruder']
I have only tried this once as it means setting my siren off 
so please test it.
You need to set it the same as what your panel does.
HA Event updated
There’s a new “condition” value of 11 for the alarm_panel_state_update event
This is generated in HA when you try to arm/disarm the panel from within HA. It contains data about the sensors that are “OpenZones”, “Bypass”, “Tamper”, “ZoneTamper”. So, for example, if you try to set the alarm (from within HA) there will be an event (condition = 11) that tells you if there’s 0 or more zones open. The HA Event is generated Before the arm/disarm command is sent to the panel.
I have not updated the wiki yet as we might end up changing the operation of these.
Feedback as always very welcome 
Thanks, I have tried again:
https://pastebin.com/zj9USbbt
The condition 11 is correctly triggered.
However I don’t understand how to access the data in OpenZones, is it in the “trigger.event.data” ?
I have to re-read the manual again, but can the Panel failed to get armed once we start to arm it (i.e. condition 11 is not triggered when we arm, but the Arm Away is not successful) ?
If yes perhaps we’ll need a condition 12 or something to handle this case.
I’ll try to trigger this behavior.
Thanks a lot for your support.
Yes.
OpenZones (and the other parameters) is a list. You need to use square brackets, put this in the dev tools template editor
Imitate available variables:
{% set my_test_json = {
"OpenZones": ["binary_sensor.visonic_z01","binary_sensor.visonic_z02"]
} %}
The First Zone is {{ my_test_json["OpenZones"][0] }}
The First Zone is {{ my_test_json.OpenZones[0] }}
For loop example:
{% for entity in my_test_json.OpenZones -%}
{{ entity + "\n" | lower }}
{%- endfor %}
The panel will not arm if it is not ready, check the attribute “Panel Ready” for “No” or “Yes”. I will include the attribute in the event (condition 11) to make it easier. Condition 11 will be an event whenever there is a call to arm/disarm the panel unless it fails a few check I have (I’ll also add some events for the various failure cases e.g. Pin not set). Whether the panel actually does it you can only tell when the panel changes state from Disarmed.
EDIT: Forgot to add that you can either do it like this my_test_json["OpenZones"][0] or my_test_json.OpenZones[0] so I edited the example above to do both.
I’ve just uploaded a new release 0.3.6.3 to Github (just after I did 0.3.6.2 
)
I suggest you trigger on the “alarm_panel_state_update” event and then use “condition” = 11 and then “PanelReady” as a boolean state. If “PanelReady” is False then use the “OpenZones” list to show the zones that are open (perhaps getting their friendly names). If the “OpenZones” list is empty then perhaps display a generic message “There’s a problem with the panel”
Showing these zones might not be the whole story as there could be other reasons why the panel will not arm/disarm that I don’t know about. Perhaps because of a “Tamper” but that list is in the event as well. I also included a “Bypass” list just in case you need it (the list of bypassed zones).
I’m not sure about putting “PanelReady” in the event data but it makes sure that it is pushed through in to HA with the event instead of any delays in showing up as an attribute, so I added it to the event.
I have also added a condition 12 for when I can’t send the request to the panel. The reason is in the “Message”. I think that you can test by setting “allow_remote_arm” to “no” in your configuration.yaml file and then try to arm the panel using the HA frontend. As well as the “Message” would you like a unique integer value as there are several reasons to send a 12.
You will receive a condition 11 or 12. When it’s 11 you at least know that the request has been sent to the panel.
D
I’ve just been playing again with my automations 
and thought I would show you these
- alias: 'Alarm Panel Arm/Disarm Request Action'
initial_state: true
trigger:
platform: event
event_type: alarm_panel_state_update
event_data:
condition: 11
PanelReady: False
action:
service_template: persistent_notification.create
data_template:
title: "Alarm {{ trigger.event.data.Command|string }} Request Failed"
message: "{% set st = trigger.event.data.OpenZones %}
{% if st|length > 1 %}
There are open zones, check the following
{% for ent in st %}
{{ '\n' ~ ' '|safe*30 ~ state_attr(ent, 'friendly_name') | string }}
{% endfor %}
{% elif st|length == 1 %}
The {{ state_attr(st[0], 'friendly_name') | string }} is open
{% else %}
And I do not know why it failed
{% endif %}"
- alias: 'Alarm Panel Arm/Disarm Reject Action'
initial_state: true
trigger:
platform: event
event_type: alarm_panel_state_update
event_data:
condition: 12
action:
service_template: persistent_notification.create
data_template:
title: "Alarm {{ trigger.event.data.Command|string }} Request Failed"
message: "{% set st = trigger.event.data.OpenZones %}
Could not make the request to your alarm panel \n {{ trigger.event.data.Message|string }}
{% if st|length > 1 %}
Also there are open zones, check the following
{% for ent in st %}
{{ '\n' ~ ' '|safe*30 ~ state_attr(ent, 'friendly_name') | string }}
{% endfor %}
{% elif st|length == 1 %}
Also, the {{ state_attr(st[0], 'friendly_name') | string }} is open
{% endif %}"
The first triggers when you try to arm (and disarm) the panel and there are open zones e.g. you left a window or door open. It puts a notification in the HA frontend telling you which zones. It sends the request to your alarm panel but the panel will ignore it.
To test this: Open a door or window and try to set the alarm from the HA frontend.
The second triggers when the request is not made to the panel, with a message telling you why.
To test this: Set allow_remote_arm: 'no' in your config and try to set the alarm from the HA frontend.
Oh yeah, you need to be using release 0.3.6.3
D
Hello,
I just tested everything and it seems to work, that’s great, thanks !
It seems that ‘Message’ is also sent with Condition 11:
{
"event_type": "alarm_panel_state_update",
"data": {
"Command": "Armed",
"PanelReady": false,
"OpenZones": [
"binary_sensor.visonic_z01"
],
"Bypass": [],
"Tamper": [],
"ZoneTamper": [],
"Message": "Panel Access, Sending Command to Panel",
"condition": 11
},
"origin": "LOCAL",
"time_fired": "2020-03-07T06:50:47.522282+00:00",
"context": {
"id": "6d87c91e9f81458b8d4a15b0627b46a4",
"parent_id": null,
"user_id": null
}
}
But the ‘Message’ doesn’t seem relevant ?
I also tried to trigger a sensor during the arming delay and an Alarm is correctly triggered AND a Condition 11.
What is the difference between ‘Tamper’ and ‘ZoneTamper’ ?
Thanks a lot again
I did that in case anyone wanted to combine 11 and 12 in the same automation, then Message could be used from either. Having said that, I think I’ll replace message with a unique integer that can be used to select your own message. I think that adding a unique integer would be better than a message text in English.
Haha, no idea. The panel sends the data and I just pass it on 
EDIT: And do we need both 11 and 12, should I combine them in to the same one. I ask as I’m not that good with the automation side of HA and how to set them up. What is “best practice” for doing this in HA?
Well, you made me look:
Zone Tamper : "Tamper switch protection of all zones and other peripheral devices (except the control panel).
Tamper: The control panel tamper.
So I’ve done some experimenting and I think there are 3 tamper values
The first is the Main Panel Tamper, this is an attribute of the alarm_control_panel.visonic_alarm called Tamper (the panel sends this through in the panel settings PDU A7)
Each zone has 2 Tamper values, a zone tamper and a device tamper (through the zone settings PDU A5 message). I think that the device tamper is the raw data and the zone tamper is more like a logical setting. Let me explain why I think this.
I removed the cover from one of my PIRs (the panel is disarmed)
- That set both zone and device tamper to ‘yes’ for that PIR
- I then set Arm Home through HA, the panel set zone tamper for that PIR to ‘No’ but left device tamper at ‘Yes’
- The panel armed home but told me that there’s Trouble. Also Panel Ready was set to ‘No’ and it still did it.
- I then Disarmed the panel
- I then set Arm Away through HA and the panel refused
When you get an HA Event condition 11 or 12 then Tamper is the raw device tamper and ZoneTamper is the logical zone tamper.
That makes sense based upon your testing and observations. I’m guessing the behavior is similar to the wired sensors which use a loop resistance to detect different states (Tamper, Normal, Arm, Disarm, Alarm).
There are several zone types that have different behavior dependencies based upon Away and Home mode. These are listed in Table A1 of this User Guide:
https://www.visonic.com/Data/Uploads/PowerMaster_10_30_G2_User_Guide_English_V19_4.pdf
Edit:
Apologies. The Table in the User Guide was relative to partitions, which is not relevant to the integration. Here’s what I should’ve listed for some Zone Types where there was a dependency to Home or Away mode. Looking at them, they seem fairly obvious, but I’ve never given them any thought relative to the integration.
- Home Delay: Applies to door or window switches and motion sensors. Works as a delayed zone when Home, Perimeter Follow when armed Away.
- Perimeter: Triggers alarm when armed Home or Away.
- Interior: Triggers alarm only when armed Away.
In total, there are 18 Zone Types on the PowerMaster G-10/30 panels.
I’ve just uploaded release 0.3.7.0 to Github, please give it a try.
If you use the HA Visonic Events then it’s a breaking change (sorry)
3 Main areas of change
- Several changes to HA event generation, I have updated the wiki so please read it. I combined events 11 and 12 in to 11 but there is a new 12, 13 and 14 so be careful.
- There are 2 new configuration.yaml settings
arm_away_instantandarm_home_instant. They both default to the existing operation so should be OK. - There are 2 new HA Services
alarm_panel_commandandalarm_panel_download
alarm_panel_download is very experimental so don’t use in a “production” environment i.e. don’t expect it to be 100% reliable It’s main use is if you change any panel settings. You can trigger an automation from the “System Reset” event to re-download the panel settings if you wish to.
Please read all the descriptions on the wiki as I have tried to do an extensive write-up for them.
For most users this will not make a difference as you probably don’t use services and events, and the 2 new config parameters will continue as before anyway.
Any problems then I’m sure that you’ll let me know. I’m aiming for a HACS release update soon as well as there hasn’t been one for a while, let’s see how we get on with this release
Oh yeah, for automations you might find this useful:
trigger:
platform: event
event_type: alarm_panel_state_update
condition:
condition: template
value_template: >
{{ trigger.event.data.condition in [12,13,14] }}
Do you have a list of them, are they cameras maybe? I currently have the following zone types, only 16 of them 
"Non-Alarm", "Emergency", "Flood", "Gas", "Delay 1", "Delay 2",
"Interior-Follow", "Perimeter", "Perimeter-Follow", "24 Hours Silent",
"24 Hours Audible", "Fire", "Interior", "Home Delay", "Temperature", "Outdoor"
Also I use the same list for all panels i.e. PowerMax and PowerMaster
1 Like
Hi Dave,
Maybe you can help me with the following. Currently the setup is running in Standar Plus mode, but for some reason it refuses to jump to Powerlink mode. I know there is not much of a deference between Plus and Powerlink mode, still I thought it’s maybe helpful to troubleshoot to further tweak the plugin to perfection. I tried to enroll the powerlink connection, but that results in a long beep, so unsuccessful.
Please find more info wrt to the setup below
HA: 0.106.5
Connection: via USR-TCP232-E2
Alarm: Powermax Pro Model 22
Plugin: 0.3.7.0
force_autoenroll = No
Panel Serial: 0211029422.
Panel Eprom: J-700620 v4.6.06
Panel Software: JS701192 v4.6.06
visonic:
device:
type: ethernet
host: x.x.x.x
port: y
motion_off: 120
language: 'EN' #'NL'
force_standard: 'no'
sync_time: 'yes'
allow_remote_arm: 'yes'
allow_remote_disarm: 'yes'
force_autoenroll: 'no'
# exclude_sensor: [2,3]
# exclude_x10: [1]
# force_numeric_keypad: 'yes'
panellog_logentry_event: 'yes'
# override_code: ''
# download_code: '5650'
# arm_without_usercode: 'yes'
Please find the log here: https://pastebin.com/qhcBMFWx
I’ve taken a look through your log file and it looks like:
- You restarted this component in HA when your panel is in the installer menu, is this correct? If it is then quit out on the panel to the normal screen and reset HA.
- You either do not request a manual powerlink enrollment or you have had a powerlink connected in the past and it hasn’t been un-enrolled. In the log file you uploaded, there is not a request from your panel to enroll so I don’t trigger the panel enrollment process for a Powermax Pro (there’s no point until the panel asks for it). Did you try to manually enroll during this log file?
I suggest that someone else with a Powermax Pro help out here with the sequence of things to do and try. Perhaps
- Be on the normal panel screen (after un-enrolling a previous powerlink module)
- restart HA or just this component with the service call
- Wait until it shows Standard Plus
- Go in to your installer menu and try to manually enroll a powerlink module
Let me know how you get on
The zone types you list are correct as of 19.412
The pir camera lists its zone type for the pir and the camera is assigned a trigger action. Only ofther devices would be the keypad or RF fob.
Video cameras installed by suppliers like then connect to the panels wifi (360/360r) or gateway (10/30/33) but only present in applications from amdocs, alarm.com etc
Thanks for the info, I’d still like to make sure so
Anyone with a PowerMaster panel, can you check each visonic sensor details and look at the “zone type name” attribute, tell me if its incorrect please (according to your panel settings)
If it is then tell me what it is, what it should be instead and also the “zone type” number.
Hi Dave,
Thanks for your quick response.
Going through your remarks below;
- That’s correct, I did a reset of the connection via the visonic.alarm_panel_reconnect service. I followed the steps 1 to 4, and attached a new log. Also with step 1 to 4 the panel refuses to enroll a powerlink.
- I did try to manually enroll the powerlink module, but to no prevail, as it results in a long beep.
There was no powerlink module installed before. As I’m the first owner, I’m sure about that. I also don;t have the option in the menu to remove a powerlink module. The only option I have is to enroll a powerlink module.
Please find the new log here; https://pastebin.com/F99MnVUj
In case someone else has a powermax pro, type 22, and successfully enrolled “HA”, please share the steps that were followed.
I’ve looked through your log file and it is now asking for enrollment (that’s good) but your panel isn’t sending the powerlink messages after that. You’re manually enrolling about 8 seconds apart, maybe try manually enrolling, exiting the installer menu and then leaving it a few minutes.
If you’re willing to experiment and you can change pyvisonic.py then try changing line 1255 (in version 0.3.7.0) from this
if self.PanelType >= 3: # Only attempt to auto enroll powerlink for newer panels. Older panels need the user to manually enroll, we should be in Standard Plus by now.
to this
if self.PanelType >= 2: # Only attempt to auto enroll powerlink for newer panels. Older panels need the user to manually enroll, we should be in Standard Plus by now.
i.e. change the 3 to a 2. This will try to send an Enrol to your panel instead of a Restore request after you manually enrol on your panel. I’ve seen mixed results with a Powermax Pro panel in doing this but I think it’s worth a try if you’re confident to have a go. If you decide to have a go then let me know the results (and another log file please).
Also remember to leave it much more than 8 seconds between manual enrolls on your panel
D