What's the current 'state of the art' on bilge monitoring?

The friendliest place on the web for anyone who enjoys boating.
If you have answers, please help by responding to the unanswered posts.

wkearney99

Guru
Joined
Feb 17, 2018
Messages
2,189
Location
USA
Vessel Name
Solstice
Vessel Make
Grand Banks 47 Eastbay FB
It's been on my to-do list forever... to have "something" in place to help me keep better tabs on how the plethora of bilge pumps are performing on our EB47. Engine room, mid-bilge, forward bilge, galley gray tanks, black water, etc.

There have been a bunch of different approaches to this in the past. Either simple counters, panels that monitor just one or two, but little that really paints a clear picture of what's going on with the pumps. How frequently were they running, and for how long? Short-cycling kills pumps, perhaps even more so than them running for extended times.

What's the latest-and-greatest on this these days? Anything new lately?
 
Not sure about SOTA, but I'm trying to coordinate digital switching with monitoring for bilges.
Each bilge would have a non-mechanical switch and a pump. Both are wired back to a digital switch unit (Maretron). The unit is N2K, and with the switch and pump separate, the pump is programmed to turn on when the switch goes high, or you can manually turn it on via N2K switching.
While the pump and switch separation is a risk in case there's a problem with the wires or unit, really bilge pump operation should be checked regularly anyway.
Benefits of this include being able to monitor each pump for amperage, and also provides a count of number of times it's turned on and the time it was on for each one.
All this would be overkill for 1-2 bilges, but we have 8: catamaran, 4 areas in each hull.
 
I had a panel made for my helm station for all four bilge pumps. Each pump had a green indicator light to show the pump was on in the Auto position or Manual position. There is a brighter yellow light to indicate the pump is running in either the Auto or Manual setting. There is a counter with a zeroing button that holds the count in memory, regardless of whether power is turned off from the panel. Each pump is independently fused to a separate panel in the engine room. The boat has two compartments each with a small primary and large secondary pump. As the large secondary pumps are several inches higher, those each have a buzzer to indicate activation. They are also tied to the Siren alarm system so I receive a text and an email whenever they would activate. I thought that was a pretty thorough standalone system.

My panel was made by Aqualarms.



Ted
 

Attachments

  • Screenshot_20240620_081005_Gallery.jpg
    Screenshot_20240620_081005_Gallery.jpg
    67.4 KB · Views: 83
Last edited:
There a plethora of ways to monitor bilge pumps. Rule has a system, use a backbone, get a cell phone app tied into your 12 volt panel etc.

To me, any water in the bilge is a bad thing and should be tracked and fixed post haste. Thus employ a belt and suspenders approach. Lift the hatch, visit the ER and or install a camera for direct eyes on monitoring. A faulty float switch negates the purpose of bilge pump monitoring system.
 
This would be a simple and fun project for an Arduino if you are so inclined to DIY.
 
I've done a bit of a hybrid, hopefully getting the best of both worlds.

- Each pump has the typical Off-Auto-ManualOn switch, left in the Auto position under all but exceptional circumstances.

- There are two stage float switch made by Ultra, and seem to be the most reliable float switches. The first stage/level turns on a small bilge pump, and the second stage/level turns on a large bilge pump. The second pump is optional, but the associated alarming is import and in the next part.

- When either stage of the float switch is activated, it signals a monitoring system, Maretron in my case. I have dry bilges so any pump operation at all is cause for immediate attention, both are set up as full Alarms, not warnings, and they make noise and send emails. These alarms also trigger counters, and a cumulative runtime.

I like having the activation of the pumps as simple as possible with as few things that can prevent them from working correctly. Contrast this to mcarthur's setup where the float switch, the detection module, N2K, and the power control module all need to be working correctly for the pump to run. All I need is for the float switch to work, so much less opportunity for failure. I'm still subject to the same N2K failures, but only for monitoring, not for actual pump operation.
 
I no desire to interfere with how they're currently operating. They're each on individual breakers with a manual mode. That's all working fine. They're critical to the boat being 'not sunk' so I'll keep them powered as simply as possible.

