Have been running a bunch of Pis with Grove Pis (we have a mix of the old and the +) to get sensor data (motion, temp/humi, sound, light) all has been fine. Recently one of the ones that uses a GrovePi+ stopped getting sensor data, when I went to check it out I saw that both the green power led and red RST led on the Grove were lit. After hard resetting it, the problem went away.
What exactly triggers this? The Pi is in a Grove Pi case so its mostly enclosed, it is open to people coming up and touching it so could some rouge finger have caused this or is there something else we need to consider.
I saw some posts about other shields using the CE0 pin on the Pi and that making it reset, but we only have the GrovePi on there.
If this is something we need to code against is there a way to fix it with out needing to unplug/replug the Pi so that we could just detect a bunch of failed reads and restart. (A normal restart did not seem to fix it in our initial testing)
Hey,
The CE0 pin is indeed connected to the Reset pin on the GrovePi and if something pull it high momentarily, it would reset the controller. It seems that the CE0 Pin is somehow being held HIGH. We have not seen this situation earlier unless someone was intentionally pulling the pin high. If it is happening very often then you should run the gpio readall command when you see the Red led to check whether it is because of a the Software.
You can also try using the Dexter Industries image to see if that makes any difference.
I have had the same intermittent issues with a Grove Pi kit. I have temperature/humidity (DHT11), sound, light, ultrasonic ranger and a PIR motion sensors attached to the Grove Pi and I am streaming the readings into an Azure Event Hub (via http REST interface).
I have updated/upgraded Raspbian, updated the Grove Pi software and flashed the Grove Pi with firmware version 1_2_5 (the latest step did eliminate frequent I/O exceptions, which the code was handling).
The python code has at least a .25 second delay between each Grove Pi read (I also have a switch, that if pressed, will force a Pi shutdown). I am also driving the RGB display that I use to show the latest reading set and I turn the display green or red depending on the success of the send to Azure. I do not have any delays around writing to the display (should I?).
Everything works perfectly, sometimes for many hours (i.e. overnight & over the weekend), but suddenly (often with someone standing in front of the ranger) the Grove Pi RST red light will come on and python calls to Grove Pi start returning an exception: TypeError: ‘int’ object has no attribute ‘getitem’. When this happens, even a Pi restart won’t fix the issue - I need to physically shut it down and pull the plug on the Pi (the shutdown switch was an idea, but the code can’t read it either). After a power cycle, everything is fine again for some random amount of time.
Flashing the Grove Pi, does turn off the RST light, but that seems a bit extreme from code :-). While in the RST red light on state, I did try a write to GPIO pin 8 (CE0), but it did nothing.
While on the old firmware (1_2_2), I found that pulling out the wireless USB mouse and keyboard transceivers seemed to stabilize the system somewhat.
If driving GPIO 8 high doesn’t work, is there any other way of causing the Grove Pi board to reset/restart?
btw; I am considering buying another 10 kits to gather readings from various rooms around our facility, so it would be good to get this solved. One thing we are considering is using the new Windows 10 IoT Core Grove Pi library and re-writing the code. If this is a hardware or firmware issue, then this won’t help the stability of the solution though…
Hey Mitch, I promise we’re not ignoring you. Karan is the lead developer on this, and he lives in Chennai (which is currently knocked out by a massive flood). He has been out of the game for a few days, not sure when he’ll be back. I just don’t want you to think we forgot about this.
No Problem John, thanks for the heads up. I hope Karan and the rest of Chennai are ok. Obviously, their safety and getting their lives back together is the priority.
It will likely be a few weeks until we acquire the kits and build/configure them and put them in cases.
btw; have you or anyone else reading seen any case options for the sensor kits? The orientation of the connector on some of the sensor PCBs is not exactly conducive to putting together a tidy solution (i.e. with only the sensor exposed). My experiment with a flanged Hammond project box worked out ok, but it is quite a bit of dremel work to carve out vent holes (a Pi symbol) and cutouts for the sensors/display etc.
Hi mitchvh,
Sorry for taking this long to reply back and thanks for understanding about the situation here. It’s much better now.
Now coming back to the reset issue, we haven’t seen it ever before with the GrovePi. I have a suspicion on the pullup resistor for the Reset line but really not sure. One way to reset the GrovePi from software is to use avrdude -c gpio -p m328p which should reset the firmware from the software. Can you try this out and let us know if this works. Can you also send the code that you were using so that we can try replicating the problem at our end.
Thank you Karan, glad to here things are better there.
I had not seen the sensor mounts. They are a bit pricey and still would leave the wires hanging out, which isn’t exactly the finished look we were hoping for.
We were already thinking of buying the Dexter case and the sensor mount says it is compatible with the Pi case, but I assume you have to drill your own holes to mount it on the case.
The source code is attached (for you and anyone else interested). iotREST.py is the main application, while SendTelemetry.py implements the REST calls to send the message to an Azure Event Hub - it was “borrowed” from Kloud (http://blog.kloud.com.au/2014/10/11/the-internet-of-things-with-arduino-azure-event-hubs-and-the-azure-python-sdk/) and adapted to my purposes. To use the SendTelemetry component you would need to fill in the event hub information (namespace, name, and sas key). If you need this for testing, let me know and I will share them privately.
Hey mitch,
Thanks for the feedback about the sensor mounts. We’ll take these into consideration when we are doing the next iteration of the Grove Pi case and the sensor mount. Any suggestions on what we should do to make them work for everyone.
I’ll test the code in a bit and let you know how it goes.
I found an issue in the IO Exception handler in iotREST.py - the Ethernet interface name was incorrect. It was causing the autostarted code to crash occasionally. btw; the avrdude command indeed resets the GrovePi board - so I now have it run that command if I get 10 exceptions in a row.
My thought on the sensor design is a connector that is parallel to the circuit board (like the one on the RGB display) on either the top or ideally on the bottom of the board (side away from the sensor). Obviously you would need a cutout in the sensor mount to make that work, which would be an issue, given the different sizes and shapes of the sensor circuit boards.
As previously noted, I came up with a custom case as a version 1 experiment - pictures attached for your amusement.
Sorry for bringing up an old topic…
I am also facing the Grovepi+ RST issue.
It happens since I added a 2-Coil Latching Relay to the Grovepi+ board.
The relay is used to turn on and off a car wiper motor (powered by an external 12V source).
My test program turns it on for 5 seconds every minute.
It works fine for a couple of cycles (say 1-3 times, can vary), then the RST led turns red and every subsequent calls triggers IOException.
It’s always the call grovepi.digitalWrite(Relay,0) to turn the motor off that raises the RST.
I also tried the demo program, it causes the same effects.
It also happens that the call to turn off the motor does not work (the call itself works but the relay doesn’t switch). I don’t know if this is related to the RST issue.
“avrdude” restores correctly the board.
I ran “gpio readall” before and after a run of my programm. The result is attached.
I suspected electromagnetic parasites causing interference; So I enclosed the Grovepi+ in a mini Faraday cage: It did not work better.
I tried grove_2_coil_latching_relay.py; the error is the same:
sudo python grove_2_coil_latching_relay.py
on
off
IOError
on
IOError
off
^CIOError
The only modification I had to do is change the port number from 4 to 3, because D4 is taken by chainable LEDs
Here's my program.
I noticed one strange thing... In my program (function Open_Door1()), when I turn the motor ON, I turn a LED ON and turn is back OFF when switching the motor OFF. Then, when the relay fails switching OFF, the LED also doesn't turn OFF. Probably because the board is already in a bad state...
I have a second relay, tried it with the same result with both programs: Either hangs the board or refuses to switch off.
He Benoit,
That is a pretty big project you have there. Can you run the troubleshooting script following the instructions here: https://www.youtube.com/watch?v=MJu8k-_UQgg and upload the log here. Can you also disconnect the RGB LED’s before you start. Also, does the Relay work after you get the IOError’s or does it stop responding at all. The LED’s do have some problem but we are moving towards a fix (Read here for more details: http://www.dexterindustries.com/topic/chainable-leds).
Thanks for the clues.
The read errors mentionned in the chainable LED topic you pointed look pretty much like my experience. As you maybe have noticed in my code, I had to perform the sensor readings in loops until getting a valid value. Just because error were occurring several times a minute (my sensor reading rate is every 2 seconds).
To reply to your question, Yes, after the IOerror occur, the relay doesn’t work anymore; as well as the other sensors.
My code had a global boolean variable (WithLEDs) that I used to skip all portions of code dealing with LEDs. Setting it to false didn’t make the issue disappear.
Anyways, I was about to disconnect the LEDs and remove the according parts of my code as you suggested (they aren’t required in my project).
That’s the moment my GrovePi+ board chose to fail, preventing the Pi from booting.
I have now to figure out why, since the Pi boots correctly without the GrovePi+ plugged.
I couldn’t try the GoPiGo test program either.
And yes it’s a rather big project. It’s meant to manage a hen house : Doors opening and closing at dawn and dusk, water and seed provision automated, temperature control, camera, etc…
So, I need a reliable system coz I don’t want to have to get up at 5 AM to open the doors manually because of a failing relay
Hi Benoit,
Thanks for the information and sorry for the troubles you are facing. To solve this, it might be best to stat small and then slowly keep on adding the sensors until you encounter what fails. I would suggest you to disconnect everything from the GrovePi and then connect it to the Pi and power it on and see if it works. If the Pi powers on correctly, then run the troubleshooting script and upload the log on the forums so that I can look if there is anything wrong with the hardware (instructions here: https://www.youtube.com/watch?v=MJu8k-_UQgg).
All the best for your project too and we’ll try our best to help you out with any problems you face. It would be great if you could share the details/pictures of the project once its completed.
I started my project adding one sensor at a time. Trouble started when adding the relay.
Nevertheless, I unplugged everything from the GrovePi and the Pi could boot.
Where can I download the troubleshooting script mentionned in the video? As I don’t have a GoPiGo bundle…
Could the power supply be an issue?
By any chance would you have and idea of the required power supply for:
RPi2
GrovePi+
Wifi dongle
Temp+humidity, light, air quality sensors
3 chainable LEDs
1 buzzer
1 2-Coil Latching Relay
And I still have to add :
1 2-Coil Latching Relay
1 RPi camera
My power supply delivers 1 AMP. Maybe it’s not enough?
I plugged only the relay to the GrovePi+ and ran grove_2_coil_latching_relay.py.
The IOerror still occurs after only one on-off cycle, then the RST LED turns red.
I tried my 2 relays with the same result.
BTW, in this case the power supply cannot be the problem.
