Possible bug in Grove Pi/Light sensor/Sound sensor




I have been working with the Grove Pi for only some days, but have worked with the RPi for about a year and have done a few projects.
I really like the Grove Pi as I can do things better and faster.

So I have been building a setup to measure air quality using the sensors for Humidity&Temperature and Dust.
I was trying to add the light and sound sensors, but eventhough I get output - its the same.
Somehow I think the data from the sound sensor is copied to the light sensor.
First I setup the light sensor to A2 and sound to A0. Same data was collected.
Then I moved the lightsensor to A1, but didnt update the code to reflect it. Same data was collected.
Then I updated the code. Same data was collected.

So what I conclude from this is that maybe the data from the soundsensor is applied to the lightsensor. Either in code, firmware or hardware.

This is my code:

from __future__ import print_function
import paho.mqtt.publish as publish
import psutil
import string
import random
import time
import grovepi
import atexit
from grove_rgb_lcd import *
from grovepi import *

#Setting up sensors
sensor = 7 #D7
LightSensor = 1 #A2
SoundSensor = 0 #A0
LED_green = 4 #D4
LED_red = 3 #D3

#Setting up data to write data to Thingspeak
channelID = "XXXXXXXXX"
mqttHost = "mqtt.thingspeak.com"
mqttUsername = "TSMQTTRpiDemo"
tTransport = "websockets"
tPort = 80
topic = "channels/" + channelID + "/publish/" + writeAPIKey

while True:

                #Set green operation

                #Gather data from sensors
                [new_val,lowpulseoccupancy] = grovepi.dustSensorRead()
                [temp,hum] = grovepi.dht(sensor,0)
                light_intensity = grovepi.analogRead(LightSensor)
                sound_level = grovepi.analogRead(SoundSensor)
                if sound_level > 0:

                #Prep connection to Thingspeak
                # Create a random clientID.
                for x in range(1,16):

                #To avoid posting empty data as "0" from the dust sensor. New_val means there is new data
                if new_val:
                        #Show data
                        print ("Temp =", temp, "C & Humidity =", hum,"% & Dust consentrantion =",lowpulseoccupancy," & Light =",light_intensity," & Sound =",last_sound)

                        #Prepare data for use on LCD & Thingspeak
                        t = str(temp)
                        h = str(hum)
                        d = str(lowpulseoccupancy)
                        l = str(light_intensity)
                        s = str(last_sound)

                        # build the payload string for Thingspeak
                        payload = "field1=" + t + "&field2=" + h + "&field3=" + d + "&field4=" + l + "&field5=" + s

                        # attempt to publish data to the topic on Teamspeak.
                                publish.single(topic, payload, hostname=mqttHost, transport=tTransport, port=tPort,auth={'username':mqttUsername,'password':mqttAPIKey})
                                print (" Published to Teamspeak to host: " , mqttHost , " clientID= " , clientID)

                        except (KeyboardInterrupt):
                                print ("There was an error while publishing the data.")

                        #Set LCD color
                        #Print on LCD
                        setText("T:" + t + "C" + " H:" + h + "%" + " Dust:" + d + "psc/L")

                #Wait 5 seconds
        except (IOError,TypeError) as e:

I have checked it several times, but I cant find the fault in the code itself. Can you find fault?

I have tested a bit more and I get data from the sound sensor, even when its not connected.

If I disable code for the temperature and humidity, then it works for the light sensor…its really strange!
I made a separate script to test the light sensor and that works…

Any points to errors on my code?

If I collect the data for light and sound before I collect humidity and temperature, the light data looks correct, but sound still looks strange.


So the light sensor works, but where the collection of data (analogRead) is placed in code influences what data I get. If I place the line of code before the TH sensor works, but if I place the line of code after TH I get wrong data.

Also the sound sensor data does not look correct. It builds up over time in a steady environment.

I will make a separate script to test it on its own.


Hi @jbeckj,

That’s very important information that you’re giving us.

We are working on fixing the bugs with the GrovePi - we sort of already have planned this “maintenance” update of the GrovePi. As soon as we have something for it, we’ll make a post about it and let everyone know.

What we also know is that when a subset of different sensors get combined on the GrovePi, the polling functions either return unjustifiable data or they mix the values between themselves.

Thank you!


Do you have a bug list available, because I have a great deal of sensors hooked up. F.ex. I get what I would categorize as “false-positives” on the dust sensor:

Those peaks, cant be true in a rather steady environment.

Any comments on those?


And this is the sound sensor output…in a room where there is talking during the day, TV and loud parrot noise at times…


Is it a faulty sensor?


Hi @jbeckj,

A quick fix for the dust sensor would be to use some very simple statistical filtering. Here’s how I did it with a DHT sensor a while ago:

No, at the moment we do not have a list with all the bugs. Most of them have already been reported on the forum, so we have first got to check those and then move on the other things.

As for the sound sensor, I’m not following what is the issue, except that the measured loudness is way too high.

Thank you!


Thanks for the help with code to remove those false readings - very helpfull!

The problem with the sound readings is that they dont change to reflect change in noise. There is not difference between the sensor being in a noisy environment of completely still.


Hi @jbeckj,

Hmm regarding the sound sensor I think that’s because the GrovePi is not fast enough for picking up sound. Maybe you can test it by brushing your finger directly onto the microphone and see if that reports a higher value when calling it.

I know we have used it, but it wouldn’t pick everything and because of this, we moved onto using the Grove Loudness Sensor.

You can find a more detailed explanation here:

Thank you!