Visonic Powermax and Powermaster Integration

Thanks for your quick reply.

Both boxed are ticked

Please find the log below:
https://pastebin.com/VXsef3uV

Hi Dave,

I already found the issue.

As you can see in my previous post, the box “Arm without User Code” was ticked. Seems logical to me at least :smile: , as I don’t want to use a code. But when I untick that box, I can arm/disarm.

Sorry for using your time, a bit more trial and error from my side would have been enough…

Thanks

I’m pleased you fixed your problem and it’s working.

However … I realised that it’s not supposed to do that when “Arm without User Code” is selected. I’ve updated the Integration and I’m testing it at the moment. I’ve also updating the wiki offline as I looked at it and it confused me, never mind anyone else. I understood the wiki text when I wrote it but not now. So I’m updating Note 2, especially the table in this section on the wiki.

So in a way, it made me look at it again and fix a bug.

1 Like

Hello @davesmeghead. Sorry for the late reply, I received no email, so I didn’t noticed you have replied. I just reviewed my settings :slight_smile:

I saw in the wiki the mention to trigger the siren, but I was not fully sure if this was acting just to activate the siren devices, or if it triggers a full intrusion event with all the configured actions in the panel (emails, sms, voice call, and siren). That for me makes a big difference, because when I’m out of home I prefer the reliability of a voice call rather of receiving a HA notification or a Telegram bot. Will it trigger a full intrusion event?

BTW now that you have a PM30 have you tried to use the dual RS232 port? Months ago I tried to identify the pins with a multimeter and tried and error many options without luck.

Thanks a lot

It needs a wired connection to your panel using one of the available wired sensor inputs (and you need the 2 resistors as defined in the visonic manual). The panel thinks it has a wired sensor and so you can configure your panel to do with it what you want. If you have the sensor in HA through this Integration from that zone, then it can be used in HA to trigger whatever you can.

For example

  1. Create the Wemos as defined on the wiki here
  2. Wire 1 of the relays to a panel sensor input e.g. Zone 30. You could wire both relays if you have the available wired inputs on your panel and use them in different ways
  3. Configure your panel to use Zone 30 as a 24hour or perimeter or whatever you like. This can be full intrusion event etc etc, just like using any other sensor that is connected to your panel
  4. When in use, you can switch the relay “on” from HA and that will trigger the Zone 30 sensor in the panel. The panel will do what you configured it to (24hour triggers the siren immediatelly) and this in turn will cause the HA Integration to show Zone 30 triggered and whatever your panel is doing. You can then send emails from HA as you could normally.

It’s on my “to do” list of things to try, one of the reasons that I was waiting for a cheap PM30. Lets just say that it isn’t much to look at but it works and was fairly cheap.

:slight_smile:

Hello,

I am using the Visonic integration to arm and disarm my Powermax+ alarm panel. I have created m5stack RFID panels to arm/disarm the alarm at different places in my home. It works with MQTT set and status topics.

It all works fine to arm the system, except when there is a zone open (panel ready: no) then the alarm panel does not arm.

I am looking for a HA automation that does the following:

If MQTT set topic received is arm_away AND panel ready = yes then call service to arm the panel
ELSE (so if panel ready = no) then do nothing and send a MQTT state topic to the m5stack remote panels to indicatie that alarm is not armed.

How can i incorporatie this all in one automaten. I have managed to do it in 2 different automations already.

So basic question is, how can I make an if-the-else automation based on panel_ready attribute.

Never mind,

I already found out that since version 2022.5 if-then-else is integrated in the Action phase of automations. Works like a charm

Trigger: MQTT command topic received is arm_away
Action: 
if   panel_ready =yes
then switch on alarm
     switch off lights
     switch off heating
else send MQTT state topic disarmed

@davesmeghead
Thank you again!!!

I bought a PM 10, but later a PM 30… (also another Powermax pro for spares… There are really good prices sometimes in second hand sites).

Today I received the PM30 and added without problem together with the Powermax. Both in Powerlink mode.

