Introduction from a newbie, retired SCADA Architect

[NewbyNW]

Greetings all.

I have been lurking for a while and thought it time to introduce myself and contribute. Firstly, well done to all and many thanks!

My background: Highschool: ('77) PDP-10 timesharing account and SC/MP microprocessor evaluation kit [dinghy sailing]. University: Electronic Engineering [windsurfing]. First career: television broadcast engineering maintenance. LDK5 camera specialist, Sony BVH tape remote RS422 control by assembly programming on 286 [keelboat race crew]. Second career: Network support engineer, push transition from SPX to IP. Make menu-config on 22 floppy slackware [ski boat]. Third career, SCADA (Supervisory Control and Data Acquisition) System Architect, translate "Control Systems Engineer" speak/CAD into "Information Systems" speak/Visio and vice-versa without blood being spilt (only just!)[Traditional carvel jarrah Motor-sailor]. Retired to cruising from Fremantle to Philippines with a few years on the way there and back spent in Indonesia. OpenCPN grateful user with many KAP charts. https://www.marinetraffic.com/ais/details/stations/2094 https://www.findacrew.net/en/boat/212777

With time locked up in Sicily instead of Christmasing in Australia, I looked for a new hobby and found SignalK!

First pass through docs, installed node version server on raspian laptop (to get the flavor) and a PI zero and zeroWH to test the loads (30 AIS @ 7/sec AIS-forwarder 40%cpu). I/O anticipated using MEGA with Node-Red+Johny5+firmata. MCP2515 reading N2k. Discovered ESP-cam.

Detour through Venus because of Quattro on board, rejected GX for now (non-PI, noted their reasons, integrated MK3 "expensive") but purchased USB-MK3 because that's one wheel I don't want to re-invent.

Second pass through the docs and source and SenseESP. Trying to get a good feel for SignalK control semantics at the supervisory (setpoint) level and also micro-controller(PLC) servo-loop level. So far I have found the following control software:

signalk-switch-automation server plugin talking N2k so no SignalK controller semantics to worry about. Likewise signalk-empirbusnxt-plugin signalk-fusion-stereo signalk-instrument-light-plugin etc. This first class of plugins talk to devices in their native protocols and might properly be described as gateways. Great job reverse-engineering or even just implementing those!

Node-red based i/o can do anything so it is in a class of it's own, it could talk to local PI relays or any protocol including SignalK. Before discovering SenseESP it was my preferred choice.

SenseESP has 3 examples, relay_control, smart_switch_example, remote_switch_example.
relay_control logic is "if {get some SignalK value/s , apply some logic} do something else" so it is in the same (but remote) class as Node-Red, ie based on some SignalK value/s do something.
remote_switch_example is actually conceptually a UI-client device, it may be compared to a smartphone that has permission to PUT a value

smart_switch_example is the only bit of code I can find to remotely claim registration of ownership of a control point with the server by using SignalK protocol, and I'm unsure of the underlying semantics of it doing so.
// Here, we set up a SignalK PUT request listener to handle
// requests made to the Signal K server to set the switch state.
// This allows any device on the SignalK network that can make
// such a request to also control the state of our switch.
auto* sk_listener = new SKStringPutRequestListener(sk_path);
sk_listener->connect_to(controller);

So I joined slack to learn more, found SignalK/specification#592 and decided to jump in here:)

I'm not a control system engineer but I understand many of the concepts. I'm not a programmer or a protocol specification designer but I have some experience with assembler, C and DNP3. I offer some observations as a retired and out of date SCADA architect;)

As a "thought experiment", what does the future look like without any other protocols on board? Is that desirable? NMEA see benefits in co-existing with a firewall... but security by obscurity is no longer tenable cf AIS transmissions spoofability. Do we want SignalK all the way from cloud, smartphone, chartplotter, ... ,rudder hydraulic valves, bilge pump, throttle?

It looks like the answer for some is a resounding yes. So the protocol needs to be fit for purpose (and the servers, maybe I need to learn multi-threading Java & Artemis;)

