I upgraded today. Thanks for all new features!
I see there’s an option for multiple codes now, that’s just great…
# codes: #[OPTIONAL, list of names/codes] User specific codes.
# - name: gazos
# code: '6576'
# - name: enzo
# code: '8734'
…but it’s not implemented yet I assume?
Very promising anyway. Will there even be possible to track which code/name was used to disarm?
Hi gazoscalvertos, does the MQTT still function?
When I set the mqtt: True, i cannot open the Alarm Panel
My log shows:
Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File “/usr/lib/python3.6/asyncio/tasks.py”, line 180, in _step
result = coro.send(None)
File “/usr/lib/python3.6/site-packages/homeassistant/helpers/entity_platform.py”, line 258, in _async_add_entity
await entity.async_added_to_hass()
File “/usr/lib/python3.6/asyncio/coroutines.py”, line 210, in coro
res = func(*args, **kw)
File “/config/custom_components/alarm_control_panel/bwalarm.py”, line 672, in async_added_to_hass
return self.mqtt.async_subscribe(
AttributeError: ‘NoneType’ object has no attribute ‘async_subscribe’
and:
https://my web site/frontend/panels/alarm-04cb8e8210cbe9d98093bb2898610b63.html:272:34 Uncaught TypeError: Cannot read property ‘attributes’ of undefined
I’m running Hass.io 0.65.6 on RPI3. It was working on the previous version of the Alarm.
Thanks!
Sorry folks there’s clearly an issue with MQTT I’ll work on a fix today. In the mean time you could too back to a previous version
install it 2 days ago works f in alsum
2 problem
NO clock
after reading the alarm.html I see what missing
FIX MUST HAVE sensor.time
and
tryed out the MQTT bit no go alarm panel did not display
yes I have MQTT working on all 10 of my Sonoff’s
will look into it tho
Thank for all the hard work you have done
think it took me longer to read this than intall it
did you put some sensors ??
immediate:
- sensor.Garage_Door
- sensor.Garage_Side_Door
in the alarm.yaml
Hello i just updated today to last version and it’s seems to be broken for me too.
I’m using MQTT and here are my errors codes:
2018-03-27 12:32:11 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/lib/python3.6/asyncio/tasks.py", line 180, in _step
result = coro.send(None)
File "/usr/lib/python3.6/site-packages/homeassistant/helpers/entity_platform.py", line 258, in _async_add_entity
await entity.async_added_to_hass()
File "/usr/lib/python3.6/asyncio/coroutines.py", line 210, in coro
res = func(*args, **kw)
File "/config/custom_components/alarm_control_panel/bwalarm.py", line 672, in async_added_to_hass
return self.mqtt.async_subscribe(
AttributeError: 'NoneType' object has no attribute 'async_subscribe'
2018-03-27 12:39:16 ERROR (MainThread) [frontend.js.latest.201803100] http://192.168.0.29:8123/frontend/panels/alarm-04cb8e8210cbe9d98093bb2898610b63.html:272:34 Uncaught TypeError: Cannot read property 'attributes' of undefined
I suppose it is also related to MQTT.
Good luck for the fix and thanks again for the great feature.
A word of warning regarding default trigger_time: 600
If you use a cheap piezo siren, it might die halfway through that period of time as mine did.
Keep it in mind and either test your siren or decrease trigger_time .
Ok folks, updated code on the repo.
(28/03/18) Major Update - Moved the entire codebase of the panel (alarm.html v1.1.0) over to Polymer2 so that translations can be included in the next release and the panel can be integrated into the HA codebase at some point once its ready. Please note that depending on your browser you will likely need to set the javascript version to the latest version using the config below. I don’t know how this will effect older browsers but this has been tested on a Samsung Galaxy Tab 10 (Original), S7 Edge, Iphone 6, Firefox, Chrome
#CONFIGURATION.YAML
frontend:
javascript_version: latest
(28/03/18) BUG FIX - MQTT issue not working resolved (bwalarm 1.0.2)
(28/03/18) BUG FIX - Re-included ignored sensors (Panel 1.0.1), (Bwalarm 1.0.2)
(28/03/18) UPDATES - Began to clean up panel css file to enhance firefox/opera support. Let me know if there are still issues. A browser cache wipe will be required (alarm.css 1.0.1)
(25/03/18) BUG FIX - Moved comments line above the actual config to resolve the hassio issues
(25/03/18) BUG FIX - Fix to resolve slidebar constantly opening when using mobile devices (Panel 1.0.1 / Bwalarm 1.0.1)
Thanks a lot for the new version!
Very nice code cleanup and everything I tried so far, including MQTT, seems to work fine!
I have been struggling to get your nice alarm working together with @thanksmister MQTT Alarm Panel. Today I finally got it to work as I want - to have the MQTT Alarm Panel show a countdown with beeps after the alarm is triggered. It seems the term is “delay_time”.
As I understand it now, in the manual_mqtt alarm panel, the pending_time is used “when you are on your way out” to be able to leave without tripping the alarm.
And delay_time is used “on your way in” to be able to disarm before hell brakes loose.
But those two parameters activates different MQTT states. Or something. They makes the MQTT Alarm Panel to behave differently anyway 
The pending time between Disarmed > (Pending Time)> Armed Away activates a visual countdown.
The pending time between Armed Away > (Delay Time) > Code > Disarmed activates a keypad and visual countdown + beeps.
In your alarm, the pending_time seems to be used both “on your way out and in”. Which seems to means that the alarm never enter the MQTT state where the delay_time is used, i.e. you never get the countdown in MQTT Alarm Panel.
So…
delay_time for some reason?delay_time (I confess, I haven’t tried)?Thanks!
Am I on the right track here or have I misunderstood the whole thing?
Defo on the right track!
Have you have left out delay_time for some reason?
To be honest I had plans on splitting pending time into two as you have described.
The Manual MQTT sets it state as Pending not Warning when a sensor is tripped. I’ll add an option to override MQTT warning state to support this.
I had to look into your bwalarm.py code today as I needed access to trigger_time for my external python script.
In device_state_attributes function for some reason you a) export pending_time as countdown_time and b) do not export trigger_time.
Just an observation.
I still use an old version and don’t know if you have change it since…
Hi @gazoscalvertos first of all a big thank you for all your work on this great project!
Last night I upgraded to your latest version but I think something is broken with the pending_time on ‘arned_home’ mode. When this morning the ‘delayed’ sensor was triggered (whilst in armed_home mode) the alarm went off immediately, I did not override the ‘global’ pending_time for armed_home but now it seems there is no grace time anymore when triggering the delayed sensor.
As a workaround I put the pending_time on armed_home mode to 25 seconds as well and now I do get the grace time when triggering the delayed sensor. However I also now have the grace time when turning the alarm on in home_mode. Not a big deal but so you’re aware
For reference hereby the 1st part of my alarm.yaml:
platform: bwalarm
name: House
alarm: automation.alarm_triggered
warning: automation.alarm_warning
##[CODE RELATED]
#[REQUIRED] Master Code, should consist of one or more digits ie '6482' ensure your passcode is encapsulated by quotes
code: !secret alarm_code
#[OPTIONAL] Panic Code should consist of one or more digits ie '9876' ensure your passcode is encapsulated by quotes, it needs to be different to your standard alarm code. This enables a special panic mode. This can be used under duress to deactivate the alarm which would appear to the unseeing eye as deactivated however a special attribute [panic_mode] listed under the alarm_control_panel.[identifier] will change to ACTIVE. This status could be used in your automations to send a notification to someone else police/spouse/sibling/neighbour that you are under duress. To deactive this mode arm then disarm your alarm in the usual manner.
panic_code: !secret panic_code
#[DEFAULT] Grace time in seconds to allow for exit and entry using Away mode
pending_time: 25
#[DEFAULT] The amount of time the alarm stays triggered before returning to its previous state
trigger_time: 300
##[STATE RELATED]
#[OPTIONAL]
#armed_perimeter:
# ##[OPTIONAL however either an immediate or delayed group must exist] Sensors in this group tigger the alarm immediately
# immediate:
# - binary_sensor.garage_door
# - binary_sensor.back_door
# - binary_sensor.kitchen_motion
#[REQUIRED]
armed_home:
#[OPTIONAL] State specific overrides default time above
#pending_time: 25
#[OPTIONAL] State specific overrides default time above
#trigger_time: 300
##[OPTIONAL however either an immediate or delayed group must exist] Sensors in this group trigger the alarm immediately
immediate:
- binary_sensor.eetkamer_sensor
- binary_sensor.woonkamer_sensor
##[OPTIONAL] Sensors in this group start the clock (pending_time) when tripped before the alarm is triggered
delayed:
- binary_sensor.bijkeuken_sensorWork in progress on themes, this is the dark one. I want to be able to switch between light and dark depending on time. Let me know what you think.
Still a couple of things to sort, i.e caps on alarm state, colour on weather svg etc
Thanks will rectify this in next release
This is really nice. Getting better and better. Thank you so much.
Like it a lot.
Looks great!
I’m not a designer, but would suggest not to mix different fonts on one screen (namely, temperature and weather conditions).
Is the keypad still moves when one starts entering a code? I saw someone else mentioning it, and it’s really annoying feature… :\
Keypad is now fixed in place
