Well, Travis, that worked. Sort of. The first time I bridged those terminals with a wire, the red relay light came on (and some kind of relay action in the well was heard), but after just a few seconds the LED went out even though I had not removed - or moved - the wire. The second time I tried, it worked again and the R1 LED stayed on for a minute or so until I removed the wire; that, of course, is what was expected. Then the Electron lost cellular service for several minutes. When it reconnected, I bridged the terminals again but R1 did not come on, even though I left the wire attached for a couple of minutes. Another two attempts both worked as advertised.
So the questions for you are 1) is there some minimum time after a broken link to the Particle Cloud is restored before end-to-end messaging can resume and 2) what does “spark/status” in the log mean (see attached)?
So let me explain how these devices work and perhaps in turn that will answer most of your questions.
The board at the tank has an input(GP2). If GP2 is connected to Ground it publishes a 1, if GP2 is not connected to ground it publishes a 0. The board will publish a 1 or a 0 immediately when the status of the input changes(just opened or just closed). It will also publish that status once every minute just in case the remote board lost power and powered back up. Think of these publishes as a 1 shot command. For instance lets say you are the board at the tank and I am the board at the pump. If you need water then you yell at me to turn the pump on, if I’m asleep or left to get lunch I wouldn’t know you asked me to turn the pump on, so if you repeatedly(once per minute yell at me whether you need water or not then no matter when I arrive on site I’ll know what you need.
The second board at the pump subscribes to the publishes the board at the tank sends out(on change or once per minute). It will only ever turn it’s relay on or off when it receives a publish from the other board. If it’s relay turns on or off that means the other board told it so. If you power up the tank board, close it’s input so it calls for water and then disconnect it’s power indefinitely the other board will keep it’s relay on as long as it has power. Now that said if the board at the pump looses power and powers back up it will power up with it’s relay off and will not turn it on until it is told to do so. If you prefer for the default status of the pump to be on then wire to the COM/NC terminals on the pump relay board.
Those spark/status events are from Particle themselves telling you the device went offline or came online. We do not control those.
I hope this all makes sense. I’m trying to explain it as best I can. The devices really are very simple.
That helps immensely, Travis. Again, many thanks! My next struggle is to find a way to save and, ideally, export the device log from the Particle Cloud. That would be very helpful as a tool to determine how often water usage depletes the storage tank and how long it takes for the pump to replenish. I’m having a dialog with a couple of folks on the Particle forum regarding this matter, but if you have any thoughts that you’d like to share, please do!
You nailed it. The folks on the Particle forum are extremely knowledgeable and far more experienced with the Particle Cloud than even I am. I trust their advice. I am sure they can help you put together a data logging solution to track water usage.
Another way to track water usage would be a flow meter, not sure if that is something you are interested in or not but it would allow you to track actual gallons used. We do not sell the actual flow meters but we sell hardware that you could connect the flow meters to and then it could log that information to the Particle Cloud.
What would I have to do to get this added to the firmware in the Electron at the tank? Can I do it myself or must you? What might you charge to add this capability? My host and port = logs7.papertrailapp.com:45358
You could certainly use that. I don’t think security of the data you are logging is an issue in this particular instance so the fact that the data is sent insecurely using this system is acceptable.
Customization of the firmware running on the pump board would be required to do this but honestly I would say this is very minor and would probably only take me 15-30 minutes to implement so I’d be willing to do it for you at no charge.
That said I do have to warn you that this will increase the data usage of the Electron module installed in the Pump board so your monthly data bill may increase a bit. There really isn’t any way around this if you want to do it simply. If you really wanted to invest the development time to minimize data usage it might cost a little more on the firmware development so that decision is up to you.
Basically what we would do is send a transmission to PaperTrail every time the pump turns on or off. This amount of data should be pretty minimal. That said if something were to “go haywire” the firmware could try sending multiple logs in a short amount of time and eat data. To put stop gap measures in to prevent that would require additional firmware development time.
Let me know what you think. Go ahead with the simple firmware implementation(no charge for development required) or spend some development time trying to get it as efficient as possible with data usage(could take a couple hours). Honestly I’d probably go with the first solution for now and just keep an eye on it for a bit to make sure it doesn’t eat too much data.
Very gracious of you, Travis. I’m inclined to go with your recommended simpler solution. If we exceed our data allowance, at $.40 Mb it can’t possibly cost us an awful lot more. Let check with the other players to get approval.
Should we upgrade the device OS to 0.7.0 or the latest 0.8.0 release candidate?
BTW, many years ago I did a bit of programming (wrote a Physician’s Answering Service app for a large hospital almost entirely in Unix Shell; just one routine in C), so it might be fun to get acquainted with writing apps for Particle devices. Got to figure out where to start the learning process.
To be perfectly honest I really don’t think there is an easier framework to start learning programming with than Particle if you’re wanting to do some hardware programming.
Check out docs.particle.io and have a look at the firmware section under reference. It pretty much spills out everything you need to know. All programming is in C/C++ which is just a step simpler than C I think since you have objects to work with(makes things much cleaner than old C). I’d start by opening the firmware links I sent you before and just read through the lines until you understand what is going on. If you look at it long enough you will get it. For this project you just need to add in the files for PaperTrail and start referencing it. While I’m adding this to the code for you I’ll do a screen recording and sort of explain what I’m doing to you. It won’t take me any additional time and will give you the opportunity to learn a bit.
Good morning Travis. I have received enthusiastic approval to accept your gracious offer to tweak your code to send the Particle logs to PaperTrail. I’d also very much like to upgrade the Device OS from 0.5.4 to 0.8.0. Can that be done at the same time when I flash your modified code?
And exciting news from our end: until last night, the entire pump control application has been tested only by jumping the GND and GP2 terminals. Last night the water in the well dropped - for the first time since application installation - to the point that the float switch closed (at 4:42 AM). It opened at 6:15 AM. A visual inspection of the tank this AM shows that it is full! Yippee!
BTW, does this statement in your code - “Particle.publish(“IO”, publishData, 60, PRIVATE);” - define the 1-minute (60-second) frequency of messages to the device at the well? If so, could we change that to, let’s say, 120 to cut the cellular traffic in half if we find ourselves exceeding our allowance?
Thanks Travis! Imbibing a fine pint of Iron Rail IPA at Wedge Brewing at the moment but will jump on this as soon as I get home. If you were local to Asheville, I’d pick up your tab too!
Our forum seems to be trying to do something funny with the video link I posted. Click here for the video. Hopefully that will work.
It looks like Build is not pulling in the library for you. Open the code I sent you. Delete Line 2 that says #include <papertrail.h> then click the library icon on the left(looks like a ribbon). Type in papertrail and you should see the library there, click it to select it, then click the include in Include in Project button on the left, when it asks which project to include it in click on the code I sent you. That should pull the library into that project and it should then compile. If not let me know.
You can try upgrading the OS on the module if you like, to do that click the devices icon on the left(looks like a target), then click the drop down for one of the boards and select the OS version to use. Then flash the firmware. That should flash it with the latest OS and the code.
If I ever make it to Asheville I’ll take you up on that beer
As you may have noticed from the extensive ongoing dialog here, I took your recommendation and went with Electrons. AT&T’s (or maybe it’s T-Mobile; I don’t know how to tell) service is present but with low signal strength. I played around with Particle’s device OS 0.8.0 for a brief period to see the ‘vitals’ information introduced with that release and I saw that the signal strength varied all over the place from ‘good’ to ‘fair’ and, more often, non-existent. The attached screenshot of the log shows one of the Electrons connecting and disconnecting repeatedly.
The curious thing to me is that the strength would vary at all. During the period covered by the screenshot, there were absolutely no changes in the environment. No change in weather, temperature or any other variable whatsoever that might affect the signal. Have you seen this? Can you suggest any way to mitigate the variations in signal strength or the affects thereof?
BTW, one of the many reasons that I didn’t stick with 0.8.0 is my lack of trust. Note the battery level in the vitals data. It varied all over the place too, from 97% to 0% to 75%, etc. There are no batteries connected to either Electron (powered off the NCD relay board, of course)!
Lastly, I reverted to OS version 0.7.0 and the disconnects continue frequently. The Electrons are disconnected from the cloud far more often than they are connected. Big problem.
I wonder if this isn’t a power issue. That said I have used these 2 channel relay boards with Electron in the past and didn’t have any issue.
I suppose you could try connecting the battery to the Electron and see if the problem goes away. That’s about all I can think of. @Bhaskar is there any issue with connecting the battery to the Electron while it’s installed in the 2 channel relay board which has the “beefed” up power supply?
I agree, that looks like power issues.
Attach the Li-Po as Travis said and that will give you the answer.
What’s the rating for the actual relay board you have?
If it’s not at-least 2 amp supply, then you will need the Li-Po to handle the current peaks of the cellular modem.
I also noticed a problem with 0.8x firmware while running < 2 Amp boards with no Li-Po. Those were boards that previously ran fine on 0.7x
The battery level in the diagnostics can be ignored if you don’t have the Li-Po connected.
If the Cellular Connection proves to be unreliable, you can always add the pressure sensor at the Well Site. The Electron at the Well can measure the approximate Tank Level and make decisions locally, without the Cloud Connection as a failsafe.
(Previous Post #31)
The 2 channel relay board @blshaw45 has should have the 2 amp power supply so I wouldn’t think it would be a problem but trying that LiPo I think would be a prudent first step in troubleshooting. There is definitely a shot that’s the problem.
