Visonic Powermax and Powermaster Component

pocket · December 31, 2019, 5:19pm

Hi Chris. It’s working. It took about 30 seconds to respond in HA.

pocket · December 31, 2019, 5:34pm

Here’s a snippet from a PowerMaster-10 G2 showing a couple of motion sensor events while in PowerLink mode. I hope it’s useful.

https://pastebin.com/rKe84gZ8

If there’s more you need, just say the word.

cjones813 · December 31, 2019, 5:39pm

Great! Thats a good start. Hopefully Dave can have a look and hopefully speed it up if possible. I am wondering if the b0 are even related to motion events?

pocket · December 31, 2019, 5:43pm

I’m wondering how long the battery will last. I think there’s an option to turn off the LED.

cjones813 · December 31, 2019, 5:57pm

Yes there should be an option to switch off led in device settings. From my experience you should still get at least 2 years of battery life even with disarm activity switched on. Basically should be roughly the same as a powermax system.

pocket · December 31, 2019, 5:58pm

Thanks. Found it.

Pbathuk · December 31, 2019, 6:33pm

@cjones813 thanks Chris, turned it on for one of my PIRs, need to turn the LED off as WAF will be low if that keeps coming on
However I now get near instant update in HA from that zone. I’ve not turned logging on etc, but it’s definitely working well enough that I know if someone is in the room, won’t be using it for lights etc.

pocket · December 31, 2019, 10:11pm

Mine seems to be behaving about the same. I might try to hook it to an automation and turn on a light just to see how it does.

davesmeghead · January 1, 2020, 9:39am

I have added these to my local version and will upload to Github sometime soon.

I’m trying to catch up with you all so here goes. From this (Chris) log file I can see the following…

By the way, you’re setting the override code and it is only used in Standard mode

We are already in Powerlink

At time min:sec

5:02 We send a command "Restore". This asks the panel to send it's status with a series of A5 messages "10 01", "10 02", "10 03" etc etc to "10 10"
5:03 As part of this we see the A5 message "10 04" which gives us the panel status and whether zones have been triggered. 
     Nothing has been triggered.
5:03 We dump the list of sensors and their states to the log. 
     Nothing has been triggered.
5:32 We get the powerlink keep-alive from the panel and dump the sensor states to the log again. 
     Nothing has been triggered.
5:51 We receive a "B0" message from the panel. It's a "03 24" and I don't know what this means.
5:51 We receive an A5 message (without it being requested). 
     This A5 message is to do with door/window open/closed status but nothing is triggered
5:52 We receive a "B0" message from the panel. It's a "03 39" which I think is the panel telling us that there has been activity.
     The data length inside the message is 8 but I have no idea what the 8 bytes "ff 08 ff 03 18 24 4b f2" are
5:53 When I receive a B0 "03 39" message from the panel I send a request to ask the panel to send me a B0 "03 04" message
     I am now expecting a B0 message back from the panel
6:02 I have a 10 second timeout whenever I expect a message back from the panel and this has expired 
     i.e. no B0 message back from the panel.
6:02 When the response timer expires I send a "Message Restore" to the panel, the panel then sends me the series of A5 messages "10 01", "10 02" etc.
6:03 As part of the series of A5 messages we get the "10 04".  
     This tells us that Z05 has been triggered (violated) for motion.
