Visonic Powermax and Powermaster Component

Share your Projects! Custom Integrations
606

Do the issues only appear when the panel is armed and connected to the USR module?

The USR module operates on 3.3 volts and the serial interface logic levels for Tx and Rx are appropriate for 3.3. volt systems. What alarm panel are you using? Do you know the logic levels for the alarm panel serial interface? Where are you getting power for the USR module?

I know this information is arcane, but at least we might be able to eliminate the interface hardware as a potential contributor to your problem.

Another approach to isolating the problem may be to try using a USB serial interface having an appropriate logic level for your panel. Still, let’s first see what Dave might find in your log.

(Full disclosure: I’m a hardware designer. When all you have is a hammer, everything looks like a nail.)

607

Hi Rob,
It’s a Visonic Powermax and I connected it as per this https://www.domoticaforum.eu/viewtopic.php?f=68&t=7152
But, my original problem did re-occur once when I had removed the 3.75V jumper link. So I had dismissed this being caused by the USR module. However, the loss of connection at 4:06PM today was another, maybe related problem. I suspect there is something amiss somewhere.
Similar disclosure, I used to be a HW engineer. But it was a long while ago and, if truth be told, probably not the most gifted. :slight_smile:

608

When you disconnect just the power wire, the Tx driver at the alarm panel might attempt to power the USR module. There are typically protection diodes at the Rx interface that provide a current path from the input pin to the 3.3 volt internal bus of the receiving device. Related to to the concern, when in the idle state the Rx and Tx lines would typically be at a logic high voltage. The Tx device at the panel might be very unhappy trying to source so much current.

Have you measured the 3.75 volts at the panel or even at the USR module? If so, can you see any change when the panel is armed?

Regarding specs:

The USR manual for your module states the peak current is draw is 350 mA (164 mA, typ) when powered at 3.3 volts. That a bit more than the USR-TCP232-E2 (120 mA, typ). Hopefully, yours is within the excess capability of the panel’s power supply. In addition, the USR states the 3.3 input voltage should be within ± 5%. I realize there is often excess margin in the product, but yours could be an outlier. You could try to put a Schottky diode in series with the 3.75 to see if the system is more stable at a lower voltage. The 1N5817, 1N5818, or 1N5819 are cheap enough and have a forward voltage drop below 0.4 V.

Here’s a question: Can you access the configuration screen of the USR via a browser while the USR is passing data? What about when it’s not communicating with the panel?

609

Hello Rob,
Good point on the TX of the alarm could try to power the USR module. Next time I disconnect it I will remove that line too. However, it took 3 days to reproduce a false alarm before so I am not going to get a quick indication if this is the cause of the problem. But certainly worth trying.
I also like the idea of the Schottky diode. I had thought about a normal diode but that would have been too much of a volt drop so discounted it. So I have 2 on order and should get them later in the week.
With regards to accessing the USR whilst it was transmitting data… I believe I can and they seem to work concurrently. I tried looking at the web interface, made alarm status changes and added some pings in too for good measure and nothing seemed to go wrong. I didn’t think to access the web interface when the server lost connection. Although it seemed to come back online when I had disarmed the alarm. So I only knew about the lost connection when I viewed the history.
Anyway, I appreciate you helping me, thank you and I’ll give the diode a go later in the week when it arrives.
Cheers
Mark

I’ll try and get a scope at the weekend to measure the signal voltage levels

610

Hi Mark,
I’ve taken a look through your log file and it’s mostly OK. It achieves powerlink OK etc etc.
I haven’t found anything that would indicate why you are having the problems, but I did find something else. The only issue that I’ve found is as follows:

From your log file
… Connects, downloads EEPROM and start Disarmed, everything looks OK to here …

20:17:38 A5 Message: Panel Status Arm Away - Exit Delay
20:18:08 A5 Message: Panel Status Armed Away
20:18:10 A7 Message: Panel Status Detail showing Armed Away with Fob 02

… perioidic A5 message updates as Armed Away …

20:22:51 A5 Message: Panel Status Armed Away
20:23:16 A7 Message: Panel Status Detail showing Disarmed with Fob 02
20:24:48 I haven’t had an A5 for a while so I ask the Panel for it’s Status
20:24:50 A5 Message: Panel Status Disarmed

What I expect to happen
I expect to receive A5 messages to determine panel status, the A7 message gives detailed information but only when in Powerlink mode so I tend to ignore these. When the Panel changes it’s status (Arming/Disarming and Zone Changes when sensors are triggered) the Panel sends me an A5 message without me requesting it. If nothing has happened in the Panel after a defined time, usually 90 senonds after the last transaction, then I request the Panel Status and the Panel sends me a series of A5 messages.

What your panel is doing
At 20:23:16 the A7 message should be preceeded by an A5 message that doesn’t happen with your panel. At 20:24:48 I haven’t had an A5 status for a while so my Component asks for it, this is what prompts the panel to send me the Disarmed status at 20:24:50. I don’t know why it didn’t send an A5 just before 20:23:16 when it sent the A7 message. In all other systems this is what I have seen.

What you see because of this
In the frontend it will show “Armed” until 20:24:50 even through you actually disarmed it at 20:23:16. So for a whole 94 seconds it showed the wrong panel state.

Maybe this is specific to your panel i.e. a “PowerMax Complete Part”. Or maybe not :slight_smile:

Perhaps I need to look at using either the A5 or A7 message for the main panel state and not just the A5 as I can’t rely on the panel sending it promptly.

So, like I said at the start, your log file doesn’t indicate why you are having the problems you are having, sorry :frowning:

611

