Onderwerp: Sailing Performance Dashboard

michaelh schreef :
Dan is de vraag, werkt os.getcwd() wel op de Pi....

Of is de picture.gif er niet??

Zeker wel. De getcwd werkt, want dat was namelijk eerder de oplossing. Picture en icon zijn er ook. Ik hoef ook alleen op OK te drukken..
Zodra ik headless.txt weer weghaal start SPD weer gewoon op zonder te vragen.

michaelh schreef :
Heeeel gek. Zal er weer naar kijken.

De berichten van SPD voorzie ik van:
"SPD error : de fout"
"SPD info : de info"
SPD question : de vraag"

ok?

michaelh schreef :
Gevonden! Verraderlijk dingetje.....

Dit is de code die het plaatje ophaalt:

picture=PhotoImage(file=filestoredef+"/systemfiles/background.gif")

Maar dan staat het nog niet op het scherm (in tK)
Toch is kennelijk al een actief tK window hierbij nodig.... en dat is er niet, headless.
PhotoImage() gebruikt dat stiekum intern al.

Opgelost dus.... binnenkort in 3.0.1.

Eerst nog even kijken naar de mogelijkheden om door te draaien zonder NMEAinput.

De laatste wens: doordraaien zonder NMEA input.....

Het zit er nu in, voor TCP en UDP.
Voor serial is het teveel gedoe. Daar kan een COM of TTY die niets binnenkrijgt ondanks een time out-specificatie toch blokkeren. De time-out geldt slechts voor de verbindingsopbouw, niet voor het ontvangen van berichten.
Dus een COM of TTY die wel open is maar niets binnenkrijgt hangt de hele boel op.
Dat blijft zo. Stoppen van SPD is dan de enige optie, en dat doet het dan ook.

Voor TCP zit het er wel in. Als de verbinding intact blijft maar er niets binnenkomt geeft SPD een melding. Als er weer data komen loopt alles weer door.
Als de verbinding verbroken is moet alles opnieuw geinitialiseerd worden (socket maken, connect etc).
Dat gaan we dan niet doen.... dan wordt het stoppen en weer opstarten.

UDP is het simpelste: geen verbinding, alleen luisteren.
Als er niets komt dan verschijnt een bericht.
Als er weer NMEA komt loopt SPD weer door.
Kunnen dan nog wel wat opgespaarde meldingen komen over de uitval....

Het kan tot totaal geblokkeerde toestanden leiden, waarbij zelfs de stop-knop het niet meer doet.
Iets voor gevorderden dus, en daarom aan en uit te zetten met een nieuwe key in processlist:

[Starting specials]
Run on empty = Y

Mijn advies: lekker op N laten staan

Even de manual etc doen, dan komt 3.0.1

v3.0.1 vrijwel klaar, github is bezig...

Version 3.0.1 of 27 January 2022
- Error in headless operation solved; no more unwanted tK-screen will appear.

- The messages (info, error, askquestion) from SPD in headless mode are now more easily recognisable. They start with
SPDinfo, SPDerror and SPDquestion, followed by : and then the text of the message (title and text). This makes it easier to detect them with a piece of software (Node Red, f.i.)

- SPD can now in network mode continue to run when there is a temporary standstill in the NMEA records stream. Earlier, SPD stopped when there was no more NMEA coming in.
That is still the case when using serial (COM , TTY).
When using TCP, SPD will go on as long as the TCP connection is active, records or no records. A message will show up when the NMEA stream stops.
If the TCP connection breaks, SPD will still stop.
When using UDP, there is no connection, so SPD can just wait to see if records start coming in again.
Nota Bene:
SPD will only operate this way (go on with no data coming in) when a new key in processlist.ini is set to Y:

[Starting specials]
Run on empty = Y

When Run on empty = N, SPD will, as before, stop when records do not arrive.

Since this can lead to a blocking TCP socket (and thus a non-responsive SPD) it is advised to only use this when you know exactly what you are doing. In a normal, stable operating environment these should be no need for Run on empty = Y

- The webserver output is now visible on a web page. Point a browser to webservername:webserverport/demo (name and port defined in sendoverwifi.ini). You will see live webserver output.


En nu (foutjes voorbehouden) eerst maar allemaal eens proberen

De run on empty functionality is helemaal top.

