2020-02-25, 02:35 AM
(This post was last modified: 2020-02-25, 02:45 AM by seandepagnier.)
It is unfortunately infeasible for pypilot to use the signalk format strictly and directly.
Instead a pypilot-signalk-node plugin is needed but not developed yet. using node-red will be poor performance and difficult to configure but still interesting to try.
Please correct me if I am wrong but:
1) signalk lacks the ability to be routed. Clients do not register data and produce it according to subscriptions, instead plugins on the server handle this role. This means it's not feasible or efficient to route data through several signalk servers. All data is produced at the fastest rate regardless of if any clients are subscripbed so it is not efficient to produce costly data. All of the important plugin logic must be implemented in the server as plugins rather than signalk clients which unfortunately means it is not possible to distribute plugins for the server on remote hosts, and also the plugin logic must use javascript at least writing signalk-node-server plugins in other languages is unknown. Because so much logic is implemented in plugins rather than clients, it is unlikely alternative signalk server implementations will emerge.
2) redundant data -- the signalk format is not concise making it less efficient and extra logic in code to process. This does not prevent integration as a translation can be used but it is better for pypilot specific services to not be forced to deal directly with this format to ensure the best performance.
3) listing -- no way to get directory listing without using http requests. This complicates simple implementations.
4) security -- I use a WPA wifi network to prevent others from controlling the boat. websockets and ssl encryption are not needed and complicate as well as increase latency. better to use ssh tunneling instead of websockets if this type of security is required.
5) poor autopilot interface -- signalk defines a few autopilot keys which are redundant and require signalk-node-server to perform autopilot logic to update absolute fields from relative ones since both are defined unfortunately. The interface misses a lot of what pypilot implements and seems to be intended to control nmea2000 autopilots. For this reason, any signalk autopilot control will be much inferior to just using the direct pypilot control options.
The data format of pypilot does not have these issues but lacks a lot of other flexibility in signalk that is not useful for pypilot.
Instead a pypilot-signalk-node plugin is needed but not developed yet. using node-red will be poor performance and difficult to configure but still interesting to try.
Please correct me if I am wrong but:
1) signalk lacks the ability to be routed. Clients do not register data and produce it according to subscriptions, instead plugins on the server handle this role. This means it's not feasible or efficient to route data through several signalk servers. All data is produced at the fastest rate regardless of if any clients are subscripbed so it is not efficient to produce costly data. All of the important plugin logic must be implemented in the server as plugins rather than signalk clients which unfortunately means it is not possible to distribute plugins for the server on remote hosts, and also the plugin logic must use javascript at least writing signalk-node-server plugins in other languages is unknown. Because so much logic is implemented in plugins rather than clients, it is unlikely alternative signalk server implementations will emerge.
2) redundant data -- the signalk format is not concise making it less efficient and extra logic in code to process. This does not prevent integration as a translation can be used but it is better for pypilot specific services to not be forced to deal directly with this format to ensure the best performance.
3) listing -- no way to get directory listing without using http requests. This complicates simple implementations.
4) security -- I use a WPA wifi network to prevent others from controlling the boat. websockets and ssl encryption are not needed and complicate as well as increase latency. better to use ssh tunneling instead of websockets if this type of security is required.
5) poor autopilot interface -- signalk defines a few autopilot keys which are redundant and require signalk-node-server to perform autopilot logic to update absolute fields from relative ones since both are defined unfortunately. The interface misses a lot of what pypilot implements and seems to be intended to control nmea2000 autopilots. For this reason, any signalk autopilot control will be much inferior to just using the direct pypilot control options.
The data format of pypilot does not have these issues but lacks a lot of other flexibility in signalk that is not useful for pypilot.