Bwalarm (akasma74 edition)

[AhmadK (akasma74)]

Could you please open a new issue here as this topic is not for reporting problems?

I take you just replaced files of your original alarm with ones from my Github?
If so, it won’t work, please read installation instructions first.
I’d recommend to remove the old stuff and install it from scratch and then configure (you can reuse parts of your alarm.yaml if you want, just save it somewhere safe).

[lukeh182]

yes I did.

[lukeh182]

@AhmadK

I’d recommend to remove the old stuff and install it from scratch and then configure (you can reuse parts of your alarm.yaml if you want, just save it somewhere safe).

I removed everything, reinstall and settings is still not accessible. I will open a new issue, I only posted here because I saw other people discussing it.

[sparkydave (🇦🇺 Dave)]

@AhmadK

Namely, I’d like to know if:

• you’re using only the alarm part of this component and rarely/never use its web panel
• you’re using the alarm’s MQTT functionality (if yes, how?)

I only use the side panel for controlling the arm/disarm state ( and adjusting alarm settings) other than the link with my hardwired alarm (see next point). I don’t use a Lovelace alarm card at all. The reason this side panel was created (aside from being the only way to control things in the beginning of this component) is that you can (at least could previously) make it such that the side panel was the only screen the user would have access to if the alarm was armed (this was an optional feature) and then once the alarm was disarmed the rest of the HA GUI would be available. It was a way of locking the interface if armed.

I do use the MQTT functionality heavily, as it keeps HA synchronised with my hard-wired alarm system.

Thanks for keeping this component going, it’s awesome.

[AhmadK (akasma74)]

@lukeh182

I removed everything, reinstall and settings is still not accessible. I will open a new issue

That answer was to another person but yes, please do that and provide as much info about the component and_what_ and how you did so I could reproduce it.

[daneboom]

@daneboom

Secondly, I’m wondering about whether anyone has done any looking into creating a ‘probability of ingress’ automation? I’ve had two false alarms since I began using this package. One was probably caused by a power blip and using a built in pull up resistor on a hard wired sensor, the other I’m still not sure, maybe sunlight shining on a PIR (but it wasn’t particularly sunny that day and has been much sunnier since!). Anyway. They’re really, really rare BUT when they do happen the stress and disruption is immense. On both occasions I pegged it home and found…absolutely nothing amiss.

I was wondering about creating an automation that somehow monitors whether a second sensor is tripped within (say) a minute of the first being tripped and if so, confirms that there is almost certainly an intruder rather than just a false positive.

I think I now know how to do this. But I’d need access to the information which is possibly just internal to the alarm system: what has tripped the alarm.

I’ve installed the HACS integration ‘variable’ and my plan was to compare a sensor turning on against a stored variable, which would = the sensor which originally tripped the alarm.

Any idea on how to do this? Thanks!

[AhmadK (akasma74)]

@daneboom

I’d need access to the information which is possibly just internal to the alarm system: what has tripped the alarm

it’s in alarm_control_panel.house (if you didn’t change it in your config) and the attribute in question is changed_by.

But what’s the point of it, briefly?

[daneboom]

Thanks for this. The point is as outlined above. But to give you a use case, last night my alarm went off erroneously twice, at 4.18 and 5.13am. I have three theories.

1. Faulty Xiaomi PIR (which has worked flawlessly for a year hitherto)
2. Low battery on Xiaomi PIR causing false positives?
3. Android tablet screen in kitchen turning on erroneously in an otherwise pitch dark kitchen causing a false positive.

I got notified on each occasion which was a bit scary. I want to instead only get notified (and woken) if TWO sensors are tripped within quick succession of each other.

[AhmadK (akasma74)]

@daneboom

I want to instead only get notified (and woken) if TWO sensors are tripped within quick succession of each other.

How about using Bayesian sensor (haven’t used it yet but people use it exactly for that)?

@daneboom

Faulty Xiaomi PIR (which has worked flawlessly for a year hitherto)

collect statistics and then get rid of the faulty one if confirmed.

@daneboom

Low battery on Xiaomi PIR causing false positives?

monitor batteries on a regular basis to avoid it

@daneboom

Android tablet screen in kitchen turning on erroneously in an otherwise pitch dark kitchen causing a false positive.

Are we talking about Passive InfraRed sensors?

By the way, the changed_by attribute won’t help you if you hoped to capture its change after the alarm is tripped as I intentionally stop updating it when it happens to see what triggered the alarm.

[daneboom]

