Yes it is, it’s the opposite of bypass because it is an “armed” attribute. When bypass is on (True) then device_armed is False (and vice versa).
Could you help me out and give me (everyone?) some instructions on how to do this please.
Config done !
See attachments for the render:
The first one is a normal case with no sensor active.
On the second one we can see that an adaptive card is dynamically inserted to allow sensors bypass when there are active. A simple click on them call Dave’s new bypass service.
On the third one, there is a new adaptive card showing a list of bypassed sensors so we can rearm them by a simple click.
Theses 2 cards disappear if there is nothing in their lists.
Not perfect through cause there can be a lag of several seconds(standard mode only ?) between a bypass event/click and the moment it disappears of the Bypass list to appears in the Rearm list, and vice versa. Anyway it will do the tricks for me for the moment as i can’t afford to spend too much time on it, my baby almost takes it all…
As you may see, i tweeked my cards styles to have a (nice?) shrinked size footprint so it fit nice on desktop and iphone SE screens. Up to you to rearrange it the way you prefer if you want to use my config or parts i share below. For the bypass add on cards only, just keep the 2 "- type: ‘custom:monster-card’ " sections.
Requirements:
Mandatory, untill official monster-card plugin developper validate my push request you can get my specially enhanced monster-card for beieng able to pass the click element entity_id to Dave’s bypass service.
Just put monster-card folder in your config/www directory, create it if if does not exist.
Optional if you want to tweak styles:
resources:
- type: js
url: /local/custom-lovelace/card-mod.js
- type: js
url: /local/monster-card/monster-card.js
title: Home
views:
- badges: []
title: Home
panel: false
path: default_view
cards:
- cards:
- type: glance
entities:
- alarm_control_panel.visonic_alarm
- binary_sensor.visonic_z10
- binary_sensor.visonic_z01
- binary_sensor.visonic_z11
- binary_sensor.visonic_z12
- binary_sensor.visonic_z02
- binary_sensor.visonic_z14
- binary_sensor.visonic_z13
- binary_sensor.visonic_z08
- binary_sensor.visonic_z09
- binary_sensor.visonic_z05
- binary_sensor.visonic_z04
- binary_sensor.visonic_z03
- binary_sensor.visonic_z06
style: |
ha-card {
font-size: 12px;
padding: 0px 0px 0px 0px !important;
margin: 0px 0px 0px 0px !important;
}
.entity {
margin: 0px 0 8px 0 !important;
padding:0px;
font-size: 12px;
}
.name {
white-space: pre-line !important;
height: 4em !important;
}
state-badge {
margin:0 0 0 0 !important;
}
.entities.no-header {
padding:0 0 0 0 !important;
}
hui-glance-card {
margin:0px 0px 0px 0px !important;
border: none !important;
}
- type: 'custom:monster-card'
show_empty: false
card:
type: glance
title: Bypass
columns: 5
show_state: false
style: |
ha-card {
font-size: 12px;
padding: 0px 0px 0px 0px !important;
margin: 0px 0px 0px 0px !important;
}
.entity {
margin: 0px 0 8px 0 !important;
padding:0px;
font-size: 12px;
}
.name {
white-space: pre-line !important;
height: 4em !important;
}
state-badge {
margin:0 0 0 0 !important;
padding:0 0 0 0 !important;
}
.card-header{
font-size: var(--ha-card-header-font-size, 16px);
padding: 8px 8px 0px; !important;
margin: 0px 0px 0px 0px !important;
}
.entities.no-header {
padding:0 0 0 0 !important;
}
hui-glance-card {
margin:0px 0px 0px 0px !important;
border: none !important;
}
filter:
include:
- entity_id: binary_sensor.visonic*
state: 'on'
options:
icon: mdi:shield-off
tap_action:
action: call-service
service: visonic.alarm_sensor_bypass
service_data:
bypass: 'True'
entity_id: this.entity_id
exclude:
- entity_id: binary_sensor.visonic*
attributes:
device_armed: 'False'
- type: 'custom:monster-card'
show_empty: false
card:
type: glance
title: Rearm
columns: 5
show_state: false
style: |
ha-card {
font-size: 12px;
padding: 0px 0px 0px 0px !important;
margin: 0px 0px 0px 0px !important;
}
.entity {
margin: 0px 0 8px 0 !important;
padding:0px;
font-size: 12px;
}
.name {
white-space: pre-line !important;
height: 4em !important;
}
state-badge {
margin:0 0 0 0 !important;
}
.card-header{
font-size: var(--ha-card-header-font-size, 16px);
padding: 8px 8px 0px; !important;
margin: 0px 0px 0px 0px !important;
}
.entities.no-header {
padding:0 0 0 0 !important;
}
hui-glance-card {
margin:0px 0px 0px 0px !important;
border: none !important;
}
filter:
include:
- entity_id: binary_sensor.visonic*
attributes:
device_armed: 'False'
options:
icon: mdi:shield-check
tap_action:
action: call-service
service: visonic.alarm_sensor_bypass
service_data:
bypass: 'False'
entity_id: this.entity_id
- type: alarm-panel
entity: alarm_control_panel.visonic_alarm
states:
- arm_away
- arm_home
type: vertical-stack
style: |
ha-card {
font-size: 12px;
padding: 0px 0px 0px 0px !important;
margin: 0px 0px 0px 0px !important;
}
hui-glance-card {
margin:0px 0px 0px 0px !important;
border: none !important;
}
It’s doesn’t equal Dave’s valueable hard work on this module but it’s the least i can do to render back to visonic community.
I followed this install and configuration guides :
https://hacs.netlify.com/installation/manual/
https://hacs.netlify.com/installation/configuration
You need a github account and you have to generate a personnal access token.
When done, put this 2 lines in you configuration.yaml :
hacs:
token: YOUR_GITHUB_GENERATED_ACCESS_TOKEN
Restart HA, it takes a long long time to initialize after restart because it download all custom_component search query it can find on github.
on the left side bar your have a new Community menu. Go to SETTINGS in the HACS header then add GitHub - davesmeghead/visonic: Visonic Custom Component for integration with Home Assistant in the ADD CUSTOM REPOSITORY text input and choose integration in the select input, then click on the save icon.
I saw on this forum that we can add list card to show which module are installed by hacs and if there are up to date with an update button but i haven’t put it in my config.
To say true, i just reactivate HACS since you make your integration compatible with it.
Here are a few thoughts based on looking at the available documentation. Unfortunately, I have no hands-on experience with the USR modules.
I would suggest seeing if the VCC is in the expected range or if it is being loaded down below 3 volts. rhys, do you have a multimeter? Do you have any instruments (logic probe or oscilloscope) to see if there is any activity on the Tx and Rx pins ?
Is there any possibility you miswired anything before getting to the current configuration? Is there any possibility the board contacted any conductor that could’ve damaged the circuitry?
This isn’t completely true, you can read out the PIRs with PM10/30, but they don’t arrive in the same way as with the door sensors. You need to check for a specific B0 message and send 2 other B0 messages and check the result … Then you are 98% sure which sensor is triggered 
I put this code in the DomotiGa Visonic Plugin (gambas), so i know it works 
Ah yes, I know this already but have not implemented it fully as I don’t have a PowerMaster 10 or 30. As you also say, I’m not sure either if this method is 100% certain either. I have logging statements in the existing code but they do not change any settings or push the values in to HA.
So, just to say that if anyone with a PM10 or PM30 is willing to help (to show PIR state when the panel is not armed) then do the following and perhaps between us we can make sure it is a reliable indication:
- Set the logging levels as here to make sure the debug statements appear in the log file
- Restart your Home Assistant and wait a few minutes.
- Walk around your home to trigger the various PIRs (make sure they are triggered)
- Upload your home-assistant.log file to pastebin and place the link in this forum, telling me that it is to do with this experiment. Also, if you can tell me the order in which you triggered the PIRs that would be helpful.
That’s it for now 
Currently I don’t use your custom_component yet, but i will give it a try soon (with debug enabled). At this moment my PM30 still is connected to DomotiGa which forwards it via MQTT to HA.
I recently upgraded my Hass.io host from a RPi to a more-capable Odriod-H2. It’s running Ubuntu Linux. Here are two additional things I needed to do for the USB-to-serial cable connected to the alarm panel:
- Disable the default Modem Manager service using the command:
sudo systemctl disable ModemManager.service
- Once the serial cable is plugged in, identify the USB serial port using the console command:
dmesg | grep ttyUSB
Hi,
I managed to load the latest github version this morning & followed the guidance for the Powermaster 30 request:
Names:
Z01 - front door - door sensor
Z02 - hallyway - motion
Z03 - living room - motion
Z04 - utility door - door sensor
Z05 - playroom - motion
Z06 - Dining room / Kitchen - motion
Start of walk around:
Hallway
Front Door
Playroom
Hallway
Living room
Dining room / Kitchen
Utility Door
Dining room / kitchen
Living room
Hallway
Playroom
Hallway
End & turn off debugging
Hi Phil, thanks for the log file upload, I’d like to say that it helped but it just confused things more.
Let me try to explain.
I’ve decoded the B0 PowerMaster messages and I’ve realised by also looking at the
that I am decoding the message in the wrong way. I also looked at plugins for other gadgets and there are very few B0 messages decoded.
There are 2 differences to DomotiGa with my decoding of the B0 message data:
- I do not have the B0 message data timeouts as per the DomotiGa plugin. The DomotiGa plugin uses 2 timouts:
- The first that prevents sequential device triggers within 30 seconds. This means that walking aound a property may not trigger each motion sensor within HA (or DomotiGa). Since I have not implemented this timeout it isn’t an issue for me but they must have a good reason for doing this.
- The second is that 2 messages have to come from the panel within 5 seconds of each other. Looking at your logs this does actually happen (44:38, 44:40 and 46:42, 46:45). The DomotiGa plugin looks at the differences between the first and second zone states and assumes that each difference means that there has been a detection. The main problem with this is that it has no idea what the values actually mean, it just looks for a difference, it could mean anything.
- I have been decoding the zone data in the wrong place. I assumed in version 0.3.2 that the data started at offset 3 and it starts at offset 7.
Having taken item 2 above in to account in your logs, if I used the same code as DomotiGa then I would not get any motion sensor detections, let me explain using this sample from you logs:
Zone Position 1 2 3 4 5 6
07:44:38 03 04 45 ff 08 03 40 11 08 08 04 08 08
07:44:40 03 04 45 ff 08 03 40 15 08 08 04 08 08
I have tried to line things up so I can explain, I know it’s detail but I might as well go for it
03 04 is the message type and subtype
45 (or 69 decimal) is the length of the data part of the overall data structure
FF 08 03 I have no idea but it’s the same on all “03 04” and “03 07” messages
40 (or 64 decimal) is the number of zones. I have seen in the past this set to 1E (30 decimal) for PowerMaster10 so I assume that it’s correct.
The 6 values after the 40 represent your 6 Zones. If you look at your logs at the same message data then you’ll see lots of 00 that I’ve missed out as there’s no zone data.
As you can see from this pair of messages, Zone 1 has changed data from 11 to 15. Since Zone 1 is not a motion sensor the DomotiGa plugin would ignore this change.
It is a similar story for the pair of messages at 46:42 and 46:45. The only change in data is for Zone 4 (from 17 to 21) which is also not a motion sensor.
So, I’m confused. It’s possible that 03 04 messages are only sending through non motion sensor data but that isn’t what DomotiGa thinks. It’s also possible that I’ve translated the DomotiGa plugin code wrong, no ones infalible. If anyone else thinks different to the above then please please let me know.
Anyway, I have made some changes to the B0 message decode to see if we can get more data and I’ve uploaded Version 0.3.2.1 to Github. Could you and anyone else interested please do as I suggest previously (if you have a PowerMaster 10 or 30): update the plugin, set debug logging on this plugin, restart HA, walk around your house triggering magnet and motion sensors and then upload the log to pastebin please
Thankyou for your patience.
After the weekend I will check my code again and let you know what it expects. Long time ago I check the Visonic programmer software how it detects the movement, but that is also not an easy why of doing things. The Master10/30 are just not great usage for motion detection, the older models work much better.
Hey,
So I have grabbed the lastest github version, ran then same tests but started with:
set home mode one and then off, waited and then walked around the same route
then after walking around. I set the home mode again and walked down stairs to the hall (saw the light) disarmed the alarm & then walked around again (did not open doors though)
Please tell me, I can not achieve the display of the numeric keypad. Reinstalled several times. What can be done?
Hi Phil,
I’ve analysed your log file and the receipt of the B0 messages looks fairly random to me, the biggest problem I have is that I can see that data is changing but I have no way to correlate these changes to you walking around your house.
So I have uploaded 0.3.2.2 to github with code to try to determine motion from the sensors using the PowerMaster “B0 03 04” message. It waits a minimum of 30 seconds (default) between triggers and then needs 2 consecutive “B0 03 04” messages (within 5 seconds (default)) to use the data differences to assume motion detection. This is in the code for testing for now so you’ll need to add the following to your configuration.yaml file. I didn’t want everyone getting it yet in case it messed things up but everyone with a PowerMaster is welcome to try it and feedback here.
b0_enable_motion_processing: 'yes'
b0_min_time_between_triggers: 30
b0_max_time_for_trigger_event: 5
If you have time to experiment I’ve included the 2 timing values in the configuration.yaml file.
Note that once a detection is made and if you see a motion zone triggered in the Frontend then it will be a minimum of “b0_min_time_between_triggers” seconds before you see another.
If you get chance to try it then let me know how it goes.
You only get the numeric keypad if it remains in “Standard” Mode. If it gets to “Standard Plus” or “Powerlink” then it has downloaded your EEPROM and it knows the user code. It then does not display the numeric keypad.
So, my question back to you is “What is the Panel Mode”?
Excuse me. Perhaps I didn’t ask the question correctly. And I do not understand the answer. Perhaps translate.google is to blame :))
I did not ask a question about “Panel Mode”
I am asking how to finish the output of a numeric keypad? It’s comfortable. When I had Hassio, there was a digital panel. Now on Hassbian - and there is no such imagination.
My settings:
“device:
type: ethernet
host: !secret visonic_ip
port: !secret visonic_port
motion_off: 120
language: ‘EN’
force_standard: ‘no’
sync_time: ‘yes’
allow_remote_arm: ‘yes’
allow_remote_disarm: ‘yes’
override_code: !secret visonic_override_code
download_code: !secret visonic_download_code
arm_without_usercode: ‘yes’”
Apologies but my answer was too quick and too short and I didn’t explain very well. I’ll try to keep what I say simple so it hopefully works in google translate.
When you start Home Assistant, it starts all the components.
When my Visonic Component starts, it tries to connect to the panel and download the EPROM.
If it fails to download the EPROM, it stays in “Standard” Mode.
If it gets the EPROM data then is goes to “Standard Plus” Mode
If it gets the EPROM and the Powerlink data then it goes to “Powerlink” Mode
If it gets the EPROM data, then it has your “user code” from the panel.
If it gets the EPROM data, it does not display the numeric keypad.
In my opinion:
- When you had Hassio, it remained in “Standard” Mode and displayed the numeric keypad.
- In Hassbian, I think it is in “Standard Plus” or “Powerlink” and does not display the numeric keypad.
So the Panel Mode is very important, what is it?
If you want to force it to stay in “Standard” Mode and show the numeric keypad then:
force_standard: ‘yes’
and remove the following line
override_code: !secret visonic_override_code
I’m new to HA (I just recently installed it together with the Visonic component). Everything works great, but I’ve got one question. I have a Visonic KP-160 PG2 (touch-screen keypad with proximity/RFID tags) and we use it to arm and disarm the alarm. Every proximity tag is assigned an id and I wonder if it’s possible to use the Visonic component to show who armed or disarmed the alarm?
No, it does not work
“Attempt to send a command message to the panel that has been denied, wrong pin code used”
Log: https://pastebin.com/wgD8Y7zT
In the “alarm_control_panel.visonic_alarm” Entity I create an Attribute called “Panel Last Event”. This is a string that has the last action, a forward slash “/” and then the user or gadget that did it. Take a look at what it gets set to for the various ways you arm and disarm your system and let me know if that does what you want.
Edit: Just thought, this only works if you’re in “Powerlink” Mode as it uses the A7 messages