I am currently wiring that sensor and a YL-69 to a Mega 2560. Since there isn’t a lot of pins on the Electron, I decided to vet the sensors on the Mega 2560. I’ll have some stable code to compare against the particle library. Somewhere, I acquired a YL-69 moisture sensor. I haven’t found any real calibration for it. Once I know the total amount of sensors I want to deploy, I can do some balancing between the Electron and the Mega 2560. I’ve figured out the wiring needed to get the SparkFun Weather Shield operating on the Mega 2560. With I2C operating between the two I can have the Electron pull data via I2C with the sensor attached to the Mega 2560. Why use the Mega 2560? The Particle Relay Shield just ate 4 of the digital pins.
The one thing that bothers me about the sensor libraries using I2C is each one seems to create a master in their constructor: Wire.begin(). That isn’t going to sit well if I’m going to be using I2C at the top level to communicate with other devices. If I am trying to read a sensor over I2C and another device triggers any other event then there is a collision.
So, there will be four things to balance at least:
- Serial events
- Interrupt events (sensors that are collecting pulses over time; wind/rain)
- I2C events
- Particle function events
- Other network events: tcp, udp (if used)
JTOL (just thinking out loud): The function events can be queued for later processing. The command could be captured and a response sent back to the cloud (positive integer indicating number of messages in the queue). That would keep those sections of code short and sweet. The queued actions would take place when possible.
Takes me back to the days when I was playing with a Campbell Scientific data logger.
Anyway. Let me know if there is something specific that needs investigation.