I’ve got a project setup on a pi B with 5 one wire DS18B20s, a hall effect switch as a digital input, and an LED set to trigger on the hall switch. When the magnet trips the hall sensor I almost immediately see the change in WebIOPi, but it takes several seconds for the LED to trigger. Is this lag a limitation of Cayenne, or am I having an actual issue? The reason for my concern is, although this is a test, I’d like to be able to move up to a temperature sensor triggering an action based on an over temp condition, but a lag of this duration, 10-15 seconds, is too long.
In addition the trigger does not work when the pi isn’t connected, I thought I saw mention that the pi would locally have scheduling information, is this the case for triggers?
I have had a very quick response on Temp DS18B0’s. I have mine setup if temp goes above X light an LED and then send a remote connection notification (Text and Email).
The LED GPIO ON is instant on Temp above set-point at the breadboard level, the text is anywhere between 5-30 seconds delayed.
I have seen some wonky time delays on the web page like the graphic changing states from grayed out for the light off and the blue flash light icon for light on. Sometimes that takes a handful of seconds to refresh.
I have posted a video in the video section on my setup on this forum/community. I have a pi2 B, I have not tested on the original pi b. I have one, so maybe I could set that up and see if I get the same results. I’m currently running the full version of Jessie.
Short answer: It’s a lag limitation of Cayenne. We need to refactor some things in order to get triggers to be instantaneous. There are improvements that we can make to the Cayenne agent and response time from WebIOPi that should make triggers execute faster. These improvements are going to be done sooner rather than later too.
This is correct. Scheduling will run if the Pi is not connected to, but unfortunately, this is not the case for triggers.
I could definitely see a use for allowing the RasPi to buffer data from sensors when in a disconnected state, then upload everything once connected again. This makes sometimes-connected data logging devices possible and also guards against temporary loss of connection. One issue related to triggers though is that you may not want triggers to fire from buffered (old) data depending on the application. You might have to provide for some more fine tuning options when triggering in this case.