- This topic has 3 replies, 2 voices, and was last updated 7 years, 8 months ago by
.
-
Posts
-
Ray would you be willing to make a breakout plug and input for the I2C interface on future hardware releases?
This would open up a plethora of sensors and could be used to add multiple sensors to 1 unit. Having flow sensors and a rain sensor, and say a tank level sensor all working together could lead to some pretty interesting uses and would vastly broaden the market. This would also separate your device from many others on the market.
It would also have the benefit of being able to add more NVRAM space to some of the older hardware by making it well known that the pins are built in to the device already. It would mean that those with older units could add the newer features by making a modification similar to what the new hardware would look like.
Just a thought and i do understand retooling a case and adding a few bits gets expensive in volume, however, I believe the cost would be far outweighed by the benefits it could afford users.
Sure, that’s a good point. I think at the moment the I2C pins are already mapped out in the pin-out area. Do you have any suggestion how to improve it?
Well not being the guy that has to work with revision of the case or boards, my if I could have everything wish would be for a pin setup like the current sensor input is designed. Maybe just another set on the top or something.
Knowing that requiring a remolding of the case could add costs, perhaps just a set of pins inside tucked up by the LCD,then if someone wants to use that connector they could figure out how to get a wire in there.
The biggest reason I ask for a change though is the capabilities that could nearly become drag and drop additions to the firmware. I’m currently working on the request to water using light accumulation, and discovered the pins and then the documentation for them over on rayshobby. Code wise I have to do very little to add the sensor and make it fully functional, however, I had to make sure the person requesting the feature could solder in pins. If they for some reason we’re unable to do it, adding the light sensor would be a pain firmware-wise because of the digital input to OS versus the analog nature or I2C output of most light sensors.
I’m super happy with the breakout right now, as a person that tinkers with everything, but I could see some pretty keen uses if more normalish people were able to take advantage of the built in functionality.
Basically I could see more uses for systems in greenhouses, or indoor plant watering. Or even off grid uses with localized weather stations. Another would be using lift or well pumps with limited supply. I2C just opens up a broader range of sensors, with simple mods to the firmware, that the current sensor port simply can’t handle. Of course cost benefit analysis would need to be addressed as I’m not a part of the financial side of things, but it seems to me more beneficial than not.
In summary, a small 4 pin (V+, GND, SDA, SCL) breakout through the side of the case somewhere would be great.
OK, that’s a pretty solid explanation, thanks. It’s actually the right time to bring up connector suggestion, as we are in the process of redesigning OpenSprinkler and prepare the next version 3.0, based on ESP8266 WiFi chip. Due to the small number of GPIO pins on ESP8266, it will make use of several I2C devices (RTC, LCD, PCF8574 IO expander), so the plan is compatible with what you mentioned, which is to rely on I2C devices. Another important design decision is that it will adopt modularized design — there will be a ESP8266-based main processor board, that contains the WiFi chip, LCD, buttons, RTC, RF transmitter-receiver headers; and a power+driver board that contains the power conversion circuitry, IO expander, and solenoid drivers. The main processor board will be plugged into the driver board. So the whole assembly will be slightly taller, but the footprint will be roughly half the size as before, so it looks every smaller than the current OS. The main purpose of this ‘split’ design is such that the ESP8266 main processor board can be used standalone, as a USB-powered gadget, but also it can be plugged into different driver board, like a thermostat driver board to make a new product, OpenThermostat. This will make it easy for us to manage stock and new products, without having to redesign the whole circuit from scratch over and over again.
Anyways, the reason I mentioned this is that to allow the main processor to be used as a standalone USB-powered gadget, I considered some possibilities of additional sensors. For example, there is a 1×4 I2C pin header reserved for a temperature/humidity sensor (like AM2320), and there is an on-board light sensor. This will make it possible to use the main processor board as a light / temperature / humidity sensor board, which doesn’t drive anything, but can sense, log, and transmit sensor values. It does also have the capability to remotely control RF power sockets (the RF transmitter and receiver pin headers are on the board).
It would be pretty easy, certainly, to duplicate this 1×4 I2C a couple times, to allow even more sensors, like you said. And I may vary the order of the pins too because the ordering of the pins is sometimes not consistent on different sensors (like some do VCC GND SDA SCL, but some will do VCC SDA SCL GND). If you have some particular sensors in mind, feel free to let me know. I think there may be just two or three common pin orderings.
But in the end, these will probably still require some small amount of soldering to connect additional sensors, unless if we know pretty sure which particular sensors will be used (in which case we can design dedicated enclosure cutouts). For now the enclosure isn’t a huge issue because we will continue using acrylic enclosure like what we’ve done on OSPi, OpenGarage and OSBee. The acrylic enclosure is much easier to redesign without paying a huge upfront mold cost.
- You must be logged in to reply to this topic.