Now the UI is used for configuration, how do i set “sync_time”, doesnt seem to be an option.
James
Now the UI is used for configuration, how do i set “sync_time”, doesnt seem to be an option.
James
You can only set this when you are creating the integration so it is not shown when modifying it. See the wiki here. Try deleting the integration and then re-creating it, both from within HA, there’s no need to restart HA remember
Hi Dave,
I just upgraded from version 0.3.something to 0.4.4 with the use of integration. Now somehow my pm pro panel arms even when zones are in the open state…which means its bypassing zones? Is there something i missed, i did not select the bypass any zone option. It generates an error in the ha log so thats how i noticed: because of an automation notify message. I was surpised it armed anyway.
Before you restart HA, what is the error message? Can you post it here please.
Also, if it persists through HA restarts then please upload a log file, set yout logger config like this
Hi Dave,
After restarting HA, the panel seems to arm and disarm normally., However: Automations that worked before result in unexpected notify messages after upgrading.
Here are my automations:
- 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: notify.telegram_oliver
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: notify.telegram_oliver
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 %}"
Now, after reboot, HA triggeres the automations correclty when i try to arm the alarm with a zone open. It generates the correct message; “Alarm stay request failed: xxx is open”
But when i close the door, and try to arm i get: "Alarm stay request failed, and i do not now why it failed. Same goes for disarming: "Alarm disarmed request failed, and i do not now why it failed.
On the other hand, the panel actually arms and disarmes, so i guess the problem it the automation. I wouldnt even notice if it werent’t for the automation.
I guess the automations is triggered because of this:
2020-06-01 13:01:48 DEBUG (SyncWorker_3) [custom_components.visonic.pyvisonic] [RequestArm] RequestArmMode stay
2020-06-01 13:01:48 INFO (SyncWorker_3) [custom_components.visonic.client] Visonic update event 11 {'Command': 'stay', 'PanelReady': False, 'OpenZones': [], 'Bypass': [], 'Tamper': [], 'ZoneTamper': [], 'Reason': 0, 'condition': 11}
However, my panle is actually ready when i’m looking at it. The update event 11 says otherwise.
and then there is this in my logfile:
Logboekdetails (ERROR)
Logger: homeassistant.config_entries
Source: helpers/entity_component.py:163
First occurred: 12:36:21 (2 occurrences)
Last logged: 12:36:21
Error setting up entry Alarm Panel for binary_sensor
Error setting up entry Alarm Panel for switch
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 217, in async_setup
hass, self
File "/usr/src/homeassistant/homeassistant/components/binary_sensor/__init__.py", line 139, in async_setup_entry
return await hass.data[DOMAIN].async_setup_entry(entry)
File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 163, in async_setup_entry
raise ValueError("Config entry has already been setup!")
ValueError: Config entry has already been setup!
logfiles: https://drive.google.com/file/d/1tyjhPoXTMbbnRvsmsdjrt8PA6QK9DCaJ/view?usp=sharing
I’ve found the bug and I’ve uploaded a bug fix version to Github 0.4.4.1
Give it a try and let me know
I also noticed an error on the wiki regarding the 2nd automation. Condition 12 is the bypass condition so it should be like this (and I’ve also updated the wiki here)
- alias: 'Alarm Panel Bypass Reject Action'
initial_state: true
trigger:
platform: event
event_type: alarm_panel_state_update
event_data:
condition: 12
condition:
condition: template
value_template: >
{{ trigger.event.data.reason|int in [1,2,3,4] }}
action:
service_template: persistent_notification.create
data_template:
notification_id: "alarm_panel_state_update_bypass"
title: "Bypass 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 notification_id
means that you don’t get duplicate persistent notifications, later notifications replace the older.
Tnx for the quick reply. How do I update to 4.4.1 when using HACS and integrations? This was easy the old way…btw event 11 should be correct, I’m not using bypass.
edit: nevermind.I had some issues with permissions. Deleted the complete visonic folder and uploaded it again instead of replacing files. Works like a charm now, no more notifications
I’ve published 0.4.4.1 as a formal release on Github so HACS should pick it up as a new release.
In your 2 automations you published about 8 hours ago I noticed that the second uses condition 12, this puzzled me so I looked on the wiki and it looks like you copied it across from there. As you’re not using bypass your 2nd automation is incorrect and you should maybe delete it as you may not need it.
That’s good to hear, take care
You’re right Dave, the second automation didn’t make any sense. That was still in there from when i was experimenting with the alarm automations…i removed it from my config. Anyhow, very pleased everything works again.
Long thread, so how do I remove keypad for alarm enable/disable ?
And more important, how do I get from Unkown to something better for my PowerMax Pro ? Would like it to connect in PowerLink mode, but my model is listed as unknown. System is from 2008, and the PC connector pins do not have the plastic buyer/connector guide around them.
Can I somehow upgrade firmware myself ?
This should work with a PowerMax Pro and there are other users that have it working. Let’s start at the beginning, “Unknown” means it’s not getting very far through the start sequence, please set your logger settings like this and upload a log file to pastebin or dropbox. Please also check your hardware setup and wiring, I’m guessing (as I don’t have your log file) that we’re not receiving any data from your panel so I strongly suspect there’s a problem with your hardware setup.
I have it up and running. But, I can not disable the pin-code display. Want that removed as for me I have security on the App.
I get most of the stuff on the alarm_panel attributes, not sure what I am missing out on, it is in Standard mode, so how do I get it one notch up ?
Alarm has these attributes:
code_arm_required: true
Panel Mode: Standard
Download Timeout: 1
Panel Model: Unknown
Panel Type: null
Model Type: 0
And I do have this in my config. The download code is what I entered into the alarm myself using installer code. override code is user 1 code.
force_numeric_keypad: 'no'
override_code: '1234'
download_code: '5679'
arm_without_usercode: 'yes'
Hi again,
Have you read this section on the wiki, are you using configuration.yaml or the integration control flow to set it up (remember that it will only read the configuration.yaml file the first time)?
As “Panel Model” is set to Unknown, your panel has not responded to the basic start sequence, to work out anything more than that I need to see a log file as I suggested in my last post
Got my head around it now. Configuration.yaml only used during creation, the rest is in Integrations.
Now I am in Standard Plus mode, and I am happy for now.
Now I just have to give all my sensors nice names for the badges to be better.
How do people monitor status ? Say what is open/closed ? Battery ?
I was considering a template to create a HTML table, is there anything better ? Except to create lots of template entities ? And how to format them ?
<TR><TD>{{ state_attr('binary_sensor.visonic_z04', 'device name') }}</TD>
<TD>Office Window</TD>
<TD>{{ state_attr('binary_sensor.visonic_z04', 'device_tripped') }}</TD>
<TD>{{ state_attr('binary_sensor.visonic_z04', 'device_tamper') }}</TD>
<TD>{{ state_attr('binary_sensor.visonic_z04', 'battery_level') }}</TD>
<TD>{{ state_attr('binary_sensor.visonic_z04', 'zone type') }}</TD>
</TR>
```
That’s correct, although it can also be created using the integration entry as well.
To get to Powerlink your panel, a PowerMax Pro, needs to be manually enrolled. Have you tried manually enrolling from your alarm panel again while HA is running, enter the same download code again.
In my customize.yaml I have this
binary_sensor.visonic_z01:
friendly_name: Kitchen PIR
But you can also set the friendly name by selecting it in the frontend and setting the name.
In the frontend, you can create a new card with all this information on. Other users have customised a card to display this info but I use the standard frontend panels.
In my sensor.yaml I include this
- platform: template
scan_interval: 5
sensors:
visonic_exception_count:
value_template: >-
{{ state_attr('alarm_control_panel.visonic_alarm', 'Exception Count') | int }}
friendly_name: 'Panel Exception Count'
visonic_panel_status:
value_template: >-
{{ state_attr('alarm_control_panel.visonic_alarm', 'Panel Status') | title }}
friendly_name: 'Panel Status'
visonic_panel_mode:
value_template: >-
{{ state_attr('alarm_control_panel.visonic_alarm', 'Panel Mode') | replace("_", " ") | title }}
friendly_name: 'Panel Mode'
These extract state attributes from entities and make sensors out of them, you can then use them directly in the frontend card. You can do the same with the binary_sensor.visonic_z01
entities to extract battery data as well. Remember that the battery is either 0% or 100%, the panel only tells me when that battery needs replacing.
Yeah, but creates lots of new “sensors” in HA. What I really want is more like the ability to directly use sensor.name.attribute - But still only sensor.name should exist in the tree. But that is a discussion for somewhere else. I have MANY things where I would like an easier way to supervise the battery status, without that cluttering all the config menus.
Thanks for the wonderful work Dave, this component is what I dreamed of.
I have a Powermax Pro, with a few “Next-MCW” Pir detectors, but only 1 of them is detected as a ‘Motion’ device, all the others are detected as ‘Magnet’ devices. I looked at pyvisonic.py and noticed pmZoneSensorMaster_t does not contain Next MCW detecters, but as far as I can tell this is only for PowerMaster models…
So could anyone wit the same type of sensors (NEXT-MCW) tell me if they get detected as magnet or as motion ?
Or is this something you can define on the PowerMax panel itself ?
Please upload a log file (after setting the logger config) to pastebin or dropbox and I’ll take a look.
Please find the log here: https://pastebin.com/k1FBSN9R
Sensor i=12 until i=17 are all NEXT-MCW’s. But only the last one (0xe3) is recognized as ‘motion’.