6:30 Z05 is still showing as triggered. 
     You set the MotionOffDelay value to 30 seconds so at 6:33 this will be set to 0 (not triggered)
     (Although we dont' explicitly see this in the log entries)
     So by 7:00 for Z05 triggered is set to 0

Nothing much happens then until 7:08 where we get a series of B0 messages.

7:08 03 24 1a ff 08 ff 15 06 00 00 00 00 00 00 00 08 07 01 1f 0c 13 14 03 01 00 83 00 00 f9 43
7:10 03 39 08 ff 08 ff 03 18 24 4b fb 43
     I get a "03 39" so I send a request to the panel to send me an "03 04", this time the panel responds straight away
7:10 03 04 45 ff 08 03 40 04 04 15 11 08 15 04 04 15 08 15 15 11 15 15 15 08 15 15 08 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fc 43
7:11 03 24 1a ff 08 ff 15 06 00 00 00 00 00 00 00 0b 07 01 1f 0c 13 14 03 01 00 83 00 00 fd 43
7:11 03 51 08 ff 08 ff 03 18 24 4b fe 43
7:12 03 39 08 ff 08 ff 03 18 24 4b 00 43
     Another "03 39" so I send a request to the panel to send me an "03 04", this time the panel responds straight away
7:12 03 04 45 ff 08 03 40 04 04 15 11 08 15 04 04 15 08 15 15 11 15 15 15 08 15 15 08 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 43
     In this "03 04" message, the "45" (hex) means that the inside data block is 69 bytes
     The first 4 bytes "ff 08 03 40" I have no idea what they mean
     The next 64 bytes I think are the sensor states
          You have 21 sensors/devices Z01 to Z21, I think the breakdown of this data is as follows:
                "04 04 15 11 08 15 04 04 15 08 15 15 11 15 15 15 08 15 15 08 11"
          The remaining 43 bytes are all "00"
     The last byte in the 69 is "01", I have no idea what it might mean

I periodically ask the panel for its status, it gets interesting again at 8:25 when I do this.

8:25 We send a command "Restore". This asks the panel to send it's status with a series of A5 messages "10 01", "10 02", "10 03" etc etc to "10 10"
8:25 When it decodes the A5 "10 04" message, it says that Z05 has been triggered

Overall, I think that:

Many of the B0 messages data content start with the same “ff 08” but that could mean anything or nothing. It could be specific to your panel, I don’t know.
What we can see is that the panel does not push out motion/event changes like a PowerMax does, at least not using the A5 messages.
I believe that the triggers you see are associated with us periodically asking the panel to send the state as A5 messages. I think that the delay in you seeing the triggered state is to do with when we ask the panel to send it’s state.
Any special B0 function in the code I have is disabled (you would need to enable it). However:
Looking at the 2 B0 “03 04” messages that happened 2 seconds apart, I cannot see a change in the zone part of the data.

D

davesmeghead · January 1, 2020, 10:19am

In the original log file you uploaded you’re correct but in the latest log file you uploaded there are plenty of B0 messages when you’re in powerlink. I’m confused, what changed?

In the code, if these 3 conditions exist:

we have nothing else to send to the panel and
we’re not downloading the EEPROM and
we have exceeded a timeout of 75 seconds

Then we send a request to the panel to ask for its status. I think that you’re seeing the effect of this when you trigger your sensors, this is what’s causing the delay. It is between 0 and 75 seconds that you see the status come through to HA.

For this log file, you have enabled my experimental code. This works its magic and I can see in the log file it shows that the B0 messages are used to show zone triggers.
No detailed analysis needed this time so to summarise your log file

18:06 We send a request for the panels status
      The panel sends its status and we work out that Z04 has been triggered

20:30 The MotionOffDelay defaults to 120 seconds so we assume at 20:06 Z04 has triggered back to 0. 
      At 20:30 the log file shows that triggered is 0.

20:32 There are several B0 messages within a space of 4 seconds.
      Culminating in Z04 showing triggered (lines 232 to 300 in the log file). 
      This is the experimental code.

21:24  We send a request for the panels status
      The panel sends its status and we work out that Z04 has been triggered.
      I think that this is the same trigger as what we found out at 20:32 above and not a new trigger.

23:18 Somewhere between 23:18 and 23:48 the trigger is set back to 0. 
      I may be holding the trigger to 1 for longer than MotionOffDelay
         (120 seconds by default) by mistake (I'm using the 21:34 time as the start instead of the 20:32). 
      I can look at this when we get the B0 experimental code working consistently.

25:06 There are several B0 messages within a space of 4 seconds. Same as the 20:32 time.
      Culminating in Z04 showing triggered (lines 667 to 697 in the log file). 
      This is the experimental code.

26:07 We send a request for the panels status
      The panel sends its status and we work out that Z04 has been triggered.
      I think that this is the same trigger as what we found out at 25:06 above and not a new trigger.

Ran out of log file but I assume the same happens as at 23:18

So, overall:

We have 3 Z04 triggers in the file
The 1st trigger was detected by us requesting the panels status, the panel did not tell us about it.
The 2nd and 3rd triggers, the panel told us about using the B0 experimental code
I have no idea of the timing and the delays associated with these 3 triggers i.e the time between you waving your arms in front of the PIR and it showing in HA a triggered status. Are you able to remember if there was a difference between the 1st, 2nd and 3rd triggers?

So the experimental code might be promising, it could be working.

Can you try it with the experimental code disabled and enabled (in your configuration.yaml) and tell me what time delays you get with PIR sensors (between waving your arms and it showing in HA). I’m interested to see if the time delays are different so no need to upload log file but you can if you get chance. Make sure that each time you test you leave at least 2 minutes apart to allow for both the panel and my code to reset the motion sensor trigger back to 0 (off).

pocket · January 1, 2020, 3:00pm

I changed the panel setting of the sensor to ‘Disarm Activity’. Like a hardware failure lets the smoke out, the configuration change lets the ‘B0’ out of the panel. Or is it something else?

I think I’d have to re-enable the LED to see when triggers are occurring to correlate it to the message activity. Later in the day, I might be able to do that.

pocket · January 1, 2020, 11:48pm

Hi Dave. Here ya go.

The first capture is with the three B0 directives in the configuration.yaml file:

https://pastebin.com/zfzRNnsu

For these events, from the LED being triggered to a change of state in HA is about 2-4 seconds. It takes a second or two to trigger the LED from a hand wave in front of the sensor. Clearing takes about 2½ to 3½ minutes.

The first event is triggered at 17:48:00. The state is cleared at around 17:50:30.
The second event is triggered at 17:51:00. The state is cleared at around 17:53:50.
The third event is triggered at 17:55:00. The state is cleared at around 17:58:38.

Here’s the second capture without B0 directives in the configuration.yaml file:

https://pastebin.com/8L50XJzP

For these events, it takes between 30 seconds and 2 minutes between a hand wave and a state change. Clearing the state takes uniformly about 2 minutes for each event.

The first event occurs at 18:06:00. State change is at 18:06:30 and clear is at 18:08:30.
The second event occurs at 18:09:00. State change is at 18:09:49 and clear is at 18:11:49.
The third event occurs at 18:14:00. State change is at 18:15:54 and clear is at 18:17:53.

I hope I got the info accurately transcribed. Let me know if I can do anything more.

olijouve · January 2, 2020, 9:37am

First happy new year, my best wishes for all of you guys !

@davesmeghead, I’d missed that, thank’s indeed it’s better now.

@syrakarn what about your wemos mini integration, did you succeed on it ?
I can give you a hand if you still struggle.

davesmeghead · January 2, 2020, 10:10am

Hi Rob, you’ve confirmed what I had thought and hoped for.

Without the B0 message processing we rely on the periodic request that we make to the panel to tell us its state. That’s why it takes so long to get the state change in HA and why its so variable, it depends on the timing of you waving your arms and when the request is made to the panel. Clearing takes 2 minutes as that is what “motion_off” defaults to i.e. 120 seconds (and I assume you haven’t changed it). This setting must be more than the equivalent setting in the panel.

With the B0 message processing, it looks like it’s working triggers are coming through pretty quickly, I’m not sure if this can be speeded up or not. The problem is that the time is taken by the panel sending us a “something changed” message, we then ask the panel what and then it tells us.
Clearing is not as precise because of the way I added the B0 processing code, I just put it in for testing purposes.

I have updated the B0 message processing to make the Clearing time more consistent and uploaded version 0.3.4.10 to Github. Can you please give it a try with the B0 directives.

Digiw · January 2, 2020, 1:00pm

Hi Olijouve,

I use your configuration a few months and I like the add-on in your picture in particular the battery status and notifications in your picture (post 767). Question I have, what have you changed in the configuration mentioned in post above 532 to show the battery and notifications? Thanks in advance.

cjones813 · January 2, 2020, 2:39pm

Many thanks Dave. Should i remove the test code out of the config.yaml file after the update? or should this be left in place?

davesmeghead · January 2, 2020, 3:10pm

Leave it in place for 0.3.4.10, it’s still experimental and I only want people to enable it who are aware of what they’re doing i.e. testing PIRs with a PowerMaster panel. So, please leave these:

  b0_enable_motion_processing: 'yes'
  b0_min_time_between_triggers: 30
  b0_max_time_for_trigger_event: 5

If other PowerMaster users use it I might get lots of questions on here about what’s happening

You and Rob (as I don’t have a PowerMaster) might need to experiment with the 2 time values:

b0_min_time_between_triggers is the time between subsequent B0 PIR triggers. This is a difficult one to judge as it is a global for all your PIRs. If you trigger 1 of your PIRs, then you won’t be able to trigger it again or any other PIR for this time. But I need a time interval in order to judge the pairs of B0 messages to determine the difference in their states.
b0_max_time_for_trigger_event, this is the maximum time to receive the 2 consecutive paired B0 “03 04” messages to determine the change in PIR state, currently 5 seconds. From Rob’s log file I can see that this happens within 2 seconds so I might default this to 5 seconds and let users override it in their config files if they need to. This has to be a smaller number than b0_min_time_between_triggers

Hope this makes sense

If you (I think Rob only has 1 PIR at the moment) are up for experimenting, then try setting:

  b0_enable_motion_processing: 'yes'
  b0_min_time_between_triggers: 5
  b0_max_time_for_trigger_event: 2

Then try to trigger multiple PIRs as quick as you can and see what it looks like in HA (Use HA on your phone or tablet so you can walk around with it)

cjones813 · January 2, 2020, 3:21pm

Thanks Dave you have been very helpful. Yes going to have a play around with it tonight, will update you and let you know what setting is working best.

olijouve · January 2, 2020, 3:58pm

Hi @Digiw , i’m glad you find it usefull !

I finally took the time to secretize my passwords and logins so i’ve pubished my config on github:

As i said on post 767, i had switched to yaml mode on mid September so now my lovelace config has a split views/cards/subcards logic. I find it much more maintainable.
Also and since then MonsterCard was deprecated so i switch to its new auto-entities substitute.

Lucky you I have kept my old lovelace config, battery part is from line 200 to 264:

github.com

olijouve/my_HA_config/blob/9d5979583c79287c55ada8160ed6d40bc44a4c6e/ui-lovelace_save.yaml

cch:
  swipe: true
  swipe_amount: '30'
resources:
  - type: js
    url: /local/custom-lovelace/card-mod.js
  - type: js
    url: /local/custom-lovelace/alarm_control_panel-card/alarm_control_panel-card.js
  - type: js
    url: /community_plugin/monster-card/monster-card.js
  - type: module
    url: >-
      /local/custom-lovelace/compact-custom-header/compact-custom-header.js?v=1.3.1
  - type: js
    url: /community_plugin/vertical-stack-in-card/vertical-stack-in-card.js
  - type: js
    url: /community_plugin/list-card/list-card.js
  - type: module
    url: /community_plugin/garbage-collection-card/garbage-collection-card.js
title: Home

This file has been truncated. show original

Notifications are set up here:

components/input_booleans/visonic.yaml
components/notify.yaml
automations.yaml

Enjoy !

pocket · January 2, 2020, 4:42pm

I’ve experimented a bit without changing the values. Triggering seems pretty quick, although the first one after HA restart seemed slower. Perhaps it was still negotiating mode. Waiting longer after a restart put the first event within family.

From triggered to clear have be between 2¾ and 3½ minutes, so not much improvement.