Visonic Powermax and Powermaster Component

You can do/simulate it thanks to the sensor bypass feature. I do it manually in summer to be able to arm the alarm with second floor windows opened but you can also make automation for it.
Create an indoor group for all your indoor sensors then create automation that trigger at wanted time. Here is helpfull infos for configuring the bypass service call.

          service: visonic.alarm_sensor_bypass
          service_data:
            bypass: 'True'
            entity_id: YOUR_INDOOR_GROUP_ID

Create one more automation to remove bypass by setting it to ‘False’.

Notice that bypass status will be cleared after a panel disarm.

Hello Dave,
I’ve been having problems staying connected with the more recent releases but have been trying again recently with similar results. An older version is working quite well and I only get problems every week or 2.
If you get a chance could you take a look at the log below please and let me know if you can see anything wrong.
I can see an exception error 104 but nothing more than that.
Regards
Mark

2020-02-19 19:41:45 INFO (MainThread) [custom_components.visonic.pyvisonic]    Mode  Powerlink              Status      Disarmed               Armed     No                     Trouble None              AlarmStatus None        
2020-02-19 19:41:45 INFO (MainThread) [custom_components.visonic.pyvisonic] ==============================================================================================================
2020-02-19 19:41:45 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [pmSendPdu] Sending Command (Ack Long)    raw data 0d 02 43 ba 0a    waiting for message response []
2020-02-19 19:42:15 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [Sending ack] PowerlinkMode=True    Is PM Ack Reqd=True    This is an Ack for message=0XAB
2020-02-19 19:42:15 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [handle_msgtypeAB]  data 03 00 1e 00 32 30 35 37 00 00 43 
2020-02-19 19:42:15 INFO (MainThread) [custom_components.visonic.pyvisonic] [handle_msgtypeAB] ***************************** Got PowerLink Keep-Alive ****************************
2020-02-19 19:42:15 INFO (MainThread) [custom_components.visonic.pyvisonic] =============================================== Display Status ===============================================
2020-02-19 19:42:15 INFO (MainThread) [custom_components.visonic.pyvisonic]      key 0  Sensor id=1  dname=Z01  stype=Magnet   zname=Front door     ztypeName=Delay 1    ztamper=0  ztrip=0  bypass=0  lowbatt=0  status=0  tamper=0  enrolled=1  triggered=0 
2020-02-19 19:42:15 INFO (MainThread) [custom_components.visonic.pyvisonic]      key 1  Sensor id=2  dname=Z02  stype=Motion   zname=Kitchen        ztypeName=Perimeter  ztamper=0  ztrip=0  bypass=0  lowbatt=0  status=0  tamper=0  enrolled=1  triggered=0 
2020-02-19 19:42:15 INFO (MainThread) [custom_components.visonic.pyvisonic]      key 2  Sensor id=3  dname=Z03  stype=Motion   zname=Upstairs       ztypeName=Interior   ztamper=0  ztrip=0  bypass=0  lowbatt=0  status=0  tamper=0  enrolled=1  triggered=0 
2020-02-19 19:42:15 INFO (MainThread) [custom_components.visonic.pyvisonic]      key 3  Sensor id=4  dname=Z04  stype=Magnet   zname=Back door      ztypeName=Perimeter  ztamper=0  ztrip=0  bypass=0  lowbatt=0  status=0  tamper=0  enrolled=1  triggered=0 
2020-02-19 19:42:15 INFO (MainThread) [custom_components.visonic.pyvisonic]      key 4  Sensor id=5  dname=Z05  stype=Motion   zname=Garage         ztypeName=Delay 1    ztamper=0  ztrip=0  bypass=0  lowbatt=0  status=0  tamper=0  enrolled=1  triggered=0 
2020-02-19 19:42:15 INFO (MainThread) [custom_components.visonic.pyvisonic]    Model PowerMax Complete Part     PowerMaster No                     LastEvent Disarm / User 01       Ready   Yes          
2020-02-19 19:42:15 INFO (MainThread) [custom_components.visonic.pyvisonic]    Mode  Powerlink              Status      Disarmed               Armed     No                     Trouble None              AlarmStatus None        
2020-02-19 19:42:15 INFO (MainThread) [custom_components.visonic.pyvisonic] ==============================================================================================================
2020-02-19 19:42:15 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [pmSendPdu] Sending Command (Ack Long)    raw data 0d 02 43 ba 0a    waiting for message response []
2020-02-19 19:44:14 INFO (MainThread) [custom_components.visonic.pyvisonic] [Controller] ****************************** WatchDog Timer Expired ********************************
2020-02-19 19:44:14 INFO (MainThread) [custom_components.visonic.pyvisonic] [Controller]               **************** Trigger Restore Status ***************
2020-02-19 19:44:14 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [ClearList] Setting queue empty
2020-02-19 19:44:14 INFO (MainThread) [custom_components.visonic] Visonic update event 9
2020-02-19 19:44:14 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [pmSendPdu] Resetting expected response counter, it got to 0   Response list length before 0  after 2
2020-02-19 19:44:14 INFO (SyncWorker_9) [custom_components.visonic.alarm_control_panel] alarm control panel received update event
2020-02-19 19:44:14 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [pmSendPdu] Sending Command (Restore PowerMax/Master Connection)    raw data 0d ab 06 00 00 00 00 00 00 00 00 00 43 0b 0a    waiting for message response ['0XA5', '0X2']
2020-02-19 19:44:14 DEBUG (MainThread) [custom_components.visonic.alarm_control_panel] code format called *****************************
2020-02-19 19:44:14 DEBUG (MainThread) [custom_components.visonic.alarm_control_panel] code format none as powerlink or standard plus *****************************
2020-02-19 19:44:14 ERROR (MainThread) [custom_components.visonic.pyvisonic] ERROR Connection Lost : disconnected due to exception [Errno 104] Connection reset by peer
2020-02-19 19:44:19 ERROR (MainThread) [custom_components.visonic.pyvisonic]                         Calling Exception handler.
2020-02-19 19:44:19 ERROR (MainThread) [custom_components.visonic] PyVisonic has caused an exception [Errno 104] Connection reset by peer
2020-02-19 19:44:24 INFO (SyncWorker_13) [custom_components.visonic.alarm_control_panel] alarm control panel received update event
2020-02-19 19:44:24 DEBUG (MainThread) [custom_components.visonic.alarm_control_panel] code format called *****************************
2020-02-19 19:44:24 DEBUG (MainThread) [custom_components.visonic.alarm_control_panel] code format none as powerlink or standard plus *****************************
2020-02-19 21:29:44 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [RequestArm]  RequestArmMode Stay
2020-02-19 21:29:44 INFO (MainThread) [custom_components.visonic.pyvisonic] [SendCommand] Suspended all operations, not sending PDU

Sorry, I should have said this is version 0.3.5.5.

Hi Mark
From the info you show:
At 19:42:15 everything is normal i.e you are receiving powerlink messages from the panel
The panel then stops communicating and there’s no more powerlink alive messages.
After 2 minutes at 19:44:14 my watchdog timer kicks in and sends a restore status to the panel.
When this happens I send a “condition 9” on the HA event bus so you can detect it in HA.
However, by me trying to send something to the panel there is a communication failure and you lose the connection with the panel.
I try to reconnect to the panel. This sends a “condition 0” on the HA event bus.
But the reconnect doesn’t seem to work, I can’t tell as I would need to see the next minute or so from the log file but there doesn’t seem to be any received data from the panel.

This is the underlying python communication connection telling me that the comms connection to the panel has been disconnected / interrupted.

I would say that the problem lies with the connection to your panel. Somewhere between 19:42:15 and 19:44:14. Is it Wifi, Wired Ethernet or USB?

Hmmm, just noticed the time stamp on the bottom 2 lines, I’m not sure why it didn’t try to reconnect to the panel. It just seems to have stopped :frowning:
Let me think about that. However, you may still have a comms problem or a problem with the hardware that HA runs on, are the other things in HA working OK?

Thanks for the super speedy reply.

It’s Wifi and I can believe there is a communication problem as I had other problems previously that seem to be cured by moving other 2.4GHz things away from the alarm panel. I’ll take the antenna out of the enclosure and see if I can see a better connection.
Having said that, it’s pretty reliable with an older version of your code. Which doesn’t really make sense. At least to me.
All other functions of HA work OK

