Temperatures in spec could be improved

[faceless2]

There are a few temperature units in the specification - at least environment.airTemp and environment.waterTemp. These are both specified in Kelvin, according to the spec published as of today.

First, Kelvin is perhaps not the most useful unit here - I appreciate the need for SI units but Celsius is more familiar and practical, at least until SignalK migrates from ships to spaceships.

Second, this is not a scalable way to do it. A boat will certainly have multiple temperature sensors and providing a consistent way to represent these will make it easier for a UI.

I would suggest instead of

environment: {
    airTemp: {
        value: 11.8;
   },
   waterTemp: {
       value: 8.4;
   }
}

we have

environment: {
    temperature: {
         air: {
            value: 11.8
        },
        water: {
            value: 8.4
        }
    }
}

This has several advantages. First, it scales - I can add keys for fridge, cabin, engine, cpu, hot water tank, masthead, whatever else I am measuring the temperature of. Second, any consumer knows that a value under "environment.temperature" is a temperature measured in C, which will make representing these easier.

[tkurki]

See also

https://github.com/SignalK/n2k-signalk/issues/13 https://github.com/SignalK/n2k-signalk/issues/14

My €.02: one unit for one quantity.

[keesverruijt]

Yes, SI = K(elvin).

We have had very very long winded discussions about this. There are other situations where SI units are not units you would present to users, like radians for angles, but it is the only sensible standard for a (potentially) worldwide database of data.

As to the model change, I like what you are proposing.

[tkurki]

Started work on this.

[keesverruijt]

Instead of environment.temperature.* which will be accompanied by environment.humidity.* should we have environment.*.{temperature,humidity,...} ?

[tkurki]

Hmm. There are already fixed keys under environment and I don't like the idea of dynamic and fixed as siblings.

environment.air.*.{temperature,humidity,...} maybe? And environment.sea.*.{temperature,salinity,...}? Doesn't solve jacuzzi and fridge temps....

[keesverruijt]

I agree, no mixing dynamic / fixed. air/sea doesn't cut it, as you have battery temp (maybe elsewhere in schema) but also tank temp (fishing folks wanna know whether the bait is still fresh) or on my boat I'm going to measure the heating system soon, and you also have the use case of airconditioners.

So let's stick with the original method, environment.temperature.* etc

2016-03-01 13:42 GMT+01:00 Teppo Kurki notifications@github.com:

Hmm. There are already fixed keys under environment and I don't like the idea of dynamic and fixed as siblings.

environment.air..{temperature,humidity,...} maybe? And environment.sea..{temperature,salinity,...}? Doesn't solve jacuzzi and fridge temps....

— Reply to this email directly or view it on GitHub https://github.com/SignalK/specification/issues/170#issuecomment-190707778 .

[tkurki]

Ok, making some headway here. Decided to proceed implementation-first, eg. figure out paths in the Signal K model for data in pgns 130310, 130311 and 130312.

Now the mapping in n2k-signalk branch with (the test data)[https://github.com/SignalK/n2k-signalk/blob/2642df0b4f139aee6d765146754f9881fedc8749/test/130310-2.json] produces delta with paths & values such as:

130310-outtemp_pressure
 environment.air.outside.temperature:7.76
 environment.air.outside.pressure:1018
130311-outside-temp-humidity-pressure
 environment.air.outside.default.temperature:8.05
 environment.air.outside.humidity:72.772
 environment.air.outside.pressure:101800
130311-insidetemp
 environment.air.inside.default.temperature:13.51
130311-engineroom
 environment.air.inside.engineRoom.default.temperature:9.77
130311-maincabin
 environment.air.inside.maincabin.default.temperature:17.21
130312-heatingsystem-novalue
130312-engineroomtemp
 environment.air.inside.engineRoom.5.temperature:70
130312-insidetemp
 environment.air.inside.3.temperature:13.18
130312-maincabin
 environment.air.inside.maincabin.4.temperature:16.93
130312-engineroomtemp-novalue
130312-outsidetemp
 environment.air.outside.0.temperature:7.84
130312-seatemp
 environment.sea.0.temperature:15.2

[keesverruijt]

That’s looking pretty good actually, not nearly as bad as I thought :-)

If we replace sea by water ?

On 05 Mar 2016, at 16:27, Teppo Kurki notifications@github.com wrote:

Ok, making some headway here. Decided to proceed implementation-first, eg. figure out paths in the Signal K model for data in pgns 130310, 130311 and 130312.

Now the mapping in n2k-signalk branch https://github.com/SignalK/n2k-signalk/blob/2642df0b4f139aee6d765146754f9881fedc8749/n2kMappings.js#L305-L441 with (the test data)[https://github.com/SignalK/n2k-signalk/blob/2642df0b4f139aee6d765146754f9881fedc8749/test/130310-2.json https://github.com/SignalK/n2k-signalk/blob/2642df0b4f139aee6d765146754f9881fedc8749/test/130310-2.json] produces delta with paths & values such as:

