If i recall right, they upgraded the firmware back when i ordered the panel, i think it was due to support for the app or something like that - but that was in 2016.
But on the bright side - we now know there is a “new” combination
I’m not sure if it’s relevant, but the panel is a EU version, i don’t know if that could explain some of it. But as far as i know the only difference on the versions are the frequencies used for communicating with the sensors.
So let’s say it’s a bug, in that case, it could make sense for me to pay for the upgrade of the firmware. Atleast that way we will learn if it is a bug, of if they have changed the way they communicate, either way, i guess it’s good to know for the future? Or what do you think?
I have an test instance i can configure it on, so there i can pretty much do everything you ask I will configure it now and return with the logs as soon as possible.
and again, thank you for your time on this issue, it is really appreciated.
Shouldn’t make any difference as far I can tell, as you say the frequencies are different. My integration mimics the visonic powerlink2 / powerlink3 operation and I don’t think they make a difference with them for the different parts of the world.
That’s up to you I guess, but even if you didn’t upgrade then there’ll be other users that use this integration with that firmware version.
Thankyou
Just for completeness, as I’m a glutton for detail
Taking the PDU at 2021-02-21 01:05:11 as an example. A 3F (hex) PDU from the panel is used to download the EPROM data.
0d 3f 00 00 80 (127 bytes of EPROM data) f2 0a 0d
That 0x3F PDU is normally a variable length message as follows:
0x0D - the PDU header
0x3F - the message type
0x00 - the Index reference
0x00 - the Page reference
0x80 - the data length, this is important as I ask for a length of 0x80 so this is correct
0x80 is 128 in decimal
The Data - this should be 128 bytes of data
This is where it goes wrong as the panel only sends 127 bytes of data
0xF2 - this is a valid checksum but for the 127 byte PDU
Because I expect 128 bytes I use this as the last byte of data instead of the checksum.
The 0x0A should be the PDU terminator but it is taken as the checksum
The 0x0D is actually the PDU header of the next message so it throws the link with the panel out of sync.
This is what should happen, where XX is a valid checksum
0d 3f 00 00 80 (128 bytes of EPROM data) XX 0a
The problem is that this is different each time, sometimes the panel sends 127 bytes of data, I looked at another of the 0x3F messages and it was 124 bytes of data. If it tolf me that it was only sending 127 bytes then I could cope in the software but it lies.
I could make a special case in the software for your panel type, if I do would you be willing to give it a try. Are you able to replace the files in the /config/custom_components/visonic directory or have you installed it using HACS?
Point taken For me, the best solution would be if we could make this version work, but if not, then it could make sense with an upgrade. And if that doesen’t work either, then atleast we will know.
I will have to educate it in honesty
but first of all, sorry about the delay, but had some things to attend to
but, just to sum up:
I have revertet back to an empty HA on my test enviroment, and installed basics (SSH, samba, file editor) in it, then i installed the components for visonic manually (to ensure that we could update manually like you wrote the below quote).
it is configured to allow for it to arm/disarm and with force standard activated.
I tried to read your explanation and i think i get that you wrote above, however, when i tried to see if i could read the log file, i have to admit that i failed I could not see the same errors as in the other installation, so hopefully you have more luck.
I have updated and uploaded a code change to Github.
Some of the data within the services and events have changed and I haven’t yet updated the wiki. For the coders amongst you, I have created an Abstract Interface to the low level python code that interacts with the panel. As part of this I have created enumerations instead of passing strings everywhere. I have also tidied up the events and services processing and made some tweaks, especially to the Arm/Disarm Home Assistant service.
For most users, please don’t use this release unless you’re keen on testing alpha/beta releases as I haven’t finished fully testing it on my own system.
Now on to the PowerMaster 33 Model 71.
Please consider this a test release only for a PowerMaster 33 to try and get it working.
martinta89 - could you please give this release a try on your panel. It contains some test code that should check the 0x3F PDU and try to process it if it is shorter than it should be.
Just upgarded through HACS from 0.5.0.0.0 to 0.6.4.4.4 and having a few issues;
I have tried and copied your siren trigger automations but I’m not getting any notifications, I use to get a notification to my mobile that I configured by changing the action
Also when an alarm siren is triggered I am getting the notification on the frontend but it no longer tells me where this has been triggered, it use to state what has been triggered somewhere?
basically without looking constantly at the frontend I can’t see if anything has been triggered…is there a way to alert me on my homescreen?
I’m not sure what you mean. Did you use the automation before updating to 0.6.4.4?
Have you “ticked” the appropriate settings in the new configuration? Try going to the integrations page and for visonic select “options”. There’s a drop down box with reasons why the siren would be sounding for your system, have you set this correctly?
For that version of the integration nothing in the event data has changed that I can think of.
It might be useful if you could post the automation that you’re having trouble with.
You would need to add a new automation that created an audible notification (or you might have sound turned off on your phone, sometimes the simple solution is the right one )
Please post the automation and I can look at it, is it exactly the same as that on the integration wiki?
Force Standard seems to work from your log file.
For this test please untick it to try and download the EPROM and get to “Standard Plus” and then hopefully “Powerlink” Mode.
EDIT: Forgot to say, you’ll have to delete the integration from HA and then re-create it.
So i wasen’t the only one who could not find the errors in the last log?
This is weird though, before i wrote here, i have reinstalled this integration many times, trying different configuration methods, including forcing standard.
The logs can be found here.
For now it still shows standard mode in the developer tools though.
I’ve just updated the code (again) and uploaded to Github. Basically I forgot to remove the check to decode the panel settings for a Power Master 33.
The only concern I have is that the panel isn’t fully downloading the EPROM data and if the panel settings tries to use some of the data that isn’t downloaded it won’t work.
Can you please upload a log file again, even if it seems to work as I’d like to check it.
For the first automation it looks the same as the wiki and so should be OK.
Just so you know you can paste it in to a code block using the weird single quote ` it’s top left on my UK keyboard.
3 of these at the start and 3 at the end, and it appears like this
Text that keeps its formatting
and it keeps the formatting and indentation.
So for the first automation, what notification do you get? Is it
Alarm siren from unknown sensor
or
The Sensor that triggered the Siren is the XYZ
Where XYZ should be the sensors friendly name
For the second automation, that one looks OK as well. Are you certain that the actions are correct? There’s no way I can test your notifications.
Could you post again with the automations surrouned by 3 at the start and 3 at the end. Put them in the post first and then paste the automation text in the middle of them.
EDIT: oops, it did the formatting thing while I was showing you the formatting characters. You can just click the </> icon at the top of the post you’re creating and it inserts them for you.
I’ve uploaded another test to Github, please give it a try.
I was checking the length of the received data and if it wasn’t correct I would discard the data. Like I said please give this version a try. Once again, delete the integration from HA and re-create it.
Also, you should have Force Autoenroll set to True in the config. Only Powermax+ panels should set this to False as they have to manually enroll with the panel.
alias: Alarm Siren Triggered Action
trigger:
- platform: event
event_type: alarm_panel_state_update
event_data:
condition: 3
context:
user_id:
- b7d7993b2bb1439dbfb65ae2abaaf462
action:
- service_template: persistent_notification.create
data_template:
title: Alarm Siren
message: '{% set ety = trigger.event.data[''Entity'']|string %} {% if ety ==
''None'' %} Alarm siren from unknown sensor {% else %} The Sensor that triggered
the Siren is the {{ state_attr(ety, ''friendly_name'') }} {% endif %}'
initial_state: true
mode: single
I get nothing returned as if its not running. I turned the automation off and the same thing I just get the persistant notification that I have the option to dismiss but it doesn’t tell me what has triggeredb it.
I can’t remenber exactly how it worked before I upgraded, I know I got a notification that the alarm is sounding but either when I dismmed it or something somewhere else it told me what had triggered it?
On your setup how do you know if you’ve an alarm sounding on your device homescreen?
I’m afraid that I do try and use some of the data from the EPROM that doesn’t get downloaded. I’ve done another update to Github to determine whether it’s settings that we can do without. I set some attributes for the Alarm Panel Entity in HA and we could probably do without them for a PowerMaster 33.
I have not updated the logic, I’ve just put log statements to try and work out which data it is missing.
Same again please, delete it from HA and re-create it. And then upload the log file.
So you don’t have to trigger your siren and annoy the neighbours, you can change the condition from 3 to 2. This will trigger the automation on any sensor change so you can see if the notification works. The message will not be correct and will likely say: Alarm siren from unknown sensor
But at least you can test the notification.
My phone buzzes whenever I get a notification through HA but I’m on Android so not much help to you. Are you sure it’s not a phone setting?
I’m not sure what the context and user_id settings do either.
Where does the message “Alarm siren from unknown sensor” appear?
I’ve also noticed some things refer to “alarm_panel_status_update” or “alarm_panel_state_update” which one should be used in the automation?
The only thing that is appearing when anything is triggered causing a siren is the notification “Siren is Sounding. Alarm has been activated” which I have to dismiss but this never appears on my homescreen only in the app
I will configure it now and return with the logs as soon as possible.