I am also noticing that there is no ‘tick’ to the right of the ‘Enable MQTT’ setting. What file are these settings saved in? Can we edit that? I need to finally try and get my MQTT alarm interface working
If you are on 0.100 and up you can copy my panel.html (https://github.com/tech165/Hass-Custom-Alarm/blob/ea4d2fbc00d6e4eb3590c897e486bf9ab5f66368/custom_components/bwalarm/resources/panel.html) file and I will work as a temporary solution.
Thanks. I guess I should finally switch to HACS because I don’t even have a ‘resources’ folder…
HACS works really good. I think before panel.html was located in www but I’m not sure …
Well I installed HACS and then this alarm component but I still can’t set the MQTT on. Also, when I type in the MQTT topics in the GUI, they don’t seem to save and are back to default after a HA restart. Any ideas?
Have you cleared your browser’s cache? And is your bwalarm.yaml (the file with all config settings that you actually can edit manually if GUI doesn’t work) in <HA config folder>/resources/bwalarm/ ?
yep, the tickbox still isn’t there next to the enable MQTT setting
I dont have a bwalarm.yaml
it will only appear if you replace your panel.yaml with the one from here OR in your existing one replace ALL paper-toggle-button entries with mac-switch
then you really have to follow the installation instructions to get your integration to work as expected.
And actually you should have bwalarm.yaml, most likely in your <HA config> folder…
Ok, it turns out I do have the file, I was just looking in the wrong place. I think the instructions for this could be improved a little. It took me realising that we are dealing with resources inside the custom_components folder, and resources inside config folder 
Hi, do you there will be a possability to see some sort of tutorial during october?
Well, I know it’s not ideal to have config files separately but that’s the way HACS works afaik - in essence, it deletes old files and downloads all new files from GitHub when a new version arrives.
That way you always get a new version and not a mixture of new/old files to avoid any issues. On a flip side, you cannot have anything that is different to the repository in that folder, that’s why I moved the config file somewhere else.
I’m not saying it’s ideal and I’m thinking about alternatives.
In the meantime, feel free to edit the instructions/create a pull request here to improve the instructions, it’s open to everyone and they will be grateful!
Sure. I put it on my todo list and will make an announcement when it’s ready.
Grateful for your time and hard work. Thanks!
Do you have any idea what this error message in the home assistant log means?
[settings_yaml_save] state armed_home: check_before_arm found, remove before saving
I think it might have been because I was moving a sensor from immediate to delayed but forgot to take it out of the immediate list before selecting it in the delayed list. Could that cause it?
Don’t worry about that, should be a debug message as it just removes any internal structures before saving them into yaml file.
Already fixed in dev branch.
1 Like
Hi there, I’m trying to configure mqtt to disable alarm. From what I understand, the payload should be “DISARM 0000” (assuming disarm is my disarm payload and 0000 is my code). This doesn’t seem to be working for me. In my log, I see:
[custom_components.bwalarm.alarm_control_panel] [message_received] Exception: Extra data: line 1 column 2 (char 1)
and:
[custom_components.bwalarm.alarm_control_panel] [message_received] Failed to DISARM: passcode required
Thanks for any advice!
My advice is to set log level for this integration to warning and you’ll get more diagnostics.
Version of your installation is important as well.
To the point, MQTT messages should be in JSON form, i.e I’d say something like this should work:
DISARM {"code": "0000"}
Thank you. Your solution worked perfectly. Cheers!
1 Like
Has anyone been in a similar situation when disarming the alarm from the panel:
You enter your house, disarm the alarm and start doing your business and then after a short while it triggers so you have to disarm it again?
I noticed that sometimes when you disarm it, you might make one extra tap (as it takes time for the panel to update its status) and somehow it translates into tap on ARM button - at least in such cases I can see the following sequence of events:
Disarmed -> Armed Away -> Warning -> Triggered -> Disarmed
The delay between the first two evens is a couple of seconds more than pending_time.
I’m thinking of adding a simple debouching code (that can be switched on/off) to prevent setting the alarm within say, 10 seconds from disarming.
Any thoughts on this?
I haven’t had any issues with that, but I can see how that could happen and be an issue. I like the idea of adding debouncing code.
On another note, do you track the issues on github for this? I was thinking about seeing if I could help out with the issues/feature requests, but it seems there are some old entries and it doesn’t look up-to-date to me.