130310-outtemp_pressure environment.air.outside.temperature:7.76 environment.air.outside.pressure:1018 130311-outside-temp-humidity-pressure environment.air.outside.default.temperature:8.05 environment.air.outside.humidity:72.772 environment.air.outside.pressure:101800 130311-insidetemp environment.air.inside.default.temperature:13.51 130311-engineroom environment.air.inside.engineRoom.default.temperature:9.77 130311-maincabin environment.air.inside.maincabin.default.temperature:17.21 130312-heatingsystem-novalue 130312-engineroomtemp environment.air.inside.engineRoom.5.temperature:70 130312-insidetemp environment.air.inside.3.temperature:13.18 130312-maincabin environment.air.inside.maincabin.4.temperature:16.93 130312-engineroomtemp-novalue 130312-outsidetemp environment.air.outside.0.temperature:7.84 130312-seatemp environment.sea.0.temperature:15.2 — Reply to this email directly or view it on GitHub https://github.com/SignalK/specification/issues/170#issuecomment-192672017.

[tkurki]

Problem here is that 130312 has the "Temperature instance" field, which the others don't have. Solution above handles that as a dynamic path value and fills in 'default' for the missing values.

I think this should be handled with the "multiple values" strategy, but we need to revise that a bit: currently each N2K bus source is handled as a different source, but here we get an extra level. @rob42 this sounds like actually sending the source reference in the delta and not the object that you mentioned the other day.

So instead of the current ... "source": { "label": "N2K", "type": "NMEA2000", "pgn": 130312, "src": "160" }, ... we could send the source reference ... "$source": "N2K.160.5", "pgn": "130312", .... Makes deltas a bit more compact as well.

Ping to @sumps as well.

I'll continue in that direction and keep you posted.

[tkurki]

Sea is now water.

[keesverruijt]

I think this should be handled with the "multiple values" strategy, but we need to revise that a bit: currently each N2K bus source is handled as a different source, but here we get an extra level. @rob42 https://github.com/rob42 this sounds like actually sending the source reference in the delta and not the object that you mentioned the other day. So instead of the current ... "source": { "label": "N2K", "type": "NMEA2000", "pgn": 130312, "src": "160" }, ... we could send the source reference ... "$source": "N2K.160.5", "pgn": "130312", .... Makes deltas a bit more compact as well.

+1 on this!

[sumps]

Yes like this and I will see if it can be applied to all N2K instances

[tkurki]

Next step done:

• remove the instance id from the path
• add it to the delta source object

Paths look now like this

          "path": "environment.air.outside.temperature",
          "path": "environment.air.outside.pressure",
          "path": "environment.air.outside.temperature",
          "path": "environment.air.outside.humidity",
          "path": "environment.air.outside.pressure",
          "path": "environment.air.inside.temperature",
          "path": "environment.air.inside.engineRoom.temperature",
          "path": "environment.air.inside.maincabin.temperature",
          "path": "environment.air.inside.engineRoom.temperature",
          "path": "environment.air.inside.temperature",
          "path": "environment.air.inside.maincabin.temperature",
          "path": "environment.air.outside.temperature",
          "path": "environment.water.temperature",

And delta like this

{
  "updates": [
    {
      "source": {
        "label": "N2K",
        "type": "NMEA2000",
        "pgn": 130312,
        "src": "130",
        "instance": "0"           <--------------------------------------------
      },
      "timestamp": "2015-01-15-16:15:18.371",
      "values": [
        {
          "path": "environment.air.outside.temperature",
          "value": 7.84
        }
      ]
    }
  ]
}

The resulting source tree turns out like this:

  "sources": {
    "N2K": {
      "36": {
        "0": {},
        "src": "36",
        "pgns": {
          "130310": "2015-01-15-16:15:21.650",
          "130312": "2015-01-15-16:15:19.628"
        }
      },
      "41": {
        "0": {},
        "3": {},
        "4": {},
        "5": {},
        "src": "41",
        "pgns": {
          "130311": "2015-01-15-16:25:14.122",
          "130312": "2015-01-15-16:15:18.136"
        }
      },
      "130": {
        "0": {},
        "src": "130",
        "pgns": {
          "130310": "2015-01-15-16:15:21.862",
          "130311": "2015-01-15-16:25:13.828",
          "130312": "2015-01-15-16:15:18.371"
        }
      },
      "label": "N2K",
      "type": "NMEA2000"
    }
  }

Now here you see a less than perfect artefact: the same device #41 is sending 130311 and 130312, probably the same datum in two different PGNs. In the tree it will not matter too much, it will show as multiple values/sources for the same thing, but here it is a bit confusing.

The instance subobjects here have no properties, but they could have whatever metadata we want added.

[tkurki]

See also http://www.mvtanglewood.com/2015/12/nmea-2000-instances-there-are-more-than.html

[tkurki]

Instance is niw supported in schema and afaik temp support is in ok shape.