I’m having an issue with GrovePi in python when reading from multiple digital pins in short consecutive order. I’ve adapted your sample GrovePi/Software/Python/grove_dht_pro.py to read from two DHT22 sensors instead of one to investigate the issue.
Depending on how long I wait between the read from one ot the other sensor I get the same reading from the previous port when the wait is too short. I tried that using IKPdb debugger and by manually running another script for one and then the other port right after each other. No matter what i try I have to wait between 1-2 seconds between read from D6 and D8 to get different Temperature/Humidity readings. If i do not wait between read from D6 and D8 i get the same D6 reading from D8 as well. As if GrovePi needs 2 seconds to switch between D6 and D8.
I started with a fresh Vanilla Raspbian installation. NOT the Dexter version. Grovepi was cloned from git and installed with the scripts.
The reads used to work on my old installaion in a Dexter Raspbian. But afer a update with the Dexter Sofware Update tool ALL my custom scripts and data in /var/www got deleted! So I thought that wont happen to me again so I reinstalled my RPi3s SD wih a original Raspbian.
What I did just before reinstalling Raspbian was a GrovePi Firmware Update from 1.2.2. to 1.2.7. I’m not absolutely certain but it might be that the issue started right after the update in the Dexter Raspbian already, but for sure it’s present now. I alredy tried reinstalling the 1.2.7 firmware again.
I’ve seen something in the Firmware changelog of 1.2.7 about faster IO and so on. I would have thought that this would improve my problem if anything but does not seem so.
So what elese can I do?
Here’s my sample code:
import grovepi
import math
sensor = 8 # The Sensor goes on digital port 4.
sensor2 = 6 # The Sensor goes on digital port 4.
blue = 0 # The Blue colored sensor.
white = 1 # The White colored sensor.
while True:
try:
[temp,humidity] = grovepi.dht(sensor,white) #Here I have to wait for 1-2 seconds to get both readings correct.
[temp2,humidity2] = grovepi.dht(sensor2,white)
if math.isnan(temp) == False and math.isnan(humidity) == False:
print(“temp = %.02f C humidity =%.02f%%”%(temp, humidity))
print(“temp2 = %.02f C humidity =%.02f%%”%(temp2, humidity2))
Thanks for reaching out to us. Can you run the a troubleshooting program following the instructions given in the ReadME here and upload the log with your reply so that we can debug.
Hi Shoban
I sure can. Hope you find anything. log.txt (6.2 KB)
Hope you find anything.
I did another test with a node.js example and there it seems that the problem does not exist. I can read all sensors with the .on condition like your example. So my problem seems isolated to Python.
You might want to introduce a warning in the Dexter Software Updater that data on /var/www is deleted by the way to safe other from the trouble I had.
EDIT: Just noticed something strange in node.js as well.
After a reboot my node.js script can not write to my SPDTRelays on D2-D4. Reading from DHT22 Sensors on D6-D8 or Analog sensors from A0-A1 works. Any write to D Ports have no effect. That is until I read the D port via a Python script first. A single python digitalRead from D2 is enough. afterwards writing to D2 works in my node.js script. Sometimes reading from one D port via python enables writing to other D ports in node.js as well. But most of the time i have to read each D port via python first after a reboot before i can start writing to them in a node.js script.allSensors.js.txt (4.5 KB)
This is the node.js script I use.
The realy strange thing is that if I read a D port after an unsuccessful write to true in node.js, the python read afterwards also sets the relay to true. As if the write was cached somewhere and only released when reading the D port via python.
I might add that I also reinstalled GrovePi and double checked all the modifications in /boot incuding the Pi3 overlay fixes. All to no effect. The problem remains.
Thanks for reaching out to us and for the detailed explanation of your problem. Yes we will put up a warning to our users on the /var/www/ files soon.
Since your problem is isolated to python, can you try to reinstall the python drivers by running this script. Also it looks like you have made the test with the Relay sensor, can you try out our examples on digitalWrite with some other simple sensor like the buzzer here.
But we have two things mixed up a bit. In python i have the problem that i cannot READ from all my digital sensors in short consecutive order. I have to wait 2 seconds between reads from different ports.
In node.js i have the problem that I cannot WRITE to my relays after a reboot. Doing a digitalWrite via python to the relays does work. Doing a digitalRead in python enables me to write to the relays in node.js afterwards.
Looking at my relay read script above, and also my other digital sensor read scripts in python, i just noticed that I set the pinMode to OUTPUT before the digitalRead. I must have copy pasted that from some example months ago but that used to work on my old Raspbian for robots installation like this without issues. Thinking about it, setting the pinMode to OUTPUT in python might be the reason why i’m able to write the relays in node.js afterwards. Or at least it would explain why the attempted write to TRUE in node.js is being written to the port when I run the read script afterwards.
What’s the genral idea behind pinMode? Do I have to set that accordingle each time prior to a digitalRead/Write?
Is there a pinMode setter in node.js as well?
UPDATE: Check my other post. I believe I found a bug in your node.js packages regarding the setting of pinMode. After I changed my node.js test program to manually set the pin mode before writing to the relay the write seems to succeed! I just briefly tested that by rebooting the Pi and not running any python scripts prior to my node.js script. At least one relay could be successfully written to after the reboot.
This leaves me back with my initial problem of switching pins in a python script. I also did some debugging there. In grovepi.py i came across this comment around “def dht”:
Delay necessary for proper reading fron DHT sensor
time.sleep(.6)
So it seems you had some wait delays in the python functions between reads and writes from i2c. For some reason these wait statements got commented out. What I found is that when i’m debugging the code in single steps the effective wait between the statements is long enough for the readings to become plausible. Only when i step over the read statements so “write_i2c_block” and “read_i2c_byte” are executed without a dely my sensor readings become implausible. Or in other words i get the readings from sensor A when querying sensor B.
I’m not sure why these time.sleep commands got all commented out. I beleive they were in place a few months back when i first started tinkering with GrovePi. I guess it’s somehow related to the latest 1.2.7 Firmware update making the GrovePi faster. But at least for me this does not seem to work.