Monitoring them presents options. Is the RIM100 the Mareton unit you're using? What's handling the collection of data and alerts?

I have my main N2K network on it's own breaker along with the lower helm. The upper station is on a second breaker to allow powering it off separately (this to avoid having the gauges lit up all the time if I'm running from below). I'd imagine something similar could be done with a power tap for just the RIM100 to allow it to remain powered without all of the other sensors consuming power. Being mindful of voltage differential issues, of course, as N2K is a finicky beast about that.
 
Are we talking about monitoring on the boat OR monitoring off the boat. In my case when I am on the boat I am aware. It is off the boat I want to be alerted to unusual activity.
Currently I have for many years what is called BRNKL. It works as long as there is a cell service.
Bilge pumps? have a two pump setup in the ER, one float switch to smaller pump to maintain, second float switch mounted higher to larger pump for that day when all hell breaks loose.
I can program the alert for repeated events and/or length of pumping.
 
I no desire to interfere with how they're currently operating. They're each on individual breakers with a manual mode. That's all working fine. They're critical to the boat being 'not sunk' so I'll keep them powered as simply as possible.

Monitoring them presents options. Is the RIM100 the Mareton unit you're using? What's handling the collection of data and alerts?

I have my main N2K network on it's own breaker along with the lower helm. The upper station is on a second breaker to allow powering it off separately (this to avoid having the gauges lit up all the time if I'm running from below). I'd imagine something similar could be done with a power tap for just the RIM100 to allow it to remain powered without all of the other sensors consuming power. Being mindful of voltage differential issues, of course, as N2K is a finicky beast about that.
Yes, I use a RIM100 and N2KView to collect data and do alerts. Alerts get sent out via email over the boat's internet connection, not via a Maretron SIM device. I have the computer that runs N2KView set up to auto reboot once a week. That plus setting the IPG100 up as a WAN device with fixed IP address is the only way I have been able to finally keep the whole thing running for more than about a month. It's taken 15 years to get to that point. All this results in a love/hate relationship with Maretron's products, shifting rapidly towards the hate side because they just aren't keeping up in general with technology, and are becoming increasingly incompatible with other N2K devices because of their unique approach to selecting data sources.
 
Ugh, I didn't much like the N2Kview software. It's clunky, at best, and (if I'm remembering right) overpriced for what it offered. I also have an IPG100 but never really made much use of it.

I've ordered a RIM100. Does it do the collecting on itself? And can I bring up the counters on a DSM410? I'd be ok with putting a page (or several) on my DSM410 displays that showed counters. But I'm not yet familiar with what data is available on the RIM100 and what the DSM410's can display.

It's one thing to have counters, it's another thing to put them in context over time.

I do have a Raspberry Pi aboard with an N2K interface. I've not put much effort into utilizing it. This could be an incentive. Grafana has some excellent features for graphing data and I have the HDMI from the pi fed into one of my TZT3 chartplotters.

I haven't added much in the way of new devices, what's Maretron been giving you trouble with?
 
I don't believe the RIM (or any of maretron's sensors) stores any data. They just sense then send on the N2K bus. I haven't used one of the DSM products in well over a decade, but as I recall they can display most of the same data as N2KView. But I'm not sure about graphing. Maybe, but I'm not sure. And I don't know if you can send email alerts from a DSM. I would guess not, but don't know.

N2KView is very clumsy to work with, as you note. That's one complaint. But the real killer is their unique and incompatible way of selecting data sources. For any type of data, say GPS info or battery voltage, they do it exclusively based on an instance number. Sometimes it's a device instance, and sometimes it's a data instance, but in either case that number needs to be globally unique across your network. Nobody else requires that, and that's not how the standard says to differentiate and select data sources, nor how to use Instances. The result is that it's difficult, if not impossible to get Maretron's display products to display the data you want. And if you ask about it, Maretron and other vendors just point the finger at each other saying the other is wrong. And NMEA representative just give you a blank stare when asked about it, and say to always use certified products. Well, certification doesn't test for this, so it's of no use.

