How about using Bayesian sensor (haven’t used it yet but people use it exactly for that)?
collect statistics and then get rid of the faulty one if confirmed.
monitor batteries on a regular basis to avoid it
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.
It’s a thought, certainly. I’ll have a look through the forum for config ideas.
Yep, will be doing this.
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.
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!
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.
it doesn’t go well with
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
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
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
as I said, make your own binary sensor out of whatever sensor you have - 2 PIRs? it’s 5 mins job.
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?
just to clarify, currently all user codes should be unique.
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.
I see.
What do you mean with fire an event with username upon disarming?
If you open up the Alarm Panel and open Settings, then Click “Alarm” and then:
I think that might be what you are looking for`? Mine seems to keep the armed_away if I restart my device.
I also have problem with false alarms (damn cats…) and was hoping to combine the sensors - ie trigger the alarm if two sensors indicate motion in a certain amount of time.
Unfortunately I don’t understand how to proceed with the binary sensors for this, right now I have binary sensors like this - can you point me on how to proceed?
binary_sensor:
- platform: template
sensors:
rorelsesensor_sovrum:
friendly_name: "Rörelsesensor sovrum"
device_class: motion
value_template: "{{ is_state('sensor.sensora_burglar', '8') }}"
rorelsesensor_hall:
friendly_name: "Rörelsesensor hall"
device_class: motion
value_template: "{{ is_state('sensor.sensorb_burglar', '8') }}"
rorelsesensor_vardagsrum:
friendly_name: "Rörelsesensor vardagsrum"
device_class: motion
value_template: "{{ is_state('sensor.sensorc_burglar', '8') }}"
ok, your request is not very detailed but let’s try.
This is one of the approaches - I’m creating one binary sensors that will turn on if there is signal from more than one of your original sensors in 30 seconds.
I assume that your sensor.sensora_burglar etc change their state to on and then back off almost instantly - if not, you’ll need to adjust delay_off below.
First of all we need to make wrappers - binary sensors that retain their on state for 30 seconds.
binary_sensor:
- platform: template
sensors:
rorelsesensor_sovrum:
value_template: "{{ is_state('sensor.sensora_burglar', '8') }}"
<<: &delay_off
delay_off: 30
rorelsesensor_hall:
value_template: "{{ is_state('sensor.sensorb_burglar', '8') }}"
<<: *delay_off
rorelsesensor_vardagsrum:
value_template: "{{ is_state('sensor.sensorc_burglar', '8') }}"
<<: *delay_off
Then we create a combined binary sensor out of these
grosssensor:
friendly_name: "combined sensor"
delay_off: 5 # will turn off after 5 seconds
value_template: >
{# add states of all sensors in the list #}
{% set observed_states = [
states('binary_sensor.rorelsesensor_sovrum'),
states('binary_sensor.rorelsesensor_hall'),
states('binary_sensor.rorelsesensor_vardagsrum')
]
%}
{# trigger if there is more than one `on` status #}
{{ observed_states.count('on') > 1 }}
Now you can use binary_sensor.grosssensor in your bwalarm.yaml instead of your original sensors (don’t forget to remove them!).
Haven’t tested it “live” as I’m pretty happy with my PIRs so please let me know if it works for you.
Problems with integration on 0.107.0. I made an issue.
Thanks for the warning.
I made a pr, very simple fix. You can do it yourself in the meantime.
I’ll take care of it, thanks!
A hotfix is available for HA 0.107 users of the alarm.
This service release allows the integration to work with HA 0.107 and higher, no other functionality was added.
Please read the release notes.