We upgraded today from 26.0.2.31 to 26.0.3.31 and the upgrade went smoothly.

But we detected a bug in the behavior when adding new IC Cards.
Everytime we put the Intercom >> Card Settings >> Card Status in Issuing and add a new IC Card, the Tamper Alarm starts.
And the only way to disable the Alarm again, is to disable (and re-enable) Intercom >> Advanced >> Tamper Alarm.

The behavior with firmware 26.0.2.31 is correct.

This is a real nuisance as we typically add new IC Cards from remote, and the Alarm may be going off unknowingly (possibly the whole night).

Hi,

After upgrading to new firmware, R26 can try to be reset to factory settings first.

And if you use the Tamper Alarm feature, you can first adjust the value of Gravity Sensor Threshold(The smaller the value, the more sensitive it is) to be proper. If you do not use this feature, you can disable it.

Best regards

Is it required to reset the device to factory settings after an upgrade ?

BTW The second day in use the tamper alarm also went off while the device had not been tampered with, only used as a doorbell.
So maybe the default sensitivity value of 32 is too sensitive.

Also, nowhere in the interface is it made clear that a lower sensitivity value means more sensitive.
It would be best to add help information to the interface for non-obvious things like this.

Hi,

Thanks for your kind advice. We will think about it.
By the way, before you start testing the R26, its manual can be your reference.

Thanks&Best regards

So today we got another alarm, for no real reason.
It seems to happen during the time the school is out and people ring to fetch their kids (between 16:30 and 17:30 is the highest activity).

The device is wall-mounted pretty well, so I wonder if this is because of heavy traffic, or improper use by users that set off the sensor.

We already raised the sensitivity of the gravity sensors from 32 to 48.
I now increased the value to 63, hoping this will fix the cause.

But maybe it wasn't the sensor that activated the alarm, or maybe the sensor is malfunctioning ?
Does the device log anything related to this ?
It would be nice if we could see the actual read-outs of the sensors before, during and after the alarm.

Like if we could send these readout's to an MQTT server, and having the doorbell log ERROR and WARNING events to a syslog server.

We got two other tamper alarms going off.

Once there was drilling very close to the device (the device was set to treshold 63 this time).

The second time there was no real reason for it to be triggered.
(Was there a truck passing the building, or maybe someone slam the door ?)
We really don't know what triggered it.

In the meantime we have increased the treshold to 79 this time.
Let's hope it doesn't happen again.

Again I would like to know if there's some way to get more logging information on what the sensor measured.
If we would know the value that hit the treshold, we wouldn't be needing to increasing it every time again.

We ended up increasing the tamper alarm every time it gave a false alarm and now the setting is set to 120.
Since 127 is the highest, it might as well be turned off in reality, I don't know.

Better logging of tamper alarm information, as well as syslog support would be very helpful.