Everspring SE812 oddness

Other Devices & Integrations General Device Discussions
#1

Have three of these Everspring SE812 Sirens. Hardly elegant, but functional and pretty easy to set up.

One of them is doing something a bit odd, though. As far as I can tell, randomly through the day I’ll get notifications via Vera that it has changed state. No noise though, and looking at the log it’s changing ArmedTripped from 1 to 0. (Then back again one second later)

No idea why a Siren would have an Armed state? There appears to be no way of setting it to armed. There is a tamper switch, but that makes all hell break loose.

Turning the siren on changes Target (and status)

Any ideas on what’s happening?

Cheers

C

#2

I have a couple of these and have never observed this behavior, It also cracked me up as to why these have a tripped and armedtripped variable. I can only guess that it is for the tamper switch indeed.
What does the LastTrip variable say in ALTUI?

Incidentally I also have one mysterious door sensor which occasionally has a ghost trip which I can’t figure out yet.

#3

LastTripped is 09/12/2019, 15:51:42
Which matches the log:

|---|---|---|
|06|12/09/19 15:51:40.166|Device_Variable::m_szValue_set device: 241 service: urn:micasaverde-com:serviceId:SecuritySensor1 variable: LastTrip was: 1575888011 now: 1575906700 #hooks: 0 upnp: 0 skip: 0 v:0x10b51f8/NONE duplicate:0 <0x767d7520>|
|06|12/09/19 15:51:40.167|Device_Variable::m_szValue_set device: 241 service: urn:micasaverde-com:serviceId:SecuritySensor1 variable: Tripped was: 1 now: 0 #hooks: 0 upnp: 0 skip: 1 v:0x10b5f90/NONE duplicate:0 <0x767d7520>|
|06|12/09/19 15:51:42.101|Device_Variable::m_szValue_set device: 241 service: urn:micasaverde-com:serviceId:SecuritySensor1 variable: ArmedTripped was: 0 now: 1 #hooks: 0 upnp: 0 skip: 0 v:0xfe1098/DL_ARMEDTRIPPED duplicate:0 <0x767d7520>|
|06|12/09/19 15:51:42.101|Device_Variable::m_szValue_set device: 241 service: urn:micasaverde-com:serviceId:SecuritySensor1 variable: LastTrip was: 1575906700 now: 1575906702 #hooks: 0 upnp: 0 skip: 0 v:0x10b51f8/NONE duplicate:0 <0x767d7520>|
|06|12/09/19 15:51:42.101|Device_Variable::m_szValue_set device: 241 service: urn:micasaverde-com:serviceId:SecuritySensor1 variable: Tripped was: 0 now: 1 #hooks: 0 upnp: 0 skip: 1 v:0x10b5f90/NONE duplicate:0 <0x767d7520>|

Thanks

The only thing is (as you know) the tamper switch being tripped makes the siren go off, so it’s not making a great deal of sense.

C

#4

I am very dubious that this could be the device flickering in 2s. But just in case, you may want to change the batteries or at least reboot it by removing on battery and putting it back. See if that helps.

#5

Brand new batteries, but I’ll reboot it (y)

C

#6

Interesting. Exactly the same log entry by triggering the tamper switch. Wonder if it’s faulty.

I’ve disabled the jumper now, so fingers crossed

C

#7

Nope, still did it :smiley:

C

#8

sigh… Well try reconfiguring the device then? There has got to be something wrong with the configuration. It is the same as my door sensor. I can’t figure out why I have ghost trips. The trip time does not correspond to any communication from the sensor.
I used to get occasional ghost trips from some of my motion sensors but never since the upgrade to 7.0.30 and quietting down my zwave network so I think it was due to network overload. But now I get this new strange one…

1 Like
#9

Just hit ‘configure now’ you mean?

Might try it tomorrow when I can wake it up as well :slight_smile:

Cheers

C

#10

Yes, Hit the configure node now. Since it is a FliRs you don’t even need to manually wake it up. Something fishy might have happened in the user data which may have confused the variables. Just a theory.