I’m not sure if this is relevant but, after thinking about what you said, I just carried out some pings on the Wifi module. 3 in 30, or so ,timed out and some were nearly 3 seconds for the reply and other as short as 10ms.
64 bytes from 192.168.0.201: icmp_seq=0 ttl=255 time=324.642 ms

64 bytes from 192.168.0.201: icmp_seq=1 ttl=255 time=2.236 ms

64 bytes from 192.168.0.201: icmp_seq=2 ttl=255 time=4.169 ms

64 bytes from 192.168.0.201: icmp_seq=3 ttl=255 time=4.189 ms

64 bytes from 192.168.0.201: icmp_seq=4 ttl=255 time=4.597 ms

64 bytes from 192.168.0.201: icmp_seq=5 ttl=255 time=4.023 ms

Request timeout for icmp_seq 6

64 bytes from 192.168.0.201: icmp_seq=7 ttl=255 time=2.126 ms

Request timeout for icmp_seq 8

Request timeout for icmp_seq 9

64 bytes from 192.168.0.201: icmp_seq=8 ttl=255 time=2633.543 ms

64 bytes from 192.168.0.201: icmp_seq=9 ttl=255 time=1629.719 ms

64 bytes from 192.168.0.201: icmp_seq=10 ttl=255 time=625.097 ms

64 bytes from 192.168.0.201: icmp_seq=11 ttl=255 time=221.967 ms

64 bytes from 192.168.0.201: icmp_seq=12 ttl=255 time=869.663 ms

64 bytes from 192.168.0.201: icmp_seq=13 ttl=255 time=63.415 ms

64 bytes from 192.168.0.201: icmp_seq=14 ttl=255 time=7.200 ms

When wifi module is inside the panel the wifi coverage is very very poor and you often got connection loss even with the router next to the panel.
I had used that configuration for about a year before to switch to the USR ethernet module as a found ESP32/wifi unreliable for a security system.
If you have no other choice than wifi, i would recommand you to:

  • Put your module outside your panel
  • Add an 2,4ghz antenna as built-in antenna ofen sucks(Some esp32 with embedded camera have a port for external antenna)
  • monitor wifi channel usage in your neighborhood and select the channel that have the less congestion( or try to see w/ them for an optimized channel repartition)
  • watch for wifi perturbators on 2,4ghz band(microwave oven, babycam )
  • unsure to not rely on your internet box for wifi as they remotely apply updates that reboot your router/box
  • unsure your module do not overheat(add small heat dissipator)
  • unsure to not rely on DHCP and use static IP on your module

Doing all but the first 2 points i had been able to optimize a lot my connectivity but with still few disconnections and packet loss it was not good enough to me.

Remember that wifi is not known to be reliable in long runs, so the worst choice for a critical application.

Thanks Olijouve,
These are good points and I will work through them and see if I can improve the situation.
It’s still strange that version 0.3.3.4 (with HA 102.3) works quite reliably and the newer versions give me problems.
I don’t think it’s a massive problem for me but it would be nice not to get left behind with future HA upgrades.
Thanks again
Mark

Thank you very for these very usefull informations.

Hello,

I tried today with the latest commit from your component and the latest update from Home Assistant and it still doesn’t work:
https://pastebin.com/9ufFH076

I waited until the end of the delay, but I still don’t receive an alarm notification by the component.

@davesmeghead: let me know if I can do anything to debug this.

