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 69 forks source link

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

Open mark-tilden opened 8 years ago

mark-tilden commented 8 years ago

The schema needs a general way to support binary indicators. There are probably some specific/common use cases that may be explicitly supported, but a more general mechanism for non-specific binary indicators is also important.

Specific cases would include:

  1. Bilge pump running (including count of run-time and total length of run time).

Non-specific cases would include:

  1. Magnetic door switches (indicating a door or hatch is open)
  2. Motion detectors
  3. Other general-purpose digital on/off switches (e.g. I have a digital keypad to arm/disarm alarms)

Maretron makes two devices that are designed specifically for these purposes:

RIM-100 is a "Run Indicator module" that is designed to sense an energized device (like a bilge pump) running. See: http://maretron.com/support/manuals/RIM100UM_1.1.html SIM-100 is a "Switch indicator module" that is designed to sense a switch closure. See: http://maretron.com/support/manuals/SIM100UM_1.2.html

Both of these devices include on-board counters and total run/on/off time, which should be supported in the schema.

mark-tilden commented 8 years ago

It looks like there's a related issue (#187) that addresses a variety of different loads. While including current draw and other parameters is a good idea, my primary interest is "Is this device or switch on/off/open/closed" and how long has it been in that state and how many times has it transitioned. (as per Maretron RIM-100 and SIM-100 functionality).

sumps commented 8 years ago

Issue #187 was a good suggestion, it just came at a time when everyone's attention was on getting V1 done and we had decided not to tackle electrical switching in that first release. However now we need to start compiling a "wish list" for V1.1 and I would definitely like to see electrical switching included.

We need to define a flexible and powerful solution that will encompass all of the things that we want Signal K to do in the future, but we also have to recognise that currently we have well proven commercial devices like the Maretron units that use NMEA2000, so we need to make sure that a sub-set of the Signal K data fields we define can be easily supported and mapped to the NMEA2000 PGNs, so that we can immediately support the products that are out there and installed on boats now.

We need to design new Signal K data objects based on #187 but ensure that initial implementations at least support devices and scenario you have defined above.

sailoog commented 8 years ago

+1 here.

We have implemented Raspberry GPIO digital devices in OpenPlotter project and we will provisionally use notifications group to manage this kind of sensors:

notifications.GPIO.input/output.GPIOxx.message=L/H

sumps commented 8 years ago

A device connected to the NMEA2000 network can provide the status of any binary switches and change the state of the binary switches but I would not recommend that a gateway sits and monitors the status of devices on the NMEA2000 network and then informs the world if they have changed. This needs to be done by the app or service that is interested in the state change.

mark-tilden commented 8 years ago

I think I agree......but I'm not sure......

In my particular case, I'm using an iKommunicate signal K gateway and will be monitoring the N2K data via that gateway using a Raspberry. It will watch these switches and generate alerts/alarms on appropriate conditions.

If I understood what you were saying, you were recommending that the gateway itself not do any monitoring/triggering on it's own. Correct? If my understanding of your comment is correct, perhaps you could elaborate on why you think it's inappropriate for the gateway to do this kind of monitoring/triggering?

I'm mostly curious, because I don't expect that the iKommunicate would have this kind of functionality anytime soon, but perhaps you're addressing the question of whether the Signal K standard would support monitoring/alerting functionality?

On Wed, Aug 24, 2016 at 12:13 PM, sumps notifications@github.com wrote:

A device connected to the NMEA2000 network can provide the status of any binary switches and change the state of the binary switches but I would not recommend that a gateway sits and monitors the status of devices on the NMEA2000 network and then informs the world if they have changed. This needs to be done by the app or service that is interested in the state change.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/SignalK/specification/issues/241#issuecomment-242176823, or mute the thread https://github.com/notifications/unsubscribe-auth/AULYOlgDPRyG3nZZ8oFT-WUR-wsq8pM4ks5qjJfqgaJpZM4JpUiH .

sumps commented 8 years ago

Gateways are real time data converters and filters between two networks and for a gateway to monitor devices and to trigger notifications when their state changes would become a massive overhead. Much better that it efficiently passes the status information to Signal K devices and then an App or Service running on a server or an App/Consumer running on a mobile device can decide what it wants to monitor and produce the relevant notification when a particular condition occurs.

The only notifications that I see the gateway sending to Signal K are NMEA2000 alarms and alerts, which will simply be converted to a Signal K notification, but the gateway is just passing it on, not making any decisions about it.