Visonic Powermax and Powermaster Component

[davesmeghead (Dave)]

Are we not allowed to upload files anymore? Have they changed the policy?

[pocket (Rob)]

Is private messaging gone too?

[davesmeghead (Dave)]

@pocket

Ugh

Try changing the extension to png, jpeg or gif and see if it looks for the image resolution

[davesmeghead (Dave)]

@pocket

Is private messaging gone too

PM is still there but just with graphics image file upload the same as the forums.
How do HA expect us to do things without being able to upload the log files that HA produces?

[pocket (Rob)]

Very good question, Dave. I think we’ll have to use a drop-box service like Pbathuk suggested,

[pocket (Rob)]

@davesmeghead

The only way I think that I can help is if you capture and upload a log file for me to look through, remember to set the “logger” settings as per my description on the Github page please.

Let’s try this:

https://pastebin.com/8VJDQ8vM

[james_hiscott]

2.1 fixed this, thanks

[davesmeghead (Dave)]

@pocket

Perhaps I’m not understanding what exclude means in the context. I’m taking it to mean exclude the numbered devices from being registered. I have no x10 devices, so I want the entire class excluded.

I’ll try some scenarios, but the component doesn’t seem to be happy with (at least) exclude_sensor being in the configuration file.

OK, so I got your log file from pastebin and I’ve had a look through. Did you paste it twice by mistake, I haven’t compared them but the timestamps look like the same thing twice.

Anyway, it looks like you do understand exclude_x10 and exclude_sensor, they just aren’t working for you!

I’ve already fixed the X10 issue in release 0.2.1, you should only need to exclude the X10 devices you have registered in the panel. If you don’t have any registered devices then you shouldn’t need the “exclude_x10” in the configuration.yaml file at all.

And now on to the sensors and “exclude_sensor”. I have uploaded version 0.2.2 to Github and put some extra debug statements in for the log file. Would you mind giving it a try and uploading the log file again please. I think there are 2 problems, both specific to PowerMaster panels as the PowerMaster EPROM downloaded data is different to a PowerMax (what I have) so I can’t test it:

1. Sensor Enrollment. I have made a slight alteration to try to determine which zones are enrolled in the panel so it might fix it, then again it might not
2. The Sensor type. Looking at your log file, you only have 2 zones enrolled: Front Door and Living Room. Can you tell me their actual types i.e. are they Wired sensors, PIRs, Wireless Magnetic sensors etc. I can then look for these when you upload your log file to compare what they are in real life with what the panel tells me they are.

Thanks
DSM

[pocket (Rob)]

@davesmeghead

I have seen that A7 message before but never on my own panel, always on someone elses. I have to admit that I have no idea how to decode that A7 message, that’s why I use a Warning statement for the log file. I would be interested in seeing the log file please to see if I can work out what it means and what’s happening.

I found some information on this forum: https://www.domoticaforum.eu/viewtopic.php?t=6517

Here’s a quote:

A7 Message (15 Byte): 0D A5 XX XX XX XX XX XX XX XX XX XX XX 0A
General panel status indication
TYPE, byte 6:
0x0X - alarm
0x06 tamper alarm on (sensor)
0x07 tamper alarm on (panel)
0x1X - alarm off
0x13 low battery alarm of
0x16 tamper alarm off (sensor)
0x17 tamper alarm off (panel)
0x21 - low battery alarm
0x51 - armed home
0x52 - armed away
0x55 - disarmed
0x60 - admin login on panel
0x61 - admin logout on panel

[davesmeghead (Dave)]

@pocket

A7 Message (15 Byte): 0D A5