Captura de Pantalla 2022-08-17 a las 11.31.48

I had to go to work but tonight I will finish to add all the new sensors :))))) I am so happy with the two panels :slight_smile:

Thanka a lot @davesmeghead I have it working!

By now it is just a quick fix using one sonoff mini relay I had laying around. In my PM30 there is just a Zone 25 but everything was pretty easy following the installer’s guide.

But in the long term I’m thinking in a pretty different approach. Instead of a wemos I’d like to use a ESP32 with ESPHome for both the relay and RS323 port UART Bus — ESPHome

To do this you’ll need to edit the visonic.yaml file that configures the device to use with ESPHome. You’ll need to change the platform and board at the top to match your device and you may need to change the pin numbers for the tx_pin and rx_pin values. In the switch section you may need to change the pin numbers that connect the relays.
Let me know if you’re successful and we can add it as another hardware option on the wiki.

EDIT: One thing to be careful about is the power consumption. If you power the device inside the panel using the 3.75 volts from the panels PC/IP/RS232 connector then you probably won’t be able to draw enough to power a relay. @pocket if he’s still around may be able to help more but I suspect this is the case. That’s why I favour the Wemos as I can power it from the 12v DC supply inside the panel.

I was thinking on powering it using a buck step down power supply like this one, and instead of a relay board use a mosfet, so it would hopefully fit inside the panel’s case in a neat way. I would post pictures if I get it to work

I didn’t noticed this detail about wemos, but I have a box full of ESP32 so I would give a try to this setup. Have you managed to get the whole equipment inside the panel’s box?

The reason for keep asking about the dual RS232 port is because I lost the ability of using the RJ45 ethernet board I had in the panel attached to the network port :cry:

I’m still around.

I’d look at using one of these optocouplers to trigger the alarm. The isolation will mitigate any ground fault. It has a bit of resistance when on (~ 30 Ω), but the LED current for turn-on is reasonable (~ 7.5 mA). You’ll need a series resistor to establish the current for the LED (for 3.3V drive, it’d need a low wattage 270 Ω resistor).

https://toshiba.semicon-storage.com/info/docget.jsp?did=140401&prodName=TLP223GA

If you consider using an ESP32, (and as @hirofairlane mentioned) there are small buck converters that’ll output 3.3 volts from 12 volts. Here’s another example:

https://www.adafruit.com/product/4683

As there is already a requirement of 2.2k resistor, it’s just a matter of recalculate the resistor required and replace the 2.2k by the right one depending on the used mosfet.

1 Like

It’s probably not necessary to do anything special. After all, 30 Ω is 1.4% of 2.2 kΩ, and the circuit can withstand an additional 220 Ω of wire resistance (10%).

Hi,

I have a problem with the integration that I have had for a a couple of weeks, but I have not really had the time to really investigate until now.
My Panel Mode goes into “Problem” mode after a while. Usually after 1-3 minutes after it has entered Powerlink mode, but sometimes after a longer time. When in Problem mode can I still arm and disarm, but with code. I also have no problem to read for example Alarm or Door state. After a while, usually within a couple hours, does the integration stop totally with error “Connection Problem - No data from the panel” in HA.

I have a PowerMaster 10 panel, I am running HASS.io in a VM, and I have installed the Visonic integration via HACS and i upgraded to intergration version 0.8.1.0 in one of the the last 3 days with the same problem remaining.
I am using a USR-TCP232-E2 (LAN) but i have also tested with a ESP6288 (wi-fi) running esp-link with same behavior.

Snippet from my log:

