Call for interest in SignalK Raspberry Pi Image

[tho...@samoht.ca]

Hi!

Over the past couple weeks I've been looking into making an OS image in order to make installing the server and getting started easier for newer users. Basically a pre-configured OS with signalk server and more pre-installed and ready to go out of the box. Before investing a ton of time into it, I'd love to get some feedback from others :D

First, on the software to include:

• Signalk-node server and dependencies
• InfluxDB (Time series database)
  
• Graphana (pretty graphs from time series database)
• Ideally second partition for data.
• Other stuff? gpsd? etc

For the image, there are basically 3 options:

1. Build a Raspbian based image. This is relatively straightforward.
   
2. Option 1 would have a decent amount of overlap with OpenPlotter. Might make most sense to just contribute to that project :)
3. Victron Energy has an opensource version of their VenusOS software. It's based on OpenEmbeded (Linux based). We could base an image on that.

What's the difference between options 1/2 (Raspbian based) and option 3 (Venus based)?

Versioning

Raspbian is package based. The user will install the image, and then potentially need to update a bunch of packages. Different users will update at different times. So while everyone might have started with the same software, very quickly you will find that everyone has different versions of stuff (and I'm not just talking about the "services" software, but everything like libraries etc). This complicates support. Also, no clear upgrade path from image version 1 to image version 2.

Venus however is "image" based. It's more like the firmware running on your router. The image includes all software in one single package, and there is no updating individual softwares directly in the image. This has advantage that if you're running version X of the image, you know every other person running version X of the image has the EXACT same software on it. To update, you update the entire image, which replaces all software at once. Venus uses dual root partitions, so updating software is done "live". You can just plug a USB key into the Pi, and it updates the offline root partition. You reboot into that and done. (Data is on it's own partition) I'm not too worried about being out of date, as Victron is maintaining the OS so we would benefit of updates as well.

Ease of End-User use
Raspbian based images may not be terrible complicated, however the number of tutorials out there requiring to go into the CLI and run "sudo something" is large. For technical users not the biggest deal usually, but also no big points for ease of use. Raspbian is much more suited to "power users" I think.

Venus is designed to run embeded for users who are not necessarily technical. Under normal use you never go into the cli. By default the shell is even disabled. As long as image works well I imagine it would be easier for users. If there's a problem, it's with the image, so you update the image and your users problem is fixed.


My Thoughts

I think both Raspbian and Venus have strong merits.

If I was running a company and wanted to make a SignalK Server to sell (and support!) to the general public, I personally think the choice would be clear: Venus. Having all your users running known images is a huge plus. When a user calls in saying they have a problem and they're running version XYZ of the image, you KNOW what version of Node is there. You know what version of the signalk server there is. etc. It's setup with the idea that the user will never SSH into it to do anything. I think it would make a much better "product".

That said, a Raspbian based image has a few very large advantages of it's own. Two biggest being the amount of people out there using Raspbian (easy to google for stuff), and ease of customizing the os after install. Want to add you own custom script to do something? Go for it. etc

So I was hoping to get feedback regarding what others thought would be a good way to go forward? :)

Thomas

[Greg Clarke]

Venus sounds interesting, I like the idea of a firmware like setup. Then I could set up Pi's on friends boats and they could deal with updates etc. I'm too scared to suggest signal k to my less techy friends because it means I'll end up supporting them :) +1 for Venus

[Pavel Kalian]

Hi...

If going the Raspbian way, isn't OpenPlotter already doing most of this and much more, making the effort mostly redundant?

Option 3 would create a new, different, choice. Is it really needed and is it "easier" than OpenPlotter with disabled repository updates and a replace of the SD card (maybe with something like export data to cloud/restore data from cloud) once a year? I am not sure.

What is sure is one thing though - Maintaining a project like this in a usable shape long term is not a trivial undertaking, are you ready for it?

Pavel

--
You received this message because you are subscribed to the Google Groups "Signal K" group.
To unsubscribe from this group and stop receiving emails from it, send an email to signalk+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Teppo Kurki]

On Mon, Feb 12, 2018 at 4:46 AM, <tho...@samoht.ca> wrote:

Hi!

Over the past couple weeks I've been looking into making an OS image in order to make installing the server and getting started easier for newer users. Basically a pre-configured OS with signalk server and more pre-installed and ready to go out of the box. Before investing a ton of time into it, I'd love to get some feedback from others :D

First, on the software to include:

• Signalk-node server and dependencies
• InfluxDB (Time series database)
  
• Graphana (pretty graphs from time series database)
• Ideally second partition for data.
• Other stuff? gpsd? etc

For the image, there are basically 3 options:

1. Build a Raspbian based image. This is relatively straightforward.
   
2. Option 1 would have a decent amount of overlap with OpenPlotter. Might make most sense to just contribute to that project :)
3. Victron Energy has an opensource version of their VenusOS software. It's based on OpenEmbeded (Linux based). We could base an image on that.

At this day and age there are also other options, mainly a container based deployment.

If we package SK Node server and the auxiliary software (InfluxDb, Grafana, Node-Red, etc) as a collection of interconnected Docker containers with docker-compose it may be possible to eat and save the cake:

- your host OS, in this case Raspbian, is free for you to use as you will

- the deployment is a collection of file system images, the same for everybody on the same version of "SK server + aux", thus no drawbacks of versioning outlined in the original message

- we can provide an image with Raspbian + Docker + SK containers preinstalled or people can install Docker on their system of choice and still get a well defined Signal K runtime environment

- the upgrade process is well defined: chores like upgrading Node, aux software or the SK server proper do not affect the host system, you just download updated container images and restart the SK subsystem - even if something goes wrong you can ditch the images and reload them, with your config and data intact

A Dockerised SK Server would provie a universal way to run & upgrade SK in most environments, be it for development, exploration or production use. No Node and other dependencies - apart from Docker and docker-compose - required. I believe it would prove useful also within OpenPlotter for smooth SK server upgrades.

The container approach will not get to the Venus firmware-like experience, but provides more flexibility, as you can add SK subsystem in most any environments.

If we use Docker also in development and build automatic release and latest images in Dockerhub I would be hopeful that the maintenance burden that Pavel refers to would not be overly taxing.

Provided a user has Docker creating a "curl -fsSL https://get.signalk.org/ | sh" style, one command installer is not much work. 

Comments?

[Teppo Kurki]

On Mon, Feb 12, 2018 at 5:42 AM, 'Pavel Kalian' via Signal K <sig...@googlegroups.com> wrote:

If going the Raspbian way, isn't OpenPlotter already doing most of this and much more, making the effort mostly redundant?

Dunno, you tell me. The way I see it is that OpenPlotter is aimed at what it says in the name: an open source plotter, with a screen running OpenCPN, whereas a SK server is aimed at being a headless server with UIs running on other devices. Maybe not much of a difference in reality, but something. Download image, plug it in, wire your connections and start using type of thing.

 

What is sure is one thing though - Maintaining a project like this in a usable shape long term is not a trivial undertaking, are you ready for it?

You are probably quite right here. 

[Sailoog]

this is how we update openplotter and dependencies without burning new images every time: https://sailoog.gitbooks.io/openplotter-documentation/content/en/updating.html

To avoid redundancies you may focus on headless systems running on Raspberry zero

El dilluns, 12 febrer de 2018 3:46:43 UTC+1, tho...@samoht.ca va escriure:

[verkbr]

There is certainly interest in SignalK. I'am using it on my Raspberry Pi with OpenPlotter. But a lot of people use other systems.

What to advise if they also like to use signalK.

I'am using here OpenCPN also on a Linux Mint system. What steps are nessesary to have SignalK on this system ?

What are the instructions to do this ? And how about Windows users.

If you like make headway with SignalK, which is a very good idea, these things are a must to get more users and must now have the first priority.

Bram

Op maandag 12 februari 2018 03:46:43 UTC+1 schreef tho...@samoht.ca:

[Teppo Kurki]

I'am using here OpenCPN also on a Linux Mint system. What steps are nessesary to have SignalK on this system ?

https://github.com/SignalK/signalk-server-node/#installation

 

What are the instructions to do this ? And how about Windows users.

