Onderwerp: Sailing Performance Dashboard

Beetje aan het stoeien met de layout op het scherm.
Die kan je binnenkort zelf opgeven, door van elk hoofd-window de rij en kolom op te geven in de processlist.ini
Rij 1 kolom 1 = 0,0

[Geometry]
rcwind = 0,1
rccourse = 0,2
rcspeed = 0,3
rcpic = 0,0
rcangles = 1,1
rcbutton = 1,2
rcperf = 1,0

geeft



Veel kansen om er een bende van te maken

Ook een kans om zonder scherm te draaien? Op de pi kunnen we nu 2x spd draaien, een keer om performance waarden voor signal k te berekenen en een keer voor de nabewerking. Bij degene gekoppeld aan signal k is het scherm niet interessant, maar toch moet het in een desktop draaien. Het zou mooi zijn als het zonder ui kan.

Ik ken de code niet, maar als je het toch flexibeler maakt, is het een optie om een soort dummy ui of alleen tekst output te hebben?

Dat zou mijn voorkeur ook hebben. Dat zou ook de potentie hebben er een 'blackbox' performance unit van te maken zoals de bekende merken dat ook doen.

ik ken de wens.....

Het probleem is dat er in zo'n live nmea-omgeving van alles mis kan gaan,
Om dat te signaleren zit SPD vol met pop-up windows die dan iets melden en een actie vragen.
Die zitten in tientallen routines.
Dat melden blijft noodzakelijk, want anders zie je niet wat er niet werkt en waarom niet.
En of dat dan een windowtje of een printregel is, het moet ergens heen.....

Het draait natuurlijk wel al als een black box; opstarten en hij gaat.

Het hoofdwindow is per definitie een window op een scherm.
Dat kan ik niet ergens anders heen sturen, het komt als een window....
Wat doet een Pi als je er gewoon geen scherm aan hangt?

En Pi die headless werkt 't zelfde als een server. Je logt in over het netwerk met een terminal over ssh. Typisch heb je voor server-achtige toepassingen geen grafische omgeving nodig.
Als je OpenCPN draait is het natuurlijk wel anders, maar voor bijv SignalK is headless prima.
Kun je een paar voorbeelden geven van berichten en opties/acties?

hanst schreef :
Uit alleen de eerste 500 regels code (van meer dan 6000):

showerror(title = "File closing problem", message = "Some outputfiles could not be closed, may be never openend")

showerror(title = deaderror, message = "Directory not chosen, program stops.")

showerror(title = deaderror, message = "Directory not correctly chosen or no picture background.gif")

showinfo("New Logfile", message="Your new Logfile has been opened!")