Ah yes, I have seen that and it’s a typo in the post, it should be
“A5 Message (15 Byte…”

@pocket

0D A5 XX XX XX XX XX XX XX XX XX XX XX 0A

Edit: I’ve had another look and it’s partly correct, it’s just very mixed up between A5 and A7 message structures, well it is from 2011 and they were just investigating and experimenting with the protocol.

An A7 status message has between 1 and 4 “events” (this is byte 2, it’s a counter)
Each event is made of the event zone and the log information
The event zone is the zone number (0 means general panel status)
The log information is partially described in the rest of the text.

So in
0D A7 AA ZZ BB CC DD EE XX XX XX XX XX 0A
AA would be the message count
I do not know what ZZ is
If AA were 02 then BB CC would be the first and DD EE would be the second
BB and DD would be the event zone
CC and EE would be the log information

A more practical example
0D A7 01 ZZ 00 60 XX XX XX XX XX XX XX XX 0A
There is 1 message, 00 means the main panel and 0x60 is a panel reset

Edit 2:
With your A7 message
0d a7 ff fc 00 60 00 ff 00 0c 00 00 43 45 0a

The message count would be 0xFF and I don’t know what this means

[pocket (Rob)]

@davesmeghead

OK, so I got your log file from pastebin and I’ve had a look through. Did you paste it twice by mistake, I haven’t compared them but the timestamps look like the same thing twice.

I don’t think so. When I grab the using with the dowload button, nothing appears duplicated.

Anyway, it looks like you do understand exclude_x10 and exclude_sensor, they just aren’t working for you!

I’ve already fixed the X10 issue in release 0.2.1, you should only need to exclude the X10 devices you have registered in the panel. If you don’t have any registered devices then you shouldn’t need the “exclude_x10” in the configuration.yaml file at all.

I’ve already integrated version 0.2.2, so I can confirm “exclude_x10” is working as intended.

And now on to the sensors and “exclude_sensor”. I have uploaded version 0.2.2 to Github and put some extra debug statements in for the log file. Would you mind giving it a try and uploading the log file again please.

Excellent. I’ll try to do that over the next couple of days.

2. The Sensor type. Looking at your log file, you only have 2 zones enrolled: Front Door and Living Room. Can you tell me their actual types i.e. are they Wired sensors, PIRs, Wireless Magnetic sensors etc. I can then look for these when you upload your log file to compare what they are in real life with what the panel tells me they are.

That’s correct. Zone 1 is a door sensor (open/closed) and Zone 4 is a PIR motion detector. I do have an additional alarm integrated, but it’s just a peripheral, not a sensor. All external devices are wireless.

FYI: I’m still slowly ordering sensors. I only have a starter kit integrated, and I’ve not yet put the system into service. That said, it seems stable enough to do so. I’ve only seen a couple of minor glitches when playing with it, but nothing has triggered the alarm that wasn’t supposed to.

Thanks again for being so accommodating.

[pocket (Rob)]

@davesmeghead

With your A7 message
0d a7 ff fc 00 60 00 ff 00 0c 00 00 43 45 0a

The message count would be 0xFF and I don’t know what this means

I went looking for a source relating the A7 message, and that’s the only thing I’ve found, so far.

Oh well, the search continues.

[davesmeghead (Dave)]

@pocket

0d a7 ff fc 00 60 00 ff 00 0c 00 00 43 45 0a

I did wonder if a message count of 0xFF means that all 4 message events are valid
The variable that I don’t know what it means would be 0xFC

If we were to assume that all 4 messages are valid then

00 60 is a panel reset
00 FF doesn’t really decode in to anything I understand
00 0C is a panel “Panic From Control Panel”
00 00 is a “None” event

Would any of these have happened in your panel to generate this kind of response?

The 43 is the message end (for a powerlink message), the 45 is the checksum and the 0A is the message terminator.

[pocket (Rob)]

@davesmeghead

I did wonder if a message count of 0xFF means that all 4 message events are valid
The variable that I don’t know what it means would be 0xFC

The only thing I can think of is a loss of communication, which is what the panel displays when I command an HA system reboot. I suppose I can try to isolate this occurrence by pulling one of the communication pins during normal operation.

[pocket (Rob)]

Here’s the latest. The panel is running V0.2.2 and I have purposely interrupted communication around 23:41. Communication is gracefully restored after I plug the USB pin back in the panel.

Here’s an extract from the system log:

https://pastebin.com/vnD9m5t0

Unfortunately, the loss of communication error is not latched. So, I’m not sure we can isolate any error this way. Perhaps if I perform a system reboot it will latch. I’ll try that tomorrow.

[davesmeghead (Dave)]

@pocket

Here’s an extract from the system log

Hi and thanks for the updated log file. I can see that after 2 minutes of you disconnecting the pin there’s a watchdog timout in the log file and it tries to restore communication. It does this twice and the second time is successful. I can push through watchdog timeouts as an HA event if that would help. Either instead of or as well as, I can also count watchdog timeouts and make that available to the panel as an attribute of the alarm entity, do you think that it’s worth it? Also, performing a panel system reboot will not make it latch.

Also, can you upload a log file from first starting HA, I’d like to see the EPROM list of enrolled zones and their types please from your powermaster to see if I can correlate your sensors with the EPROM data.

Thanks again for your help with a Powermaster, it’s not something I can do here locally.

[olijouve (olivyeah)]

Hi,

I tried 0.2.1 and still “get stucked” in standard mode with some access denied in my logs.
I tried several time your reset process with no more chance.

If you could find time to have a look on it : https://pastebin.com/uXtUDPG4
Not a big deal if you don’t as the standard mode is already great value for me !

I use an ESP32 connected to the serial port of the powermaster and communicating through a wifi to serial arduino like sketch, so don’t know if this issue would be related to.

Otherwise have you seen this awesome custom component ? It allows direct install and update of custom component from the UI.
https://custom-components.github.io/hacs/

Not working with yours yet maybe simply because of file directory hierachy, here is the error:
davesmeghead/visonic - custom_components does not exist in the repository.

Once again thanks a lot for your great works on this component !!

[pocket (Rob)]

@davesmeghead

Hi and thanks for the updated log file. I can see that after 2 minutes of you disconnecting the pin there’s a watchdog timout in the log file and it tries to restore communication. It does this twice and the second time is successful. I can push through watchdog timeouts as an HA event if that would help. Either instead of or as well as, I can also count watchdog timeouts and make that available to the panel as an attribute of the alarm entity, do you think that it’s worth it? Also, performing a panel system reboot will not make it latch.

I think it’s worthwhile to capture the timeout and see if it’s correlated with the contents of the A7 message. Additionally, capturing the count might be useful to someone who is trying to gain confidence in their interface hardware.

Also, can you upload a log file from first starting HA, I’d like to see the EPROM list of enrolled zones and their types please from your powermaster to see if I can correlate your sensors with the EPROM data.

Thanks again for your help with a Powermaster, it’s not something I can do here locally.

Here’s the beginning of the log. It was too big to post it in its entirety.

https://pastebin.com/HFgHt90t

You don’t have to thank me. It’s in my selfish interest to help you.

[davesmeghead (Dave)]

@olijouve

I tried 0.2.1 and still “get stucked” in standard mode with some access denied in my logs.

I’ve taken a look through your log file and it really doesn’t like the default download pin 5650, there are lots and lots of access denied messages back from the panel. I don’t think it’s to do with the hardware you use to connect, the simple fact that you can connect then it should make no difference. Can you try setting this in your configuration.yaml for the component

    download_code: 'AAAA'

Let’s try AAAA instead of 5650, it doesn’t really matter what it is, just different to 5650
Can you then upload your log file again please, thanks.

@olijouve

Otherwise have you seen this awesome custom component ? It allows direct install and update of custom component from the UI

I’ve just had a quick look and will investigate further when I get time, thanks for the reference

[davesmeghead (Dave)]

@pocket

I think it’s worthwhile to capture the timeout and see if it’s correlated with the contents of the A7 message. Additionally, capturing the count might be useful to someone who is trying to gain confidence in their interface hardware.

OK, I’ll start adding it for a release.

Also, thanks for the log file, it confused me rather than helped me. I don’t think that I’m getting any EPROM data for the sensor types area. I’ve uploaded 0.2.3 to Github, can you give it a try and upload the log file again please. I’ve tried to make sure that I grab the correct EPROM area and added a log entry to tell me if I haven’t.