Hi Dave,
Thank you very much for taking the time to look into this and also for the detailed explanation. As you say, it doesn’t seem to be the cause of my problem but maybe a symptom that is linked in some way.
I’m going to try Rob’s diode suggestion later in the week and also leave the alarm unarmed at nights to see if there are any more spurious triggers.
If you do come up with a workaround for my 94 second delay problem I would gladly try it out.
Thanks again,
Mark

1 Like
612

This was of interest to me, as well. I see two features that would indicate it’s not logic level. The product uses a DB-9 connector and it supports RTS/CTS flow control. On their website Global Caché, the manufacturer, provides no electrical specifications for RS232 voltages. So, I called them.

The RS232 does indeed comply with the electrical signaling specs of the EIA standard. The signals levels are ±12 volts, not TTL. Moreover, the logic sense would be inverted. The alarm panel should not be responding unless you’re going into a similar RS232 interface on the panel. Either that, or there are features in the panel design somehow accommodating either signaling convention – which would be a revelation.

613

The values in the log file messages are correct, maybe the python asyncio library is correcting them. But how would anything (hardware or software) know to invert the logic levels?

614

I know some software can auto-negotiate baud rates, and some microprocessors (PIC series) have an invert bit for the internal USARTs Tx and Rx data.

One way of recognizing inverted data is to look at the state of the Rx line when expecting an idle state. If data on the Tx line doesn’t result in a response, or if the response looks mangled (it’ll be inverted and shifted 1 bit), the host processor might try to flip the polarity after a timeout.

And who knows? The ITach might even have a setting to flip the polarity, but that’s not a question I asked of the technical representative.

615

You might have a point here. It’s been a very long time since I installed the panel and I do not remember what I bought at the time. Looking at the iTach module I can see that I have an RJ45 to DB9 converter, so I imagine I have the RS-232 module installed in the panel, but I will know for sure when I open the panel.

616

Hi Rob and Dave,
Just a quick update on my issue… I have updated to add the Schottky diode and will leave that running.
However, I am getting more and more convinced that one of my PIR sensors is misbehaving as prior to the diode mod I got a “tamper restore” warning in the middle of the night. I’m pretty sure this PIR is the source of a previous false trigger.
I’ve ordered a replacement and will swap that out when it arrives.

visonic
visonic991×607 68.2 KB

Regards
Mark

617

Or, you have a bat in the house.

The PIR misbehavior is a good hypothesis. What do you show for the battery state attribute for the detector?

618

Hi Rob,
It’s 100% apparently. Which is slightly strange as I don’t recall changing it for many months.

visonic
visonic729×1062 64.1 KB

Cheers
Mark
PS there are only 2 of us in the house so I will have to assume my wife is that bat!

1 Like
619

If the Panel itself isn’t showing a battery low then my Component won’t either. Also the battery state seems to be either 0% or 100% in my experience.

I assume that your alarm wasn’t armed as this would have set the main alarm going.

I agree, could you swap the batteries between 2 PIRs or just put a new battery in the misbehaving one and give that a try maybe?

620

Wow! It transmits the “dead battery” bit.

621

Hi,

I’ve just uploaded version 0.3.3.3 to Github.

As per the readme, I’ve updated the Powerlink operation with:

  • Removed I’m Alive message
  • Sending periodic “Restore” instead of “Get Status”

These changes are in response to this so thankyou.

The experimental release from 0.3.3.1 kept in. Feedback on these would be appreciated.

Any issues then please let me know here as normal :slight_smile:

D

622

Hi Dave,
If you get a moment could you take a look at this log file please? I think I may have 2 issues: the dodgy PIR (which I am waiting for a replacement) and an issue where I lose connection after arming, which I mentioned previously.
The same thing happened again yesterday we left the house at 18:30 and armed using the key fob and HA has lost connection to the alarm. I can ping the alarm OK and the web interface also looks fine. So, this seems to be exactly the same as last Sunday (the only previous time we all left the house and armed the alarm)
https://pastebin.com/mEcdGw4S
Any advice, other than ‘you need to get out more often’ would be appreciated. :slight_smile:
Cheers
Mark

623

Hi Mark,

You’re right it did crash the Component and everytime I reset the Component it crashes again for the same reason. I have worked out why in the code but I don’t understand what the panel is telling me.

Let me try to explain

  1. At 18:30:23 - Zones 2 and 3 are triggered. Having a Perimeter zone triggered when arming away might be the cause of the problem (for my Component)
  2. At 18:30:27 - The A5 content is 00 04 02 41 (hex) and this is “Away Exit Delay” and “Arming”
  3. At 18:30:29 - The A5 content is 00 04 22 41 (hex) and this crashes my Component

The Component expects the 0x22 value to be less than or equal to 0x15, in fact it should still be 0x02

This means that the Panel is setting bit 5 i.e. 0x20 for some reason and I don’t know why. It’s also something that I’ve never seen before and no one else has reported :frowning:

I also note that zone tamper is set for zone 2 (at 18:30:23 ztamper=1), could this be what bit 5 means i.e. set bit 5 when there is a zone tamper on one of the zones and you try to arm the panel?

Anyway, I have updated the code to mask out bit 5 (and extend the arrays) and I’ll upload it to Github later today when I make sure it works with my Panel for a few more hours.

But I still don’t know what bit 5 means in the System Status data and is it related to when you are trying to Arm Away and:

  • when some of your zones are still triggered.
  • the zone tamper is set for one of the Zones

D

624

I have updated to the new version and it looks fine. Thank you a lot for your work and support.

625

Thanks Dave,
What you say makes sense as the 3 of us left the house at the same time and would have triggered Zone 2 (kitchen) and Zone 3 (landing) as we went out.
It does seem strange that the Zone 2 tamper is set and maybe this has something to do with it.
The postman has been today and the replacement PIR has not arrived so I will try your new version out, when you post it, and see how it goes.
Thanks once again,
Mark