I just updated to 0.12.5.2. After the update, it restarted after an unusual amount of time (Disconnection Count: 3) and reported the prior version (Client Version: 0.12.5.1).
I performed a second restart and it started more quickly (Disconnection Count: 2), reporting the correct version.
FYI, I have a PowerMaster 10.
Thank you, thats massively helpful, based on this diagram my connection are correct and once i setup the integration i see the below in my esp logs
[08:43:41.324][D][uart_debug:113]: >>> 0D:0B:F4:0A
[08:43:42.816][D][uart_debug:113]: >>> 0D:24:00:00:56:50:00:00:00:00:00:00:35:0A
[08:43:47.827][D][uart_debug:113]: >>> 0D:0F:F0:0A
[08:43:49.319][D][uart_debug:113]: >>> 0D:0B:F4:0A
[08:43:50.828][D][uart_debug:113]: >>> 0D:24:00:00:56:50:00:00:00:00:00:00:35:0A
[08:43:55.839][D][uart_debug:113]: >>> 0D:0F:F0:0A
[08:43:57.348][D][uart_debug:113]: >>> 0D:0B:F4:0A
[08:43:58.840][D][uart_debug:113]: >>> 0D:24:00:00:56:50:00:00:00:00:00:00:35:0A
[08:44:01.742][D][stream_server:093]: New client connected from 19
[08:44:02.749][D][stream_server:175]: Client 19 disconnected
[08:44:03.859][D][uart_debug:113]: >>> 0D:0F:F0:0A
[08:44:05.351][D][uart_debug:113]: >>> 0D:0B:F4:0A
As far as i understand this has to do with enabling powerlink / bba option on the panel itself.
has anyone else had to do this as well?
It sounds like you’ve had a partial upgrade, some of the files have taken a while to become available and restarted too early. Do you use HACS as I’ve found this problem myself? Is it working OK now? What happens if you restart it again?
EDIT: Thinking about it a bit more, to make sure I’d clear out the files in the visonic directory and make sure that the new version files are put there.
That’s still not working, that debug is showing:
You still do not have Rx and Tx connected correctly, are you crossing-over Tx and Rx for example, Rx on the ESP32 goes to Tx on the panel and vice-versa
on the back of my esp it says tx is yellow , rx is white and black is ground . I connected to the panel based on this and the diagram posted above
so tx(yellow) on esp → rx on panel
so rx(white) on esp → tx on panel
black ground → panel ground
I heard that there may be an option that needs to be enabled in the panel installer options ? powerlink/bba could this be the reason the connection attempts by the integration are being rejected?
A couple of observations…
It looks like it’s wired correctly, the only thing I’d try is moving the black ground to the other ground pin, next to the current white so all 3 wires are in a row. I don’t think it will make a difference but you never know
For a PowerMaster 10 you do not need to change any setting in the panel. You would only need to do something for early PowerMax panels.
The problem could be about voltage levels, @pocket knows more about this. The panels voltage levels for the RS232 is 3.75v (I think), your ESP32 is probably TTL 5v levels. You might need a voltage level shifter putting in. These are fairly cheap to buy, a couple of pounds/dollars, but to wire them you’ll need a voltage supply from each side i.e. the voltage from the panel connector is easy but you’ll need the 5v voltagesupply from your ESP32 device, this might be more tricky. Like I said @pocket will know more about this kind of thing.
EDIT: here on my wiki
just so we’re on the same page this is the guide i ve been using in the wiki, bought the parts listed here
It looks like there are 5 and 3.3 voltages are available, but I need to dig a little deeper into the M5Stack schematic. What’s clear in the specifications is the Tx and Rx signals are at 3.3 volts.
This is the basic idea for translating the voltage levels. There are modules available to do this:
I’ll try to spend some time with it over the next day, or so. In the interim, find a local source for the level translator.
Edit: Since there are only two lines needing translation, look for a module that only has two translators. A quad translator will work fine, but the inputs of the spare I/Os might need to be grounded to avoid the extra currents a floating inputs will create.
Here’s what I suggest. It’s a best-effort approach to the assumption that your problem is due to different logic levels. The design is partially based on an observation of the alarm panel having pins that provide 3.75 volts. The Schottky diode forward voltage is enough to bring the output close to 3.3 volts. The ESP32 box has a 5 V output on the UART connector.
The approach is based upon a part type (Texas Instrument TXB series) using very little current. I’m assuming both the ESP and the alarm panels supplies can handle the task. Like most similar devices it uses CMOS technology and is sensitive to electrostatic discharge. I use a wrist strap connected to a local ground.
You should check to see pins shown provide 3.75 volts on your alarm panel. If it doesn’t, you can use a LDO analog regulator for the 3.3 volts. You might also look for a small project box to house the translator and diode if it doesn’t comfortably fit in the alarm panel.
Edit: Corrected paths for A1 and A2 with the interface device.
i see, thank you very much for looking into this.
If you saw my original post, you might as well disregard it. I’ve reverted back to Core 2026.2.3 and Supervisor 2026.02.3, then created a fresh download from HACS. Here are my observations:
It takes 3 minutes for entities to populate, with Disconnection Count: 2.
Attribute Client Version: 0.12.5.2 is reported, but Version 0.12.5.1 appears in the integration dashboard.
Am I doing something wrong? Is there still a chance ‘invalid handler specified’ will be reported on new downloads with Core 2026.3?
Edit: Added Dropbox link:
Log capture
Edit_2: Updated Core to 2026.3.1 and the above observations remain.
Hi Rob, first of all apologies for taking a long time to look through this.
I’ve looked through the log file and I’ve spotted a few things that I can improve on for a serial/USB connection, some timings and timeouts. Most of these are to do with swapping baud rates automatically between 9600 and 38400. I’m guessing that on the run before this log file was captured it changed your panel to 38400. When this log file starts it does not know the panel type so tries 9600 first, but then it waits 2 minutes to swap to 38400, this is too long. It then changes to 38400 and communication with the panel starts (around 51:49 time). It gets the EPROM data and then tries to change the panel to 38400, when it already is in 38400!
But there’s one particular “feature” 
that I need to consider a bit more. When the baud rate is changed I close down the connection before creating another. With your specific system the underlying driver does not report that the connection has been closed, and I wait for this. That is why you have lots of “Waiting for protocol handler to close” log entries. So I probably need a timeout on this as well. I do test a USB connection to my test panel and it works but I use the HA dev environment on WSL ubuntu on top of windows. I assume that you probably have a different environment and that does not seem to report that the connection has been closed.
Like I said, a few things to work on.
EDIT: For anyone else reading this, this is only applicable to Powerrmaster panels that use USB/serial connection to the panel.
No apologies necessary, particularly when the alarm integration is still working.
To be honest, I didn’t know it had the capability to pass data at that rate.
I’m running HAOS on a generic-x86-64 box (an ODROID). Perhaps you can submit an HAOS issue requesting the OS to behave like the dev environment.
Lastly, there’s still the cosmetic issue with the integration dashboard that led me down the path of fussing with the HACS download.
Yeah, version 0.12.5.1 appears in the dashboard because I forgot to change the version number in the manifest file (manifest.json) when I created the release, oops. I should have changed it to 0.12.5.2 the same as the code. My bad.
For you and anyone else interested… PowerMaster 10 and 30 panels can use 9600 and 38400 baud. If a panel has been powered off for a while then it defaults to 9600. I worked out the command to send to the panel to get it to change the baud, but of course we then need to change the baud of the device we’re using in a coordinated way. I can currently do this with a “select” Entity that I can create in ESPHome (for ethernet connections) and obviously changing USB/serial is much easier. For other ways of connecting there’s no way to do it.
38400 baud is necessary to get PIR Camera sensor images downloaded, with 9600 it just times out and can’t get the data through fast enough, that’s why I’m trying to support it. Although the images aren’t that good so i’d suggest a proper camera setup rather than using the PIR Cameras from visonic.
This is all why in the past people have had trouble connecting and working out the baud rates, if they have had a powerlink hardware module installed and then use our gadgets to connect then the panel could be left at 38400 but no guarantees, and if it’s powered off completely for a while then when next powered it defaults to 9600.
Forgot to say, I don’t think that it’s the dev environment that’s the issue, I think it’s the underlying driver and I’d rather make sure it works in either conditions anyway, so I’ll look to fix it.
Hi, release 0.12.5.3 just uploaded to Github with a few very minor changes for PowerMaster panels using USB/serial connections. It’s not a HACS release yet, @pocket can you please give it a go first, thanks.
I’ve just spent some time looking through your git and have yet to find release 0.12.5.3. The latest one I see is 1.12.5.2. Can you provide me a link?
Hi, you’ll need to click on the green “code” and then “download zip”
davesmeghead/visonic: Visonic Custom Component for integration with Home Assistant
I hope this helps:
OK thanks for the log file, but that made it worse 
Can you try release 0.12.5.4 please, I’ve just uploaded it to github.
It should fix the bug but it also saves the last working baud rate. When a panel is added through the config the baud rate is set and then cannot be changed by the user (it is not shown again, even when editing the settings). I use the initial setting from the user but then for PowerMaster panels using serial, as it’s fairly easy to achieve, I try to get to 38400 baud as the connection is much more reliable and for users with PIR/Camera the images can be retrieved. So I over-write the baud rate setting with the last baud rate attempted. So on restart it first tries the last one used from the previous run (rather than the user set baud rate).
It looks like it’s working at 38.4k baud.
FYI, second restart started at 38400.
2026-03-12 12:04:22.153 DEBUG (MainThread) [custom_components.visonic.client] P0 Comms Device Type is usb
2026-03-12 12:04:22.167 DEBUG (MainThread) [custom_components.visonic.client] P0 Creating USB Connection path='/dev/ttyUSB1' baud=38400
2026-03-12 12:04:22.167 DEBUG (MainThread) [custom_components.visonic.client] P0 Creating USB Connection, the coro type is <class 'coroutine'> with value <coroutine object create_serial_connection at 0x7f85a14ace80>
2026-03-12 12:04:22.211 DEBUG (MainThread) [custom_components.visonic.client] [ClientVisonicProtocol] connection_made Whooooo
Thanks!