Extend contact closure from one site to another


#223

Here ya go: https://go.particle.io/shared_apps/5c0eceded16c1f0c07002794


#224

Hi Brian,

So sorting through this it looks like the first thing you need to know is the value for the Status event the pump board is publishing to. I would probably recommend writing that sort of information to a Particle Variable so you know what’s going on with the board rather than an event which only lives for 60 seconds on the server.

The next thing you really need to do is plug a USB cable into the board, open a serial port monitor and power cycle the board. The board will print out information and should give you and idea as to whether or not it is able to communicate to the particle cloud.

I’d say until you know these things it’s going to be hard to troubleshoot.


#225

Geezzzz… that code got long, to turn on a relay :grinning: Only 200 lines
Sorry, I couldn’t help myself.


#226

:joy:

Got to turn it off too!

Of course, some of that stuff is left over from the very first pass. I’ll clean up some of the extraneous stuff statements - like all the Serial.println statements that I don’t think I need - later.


#227

Hi again Ryan,

Things have been working quite nicely since my last post here. Until yesterday, that is. I experienced an issue that I think is Electron related but may be NCD related; I can’t tell for sure. Although you claim not to be a programmer, you clearly know more than I do in that arena, so I hope maybe you can help me figure out what happened, why and how to prevent it from happening again.

Issue: at the moment there is only one household connected to the water system here. The residents have a very stable usage pattern that results in a very predictable period between the tank’s call for water (typically ranging between 31 and 35 hours). Based upon that behavior, I expected the tank to call for water about 6:30 AM yesterday (the 20th), but it did not. It kept sending out zeros according to my 3-minute publish interval for more than 48 hours before I started to get really concerned.

There is a second, lower float switch in the tank that turns on a red light at the site when the tank is almost empty. That red light was on, causing me to believe that the higher float switch that is connected to the NCD relay board there was defective or somehow got hung up. But before I took the cover off the tank to investigate, I decided to reset the Electron. I did so not by pressing the reset button but, instead, by re-flashing the same firmware code that had been running on it successfully for several days. Immediately after the code was flashed, the Electron started sending ones as it should have started doing much earlier. After that it took considerably longer for the tank to refill than usual since the level in the tank had fallen well below the point where the pump is usually turned on.

The fact that resetting the Electron solved the problem certainly suggested that the issue was with that device and not the relay board. Do you agree? In any case, what might have caused the misbehavior? There is no way I can afford to be watching the logs continuously and reset the Electron should this happen again. Is there some code that I could add that would periodically reset the board automatically or, perhaps, refresh the inputs?

Any insights that you - or Travis - can offer would be greatly appreciated.

Brian

https://go.particle.io/shared_apps/5c1837e587ec4c682b003167

Ignore the code that relates to the transmission of keep alive messages; I’m going to remove that.


#228

Hi Brian,

I don’t see anything inherently wrong with the code. However I have a theory(always do it seems).

The Electron has a battery attached which means if there were a temporary power loss it would stay powered, however the MCP23008 chip on the board would not be battery powered. So if the Electron stayed powered up(code running) but the MCP23008 chip lost power it would need to be reinitialized. Initialization of the chip happens in controller.setAddress(0,0,0); You could just call that function once per hour or so to ensure the chip is ready to accept commands. You could test this theory by just disconnecting power from the board, wait a minute or so, then connect power again. You could then tell if that were the case.


#229

That is interesting, Travis! More so because the statement ‘controller.setAddress(0,0,0)’ was in your original firmware version. I removed it after the ‘62’ & ‘63’ status codes problem because I didn’t know what it did. Now I do! Back in it goes.

Thanks as always!

Brian

Oops: just looked. That statement is still in the firmware where you had it originally: in the ‘setup’ routine. I’ll add it to my loop with a timer.


#230

If Travis’ theory doesn’t work out, it may be Heap Fragmentation, sometimes caused by Strings in your Code.

Here’s some code I use to Remotely Reset Electrons from the Console. You could also call this function or System.reset(); from your code on a timed schedule (once a day if you wanted).


#define DELAY_BEFORE_REBOOT  2000
unsigned int rebootDelayMillis = DELAY_BEFORE_REBOOT;
unsigned long rebootSync = millis();
bool resetFlag = false;


void setup() {
// Remote Reset Function        
  Particle.function("reset",cloudResetFunction);
}

void loop() {

// Your Normal stuff goes here

if ((resetFlag) && (millis() - rebootSync >=  rebootDelayMillis)) {
    // do things here  before reset and then push the button
    Particle.publish("Debug","Remote Reset Initiated",300,PRIVATE);
    System.reset();
  }
 
  

}// End LOOP()



////////////////////////////////////////////////////////
  // Remote Reset Function       
int cloudResetFunction(String command) {
       resetFlag = true;
       rebootSync=millis();
       return 0;            
}

This is another reason to consider adding a pressure sensor and having the Well’s Electron function as a Stand-Alone Controller (as a backup) when it sees a low pressure in the water main :wink: