RFC0003: Generalization of Charging sources in electrical.json

[thomasonw]

Summary

This RFC proposes the current charger definition in electrical.json schema be extended to include a 'type' specifier (AC, Alternator, Solar, etc..) allowing charging sources be handled in a generic approach as opposed to discreet definitions for each type.

UPDATE Oct 27, 2016 After review, decision was to NOT follow this RFC, and instead extend the current method with new entries for each device type

Motivation

As additional charging sources are added to the electrical schema there are many data items in common with all charging sources. By using a common definition for all of them this RFC suggests applications will have a simpler approach for handing different charging sources.

Using a common schema entry for charging sources also allows for simple determination of what devices are installed via a single SignalK query.

Detailed design

An additional item would be added to the Chargers 'Properties' section:

                       "chargerType": {
                      "enum": [
                        "AC",
                        "Alternator",
                        "Solar",
                        "Wind",
                        "Water",
                        "DC generator",
                        "fuel cell",
                        "other"
                      ]
                    }

And the 'description' would be changed from: "description": "Battery charger", to: "description": "Battery charging source",

Ref conversation at: #https://github.com/SignalK/specification/issues/262

Drawbacks

Although charging sources have many properties in common (Associated battery ID, voltage/current being supplied, mode of operation, charging targets), there are some items which apply to only a few chargers. The acQualities applies to AC sourced chargers, but not alternators. Likewise, an alternator needs to be associated with an Engine.

By making the charging sources common, there will be several data entries which are not fully applicable to all types.

Alternatives

The current charger entry could be reinforced to be an AC Sourced charger, and additional new stand-alone entries added for each additional charging source.

Unresolved questions

1. The method for associating devices (e.g., alternator to engine) is currently undefined - ref RFC0001 for one consideration.
2. In the current propulsion schema, the engine includes a alternator definition. If this should be deprecated or if there is some way to associate one device across two sachems (propulsion and electrical) is yet to be resolved.

[sumps]

I think this is going in the right direction, but perhaps we need to take a step back as this generalisation seems to be very charging source centric and I think we could do better.

How about breaking electrical devices down in to the following sections:

electrical.sources.dc.battery.x electrical.loads.ac.airConditionUnit.x electrical.buses.ac.lighting.x electrical.sources,dc.alternator electrical.loads.dc.inverter electrical.loads.ac.charger electrical.switches.dc.navLights etc. etc.

I think you will get the idea from the short list above. So we are grouping the electrical devices/objects by their core function, then their AC or DC characteristic and then the type of device it is. We would need to maintain a Signal K list of recognised electrical devices and I am not sure a type field with enum is the right method, I think we should include the device type in the URL so that we can query and return simple lists of the AC Loads, DC Buses or go a couple of levels lower and query the sources.dc.battery.Starter1

Now you could argue that some devices like a battery are a load or a source, but in reality its core function is to be a source of DC power and when it is a load being charged, you can monitor the Solar Panel source or the AC Charger Load.

Most of these devices can be auto populated from the information available in N2K, while new or custom devices can easily be added. For the buses we can auto-number them or develop apps/tools for users to give them "real use" names , like Navigation Instruments, Hi-Fi, Bilge Pump, Nav Lights, etc.

Comments ?

[thomasonw]

A few thoughts come to top of mind:

Perhaps one could address the batteries by either introducing a .storage. type: electrical.storage.dc.battery.x (Same concept could be used for water, fuel tanks...)

OR place the battery in BOTH the source and the loads section: electrical.sources.dc.battery.x
electrical.loads.dc.battery.x

