Bwalarm (akasma74 edition)

Good point !!
I don’t :slight_smile:
It happened to me yesterday and I had to go the bwalarm panel.
I have built a nodered panel and I don’t use bwalarm panel nor alarm panel from HA.
So sending the “open sensors” in MQTT et being able to force using MQTT message would be cool.

GV

@onkytonk, @greengolfer what’s your use case?
Currently it’s possible to change how the alarm treats open sensors when arming using service calls, check this document.
Speaking about MQTT - only arm_xxx and disarm commands are supported at the moment, but it’s possible to extend if needed, just need an idea what’s required.
I’m not quite sure but I might add an attribute that can be checked (something like `alarm_control_panel.house.attributes.active_sensors) - actually, it should be a dictionary for all enabled arm modes. Don’t know if it would help, any thoughts?

It is about sensors that prevent the alarm to be activated (so not the override ones). As I am not using the bwalarm panel, I am sending the MQTT code to arm from another UI.
When a sensor is “open” then arming fails. It would be good to received an MQTT message saying why (eg sensor X is open). At the moment, from my nodered UI it just fails and I have to looks at the bwalarm interface to know why.
Does it make sense? I am not sure how to explain this properly…

GV

That’s absolutely clear.
One of the workarounds is to watch the alarm’s state for a set period of time after issuing an arm_xxx command so if it’s not armed, you show a warning or something (as described here). However, it doesn’t tell you why/what sensor is active.

I can add code to send MQTT message if a MQTT command fails but what would you do if you receive no message at all?

I don’t understand “if you receive no message at all”? At the moment, when I publish eg. “ARM_AWAY” is receive a message giving me the new state (eg pending). What you be good would be to receive “fail” and ideally why (sensor x is open).

GV

Hey AhmadK, will the changes to the manual alarm panel in the 0.110 release affect this custom component?

Breaking Changes

  • Manual Alarm Panel - When going from state disarmed to any other (armed) state such as armed_away , the state will be arming instead of pending during the transition time as set in the configuration. When going from an armed state (such as armed_away ) to the triggered state the state will still be pending during the transition time as set in the configuration (as it was before). - (@starkillerOG - #32950) (manual docs )
    • State attribute pre_pending_state changed to previous_state
    • State attribute post_pending_state changed to next_state
    • Configuration option pending_time is renamed to arming_time , functionality is the same.
    • The time the alarm stays at pending when triggered has changed from delay_time of the previous state + arming_time (previously known as pending_time ) of the triggered state to only the delay_time of the previous state.

Updated to 0.110.

“AlarmControlPanel is deprecated, modify BWAlarm to extend AlarmControlPanelEntity”

This has come up as an error in my log. Any ideas?

i think the integration Needs to be updated based upon the post by tom above yours

Yeah, I figured as much.

If there are open sensors, there will be no pending, right? No state change, nada :wink:

I’ll think about the good way of doing that.

@tom_l very likely so I’d advise to postpone updating (but it’s easy to roll back).
Will look into it soon. Actually, this component is based on AlarmControlPanelEntity and is a sibling of Manual Alarm Panel. Therefore in theory the above mentioned breaking changes should have no impact but I haven’t updated yet so cannot guarantee.

1 Like

Hi @onkytonk,

I use an Alexa Routine to Arm the alarm via a node red flow which checks if the sensors are open except for the override sensors. i.e Front Door, Hallway Motion. I do this using a Group that lists all the sensors apart from those I want to override. In node red i check the state of that Group. If it is on then at least one sensor is open and the alarm will not Arm and Alexa responds with which sensors are open. If the Group is off then I know all sensors apart from the override sensor are off and then the alarm will Arm. Here is the Node Red flow I use:

[{"id":"e611d8f0.cde5f8","type":"tab","label":"Flow 4","disabled":false,"info":""},{"id":"4d50ac10.aded9c","type":"template","z":"e611d8f0.cde5f8","name":"Format Friendly Name","field":"payload","fieldType":"msg","format":"handlebars","syntax":"mustache","template":"{{payload.attributes.friendly_name}}","output":"str","x":880,"y":200,"wires":[["ef57d024.41c9c"]]},{"id":"ef57d024.41c9c","type":"join","z":"e611d8f0.cde5f8","name":"","mode":"custom","build":"string","property":"payload","propertyType":"msg","key":"topic","joiner":",","joinerType":"str","accumulate":false,"timeout":"","count":"","reduceRight":false,"reduceExp":"","reduceInit":"","reduceInitType":"","reduceFixup":"","x":1070,"y":200,"wires":[["6eb9023a.f31fdc"]]},{"id":"7986cb1c.fce2f4","type":"ha-get-entities","z":"e611d8f0.cde5f8","name":"","rules":[{"property":"entity_id","logic":"is","value":"binary_sensor\\.((?!kitchen_door|study_door)(.*door.*)|(.*window.*))","valueType":"re"},{"property":"state","logic":"is","value":"on","valueType":"str"}],"output_type":"split","output_empty_results":false,"output_location_type":"msg","output_location":"payload","output_results_count":1,"x":690,"y":200,"wires":[["4d50ac10.aded9c"]]},{"id":"57a90e4a.a29cd","type":"api-call-service","z":"e611d8f0.cde5f8","name":"Alexa Sensors Open TTS","version":1,"debugenabled":false,"service_domain":"notify","service":"alexa_media","entityId":"","data":"{\"message\":\"Please close {{payload}} , then say, Alexa Goodbye, to set the alarm to away\",\"data\":{\"type\":\"tts\"},\"target\":[\"{{lastalexa}}\"]}","dataType":"json","mergecontext":"","output_location":"","output_location_type":"none","mustacheAltTags":false,"x":1430,"y":200,"wires":[[]]},{"id":"6eb9023a.f31fdc","type":"change","z":"e611d8f0.cde5f8","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload.data.message","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":1220,"y":200,"wires":[["57a90e4a.a29cd"]]},{"id":"d0d0a226.7462a8","type":"api-current-state","z":"e611d8f0.cde5f8","name":"State of Alarm Sensors","version":1,"outputs":2,"halt_if":"on","halt_if_type":"str","halt_if_compare":"is","override_topic":false,"entity_id":"group.alarm_away_sensors","state_type":"str","state_location":"","override_payload":"none","entity_location":"","override_data":"none","blockInputOverrides":false,"x":490,"y":220,"wires":[["7986cb1c.fce2f4"],["32dec8d4.9935d"]]},{"id":"82ab5371.362fb","type":"api-call-service","z":"e611d8f0.cde5f8","name":"Arm Away","version":1,"debugenabled":false,"service_domain":"alarm_control_panel","service":"alarm_arm_away","entityId":"alarm_control_panel.house","data":"","dataType":"json","mergecontext":"","output_location":"","output_location_type":"none","mustacheAltTags":false,"x":1430,"y":260,"wires":[[]]},{"id":"9bde7dd0.f6221","type":"server-state-changed","z":"e611d8f0.cde5f8","name":"Alarm Goodbye","version":1,"exposeToHomeAssistant":false,"haConfig":[{"property":"name","value":""},{"property":"icon","value":""}],"entityidfilter":"script.1564690605365","entityidfiltertype":"exact","outputinitially":false,"state_type":"str","haltifstate":"on","halt_if_type":"str","halt_if_compare":"is","outputs":2,"output_only_on_state_change":true,"x":120,"y":220,"wires":[["d043a31f.5b9cc8"],[]]},{"id":"32dec8d4.9935d","type":"api-call-service","z":"e611d8f0.cde5f8","name":"Alexa Goodbye","version":1,"debugenabled":false,"service_domain":"notify","service":"alexa_media","entityId":"","data":"{\"message\":\"All Windows and Doors are closed, Goodbye\",\"data\":{\"type\":\"tts\"},\"target\":[\"{{lastalexa}}\"]}","dataType":"json","mergecontext":"","output_location":"","output_location_type":"none","mustacheAltTags":false,"x":700,"y":240,"wires":[["14a603a2.6655b4"]]},{"id":"af34d1e5.804f1","type":"delay","z":"e611d8f0.cde5f8","name":"","pauseType":"delay","timeout":"3","timeoutUnits":"seconds","rate":"1","nbRateUnits":"1","rateUnits":"second","randomFirst":"1","randomLast":"5","randomUnits":"seconds","drop":false,"x":1140,"y":260,"wires":[["82ab5371.362fb"]]},{"id":"14a603a2.6655b4","type":"api-current-state","z":"e611d8f0.cde5f8","name":"State of Vacum","version":1,"outputs":2,"halt_if":"docked","halt_if_type":"str","halt_if_compare":"is","override_topic":false,"entity_id":"vacuum.victor_2","state_type":"str","state_location":"payload","override_payload":"msg","entity_location":"data","override_data":"msg","blockInputOverrides":false,"x":900,"y":260,"wires":[["af34d1e5.804f1"],["36edc3a2.f1e194"]]},{"id":"36edc3a2.f1e194","type":"api-call-service","z":"e611d8f0.cde5f8","name":"Arm night","version":1,"debugenabled":false,"service_domain":"alarm_control_panel","service":"alarm_arm_night","entityId":"alarm_control_panel.house","data":"","dataType":"json","mergecontext":"","output_location":"","output_location_type":"none","mustacheAltTags":false,"x":1140,"y":320,"wires":[[]]},{"id":"d043a31f.5b9cc8","type":"api-render-template","z":"e611d8f0.cde5f8","name":"LAst Alexa","template":"{{ states.sensor.last_alexa.state }}","resultsLocation":"lastalexa","resultsLocationType":"msg","templateLocation":"template","templateLocationType":"msg","x":290,"y":220,"wires":[["d0d0a226.7462a8"]]},{"id":"ec85d738.90de18","type":"comment","z":"e611d8f0.cde5f8","name":"........................  Goodbye Script and Check Windows and Door Sensors  ........................","info":"","x":344,"y":151,"wires":[]}]
1 Like

Thanks for this. I never really found a use of the “group” feature. Now I do !!

GV

You are right. It is easier to react when receiving a message than not receiving it. I was am lazy :slight_smile:

GV

Should be a warning. The main issue is with icons (at the bottom, for example), they’ve gone.
Unfortunately, no mention in the release notes about what exactly we need to do to fix it… pita :frowning:

Could it be do to the custom-ui not being supported anymore?

I’m not home right now so can’t look into it myself right now.

if you check the link you posted yourself, you can see it has been solved :wink:

doh, thanks. my bad

just be be precise: the custom-ui issue on Ha 110 has been solved, not the issue of this topic or other mentioned issues (at least not that I know of …)

this component does not use custom-ui.
I presume it’s something to do with the optimisation of loading MDI icons - this code correctly displays all sensors’ icons, for example, but does not display any icon that is not used somewhere else in LL interface.
Looking into it now.

I’ve seen the solution in another custom component’s issue but am having trouble finding it. Will post it here if I do.

Edit: does this help:

https://github.com/kalkih/mini-media-player/issues/297

1 Like