Not being a Windows user myself I am not in a position to offer much help here. There have been some changes added to SK Node server to make it work specifically on Windows, so it most likely works ok, but the instructions are missing.

Again this is an open source project - if you feel like something is important and should be changed/fixed acted on the best way to do it is to organise it yourself. And by organising I don't mean doing everything yourself!

[verkbr]

Dear Teppo Kurki,

you have allready done a lot of work on the signalK system. But I'am not able to make a SignalK install setup in the Linux repositories. That is the aim to let the user, who has no idea of github, install
a SignalK server on his systeem.

Of course users can buy a separate servers for signalK data. But then there are not many practical applications. MxTommy/kip is however a step in the right direction. 

Thanks for all your efforts.

Bram



Op dinsdag 13 februari 2018 15:40:56 UTC+1 schreef Teppo Kurki:

[Teppo Kurki]

On Tue, Feb 13, 2018 at 6:29 PM, verkbr <verker...@gmail.com> wrote:

Dear Teppo Kurki,

you have allready done a lot of work on the signalK system. But I'am not able to make a SignalK install setup in the Linux repositories. That is the aim to let the user, who has no idea of github, install
a SignalK server on his systeem.

Ok, thanks for the clarification. I assume you are looking for something like PPA Private Package Acrhive installation process, like in the instructions at https://community.linuxmint.com/tutorial/view/1525?

So would running 

sudo add-apt-repository ppa:.....whatever it is
sudo apt-get update

and then using your Mint system's software installer to do the actual installation be the level you are looking for?

This does not require images and is not RPi specific, just packaging the software (for amd64 and arm) for Linux installations. The process could be made very similar to installing the required Node.js.

I believe Thomas has already done most of the packaging for this solution.

[Pavel Kalian]

On 12 Feb 2018, at 17:58, Teppo Kurki <t...@iki.fi> wrote:

On Mon, Feb 12, 2018 at 5:42 AM, 'Pavel Kalian' via Signal K <sig...@googlegroups.com> wrote:

If going the Raspbian way, isn't OpenPlotter already doing most of this and much more, making the effort mostly redundant?

Dunno, you tell me. The way I see it is that OpenPlotter is aimed at what it says in the name: an open source plotter, with a screen running OpenCPN, whereas a SK server is aimed at being a headless server with UIs running on other devices. Maybe not much of a difference in reality, but something. Download image, plug it in, wire your connections and start using type of thing.

OpenCPN is installed on it. As is signalk-server-node. And stuff supporting SDR. And sensors. And... Which of them is more important for you depends on your use case I think. Making it a pure server appliance only providing data for other devices and not having a GUI at all is AFAICT just a question of changing the default runlevel from 5 to 3... But I'm sure no OpenPlotter expert, actually not even a user.

What I am kind of an "expert" on after all these years, is keeping undermanned projects rolling though. And it sure isn't an experience I would recommend :)

Pavel

[1jol...@gmail.com]

Hi Everyone,

I got intrigued with the possibility of building a navigation system on a Raspberry Pi about two years ago. For the most part, it seemed relatively straightforward. Two years later I have completed my first Openplotter project. At first, it began as an OpenCPN project and then I came across SignalK. In the end, I discovered Openplotter and seemed to be the logical choice because anyone, such as myself who has no programming skills, could easily download and install the program, get it up and running relitivly easily. It's been a challenging project and I have learned a lot along the way, however not without huge frustration. As a non-programmer, asking questions on blogs, in most cases, result in vague replies as though one should know what the responder is talking about to correct the issue. This has been the most frustrating part. In some cases, referred to Git to install patches or updates has proven impossible at best. After reading this blog, I felt compelled to reply and give my side of things. I would like to see something a little more straightforward and user-friendly for those who don't have the programming skills to easily find solutions such as updates, etc to fix problems which only a programmer can solve.     

I really want to thank all of you, who have put so much time, energy and hard work into all your perspective projects. Because of you, many boaters around the world have been able to build, learn and understand what goes into navigation electronics and systems. Keep up the great work. It's been a great learning experience for me and there is so much more to learn.

Thanks,

Chris