search

SignalK / specification

Signal K is a JSON-based format for storing and sharing marine data from different sources (e.g. nmea 0183, 2000, seatalk, etc)
Other
91 stars 68 forks source link

Tank fluid types (again)... #522

Open preeve9534 opened 5 years ago

preeve9534 commented 5 years ago

I see that this matter has gone around a few times, but I think the issue of tank fluid types needs re-visiting again. I'm new, so please correct me if I'm out of order or not making sense.

It looks from the current state of the specification and the discussion around this area that there has been an attempt to pull together some sort of dictionary of common fluid types. My problem is not so much that the list isn't comprehensive (how can it ever be), but that membership of the current list is all over the place.

To illustrate, I've listed and tried to organise the fluid types I have to monitor on my modest vessel and how they are represented in the current Signal K model and how N2K might map into these (I have no experience of other tank sensing systems except for simple sensors that don't report fluid type).

My fluids Signal K fluid type N2K fluid type
water
....fresh water
........drinking freshWater 2. Fresh water
........other
....waste water
........black blackWater 6. Black Water
........grey wasteWater 3. Waste Water
....liveWell 4. Live Well
........liveWell liveWell
........baitWell baitWell
....ballast ballast
fuel fuel 1. Fuel
....diesel
....petrol
....gas gas
lubrication lubrication
....oil 5. Oil
....grease
other
....hydraulic
....extinguishant

One could argue about this hierarchy, but I think it reveals some important ommissions and some bad assumptions. Taking the current Signal K types that I have issue with in turn:

freshWater identifies in the schema as drinking water, but I know a lot of vessels that carry fresh water but not for drinking. In my case, I have separate tanks for bathing/laundry/cooking and drinking. I propose either replacing freshWater with two categories or remove the drinking water description (and so bump freshWater up my hierarchy). As an aside I note that the N2K definition of Fresh Water is less prescriptive than the current Signal K one, so the N2K -> Signal K mapping is currently contentious.

wasteWater should be renamed greyWater: grey water and black water are two types of waste water.

liveWell and baitWell seem to me to be very pinicketty differentiations of liveWell when all we can manage for fuel is fuel! By all means keep liveWell and baitWell, but maybe we could add some more important low-level types in other areas too?

fuel. Surely we can be more granular than this in this important area (not that the liveWell and baitWell differentiation isn't important too!). I seem to recall that N2K defines fuel as diesel oil, so the current mapping in Signal K is in anycase misleading.

Hate to open this up again, but...

sarfata commented 5 years ago

Thanks for this little summary. Very useful to look at the big picture.

liveWell and baitWell seem to me to be very pinicketty differentiations of liveWell when all we can manage for fuel is fuel! By all means keep liveWell and baitWell

The reason we added it was compatibility with N2K which has separate temperature "sources" for liveWell and baitWell.

Source: NMEA2000 Temperature sources for PGN130311

As pointed in your table, NMEA2000 does not make a difference between liveWell and baitWell in other fluid-related PGNs:

I stand by the decision to make the distinction in SignalK: it makes sense for SignalK to be as wide as possible to make sure that anything expressed in NMEA2000 can be expressed in SignalK - even if the inverse is not possible (for example, there is no way to convert the key tanks.baitWell.default.currentLevel to NMEA2000). With the current data structure in SignalK, it would have been extremely weird to add one more tank type with a temperature defined but not the other characteristics.

As an aside I note that the N2K definition of Fresh Water is less prescriptive than the current Signal K one, so the N2K -> Signal K mapping is currently contentious.

Fixing the definition is easy enough and I agree it should be done, again to stay compatible with NMEA2000. Do you know how to submit a pull-request?

wasteWater should be renamed greyWater: grey water and black water are two types of waste water

I already see greyWater and blackWater in the spec. I do not see wasteWater. What is your source?

fuel. Surely we can be more granular than this in this important area (not that the liveWell and baitWell differentiation isn't important too!). I seem to recall that N2K defines fuel as diesel oil, so the current mapping in Signal K is in anycase misleading.

I see petrol, lpg and diesel, in the fluid types. I am surprised that gas is not in there. Again you seem to have a different source. Where did you look?

Two more little details:

preeve9534 commented 5 years ago

That's a really helpful response because I think it helps my understanding a little. Forgive me if I'm being silly here, but I now realise that there are two elements in the spec which are of interest.

The fluid "type" enum which I think you have been referring to I am happy with (sure there are some other types we could add) and I'll have a go with a pull request as you suggest: liveWell, baitWell, rum and even whiteRum and redRum (ah! but that was a horse) are OK by me!

The properties object is where I think I have an issue with inconsistent logic, but maybe I just need educating. Pathname components are I think derived from this properties object and I completely get the idea that these could just as well be mumbo-jumbo (as long as the data at the end of the path is good). However, the properties that are available have obviously been chosen for at least documentary value and it was these choices I had issue with. I'll explain:

I have grey water and black water tanks on my boat with N2K sensors. The black water tank pops up in a path tanks.blackWater... whilst the grey tank pops up in a path tanks.wasteWater... And this gave me pause for thought - shouldn't that second path component be tanks.greyWater? Or shouldn't both of these tanks show up as tanks.wasteWater (and I can find out which is which by digging into the type at the end of the path)? I guess my point is that path elements can serve a useful documentary and diagnostic role, but only if they are consistently and well thought out.

So, I wonder what your thoughts are on the properties values in the light of my earlier post?

Your comment on tank indexing is interesting too. The current Signal K implementation in this area uses the NMEA instance number in building the data path (e.g. I see "tanks.freshWater.2..." for example), but doesn't use a tank index id: I guess that would require an additional path element.

Time to empty the rum tank.