Think I solved this.
To set up for a new round of testing, I put one DHT Pro sensor on a 1m wire and the second on a RJ45 extender with a 6’ Cat5. Also I put the Grove temp sensor on a second RJ45/Cat5. I left the air quality sensor, 3 LEDs and 2 relays on their existing 5cm to 20cm wires. This will be approx the cabling when fully deployed.
First step was to run my program to gather a baseline error rate. The next step would be removal of all but one DHT Pro on a long cable, as you suggest above. Then I planned to add 1 sensor at a time.
Surprisingly, step 1 generated few errors this time: 82 IO Errors logged after 1578 minutes of up-time. Sensor cycle is once every 2 minutes, so ~800 cycles with an error every ~10 cycles. Obviously this is much better than ~100% errors in previous tests with 1m and RH45 cable extenders on 1 DHT Pro and the temp sensor. This 1 error in 10 cycles error rate is comparable to my past experience using “short” cables only.
What changed? Since my previous testing on this issue I’ve moved the Pi from the wall to the workbench in the rabbit building - easier to debug on the bench. The bench power tap didn’t have enough room for the old wall wart, so I swapped in a 2A unit that Adafruit recommends. Cables and sensors are same as before, and I’ve added a second pair of RJ45 (which should have made the problem worse, all other factors unchanged).
I think the cause of this problem is power supply stability or output.
From what I’ve read, any (reasonable) 5v 2A USB supply should run a RasPi with a shield or two and WiFi. The old USB wall wart was rated at 2A, as were the outputs on the 2 Anker multi-port units used before moving the project to the rabbit building. I’ve used all 3 of these supplies successfully for RasPi’s and Arduino, but none of the other projects involved as many powered parts as this one.
I don’t know where the “limits” are short of seeing Pi crashes. My understanding is that insufficient power can cause the Pi itself to crash or reset, especially if multiple shields or USB devices are added that consume a lot of power (relative to USB levels). I’ve not experienced Pi crashes with this (or any other) project, and I have used multiple shields plus USB WiFi on other projects with these and other supplies without problems.
I have found articles about cable length at low DC voltages. Sounds like current or voltage drops as the wires get “longer”. I don’t know enough electronics to know if my cable lengths “qualify”, but the symptoms I’m observing suggest they could. Otherwise why would changing power supply make such a dramatic difference in system performance?
I would appreciate input on this from you and your team. Am I diagnosing this correctly? Are larger Grove setups are more sensitive to power supply output stability (again, multiple assuming shields and USB devices)? Could the IO Error rate indicate that current or voltage had declined at the sensors enough to cause communications or sensor failure? I’ve assumed that one could fill up all the Grove ports because they were there - haven’t seen anything to the contrary, but is this assumption valid?
Here is an inventory of the parts in my project:
1 - RasPi mod B
1 - 2.8" TFT shield (Adafruit, goes into power save unless I am using the keyboard)
1 - RGB LCD shield (Adafruit, displaying all the time)
1 - USB WiFi (Adafruit - large antenna version)
1 - USB RF dongle for a Logitech wireless keyboard
1 - GrovePi
2 - Grove DHT Pro sensors on RJ45 cables
1 - Grove temp sensor on 1m cable
1 - Grove air quality sensor on 20cm cable
3 - Grove LEDs (one is on at any given time, others off)
4 - Grove RJ45 extender endpoints (2 pair, 2 cables)
2 - Grove relays (10A version, used to open/close override circuits on 2 Johnson 419 thermostat controls)
Scanning my error logs, the majority of errors that I am seeing come from the DHT Pros and temp sensor, all of which are on “long” cables. The next most common seems to be the air quality sensor. Errors seem evenly distributed between write and read.
I am letting this run for a few days. Will update.