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.
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 .
(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
(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…
Am I on the right track here or have I misunderstood the whole thing?
Have you have left out delay_time for some reason?
Or maybe it already works to use delay_time (I confess, I haven’t tried)?
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_sensor
May I ask regarding the code related option from previous version, I saw you have put extra code for multi user (not working yet).
In this latest version, you have remove this extra code for multi user.
Will it be possible to have this multi user option code in next release version or ?