@AhmadK

How about using Bayesian sensor

It’s a thought, certainly. I’ll have a look through the forum for config ideas.

@AhmadK

collect statistics and then get rid of the faulty one if confirmed.

Yep, will be doing this.

@AhmadK

monitor batteries on a regular basis to avoid it

Impossible without taking out the battery as the sensors don’t report any useful (read: reliable) battery info by telemetry, but something I’ll have to look into!

Are we talking about Passive InfraRed sensors? We are.

@daneboom

Xiaomi PIR

@AhmadK

By the way, the changed_by attribute won’t help you if you hoped to capture its change after the alarm is tripped as I intentionally stop updating it when it happens to see what triggered the alarm.

Thanks, good tip, but actually that should be OK as I’ll use regular automations and regular sensors to compare the captured variable against further developments!

[AhmadK (akasma74)]

@AhmadK

monitor batteries on a regular basis to avoid it

Impossible without taking out the battery as the sensors don’t report any useful (read: reliable) battery info by telemetry, but something I’ll have to look into!

Well, I have an automation that notifies me if a sensor _did not send a reading within a given interval (24hrs for PIRs). That way I know it has low batteries/out of RF range/broken.

@daneboom

We are.

daneboom:

Xiaomi PIR

it doesn’t go well with

@daneboom

Android tablet screen in kitchen turning on erroneously

as screens should not normally emit any tangible IR

[daneboom]

@AhmadK

as screens should not normally emit any tangible IR

I’ll freely admit I’m not an expert on this, but isn’t that a fundamental misunderstanding of what a PIR sensor does?

Since the primary source of infrared radiation is heat or thermal radiation , any object which has a temperature radiates in the infrared . Even objects that we think of as being very cold, such as an ice cube, emit infrared The warmer the object , the more infrared radiation it emits

@AhmadK

people use it exactly for that?

Perhaps my forum search failing me, but I failed to find anyone reporting use of a bayesian sensor to help stop false positives.

[tom_l]

PIR sensor presence detection

A passive infra-red sensor (PIR) triggers only when a heat source moves across zones of the sensor. So to stay triggered the heat source would have to be constantly moving. You can set up your automations so that the light only turns off if there has been no movement for a certain time. See here for an example of this sort of automation. See this diagram showing the zones of a typical sensor: [images] Some sensors are ‘pet-immune’. They don’t detect small heat sources moving down low. Most al…

[AhmadK (akasma74)]

@daneboom

Perhaps my forum search failing me, but I failed to find anyone reporting use of a bayesian sensor to help stop false positives.

Don’t limit yourself by this forum and ‘false positives’ - it’s a more universal sensor (1 and 2). Have to admit it might be heavy lifting for some… well, another option is to create a template binary sensor that does the job for less.
Hope you get the idea. PM me your non-working config if you get stuck

[daneboom]

Thanks. I’m familiar with the concept and the principles, I just dislike the inevitable fine tuning I know lies in wait for me with a Bayesian sensor. I don’t like the ‘grey’ that exists with such sensors, preferring the binary nature of an on/off sensor!
Anyway the kitchen PIR is going nuts today. It’s either suddenly gone faulty, has a low battery or it’s the tablet. Going to investigate which! Thanks

[AhmadK (akasma74)]

@daneboom

I don’t like the ‘grey’ that exists with such sensors, preferring the binary nature of an on/off sensor!

as I said, make your own binary sensor out of whatever sensor you have - 2 PIRs? it’s 5 mins job.

[kernehed]

Is it possible to trigger a automation if a certain user uses a specific code?
For example.

I’ve set up a guest account.
When they disarm the alarm with their code I want to trigger a boolean that says that guest mode gets enabled.

Would that work?

[AhmadK (akasma74)]

@kernehed

Is it possible to trigger a automation if a certain user uses a specific code?

just to clarify, currently all user codes should be unique.

@kernehed

When they disarm the alarm with their code I want to trigger a boolean that says that guest mode gets enabled.

eh?

There is no such functionality and the alarm only changes its state and (if enabled) sends a MQTT message to its status topic.

However, I think it’s not that difficult to fire an event with username upon disarming if that would help.

[kernehed]

@AhmadK

There is no such functionality and the alarm only changes its state and (if enabled) sends a MQTT message to its status topic.

However, I think it’s not that difficult to fire an event with username upon disarming if that would help.

I see.
What do you mean with fire an event with username upon disarming?

[AhmadK (akasma74)]

I mean exactly that - fire an event.