By way of example, I have four solar charger controllers, an inverter, and two BMSes, and Maretron's display products (N2KView and DSMs) can't differentiate between any of them. Through some backflip hacks, I can get it to reliably display one BMS, but everything else is a mangled mess. I have been complaining to Maretron and NMEA about this for going on 10 years and neither seems to care. Given the standard is now 25 years old, I just accept that it will never change, and I am increasingly moving everything away from N2K. I have never done any control via N2K, only monitoring. Control, and probably half of my monitoring is now on Modbus devices and communications. And I haven't used N2K for Nav data for over 10 years now. So N2K just keeps getting pushed into a smaller and smaller corner each year.

N2K had so much potential, yet has been one of the greatest disappointments of marine electronics. Doing something with Grafana, NodeRed, SignalK, etc. is very tempting, but so far I haven't been able to muster the motivation to open that can of worms.
 
Doing something with Grafana, NodeRed, SignalK, etc. is very tempting, but so far I haven't been able to muster the motivation to open that can of worms.

I hear you on the 'muster the motivation'. A thought I had was to see what it would take to get collected and/or 'calculated' data to be shown on N2K displays. As in, use a pi with an N2K interface to create a 'fake' device of sorts that the DMS410 could use as a data source. But with HDMI output from the Pi into a plotter it's not like force-fitting data into a format usable by 4" displays would be any more helpful.

Another was to look into what it would take to have the Pi generate "alerts" that the plotters could display. But I've not looked into how (or even if) the Furuno plotters I've got could accept and display externally generated alerts. That would probably be the most effective long-term. Have the Pi do the collecting, and have a few Grafana pages visible via HDMI and use alerts on the displays to raise attention.
 
I generally like the functionality of N2KView, especially the user configurable screens. And I'm happy to dedicate a computer and screen to it. I just want a more modern, usable, and compatible implementation. I scour the trade shows each year, but keep coming up empty handed.
 
N2Kview sends a sms/email warning if any bilge pump operates for more than 15 seconds and an alarm if any bilge runs continuously for 45 seconds. My bilge is dry so any bilge activity is reason for investigation but didn’t go with lower thresholds to avoid false alarms. Also have high water alarm which sounds a loud alarm and sms/email if not on the boat.
 
...
I like having the activation of the pumps as simple as possible with as few things that can prevent them from working correctly. Contrast this to mcarthur's setup where the float switch, the detection module, N2K, and the power control module all need to be working correctly for the pump to run. All I need is for the float switch to work, so much less opportunity for failure. I'm still subject to the same N2K failures, but only for monitoring, not for actual pump operation.
I agree, and was tempted to go the simplicity - and I may yet. But under my way I can monitor* the amperage of each bilge pump which is valuable for detecting possible flow problems.

*well I can if I'm running n2kanalyser, but getting that data showing up in n2kview is just insane, and I'm yet to succeed. @twistedtree - I may be following in your footsteps yet! I'm interested in how the Modbus stuff is going, otherwise I'll be heading more towards the DIY and home assistant for both control and monitoring if I ever throw Maretron (definitely not impossible!)
 
I don't believe the RIM (or any of maretron's sensors) stores any data. They just sense then send on the N2K bus. I haven't used one of the DSM products in well over a decade, but as I recall they can display most of the same data as N2KView. But I'm not sure about graphing. Maybe, but I'm not sure. And I don't know if you can send email alerts from a DSM. I would guess not, but don't know.

N2KView is very clumsy to work with, as you note. That's one complaint. But the real killer is their unique and incompatible way of selecting data sources. For any type of data, say GPS info or battery voltage, they do it exclusively based on an instance number. Sometimes it's a device instance, and sometimes it's a data instance, but in either case that number needs to be globally unique across your network. Nobody else requires that, and that's not how the standard says to differentiate and select data sources, nor how to use Instances. The result is that it's difficult, if not impossible to get Maretron's display products to display the data you want. And if you ask about it, Maretron and other vendors just point the finger at each other saying the other is wrong. And NMEA representative just give you a blank stare when asked about it, and say to always use certified products. Well, certification doesn't test for this, so it's of no use.