Mn rpi draait t allemaal prima.
Zie alleen dat de node-red 35% cpu vraagt in mn demo setting op een rpi4 8gb. Komt door de grote bak aan variabelen.
Eens kijken wat dit in real life gaat worden, en anders moet ik de node red flow trimmen en spd alleen uit laten sturen wat ik gebruik (10% gok ik). Dat laatste kan al dacht ik, dus moet goed komen.

Jij stuurt de data vanuit N2K via SignalK naar SPD toch? Gebeurt dat met de snelheid waarmee N2K data gelezen wordt? Zoja, dan zal dit een grote datastroom geven. Kun je SignalK beperken in haar executiefrequentie wellicht?

Ik draai nu een demo 0183 file in signalk als source.
Dat draait met een redelijke snelheid, misschien iets sneller dan mn normale n2k stream, maar niet veel meer zo ik even kon zien.
Kon zo even niks vinden om n2k de demo file langzamer te laten draaien. Maar is ook niet zo relevant. Het gaat om hoe t straks werkt in t veld.

Opties genoeg om t te trimmen. kan inderdaad ook de frequentie naar 1Hz brengen bv.

met de file webserverselection kun je de output van de webserver tot iets heel kleins reduceren.

Dat gaat met 1 slim regeltje Python (dank Menno!). Krachtig taaltje, dat Python....

webserverdata = {key: value for key,value in webserverdata.items() if key in chosenwebserverdata}

Ik heb SPD even schematisch neergezet met al zijn data, in en out, en de files.
Best veel geworden... voor iets wat alleen NMEA moest kunnen maken over serial
Plaatje voor de volgende versie manual.
Pijltje van de webserver moet nog 2 kanten op,je kan immers button commands geven!

Mooi overzicht!

Waarom zoveel configuratiefiles, weggestopt in verschillende folders? Zou het gebruikersvriendelijker worden door één .ini file te gebruiken met verschillende secties?

Gedaan omdat de meeste gebruikers er maar een (boat) echt nodig hebben. Verkleint de kans op fouten. Maar alles in een ini zou ook kunnen..

Jumpinjack schreef :
Zeker wel relevant. Ik heb de nodered flow zo gemaakt dat er makkelijk delen uit te halen zijn, maar dat leidt wel tot veel berichtenverkeer in nodered. Dat verkeer kan sterk gereduceerd worden met een iets andere opzet van de flow. Het kan zelfs bijna helemaal verdwijnen als spd de signalk Keys direct kan sturen. Ik zal binnenkort eerst eens kijken of de flow compacter kan. Het moet natuurlijk ook mogelijk blijven minder data te sturen, maar zou niet nodig moeten zijn.

Ik ontdek zelf ook steeds meer manieren om SPD te gebruiken

De nogal lange trimadviezen zijn prima in een browser (tablet, telefoon) te bekijken aan boord.
Als je in webserverselection.txt alleen die adviezen aanzet (en stroom en wind-waarschuwingen) en je gaat met je browser naar het juiste adres dan zie je dit soort dingen, elke secomde een update:
(de knoppen werken alleen in headless mode)

De trimadviezen.....

er wordt nu gelet op de volgende condities (die een of meer adviezen genereren):

wind, scheef en langzaam: helling 5+ graden meer dan target helling, tws > 10, perf < 95
scheef: helling 5+ graden meer dan target
teveel roer en langzaam: roerhoek > ingestelde max en perf < 95
light air en langzaam: tws 2-7 kts en perf < 95
knijpen: hoger dan beste UA en perf < 90
te ruim: ruimer dan beste DA en perf <95
buitenschoot nodig: tws tussen 65 en 100, perf < 90
te langzaam: perf < 92

Dat is simpel uit te breiden (als de data voor het vaststellen van de toestand aanwezig zijn; SPD kan niet zien of de schoten genoeg zijn aangehaald, bijvoorbeeld....)

Wat zou er nog bij moeten?

Als SPD, naast het ontvangen van tcp nmea0183 (wat eea echt flink vereenvoudigd), ook 'gewoon' de outbound op tcp zou zetten, dan is het hele node-red stuk overbodig and kan signalk gewoon beide als een simpele datasource aanhaken.
En kunnen ook andere applicaties wellicht makkelijk gebruik maken van de data.

