Ah OK, you’re getting confused. The Panel log file that the integration creates is about the panel events.
With some older panels such as very early Powermax+ panels you’ll need to manually enrol after restarting, but I can take a look at a Home Assistant debug log file to check for you.
To create a Home Assistant log file with debug information please add this to your configuration.yaml file and then zip the log file. Either upload it to Dropbox or similar and place a link here or create an Issue on Github and that will allow you to include zip files in the issue itself.
Development release 0.9.8.2 uploaded to dev_B0 on github.
This development release is for a test for a Powermax+ (and other panels that manually enrol) and an update to the 3 current language files.
For language file development it’s probably best if we track updates as Github Issues:
French here
Italian here
Dutch here
As before,
Please can you create an Issue on Github for it i.e. “Translation in Portuguese” for inclusion and discussion.
Please give this release a try. In your log file the panel is sending Powerlink alive messages from the start but refusing to download EPROM until you manually enrol. So in this release, if it receives Powerlink alive messages at the start it asks to panel to enrol, I want to see if this fixes your issue or if not then I want to see how the panel responds. So please be prepared, this might not be a fix but I’d like to see a log file in either case to see what the panel response is.
For all the panels that automatically enrol, I’ve tried to test using my panels but only once did I get the right conditions i.e. the panel outputting an alive at the start, and it seemed to work but be prepared for it not working just in case. In other words this release has had very limited testing.
I have added a translation for the Netherlands but this only includes the text in the original integration so is very dodgy and only about 20% complete. If anyone wants to edit it to complete it or just improve it further then post in the Github Issue Translation for Netherlands · Issue #157 · davesmeghead/visonic (github.com)
Entities are now linked to their Device so for example the Image and Select Entities are linked to the Binary Sensor Device.
@davesmeghead hi, i have a question. I reinstall integration and now i have a little config problem in a automation.
Before, my panel name is alarm_control_panel.visonic_alarm. Now it’s alarm_control_panel.visonic_alarm_2.
My automation doesn’t work :
alias: Notification - Alarme Sonne
description: Notification sur Oneplus8t Alarm Sonne Home Assistant & Telegram
trigger:
- platform: event
event_type: visonic_alarm_panel_state_update
event_data:
condition: 3
condition: []
action:
- data:
message: "☠️ ☠️ L'alarme de la maison sonne !! "
title: "Alarme Maison :"
data:
image: /local/Photos/IMG_20210415_175246.jpg
action: notify.mobile_app_iphone
what did i put in event type ? Is it always visonic_alarm_panel_state_update ?
Thanks
after a fresh installation from the intergration and updating it to version 0.9.8.3, Powerlink is working again with my Powermax+. And it is reconnecting to Powerlink after each restart from H.A.
I’ve created a HACS release 0.9.9.3 that includes all changes and updates to the integration. It’s on the master branch on Github and is the default release so you should be able to install it using HACS.
The dev and dev_B0 branches are on hold.
Any general issues please report them here.
Any specific issues please report them as issues on Github.
In either case please include a debug Home Assistant log file.
So condition 3 meant siren triggered, one of the reasons to change is that it’s easy to get this wrong. You need to look at the main state of the Alarm Entity being set to Triggered.
Using the latest HA 2024.10
triggers:
- trigger: state
entity_id: alarm_control_panel.visonic_alarm
to: triggered
I hope that everyone can see that this is much better than condition: 3 in an Event.
EDIT: Please see the next post by me as I’ve added a Siren Entity
EDIT 2: Try this using the latest HA 2024.10
Hi,
I’ve spent a couple of hours this morning adding a Siren Entity to the integration. I have created Github release 0.9.9.4 but not made it a HACS release so you will need to download the zip and manually install it.
EDIT: I didn’t make it a HACS release as it’s had very little testing, if you’re willing to test it and let me know it’s OK or not then I’ll make it a HACS release when I’m sure it’s robust enough
So what does it do:
It makes a slight change to the operation of Panic, Emergency and Flood. These no longer trigger the Alarm Control Panel Entity.
Only “Intruders” trigger the Alarm Control Panel Entity.
The Siren is triggered by all possible sources i.e. whatever is set in the configuration.
The Siren Entity is also a Switch and so it can be set from other HA automations etc.
The Mute service call seems to mute the actual siren but it doesn’t notify the integration so the Siren Entity is still “on”
I have copied the “Alarm” language translations from the Alarm Control Panel Entity to the Siren Entity
The alarm attribute of the Alarm Control Panel Entity and Siren Entity are the same, except when the Siren Entity is used in HA as a Switch which overrides the setting
The Siren Entity includes an attribute called trigger. When the alarm type is Intruder this attribute tells you the zone entity that triggered the siren.
So this automation works with this release, using the Siren Entity
alias: Alarm Siren Triggered Action
triggers:
- trigger: state
entity_id:
- siren.visonic_s01
to: "on"
from: "off"
actions:
- data:
title: >-
{% set fn = trigger.to_state.attributes.friendly_name|string %}
{{ fn }} Panel Siren is Sounding
message: >-
{% set fn = trigger.to_state.attributes.friendly_name|string %}
The {{ fn }} Panel Siren is Sounding
{% set etys = trigger.to_state.attributes.trigger|string %}
{% set alrm = trigger.to_state.attributes.alarm|string %}
{% if etys == "" %}
Alarm siren due to {{ alrm }}
{% else %}
{% set ety = 'binary_sensor.{}'.format(etys) | string %}
The Sensor that triggered the Siren is the {{ state_attr(ety, 'friendly_name') }}
{% endif %}
action: notify.persistent_notification
initial_state: true
EDIT: The trigger attribute is only set when the alarm attribute is intruder but you don’t need to check it, checking the length of the trigger attribute is the short cut way of doing it i.e. check trigger attribute length, if not “” then assume intruder alarm and it’s the sensor that triggered the siren
I’m sure that you’ll let me have any feedback, what do you think?
EDIT (again): After reading it through I thought I’d add this. When panic, emergency, fire are triggered in the actual alarm panel, it doesn’t change it’s state. If the panel is disarmed and panic it triggered, the panel remains disarmed but the siren is sounding. So that is why I created a new Siren Entity. The Alarm Control Panel Entity now only represents “intruder”, the Siren Entity represents all possible sources (including “intruder”).
I’ve been working on Partitions for a couple of months and finally got the time to do a bit of testing.
This only works with PowerMaster Series Panels
I have uploaded the code to the dev release on github here, you’ll need to manually download the zip file and delete/replace the existing visonic directory.
Hi @davesmeghead I noticed this log entry today while trying to arm/disarm, then the panel gets unavailable. Been working fine for years.
Latest version of the custom component 0.9.9.7 and also the latest version of HA 2024.10.4.
Power Master 30 in power link mode.
2024-10-29 22:38:14.075 ERROR (MainThread) [custom_components.visonic.pyvisonic] [_sequencer] Visonic Executor loop has caused an exception
2024-10-29 22:38:14.075 ERROR (MainThread) [custom_components.visonic.pyvisonic] ‘str’ object cannot be interpreted as an integer
@davesmeghead I see you also released version 0.9.9.9, and a quick test of it with Arm Home and then Disarm seems to be ok. No error in log and the panel status did not go into unavailable/unknown state
