The Internet of Boat Things–ride the wave (couldn’t resist a good pun)!
The evolution:
This project has taken many different forms over the years. My first attempt was a Visual Studio project that kept track of the cabin temperature, water level in the bilge, AC and battery voltages. As this ran on a Windows PC, I only had enough power to run it when plugged in, at a marina. But, that was OK. Risa often wintered wet and plugged in. This system saved me many regular treks down to the “Dock of the Winter Solstice” on cold and even snowy days. Once I added an inexpensive camera system designed for home surveillance, I could visit virtually whenever I wished and check the dock lines and fenders. There were days that I had the monitor program running all day in a window on my home computer, while I did other things. Initially, I setup the system much the way it was designed to work, that is with a dedicated internet connection, not quasi-public wi-fi. Initially it worked well. Over the next couple of years, Optimum began blocking ports. What I didn’t realize at that time was that in short order, all ports would be blocked and I had to find a different way. I finally ended up using a solution where I would remote into the boat’s on-board PC. My boat PC hosted the device monitors and it could see the output from the recorder on its browser. As she was plugged in to shore power, there was ample electricity to run all the equipment.
With the addition of this large solar panel, ‘The Internet of Risa Things’ while moored became reality! While the boat PC drew too much power to expect the panel to replace if there should be a string of rainy days, there were now many other platforms that could be used.
Of course power is always an issue on-board. My monitoring system had to use as few watts as possible. The boat computer had a conventional 120 volt AC power supply. I could replace it with a 12 volt DC input model, but the box still drew 50+ watts. A Raspberry Pi model 3b+ draws a mere 10 watts at full power and runs a very capable Linux OS! I needed under two amps at five volts. Not a problem! (power usage page)
I built a multi-buck-up/down-chopper module to make the many the many voltages I needed from the house voltage. In addition to the 5 volts for the Pi, I needed 9 volts for the phone adapter, regulated 12 volts for the access point/network switch. I had discovered that the switch would overheat and shutdown if powered directly from the battery’s somewhat higher voltage, especially the charging voltages that could be over 14 volt. That left the network bridge. The AC adapter that came with it output 24 volts for POE. The boost module that I had tops out at around 30 volts and easily makes the needed 24 volts.
At the time I began this project, TeamViewer was the only remote control software available to remote into a Raspberry Pi without setting port forwarding-something Optimum (or any other provider of remote WiFi) is unlikely to allow me to do! Once setup, I could login and check systems and views. Risa-Pi also runs a Windows app written to converse with the Morningstar MPPT controller. As the Pi processor is an Broadcom CPU, this required some magic to make happen. For most flavors of Linux, there is an abstraction layer called WINE that can run many Windows programs. Wine capitalizes on the reality that most PCs have processors that run the same instructions set, so there is no emulation needed. Hence, WINE is light on processor demands. As the PI’s processor does not run Intel code, WINE will not work. I found Exagear, a 686 emulator+wine for the pi. Now my Pi can WINE!… Suffice it to say that it works, but between the TeamViewer and the 686 emulation, my CPU utilization was high and I had other things I wanted the Risa-Pi to handle. Pushing work up to a server and eliminating at least Teamviewer (the main offender) seemed to be the answer.
As I began pushing more information to this server, I thought, “While I’m at it, do I even need the Morningstar app? – I could write a program to talk directly to the Morningstar using modbus/tcp. Modbus was developed for industrial systems to present data for other systems. Unlike a CAN bus, it is a passive system – Where CAN constantly spews out its data, modbus only does so in response to a queries from another system. Originally designed to communicate over a specialized (modbus) communication network, modbus/tcp runs over the more familiar IP (internet protocol) network.
I found a Python modbus/tcp library (Python is one of the languages that the Raspberry Pi runs natively) and I’d already done some Python programming -so Python it was – an easy enough language (you just have to keep a watchful eye on your indentations-an extra space in the wrong place (or lack there of) causes an error!). The search for documentation on the Morningstar modbus specifications turned up not only detailed documentation, but a Python program that implemented many of the basics that I needed. This greatly sped my development and before long, my Tristar MPPT-60 was talking to my Pi and Risa-Pi was relaying the data to the cloud (this webserver). The results are displayed in the charge information pages.
I added a high precision analogue to digital converter board to the Pi and added their output to the telemetry file that is uploaded to the server. Now I had current draw information. I could track current flowing to and from the batteries – giving me a more accurate state of charge gauge.
Always wanting more… It would be nice to be able to see what was happening on the mooring. A pair of IP cameras ran $35 each. Turning off the IR reduced their power draw to just over one watt each, using wired ethernet. I opted to mount them along side the solar panel, one facing fore and the other aft. Rather than running five volts out the 20 feet to the cameras (and back), I opted to run 12 volts and regulate it near the cameras with a buck down adjustable power converter (about $2!). I installed it in an outdoor electrical j-box that is mounted on the rail next to the cameras. It also gives all the connections to the cameras protection from the harsh salt environment.
I am looking to add another camera to keep watch on my mooring lines.
As the largest draw onboard, I’ve added two optically isolated relays to the Pi to control the refrigerator. With these relays and a few lines of Python code, I can turn the fridge on or off, regardless of the state of the switch in the panel. There are three states: When the Pi is powered off or booting-the relays natural state, the fridge is in manual mode. If the unit was left on and there is a period of poor charging conditions, I can shut it down remotely or even turn it on (before the weekend or when charging conditions improve) should it be off. Once the OS is up, a routine restores the last state.