I searched for "setpoint" in the spec, which is a key control systems concept and found 6 instances in electrical, ok good start but keep looking...
/steering/rudderAngleTarget is a good one for the steering servo to compare with /steering/rudderAngle I sense history in the comment "Vessel steering data for steering controls (not Autopilot 'Nav Data')" so I'll steer clear of the many "Model Specific" setpoints in /steering/autopilot [as an aside, I have always had jog-wheels on my AP4 and Coursemaster so I could argue that increment/decrement current heading is an essential addition. Never having owned a Raymarine, +10 buttons are something I don't need but doubtless many would miss?]

Finally some questions, if only rhetorical;)
How do I set the fridge thermostat target_temperature setpoint for the fridge reported at /environment/inside/wine_fridge_forward/temperature
Everything I could achieve by direct compressor and fan control [stagger motor starts between fridges, store "coolth" instead of chemical energy when genset is running, &etc.] can be achieved by multiple "smart thermostats" in response to appropriatly varying setpoints (maybe a deadZone as well, or perhaps hysteresis?).
So, should the protocol reference all the way down to fridge lights, fans, compressors and be suitable for inter-process-control communications (via a server on a PI) or should it stay more supervisory or both?

Anyway, enough for now. Thanks again for the effort so far and I leave you all with a straw poll...

A bilge pump on an unattended boat should be connected to a float switch by: A) A pair of wires. B) An ESP wifi module C)SignalK node-server on a RaspberyPi

My vote, still "A" but there are regulatory reasons pressing towards "B, with backup from A and supervision by C"

[ba58smith]

NewbyNW, I'm just now reading your post. Sorry - this Discussions hasn't gotten much traction yet, so not many people are looking at it on a regular basis. Welcome to Signal K, and I hope the lack of responses here hasn't dampened your interest in Signal K!

[NewbyNW]

Hi Brian, thanks for the reply. There is so much info out there that I previously overlooked your: https://github.com/ba58smith/SigkSens#signalk (ok, the MCU hosts a SignalK websocket server sk_listener, I was so intent searching for the "remote control protocol" that I misunderstood that ;)
Actually, from a system perspective I like this. Every device that participates in the hierarchy behaves the same. I was having the problem with GET and PUT that we used to have with 232 Rx and Tx (yes, but in which direction, aka just who is the client and who is the server atm?!)
The down side is that the MCU must support at least a web socket server as well as an IP stack and a physical layer supported by IP (and security). ESP's can do that with WiFi and hence a great project.

For the moment my mega's are using firmata protocol over USB physical because it just worked out of the box with Signalk-node/node-red/johnny5/
I really don't like the USB physical layer at sea, any more than I like wireless control (did I mention I'm getting old;). 422 point-to-point is a step backwards. CAN is another big overhead for an old style MCU. So my interim control solution is looking like modbus-485. Wired, manually addressed, lowish overhead, plugin available in addition/alternative to node-red.
I have a whole bunch of ESP32-cam's on order (50% faulty on last lot so returned them:(
After getting some experience with wifi on board for cameras I shall try and integrate SensESP for sensors and may later come back to it for control...
Thanks again, Nigel

[ba58smith]

@NewbyNW , you may have noticed that https://github.com/ba58smith/SigkSens#signalk has had no activity in over a year. There's a good reason for that. It's a fork of https://github.com/mxtommy/SigkSens, which is pretty much "discontinued", replaced (in a de facto sense only) by https://github.com/SignalK/SensESP.

Neither of these projects are mine - I've only worked on them. (Used them first, started writing documentation for them, and then finally started doing some coding - some very basic coding, I should add - on SensESP.) But SensESP is a very active project that has grown immensdely in its capabilities over the past 18 months or so. For now, you can get help for it on the Slack Signalk -dev site, in #sensors. If you haven't been on Slack Signalk-dev yet, you should check it out. That's where the vast majority of discussion happens. As noted earlier, this Google Discussions hasn't gotten much momentum yet.

BTW, I barely understand what you say about protocols and layers and so on. I limit my coding to things I understand - mostly how to interface with various hobby-level sensors (I love anything from Adafruit!). Lately, I've been working on a project for a Signal K-enabled LilyGo 2020 watch (which is an ESP32 in wristwatch format). It's still a private repo, but will become public soon enough. Again, it's not my project - I just try to make it a little better here and there.

Butch