Spec for intermittent motors and pumps

[bobhy]

Motivated by a desire to monitor my bilge pump in SignalK. But a standard should be applicable to other kinds of pumps (think domestic water, hydraulic, macerators) and to intermittent motors of all kinds (think fans, compressors).

For pumps, we will also want to measure flow, or proxies for flow like pressure, rpm, amperage. Please add your thoughts!

Core stats:

• status: (string) RUNNING, STOPPED or UNKNOWN (means sensor isn't reporting anything)
• last_edge: (UTC timestamp) date/time of the transition into the currently-reported status.
• history_start: (UTC timestamp) date/time the following stats were zeroed.
• cycle_count: (integer) cumulative number of duty cycles. (I propose a duty cycle is counted on the transition from RUNNING to STOPPED, but that's arguable.)
• run_time: (seconds) cumulative RUNNING time in the current epoch of history

This should be able to appear under a path called "motor" or "pump", e.g "electrical.motor.N...." or "hydraulic.pump.N...."

[preeve9534]

In some ways #600 may relate to this. It seems to me that we need to be clear about what classification principle is at play - are we structuring things around their application or their power type?

I would suggest the former is generally preferable and then the power type would become an attribute - after all, motors do something, they don't operate in isolation. That does however tend to demote motors to a secondary level of importance from which the perhaps should be rescued. Given the ubiquity of pumps on a vessel, then I can certainly see these standing as a top-level entity and this would yield

pumps
id

and the rescue strategy might give

motors
id

If a pump is operated by a motor (as would usually be the case), then it would be useful to be able to associate a pump with its power source and I'm not sure if there is an emerging mechanism in Signal K for this cross association.

As an aside, the Signal K standard seems to adopt plurals for collection of things (think tanks and switches) and the status of something is mostly reported as state (rather than status). Also, camelCase is used rather than '_'.

[bobhy]

Just picked up on this response: I'm new to Slack and had allowed Gmail to bury the email in "forums". I've skimmed #600, but need to read it. And my own ideas on what I actually want to see from the bilge pump are evolving as I get closer to actually deploying and sailing with it this spring. So I will be updating my proposal in the coming weeks. Thanks for pointers on schema nomenclature, will do. I'm just reading about the {meta} now! Do I understand that a plugin can and should emit a {meta} object along with each {value} on each sample, both via streaming and REST? Then I could make meta.description configurable, and let user call it what s/he wants, regardless of any spec-imposed constraints on the path. e.g, whether the path is electrical.motor.... or electrical.battery... (or even hydraulic.pump...) the meta.description could be configured to be "bilge pump". Though this is not currently discoverable I think? mxtommy/kip doesn't let me select data to display by description, only by path, nor does it seem to use meta to generate automatic titles. More research necessary....

…

On Sat, Dec 25, 2021 at 4:58 AM Paul Reeve ***@***.***> wrote: In some ways #600 <#600> may relate to this. It seems to me that we need to be clear about what classification principle is at play - are we structuring things around their application or their power type? I would suggest the former is generally preferable and then the power type would become an attribute - after all, motors do something, they don't operate in isolation. That does however tend to demote motors to a secondary level of importance from which the perhaps should be rescued. Given the ubiquity of pumps on a vessel, then I can certainly see these standing as a top-level entity and this would yield pumps *id* and the rescue strategy might give motors *id* If a pump is operated by a motor (as would usually be the case), then it would be useful to be able to associate a pump with its power source and I'm not sure if there is an emerging mechanism in Signal K for this cross association. As an aside, the Signal K standard seems to adopt plurals for collection of things (think tanks and switches) and the status of something is mostly reported as state (rather than status). Also, camelCase is used rather than '_'. — Reply to this email directly, view it on GitHub <#634 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAPBIZBL25JQC6BR5BWDL63USWIVZANCNFSM5KXKMIZQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>