Thanks for your quick reply.
Both boxed are ticked
Please find the log below:
https://pastebin.com/VXsef3uV
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 , 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.
Hello @davesmeghead. Sorry for the late reply, I received no email, so I didn’t noticed you have replied. I just reviewed my settings
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
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.
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.
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
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
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:
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.
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:
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
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:
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.
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
These are the main and potentially big failure cases:
During initialisation:
After Initialisation and the integration sets up OK (and Standard, Standard+ or Powerlink is achieved):
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
So for the 4 differences, what I think we could do about it is:
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.