Closed fuef closed 2 months ago
I seem to be having some challenges with my build environment, @davesmeghead . It's a 32-bit Raspberry Pi OS Lite (bookworm / Python 3.11 / venv).
I can run simple_example.py from master branch without any issues:
Development branch produces just a few lines of output and does nothing afterwards:
And complete_example.py
from dev
branch throws a general exception at me:
The way I setup my build environment is very simple:
unzip $HOME/visonic-{master,dev}.zip
cd $HOME/visonic-{master,dev}/custom_components/visonic
python -m venv examples
source examples/bin/activate
pip install -r examples/requirements.txt
I make a big assumption that when Python sees pyvisonic.py
in the current directory it will process import pyvisonic
by referring to the code in the current directory.
I am getting puzzled by examining
diff -u $HOME/visonic-{master,dev}/custom_components/visonic/examples/simple_example.py
output. I wouldn't be able to tell what dependencies could I be missing.
I also tried Python 3.12 from HASS Core container which makes no difference. I can try Python 3.9.6 on macOS, if it helps. Spinning up a Windows VM will take more time, and plumbing USB devices on macOS host via VirtualBox is a hit and miss in my experience. What else can I try, please?
Hi, I've just uploaded a dev release, I've made sure the simple_example and complete_example work on windows and linux in my environment, you were right that linux was an issue that I believe I've fixed.
For the complete_example.py run it like this, you need to be in the examples directory as it adds the parent path inside the python file itself to the python library path. The first is windows, the second is linux.
python .\complete_example.py -panel 1 -usb COM7 -baud 9600 -connect powerlink -logfile out.txt -print debug
python .\complete_example.py -panel 1 -usb /dev/xyz -baud 9600 -connect powerlink -logfile out.txt -print debug
In the bottom window of aconsole that starts type "c" to connect, "h" for help
This creates a log file called out.txt
Some PowerMasters alternate between 9600 and 38400 baud so if it doesn't work after typing "c" then kill it and try the other baud rate.
Dave
Oh, Man! Visonic PowerMaster 360 has achieved ❤️ ❤️ ❤️ Standard Plus mode ❤️ ❤️ ❤️!!!
What to the USB serial port baud rates, I have positive experiences with both 9600
and 38400
settings using alternate projects from public domain. And yes, I am fully aware that not every USB cable is created the same. This one is capable of programming ESP32 MCUs.
Can installer code be extracted from EPROM data, by chance? I have a valid user code, if it helps.
With reference to this entry
[handle_msgtype3C] PanelType=13 : PowerMaster 360 , Model=153 Powermaster True
does pyvisonic.py
code require any updates to accommodate Model=153
? As a reminder, the panel identifies itself as follows via AlarmInstall app:
key | value |
---|---|
Control panel software version | JS703296 L19.412 |
Control panel default version | J-705117 L19.412 |
Control panel boot version | JS702767 L01.026 |
Control panel Remote Software Upgrade downloader version | JS702768 L02.036 |
PowerLink software version | PL8.0.94.14 row |
cellular modem type. | GE910-QUAD-V3 |
In your view, do any of the above entires have to be cross-referenced against Windows PowerMaster Remote Programmer
.TDF
or .DLL
files?
It's not a big deal I guess, but complete_example.py
has failed with
The out.txt
isn't informative, it's just a middle line from the excerpt above. I attach the output of python -v
, if it helps:
Visonic PowerMaster 360 complete_example General Exception 20240524.txt
Unlike simple_example.py
, complete_example.py
has complained about a missing requests
dependency. pip install -v requests
has resulted in pulling requests
version 2.32.2
.
All known Installer and Download Codes have been attempted with simple_example.py
. No cigar, so far.
Looking at the simple_example.py
logs, it could be just my imagination, but numeric-only Download Codes always result in multiple EDIT: It was just my imagination.Mode= PROBLEM
lines. Pure hexadecimal Download Codes produce just a single line.
Thinking ahead, and if something like dscKeybusInterface logic will be required to guess the right Download Code, and given that hexadecimals are accepted by the software, 10 attempts per second will take about one year and one month. It sounds doable to me.
With reference to the Visonic / DSC / Johnson Controls / Tyco M&A timeline, I'd speculate PM-360 has happened after PM-10 and PM-30, but prior to DSC. PM-360R's been created after DSC series. Chances are that dscKeybusInterface project's brute force logic is compatible with PM-360 hardware.
EDIT: Upon re-checking with Wiki, I confirm that waiting for 9+ minutes / 4 attempts to enrol hasn't been successful and Standard Plus mode remains in power:
Visonic PowerMaster 360 simple_example 5650 Standard Plus 20240524.txt Visonic PowerMaster 360 simple_example 8888 Standard Plus 20240524.txt Visonic PowerMaster 360 simple_example 8888-2 Standard Plus 20240524.txt Visonic PowerMaster 360 simple_example 9999 Standard Plus 20240524.txt Visonic PowerMaster 360 simple_example AAAA Standard Plus 20240524.txt Visonic PowerMaster 360 simple_example BBBB Standard Plus 20240524.txt
Hi, That's good news, let me go through your points one by one and try to help
What to the USB serial port baud rates, I have positive experiences with both 9600 and 38400 settings using alternate projects from public domain. And yes, I am fully aware that not every USB cable is created the same. This one is capable of programming ESP32 MCUs.
I've found by my experimentation that a Powerlink hardware device alternates between 9600 and 38400 when it tries to start the communication with the panel. When it succeeds at 1 of the 2 baud rates, if at 9600 then it asks the panel to go to 38400, they are then both at 38400.
Can installer code be extracted from EPROM data, by chance? I have a valid user code, if it helps.
Yes, in pyvisonic.py (the dev release) uncomment these lines so you get:
# DON'T SAVE THE USER CODES TO THE LOG
log.debug("[Process Settings] User Codes:")
if len(uc) == userCnt:
self.pmPincode_t = uc
self.pmGotUserCode = True
for i in range(0, userCnt):
log.debug(f"[Process Settings] User {i} has code {self._toString(uc[i])}")
else:
log.debug(f"[Process Settings] User code count is different {userCnt} != {len(uc)}")
log.debug(f"[Process Settings] Installer Code {self._toString(self._lookupEpromSingle('installerCode'))}")
log.debug(f"[Process Settings] Master DL Code {self._toString(self._lookupEpromSingle('masterDlCode'))}")
if self.PowerMaster is not None and self.PowerMaster:
log.debug(f"[Process Settings] Master Code {self._toString(self._lookupEpromSingle('masterCode'))}")
log.debug(f"[Process Settings] Installer DL Code {self._toString(self._lookupEpromSingle('instalDlCode'))}")
After it downloads the EEPROM (which you have done if you're in Standard Plus) the above displays all user codes and all 4 installer codes (for a PowerMaster series). It prints them with a space in between as its 2 bytes but you'll see what I mean.
does pyvisonic.py code require any updates to accommodate Model=153?
As you have achieved Standard Plus mode then probably not.
I've been thinking about this over the past few days. A PowerMaster 360 and 360R both have Ethernet connections and the ability to use the Visonic Go App.
I therefore assume that they have the PowerLink hardware built in to the panel.
If that hardware inside the panel has already "enrolled" as a powerlink device then the panel is unlikely to support more than 1.
I conclude that "Standard Plus" maybe the best that we can achieve.
This is not a bad thing and the difference in my integration is very little, the exchange of "I'm Alive" messages for example but not much more.
I'm not sure why complete_example is failing for you, I do not run it in a virtual environment on linux when I test it, could it be that? Are you using the dev version I uploaded last night? aconsole may not like the virtual env
You keep talking about download codes, if you're in Standard Plus then you have already downloaded the EEPROM and have the correct Download Code. If you do a hard reset on a PowerMaster panel (you have V19 firmware) then it should default to AAAA as the Download Code. I would guess that it's AAAA unless an installer has changed it in the panel settings.
For example in some of your text files they give Access Denied messages for the download code but then it does it anyway and gets the EEPROM data. This may be because it already has the Powerlink hardware build in to the panel, I don't know.
Try doing the following change (again in the latest dev version), line 2867 in pyvisonic.py i.e. comment out the if false and show the data
if val.show:
#if False:
This will output a lot of settings to the log file / screen from the EEPROM
As you have a PowerMaster then you can also set Dumpy to True on line 676, it crashes a PowerMax and I'm looking at that this afternoon.
Do not upload a log file with this information though as it gives away a lot of information about your panel.
EDIT: Upon re-checking with Wiki, I confirm that waiting for 9+ minutes / 4 attempts to enrol hasn't been successful and Standard Plus mode remains in power:
Like I suggested above, this might be the best we get with a 360 and 360R.
I'd be interested in a log file from the beginning to get to Standard Plus and then about 15 minutes more, just to see what's happening and to see if the panel tries other things. Thanks Dave
I forgot to add, ignore this error in the log file, it'll be fixed soon !
ERROR [Process Settings] Lookup of panel type string and model from the EEPROM failed, assuming EPROM download failed
You could do it yourself temporarily with this change on line 2821
if pmPanelTypeNr is not None and 0 <= pmPanelTypeNr <= 16:
Thank you very much, @davesmeghead, for letting me know how to extract the codes! Although references to my Master Code can be found in the public domain, Installer Code, Master Download Code and Installer Download Code seem to have been either configured unique to my professional installation by ADT UK, or to all ADT UK installations.
The codes are being produced around 14-15 seconds from the start. Potentially, an equipped intruder has quite a few seconds to disarm the system before the siren goes off. Given, of course, they know whereabouts of the panel.
Both Download Codes, Master Download Code and Installer Download Code, when configured on simple_example.py
result in a complete elimination of the following two entries from the logs
0:00:03.122164 <pyvisonic.py : 3407> DEBUG [handle_msgtype08] Access Denied len 0 data
0:00:03.123892 <pyvisonic.py : 3420> DEBUG [handle_msgtype08] Got an Access Denied and we have sent a Download command to the Panel
Other than that, the correct known Download Code doesn't seem to affect anything else. Wait, I remember! The Download Code is required to operate Windows PowerMaster Remote Programmer. Otherwise, it simply kicks user off.
PowerMaster Remote Programmer [32839]
Error
Access to PowerMaster denied.
Check Download Code and retry.
I make a note that Standard Plus mode gives more accurate readings for sensors Type={ MAGNET| MOTION | SHOCK } and model. In Standard mode, it was my responsibility to correct these attributes manually prior to exposing all stuff to my final destination HomeKit.
I didn't have a chance to try the Installer Code yet. In theory, it can give me ability to de-commission the siren and, more importantly, to activate SMS notifications. Given 3G spectrum is closing down in the UK, the only hope is that GPRS / 2G will continue to operate for a few more years. Otherwise, 5G router's API would have to be explored to set up out of band notifications. Wi-Fi activation for IP camera can be another option to explore / compare to the native HomeKit capability.
One of my complaints in Standard Mode was the lask of responsiveness. HASS web application didn't give me any good enough feedback when arm / disarm buttons were pressed on the application's web page. Similarilry, panel's arm / disarm status wasn't updated anywhere close to real time. It could have been showing up in Grey, while the keypad could have been beep counting / arming. Looking at the integration logs, it appears the nature of the PowerLink integration gives about 2 minute eventual consistency of the panel's state changes.
complete_example.py
must be failing because of some missing dependencies. requests
is one example, not declared on requirements.txt
(no offence). tkinter
dependency came up to the surface some time ago as well. That one seems to be part of apt install python3-tk
. Python portability between barely compatible platforms doesn't scale well. venv
is my tried way of setting up a build environment.
Are you using the dev version I uploaded last night?
Affirmative. It's being downloaded as
curl -LO https://github.com/davesmeghead/visonic/archive/refs/heads/dev.zip
.
It comes with the Download Code AAAA
in simple_example.py
which is mentioned in public domain as a factory default for PM-360.
I'd be interested in a log file from the beginning to get to Standard Plus
I attach another dump. For avoidance of any doubt, 1234
is my credit card's PIN 🤫.
PowerMaster 360 Standard Plus EEPROM 20240524.txt
Shall we mark this issue as resolved? Or shall it wait for Master branch and documents to synchronise?
Thank you very much for enabling PowerMaster 360!
Almost un-related: HASS push towards HACS in 2024.11 seems to have been addressed by your plugin. Guess what? HACS itself is being installed via ... custom_components
when it comes to containers or Core.
https://hacs.xyz/docs/setup/download/
Thank you very much for enabling PowerMaster 360!
That's OK, I'm pleased that you got it working and that I can document this on the Wiki. I'll start looking for a cheap 360R on Ebay to see if I can get it working the same !
The codes are being produced around 14-15 seconds from the start. Potentially, an equipped intruder has quite a few seconds to disarm the system before the siren goes off. Given, of course, they know whereabouts of the panel.
I see what you mean, maybe that's why the 360R has the USB connector inside the panel and you'd need to take the panel apart.
In Standard mode, it was my responsibility to correct these attributes manually prior to exposing all stuff to my final destination HomeKit.
That's because we get the EEPROM data and can extract the sensors names, locations and types.
One more thing that I noticed in the log file, for the motion sensors you have a delay of 3600 seconds i.e. 1 hour. I suggest that you set this to 0 seconds so the motion sensors work better when the panel is Disarmed. See here on the wiki https://github.com/davesmeghead/visonic/wiki#powermaster-pirs
It comes with the Download Code AAAA in simple_example.py which is mentioned in public domain as a factory default for PM-360.
You're right, I've removed it to upload next time but no harm done, it's used with my PowerMaster30 Panel for testing.
For complete_example I have removed the requests
dependency in the dev release last night.
Shall we mark this issue as resolved? Or shall it wait for Master branch and documents to synchronise?
We can mark this as closed as I won't merge anything in to the Master branch for a month or 2 yet. I also won't update the wiki yet. I'm currently looking at getting the Image from a PIR Camera and have half an implementation for it in the dev release so splitting it and working out what to merge would be more effort so I'll do it all in one big update, probably around July time. I realise that doesn't help you but you can keep using the dev release, especially as you're not planning in using Home Assistant. Also, I was serious about the 360R from Ebay, I'll look in to making it more robust.
Lastly, thanks for using it, and for testing it out.
Just a couple of extra things, for this
0:01:29.162402 <pyvisonic.py : 3386> DEBUG [handle_msgtype06] Timeout Received data
Try changing the following to 15 in pyvisonic.py KEEP_ALIVE_PERIOD = 15 # Seconds
Does it get rid of the Timeout? If not then try 10
For this
0:10:55.124894 <pyvisonic.py : 1743> DEBUG [Controller] Giving up on Powerlink Attempts, going to one of the standard modes
And just to give it a try, setting the following to False in simple_example should stop it trying to get to Powerlink state and leave it in standard plus
CONF_FORCE_AUTOENROLL: False,
This should eliminate the powerlink attempts and so the following should not happen anymore
0:03:34.410892 <pyvisonic.py : 1729> DEBUG [Controller] ** During Powerlink Attempts - Response Timer Expired ****
And it should stop it going to PROBLEM condition
You can do stuff here with visonicProtocol, Mode= PROBLEM
Can you give these are try please and let me know, another log file would be appreciated
I just checked the code and the last thing I asked you to do won't work.
Once I know that it's a PowerMaster panel then I assume it can AutoEnroll and ignore the CONF_FORCE_AUTOENROLL
setting. It will then start trying for Powerlink status and asking the Panel to Enroll. This is what the 360 Panel ignores, and we get the error "response timer expired".
I'll need to look in to it further. Would you mind leaving this issue open and give it a try, it might take me a few days
And just to explain why I suggested 15 seconds for the KEEP_ALIVE_PERIOD keep alive messages (in case anyone was wondering)
From your log file there's 20 seconds between the timeout messages from the panel.
0:02:48.989954 <pyvisonic.py : 3386> DEBUG [handle_msgtype06] Timeout Received data 0:03:08.984868 <pyvisonic.py : 3386> DEBUG [handle_msgtype06] Timeout Received data
I was about to reply "thank you again, but as an average housewife I am not interested what may be happening inside the black box as long as it doesn't break the existing setup".
Try changing the following to 15 in pyvisonic.py KEEP_ALIVE_PERIOD = 15 # Seconds
By tweaking it to either 15
or 10
, I see why you asked me to try it. The timeouts have gone 👏, along with the incrementing PROBLEM counter. I could be wrong, but instead of status updates once every two minutes it produces 'Display Status' message every 30-40 seconds by now. This would look as a real time to me.
By referring to some historical logs from parallel universe, the interval between Message type = 0x02 - ACK
entires never exceeds 21 seconds. I have no sense if it's a like for like, and why could it be important. I can try increase it to 20 seconds if you want.
I've 'promoted' dev
branch internally into HASS container. I also might have accidentally pulled today's version. I am in a total denial of testing rules. For example, previously unseen 'problem' message resulting from a PIN missing:
WARNING (MainThread) [custom_components.visonic.client] Warning: Valid 4 digit PIN not found, panelmode is PROBLEM
doesn't look right. I've seen it with my own eyes that EPROM decoding is working and all PINs are in there. This 'problem' counter stops after ~9 minutes after start.
To add insult to injury, serial port speed has 'upgraded' to 115200
. I trust this particular USB cable.
My new favourite view is http://hass.local:8123/developer-tools/state. It gives almost exactly what is achieved with
if val.show:
#if False:
Because I am in a 'production' environment now, I cannot modify CONF_FORCE_AUTOENROLL
. For some reason, pyvisonic.py
can log user-configurable Auto Enroll Supported (Unticked for PowerMax+)
as 'force_autoenroll': False
, but it doesn't honour it and continues to auto-enrol upon every start. BTW this checkbox doesn't appear on configuration dialogs after initial installation. I don't mind to re-create the whole integration, because it's quick now.
I did configure 'motion_off': 0.0
as per your suggestion. I'd speculate that having it configured as one hour by default may save sensor's battery life for longer. From architectural point of view, I am not interested what is happening inside the blackbox. And I have no intention to re-create an alarm system from scratch by reading Visonic sensors. I have Visonic panel for this. As a housewife, I am completely happy with sensor status updates history inside HomeKit. It's off by default, and I prefer to keep it that way. When something happens, I can always refer to the HASS integration logs as if it was my 'flight recorder'.
As always, 1234 is my credit card PIN on the logs 🤫. It looks brilliant in my view, thank you very much! I have to test the new integration at some point, when internal home traffic will subside in the forthcoming hours.
home-assistant_visonic_2024-05-25T16-15-47.467Z.log
Rather than attaching an unsightly PIR to the camera, I am exploring TinyML / OpenCV options, based on ever advancing motion detection capabilities.
20 hours in a freshly commissioned integration, with addition of HomeKit...
So far, so good, thank you! The problem counter
continues to increment, but the rate isn't alarming in my view. How much does it hurt when watchdog kicks in? Or does watchdog makes it an average over 24 hours?
It's been a brave move to test the installation on Sunday's morning during the Bank Holiday, after party and without debugging level logs:
z02
in the living room has resulted in keypad's beeping 30 second countdownz04
in conservatoryWell, Home Assistant's account of the incident is kind of misleading.
HomeKit has sent command 10:53:29 alarm_disarm
way after 10:53:46 visonic_p1_z02
has detected motion (please, refer to my account what worked above). Similarly, 11:05:19 visonic_p1_z04
has detected motion before Alarm Panel changed to Disarmed
.
Neither HomeKit, nor Home Assistant have a record of the siren going off though.
A couple of questions if I may:
last_tripped_time
populated. Is this time stamp local to Home Assistant, or does panel write it to sensors? If the latter is the case, battery life may be of a concern.9600
baud? If yes, is there a place in pyvisonic.py
I could hard code it? Or am I to re-install all the integrations (Visonic Intruder Alarm + HomeKit Bridge) from scratch?KEEP_ALIVE_PERIOD
to 10
may improve responsiveness at the expense of the PROMBLEM
counter?Alarm Panel changed to Arming
event hasn't been produced on the second occasion?HomeKit logs
Hi,
The Ethernet Connector and the USB Connector on a 360 It's important that you understand this. The Ethernet connector and the Powerlink hardware behind it is the proper Powerlink connection. The USB that you're using is for an Installer to configure your panel without the pain of using the panels menus i.e. from a tablet or laptop.
The panel may not send "Panel Status" messages to the USB. The issue with the 360 is that the hardware inside has already enrolled (for the ethernet), I think this prevents the HA integration from enrolling via USB.
With the other PowerMaster panels (I have a PowerMaster 30 that I use to test) I can achieve full Powerlink and the response to sensors and commands are pretty much instantaneous. My Integration mimics the Powerlink Hardware Module so the panel thinks it's only got 1 Powerlink connection. Only the 360 and 360R panels have direct Ethernet connections and include the Powerlink hardware, all other panels just have an internal RS232 connector.
Powelink Enroll In the dev release that you have the integration gets to Standard Plus and then starts trying to Enroll as Powerlink See this in the log file "Sending Command (Auto-Enroll PowerMax/Master)" Your panel does not respond, hence you get the timeouts and the problem reports (and problem counter) See this in the log file " During Powerlink Attempts - Response Timer Expired " The dev release I have on test does not do this, for a 360 it gets to Standard Plus and then does not try to get to Powerlink. There should not be any problem reports. However, it will still not achieve Powerlink Enrolled functionality.
Panel Status Messages PowerMaster panels use a combination of A7 and B0 messages to provide Panel Status, are any of these in your log file? i.e. search for handle_msgtypeA7 and handle_msgtypeB0 I only think that the panel sends Panel Status data in Powerlink when Enrolled properly. But I'm not sure of this, take a look at your log files.
About Z04 setting the siren off If the system is "Arm Home" then Perimeter sensors will trigger the siren. Looking at one of your old logs, Z02 is Home Delay, Z03 is Interior and Z04 is Perimeter. Your Z04 is a PIR but is set up as a Perimeter sensor, that is why the siren went off (without audible countdown). I suggest that you change Z04 on your panel to an Interior Sensor I'm not sure why trying to Disarm from HA didn't work, I'd need a proper log file to check
About Problem Counter I'm working on it and have it on test for a few hours, I'll upload a dev release soon!
Home Assistant's account of the incident is kind of misleading I agree that it looks odd Again, I'd need a full debug log file to try and work it out
Neither HomeKit, nor Home Assistant have a record of the siren going off though. Home Assistant may not as it's not in Powerlink Mode.
Time The time is from the underlying operating system. In python I either use "datetime.now()" to get local time or use "datetime.utcnow()" to calculate time differences
Baud rate If the panel has been depowered for a while it defaults to 9600. The panel will only change baud rate if a special message is sent to it. All my code should default to 9600 unless told otherwise (If it doesn't then it's a bug!) However, with the 360 having internal Powerlink hardware, it may be messing with the baud rate
KEEP_ALIVE_PERIOD I'm working on it and have it on test for a few hours, I'll upload a dev release soon! My new dev release on test automatically sets it to 15
Why Alarm Panel changed to Arming event hasn't been produced on the second occasion I'm not sure, again I'd need a proper debug log file. At a guess, it may be because of the A7/B0 Panel Status messages
Why the integration is completely unaware of the siren's existence and its events? It is aware of the sirens existence but it doesn't create an entity in HA as the alarm control panel Entity includes that same functionality. In your old log file it had this "Mismatch PowerMaster Sirens 32 8" but it does not do anything with it anyway, this is just for information only. This is fixed in the dev release that I have on test, but it will not create a Siren entity.
Do Visonic panels produce an alarm event over PowerLink? Yes, but I say again that you get to "Standard Plus" and not Powerlink state
Hi, me again,
I've uploaded a new dev release to github, sorry it took so long, bank hol weekend is my only excuse
Could you summarise again the functionality that you get please, I can then decide whether or not to support the 360 panel and include it on the wiki.
If you include log files then I'll take a look
Thanks again for your help Dave
It's important that you understand this.
Thank you very much, @davesmeghead, for troubleshooting my incorrectly configured custom zone Conservatory! I was thinking of going to security installers forums or something. You are right, having it in a Perimeter zone type may make sense from installer's point of view. Especially if they never had a conservatory and didn't use to run to it in the morning, while having the silent keypad in an opposite part of the floor, next to the front door.
I can also confirm that the Installer Code, enabled by uncommenting if val.show:
has worked with AlarmInstall app on iPad, many-many thanks! I am slightly uncomfortable about this counter-intuitive app. I'll wait for another quality micro USB cable on order to arrive for testing with PowerMaster Remote Programmer for Windows.
From my memory of previous false alarms, once triggered, the siren was never quick to be silenced. Adrenaline could be a multiplying factor, of course, but the keypad -> panel -> siren kill chain consists of two wireless links. If panel doesn't operate on interrupts, but is rather polling its wireless estate every few seconds, the total delay may look far from instantaneous.
I've checked with all the logs ever produced:
handle_msgtypeB0
isn't happening in the past two days. Cutting off this channel may have been coincidental with the newer release of the pyvisonic.py
handle_msgtypeA7
has never been seen in my vicinityAccording to my current working theory, the latter deficiency is a result of a
The manual insists that GSM module is always present / always wins for reporting / notifications. Well, given the unit is out of contract, no central station reporting mechanism (GSM/telephone/broadband) is configured. The panel may potentially decide to stop emitting any reporting messages in the absence of any configured destinations. *```Report to Central Station: All Backup```** may become void as a result.
I've discovered a rather edge case scenario by activating panel's Wi-Fi access point to play with AlarmInstall: pyvisonic.py
gave up upon a few unsuccessful tries. Would it hurt to stay in the loop in a little hope the installer will finish abusing built in access point soon?
Hi,
What happens:
The HA Event at 08:30:29.854 is a bug and should not be there (it's a repeat of the first of the three).
So you have 2 options.
LAST_RECEIVE_DATA_TIMEOUT = 240
to keep trying "Get Status" for longer, I don't think that there are any other timeout gotchas in thereI'm not planning on altering the code for this so it's up to you
Hope that makes sense Dave
EDIT: and to show the installer codes in the alarm_panel entity attributes in the frontend (if using extended settings in the integration config) and in the Log File, set SDumpy = True
on line 698
I've upgraded the installation to the current dev version. The only change to the code was to enable SDumpy = True
. I also configured Master Download code this time around. There are no sightings of handle_msgtypeA7
though. Could it be that PM-360 is using a code different from A7
? Is there some serial sniffer I can use to dump the wire protocol?
There seem to be many changes in the code. I can spot some unfamiliar messages on the logs:
2024-06-02 10:52:15.771 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [Standard Mode] Entering Standard Plus Mode as we got the pin codes from the EEPROM (You can still manually Enroll your Panel)
Is (You can still manually Enroll your Panel)
a leftover, or shall I try to enrol manually?
This new version also seems to be picking up the siren more properly. I believe it shows up as S00
in Devices: K200,S00
. For the record, there is no such device as K200
. The keypad is KP-141
.
There is a sizeable block of Partition Data, marked as 'Not sure what it is'. Is the nature of this data totally unknown? Can anything of importance be stored over here?
Although every effort has been made to redact sensitive data, 1234
continues to be my credit card's PIN.
home-assistant_visonic_2024-06-02T21-25-06.841Z.log
PowerMaster Remote Programmer version 10.0.8 in my possession can work with PM-360 version 13.126.0 only. It refuses to connect to version 13.153.0. An attempt to clone / fake 'PM360 13_153.tdf' file has failed. PowerMaster Remote Programmer seems to have been de-published. This software is mentioned as the only means of resetting Master Installer Code which has been invalidated by ADT installers in my setup. Installer Code is working fine for configuration entries, marked as available only to Master Installer. Can Master Installer Code be reset programmatically?
Using AlarmInstall app to re-configure PowerManage server to tycomonitor has resulted in Visonic-Go app being able to deal with the whole setup remotely. Visonic-Go can read, see status and reports, arm/disarm, but it cannot modify any settings. BTW this integration has no knowledge of the reporting configuration 21:IP RCVR 1
. Is it not part of EPROM data?
AlarmInstall is painful to use, I might have made some unwanted changes by accident. PowerMaster Remote Programmer is so much more intuitive piece of software. Can this integration emulate control panel with all the buttons and status codes, by chance?
While in AlarmInstall, I confirmed that almost undocumented feature 80:3rd PARTY H.A
has been altered from default by my ADT installers. It reads as Enabled
. Nevertheless, connecting to PowerManage server hasn't resulted in Smart Home Server (Blue) light activation. Another Blue light, Service Server, seems to be active.
Given 21:IP RCVR 1/2
can be configured to use SIA reporting format, isn't it much easier to receive status updates via this API?
Hi, OK lots to go through here ... PowerMaster panels send msgtypeB0 and I can decode some of them but not all at the moment. If there's a message type that isn't known then I also display a message in the log file, there's no need to wire sniff as its all rs232 / UART protocols. I don't currently support partitions so it's just something I'm looking in to. You're right that I need to redact Pins better in the dev version. Can you enroll manually, if so then give it a try. To change master installer, go to installer menu and enter existing master code, and then change it. On installer menu you either enter installer or master code and that's what you then become. I'll have a look at the rest at the weekend when I get more time Dave
Thank you very much, @davesmeghead , for your patience and for accommodating my needs!
I'd suggest to add Visonic PowerMaster-360 to the list of supported panels and close this issue:
AlarmStatus
readings received every minute or so. When the Siren goes off, HA will not display any alertsI am happy to do some extra testing if necessary.
Serial port is exposed via micro USB connector at the back. USB device ID is 0525
:a4a7
. Most of the generic micro USB cables will fail to detect serial port. There would be a very few, capable of operating serial port while connected to PowerMaster-360. These cables will be the ones capable of talking to ESP32 devices using esptool
.
Receiving alerts via HA hasn't been part of the integration description. I have to confess it might have been my personal elevated expectation only.
PowerLink mode cannot be achieved with Visonic PowerMaster-360.
The panel has neither keypad, nor display built in. Unless a keypad with a display can be procured and installed, the other emulator alternatives are:
PowerMaster Remote Programmer
-- Needs to connect to the serial port, exposed via micro USB at the back. De-published by Tyco / Visonic. The software has to have a .TDF file corresponding to the panel's firmware versionAn attempt to enrol this panel as PowerLink manually didn't work.
The sequence INSTALLER MODE → 7. ENROLL PWRLNK → 01: INSTALL doesn't exist on PowerMaster-360. The nearest match is INSTALLER MODE → 07:DIAGNOSTICS.
The nearest meaningful alternative is INSTALLER MODE → 02:ZONES/DEVICES → ADD NEW DEVICES. At this point the panel is expecting wireless / wired thingy to be in adding mode. Integration cannot enter into the pairing mode because the serial port is occupied by AlarmInstall app. Exiting from AlarmInstall app makes serial port available, and it seemingly cuts off the pairing mode.
I don't have any experience of the PowerLink mode, so I cannot tell if PowerLink co-existence (#99) will bring any tangible benefits to the integration. If status updates is what we are after, it can be achieved via SIA format reporting option: https://www.home-assistant.io/integrations/sia/
To continue collaboration with a view to evaluate if PowerMaster can be added to the list of supported models.
HASS forum post Visonic PowerMaster 360: PowerLink, PowerG2, was marketed by ADT in the UK. Reportedly, factory reset doesn't give access to the installer / master installer codes.
NB PowerMaster 360 is different from PowerMaster 360R.
Repository has been forked and @davesmeghead 's instructions are being followed.