By way of example, I have four solar charger controllers, an inverter, and two BMSes, and Maretron's display products (N2KView and DSMs) can't differentiate between any of them. Through some backflip hacks, I can get it to reliably display one BMS, but everything else is a mangled mess. I have been complaining to Maretron and NMEA about this for going on 10 years and neither seems to care. Given the standard is now 25 years old, I just accept that it will never change, and I am increasingly moving everything away from N2K. I have never done any control via N2K, only monitoring. Control, and probably half of my monitoring is now on Modbus devices and communications. And I haven't used N2K for Nav data for over 10 years now. So N2K just keeps getting pushed into a smaller and smaller corner each year.

N2K had so much potential, yet has been one of the greatest disappointments of marine electronics. Doing something with Grafana, NodeRed, SignalK, etc. is very tempting, but so far I haven't been able to muster the motivation to open that can of worms.
I wonder if they’ve lost the ability to update the n2kview software. It’s written in flash/actionscript, which is no longer supported by adobe. I think they totally screwed me with the last IPG update, now my n2kview can not connect directly to the IPG, I have to connect via the POS cloud service, and don’t get me started on that pile of crap.
 
I was wondering the same - I'm looking for closely at moving everything to signalk and maybe home assistant, backed by nodered for custom alerts and actions. I'm a little jaded with n2kview
 
I ordered a RIM100 and will take a stab at it later this month. My initial concern is power consumption, as I don't want to add things that'll drain the batteries more than 'necessary'. The second being how to power the RIM100 and whatever gets employed for data collection WITHOUT powering all the rest of the N2K bus. There's a lot on the N2K bus that does not need to be active when the vessel is not in use. This will mean putting the RIM100 and presumably a Raspberry Pi on a circuit I'll have to add. I wouldn't want to power them directly from the same fuse as the bilge pumps, as they're working fine and don't need anything new changing that situation.
 
I was wondering the same - I'm looking for closely at moving everything to signalk and maybe home assistant, backed by nodered for custom alerts and actions. I'm a little jaded with n2kview
I suspect that will work well if you are facile with programming. I'm super rusty and dated, so for me a steep learning curve. It would be fun, but I would need to devote a lare block of time to it. I sure wish there were something "productized" for the rest of the world, but there doesn't seem to be.
 