2022-08-20 10:49:12.489 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [sendPdu] Sending Command (Ack) raw data 0d 02 fd 0a waiting for message response
2022-08-20 10:49:12.529 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [handle_msgtypeA5] Parsing A5 packet 10 04 00 03 04 06 00 14 00 00 43
2022-08-20 10:49:12.529 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [handle_msgtypeA5] log: Disarmed(Disarmed), arm: Disarmed
2022-08-20 10:49:12.532 WARNING (MainThread) [custom_components.visonic.client] Warning: Valid 4 digit PIN not found
2022-08-20 10:49:12.640 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [sendPdu] Sending Command (Ack) raw data 0d 02 fd 0a waiting for message response
2022-08-20 10:49:12.680 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [handle_msgtypeA5] Parsing A5 packet 10 05 00 00 00 00 01 13 12 89 43
2022-08-20 10:49:12.790 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [sendPdu] Sending Command (Ack) raw data 0d 02 fd 0a waiting for message response
2022-08-20 10:49:12.831 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [handle_msgtypeA5] Parsing A5 packet 10 06 1f 00 00 00 00 00 00 00 43
2022-08-20 10:49:12.831 DEBUG (MainThread) [custom_components.visonic.pyvisonic] =============================================== Display Status ===============================================
2022-08-20 10:49:12.831 DEBUG (MainThread) [custom_components.visonic.pyvisonic] key 0
<<<<----The log showing my sensors----->>>>
2022-08-20 10:49:12.831 DEBUG (MainThread) [custom_components.visonic.pyvisonic] Model PowerMaster 10 PowerMaster Yes LastEvent None Ready Yes
2022-08-20 10:49:12.831 DEBUG (MainThread) [custom_components.visonic.pyvisonic] Mode Problem Status Disarmed Armed No Trouble None AlarmStatus None

Thanks,
/Jonas

There are 5 reasons that the Mode is set to PROBLEM:

  • When performing a disconnect i.e. the communication has been disconnected such as TCP error
  • When trying to get to Powerlink and there is a Response Timer timeout
  • No data has been received from the panel at all (in the first 30 seconds after starting)
  • No data has been received from the panel in the last 4 minutes (data has been received but not in the last 4 minutes)
  • There is a Response Timer timeout

Since you say that you get to Powerlink Mode first and that you still seem to be able to interact with the panel then it is likely to be the last bullet causing the PROBLEM Mode. I would need a full log file for this and I do state in the first post,if you have problems then the first thing I ask for is a full log file and not just snippets, this doesn’t normally help me.

Anyway, I’m guessing that it’s the last bullet, if it is then you should see this in your log file:

[Controller] ****************************** Response Timer Expired ********************************

If you are seeing this then it means that the Integration has sent a command to the panel but has not received a response within 10 seconds. This usually means that the connection to your panel is not reliable in some way. Data is being lost somewhere.

Like I said, without a full log file then this is pure guesswork on my part.

One last thing, when it goes to PROBLEM then you will see things like “Valid 4 digit PIN not found” as the Integration limits what can be done with the panel. So I would expect to see that. In this specific case it is forcing the use of the keypad in the interface.

Hi,
Thank you for you reply!
Here is my full log via Pastebin: https://pastebin.com/7PMNQyn6
However, the short version of it is; Yes, I see this in the log:

“[Controller] ****************************** Response Timer Expired ********************************”

After I posted yesterday it took 4 hours between it went to Powerlink mode into Problem mode. This morning, when I tried to reproduce the issue, did it not go into Problem Mode after 20 minutes, so I restarted and it show up after approx 3½ minutes. (That is the log on Pastebin.)

I know that Ping does not tell everything, but there does not seems to be any obvious network problem between HA and USR-TCP232-E2: (This is the same time as the Problem Mode starts.)
166 packets transmitted, 166 packets received, 0% packet loss
round-trip min/avg/max = 0.380/0.746/7.844 ms

Could it be the panel itself that is cauing the issues?
Is there any way to make the integration auto-reset the connection?

/Jonas

I’ve looked at your log file and, here it works as designed

