Thanks for your time.
here it is:
New paste as in the last one, visonic component never succeed to load.
This one is with download_code : ‘3622’
This code 3622 comes from another project i tested severals months ago, the first time i tried to control the alarm. I didn’t knew homeassistant existance.
I think it was this one:
If it can help here a part of the json result:
{“stat”:0,
“stat_str”:“Disarmed”,
“lastCom”:9,
“panelType”:2,
“panelTypeStr”:“PowerMax Pro”,
“panelModelType”:22,
“alarmState”:0,
“alarmStateStr”:“None”,
“alarmTrippedZones”:[],
“config”:{“installer_pin”:“8888”,
“masterinstaller_pin”:“9999”,
“powerlink_pin”:“3622”,
“user_pins”:[“1111”],
“telephone_numbers”:[“0000000000”,“0000000000”,“0000000000”,“0000000000”],
“serial_number”:“0”,
“eprom”:“J-700356 v4.6.06”,
“software”:“JS701192 v4.6.06”,
“partitionCnt”:1},
“flags”:69,
“flags_ready”:true,
“flags_alertInMemory”:false,
“flags_trouble”:true,
“flags_bypasOn”:false,
“flags_last10sec”:false,
“flags_zoneEvent”:false,
“flags_armDisarmEvent”:true,
“flags_alarmEvent”:false,
“enroled_zones”:[{“zoneName”:“Porte d’entre”,
“zoneType”:20,
“zoneTypeStr”:"??",
“sensorId”:117,
“sensorType”:“Magnet”,
“sensorMake”:“Visonic Door/Window Contact”,
“signalStrength”:0,
“stat_doorOpen”:false,
“stat_bypased”:false,
“stat_lowBattery”:false,
You’re right, this one failed to load but the AAAA one got quite a bit further. I know this sounds strange but you’re better off using a download code that you’ve never used before. Don’t ask me why, it’s just what I’ve experienced.
I’ve just uploaded version 0.2.4 to Github with watchdog and download counters as attributes to the panel entity. I also push events through the HA system that can be used, see the description on github. Also, I’ve added some code to handle access denied panel messages in a much more flexible way to see if that helps you.
Can you give it a try please and upload the log file again 
Just another thought, do you need to perform manual enrollment from your panel?
A proper Visonic PowerLink hardware device has to be enrolled to the PowerMax+ / PowerMax PRO. My Component pretends to be a proper PowerLink device. Many panels do this enrollment automatically, mine does, but some panels need you to manually perform this in order to enroll the PowerLink. Try this:
Enter the "USER SETTING" menu.
Choose "DEFINE PWRLNK" and "Install".
Press "Show/OK".
Wait for the confirmation sound.
Press "Away".
Press "Show/OK".
Can you check your panel to see if it has these options in the menu system, if so then I believe it to be manually enrolled. In this case you’ll need to do these actions a few minutes after starting HA with the Component connected to the panel (I think). I don’t know if you need to do it once or every time, you’ll need to experiment a bit.
I have to admit that I’m guessing a bit here, but it’s a possibility since you’ve never been able to achieve powerlink status, you always seem to get access denied messages from the panel.
I would appreciate you trying 0.2.4 though and uploading the log file 
So kind from you !
Here are logs for 0.2.4 update:
-
0.2.4 with 5650 download code :
0.2.4_5650 - Pastebin.com -
0.2.4 with AAAB download code (i didn’t use AAAA as you said better not reuse same codes) :
0.2.4_AAAB - Pastebin.com
I can confirm that download counter attribute increments correctly in HA UI.
About enrollement from panel, i had already done it several times over last months and more recently since 0.2(while in download and in standard mode) and it’s set to enable.
Will be on seminary day and night tomorrow so i couldnt’ test anything before friday evening.
So, here’s another startup file with V0.2.4. What’s shown results from a cold boot of the HA host system. Judging by the alarm attributes, it’s still not getting the sensor type information.
Prior to the update, I recalled an edit I made with my HA configuration to get the proper badge icons for the two sensors to appear on the overview page. I thought that might’ve caused the issues, so I found which file I edited (customize.yaml) and commented the entries. I’m not surprised it didn’t work because it applied only to the appearance of the overview page.
At any rate, here’s most of the log from startup:
You’ll note that communication took a while to be established since there was a communication interruption that typically occurs when I perform a cold reboot of the system. A panel fault was flagged, which eventually cleared as communication was restored.
I’ll try to perform an HA server restart to see if that does any better.
As always, thanks.
This log is the result of an HA Server restart (vs system reboot). Not much, if anything, changed. Since there was no loss of communication indication, there was little difficulty establishing a connection with the Visonic component.
Hi @davesmeghead I know you ruled out offical support integration (due to time and structure), but what do you think about HACS integration, would make keeping up to date just that bit simpler?
olijouve suggested this a few days ago, it’s something that I’ll look into when I get some proper time to look at it so thanks for the suggestion.
Hi pocket, I’m just catching up a bit. I’ve had a look through both your log files and:
- The good news is that both times it gets to Powerlink Mode, getting pin codes etc. I admit that it does take a little longer than it should, taking about 6 or 7 minutes as it only succeeds on it’s 2nd try (I intentionally wait 4 minutes between tries to let the panel settle down).
- The bad news is that when I try to access the downloaded (from EPROM) zone types they have not been downloaded properly so it doesn’t create the proper icons in HA etc. It’s the only thing that seems to be missing. The part of the log file to look at is “MSG_DL_MR_ZONES Buffer”, it’s shorthand code speak for Message Download Powermaster Master Zones, the message before it “Sorry but you havent downloaded that part of the EPROM data” gives me the big clue
I can add some more debug code to try and find out why if you’re willing to give it a try. I’ll upload another version later tonight or sometime tomorrow.
Yes, very subtle! 
I’m more than willing, but it doesn’t need to be your highest priority.
OK, so I’ve just uploaded version 0.2.5 with:
If it does get as far as getting the EPROM data, there is lots and lots of debug logging, you may need to split each log in to 2 or 3 pastebin pastes (I dont know the maximum lines allowed for a single pastebin). I have tried to make sure that your panel user and installer pin numbers are not printed to the log files as they are part of the EPROM download. You can do a search youselves to make sure like this:
If your pin is “1234” then search for “12 34” with a space in between.
Check for your user and installer pin codes.
Edit: Forgot to mention, I’ve changed the powermaster download sequence, I’ve split it in to 3 phases to see if it works better.
Here’s the log (in 2 pieces):
https://pastebin.com/tyyPSMhQ
https://pastebin.com/MizCDE33
The log captures a system reboot. It took a while–nearly 17 minutes–to get the alarm panel to an operational state. The Watchdog and Download Timeout attributes remained at 0.
The good news is the motion detector was registered. The door switch was flagged as stype=UNKNOWN (Other Zones), but at least it was recognized. It’s a type MC 302 PG2 (ID 104-5624). How do sensors get associated with their types?
https://www.visonic.com/Products/PowerG-Wireless-Property-Protection/mc-302v-pg2
I’ve just uploaded 0.2.6 to Github for you to try please. I noticed lots of things from your log file:
- We get a badly timed message from the panel which interrupts the download sequence, I’ve hopefully sorted it by ignoring the message until the download sequence is finished i.e. I don’t react to it while doing download.
- Maybe because of 1 above I’m not sure, it took longer than 4 minutes to finish the first download sequence and because of this I triggered another download sequence. It took so long because it was downloading for a looooong time I’ve stopped this happening I think.
- You’re correct about the Unknown sensor type. It’s actually a type 45 sensor so I’ve added it to the list of valid sensors.
- The good news is that it got the valid sequence for the enrolled sensors from the EPROM eventually you should be able to remove the “exclude_sensor:” entry from your configuration.yaml (or maybe just comment it out for now to make sure)
Again, you might need to upload to pastebin in more than one go, hopefully the download will be much faster this time as it should only do it once.
Hello! I’ve been using this component for a bit with my PowerMax+, and it has been working great, thanks for all the hard work!
I recently updated to the latest github release and my binary_sensors are no longer showing up. The panel registers fine, and I can see it being available in Powerlink mode ( alarm_control_panel.visonic_alarm shows up in my device list and looks correct). I just can’t see my various sensors in hassio any longer. I’ve tried excluding all X10 devices but it didnt seem to help.
Here’s some output from the my logfiles in case it helps, appreciate any help in advance:
2019-06-22 08:45:42 INFO (MainThread) [custom_components.visonic] Visonic got new sensors/switches defaultdict(<class 'list'>, {'sensor': [<custom_components.visonic.pyvisonic.SensorDevice object at 0x7249f8d0>, <custom_components.visonic.pyvisonic.SensorDevice object at 0x7249ff30>, <custom_components.visonic.pyvisonic.SensorDevice object at 0x7249ffd0>, <custom_components.visonic.pyvisonic.SensorDevice object at 0x7249feb0>, <custom_components.visonic.pyvisonic.SensorDevice object at 0x7249fff0>, <custom_components.visonic.pyvisonic.SensorDevice object at 0x72384690>, <custom_components.visonic.pyvisonic.SensorDevice object at 0x72384710>, <custom_components.visonic.pyvisonic.SensorDevice object at 0x72384630>, <custom_components.visonic.pyvisonic.SensorDevice object at 0x72384810>], 'switch': [<custom_components.visonic.pyvisonic.X10Device object at 0x7249f890>, <custom_components.visonic.pyvisonic.X10Device object at 0x72384410>, <custom_components.visonic.pyvisonic.X10Device object at 0x723844f0>, <custom_components.visonic.pyvisonic.X10Device object at 0x723846d0>, <custom_components.visonic.pyvisonic.X10Device object at 0x723843d0>, <custom_components.visonic.pyvisonic.X10Device object at 0x72384430>, <custom_components.visonic.pyvisonic.X10Device object at 0x72384390>, <custom_components.visonic.pyvisonic.X10Device object at 0x72384350>, <custom_components.visonic.pyvisonic.X10Device object at 0x723840d0>, <custom_components.visonic.pyvisonic.X10Device object at 0x72384170>, <custom_components.visonic.pyvisonic.X10Device object at 0x72384130>, <custom_components.visonic.pyvisonic.X10Device object at 0x723841f0>, <custom_components.visonic.pyvisonic.X10Device object at 0x72384210>, <custom_components.visonic.pyvisonic.X10Device object at 0x72384230>, <custom_components.visonic.pyvisonic.X10Device object at 0x723841b0>, <custom_components.visonic.pyvisonic.X10Device object at 0x723840f0>]})
2019-06-22 08:45:42 INFO (MainThread) [custom_components.visonic.pyvisonic] [Process Settings] Ready for use
2019-06-22 08:45:42 INFO (MainThread) [custom_components.visonic.pyvisonic] =============================================== Display Status ===============================================
2019-06-22 08:45:42 INFO (MainThread) [custom_components.visonic.pyvisonic] key 0 Sensor id=1 dname=Z01 stype=Magnet zname=Front door ztypeName=Delay 1 ztamper=0 ztrip=0 bypass=0 lowbatt=0 status=0 tamper=0 enrolled=0 triggered=0
2019-06-22 08:45:42 INFO (MainThread) [custom_components.visonic.pyvisonic] key 1 Sensor id=2 dname=Z02 stype=Magnet zname=Back door ztypeName=Perimeter ztamper=0 ztrip=0 bypass=0 lowbatt=0 status=0 tamper=0 enrolled=0 triggered=0
2019-06-22 08:45:42 INFO (MainThread) [custom_components.visonic.pyvisonic] key 2 Sensor id=3 dname=Z03 stype=Magnet zname=Laundry room ztypeName=Delay 2 ztamper=0 ztrip=0 bypass=0 lowbatt=0 status=0 tamper=0 enrolled=0 triggered=0
2019-06-22 08:45:42 INFO (MainThread) [custom_components.visonic.pyvisonic] key 3 Sensor id=4 dname=Z04 stype=Motion zname=Garage ztypeName=Perimeter-Follow ztamper=0 ztrip=0 bypass=0 lowbatt=0 status=0 tamper=0 enrolled=0 triggered=0
2019-06-22 08:45:42 INFO (MainThread) [custom_components.visonic.pyvisonic] key 4 Sensor id=5 dname=Z05 stype=Motion zname=Hall ztypeName=Interior-Follow ztamper=0 ztrip=0 bypass=0 lowbatt=0 status=0 tamper=0 enrolled=0 triggered=0
2019-06-22 08:45:42 INFO (MainThread) [custom_components.visonic.pyvisonic] key 5 Sensor id=6 dname=Z06 stype=Magnet zname=Garage door ztypeName=Perimeter-Follow ztamper=0 ztrip=0 bypass=0 lowbatt=0 status=0 tamper=0 enrolled=0 triggered=0
2019-06-22 08:45:42 INFO (MainThread) [custom_components.visonic.pyvisonic] key 6 Sensor id=7 dname=Z07 stype=Motion zname=Play room ztypeName=Interior-Follow ztamper=0 ztrip=0 bypass=0 lowbatt=0 status=0 tamper=0 enrolled=0 triggered=0
2019-06-22 08:45:42 INFO (MainThread) [custom_components.visonic.pyvisonic] key 28 Sensor id=29 dname=Z29 stype=Wired zname=Hall ztypeName=Non-Alarm ztamper=0 ztrip=0 bypass=0 lowbatt=0 status=0 tamper=0 enrolled=0 triggered=0
2019-06-22 08:45:42 INFO (MainThread) [custom_components.visonic.pyvisonic] key 29 Sensor id=30 dname=Z30 stype=Wired zname=Utility room ztypeName=Non-Alarm ztamper=0 ztrip=0 bypass=0 lowbatt=0 status=0 tamper=0 enrolled=0 triggered=0
2019-06-22 08:45:42 INFO (MainThread) [custom_components.visonic.pyvisonic] Model PowerMax+ PowerMaster No LastEvent None Ready No
2019-06-22 08:45:42 INFO (MainThread) [custom_components.visonic.pyvisonic] Mode Download Status Unknown Armed No Trouble None AlarmStatus None
2019-06-22 08:45:42 INFO (MainThread) [custom_components.visonic.pyvisonic] ==============================================================================================================
...
2019-06-22 08:45:44 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [pmSendPdu] Sending Command (Setting Time) raw data 0d 46 f8 00 2a 2d 08 16 06 13 ff ff 32 0a waiting for message response []
2019-06-22 08:45:45 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [pmSendPdu] Sending Command (Ack Long) raw data 0d 02 43 ba 0a waiting for message response []
2019-06-22 08:45:45 INFO (MainThread) [custom_components.visonic.pyvisonic] [validatePDU] Not valid packet, CRC failed, may be ongoing and not final 0A
2019-06-22 08:45:45 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [data receiver] Building PDU: Length is now 9 bytes (apparently PDU not complete) 0d f1 07 43 00 00 8b 56 0a checksum calcs 38
2019-06-22 08:45:45 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [pmSendPdu] 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']
2019-06-22 08:45:45 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [data receiver] Building PDU: Dumping Current PDU 0d f1 07 43 00 00 8b 56 0a
2019-06-22 08:45:45 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [data receiver] msgType 0X2 got it so removed from list, list is now ['0XA5']
2019-06-22 08:45:45 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [handle_msgtype02] Ack Received data = 43
2019-06-22 08:45:45 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [Sending ack] PowerlinkMode=True Is PM Ack Reqd=True This is an Ack for message=0XA5
2019-06-22 08:45:45 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [data receiver] msgType 0XA5 got it so removed from list, list is now []
...
2019-06-22 08:45:45 INFO (MainThread) [custom_components.visonic] Visonic got new sensors/switches defaultdict(<class 'list'>, {})
2019-06-22 08:45:45 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [handle_msgtypeA5] Bypassed Zones 32-01: 00000000000000000000000000000000
...
2019-06-22 08:45:53 INFO (SyncWorker_5) [custom_components.visonic.binary_sensor] In setup_platform the sensor config file
2019-06-22 08:45:53 INFO (SyncWorker_16) [custom_components.visonic.binary_sensor] In setup_platform the sensor config file
2019-06-22 08:46:13 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [pmSendPdu] Sending Command (Im Alive Message To Panel) raw data 0d ab 03 00 00 00 00 00 00 00 00 00 43 0e 0a waiting for message response ['0X2']
2019-06-22 08:46:13 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [data receiver] msgType 0X2 got it so removed from list, list is now []
2019-06-22 08:46:13 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [handle_msgtype02] Ack Received data = 43
2019-06-22 08:46:14 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [Sending ack] PowerlinkMode=True Is PM Ack Reqd=True This is an Ack for message=0XAB
2019-06-22 08:46:14 INFO (MainThread) [custom_components.visonic.pyvisonic] [handle_msgtypeAB] data 03 00 1e 00 33 33 31 36 00 00 43
2019-06-22 08:46:14 INFO (MainThread) [custom_components.visonic.pyvisonic] [handle_msgtypeAB] ***************************** Got PowerLink Keep-Alive ****************************
Wow. It’s much improved. This time, it achieved Powerlink mode in 3-1/2 minutes. Moreover, the sensors were enrolled and the exclude statement in the configuration.yaml file wasn’t needed.
Here are the log files:
https://pastebin.com/zKs6Gv6B
https://pastebin.com/VmHNKG5J
From my point of view, the system performance and stability seems pretty good. I’ll verify with a few more startup scenarios, but the only remaining comments would be picking nits. These would be more associated with conveniences and cosmetics.
Thanks a million, Dave.
Hi Brian, I’m afraid log fragments don’t help me much as they don’t tell me the sequence that the panel went through. It looks like you have the logger settings correct but you would need to upload the complete log file to pastebin, if you do then I’ll take a look through.
Hi Rob,
That’s excellent news
Even better
Let me know anyway and I can look through and see how easy they are to implement
I do have more to ask of you though. That last version 0.2.6 I went over the top to make sure the panel downloaded all the necessary EPROM settings. In fact, looking at the log file there are big parts of the EPROM data that get downloaded 3 times, that’s what still makes the download take so long (although a PowerMaster needs more data to be downloaded than the PowerMax so I don’t really know how long is too long if you see what I mean). I’d like to have a go at cutting down on the number of times if you wouldn’t mind testing it for me again please.
I’ll put this stuff at the end of the post.
Yes, I saw this when looking more closely at the logs. It behaves the same during an HA server restart.
I wouldn’t mind running additional tests, at all. I’ve gotten the process down to where I can almost do it in my sleep.
As far as the nits, it would be nice if you can characterize the zone class based on keywords in the zone names. For example, if you see the word door in the zone name, assign the class as a door instead of a window. I could look at icons to see what might be options for various sensor types. I realize there will be language issues, but maybe there can be a custom yaml file for that.
Another idea is to create a configuration.yaml option to populate the friendly name with the zone name rather than the entity name. I expect there could be issues with duplicates, but appending a number or letter can make it unique.
Enough nits for now.
Thanks a bunch!