welke outbound data bedoel je? De eigen NMEA?

Signalk kan ook data over tcp ontvangen.
In 3 types: nmea2000, nmea0183 en in signalk.

Aangezien spd niet alleen maar standaard nmea0183 gegevens produceerd maar veel meer zou je dat idealiter dan 'in signalk' op tcp moeten zetten om alles beschikbaar te maken.

Of alleen maar de nmea0183 uit, net zoals op de serial, maar dan gaat er wel aardig wat verloren.
Of dat overigens een groot gemis is, dat is de vraag, in mijn huidige setup stuur ik beperkt data naar mn schermpje, dat zal via deze route ook wel lukken.

Apps als iSailor, iRegatta, navionics, OpenCPN etc ontvangen allemaal nmea0183 over tcp. Als SPD een TCP stream aan biedt, dan kan in deze navigatie apps de data ook getoond worden.
Overigens, hoewel mn plotter t wel op de wifi zet, kan die het niet ontvangen over tcp.

De eigen NMEA met gekke vulling zou misschien kunnen, hoewel je tegen dezelfde dingen zal aan lopen als bij instrumenten: het moet in het veld passen en aannemelijke data bevatten. Performance kan niet in een kts-veld, bijvoorbeeld (teveel cijfers).

In SignalK op TCP zetten kan niet zomaar; er zijn allelei data uit SPD waarvoor Signal K geen definitie (heet dat key?) beschikbaar heeft.
Bovendien is het gaan inpakken in dat Signal K formaat een heleboel werk; remember, die berichten worden 600 keer langer dan een NMEA-bericht

Tweerichting TCP (dan moet SPD zenden en ontvangen) is te lastig. Alleen de eigen NMEA over TCPde wereld in slingeren (a la UDP maar dan naar een bepaald adres) is ook al lastig, want je moet dan een sessie (connect) opbouwen tussen SPD en een ander ding.
Daar heb ik rond de kerst 3 weken mee zitten kloten (SPD op PC en een terminal-app op een handheld) en ik heb het opgegeven

Waarom luisteren die apps als iSailor, iRegatta, navionics, OpenCPN niet gewoon naar UDP???

UDP doen ze ook, zolang het in nmea0183 format is.
Signalk luistert ook naar UDP.

En dat zit er al in zeker?

ja

mmm, krijg dat niet gelijk aan de praat.

Ik heb TCP als incoming.
Als ik de manual lees, dan worden er in dat geval geen UDP messages aangemaakt?

Jumpinjack schreef :
Dat klopt.
Alleen met UDP in ook UDP out.....

if replaynmea=="N" and channel == 'network' and NMEA_NETPROT=="UDP" and not stopping:
dan gaat ie NMEA-records verzenden naar SP_NMEA_IP : SP_NMEA_PORT .

Als ik de and NMEA_NETPROT=="UDP" weghaal doet íe het ook als er TCP-NMEA binnenkomt....

Dus dat wil je erbij? Waarom geen UDP in?

Even getest met TCP-nmea erin en UDP-nmea eruit, dat werkt. Binnenkort in v302.

Wat nmea betreft: als je aan de ontvangende kant (Signal K?) ook zelfgemaakte nmea183-records kunt ontvangen en uitpluizen kunnen we natuurlijk alles wat je wilt daarin verzenden.
We zitten niet vast aan de officiele nmea183-types.

Zo zijn er al de MVW en MVP, voor de Multiview II van roos.
En er zijn 2 nog lege types PSMD voor toekomstig gebruik met een Miniplex.
Zie NMEAtemplates.txt

Niets houdt je tegen om die records in NMEAtemplates.txt te vullen met wat je maar wil verzenden.
En dan aanzetten in boatspecifics. Zo kun je (vrijwel) alles via NMEA transporteren.
Ik zou ook een type SPDIY kunnen maken, mag je dan ook helemaal zelf invullen. Maar vooralsnog hebben we 4 zelf te vullen types.

Kleine beperking nog even:
sommige van de laatst toegevoegde data-soorten (AW_filter, de 3 trimadviezen) worden nog niet begrepen door de leesroutine voor NMEAtemplates. Dat is zeer eenvoudig op te lossen.
Ik hoor het wel.