2022-08-21 09:41:04.634 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [sendPdu] Sending Command (Getting Status)    raw data 0d a2 00 00 00 00 00 00 00 00 00 00 43 1a 0a    waiting for message response ['0XA5', '0X2']
2022-08-21 09:41:04.692 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [data receiver] msgType 0X2 got it so removed from list, list is now ['0XA5']
2022-08-21 09:41:04.692 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [handle_msgtype02] Ack Received  data = 43 
2022-08-21 09:41:04.692 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [data receiver] msgType 0XA5 got it so removed from list, list is now []

To explain, as there hasn’t been any interaction with the panel for 25 seconds I ask the panel for its status i.e. the first line above “Getting Status”. I then wait for an acknowledge “0x02” message and then the actual panel status in an “0xA5” message. Notice the “waiting for message response [‘0XA5’, ‘0X2’]”, this indicates that my code is waiting for these 2 messages from the panel.
The 2nd line above I receive the 0x02 from the panel and then the 4th line above I receive the 0xA5 message. I then go on to process the 0xA5 panel status to update the sensor states in Home Assistant.
So this works as designed :slight_smile:

The following is the same situation but it doesn’t work, the panel does not respond:

2022-08-21 09:42:30.725 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [sendPdu] Sending Command (Getting Status)    raw data 0d a2 00 00 00 00 00 00 00 00 00 00 43 1a 0a    waiting for message response ['0XA5', '0X2']
2022-08-21 09:42:40.734 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [Controller] ****************************** Response Timer Expired ********************************
2022-08-21 09:42:40.734 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [_clearList] Setting queue empty
2022-08-21 09:42:40.735 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [sendPdu] Resetting expected response counter, it got to 0   Response list length before 0  after 2
2022-08-21 09:42:40.736 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [sendPdu] 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']

You’ll notice that the 2nd line is 10 seconds after the “Getting Status” request 1st line. So the panel has not responded to the “Getting Status” command.

In the current code I set the Panel Mode to PROBLEM and send a “Restore PowerMax/Master Connection” message to the panel to kick it to respond. As an aside, this can only be done if we were in POWERLINK Mode before this occurred.
This is the sequence in yout log file for this “kick”

2022-08-21 09:42:40.736 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [sendPdu] 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']
2022-08-21 09:42:41.258 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [handle_msgtypeAB]  data 03 00 1e 00 31 2e 33 33 00 00 43 
2022-08-21 09:42:41.258 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [handle_msgtypeAB] ***************************** Got PowerLink Keep-Alive ****************************

I wait for an “0xA5” message which I get but I first get an “0xAB” message (in line 2 above), this is the panel saying that it still thinks it’s in Powerlink Mode.

Sorry for the long and drawn out explanation but I wanted to illustrate that this is a very specific situation that I took a decision on for the design of the software i.e. ANY Problem with the connection then report PROBLEM Mode and do not change it back, the only way to change it is to restart the connection. The alternative to this would be to “recover” and change it back from PROBLEM if the connection recovered. I tried this in the early days (and I admit that the code had many bugs in those early days) but it just gets too complicated, I was never 100% certain that it had properly recovered and then it just happened over and over again repeatedly.
The only 100% certain way to recover is to restart the connection.

So what can you do about it?
For your setup, the connection between your HA device and your panel is unreliable in some way. This could be anywhere in the chain between the device you run HA on, all the way through to (and including) the panel. So yes it could be the panel or it could be anything else in the chain of software and hardware. As an example that I’ve seen in the past, although this was using USB, it could be a driver issue on the device where you run HA that periodically steals data and consumes it before my integration gets it.

So you have 2 choices:

  • Try and find the issue and resolve it
  • Accept that you have an unreliable setup and create an automation in HA to restart the integration when it sees the Panel Mode go to PROBLEM.

So I took the decision for the bold text above, and the 2nd bullet, that when a restart of the Integration is required it should be up to the user to do it with an HA Automation. You can then decide when and how rather than it being fixed in the Integration.

Does this help?

EDIT: I remembered that another person had wifi problems and the connection kept dropping. This is the post in this thread where I suggested the automation so that will give you a starting point.

3 Likes

Thank you vert much for your detailed description! I will think about what to do!
/Jonas

