Remote pump control ideas.

[Dannyx]

Re: Remote pump control ideas.

it's piss-poor security to use a public network.
typical corporate scumbags.

No idea, TBH, how it all operates and how it's hooked up - it's probably a LAN. We use this setup for CCTV IP cameras in another town - no actual "internet" there, just a LAN which connects together key buildings like the town hall, police stations and the mayor's home from what I know....

[Dannyx]

Re: Remote pump control ideas.

I brought my arduinos with me today at work to play with this project a bit. I didn't get very far because I only have a Mega and some Minis and I didn't bring the programmer with me so I can't program the mini....I tried using the Mega as the programmer but couldn't get it to upload - I read something about hitting the reset button at just the right time, but I couldn't do it, so I played around with the Mega for the time being.

Moving away from that for a moment, I'm trying to achieve some rudimentary way of telling whether the two stations are connected or not...I was thinking I could do it like this:

void loop() {

while (!pumpServer.available()) {bitSet(PORTB, 7);}
bitClear(PORTB, 7);

What I tried to achieve there, for proof of concept is to make the onboard LED come on and go off depending on whether or not the client (the arduino listening on the float sensor at the other end of the town) is connected. This would of course be replaced by a warning light or a message of some sort and would also trigger a shutdown of the pump to ensure it doesn't overflow....trouble is it's not working. I must be doing something wrong - I'm no programmer, as I said It does come ON on startup, since there won't be a client connected at that point, so my "not" statement seems to be working but it won't go OFF after that, even when it seems logical that it should, when I initiate a connection to the board.....not sure what the fault is - I'm probably not using the .available command right, though the tutorial says it turns true when a client hooks up, so the code should break out of the while loop, advance forward and run my "bitClear" at that point, but it's not :|

[Dannyx]

Re: Remote pump control ideas.

I managed to cook up something on my own after all - I've been at it for the past week. As always, I'm not a programmer so my code is most likely a disaster, albeit functional....I may actually share it just so I can get roasted

I also learned a bit more about the particularities of the current GSM setup by speaking to the guy who actually deployed it. He actually made a video for me too. The pump in question pushes water to some tanks upstream, so the idea is to shut it off when the tanks are full and run it when they're empty. There's two float-switches: one near the bottom of the tank, one at the top. The boards in the pictures are actually dialers commonly used in security systems: when a "zone" is closed/open, the transmitter dials a number and (I assume) sends a digit to the receiving station corresponding to what it wants it to do. I imagine it's similar to those "press 2 for English" messages, except you don't hear it. There's no acknowledgement between the two: the receiver (pump end) doesn't actually reply back to let the sender know whether it ACTUALLY shut down the pump or not, which is the biggest drawback. Another drawback is the poor reception of the transmitter end, which again causes lack of communication and possible overflow, since there's no supervision or failover mechanism/timeout at all. The pump keeps going until it's told to shut-off....

The system DOES have one neat trick and that is to SMS a number if the pump experiences a fault - I couldn't quite understand how this works from the guy's clip, but I imagine the pump goes through a motor protection contactor which trips if there's an overcurrent on the pump itself and it's got an auxiliary contact which simulates a triggered "zone" on the dialer. I'm thinking of tapping into this myself to let someone know if there's loss of connectivity or some other error I may think of.

My system: one Arduino (or something similar that takes the code I wrote) at either end, with an Ethernet shield (attached, or built-in). Upon initial startup, the "server" (pump) side begins "listening" for incoming clients. The client at the other end connects to the server's IP address. The two float switches connect to two pins (ports) on the client Arduino - for run and stop. Depending on which closes, the client sends a string to the server to start/stop one of its pins. Each command "echoes" back to tell the client whether the server has actually responded and carried out that action. The reason I included this is because during my tests I noticed sometimes my string gets corrupted and produces a garbage output at the server end: say the client sends the command "RUN", the server would sometimes get RU?? or some placeholder character and would get stuck. Only when it gets a clear "RUN" does it send an "acknowledge" back to the client - if it doesn't, the client tries the command again until it gets an "ACK".

The server also "pings" the client every X seconds to ensure it's still there. It does this by sending a string which the client picks up and replies back to with an "ALIVE". If there's no reply, the server retries X times before setting an alarm flag and starting a maximum time for the pump to run, to ensure it doesn't overflow....haven't quite figured out the right amount or how to do this better.

Likewise at the client end, if there's no "ping" coming in for more than x seconds, it means something's wrong and the client retries to connect to the server. This was necessary because I tried unplugging the network cable from one of the boards and it doesn't reconnect when it's plugged back in - you HAVE to reset the board to get the client to connect to the server, but I managed to find a workaround by doing this. No reply for X seconds forces a retry, and another and another until it finally manages to get through, if ever. Because there's no client, meanwhile the pump side starts its "standalone" mode which shuts off after an aproximate time.....WHEW That was fun

[stj]

Re: Remote pump control ideas.

you want spare sensor inputs,
it's common for remote systems to also watch the building for fires, flooding or intruders(door sensor)

[Dannyx]

Re: Remote pump control ideas.

Not necessary in this case, but could be added later on....I also managed to score the user manual for the GSM boards currently in there thanks to this chap who installed them. It's HERE if you wanna take a look.

[diif]

Re: Remote pump control ideas.

Not necessary in this case, but could be added later on....I also managed to score the user manual for the GSM boards currently in there thanks to this chap who installed them. It's HERE if you wanna take a look.

Page 8, Antenna Installation.
Never install in the following locations: inside the metal cabinet. Closer than 20cm from the power lines.

[Dannyx]

Re: Remote pump control ideas.

Not sure where the antenna is located exactly, but I was thinking of leaving this system in place as well as a sort-of backup in case something goes wrong with my super high tech setup

[diif]

Re: Remote pump control ideas.

Not sure where the antenna is located exactly, but I was thinking of leaving this system in place as well as a sort-of backup in case something goes wrong with my super high tech setup

You can see it in the photo, in the metal box draped around the power wires.
There are only two "Never install in the following locations" in the instructions and both have been ignored.

[Dannyx]

Re: Remote pump control ideas.

Yes, but that's the wire for the antenna - we're not sure if the antenna itself is actually inside the box....

[stj]

Re: Remote pump control ideas.

but it's not double-screened, so your inducing AC noise onto your groundplane!

[Dannyx]

Re: Remote pump control ideas.

With my project taking shape, despite the awful code it's time to think of the hardware I should actually use to deploy it. Throughout the "design" phase I used my personal Arduino Mega, Pro Mini 328p, w5100 shield on the Mega and 5500 on the Mini, with the Mini being the client and the Mega being the host.

Ideally the final boards should be something industrial which still accepts C++ code in the Arduino IDE. It must also have Ethernet. Too many I/O pins are not necessary. I'll definitely not use Dupont wires for this project - I'll desolder the headers (if the board I settle for doesn't have a "bare" option) and solder my wires straight to the board. Both ends run at 12v, with the "client" one, located at the tank side where the float switches are, running on solar power, so energy conservation would be desirable, though not necessarily required. I'm not sure of the thermal environment these things will be running in, since I haven't visited the site yet, though I do see a fan and thermostat at the side of the box there...

STJ suggested the STM Nucleo, but looking through the website where our company will order them for me I couldn't find one with Ethernet - either they don't exist, or I'm not looking in the right place...

The Arduino Yun also seems to be a good choice, since it's got Ethernet AND seems to do some crazy Linux stuff which I could learn further down the line, but don't know anything about yet

[stj]

Re: Remote pump control ideas.

nucleo144 boards -most have ethernet.

and here is an arduino support page for which boards it supports
https://github.com/stm32duino/Arduin...leo-144-boards

[Dannyx]

Re: Remote pump control ideas.

Should I be worried my sketch is too big to fit on one of those things or other stuff down the line which would make my project not run so well on a different board than the one it got conceived on ?

I found the L496ZG for a decent price, which is less than an Arduino Yun which I originally had my eyes on...

[stj]

Re: Remote pump control ideas.

look at the databrief, it will list which have ethernet, then go for big memory if your concerned,
i have an F746ZG somewhere here - that's pretty high end, with 1meg of flash.
compare that to 32k in your nano/micro!!

[Dannyx]

Re: Remote pump control ideas.

Ok, I just screwed up - L496 doesn't have eth (no RJ45)....I was looking through the specs and missed that part entirely F767ZI has it...

[stj]

Re: Remote pump control ideas.

btw probably obvious,
L = low power
F = fast
H = dual-core version of F!
first number afterwards is the core series.
3 being low spec, 4 is good, 7 is serious power!

last 2 digits is the pheripherals on the chip

so an F7 is seriously powerfull

[Dannyx]

Re: Remote pump control ideas.

btw probably obvious,

Nope, so thanks for clearing that out - it's probably mentioned somewhere in the documentation which I haven't read because I've become a lazy bum lately

One thing I DID read is that they're compatible with Arduino shields, so I might add a card slot to host a control webpage....don't know how to do that just yet, but it's good to know it can handle it.

[stj]

Re: Remote pump control ideas.

well.... - most of those boards have usb-otg, so you could just use a usb-stick instead of a card.

[Dannyx]

Re: Remote pump control ideas.

Even better. Like I said - I don't know squat about this stuff. I just learn as I go, piecing together various projects and examples to form the end result

[Dannyx]

Re: Remote pump control ideas.

I finally went to see this pump control system in person and take some pics of my own. It's about what I expected. The tank is located up on a high hill and its control box is solar-powered by that blue charge controller and battery. The battery appeared to be flat, according to the flashing red LED on the controller, despite the green LED indicating the status of the photovoltaic panel indicating adequate performance. It could be because it's been rather cloudy lately or because the battery itself is long in the tooth, or the controller's faulty somehow - I haven't touched anything at this point.

Down in the foothills where the pump shack is, there obviously IS constant 3 phase 400v utility power running our box, which is also much more involved: there's the main contactor, an overload switch, a phase monitoring relay and a handful of different goodies for me to play with.

I'm not sure how to best handle the case where the two ends lose communication. The local official who accompanied me on my visit told me it'd probably be best to just shut off the pump and send an SMS alert to someone, which the system actually does already through its GSM modules, though I'll need to modify this a bit so it's the Arduino who sends out the command to the GSM module when it can no longer ping its buddy up on the hill...

Other than that, I'm not sure whether I should have a "manual" mode as well, which would allow the pump to be turned on/off locally with some buttons, regardless of the status reported by the MCU up on the hill, as this could lead to someone forgetting it in the ON position and the tank overflowing...