Hi Brian,
That stuff is above my pay grade 
You can contact DeeAnn directly if you like, her email is orders@ncd.io. She can help you with returns, refunds, ordering, etc.
1 Like
Travis/Ryan: here’s your weekend update; lots to share.
-
As you will recall, the relay board at the pump had recently become erratic. Sometimes it would supply power to the Electron and other times it would not. Some times when the tank called for water by sending 1’s, the R1 LED at the well would not come on and the relay would not close. On a later occasion (yesterday, maybe, or Thursday) - when I was not on site to observe relay status visually - the event log for the Electron at the tank showed that it was again calling for water and an hour or two later it again started sending 0’s, showing that for that specific occasion, at least, everything was working. Note that during this entire period it was pretty cold outside, in the mid to high 30s.
-
As you will also recall, when I first tried to flash Ryan’s most-recent code, it failed to compile. Ryan suggested a reduction in the length of a long function name because of a 12-character limit. After doing so, the code did compile and did flash to the Electron, and the ‘Pump_min’ function has now showed up in the Console (I also reverted back to 0.8.0 yesterday).
-
It is much warm today (Saturday), in the high 50s. The Electron at the well is getting power from the relay board (but still has the battery attached, too, since it’s running 0.8.0) and its cellular connection - which had become very unstable in recent days - is solid (but still only ‘Fair’ per the Device Vitals).
-
With the entire system currently stable (knock on wood again), I tried Travis’ ‘controlRelay’ function while also viewing the relay board for the first time. I sent ‘1ON’ and BINGO, the R1 LED came on, the relay closed and the pump came on. However, when I retrieved the ‘RelayState’ variable’s value, it came back ‘0’. It should have been a ‘1’ (if I understand the code properly), right? When I later sent ‘1OFF’ the LED went off, the relay opened and the pump stopped. Voila!! Sunday update: a call for water today by the float switch resulted in another satisfactory tank re-fill, and this time the ‘RelayState’ variable properly reported ‘1’. Yippee. Note, also, for the first time the event log for the unit at the well started showing '1’s (every second) rather than '0’s; that’s the first time I’ve ever seen that!
-
I next tried Ryan’s ‘Pump_min’ function by sending 2 for a 2-minute run time. The R1 LED came on for less than a second. I heard the pump’s relay close and immediately re-open. Only a single entry appeared in the event log (see attached). So there appears to be something missing in that function’s parameters.
-
Ever since Travis added some diagnostic routines to the code, the Electron at the well is sending out 0’s ever second, greatly exceeding my Particle data allowance. I don’t understand why that Electron would be sending anything other than diagnostics since its role is to listen, is it not? How can I make it stop doing that? Sunday update: I got a warning from particle that my 10 MB data limit was nearing, so I increased the limit to 20 MB. Monday update: awoke this AM to discover that the SIM at the well has been disabled because I reached my revised 20 MB limit overnight. Aaargh!
-
As Travis knows, I have ordered another relay board due to the funkiness of the current one at the well (I think temperature has something to do with it). Once I receive it I’ll report back on results. I have also posted an inquiry on Particle’s forum regarding the instability of the cellular signal at the well. The Electron at the tank is rock-solid, but the one at the well was disconnected more than it was connected yesterday, on/off, on/off all day long). Sunday update: no one has yet answered my question on the Particle forum about way to improve cellular reception, but I did find an earlier question of a similar nature and, based upon that, I have ordered an external antenna (and IPEX to SMA adapter). Probably won’t help, but it’s cheap so worth the test. I’ll report the results in case you’re interested.
-
A question that I think I asked before but did not get an answer to: if the relay at the well is closed but then the cellular link between devices drops, will it remain closed until the link is re-established (maybe overfilling the tank) or does the app firmware there open the relay if it does not receive those regular messages from the tank? If it will remain closed, is there a way to add the ability to open it if the firmware fails to receive regular updates from the other end?
Can you guys help with the following:
Ryan, can you help with a tweak to your code so that the Pump_min function works correctly?
Travis, can you advise how to stop the Electron at the well from sending so much data? Also, if I want to change the Electron at the tank so that it sends events only every 2 minutes (or some still-longer interval) rather than every minute, where/how would I change that in your code? Note that I have tried every modification to the code that I thought might possibly be the governing parameter, e.g. change the ‘Particle.publish’ parameter, but there was no change in the event interval (I put everything back)
For either of you: why would the ‘RelayState’ variable always return a ‘0’ even when relay #1 is closed? Is that a problem with the Electron’s firmware, the board’s firmware or perhaps a hardware fault somewhere? Sunday update: This started working, so this question can be disregarded.
Hi Brian,
Go to build.particle.io and open your current code running on the Well Pump board. You should see a Share this Revision button on the left. That will give you a link which you can share here. With that we can view the code you are currently running, make modifications, and send it back. I believe I know the problem with the Pump_min function. I’ll have to look into the 0 publishes though, can you confirm it is the Pump board sending the 0 publishes or is it the tank board? If it’s the tank board then share that code revision also.
Out shopping right now but will be home in about 40 minutes and will share then. The ‘0’s are from the well site and the every-second thing started back when you added some diagnostic routines.
As I also mentioned, when the pump was running yesterday, it was sending '1’s as I think should be expected.
Here’s the link to the pump code Travis:
https://go.particle.io/shared_apps/5bf1b88cf1e96d194800048c
Although there are no urgent issues with the code at the tank, I did inquire about how to change that timer as well (from the current 60-second interval to something longer). Here’s the current code for that Electron (unchanged from your very first version): https://go.particle.io/shared_apps/5bf0b9d87f4e914fdf000dd3
Note that at one point I un-commented your well/pump code relative to PaperTrail and entered my PaperTrail credentials but I got an error when I tried to compile it. After we get this most urgent problem addressed, I’ll try that again and share the error with you.
Brian
Hey Brian,
You say the well pump board is publishing 0’s. What is the name of the event those 0’s are being published to?
I/O_Data, per the screenshot I included in my Saturday post.
As mentioned, while the pump was running yesterday the Electron was sending '1’s rather than '0’s as I suspect it should have.
Strange, that should only happen when the Tank board publishes. I removed that publish and fixed code so the Pump_min function should work. Here is the updated well pump code:
https://go.particle.io/shared_apps/5bf2f0af85907fd79c000443
Can’t flash your revision yet, as the Electron is disconnected from cell service yet again.
While waiting for it to reconnect, can you tell me exactly where in the previous code that 1-second timer was defined?
You Data usage is likely being driven by all the OTA Firmware Flashes.
You can reduce your Data by having the Tank only Publish every 10, 20, 30 minutes or more.
AND - At the Well Site, have it close the relay for a specific Cycle Time for the Tank.
Thought Process: Your tank contains a specific volume between On and Off probes. Your Well Cycle should be fairly constant time periods to refill this specific volume, only changing as the water system demand changes. For instance, if the well normally operates for 2 hours to refill this volume then you could have the Tank publish a request for water every 10 minutes. The Well will automatically open the relay after 2 hours (whatever your normal Cycle Time is) if it has not heard from the Tank that it’s FULL within that time period.
This Control methodology:
- Lets the Tank “REQUEST” water every 10 minutes as a fail safe, in case the Well didn’t start on the first request for water.
- Makes the Well fill the tank even if it only gets (1) request from the Tank. It will shut-off even if it never hears back from the Tank, but normally stops as soon as the Tank is full if Both Electrons are connected to the cloud.
OK Travis. I flashed your modified code. The 1-second events have stopped altogether - YAY - and the Pump_min function works to the extent that it turned the pump on and it stayed on. However, it has not shutoff after 5 minutes so far (set it for 2 minutes). Turned it off with the controlRelay function (1OFF).
I like that idea a lot, Ryan. May need some help with the code, though; I’m still trying to learn C++
First things first, though; I want to get everything working correctly first and it appears that we are very close with the changes that Travis just made. Need to get the Pump_min function fixed so that it turns the pump off after the allotted time and I need to get the PaperTrail routine functioning.
Oh, and BTW, the excessive data usage by the Electron at the well was the 1-second updates. I increased the data limit from 10 MB to 20 MB last night just before I went to bed (because Particle sent me a warning). When I got up this AM, I had already reached 20 Mb (no firmware upgrades while I was sleeping)…
Since the integer tempRuntime is already ms : {Minutes from Console * 60 seconds * 1000 ms}
We shouldn’t need the *1000 in the While Loop.
while ( (millis() - previousMillis) < ( (tempRuntime * 1000)) )
I guess its safer to declare tempRunTime as an Unsigned Long (and as a Global Variable at the top of the CODE), since millis() and previousMillis both are UL’s and the units are both ms.
I’ll make those changes.
I made tempRuntime a static unsigned long , and removed the * 1000 in the While Loop.
Now I’m going to see if I can figure out out to send the same ‘Pumping Now’ and ‘Pump Off’ events when the relay is commanded by the tank, not just via your Pump_min function
Looks like you’d do that inside Travis’ myHandler Function like this:
void myHandler(const char *event, const char *data) {
if (manualTimer) {
//Do not react to publishes if command was sent to manually turn pump on for time period.
return;
}
Serial.println("IO Event Received");
String d = String(data);
int status = d.toInt();
String publishInt = String(status);
if (status & 1) {
controller.turnOnRelay(1);
relayState = 1;
Particle.publish("Pump", "Pumping NOW", 300, PRIVATE);
//Lets log that the pump just turned on
// Log.info("Pump Turned on");
} else {
controller.turnOffRelay(1);
relayState = 0;
Particle.publish("Pump", "Pump OFF", 300, PRIVATE);
//Lets log that the pump just turned off
// Log.info("Pum Turned off");
}
if (status & 2) {
controller.turnOnRelay(2);
Particle.publish("Pump", "Pumping #2 NOW", 300, PRIVATE);
} else {
controller.turnOffRelay(2);
Particle.publish("Pump", "Pump #2 OFF", 300, PRIVATE);
}
}
One step ahead of you for once, Ryan, except the ‘Pump OFF’ event repeats every minute. I haven’t pursued it yet, but I’m sure that’s because the code loops through that routine repeatedly every minute, so it should be an easy fix.
I did figure out how to change the event interval at the tank from 60 seconds (60000 ms) to 120 seconds (120000 ms), so that’ll cut my data usage there in half.
Nope; it’s the ‘IO Event Received’ thing. No problem to fix. In fact, I might leave it there as a way to see if end-to-end communications is stable, i.e. if the tank sends a ‘0’ and the event log at the well doesn’t display a corresponding 'Pump Off", then I’ll know when the link disconnected.
And I just realized why, on occasion, if I command the pump to turn on with either function and then ‘get’ the 'RelayStatus" it returns a zero: the next incoming ‘0’ event from the tank overwrites the manual command.