Ugh, I didn't much like the N2Kview software. It's clunky, at best, and (if I'm remembering right) overpriced for what it offered. I also have an IPG100 but never really made much use of it.

I've ordered a RIM100. Does it do the collecting on itself? And can I bring up the counters on a DSM410? I'd be ok with putting a page (or several) on my DSM410 displays that showed counters. But I'm not yet familiar with what data is available on the RIM100 and what the DSM410's can display.

It's one thing to have counters, it's another thing to put them in context over time.

I do have a Raspberry Pi aboard with an N2K interface. I've not put much effort into utilizing it. This could be an incentive. Grafana has some excellent features for graphing data and I have the HDMI from the pi fed into one of my TZT3 chartplotters.

I haven't added much in the way of new devices, what's Maretron been giving you trouble with?
The RIM100 collects cycle counts (times circuit activated) and cumulative runtime since reset. I wanted the cycle counts/runtime to automatically reset every midnight but per Maretron tech support the reset is using a proprietary PGN so the only way is a reset manual button on a screen. As a result I need to activate my warnings/alarms based on runtimes, warning if any bilge runs for 15 seconds and alarm if any bilge runs 45 seconds. I’d rather have a warning on 5 cycles in a 24 hr period or cumulative runtime of 1 minute.
 

Attachments

  • IMG_2126.jpeg
    IMG_2126.jpeg
    89.5 KB · Views: 35
I ordered a RIM100 and will take a stab at it later this month. My initial concern is power consumption, as I don't want to add things that'll drain the batteries more than 'necessary'. The second being how to power the RIM100 and whatever gets employed for data collection WITHOUT powering all the rest of the N2K bus. There's a lot on the N2K bus that does not need to be active when the vessel is not in use. This will mean putting the RIM100 and presumably a Raspberry Pi on a circuit I'll have to add. I wouldn't want to power them directly from the same fuse as the bilge pumps, as they're working fine and don't need anything new changing that situation.
The RIM100 is powered from the N2K backbone, no other power connection.
 
I wonder if they’ve lost the ability to update the n2kview software. It’s written in flash/actionscript, which is no longer supported by adobe. I think they totally screwed me with the last IPG update, now my n2kview can not connect directly to the IPG, I have to connect via the POS cloud service, and don’t get me started on that pile of crap.
I started having connection issues (both local network and remotely) with the IPG100 about 4-6 weeks ago. I spent over an hour on the phone with technical support and they claim it’s not their firmware but a hardware problem with my IPG100. They asked me to return under a RMA. This will be the second RMA for the IPG100 device. I sure hope a replacement fixes my connection issues.
 
Wow, this is a lot of high tech stuff for big boats. Impressive.
I kinda went the other way and put in the largest 4000gph high water pump I could find and a 2" thru hull 11" up from water line.
I went with a simple Johnson float switch, led it to a Johnson high water alarm and a light/buzzer to the flybridge that I picked up on Amazon.
Yes, I will run some leads to an optoswitch and onto my Cerbo, so it emails me when the boat is sinking.
This is in addition to my normal bilge pump and is a completely separate system.
This was on the advice of my 24 year veteran mechanic; KISS on pumps and switches is best.

Please return to your regularly broadcasted program...

Jack
 
I suspect that will work well if you are facile with programming. I'm super rusty and dated, so for me a steep learning curve. It would be fun, but I would need to devote a lare block of time to it. I sure wish there were something "productized" for the rest of the world, but there doesn't seem to be.
Ah, super rusty and dated sounds exactly like me - no programming for many years! Good 'ol Basic, Pascal, C, Perl, LISP, ML :rolleyes:. If I go down the path I'll definitely make it available.
 
Wow, this is a lot of high tech stuff for big boats. Impressive.
I kinda went the other way and put in the largest 4000gph high water pump I could find and a 2" thru hull 11" up from water line.
I went with a simple Johnson float switch, led it to a Johnson high water alarm and a light/buzzer to the flybridge that I picked up on Amazon.
Yes, I will run some leads to an optoswitch and onto my Cerbo, so it emails me when the boat is sinking.
This is in addition to my normal bilge pump and is a completely separate system.
This was on the advice of my 24 year veteran mechanic; KISS on pumps and switches is best.

Please return to your regularly broadcasted program...

Jack
That's very similar to the setup I built on my boat for a high water alarm. The second level bilge pump in the engine room triggers 2 relays when the float lifts (in addition to starting the pump). 1 relay is a 5 second time delay for a buzzer at the helm (delay is so a float switch bounce doesn't cause beeping). The other relay closes a pair of contacts on the Cerbo GX (no delay) which then alerts my phone as well as popping up a warning on the Victron touchscreen.
 
I started having connection issues (both local network and remotely) with the IPG100 about 4-6 weeks ago. I spent over an hour on the phone with technical support and they claim it’s not their firmware but a hardware problem with my IPG100. They asked me to return under a RMA. This will be the second RMA for the IPG100 device. I sure hope a replacement fixes my connection issues.
They said something like that to me when this happened last year. Instead, I had to reset the firmware and eventually it worked. I am *always* suspicious when software people start blaming the hardware. It's basically a little linux computer. They have lost their leadership position, someone needs to fill the void with a new product.
 
I'm curious???

You are running the Aux contacts into the PLC and checking those contacts as a verification of open or closed before closing in on a power source...

Great design!

Have you ever considered running your closing coil currents through the aux contacts of the other energy source contactors? Or with the number of sources is this impractical?

Also... Are you using mechanically, or electrically held contactors for your energy sources? If you are using mechanically held, what are you using???
I've asked the mods if these PLC posts can be broken out into a new thread. It's a good topic, but shouldn't distract from this thread. Mea Culpa for starting the tangent.
 
Back
Top Bottom