Victron - Remote Display

[teppokurki]

Originally Posted by conachair

As a side note - signalk is gaining momentum, already there's an app for a victron battery monitor. Not actually sure what it does but very likely more and more displays/controllers will be written to access the various bits of kit onboard via signalk far beyond the capabilities of NMEA. And it's free and opensource

Several things are available:

https://github.com/sbender9/signalk-venus-plugin allows you to get data from a Victron Venus device to Signal K server

https://github.com/sbender9/signalk-switch-automation allows you to control the relay in a Victron Venus device based on other Signal K data (do stuff like turn on your ACR (Automatic Charge Relay) when the engine is running and the AC charger is not on).

https://github.com/sbender9/signalk-...attery-monitor convert proprietary Victron N2K messages to Signal K

https://github.com/sbender9/vedirect convert input from VE.direct to Signal K

[conachair]

Originally Posted by teppokurki

https://github.com/sbender9/vedirect convert input from VE.direct to Signal K

Sorry travellerw, looks like your code was good while it lasted but might be resigned to dropbox

Cool! Did you notice there's stuff happening to create a generic Signal K ESP8266 IoT device? https://github.com/mxtommy/SigkSens

Been playing around with that one past couple of nights, great so far

[travellerw]

I'm glad that this inspired project inspired some new projects.

As to SignalK stuff. I personally have no use for it, and frankly don't understand its point. I was actually interested in contributing a while back, but I simply couldn't figure out the point of the project. I have read through the about page numerous times and still fail to understand the point. It seems like a protocol trying to solve a problem that doesn't exist.

From a technical stand point, all the things posted here are easily acheivable without SignalK. Frankly some of it is easier as you don't have an extra software/hardware layer in the middle.

[conachair]

Originally Posted by travellerw

I'm glad that this inspired project inspired some new projects.

As to SignalK stuff. I personally have no use for it, and frankly don't understand its point. I was actually interested in contributing a while back, but I simply couldn't figure out the point of the project. I have read through the about page numerous times and still fail to understand the point. It seems like a protocol trying to solve a problem that doesn't exist.

From a technical stand point, all the things posted here are easily acheivable without SignalK. Frankly some of it is easier as you don't have an extra software/hardware layer in the middle.

I'm a huge fan of signalk as far as any kind of home brew kit is involved anyway. Just makes everything so much easier with the server doing all the work.

As far as displays go, it's massively easier to get all the data in one place on any device you want to view it on - just takes a few minutes drag and drop, the real one is much smoother than this gif.


If your victron was plugged into a SK server your code would have been a few lines and the data available on any machine on the boat. Also pumped out over MQTT you can see it anywhere in the world on the web (assuming the boat is online of course), and everything can be pumped into a database. Doing all that with nmea 0183 & 2K plus various sensors, barometers etc would be a complete nightmare.

[travellerw]

Originally Posted by conachair

I'm a huge fan of signalk as far as any kind of home brew kit is involved anyway. Just makes everything so much easier with the server doing all the work.

As far as displays go, it's massively easier to get all the data in one place on any device you want to view it on - just takes a few minutes drag and drop, the real one is much smoother than this gif.

If your victron was plugged into a SK server your code would have been a few lines and the data available on any machine on the boat. Also pumped out over MQTT you can see it anywhere in the world on the web (assuming the boat is online of course), and everything can be pumped into a database. Doing all that with nmea 0183 & 2K plus various sensors, barometers etc would be a complete nightmare.

Hhmm I remain unconvinced. I'm not dazzled by a pretty guage interface that is just a gimmick to me. Once I got out cruising I realized that "having the data available on any device, via drag and drop" was of no value to me. When I want to look at boat data, I'm sailing the boat and the data I need is right in front of me via guages and a chartplotter (the reason I actually made physical guages for my chargers). If I'm not sailing the boat, I'm either off watch (sleeping) or enjoying the cruising lifestyle. No I have no interest in laying in my bunk looking at my engine temperature while I'm off watch.

Second.. Sure my code would have been smaller with a SignalK server. However, the code is not really smaller, just moved to a different location. On top of that, I have to run another device sucking power to now parse the SignalK data (SignalK server on a Raspberry Pie most likely). I don't understand why I would convert already open clear text serial data to another protocol when I just want to display it on an LCD?

Third.. If I wanted to push my data up to an IOT website I don't need SignalK to do that. The Arduino nanos paired with an ESP8266 (one could service many nanos) could easily do that. Pushing data up to ThingSpeak is a trivial matter and takes a small amount of code. I have no idea why you think this would be a nightmare with NMEA0183 or N2K? Especially parsing NMEA0183 data is super easy.

In any case, the pretty interface or the other stuff is not really what SignalK is about. The SignalK protocol is what I really don't understand. The technical problems they say they are trying to solve aren't really a problem. I just seems like they are WAY ahead of the current state of cruising. I know of no "Cruiser" anywhere that wants his boat to share data with other boats/Aids/Ports or other. I can't see this changing in the next 15-20 years (I could be wrong). However, they do have some validity in their statement about the license aspects of NMEA2000. I feel it would be a smarter effort to work on getting those aspects modified then making a whole new protocol where its just not required.

