2020-03-03, 05:13 AM
(This post was last modified: 2020-03-03, 05:21 AM by seandepagnier.)
First, thanks for the reply and interest.
By converse the pypilot specification can fit on a single page and supports forwarding subscriptions, but doesn't handle multiple sources for the same key since this feature is not utilized by pypilot anyway.
It seems this is already needed if the signalk server makes a client connection to another signalk server so that it can subscribe to all the messages its own clients subscribed at whatever the fastest rate for each one is.
I will open an issue. I agree with you completely. The difficulty for me is implementing in javascript what is needed.
Discovery is great for some applications but I am not sure about pypilot.
It is possible to have two openplotters each with a signalk-node server and a single pypilot. So in this case pypilot would need to discover both plotters to update their signalk. It is not clear which plotter it should receive updates for route following or other autopilot control. You could just run signalk-node on a single openplotter but then if it goes down the other plotter will stop too.
Also possible is two pypilots (one backup standby) and a single signalk-node server. In this case they could both discover the single signalk node server and maybe it would work as intended after all, but could cause unintended consequences.
If there are two plotters and two pilots it is not as clear how the connections should be made.. how data will flow and avoid loops but also allow any of these devices to stop working without disabling the rest.
The alternative is to just have the user manually add a signalk connection to pypilot from the node-server setup once that is fully supported. This would give the most control but is an extra step and if changing network setup annoying.
Any thoughts on this? Is it possible to have detection by default unless connections are specified and how would this be supported?
(2020-02-28, 12:17 PM)tkurki Wrote: The current standard is somewhat confusing supporting websockets, tcp as well as using http GET and POST requests.I think signalk is confusing at first because as mentioned the specification is "heavy" there are a lot of details and it's more complicated than nmea or other formats but also more powerful.
To share a little background: we started with http for data retrieval and WebSockets for streaming. Tcp was added by popular request (I think I remember you saying that tcp is the preferred mechanism, as well as request-response over ws. Ws and http have standard mechanisms for authentication and secure communications and can be used in browsers, as opposed to tcp lacking of all these qualities/features.
Maybe we can improve the specification or add documentation to clear up the confusion? I am way too deep in this to see the it - can you expand on this?
By converse the pypilot specification can fit on a single page and supports forwarding subscriptions, but doesn't handle multiple sources for the same key since this feature is not utilized by pypilot anyway.
Quote:The subscriptions are not forwarded so linking servers is inefficient.
Like with many things open source feature X is added when sufficient interest and somebody willing to do the work meet. The need for forwarded subscriptions surfaced recently - I am willing to help in the implementation but I'll need help in fleshing out the details and use cases. Care to elaborate on this? Preferably in a Github issue.
It seems this is already needed if the signalk server makes a client connection to another signalk server so that it can subscribe to all the messages its own clients subscribed at whatever the fastest rate for each one is.
I will open an issue. I agree with you completely. The difficulty for me is implementing in javascript what is needed.
Quote:The data flow is only from server to client (except for PUT which is impractical for streaming data)This is very good news. Maybe because I was using tcp sockets but I just got websockets working with python now so as long as "updates" can go both ways it is going to work. The next step is making "subscriptions" also go both ways.
This is not true, ws connection has been two way for years and in use by projects like https://github.com/SignalK/SensESP and https://github.com/SignalK/SensESP.
Quote:how to discover the signalk server address is unclear.
Again could you please give a little more detail? The process is documented at https://signalk.org/specification/1.4.0/...ction.html and people have successfully implemented discovery. If there's something missing in the docs (or the discovery mechanism) let's improve them!
Discovery is great for some applications but I am not sure about pypilot.
It is possible to have two openplotters each with a signalk-node server and a single pypilot. So in this case pypilot would need to discover both plotters to update their signalk. It is not clear which plotter it should receive updates for route following or other autopilot control. You could just run signalk-node on a single openplotter but then if it goes down the other plotter will stop too.
Also possible is two pypilots (one backup standby) and a single signalk-node server. In this case they could both discover the single signalk node server and maybe it would work as intended after all, but could cause unintended consequences.
If there are two plotters and two pilots it is not as clear how the connections should be made.. how data will flow and avoid loops but also allow any of these devices to stop working without disabling the rest.
The alternative is to just have the user manually add a signalk connection to pypilot from the node-server setup once that is fully supported. This would give the most control but is an extra step and if changing network setup annoying.
Any thoughts on this? Is it possible to have detection by default unless connections are specified and how would this be supported?