Author Topic: Random lag from an SM103 tripping and corresponding LUUP event  (Read 3977 times)

Offline cscaswell

  • Newbie
  • *
  • Posts: 7
  • Karma: +0/-0
Hey,

My Vera2 + sensors arrived yesterday and it's all set up nicely :o)
For each of the sensors I've added a LUUP event when tripped. The event simply sends a luup.inet.wget() to my home server, which in turn triggers eventGhost on so on.

It's all working wonderfully except that delay between the physical trip and the luup.inet.wget() firing is very erratic. Sometimes it fires after a few seconds, other times it takes closer to a minute.

The sensor I'm testing with is an Everspring SM103 door/window detector.
Are there settings to get this event to fire more reliably?

Any advice would be much appreciated
Many thanks

Chris

Offline mcvflorin

  • Administrator
  • Hero Member
  • *****
  • Posts: 1755
  • Karma: +11/-3
Re: Random lag from an SM103 tripping and corresponding LUUP event
« Reply #1 on: May 18, 2011, 09:12:35 am »
Quote
Sometimes it fires after a few seconds, other times it takes closer to a minute.

Look in the logs to see what's happening, if the delay is from the sensor or not.
1. Add a log like
Code: [Select]
luup.log("STATUS: Sending message") before sending the message with luup.inet.wget.
2. SSH into Vera
3. Enable verbose logging:
VerboseLogging enable
4. Check the logs to see all activity related to the device:
tail -f /tmp/log/cmh/LuaUPnP.log | grep 'node <altid>\|STATUS'
<altid> is the value in the altid field on the Advanced tab. Grep-ing for node <altid> shows all activity related with the device as a Z-Wave node. Grep-ing for STATUS shows your logged message before the luup.inet.wget funtion call.
5. After you're done checking disable verbose logging:
VerboseLogging disable

This is what I see when the sensor (node 4, device 10) is tripped (I have a Hawking HRDS1, but it shouldn't be much of a difference):
24      05/18/11 15:41:27.168   ZWaveJobHandler::DoReceivedFrame m_iFrameID 133 gwf_ach node 4 command 0x4 data EMPTY BUFFER () <0x803>
24      05/18/11 15:41:27.169   ZWaveNode::HandlePollUpdate node 4 device 10 class 0x71 command 0x5 m_iFrameID 133/8128600 data 0x1 0x11 (##) <0x803>
02      05/18/11 15:41:27.170   ZWaveNode::HandlePollUpdate_Alarm node 4 device 10 alarm code 1 <0x803>


Hope this helps.

Offline cscaswell

  • Newbie
  • *
  • Posts: 7
  • Karma: +0/-0
Re: Random lag from an SM103 tripping and corresponding LUUP event
« Reply #2 on: May 18, 2011, 09:59:50 am »
Excellent advice,
Will try tonight, cheers.

Offline cscaswell

  • Newbie
  • *
  • Posts: 7
  • Karma: +0/-0
Re: Random lag from an SM103 tripping and corresponding LUUP event
« Reply #3 on: May 18, 2011, 05:28:51 pm »
Hey,
I've spent an hour peering at the log (all, as well as grep'd).
The delay I'm experiencing is actually between the sensor tripping and Vera 2 responding.
The LUUP runs immediately after which is great.

The length of delay is quite erratic. The last two timings for example were 37 seconds, and 14 seconds.
Re-Arming the sensor experiences seems even worse, minutes before a "Tripped was: 1 now: 0" event is received.

I presume this is not normal? Could the sensor be faulty?

Offline cscaswell

  • Newbie
  • *
  • Posts: 7
  • Karma: +0/-0
Re: Random lag from an SM103 tripping and corresponding LUUP event
« Reply #4 on: May 18, 2011, 05:44:13 pm »
Just messing about I changed the "Poll this node at most once every" to 2 seconds.
Vera2 not responds timely and reliably, which implies the sensor isn't actually proactively triggering.
Is this normal? :)

Offline cscaswell

  • Newbie
  • *
  • Posts: 7
  • Karma: +0/-0
Re: Random lag from an SM103 tripping and corresponding LUUP event
« Reply #5 on: May 18, 2011, 06:24:10 pm »
Unfortunately the delay reoccurred while testing.
I think the period of time that it was functioning correctly was caused my be manually waking the sensor. As soon as it reverted to sleep mode the delay was back.

Offline mcvflorin

  • Administrator
  • Hero Member
  • *****
  • Posts: 1755
  • Karma: +11/-3
Re: Random lag from an SM103 tripping and corresponding LUUP event
« Reply #6 on: May 19, 2011, 03:05:35 am »
Hey,
I've spent an hour peering at the log (all, as well as grep'd).
The delay I'm experiencing is actually between the sensor tripping and Vera 2 responding.
The LUUP runs immediately after which is great.

The length of delay is quite erratic. The last two timings for example were 37 seconds, and 14 seconds.
Re-Arming the sensor experiences seems even worse, minutes before a "Tripped was: 1 now: 0" event is received.

I presume this is not normal? Could the sensor be faulty?

I don't think that's normal. With my sensor, the delay between the tripping and Vera responding is at most 5 seconds, usually around 2-3 seconds, which is pretty consistent.

Have you tried to play with the Wakeup interval value? Maybe setting it to a lower value will help.

Offline cscaswell

  • Newbie
  • *
  • Posts: 7
  • Karma: +0/-0
Re: Random lag from an SM103 tripping and corresponding LUUP event
« Reply #7 on: May 19, 2011, 04:58:57 am »
Will have a play with that tonight, what's yours set to?.
Also going to delete the device, reset it defaults and add it again.

Offline cscaswell

  • Newbie
  • *
  • Posts: 7
  • Karma: +0/-0
Re: Random lag from an SM103 tripping and corresponding LUUP event
« Reply #8 on: May 20, 2011, 04:54:04 am »
Reset the SM103 to factory defaults. no change.
Dropped the wake-up interval to the minimum, no change.

Decided to crack on a second unit (I've been resisting in case I needed to swap them for the AEON equivalent), works perfectly. So I guess its a fault unit.

Thanks for the advice/support mcvflorin :)

Offline mcvflorin

  • Administrator
  • Hero Member
  • *****
  • Posts: 1755
  • Karma: +11/-3
Re: Random lag from an SM103 tripping and corresponding LUUP event
« Reply #9 on: May 20, 2011, 06:36:35 am »
Thanks, I'm glad you found the problem.