[conachair]

Originally Posted by travellerw

Hhmm I remain unconvinced.

Guess we've different styles of sailing, I liveaboard and having easy access to all the sensor data is such a godsend, roll on when Opencpn goes over to signalk. Doesn't seem to bo of interest to you but it really opens the door for simple addition of any kind of data onto a network, eps's are so cheap now it's really within the grasp of boat owners without having to write reams of code, drag and drop graphics. Easyesp & https://github.com/mxtommy/SigkSens does it all for you once the sketch is uploaded though the latter isn't immediately obvious to set up.

IMHO it is a fantastic opensource resource wrestling data transfer to free and infinitely adaptable from the constraints & cost of NMEA.

If only a few more hardware manufacturers would catch up..

[teppokurki]

Originally Posted by travellerw

I don't understand why I would convert already open clear text serial data to another protocol when I just want to display it on an LCD?

In your particular case, with Victron open data and a single display like your work the spot solution is simpler. No reason to create a universal solution for a particular problem.

But let's take that a little further. What if we had no 0183 and N2K standards, every single manufacturer had their own, open but not common protocols, not unlike the Victron one: open clear text serial data. Sure it would be easy enough to write a gauge like yours for one vessel, and all it's data just the way you want it. Wouldn't you think people would pretty quickly figure out that a common protocol just might be a good idea?

Let's imagine a case that you for some unfathomable reason want to add a second battery bank with a battery monitor that speaks N2K. If you had been using SK you would just add the N2K physical connection, configure the input and you would have both data sources available, Victron and the new N2K, in your gauge (an oversimplification, I know, but close enough). And even today: your gauge's potential audience would not be constrained to vessels with Victron equipment if it were SK.

This is what happened to me originally: I had some software for my own vessel. Then I switched my wind instruments over to N2K and had to redo quite a bit of stuff. So why not convert the incoming data to a data model that is not source protocol specific?

This is btw what Scott has done with the Victron Venus plugin: the plugin converts data from Victron's manufacturer specific dbus over tcp protocol to Signal K.

Conachair already mentioned databases. By creating a single db writer module we can write all our data to a database in a uniform, predicatable and understandable format, and use open source tools for graphing it. Aren't you the least bit interested in how your electrical system is working, in terms or amps & volts over time, not just what the gauge's instantaneous readings are?

I added an ESP8266 based temp sensing node to my boat last season. All I had to do was to start pushing values in SK format and they were automatically stored in db, logged in a log file and available as graphs (I was interested in my alternator temperatures - access to historical data is much nicer than writing the values down by hand...).

Db and/or graphs are not the point here. The point is that once data is in one data model the tools for manipulating it are usable for all the data, no matter where it is coming from.

Originally Posted by travellerw

I have no idea why you think this would be a nightmare with NMEA0183 or N2K? Especially parsing NMEA0183 data is super easy.

The thing here is that once somebody has written the mapping to SK format everybody else benefits. You don't need to write all that software yourself. Unless you want to, of course, and that's totally ok with me.

Parsing 0183 is easy enough. N2K less so, but doable with a little help from the net. MQTT is dead simple as you say. But in the end you will have a custom solution specific to your particular setup. Signal K attempts to provide a shared data model and protocol so that not everybody has to write their custom protocols, parsers and conversions. Take MQTT: what topic and message structure do you pick? Are you going to call it voltage, v, batteryvoltage or housebatteryvolts? If you start pushing temperatures what unit are you going to pick? All of these decisions will result in a solution that is specific to your particular system.

Originally Posted by travellerw

The technical problems they say they are trying to solve aren't really a problem.

Taken one at a time they are mostly not problems as you say. Together the problems result in brittle spot solutions.

Originally Posted by travellerw

However, they do have some validity in their statement about the license aspects of NMEA2000. I feel it would be a smarter effort to work on getting those aspects modified then making a whole new protocol where its just not required.

I have not seen much traction in that area.

Anyway, I wanted to clear some things up as to what SK is trying to do for everybody here, not win you over, as you clearly seem to know what you need and can implement it. Thank you very much for taking the extra effort to share! I think for every blog post you see there are 20 similar solutions, working in the wild but never shared.

[john61ct]

Lots of users think any BM/SoC meter is unnecessary overkill.

Others want to graph their average AH/day inputs and energy usage.

Whatever floats your boat man!

[travellerw]

Originally Posted by teppokurki

In your particular case, with Victron open data and a single display like your work the spot solution is simpler. No reason to create a universal solution for a particular problem.

Teppokurki.. You missed the point of my post. So let me ask it this way..

Why SignalK when it could be N2K? Why do we need the SignalK protocol at all if the N2K protocol was more open? Is N2K really antiquated and can't do the job, I think not. There are data elements in N2K for pretty much everything that has been posted here and N2K can be extended? I totally get a server that can process the data and do useful things with it. However, that does not require a new protocol.

Originally Posted by teppokurki

