I am hoping to set up a climate control for my greenhouse using Raspberry Pi 5 and I2C temperature and humidity sensors like DHT22. Minimum config will be to run the bus from the RPI-5 at the front of the greenhouse down the centre 15 metres and then split left and right so 2 sensors will be 8 metres apart in the tops of the roof apexes (dual tunnel greenhouse 4 metres off ground) and 2 more sensors at bench height 1.5 metres off ground and 12 metres apart. Basically, a star config at 15 metres from the RPI-5 with 4 leads at 10 metres long going to the 4 sensors.
Is this achievable? What hardware will I need to implement this solution? I am a newbie and do not even have my Raspberry Pi yet, but programming is not an issue for me. Mostly I need help with the I2C hardware side of things.
I don’t think this would be possible using I2C which is designed for just a few centimetres. I think some have got it to work over about 1m or so but I your requirement s way beyond that. Not sure but I think there is a limit to the number of I2C devices on a string also.
Cheers Bob
Could you provide a drawing of some description of EXACTLY what you have in mind please.
Hey there, @Rod321444, and welcome to the forum. Glad to have you here.
Bob is right, I2C needs a fairly short range to get good signals.
For something of this length, you’re going to need RS485 connection. At low baud rates, you can quite literally have over a kilometre of cabling.
Although, really, that’s still not the best option. Unless security is the primary motivator, it will be much more efficient to take the wireless option and hook each DHT22 directly to an ESP32C3 and then sent MQTT data to a local broker on the Pi 5. Much more efficient, less chance of tripping over cables.
Hi Jane, Rod.
Of course the other problem which could be governed by Murphys law is that there is a very good chance that these sensor outputs could be I2C only which will raise another can of worms.
Cheers Bob
I myself have a hobby greenhouse automation project, and use i2c for most of my sensors. Mine is only small (2m x 2m x 2m) though, so not the same issues you have.
As you have noticed, there are lots of different sensors which use i2c communications, and it is well supported … so I did some research into extending i2c’s range beyond a circuit board. For a total distance up to 1 metre, Core sell
To go further (100 feet claimed) there are QwiicBus EndPoint and MidPoint devices.
I haven’t used QwiicBus, so that’s not my recommendation - I expect it will be more expensive than other options in your environment. Personally I like Jane’s suggestion of connecting the DHT22 (and other devices) to microcontrollers distributed around your greenhouse; maybe with a few sensors connected to each.
Do you have 240V mains power (or 24V or 12V) available throughout the greenhouse, or at one end ? I think this could be an issue. Each microcontroller will want 5V power, and a Raspberry Pi likes a bit more power than a standard 5V supply provides.
You mention that programming is not an issue for you … if you prefer C++ then you will probably go with arduino or ESP32 microcontrollers. Python is also a good option. I personally like ESPHome for IoT on ESP32 microcontrollers because it uses YAML configuration files to build firmware incorporating hundreds of sensors, displays and other components including wi-fi and MQTT.
Thanks everyone. Looks like the simplest solution is to set up a HTTP server on the raspberry Pi and use esp32(s) each with a sensor for the monitoring points. Set up a loop with an interval on the esp32 devices to read the sensor values and then send the data to the HTTP server on the Raspberry Pi. Would welcome any comments or further suggestions.
We could probably make that even simpler by using MQTT publish / subscription model. Just set up a broker on the Raspberry Pi using something like Mosquito, then get your ESP32 to publish that data to a feed at regular intervals. Anything that subscribes to the feed will receive it more or less instantly.
If you want a wired configuration, maybe a CAN bus as used in automotive and other applications would suit. Each sensor would need a microprocessor and a CAN bus driver. That would be a few dollars - e.g. PIC16F15223-E/MG 80¢ (element14) CAN tranceiver approx $2 from reputable supplier but much cheaper from China. CAN bus can be as long as you like (within reason) depending on the speed. e.g 500 kbit/s - 100 m (328 ft). Over 100 devices per bus. Just a suggestion.
I might have stepped in a bit quickly. I did more reading. Certainly the CAN bus would be ideal for this strung out multi sensor situation, it’s what it was designed for. But the microprocessor needs to deal with the CAN bus protocol and I don’t think the PIC16F15223 does in hardware. It would have to bit bash which is not desirable. However Microchip has many that have dedicated on board peripherals that do, along with I2C interfaces. It’s a well established standard (> 40 years) and there’s plenty of documentation out there.
It’s a good idea and there are certainly ways of getting microcontrollers to work with the CAN Bus Protocol, such as Adafruit PiCowbell CAN Bus for Pico - MCP2515 CAN Controller (SKU: ADA5728) for the Pico, so microprocessor compatibility is not necessary out of the box.
With a personal project like this, however, I am always going to recommend wireless IoT devices. As someone who has been renting my whole adult life, I find exposed wires either become trip hazards, eyesores, or a loss of bond (I have known a few people who put patch ports in walls without landlord or electrical permission). Wireless gets around all of those problems.