Thanks a lot in advance

Thanks first of all for uploading a log file rather than just saying “it doesnt work” :slight_smile:

I looked at your log file and noticed that your panel sends a “Confirm Alarm” message where I then cancel the alarm. This isn’t what we want so I’ve uploaded 0.3.5.6 to Github, please give it a try.

I’ve also added functionality to detect if there is any data received from the panel at all in the first 30 seconds of the component starting up. If there is no data received within 30 seconds then you should get a message in HA and an event is created on the event bus that you can trigger other automations from.
EDIT: This is to help you identify if you have a communication problem between HA and your panel, this could be hardware, drivers or software. It simply indicates if no data has been received in the first 30 seconds after it starts. If it triggers, it stops all activity and gives up, setting the mode to “Problem”

I’ve compared the current with the 0.3.3.4 releases and I think that there are 2 possible reasons that this might be happening:

  1. I added this to the Ethernet connection
        log.info("Setting TCP socket Options")
        sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        sock.setsockopt( socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)
        sock.setsockopt( socket.SOL_SOCKET, socket.SO_KEEPALIVE, 1)
        sock.setblocking(1)      # Set blocking to on, this is the default but just make sure
  1. When in Powerlink, version 0.3.3.4 periodically sent a “Restore” command to the panel to let the panel know we’re OK. Several users had problems with this (for Powermax panels I think) and so I made it only do this for PowerMaster panels. I must admit that I have a Powermax Pro and I didn’t have a problem and it worked reliably for me either way so I made the change.

Item 1 could be a problem for you as it changed the ethernet configuration and item 2 because there isn’t as much data sent between HA and the alarm panel.

There have been lots of other changes like B0 messages and event logs but nothing that I think would have the effect that you’re seeing.

Just some thoughts at the moment, anyone else have any thoughts?
D

I think that I’ve just unticked the box on Github to allow anyone (with a Github login) to edit the wiki that is on the Visonic Github page :smile:

As a general shout out, if any of you have an interest in updating the wiki then please go for it. I put the basic readme that I have on there ages ago with a few images from my setup as examples but feel free to edit/change it. Or maybe just add your own page with your set up and create a link to it from the main page, or maybe from a side panel.

1 Like

Brilliant :slight_smile:

I’ve added my guide here, including a few small changes.

Thanks a lot, it seems to work now: Home Assistant is receiving the alarm event.
In case it helps, see the log here:
https://pastebin.com/6whT3Yaa

Hello Dave,
Thanks for looking at my problem. Both reasons look, to me, like they could be logical candidates for explaining the difference. If either of them is easy to change back to make a special build to test out, then I would be more than happy to give it a go.
I wish I could offer more technical feedback.
Regards
Mark

Hello,
I managed to build the above Frontend card with the “custom” sensors (Panel Status, Panel Mode, Panel Exception Count and Last Event) but what should I write to get the “Panel Ready” and “Siren” values ?
The icons are different, so I suppose they are not sensors ?

Thanks in advance

I have a binary_sensor.yaml file that I reference from configuration.yaml like this

binary_sensor: !include binary_sensor.yaml

The content of binary_sensor.yaml includes

- platform: template
  scan_interval: 5
  sensors:
      visonic_siren_active:
        value_template: >-
                    {{ state_attr('alarm_control_panel.visonic_alarm', 'Panel Siren Active') == "Yes"}}
        friendly_name: 'Siren' 
      visonic_panel_ready:
        value_template: >-
                    {{ state_attr('alarm_control_panel.visonic_alarm', 'Panel Ready') == "Yes" }}
        friendly_name: 'Panel Ready' 

This creates sensors called

binary_sensor.visonic_panel_ready
binary_sensor.visonic_siren_active

:smile:

Oh you just created sensors like with the other attributes then ?
I thought it was different because the icons on the left are different (checkbox and empty circle).
Perhaps they simply both represent binary sensors, which have a different icon.

Thanks