I have not seen much traction in that area.

Why do you think there has not been much traction in opening up the N2K protocol? Has anyone every formed an organization and lobbied the National Marine Electronics Association?

Anyway.. I salute anyone doing cool projects. If SignalK is how they are doing them, then maybe I'm its earned its place by simply enabling that. However, I think there is a ton of confusion between SignalK the "Protocol" and SignalK the processing server.

On another note... Based on this thread, its seems there are people benefitting from the data in ways that I am not. I would love if someone could describe how access to this data has made their cruising experience better. I think I must be missing something.

[teppokurki]

Originally Posted by travellerw

Why SignalK when it could be N2K? Why do we need the SignalK protocol at all if the N2K protocol was more open? Is N2K really antiquated and can't do the job, I think not. There are data elements in N2K for pretty much everything that has been posted here and N2K can be extended?

Leaving the licensing issue aside let's look at just the technical details.

N2K is inherently not extendable without updates to all the software components. It is a binary protocol, which means in practice that the message receiver must know in advance the structure of the message (how many bits for this and that field) and the meaning of the fields (what each value is and what scale & unit is used). Without this knowledge the message is just binary data.

Now contrast that with Signal K: without any prior knowledge a device, such as a gauge, can parse the message, see what the data is about and retrieve metadata such as the unit used and description of the item from the server and display all that in nice, human friendly way.

Let's take a concrete example: how well you are sailing compared to the theoretical speed of the boat in these conditions. Let's define that as a the ratio of current speed to the theoretical max speed, commonly referred to as polar speed. Let's call that performance.polarSpeedRatio.

If your gauge would be speaking Signal K you could configure it with the string performance.polarSpeedRatio and it would be able to display it without any changes in the gauge software. Then we could add this path to the server's Signal K schema with the unit "ratio" and the gauge would be able to retrieve that data and show the number as a percentage. Again, if you wrote the gauge software smartly in the first place this would not need any changes.

Contrast that with N2K: I am not aware of a PGN that carries this information, despite you saying that pretty much everything is covered. You would have to define a new PGN for this purpose and define how the value is carried in binary format. A float maybe - signed, unsigned, how many bits? Or scale it to an integer between 0 and 65535? Decisions that you would have to make - and implement the corresponding decoding in your gauge software. All N2K extensions need updates in all the receiving equipment software that wants to use them. And once you did all this no other equipment would still be able to display your data!

If that is extensible to you you are using that word with a veery flexible meaning.

BTW this is a real life example: a Signal K user implemented the conversion from a vendor specific 0183 sentence to tank level PGN, just to get his commercial multifunction instrument display to display his polar speed ratio as black water tank level!

Originally Posted by travellerw

Why do you think there has not been much traction in opening up the N2K protocol? Has anyone every formed an organization and lobbied the National Marine Electronics Association?

My opinion: a hell of a lot of work with very little chance of success.

[jbinbi]

Many thanks. I am about to purchase 1 or 2 victron mppts to replace my two Chinese mppts. I was going to purchase one of the 712s. Maybe not now. BTW, it seems all the new products are the 'smart'products with integrated BT.

[Lake-Effect]

Originally Posted by conachair

Been playing around with that one past couple of nights, great so far

Oh, sweet!

[sbender]

Originally Posted by travellerw

On another note... Based on this thread, its seems there are people benefitting from the data in ways that I am not. I would love if someone could describe how access to this data has made their cruising experience better. I think I must be missing something.

I'm attaching a couple screenshots of how I use Signal K data.

The first shot is a screen that I use when at anchor. It gives me one view into my electrical, weather and music.

The second shot shows the electrical history that I store using influxdb. This is just one of many screens that shows history for all different aspects of my boat.

[basssears]

Originally Posted by sbender

I'm attaching a couple screenshots of how I use Signal K data.

The first shot is a screen that I use when at anchor. It gives me one view into my electrical, weather and music.

The second shot shows the electrical history that I store using influxdb. This is just one of many screens that shows history for all different aspects of my boat.

Daaammmnnn... that's pretty slick!!

[travellerw]

Originally Posted by sbender

I'm attaching a couple screenshots of how I use Signal K data.

The first shot is a screen that I use when at anchor. It gives me one view into my electrical, weather and music.

The second shot shows the electrical history that I store using influxdb. This is just one of many screens that shows history for all different aspects of my boat.

Nope.. Looks like I'm not missing anything,

Yes, that sure is pretty.... BUT.. Most of that data is of no value to me. In fact most of the instruments that provide that data are turned off when I'm at anchor to save power. Not sure why I would want to know my depth while I'm anchored (as long as I'm not dragging). All the other data I have on displays in the salon that I can just glance at.

I have all that same solar data, but stored on each controller and acessable by bluetooth. I will agree that having all my solar data consolidated in one place (since I have 4 controllers) would be nice. However it would be pretty trivial to send that data up to one of the IOT services using a single ESP8266.

Anyway.. different strokes for different folks, but there is nothing in your screenshots to convince me I'm missing something. Thanks for taking the time to do screenshots and post.