Accessing your boat remotely is a common desire. Most people can access their home remotely, so it seems like it should be just as easy for your boat. But there are some limitations with the types of connectivity that most boaters have that make it a bit more challenging.
Remote Access vs Remote Monitoring
I think it's important to separate things into two different categories when talking about connected boats – remote access and remote monitoring. Remote access is a bit more complicated, and means you can access almost everything as if you were on the boat itself. Remote monitoring is usually a dedicated product that you install aboard separately from existing systems, and uses a dedicated app or service to allow you to see the status of specific items on the boat. I go into a little more detail below.
Back when I first started trying to connect my boat to the outside world, remotely accessing them was complicated. The first systems I had were all home-built Linux machines that used serial or USB connections to GPRS modems that had very slow connections. The systems required lots of fine tuning and were prone to disconnect and not reconnect, requiring a physical visit to the boat.
Above is one of the more reliable systems I had which paired a Soekris net5501 Linux machine with an AT&T Unite Pro hotspot. This was one of the first 4G hotspots that I remember seeing on the market which happily showed up as a USB device when connected to a Linux machine. You can also see an Actisense NGT-1-ISO connected to the serial port on the Soekris box. At the time I was using canboat and a series of custom-made scripts that parsed the various NMEA 2000 data on my network and sent text messages depending on what was going on. I also had a reverse SSH tunnel into the Linux box to access it remotely.
I call this Remote Access.
Way back in 2008, I started testing a solution from Boat Sense Solutions that was one of the first, affordable remote boat monitoring setups out there. Unfortunately, like many companies before and after, they had major reliability and support issues, and ended up going out of business. The product provided battery voltage levels, bilge status, bilge alerts, door open alarms, and the like.
I call this Remote Monitoring.
If you are more technical, then the rest of this article will be useful to you.
If you just want to monitor your bilge pump, battery, and other critical key things, and are not technical and want a dedicated app and system, you will want to consider a remote monitoring solution like BRNKL or Siren. I won't be covering that in this article – that's a larger discussion for another time. I have a bunch of these systems on board, and they are very useful in their own right.
Yes, there are crossover points with these technologies – remote access systems can also have notifications, while remote monitoring can also connect to NMEA 2000 networks – but they aren't as good at one as they are as the other. There are limitations on both fronts. Consider your use case carefully when choosing one over the other.
Why is remote access harder on a boat?
There are a few reasons that remote access is harder on a boat. Whether you are running a server aboard that you want to access, or are using various IoT apps like SmartThings or Philips Hue lights, there are challenges here that aren't the same as your house.
Can't just “open a port”
This is specifically a problem if you are running a server or system that you want to access remotely that doesn't work with a cloud service or is an IoT-thing. Cloud services and IoT stuff have other issues, covered below.
With your home internet router, you may have been able to open a port or turn on a service like UPnP to allow access remotely to things at your house. This is a common practice, and combined with dynamic DNS services like Dyn or NoIP, you can have access to web things and other stuff remotely from anywhere.
This works in most places because internet service providers allow your home router (or their router if you're using that) to get an address on the internet (an IP address) that is reachable by just about anything. Some providers block this, or like Comcast, block specific ports to prevent people from running servers or services on what is meant for residential, non-commercial use.
Where this does not work is on shared WiFi networks, such as in a marina, or for any type of cellular connection.
WiFi networks that are owned by marinas or other companies are usually locked down in various ways, and won't allow you to open a port or poke a hole into their networks. Not only that, your equipment might get a different network address every time it joins, which makes it even more complicated.
Additionally, WiFi networks only work while the boat is at the dock, and they are notoriously unreliable. Not only do they stop when you leave the marina, but in bad situations, like a power outage, they often stop working at the most inopportune times.
Cellular connections rarely have a public IP address that you can open services on. Most providers have many, many devices between your connection and the internet (my day job at F5 Networks involves understanding some of these environments, and they are insanely complex) and there is no way you could ever have a public address and port. Opening up a port or poking a hole into your boat when using a cellular connection is almost impossible.
So how do you get around this? The boat itself must connect out to something that is public, or to another location on its own. It has to know of a remote VPN server, remote proxy, or send its data to something that you can reach, because you can't directly get into it remotely.
Connection quality
Connection quality on a boat is not as reliable as being on land. Houses and businesses are usually connected via a physical cable of some sorts which offers a highly reliable and low latency connection. Latency is the time it takes for things to go back and forth across a connection, and becomes important with more chatty systems, and especially IoT.
Boat connectivity is usually WiFi or LTE/cellular which has much higher latencies in most cases, tends to get slower and faster as you move around, and can be disconnected much more easily than a physical wire.
In the screen shot above, you can see a pretty typical scenario. My fiber-optic internet connections at home are on top and showing only a small amount of latency. Meanwhile, on the boat connection at the bottom, it is showing over 300 milliseconds of latency due to a lower signal level. While it might not seem like much, every single thing you do slows down exponentially because each packet or thing flying back and forth across the network takes even that much longer.
Even if you do not want to run a server, you could be interested in using cloud-based things or IoT stuff like SmartThings, Philips Hue lights, Google Nest thermostats, and the like. These also have challenges with being run on a boat because of the connection speed and quality.
I used to have Philips Hue on board Grace, but I took most of them out and put in “old school” manual LED lights, still with fancy color changing remotes, but not controllable via the Philips app or even integrated with Alexa. The reason why was repeated issues trying to turn a light on with an app or screaming at Alexa when the internet connection was going through some sort of transition state. It was completely unusable in Princess Louisa Inlet that year.
Alexa is a common thing to throw on a boat, and I like it for controlling music and other things, but it is still highly unreliable even on a crazy connected boat. The latency at times results in a voice command taking a lot longer, or even timing out.
Connection quality is definitely something to consider if you are wanting to use SmartThings or other similar devices. Most of these types of devices are designed for normal latency, always available internet connections, which is not what you have on a boat. If you decide to use these systems, make sure you know the limitations.
Even trying to use things like Grafana or other tools remotely which aren't IoT can be challenging with the higher latency, coming-and-going type of connections you might have with LTE or WiFi. Keep this in mind when choosing the type of things you want to access remotely.
Limited data
With the challenges above, it is a common thing to consider sending all of the things you want to access remotely to some external server – in the cloud, home, etc. But there is a critical challenge with this, specifically around limited LTE data plans.
In particular, folks have asked why I don't use a remote Influx database (see Engine and power dashboards, Real-time weather from the boat, and Setting up Signal K and Grafana on a Pi) or replicate everything from my local database out to the cloud somewhere.
There are a few reasons, but the primary one is the amount of data that would use on my LTE plans. My Influx database is about 20GB and that's only for about 6 months or less. While that's not a huge amount, it is still enough to be concerned about, even with “unlimited” LTE data plans.
The other challenge is how these products deal with poor and no connectivity. Many database replication or other similar protocols don't expect to be disconnected for long periods of time (like being in an anchorage with bad/no cellular connectivity). And if they are OK with it, they will go crazy trying to catch up as soon as you're back, fill the pipe up, and cause even more delay while it catches up.
Some people have suggested trying it only when connected via WiFi at the dock, which is when you would be monitoring it remotely – you're not on board. That is a possibility, but then you have to turn it off when you leave to make sure it doesn't take up LTE bandwidth, which is potentially a manual activity (that can be forgotten) – and then what you do you do to sync things back up when you're back?
I just think it's more complicated than it's worth right now. You could design data summarization processes and only replicate the high points, but what is the point? If you're trying to remotely monitor your boat temperatures or battery voltages, summaries aren't what you're looking for remotely.
There are some projects out there such as Craig Howard's Signal K to Batch Format that take batches of flat files of data and sends them up when there is connectivity to storage on Amazon to be processed later for analysis. This is a good thing for bandwidth and connectivity, but it is not real-time – it's meant for longer term analysis.
I've wanted to do real-time, off-boat data replication for years – I started looking at it with MRTG (if you know what that is, you're old like me) and even later with RRDs and copying things back and forth in 2005. It's a hard problem to solve because of the data limits on being connected from a boat. Eventually when Starlink and other more unlimited data solutions become available in a few years on boats, I think it may be possible to finally replicate things real-time, but for now it is a bit more challenging.
Why Remote Access?
There are a number of reasons why you might want remote access to your boat, but the primary one is to access various systems and check on the health of the boat, weather, etc. Many systems on board now have web interfaces, or you may be using something like the Raspberry Pi + PICAN and Signal K + Grafana.
One of the biggest reasons for remote access is the amazing feature set from open source tools like Grafana. The dashboards that you can create are far beyond what any purpose built or marine electronics vendors provide, and accessing them remotely can give peace of mind in bad weather or when far away.
You can also use Signal K, Yacht Devices, and a wealth of other vendors that provide realtime gauges and other useful things, say, during a storm that you're worried about.
One use case I use all the time is remote desktop into a Windows machine that runs Maretron N2Kview 24×7. N2Kview is a dashboard based system that uses NMEA 2000 data to do a lot of things. It has a whole alarm and alerting engine, and I use it while on board a lto too. Using remote desktop allows me to change settings, update alarms, and even open other programs like N2Kanalyzer, Actisense tools, and more. I could even fire up the navigation software, turn on the radar, and much more if I wanted to for some strange reason.
Steve Mitchell
I also use remote access to access my Grafana server to check on the environmental / weather dashboard the most. I can see the current wind, wind the last few minutes for any spikes, temperatures inside/outside/engine room, and much more. I usually am looking at this because there is a storm or bad weather, and want to make sure things are OK.
I also use remote access to connect into my linux machines that run Signal K, Grafana, Influx, Plex, and tons of other things. I'll work on articles like this, update software, and do all sorts of other things.
Considerations
Security
Each of the approaches below have different security postures. You should carefully consider whether exposing your boat data through a cloud service or proxy is safe enough for you. Some of these services involve a 3rd party that you pay, but if they are compromised somehow, people could access the web interface to a device on your boat.
What is the risk? Well consider that most of these apps usually contain your GPS location and other information on all of the devices on your boat. That could allow someone to know where a boat with a lot of expensive things is sitting, unattended. That's just one of many things I could think of from a security perspective.
If you need the most secure, then a VPN is likely the best choice, and not a distributed one or endpoints in the cloud, but one between devices that you own.
Where will you access it from?
Will you only access your boat from home? If so, a VPN between your home router and your boat, where the boat connects to your house, is likely the easiest. That means only setting up two things, and simplifies maintenance.
If you want to be able to access things from your cell phone while anywhere, or from a laptop while traveling, then you will need a slightly more complex setup.
What do you need to access?
If you're only accessing one web server/application, then consider a proxy instead of a VPN or other more complicated setup. You'll still want to ensure that the application has a password and can be secured appropriately, but this may be a much simpler setup than any of the other choices.
If you need access to everything aboard, or multiple systems, or are constantly interacting with various devices via SSH, HTTPS, and other methods, then a VPN might be a better choice so you don't have to go through more steps.
Your budget / technical ability
If you are wanting to do this for free, then you probably are faced with using open source VPN solutions which will require a bit more technical ability and work.
If you are non-technical, you may wish to choose a proxy or a more simplistic VPN service. If those are even beyond you, then you should probably consider a dedicated boat monitoring system (not this article) or a solution that is simple but has potential security risks.
Remote Access Methods
Virtual Private Network (VPN)
VPNs are probably the most popular, and more secure, than any other solution. However, they have traditionally required a lot of setup. Most people are probably familiar with them from their employer – needing to connect to something at the main office via VPN that is private or confidential – especially given how much we're all working remotely this last year.
The good news is that many vendors have made VPNs much easier to setup, and in my opinion, they are the best way to get access to your boat in a secure manner.
Besides the security, they will generally give you full access to everything on the boat networks as if you were on-board, where the other methods below only allow specific access to particular web or devices.
There are a class of VPN services that have been sold the last few years that are designed to be used from your personal computer out to a service somewhere on the internet. These are designed to “mask” where your computer is coming from for privacy reasons, or to get around restrictions that content providers like Netflix and Hulu enforce. These types of VPNs are meant mostly (if not exclusively) for those purposes, and aren't the same as what we're talking about here, and are usually considered client-only VPNs.
We're looking for a site-to-site VPN, a VPN solution that connects multiple devices, or a VPN that allows remote clients (your phone, etc.) to connect to it.
Here are a few VPN solutions I've used myself. There are a ton to choose from, and they all have their own pros/cons. I'm not going to to go through all of the implementation steps – that would be its own article alone. You can read more about the different options from each vendor.
OpenVPN
OpenVPN is a great solution that provides both site-to-site and client VPN solutions. There is a Community edition that is essentially free, and many routers include it in their firmware. Most of them will allow you to connect two routers and allow the two networks on either end to communicate with each other.
This would be a good solution if you only really ever want to access your boat from home – setup OpenVPN on both routers, and have the boat router connect to your home. You'll likely need a Dynamic DNS solution on your home router to register it's address as it will change every time you reboot your router. This is what the boat router will use to connect – the boat is always responsible for coming up, looking for the home address, and then trying to connect to your house. Remember that the LTE or WiFi connection on the boat does not have a public address, so the house can't figure out where it is and connect to it – it's always one way.
I used to use OpenVPN exclusively using Linux machines at all locations, a site-to-site VPN between the locations, and an OpenVPN client server at home so I could connect phones and laptops if I happened to not be at either location. These setups are well documented online, and will require a certain degree of network expertise if you are going to route entire networks between locations (static routes, etc.).
PepVPN
If you have a Peplink product, it comes with PepVPN which is a feature-packed VPN with a lot of features. I highly recommend using it instead of other solutions if you have more than one Peplink product because it has features that make it easy to use and deploy with mobile connections.
If you have multiple internet sources, such as multiple LTE radios or WiFi, PepVPN is an amazing feature. It can be used with SpeedFusion to allow for automatic and almost instant failure. There are even features that help with Zoom and other features (a subject for another article in the works) and makes staying connected very easy.
PepVPN at its heart is a site-to-site VPN that is meant to connect two more more Peplink products. There are a ton more features built in that provide customization of how you want the VPN to work, what happens in a failover, and even down to what traffic is routed where.
Note: SpeedFusion is a different/complementary feature, which I do plan on writing about, but is geared more towards redundancy and traffic sharing, not VPN alone. You can have both (I use it that way) but it is a bit more advanced topic than for this article.
If you want to have a redundant, scalable, always on VPN between your boat and home, I would recommend getting a Peplink Balance-series router for home and creating a redundant PepVPN connection. I've been using one for years and would never go back. Not only is it almost set-and-forget with tons of features and redundancy, but the home Peplink routers outperform most of the other higher end ones and provide a lot of features and functionality that you would only find in enterprise products.
You can also run a server version in the cloud if you prefer called FusionHub. It can be the endpoint that your boat connects to, and you can run OpenVPN on it and have your remote clients like your phone connect to it there. It does require a bit more setup, but it is an alternative if you don't want a Peplink router at home.
Tailscale
Tailscale is a new-ish concept to VPNs that is extremely easy to setup, and avoids some of the pitfalls of traditional VPNs. Essentially, it uses a distributed model where things that need to be connected together “check in” their info on a central coordination server, and then the individual devices connect to each other directly in a mesh, and are intelligent enough to route traffic the most efficiently. Traditional VPNs, like PepVPN and OpenVPN, use a hub and spoke method, which has some limitations. You can read more about how it works here.
Some of the benefits of Tailscale include the fact that it is a full mesh, so if one thing dies, you could still get to other things without having to fix that failure. It's also very easy to setup – just download and install a small client on a Windows, or Linux or use their iOS app. They do not have a native Mac app and the workaround isn't that great.
Tailscale is a service, so you have to trust them if you are going to use their service and coordination server. In addition, their DERP servers would be used in the case of some LTE connections, so your traffic would be running through their servers. Other similar services include Pritunl, and ZeroTier, plus many more.
The challenges with these sorts of services is almost always security. You have to really consider whether the ease of setup is worth the risk. Having a 3rd party route your home and boat network traffic, and have the ability to connect into those points is too big a risk in my mind, but then again I am a former network administrator…..
Proxies/Tunnels
Proxies or tunnels are probably the easiest way of exposing something remotely for the mildly technical user. They are essentially a piece of software that you install on a machine on your boat that connects to something out in the cloud which acts as a relay to the thing on the boat. Or put more simply – you end up with a web address that is essentially public for something on your boat – no VPN, no complicated networking things.
Ngrok is my favorite one of these, and they have a very good set of tools and options. Download a tiny program onto your Linux machine, run a command, and you have a public link that you can use to connect to Grafana, Signal K, or any other web based tool aboard.
To use it, you'll need to sign up for an account and get an authentication token. This is used to identify who you are and connect things correctly.
It's free to sign up, but there are limitations to free accounts that might become annoying if you're using it remotely.
- 4 tunnels / services
- 40 connections / minute (should be plenty for a single user)
- Random URLs
The last one is the most irritating. Every time you start things up, the URL to the remote service is going to change. If your system reboots while you are away from the boat, this could be problematic unless you login to your ngrok account and find it. It also means you can't bookmark it.
If you end up using ngrok, I would recommend looking at their pricing and signing up for a paid account. I use the Pro level because I wanted my own domain names for things, and end-to-end secure tunnels.
Here's an example of using ngrok for Signal K. I'm running this on the system running Signal K, but you could do it from another machine – it's a slightly different syntax for that which you can look up yourself.
./ngrok http 80This is starting the ngrok software, telling it that the thing you're wanting to expose is running a web server (HTTP) locally and that it's using port 80. If you followed my Setting up Grafana and Signal K article, Signal K will be running on this port.
This process is called creating a tunnel.
You'll end up with a status page showing you if the connection is successful along with some other useful info. The most important bit is the forwarding details – in the example above, http://74c723c52735.ngrok.io is the URL you would use to access the Signal K server. This could be used from anywhere, so be aware of the security implications.
For Grafana, it's similar:
./ngrok http 3000Grafana usually runs on port 3000, so you need to change the port to get that piece to work.
You can also setup configuration files that contain multiple tunnels, options, and much more.
Above is an example with a configuration file bringing up four different tunnels – three for things on the linux machine locally, and one creating a tunnel for a Yacht Devices gateway. I'm also using Pro features that allow me to have my own domain names that don't change, and you can see traffic flowing through the tunnel at the bottom.
The biggest con to solutions like this is security. Not only are you exposing something from your boat to all of the internet, but the company running the service is essentially in the middle between the thing on your boat, and whomever is using it.
You must make sure that whatever application you're exposing has some level of security in it, or is read-only. Exposing Grafana is probably OK, as long as you keep it updated frequently, and create a secure administrator password. Exposing Signal K without changing the default password would be a huge security risk, as an example. Even without logging in, people could open up the Instrument Panel app in Signal K and add panels showing your GPS location, tank levels, wind speed, and other things about your boat. You might not want that…
You also should highly consider using a secure, HTTPS tunnel, and pay for end-to-end encryption (Pro level) so that nothing between your client and your boat is viewable by someone intercepting the traffic.
While this is one of the easiest ways to expose something, it has more risk than a VPN, and if you need to expose more than 4 or 5 things, or more complex access, it's probably easier to use a VPN.
For people wanting to expose Signal K and Grafana, however, it is a very convenient and easy way to do so.
Reverse Tunnels
Reverse SSH tunnels are a very secure way of accessing your boat remotely, but require a bit more technical knowledge. Remote access using this method requires a machine off-boat that has SSH exposed somehow on the internet, or intermediary proxies and other more complicated things.
Essentially you are SSH'ing from a system on the boat out to a remote system that is always reachable, such as a Linux machine running in AWS EC2. That connection is a reverse tunnel, which means if you connect to the AWS machine, which has a public IP that doesn't change, you can then use the tunnel to connect to the machine, and potentially other devices, on the boat.
It is a bit more advanced to setup than any of the other options above, but if you have a machine at home that you can expose through your router, you might have everything you need without any other additional software. It also requires you connect to that specific machine to get to the boat machines, or add routes and other things, and if you want to expose web services from the boat, do some additional configuration, port forwarding, etc. which is beyond the scope of what I'm covering here.
However, it is a viable solution since it is essentially free software, although it does require an exposed Linux machine somewhere. This is what I used for years until I setup OpenVPN and later PepVPN.
Cloud Services
Cloud Services are usually specific programs or things running on your boat that spit out their data to something out on the cloud. They may charge a fee to do this (most do) and you can then access that data by connecting to a web thing somewhere in the cloud. You're not technically really accessing your boat remotely – you're just accessing the data, or a slimmed down version of the data, on a cloud server somewhere.
Sometimes these can be more sophisticated versions of proxies that are purpose built for one particular application, send the data somewhere else, and end up costing you a subscription or fee to access.
The other potential big negative with Cloud Services is the data fees. Since it is streaming your boat data constantly up to something in the cloud, you could be using a significant amount of data. If you are using LTE for most of your connectivity, as I do, then this could be a concern with monthly data limits.
Signal K Cloud is a good example of a cloud service – it essentially connects your local Signal K server with a cloud version. You can access your server with just a few steps, and use apps like WilhelmSK to see it remotely. The downside is that other people can see your data as well, and you're replicating the data from your boat out to the cloud, potentially using more LTE data than you might want.
Maretron has as Real Time Cloud Service as well but it is quite expensive. It's dependent on how much data your boat sends to them, which is pretty typical for these sorts of services. My boat would likely be in the highest tier which would cost about $895 a year, or $75 a month. That does not include the LTE bandwidth I'd be using to do this.
There are not tons of other marine-specific cloud services yet, although many vendors are offering boat monitoring (not full remote access) solutions which are sometimes a subset of the data you could get from Grafana or other solutions. Cloud Services can be in between full remote access and just a subset or summarized version of data.
I believe we will see even more of these being offered by specific vendors, and being enabled in open source software like Grafana and Influx in the next few years. The popularity of dashboards with Grafana has really taken off on boats in the last year, and once we get better and cheaper connectivity (it is always getting better), we'll be able to do more real-time replication with solutions like this.
My Setup
I use OpenVPN as a client VPN for my phone, laptops, and tablets – my home router has it running and registers dynamic DNS entries so that my remote random clients can find it when the router reboots or the IP address changes. This allows me to connect to my house from anywhere. I then have PepVPN setup between the house, boat, cabin, and other locations. Everything connects to the home router since it has dual redundant links, and is the most stable location and connections.
Because I'm using PepVPN, I get a redundant connection from the boat back to the house across my multiple internet sources. Even if one disconnects, another is already there, ensuring I can always access the boat remotely.
The client VPN allows me to connect from anywhere into home, and home has access to the boat via the site-to-site VPN. If I am at home, I don't have to VPN at all – I can access the boat directly through the site-to-site VPN as if I were on the boat.
I have additional rules and protections in place beyond this to help protect things and increase security and limit exposure – firewall rules, etc. My home router also has redundant gigabit internet connections from two providers and a backup LTE device just in case both of those are down for some reason.
For my Mac, I use a program called Viscosity which is a fantastic OpenVPN client that I have had a lot of years of success with. The OpenVPN one is not as good and is just clunky.
I will occasionally use ngrok tunnels specifically for a vendor or individual that needs access to something, or if I am helping train someone, etc. but I do not leave those running continuously. It's too much of a risk to trust that whatever I am exposing doesn't have a security flaw of some sorts. Even when I do use them, I use specific DNS names that I have pre-configured, all SSL / TLS and fully encrypted from both ends all the way through, and every other security feature ngrok offers.
Recommendations
I want to access a couple of web things remotely – look at ngrok or similar tunneling solutions. Run it on a machine on the boat, access the thing via a URL. Keep in mind you need to ensure that whatever it is has a username and password and some level of security.
I want to access lots of things remotely – use a VPN. It's more secure and allows you to access everything remotely.
I want to access Signal K remotely – consider Signal K cloud, as long as you realize everyone else will be able to see your data. If you don't like that, then use one of the other methods.
Ultimately you will have to balance security, your technical skills, features, and budget when you choose. Once you have remote access, you will never go back – it is so convenient and adds peace of mind when you can quickly get in and check on things, access dashboards, and make sure your home on the water is safe!
Archived Comments
These are read only comments from the old system. Scroll down to participate in SeaBits Discussions, our new interactive forum attached to each article.
Mark
February 6, 2021 at 8:04 pm
Why not just use RealVNC?
It’s easy to enable on the Raspberry Pi.
- Steve Mitchell
February 6, 2021 at 8:14 pm
I think would qualify as a Cloud Service.
The only thing I don’t particularly care for with VNC in general is how bandwidth intensive and latency sensitive it is. If you’re trying to access Grafana or Signal K over a marina WiFi or LTE connection, it would make more sense to access the apps natively than try to send the whole Raspberry Pi screen.
If the connection is always good, then that could work
It would also be somewhat limiting for mobile or smaller screen devices since there are little or no clients for them, and the screen would be mostly unusable.
Martin Jarvis
February 7, 2021 at 12:18 am
Props for covering ngrok. It’s a great tool for tunnelling through firewalls. I have a couple of compute nodes on an “always free” cloud service running nodered and mqtt. I haven’t decided what I will do with it all yet!
Scott
March 29, 2021 at 10:49 am
Another solution is Chrome Remote Desktop. You can use Chrome on your SignalK server, install the Chrome Remote Desktop plugin and then share it’s screen using Chrome from any PC you want. It’s simple, but not the most efficient or bandwidth friendly I’m sure. It can get you started quickly, however setup on Ubuntu isn’t necessarily straightforward though.