Having the same device ID would tie them together. Doing that would be a special case of other devices which both source and consume, example a common inverter/charger might look like: electrical.ac.load.inverter.x (AC input side) electrical.ac.source.inverter.x (AC output side. Perhaps in here would call out the 'mode': pass through, idle, off, or inverting) electrical.dc.load.inverter.x (A load when 'inverting') electrical.dc.source.inverter.x (A source when 'charging)

Perhaps switches, fuses/breakers, DC/DC converters could be address the same way?: electrical.dc.load.switch.x (Input side of switch) electrical.dc.source.switch.x (Output side...) There would need to be some way to indicate a source is N/A at the moment - switch open, fuse blown.. Am wondering down the road how to give simple control input to remote switches. electrical.control.switch.x

But this also opens up how to do thinks like configure an alternator for its charge profile, or allow a BMS to control an AC charger...

Another though - would there be a benefit to embedding the bus into the access method? Maybe like:

electrical.ac.bus1.load.inverter.x
electrical.ac.house1.souce.inverter.x
electrical.dc.busHouse.load.inverter.x
electrical.dc.busHouse.source.inverter.x

Would this approach make apps simple to get the details an app needs? OR, does it break things up into way too many different paths to get a full picture of what is there, and how to monitor/control it...

This latest thought: The examples here brings back the replication of common types of information across many definitions (e.g, temperature, bus ID, % capacity). No reuse. But it would prevent the issue of a 'common charger' type containing entries which are not always used.

[sumps]

No I dislike this change in emphasis, as it makes the schema boat system specific at a very high level. Generalisation is all about creating a model of the world that covers a wide variety of situations in the same way.

Placing the emphasis on the circuit first Bus1, House1, etc. means that every system would need human intervention. At the moment a smart inverter knows what it is and can pass that information to a Signal K device that can then place it correctly in the schema.

A Signal K device has no way of automatically knowing about buses and circuits, so how would it know where to place the inverter in the schema ?

[tcs1026]

@thomasonw invited me to look at this thread - I've been using his alternator reg. I like the concept of a '.storage.' type. It avoids the replication of the element ID inherent in electrical.sources.dc.battery.x electrical.loads.dc.battery.x I think that there are complications from the separation of one element into sources and loads. For example, would a load display be capable of showing that an element is sourcing energy (and vice versa)? A 'storage' display could have the concept of 'full' and 'empty', with thresholds for 'over full' and 'nearly empty'. Applying this to tankage as well as batteries seems natural.

I don't care for the detail of input/output of switches, fuses, etc.

[thomasonw]

“’ No I dislike this change in emphasis,” – there have been several concepts floated in this thread this past 12 hours, not sure which “this” you are referring to..

[sumps]

This is the "this" that I was referring to...

"Another though - would there be a benefit to embedding the bus into the access method? Maybe like:

electrical.ac.bus1.load.inverter.x

electrical.ac.house1.souce.inverter.x

electrical.dc.busHouse.load.inverter.x

electrical.dc.busHouse.source.inverter.x"

[sumps]

I'm not sure about storage as a high level object as it can only be DC and I certainly would not like to see tanks being generalised with the electrical group. Comparisons between electricity and fluids is fine for teaching children but for real life models we have to keep them separated.

[timmathews]

I'm not sure about storage as a high level object as it can only be DC

I think you're forgetting about kinetic energy storage systems, those are AC. Granted, they only exist on Ford-class aircraft carriers. 😄

I certainly don't see the connection with tankage other than the similarity in terminology; we don't need to worry about changes here propagating into other aspects of the specification.

The top level of the electrical schema is pretty well defined, dc and ac should continue to be the only two levels under electrical. Whether or not we include storage under ac is certainly up for debate, but it seems pretty useful as a category under dc.

So we have something like

electrical.ac.sources.{shore, inverter, generator}
electrical.ac.loads.{charger, waterHeater, microwave}
electrical.dc.sources.{solar, charger, alternator}
electrical.dc.storage.{houseBattery, starterBattery}
electrical.dc.loads.{inverter, windlass, bilgePump}

I also don't think it makes sense to be "circuit first" here. We have another proposal for building generic relationships between devices (i.e. circuits) which should cover all of the circuit use cases and then some.

Placing the emphasis on the circuit first Bus1, House1, etc. means that every system would need human intervention. At the moment a smart inverter knows what it is and can pass that information to a Signal K device that can then place it correctly in the schema.

Ultimately, as @sumps points out, we need to maintain a schema which requires minimal human intervention to auto-configure. So, named circuits in the model are really a non-starter. I'm not saying that we shouldn't have them, but rather they need to be part of an optional user-configured relationship.

There are two other open issues which should be referenced / incorporated:

187: Proposal for "Circuits" object for switchable electrical objects

241: Support for binary indicators (switches, other on/off indicators)

241 is almost a perfect subset of #187, and #187 is pretty much a subset of this.

I'd like to find a more elegant solution than the n2k binary indicators - with the understanding that it needs to be able to model existing n2k binary indicators.

[joabakk]

I have followed this discussion. I think that in order to gain some value for fault finding, the user would have to provide a lot of logic to the system during set-up. I don't think it adds any value. At first it is a tempting idea, but most boat owners have a way to find faults, either by logic,luck,schematics or calling the electrician

Perhaps this was a sidestep from the main topic, but we should limit the use cases to realistic ones.

[tcs1026]

I think that the concept of a 'storage' element could be applied to anything that has a fixed capacity. When I suggested it, I had thought of any energy storage system, including flywheel storage systems, fuel cells, batteries, and fuel tanks. The abstraction of a storage element then seemed to fit water tanks, even though they don't store energy. Configuration can be minimized by automatically determining capacity limits over time. While more complex to setup, storage limits can also be set by calibration or by entering specific values. For example, the Ferriellio tank monitor (http://www.ferriellosales.com/) has a calibration procedure. The Victron BMV battery monitor must be set to the AH capacity. A display widget that can show a bar graph and high/low alarms could automatically configure itself. Drilling into an element in the bar graph could show trend data in a line graph over time.

[sumps]

I think the responsibility of the setting up and long term calibration should be the responsibility of the sensor and not passed on to a Signal K server or other device further down stream.

The schema should specify tank level, battery charge, etc. and have this as a 0-100% value and then it is the sensor or intelligent interface that has to format the data, apply initial settings and auto-calibrate.

[tcs1026]

@sumps: The tank.. and electrical.batteries.* specs include the capacity, so maybe I'm not following your thoughts. I'll look at it further.

BTW, I'm new to SK and I haven't found the data model definitions for Units:. I assume that Units:m is meters, that Units:m3 is cubic meters, Units:C is coulombs, and Units:J is joules. Is there a page defining all the possible units? Thanks!

[sumps]

This document gives all of the SK keys and units....

http://signalk.org/specification/master/keys

All units in the Signal K schema are SI units.

[tkurki]

I just changed that doc so that the units are spelled out in addition to the abbreviations. Furthermore I added a list to the beginning of the list of the units.

For some caching? reason I am not getting the updated version from the url listed above, please use the one with the trailing slash: http://signalk.org/specification/master/keys/

[tcs1026]

The items in the battery section have units that disagree with the description (Kelvin vs Celsius). /vessels//electrical/batteries//temperature/limitDischargeLower Units: K (Kelvin) Description: Operational minimum temperature limit for battery discharge, in degrees Celsius

[tkurki]

@tcs1026 thanks for pointing it out! It would be great if you could submit a pull request for any errors that you notice like the one you mentioned above. The schema files are here: https://github.com/SignalK/specification/tree/master/schemas/groups

Or you can just create a separate issue for stuff like this instead of adding to an existing issue that is about something completely else.

Mixing everything into one thread makes progress needlessly hard when you need to weed out the off topic con

(I am guilty of this as well above, but I'll end my detours here...)

[tcs1026]

@sumps: I thought some more about the calibration and I think there are some assumptions in your statement: "I think the responsibility of the setting up and long term calibration should be the responsibility of the sensor and not passed on to a Signal K server or other device further down stream."

If the sensor has local intelligence, then it could set the calibration value. But if it is a dumb sensor, it won't have that capability. Perhaps you are only considering sensors that are NMEA0183 or N2K compatible and therefore have some local intelligence.

The electrical specification has definitions for various battery values that cannot be deduced by a sensor, e.g., capacity and dischargeLimit. It seems to me that these values should be defined by user input. Perhaps you're not considering them 'calibration'.

I have a RPi that reads data from DS18B20 temperature sensors, which are dumb. In this case, perhaps you're thinking that the software that interfaces with the sensor is where the calibration and thresholds are defined? I'm thinking that the definitions are done in a Signal K UI device, such as a tablet or laptop and are communicated back to the RPi's Signal K schema so that the settings are available for other UI devices.

Finally, I have a separate observation since I'm new to this group. Things like the battery stateOfHealth don't have a good definition. Is this value derived from the delta between 'capacity' and 'actual', in which case it is redundant since the calculation should be done from the fundamental parameters. If it is something different, the definition doesn't make it clear how it is to be determined.

[tkurki]

I believe that sensor calibration is beyond the scope of the SK data model but not beyond a Signal K system.

For example your temperature sensor calibration: the calibration can take so many forms (off the top of my head: two point linear calibration, just percent adjustment, multiple points linear etc) that it is not feasible to figure out a universal data model for it.

However a Signal K server can provide the facility to install a "plugin" that allows you to

• enter correction parameters in a configuration UI
• persist the correction parameters
• alter the values from the sensor along the way to SK clients according to the parameters

The plugin may take the form of a more complex provider that may be able to push the configuration values all the way to the sensor so that no on-the-fly changes are needed but the sensor outputs the corrected value to the 1W/I2C bus or some similar connection to the SK server.

[thomasonw]

OK, seems conversations have slowed down some, maybe time to see if a direction can be set. Going back to the original issue (how to approach adding additional charging devices to the electrical spec) I think I can ferret-out three proposals:

1. Use the existing structure. Add new device types as a complete separate entry. e.g., add an 'Alternator' type - mirroring much of the existing 'charger' structure.
2. Expand the existing structure, adding a 'chargerType' entry to reduce replications (this RFC)
3. Restructure electrical.json schema along the lines as proposed by @sumps above.

Can we reach a consensus on direction?

And if option 3, @sumps - do you want to take a stab at the 1st draft for replacement of the current electrial.json schema? Alternatively I can try - but really need someone else to proof the results....

FYI: I will be out of Internet Range for about a week starting now. So please understand if I am quite for the next week while I hope this gets resolved.

[tkurki]

My vote is on (1). It presents logical grouping of devices, the device specific values have a natural home and is well in line with the rest of the electrical schema.

[tcs1026]

I'm going to also vote for (1). I think there will be many different charging sources that have unique characteristics, which would make it difficult to create a single high-level definition. It does mean that some elements will be repeated, but this will be the most flexible.

[thomasonw]

Seems option #1 gets the votes, Anyone else have a different opinion? If not, will close this RFC as rejected and proceed with expanding the current electrical spec.

@timmathews Do you want me to create a new RFC for the expansions / additions, or do I simply do a pull request, or is there some other procedural approach?

[tcs1026]

I have been thinking more about this and wanted to clarify why I think option #1 is best. Engine alternators may have parameters like RPM, while solar would not. Other sources like wind and water generators may or may not have RPM but may have other parameters that would be useful to track for that source (wind speed for a wind generator or a boat's water speed for a water generator). It will be difficult to anticipate all of the parameters that might be useful for a given charging source and incorporate them into a single definition. Using separate definitions as described in option #1, seems to me to be more flexible because the set of parameters for that charging source would all be known at the time of the definition.

[thomasonw]

Sounds good, and with Sumps Thumb Up seems just about all have aligned behind #1. So, going to close this RFQ - and will start working over the weekend with some additions for the Electrical Spec.

Still have a procedural question, do I do a new RPF - or what??

[tkurki]

@thomasonw since this discussion resulted in a resolution and is closed I would open another issue/RFC.