Visonic Powermax and Powermaster Component

olijouve · August 23, 2019, 2:40pm

Hi Dave,

I’ve looked at your alarm_arm_custom_bypass service but i can’t get it “working” and looking your code I see it is kind of work in progress.
Anyway when i call the service with a visonic binary_sensor id, can see that HA seems to execute the service but no logs are produced by your function. i’m in debug level for all logs and if i add a logger entry before the self.queue condition i still can’t get it in the logs.

Do i miss something for HA to call your registred alarm_arm_custom_bypass service ?

Here are the logs of the service call.

 DEBUG (MainThread) [homeassistant.components.websocket_api.http.connection.1807958928] Received {'type': 'call_service', 'domain': 'alarm_control_panel', 'service': 'alarm_arm_custom_bypass', 'service_data': {'entity_id': 'binary_sensor.visonic_z02'}, 'id': 45}
 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event call_service[L]: domain=alarm_control_panel, service=alarm_arm_custom_bypass, service_data=entity_id=binary_sensor.visonic_z02>

It would be nice to me having sensors bypass/isolation because i live in a 3 floors house and open windows in last floor are not that critical so i wish i could arm my non ready panel anyway.

I know this can be tricky to integrate in the UI.
I tried something like for testing purpose:

      - type: entity-button
        entity: binary_sensor.visonic_z02
        tap_action:
          action: call-service
          service: alarm_control_panel.alarm_arm_custom_bypass
          service_data:
            entity_id: binary_sensor.visonic_z02

Maybe coupled with conditional card or something else, it could do the job…
Off course it would be far better with a custom card that could list all triggered sensors and allowing them to be bypassed but this is an other story.

Olivier

davesmeghead · August 24, 2019, 1:12pm

I have just uploaded version 0.3.1 to Github. I have added a service call to bypass/arm individual sensors. There are no other changes.

I have updated the readme on Github here, it documents the 4 services that are provided and working.

Olivier, please give it a try. I have been using the developer tools section in the Frontend for testing purposes like this HAServiceCallExample

simonporter007 · August 24, 2019, 10:38pm

Connected it this weekend, looks connected and receiving info through test.py via WiFi. Thanks for the pinout!

Do you know if the motion sensors trigger without the alarm being armed? I thought I saw the triggered=1 when walking around the house with the laptop, but now I can’t get it to repeat that. It looks to be in powerlink mode, which I gather is what I want.

Think the door sensor still triggers when disarmed, would be nice if the motion did too. Maybe I’m misreading the output from test.py though.

davesmeghead · August 24, 2019, 11:00pm

Yes they do but there’s a panel setting to prevent them retriggering for a period of time. I also have a period setting so it doesn’t retrigger called “motion_off”, this defaults to 120 seconds.

simonporter007 · August 24, 2019, 11:09pm

Hey Dave, thanks for replying! Even on the PM10? I went ahead and hooked it up to Hass and I can see the door sensor change no problem, both motion sensors are dead ducks when not armed it seems. Reading up a bit in the thread, it sounds like this might be expected.

davesmeghead · August 25, 2019, 9:31am

Ah yes, others have said that. It looks like the PowerMaster 10 and 30 only support motion sensors when the panels are armed. I have a PowerMax Pro which supports motion sensors all the time.

davesmeghead · August 25, 2019, 2:07pm

I mentioned several posts ago that I’ve started to create the wiki page on github here. At that time I copied most of the readme.md file in to it and then left it alone. Well, I’ve just updated it with the services information from 0.3.1.

A few of you have asked in the past about a central place for info and there’s a lot more information that other people have provided over the past 14 months or so, especially:

How to use it in Hass.io
How to wire up and physically connect the various panel types
Specifics about automation and examples
Screen shots of what it looks like
What are the differences in using the various Panels e.g. PowerMaster motion sensors

So I don’t have all the knowledge about this Component and it’s use, you do . Yes I mean you. So I’m asking if anyone is interested in contributing to the wiki, after all it is a wiki and that’s why wikis were set up originally, so the people with the knowledge could share it.

I would then cut out most of the description from the readme.md file, probably only leaving a brief description, the version information, what does and doesn’t work, and a link to the wiki page.

One last thing, I’m not sure how github works for wikis, do I need to share it somehow?

davesmeghead · August 25, 2019, 8:49pm

I have just uploaded version 0.3.2 to Github. I’ve changed the way the service works to incorporate the services.yaml. Take a look here for the changes in the service calls. The service call I now create is called “visonic.alarm_sensor_bypass” to individually bypass/rearm sensors.

Also, and more importantly “I HAVE CHANGED THE DIRECTORY STRUCTURE”

I have added a custom_components folder to make a start to get it working in HACS. For those interested it follows the directory structure defined here.

Example of the new service in development tools

olijouve · August 26, 2019, 9:21am

Awesome, thanks a lot !

Installed nicely with HACS but the service has no effect yet, I think it comes to my panel which is probably set to “no bypass” by default

According to documention, bypass needs to be enabled in :
INSTALLER MODE -> 4. DEFINE PANEL -> 08: BYPASS-> manual bypass
or in French :
MODE INSTAL -> 4. DEFINIT CENTRE -> 08: ISOLATION -> isolation manu

I’ll test it further after my day work.

Haven’t checked but can we see sensor bypass status in sensor attributes ?

olijouve · August 26, 2019, 6:56pm

It’s working nicely after enableling manual bypass in panel menu !

Also, bypass status seems to be the device_armed attribute.

I have made a push request for the monster card component to beeing able to call dynamicaly a service based on the clicked entity.
It’ll allow me to have 2 lists, one for opened state sensor we can click on to bypass them and an other one to list bypassed sensor we can click on to rearm them.
Still not perfect but it’s not a gaz factory.

I finish my config and i’ll share it here.

Many thanks !!

davesmeghead · August 26, 2019, 10:33pm

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.

olijouve · August 26, 2019, 11:15pm

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.

olijouve · August 26, 2019, 11:34pm

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.

pocket · August 27, 2019, 3:11am

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?

ualex73 · August 27, 2019, 6:16am

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

davesmeghead · August 27, 2019, 7:40am

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

ualex73 · August 27, 2019, 8:58am

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.

pocket · August 27, 2019, 11:01pm

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

Pbathuk · August 28, 2019, 9:00am

Hi,

I managed to load the latest github version this morning & followed the guidance for the Powermaster 30 request:

https://pastebin.com/f3zJMTMV

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

davesmeghead · August 30, 2019, 6:37pm

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.