Path Mapper - Electrical Switch Inputs

[Phil]

Hey guys, 

I have been looking through the schema for an explanation for what the standard naming should be for 'electrical.switches.bank.0.1' it is a digital input module with 12 inputs. 
If this is connected to a bilge alarm what would the correct name for the path to be?

I am using the path mapper plugin.

[Brian Scally]

Phil

I can't say that this is the best way of doing this..  But I struggled on the same issues.
In my case I was looking at navigation lights.
Here was the 3 arguments / schemes I looked at.

--
1: The Signal K data stream is a represent of the changes of state of the boat.  In switches this is simply on or off property of the leaf.
Thus these monitored inputs banks of switches just like any other.
In reality there is a separate plugin that controls the writing of the data to the switch.  So it should know that there is no ability to write to that 'switch' and it is information only.

HOWEVER there is no human readable name associated with the data tag and there is no key for read only, or read write or write only devices.
This leaves us searching for the serial number of the electrical.switches.bank.# entities.  Their number is session unique.  But between re-powers they may appear at different bank numbers. ( I have 2 Maretron DCR100s and a RIM100 )

The only solution to this is knowing the serial number of the switch bank you want to talk to
And knowing that serial number AAAA is the switches with the navigation lights BBBB is the serial number of the deck lights and CCCC is the digital inputs monitoring the fridge motor and bilges.

This make finding the 'bilge pump' or 'anchor light' 'switch' a search for the device and knowledge of which input it is wired to.
- NOW this knowledge is necessary at installation time and when writing an app for your boat.  ( I have the same issue with tank sensors and GPS units ).
- HOWEVER I feel that this to require the 'data display' to have explicit knowledge of the connected device and structure is putting too much explicit knowledge in the app.

My thought of a solution here is to add to leaf to the switches.bank.#.#key path. A HRN ( Human readable name ) label.  The labels clearly needs to be controlled and written at  hardware device installation time and is quite a setup chore.  How the text if formatted is then the only thing that would need to be kept in check.

--
2:  The placement of the switch information in a relevant 'key path'

You could remap electrical.switches.bank.#.# to navigation.lights.anchor.  However you have to solve the problem of do you make it unique? or do you have 2 copies of the same data, can you write to one for a change of state?

For your case, if you just said electrical.switches.bank.0 was always bilge pumps you could happily remap this to  electrical.switches.bilge.0.1 and that would make fine sense.

I did this in 2 ways,  using the path mapper plugin, or by rewriting the Maretron plugin.

--

3: The addition of a 'link' in the database.

logically navigation.lights.anchor should contain a piece of information that allows you to read and write to the correct switch.  In reality I kind of coded that in the switch label property.  But it would be possible to write something that added a 'link' like property into navigation.lights.## that pointed you to the switch bank/channel.

Then your is the anchor light on would find the link property and recurse

( OR the server would do this for you..  VERSION 2? ).

Ultimately I added this information in the way I labeled the switches and would require the server to have some way of managing and generating these links.
But I could extend to add a link property.. but the data viewing application would have to know to follow the link and this felt like the wrong division.
--

FOR ME

Ultimately 2 proved increasingly  messy and convoluted.  And the more stuff that was added the more messy it became.

IF you are stopping at one set of switches it is fine, everything on my boat is digitally switched.  It became a TOTAL clusterfuck, and I ripped it out.

I have a badly written(NODE RED) label adder that takes a JSON file formatted with the serial number of the device and channel and adds a "label" property.
I feel this should be a plugin.  I am slowly working on that with all my other projects.

Following the scheme detailed for engines...

/vessels/<RegExp>/propulsion/<RegExp>/label  -  Description: Human readable label for the propulsion (1.5.0 page 82)

So now I have :
An  electrical.switches.bank.0.label key - this contains a description of where I installed the unit. { Yes I sometimes forget }
An  electrical.switches.bank.0.1.label keys - this contains a description of the switch function ie "pump.bilge.fore"
Clearly these are not high delta flow items.  But when an application subscribes to electrical.switches it gets the labels and works out which bank and channel are relevant for it's 

purpose.

For example the fridge run counter looks at the one and off times when it gets a delta with a change and adds the times up.

-----------------

Now may be I am off base with what I did.  I made it work in a maintainable method.  And that is a good thing.

Brian