showinfo("NMEA processed so far",
message="Total number of NMEA records processed:

showinfo("Files and MSG-Wifi IP in use: ",

showerror(title = deaderror, message = "Filename for Polar file not chosen, program stops."

answer=askquestion(title="Sailing Performance Dashboard: boatspecifics?",message ='read same Boatspecifics file again?')

answer=askquestion(title="Sailing Performance Dashboard: NMEAtemplates?",message ='read NMEAtemplates file again?')

showinfo("STW not possible", message="STW data not present in the input used (replay or live).")

showinfo("STW calibrated", message="STWc corrected based on SOG with "+str(stwcal)+" kts.")

showinfo("STW no longer calibrated", message="STWc corrected based on correction table only.")


En dan dus 10 a 20 keer zoveel...

De messages bij het lezen van een boatspecifics:

showinfo(title="Error in boatfile",message ="Wrong speed source:\nDefaults to SOG now.
showerror(title = "Error in boatfile", message = "Sensor height: "+sensor+"\nshould be a number with decimal dot.")
showerror(title = "Error in boatfile", message = "K value: "+k+"\nshould be a number, integer or with decimal dot.
showerror(title = "Error in boatfile", message = "network protocol invalid: "+NMEA_NETPROT+"\nshould be TCP or UDP."
showerror(title = "Error in boatfile", message = "Error in parameters with: "+comport+"\nCheck parity Y or N"
showerror(title = "Error in boatfile", message = "Error in parameters with: "+comport+"\nCheck bps etc."
showerror(title = "Error in boatfile", message = "Error in parameters with: "+sendcomport+"\nCheck parity Y or N"
showerror(title = "Error in boatfile", message = "Error in parameters with outCOM: "+sendcomport+"\nCheck bps etc.
showerror(title = "Error in boatfile", message = "Error in wind speed correction:
showerror(title = "Error in boatfile", message = "Error in AW filtering:
showerror(title = "Error in boatfile", message = "Error a frequency parameter.\nCheck speech interval, UDP interval, perf filter and general filter."
showerror(title = "Error in boatfile", message = "NMEA types in boatfile invalid selection: "+YN2+"\nshould be all Y or N"

En zo kan ik nog wel een dagje doorgaan

Voor info/error messages is het prima on stdout/stderr te gebruiken in headless mode.
Mocht er iets mis zijn met een instelling tijdens startup mag het ook wel gewoon niet opstarten.
Daarvoor hoeft alleen in de showinfo/showerror een wijziging gemaakt te worden.

Zijn er ook meldingen waar een keuze moet worden gemaakt tijdens het draaien?

Het nadeel van een pi zonder scherm draaien is dat je dan dus de fouten niet meer ziet en het gedrag van SPD niet kan beïnvloeden. En dat is wat je juist wel wil met SPD. Bij een headless setup wil je de output bijvoorbeeld naar stdout/stderror, naar een log of naar bijvoorbeeld een webserver. Geldt ook voor de input die niet vanuit een keyboard komt, maar vanuit een ander programma (bijvoorbeeld webserver of signal k of node red oid).

De meldingen zijn misschien veel, maar lijken niet ingewikkeld. Het aanpassen naar de mogelijkheid om headless te draaien zou daardoor kwa complexiteit wel eens mee kunnen vallen.

Keuzes waarvan vooraf bekend is dat ze gemaakt moeten worden, kunnen of meegegeven worden of in een file geplaatst. Dit geldt bijvoorbeeld voor de files waar mee opgestart wordt zoals boatspecifics ini.
Voor het maken van keuzes tijdens het draaien of het beïnvloeden, van het gedrag (bijvoorbeeld een zeilwissel), heb je een interface nodig.

Als ontwerppatroon zou je op hoofdniveau kunnen bepalen wat je opstart (wel/geen ui) en dan aan de rest van de programmatuur interfaces mee geeft waar de output naar toe moet (stdout/stderr) en waar eventuele input aan meegegeven kan worden die dan verwerkt wordt. Die interfaces koppel je in de huidige versiedan aan de UI. Als je de interfaces doorgeeft, kan iemand anders eventueel de headless versie bouwen en integreren. Aangezien we al een websocket hebben kan je daar voor input en output misschien meer gebruik van maken?

Het lijkt mij ook goed dat los te koppelen. Websockets klinkt als een goede universele manier van het communiceren met de buitenwereld. Voor de info/error/vragen/antwoorden/settings veranderen tijdens het zeilen kunnen dan verschillende interfaces worden gemaakt door wie daar interesse in heeft.
Van ipad tot smartwatch of zelfs fysieke schakelaars voor zeilconfiguraties.

Het is echt veel complexer dan jullie denken

Er zitten vele honderden calls naar de Tk/Tcl GUI in SPD.
Dat gaat van foutmeldingen (showerror), info (showinfo), vragen (askquestion, askfilesave) naar het maken van buttons en het bijhouden van de status daarvan, de kleur veranderen als je erop klikt, enzovoorts enzovoorts.
Ik ga het niet tellen, maar ik schat meer dan 500 calls.
Dan moet bij elk van die honderden calls gekeken worden of er headless gewerkt wordt en dan een keus gemaakt, een tk-call of een print. En dat is dan alleen nog maar voor de output...

Voor de input (knoppen!) moet dan ook iets komen.
SPD draait in een loop die records leest en naar wind en RMC zoekt.
Om die loop heen zit tk/tcl, dat alle interrupts van knoppen afvangt.
Dat moet dan ook helemaal anders.... op een ofandere manier binnen de loop.

En jullie hebben het nog niet varend gebruikt.... dan zal je merken dat je die knoppen echt gaat gebruiken. Een van de vele filters bijstellen, STW calibreren, shifts eerder of later opmerken, andere polar inlezen, nieuwe boatspecifics inlezen, etc.
Zonder knoppen ben je een boel functionaliteit kwijt. Maar dat is dan een keuze....

Dus... ik ga dat niet doen. Het aansluiten van een klein schermpje (desnoods weggestopt in een kastje) is veel simpeler

Wat ik wel ga bekijken:
misschien kan ik in headless mode (dan op te geven in processlist.ini) alle display-calls naar tk/tcl gewoon niet doen.
Dan komt er geen splash-screen, geen window met data, en ook geen knoppen. Helemaal niets.
Als er dan toch een fout opstreedt ((bij opstart of tijdens NMEA ontvangen) wordt die wel gevangen maar hij kan niet getoond worden. De call naar tk die dan optreedt wil iets kwijt in een window (de root) dat er niet is.
Dat geeft dan een stop en een foutmelding in de python-log.

Als je alles prima voor elkaar hebt en alles hebt ingesteld zoals je wilt dan kan je de headless mode (en noquestionasked) aanzetten en komt er alleen de output uit voor het kanaal dat je daarvoor ingesteld hebt (NMEA, webserver, UDP-messages, whatever).
Je kunt alleen niet op knoppen drukken (en dus ook niet netjes stoppen).

Als 't goed hoeven de aanpassingen alleen in de functies gemaakt te worden die je aanroept, zoals showinfo en showerror. Ik neem aan dat voor knoppen etc er ook functies bestaan.

Misschien dat iemand anders wel kan helpen met het werkend maken van websockets.
Is de code toegankelijk in github?

hanst schreef :
Die aangeroepen functies (showinfo etc) zijn black boxes van Tk/tcl.
Daar is niets in aan te passen. Het zijn gecompileerde stukjes C.
Ik kan er niet eens bij....
Knoppen idem. Een knop roept een zelfgemaakte functie aan die bij het definieren van de knop genoemd is ('command = xyz')
Maar het 'luisteren' naar of er een knop is aangeklikt is weer integraal deel van tk/tcl.

Volgens mij zijn we al bijzonder dicht bij een ‘blackbox’ oplossing.
Spd kan gewoon automatisch opgestart worden zonder gebruikers interventie.
Je kan hem hard onderuit halen.
Met de ini files kan je alles gewoon vast instellen.

Wat overblijft is dat het soms toch zinvol kan zijn om eea even te tunen via de UI om dat later vast in te stellen.

En wat is nu de overhead van de UI?

Op een laptop lijkt t me er eigenlijk niet toe te doen.
En op de rpi draait t bij mij in openplotter wat ook gewoon een desktop draait.
Misschien als t straks echt aan boord draait dat t dan net te veel is, maar dan kan ik eerst nog naar een rpi 4 en 64 bit.

Als je naar echt black box wilt, dan zal de UI web based moeten worden. Want een UI is toch nodig, als was t maar om t te testen en ‘in te regelen’.

Zou dat mooi zijn? Ja. Is dat een bak werk om eea architectuur technisch fundamenteel aan te passen? Dat gok ik wel ja.
Zou je wel mooi met de webgui ook de ini’s aan kunnen passen enzo. Dat wel

Jumpinjack schreef :
We zijn er ook vlakbij

Voor het testen en inregelen even een schermpje eraan. En dat eraf als alles naar je zin is.

Dat allemaal (inc files editen) web-based maken is echt heel ingewikkeld. Komt neer op opnieuw beginnen, en dan heb je nog een onbetrouwbaarder geheel dan nu, want er komt een device en een twee-richting verbinding bij. Allemaal narigheid.
Het maken van de huidige webserver (aparte thread met asyncio) was al extreem complex....

De overhead van de UI: niets als je Display Off aanklikt. Scheelt de halve CPU-belasting.

Ik stop mijn tijd liever in verbeteringen van de berekeningen, in meer Smart Warnings, meer analyse van logs dan in technische complicaties die voorkomen kunnen worden door een schermpje aan te stekkeren

Inmiddels bekeken hoe SPD zonder data en knoppen op een scherm te zetten zou kunnen werken.
Dat ziet er niet te ingewikkeld uit.
Maar foutmeldingen etc zullen verloren gaan, en de knoppen ook.
Dus alleen gaan gebruiken als alles lekker is ingeregeld.

Inmiddels maakt Github versie 2.6.4, met daarin zelf instelbare scherm-geometrie. Jaja, er zijn ook mensen die graag wel een scherm hebben

Baasklusje schreef :
Volgens mij is het voor showinfo/showerror vrij gemakkelijk op te lossen:

1. Search/replace showinfo -> _showinfo (in vim: %s/showinfo/_showinfo/g)
2. Functie _showinfo toevoegen:(of met switch/case)

Zelfde voor showerror en askquestion.

De functies voor de knoppen kunnen zo blijven lijkt me omdat die later via websockets ook aangeroepen kunnen worden.


Over ini files:
Ini files aanpassen via websockets/webserver zou ik zeker niet in SPD bouwen. Gewoon los ernaast. Even googlen bracht me hier: github.com/sujeetkv/flaskcode. Een webbased editor. Als 't werkt is het prima.

Dank voor de suggesties.
De tk/tcl show-xxx vervangen door iets eigengemaakts met opties erin had ik ook bedacht,maar dat wat erin moet is 'geen idee hoe' zeg maar

Het zit soms ook 5 aanroepen van routines diep, dus het wordt eindeloos parameters doorgeven....

Ik laat het nog even op mij inwerken

Wat ik al wel gedaan heb:
een black box ervan gemaakt.....

Als in de /systemfiles/ een (lege) file headless.ini aanwezig is dan worden alle calls naar tk/tcl in het hoofdprogramma onderdrukt, en als die file er niet is draait SPD gewoon met scherm en knoppen.
Daarmee (en met noquestionsasked = Y) kun je starten en draaien zonder dat er iets naar een scherm gestuurd wordt.
Geen knoppen. Dus alles in de ini's vooraf instellen.
Als er iets fout loopt gaat tk/tcl proberen een klein windowtje met een melding te maken.
Maar die zie je niet zonder scherm....
Er komen wel foutmeldingen (ruwe python fouten) in de python log.

Nog even wat mee testen, en dan wordt het v 2.7.0

Baasklusje schreef :
Het is makkelijker dan je denkt.
Je maakt een eigen functie die dezelfde functieparameters heeft. Zie hier hoe je met een onbekend aantal opties omgaat: book.pythontips.com/en/latest/args_and_kwargs.html

Die geef je dan door aan tk/tcl als dat de keuze is, of je geeft 't door een andere functie die dan de info bijv op een websocket zet.

Bijv:
Daar maak je voor:
Dan verander je voor de test even 1 tkinter.messagebox.showinfo aanroep in _showinfo en kun je zien of het werkt.

Als 't werkt, search/replace en daarna hoef je alleen nog maar in _showinfo andere outputmechanismes toevoegen.

hanst schreef :
Ja, dat is de makkelijke 1%

De andere 99% zitten in 'daarna hoef je alleen nog maar in _showinfo andere outputmechanismes toevoegen.'

En dan komt er nog 100%, de andere inputmechanismes....

Die 99% voor stdout is natuurlijk nog minder werk:

Stdout werkt dan met 2 a 3 regels.
If (headless): print ("[" + title + "] " + message + " " + options) Dat geeft al veel info op de console die anders onzichtbaar is in headless. Headless is niet het zelfde als blind :)[code]
If (headless):
print ("[" + title + "] " + message + " " + options)

Dat geeft al veel info op de console die anders onzichtbaar is in headless.

Headless is niet het zelfde als blind

hanst schreef :
Bijna wel
Ik ken overigens been black boxen met knopjes....

SPD 2.7.0 (binnenkort) is wel blind maar roept heel hard via de webserver en via UDP-berichtjes en via serial of netwerk. Het logt ook!

Je ziet dat het zonder hoofd nog leeft, zeg maar.

De output-messages zonder tk/tcl-messages is niet het grootste probleem;
een eigen versie van die tk/tcl functies ervoor zetten waarin dan gekozen wordt voor een messagebox of een print is niet moeilijk maar wel heel veel werk (500+ stuks) die dan ook in alle variaties getest moeten worden.

En stuk lastiger wordt om input te geven aan SPD (nu simpel met de tk/tcl buttons) op een andere manier.
Dat is niet alleen input ontvangen; dat moet ook onafhankelijk zijn van de loop in SPD.
Als SPD zijn records staat te verwerken kijkt het niet of er iemand op een knopje gedrukt heeft.
Dat doet tk/tcl, volledig zelfstandig en asynchroon en parallel aan SPD.
Dat moet dan allemaal zelf gemaakt worden.... en jij en ik hebben geen idee hoe dat moet

De H5000 van B&G heeft een webinterface ipv een eigen display. Dat is dus headless met de mogelijkheid van knopjes in de webinterface.

Niet alle 500+ functies hoeven getest te worden. Dat is immer precies de functie van een functie: dat je op 1 plek bepaalde logica onderbrengt en dat zorgeloos kunt aanroepen. Ook 500 keer.

tk/tcl is geen magic. En meerdere dingen in parallel doet is precies waar threading voor is uitgevonden. Dus een thread die luistert naar web events en dan via een mapping de functies aanroept.
En het hoeft allemaal niet in 1x te werken. Babysteps etc.

Het hoeft allemaal ook niet zelf gemaakt te worden, maar bijdragen in code is lastig zolang we er niet bij kunnen. Ik heb het denk ik gemist, maar is er een reden dat we niet gewoon naar de code kunnen kijken?

Die 500+ calls naar tk/tcl zitten verspreid over de 105 modules waar SPD uit bestaat.
Die moeten dan allemaal gewijzigd worden, met kans op foutjes, en dus getest....

Threading zit erin voor de webserver, die draait in een eigen thread.

Maar laten we klein beginnen Baby-steps.
Dit is de definitie van de stop-knop. Deze code werkt, getest !

Dan verschijnt de stop-knop op je scherm.
En dan maakt jij iets waarmee je die knop met een webinterface kan bedienen

De code hou ik nog even voor mezelf, want ik zit niet op werk te wachten, zeg maar.
Openbaar maken gaat vast leiden tot enorm veel voorstellen voor veranderingen.
Zie ook ons gesprek hierover, al zonder openbaarheid.
SPD is zeker veel uitgebreider en beter geworden door alle opmerkingen, dat staat vast.
Dus dat kan ook zonder openbare code

Ben benieuwd naar je web-bediening uit een aparte thread van die Stop-knop!

Zullen we dit in een apart draadje gaan doen?
Is wat technisch voor de gemiddelde gebruiker....

@hanst
De h5000 heeft ook nog wat instel en calibratie mogelijkheden via n2k en een zeus

Gepost met de officiële Zeilersforum-app

Nieuw draadje is prima. Ik heb nog nooit multi threaded in pyhton gedaan, maar met wat googlen is het werkend:
pastebin.com/raw/7vTvk1kw

telnet localhost 33000

Dan kun je 'quit', 'button1', 'button2' doen en dat afvangen en verschillende dingen starten. Het zijn geen websockets, maar gewoon tcp.