Hello,
Im new here. I wanted to know how to set up the particle to get a notification when a GPIO gets an input (ie we get a contact closure, example when someone passes from a beam security system and the beam is interrupted).
I was able to connect particle to IFTTT. However, when I get multiple inputs the response stops.
Also, how do i check if GPIO 1 (of 7) is working correctly/
Thank you
Markos
Go to https://console.particle.io and login with your particle account. Click on your device in the device list, now close and open the inputs on the board, you should see events appear here for diagnostic purposes. Once you understand the events you can setup an IFTTT applet to monitor events and generate notifications.
Hi Travis, I too am new and have a 1-Channel SPDT Signal Relay Board + 7 GPIO and am having a problem with long delays from the time of a GPIO input to action on IFTTT. On the Particle website I can see my device but I see no events published when I ground GP1. Also when I run the health check, it just stops at 50%. What am i doing wrong?
Ok, now the health check reports: The device is publishing messages too rapidly, and is being rate limited. This causes messages sent by firmware to be blocked from reaching the Particle cloud. Reduce the frequency of published messages in your application firmware to below 1 per second to avoid rate limiting.
Are you able to see what event the rate limited messages are publishing to and what the messages contain?
Also did you order the board with optional IFTTT module or did you program the Photon module yourself? If you are not sure you can provide your online order number and I can take a look.
No I cannot see what event the rate limited messages are publishing to because there are no events posting. Occasionally I can trigger an event by making GPIO 1 low, but for the most part nothing is posting.
Yes, I did order the board with the optional IFTTT module as I did with the 4 channel board I ordered that has the same problem. Is it possible I was sent the wrong particle board?
Sorry for the late reply, I did not see your reply.
You might try refreshing the firmware to the board. To do this go to https://build.particle.io and sign in with your Particle account. Now click the libraries icon on the left(looks like a ribbon) and search community libraries for NCD1Relay, once you it click to select it. On the left click on CloudControl.cpp and then click the Use this Example button. Now make sure your board is powered up and the Photon module LED is breathing light blue in color. If you have more than one Photon board make sure it is selected under the selection menu(looks like a target). Finally click the flash button on the left(looks like a lightning bolt). You should see the LED on the photon turn magenta in color while the firmware is flashed.
Let me know what you find.
Ok, I updated with firmware version from 1.2.1 to 1.5.0.
I couldn’t get the device to flash, then I saw there is a star to the left of the device name that needed to be selected for flashing.
Ok, so I made an applet that triggers my Lutron Caseta lights, but it takes 30 seconds to one minute after triggering a GPIO lo before they come on. Is the delay normally that long?
When I run a health check I am getting some messages again: 8 rate-limited publishes - then the same message I had before about the the device is publishing messages too rapidly.
Particle devices are allowed to publish an average of 1 event per second in application firmware. Publishing at a rate higher than this will result in rate limiting of events. The device is publishing messages too rapidly, and is being rate limited. This causes messages sent by firmware to be blocked from reaching the Particle cloud. Reduce the frequency of published messages in your application firmware to below 1 per second to avoid rate limiting.
Hi @Carl_1,
The communication between the Particle Cloud and IFTTT is sort of out of our control. You could possibly post the question on their forum as to whether or not it is possible to decrease the delay. They may have some solutions for that. I can tell you it takes little to no time for the event to go from Particle to IFTTT so it could be a delay between IFTTT and Lutron, you might try triggering them in another way on IFTTT to see if the results vary.
What do you have connected to the inputs on the board? Have you tried disconnecting everything except power from the board to see if the high volume publishes stop?
Part of the issue here is communication between the Photon and the Particle Cloud as it is publishing messages too rapidly, and is being rate limited. I assume I will have to look on the Particle site for an answer to that. I will try your suggestion to see if I can activate Lutron through another method, such as a scene on SmartThings.
The board is on my workbench and I have nothing connected to the inputs other than two wires to make an input go low. Nothing seems to correct the publishing rate.
Hi @Carl_1,
We’d be happy to take a look at the board for you if you’d like to send it in for RMA repair. Our RMA form can be filled out here. Instructions for returning the board for repair will be provided.
https://ncd.io/contact-us/product-returns/
Considering I have two different boards with the same issue I am not sure if sending them back would result in a fix. When I signal or ping each board through the Particle Console the response is almost instantaneous, so communication is working. However, it is when I run the Health Check diagnostics that it either hangs at 50% or gives the error about the frequency of published messages. No events publish when I don’t get a good health check. On occasion, when I get a good health check the events are published.
Hi @Carl_1,
We’ve been selling these boards for about 2 years now and we have sold a bunch of them. This is the first time this has ever been reported that I can remember. I cannot replicate the issue you are having here. If you have everything connected and powered up correctly then I have to assume there is a hardware issue because it is not firmware related. This would however require us physically looking at the boards. You could try posting a photo of one of the boards powered up and we can see if anything jumps out at us.
Thanks for your reply. The rate limiting seems sporadic and there are times I don’t get the error message.
Here is a picture of the board powered up as requested. As for sending the board back for inspection, that would be great, however, I am in Canada and it is a bit complicated to do so. If it is not software, what hardware issues could potentially cause this?
Thanks, Carl
Hi Carl,
I’m actually not seeing any hardware issues with the board. Everything appears to be good. If the relay works(you are able to switch it on and off) then that basically verifies that the multiplexer chip which is also used for the inputs is good as well.
Have you reached out to Particle on this topic? We really need to find out what messages are being sent that trip the rate limit on this device.
Hello,
I would like to ask how you can write a code that will open/close the relay when input 1 is grounded?
Hi @markospefkaros,
Go to https://build.particle.io and sign in with your Particle account. Now click the libraries icon on the left(looks like a ribbon) and search community libraries for NCD1Relay, once you it click to select it. On the left click on CloudControl.cpp and then click the Use this Example button.
Look at lines 29 - 56. This is where the inputs are monitored. Add a line after line 33(if(!tripped[a]){) to turn the relay on. Or after line 47(if(!tripped[a]){) to turn the relay off.
The methods to turn the relay on and off are:
relayController.turnOffRelay()
relayController.turnOnRelay()
Thank you,
Travis Elliott
Hi Travis,
Ok, glad to hear you don’t see any issues with the board. Yes, the relay works when I send a command from the Particle console. I sent a message to Particle to see if they have a solution. I will keep you posted.
Thanks,
Carl
I was in touch with Particle regarding the publishing rate and here is their response:
Matthew - Particle Support (Particle)
May 5, 09:55 PDT
Hi Carl,
I was able to briefly review your code and the cloud side logs for your device.
If I am understanding the code correctly, it appears that whenever your peripheral ever has a signal readout, you have a loop that will publish 4 events minimum each iteration.
Per our documentation here :
NOTE 1: Currently, a device can publish at rate of about 1 event/sec, with bursts of up to 4 allowed in 1 second. Back to back burst of 4 messages will take 4 seconds to recover.
If my understanding is correct, the conditions in your loop allow for multiple loop iterations to publish, thus, it would be absolutely possible to exceed this limit and put your device into a rate limited state.
Rate limiting would absolutely have an impact on the timeliness of services such as IFTTT. It is also wroth noting that the free tier of IFTTT is known to have considerable delays as well in certain conditions, and may also be catalyzing the undesired behavior. If time sensitivity is a concern, I may consider pursuing other services in addition to reducing the publish frequency of your code.
Hi @Carl_1,
Yes, it is possible for the firmware to publish more than 4 messages per second. The firmware does nothing to limit that. However you would have to close the input and open it pretty quickly to make that happen. If you are just closing and opening the input at a reasonable pace then you should never exceed the 4 publishes per second limit. You aren’t closing and opening the input really fast are you?
Not sure how I can limit the rate as I get the publishing rate warning with the device just sitting on the bench with nothing attached.
Carl