I’ve been thinking about this a lot during today while I’ve been doing other things, such as painting the garden fence :slight_smile:

These are the main and potentially big failure cases:

During initialisation:

  • The Integration does not make an initial connection to the panel, the TCP or USB connection fails e.g. wrong IP address, wrong port, incorrect wiring etc. This also includes the TCP connection to the Ethernet Gadget e.g. a Wemos
    • This results in a HA Notification and a Warning message in the log file “Failed to connect into Visonic Alarm. Check Settings.”
    • No HA entities are created
  • The Integration makes an initial connection to the panel, data is sent but no data is received in 30 seconds
    • This results in a HA Event (On the wiki here, X=10, “state”=“NeverConnected”)
    • An Error in sent to the HA log file.
    • An Alarm Control Panel HA Entity is created
    • Panel Mode is set to PROBLEM.
    • The integration has now stopped interacting with the panel

After Initialisation and the integration sets up OK (and Standard, Standard+ or Powerlink is achieved):

  • If the connection to the panel is disconnected for any physical reason e.g. TCP Error caused by a router reboot
    • To be clear, this use case is from an Exception condition that is raised in the Python code from the underlying Operating System
    • All current operations are stopped
    • An Error is sent to the log file, if there was a program exception that is also logged
    • An HA Event is generated (condition=0)
    • The Exception Counter is incremented
    • I assume here that it is recoverable, the integration attempts to reconnect after a small delay.
    • Panel Mode is set to PROBLEM but as the Entity is very quickly deleted I doubt HA sees this
  • The panel periodically reports its status to the integration, if it does not send a message for 4 minutes
    • This results in a HA Event (On the wiki here, X=10, “state”=“DisConnected”)
    • An Error in sent to the HA log file.
    • Panel Mode is set to PROBLEM.
    • The integration has now stopped interacting with the panel
  • A command has been sent to the panel and there has not been a response for 10 seconds
    • If this is during Powerlink Enrol
      • Panel Mode is set to PROBLEM.
    • During normal operation
      • Panel Mode is set to PROBLEM.
      • Clear out the current command and send a new command asking the panel for its Status
  • Corrupt Data, corrupted messages have been received from the panel or excessive messages that have failed their CRC checks
    • Various detailed warnings and debug to the HA log file
    • If excessive (5 failures in 10 minutes) then
      • All current operations are stopped
      • An Error is sent to the log file, if there was a program exception that is also logged
      • An HA Event is generated (condition=0)
      • The Exception Counter is incremented
      • I assume here that it is recoverable, the integration attempts to reconnect after a small delay.
      • Panel Mode is set to PROBLEM but as the Entity is very quickly deleted I doubt HA sees this

From the above 6 use cases there are 4 differences.
The last 3 all result in the same Panel Mode “PROBLEM” and I think this is a problem - pun intended :slight_smile:
So for the 4 differences, what I think we could do about it is:

  • No initial connection and can’t do anything about it → Notification to HA User
  • The interaction has stopped and the integration is waiting (i.e. not doing anything about it)
    • In this case we could consider creating a new Panel Mode called STOPPED
  • The interaction has stopped and the integration is attempting to fix it (by restarting)
    • Panel Mode is set to PROBLEM but as the Entity is very quickly deleted I doubt HA sees this (and remember that an HA Event is generated so the User can use it instead)
    • Suggest to use STOPPED as above
  • This leaves the situation where a command is sent to the panel without response for 10 seconds
    • In this case we keep PROBLEM as the Panel Mode but also could consider changing PROBLEM back to represent its Panel Mode if the problem resolves itself or to a different Panel Mode depending on what happens with the panel
    • If this were done then we could also have a HA Attribute “Problem Count” akin to the “Exception Count” HA Attribute so the User knows how often this is happening over time

This would be a breaking change for those that use Automations and the PROBLEM Panel Mode.

What does anyone think? I know this is complicated but I hope that you followed my logic.
:smiley:

1 Like