@AhmadK He is saying that the script for disarming is taking too long and therefore the alarm is going into warning due to sensors tripping when it should have already been disarmed.
@daneboom What do you have in your disarm script? Something in there must be seriously slow…
No, I think you’re misunderstanding - as @sparkydave says (and I said 
) these are events that are happening WHILE my disarm script is running.
Script looks like this
alarm_disarm:
sequence:
service: alarm_control_panel.alarm_disarm
entity_id: alarm_control_panel.house
data:
code: xxxxx
Could it be my hardware? Raspberry Pi 3
That should still disarm fairly well instantly. That was my old hardware and I didn’t have the issue you are facing
BWalarm, breaks in 0.115 with something to dp with html_url when registering the panel
Reported when the original deprecation notice came out. Akasma has stated he is investigating alternatives.
To be precise, I’m aware of the deprecation thanks to you guys but my investigations were (and will for a bit) far away from HA.
On top of that, Baloobs statement “who created HTML panel can create JS panel” is good and stuff but I honestly don’t know where to start.
So my advice at the moment is not to update HA to 0.115 or higher if you want to use this component.
Do you have any idea on when you might have the component updated to be compatible?
He did say far away so i wouldn’t expect it soon.
I am so grateful for all the hard work of those behind most open source projects. I don’t understand why some feel the need to be rude and/or demanding of these guys that share their projects with us often asking little if anything in return.
It is a bummer that it stopped working on .115 hopefully he can get it working again soon, and maybe those that say anyone that does it on HTML can do it on JS panel perhaps they can roll up their sleeves and work on the fix.
No one was being rude. We were discussing contingencies to allow the dev time to work on a solution. I asked a mod to split it into another topic.
I’ll definitely have more time from next week so there is much more hope 
Does making a release that does not register the panel make sense as an interim fix (as some already did)?
that was Paulus so I really doubt he will work on it, ever
It seems to work well from what I can tell and is very easy to do (see split topic). I think it would be worthwhile.
yeah, in fact the alarm itself can easily function on its own, the panel brings nice things like overriding sensors on arming and changing settings.
I have been thinking for a long time about splitting them in the light of depreciation of html panels and converting it to LL… will see.
@Ahmadk, please do not think your obliged to make it work, if RL is where you need to spend time, then please do. At the moment it works perfectly fine using the built in alarm panel. so no need to rush
I think one of the original driving factors behind this integration was that fact that we didn’t have the power to easily create a custom card with the old states menu and the html panel was put up in its place. Now we have Lovelace replacing it with either a custom card (or built in ones) certainly bears thinking about. I’d wait until the current lazy loading issue is sorted out though.
Yes please, as long as I can enable/disable with an automation would be great as interim.
I don’t quite get what you mean… 8()
I decided to try to transition to the manual alarm_control_panel, while waiting on the bwalarm update. It requires a bunch of automations, and more config, but in the end it does most of what I needed from bwalarm.
I made a custom Lovelace card (based on the earlier Lovelace alarm panel card), which works with the manual alarm_control_panel, and tries to reproduce the nice appearance of the bwalarm GUI.
I posted the modified card and my entire config, with automations, explanation, etc at: https://github.com/jcooper-korg/AlarmPanel
Here are some screenshots:
