Callbacks gehen verloren beim Disconnect von anderem Host

[remotecontrol]

Hallo,

 

wenn ich zwei Hosts gegen einen Stack connecte, so bekommt der 1. Host einen erneuten enumeration Callback, wenn sich der 2. connected (-> OK). Der 1. Host muss dann die Callbacks neu registrieren (-> OK).

 

Disconnected sich nun der 2. Host, so bekommt der 1. Host aber keinen enumeration Callback mehr und alle Bricklet-Callback sind dennoch weg.

 

Oder habe ich was übersehen?

Wie kann ich mitbekommen, wenn sich der 2. Host disconnected und der 1. seine Callbacks neu registrieren muss?

 

[AuronX]

Mir war ehrlich gesagt neu, dass irgendwelche Callbacks ausgeschaltet werden, wenn sich ein Host disconnected...

[remotecontrol]

Ist mir bisher auch nicht aufgefallen.

 

Ich versuche aber gerade, meine Anwendung gegen Ausfälle und externe Connects zu stabilisieren und dabei ist mir aufgefallen, dass ich nicht mitbekomme, wenn sich z.B. der brickv disconnected. Danach sind aber "fast" alle Callbacks weg:

 

- von den Sensoren (temp, baro, ambi, humi) kommt nichts mehr

  (hier hatte ich 5 Sekunden Callback-Period eingestellt)

- die Buttons des LCDs senden aber noch Callbacks

[borg]

Der Brickv setzt wenn du ihn schließt alle Callbacks die er selbst aktiviert wieder auf Default zurück. Das ist aber kein Standardverhalten der Firmware oder sowas, das macht der aktiv.

[remotecontrol]

Das bedeutet aber, dass eine 2. Anwendung die Callbacks der 1. ebenfalls löscht, ohne dass die 1. das mitbekommt.

 

Ist für mich erstmal kein Problem, da es wohl eher die Ausnahme ist, dass sich eine 2. Anwendung connected.

 

In meinem Fall prüfe ich nun ob x Sekunden kein einziger Sensor-Callback erfolgt ist, wenn ja starte ich den Enumerate neu und registriere damit die Callbacks neu.

[AuronX]

In diesem Bereich sind aber viele weitere Probleme denkbar:

- Period wird nur angepasst (statt alle 50ms nur alle 5s)

- Threshold wird angepasst

- irgendwelche anderen Settings werden überschrieben

 

Am Ende muss man einfach festhalten, dass keine zwei beliebigen Anwendungen auf den gleichen Stack zugreifen dürfen. Wenn beide Anwendungen von dir stammen, dann kannst du natürlich Spielregeln einhalten durch die das trotzdem funktioniert... (etwa: Einheitliche Periods, kein Abschalten bei Schließen der Anwendung usw.)

[Loetkolben]

Hallo zusammen.

 

Nur mal eine (Design) Frage:

Kann man nicht feststellen, dass ein Callback gesetzt wurde und dementsprechend handeln? Also sollte die zweite Anwendung nichts tun oder vorher eine Warnung ausgeben.

 

Waehre das nicht eine Notwendigkeit fuer den Brickviewer?

 

Der Loetkolben

[AuronX]

Ich gebe dir recht Loeti.

Wenn zum Start des Brickv schon ein Callback aktiv war, dann sollte er zumindest am Ende nicht deaktiviert werden.

 

Vorsichtiger kann man aber leider nicht mehr sein. Beim Beenden beispielsweise den Wert vom Start wiederherzustellen ist beispielsweise auch nicht für Anwendungen geeignet, die zwischendurch Änderungen am jeweiligen Wert vornehmen.

 

Deswegen sollte grundsätzlich klar sein, dass zwei Anwendungen aktiv aufeinander abgestimmt werden müssen, damit sie sich parallel verbinden können.

[Loetkolben]

Deswegen sollte grundsätzlich klar sein, dass zwei Anwendungen aktiv aufeinander abgestimmt werden müssen, damit sie sich parallel verbinden können.

 

Jep und in diesem Fall wird dem Brickviewer eben eine besondere Stellung zu teil. Zum einen ist er notwendig um mal etwas zu kontrollieren oder an einem Bricklet etwas einzustellen und zum anderen ist die Anwendung nicht von einem selbst geschrieben.

 

Wenn Tinkerforge da etwas aendern moechte/sollte/wuerde dann ist das wohl leider nicht in 10 Minuten gemacht.

 

Der Loetkolben

[The_Real_Black]

Der Brickv setzt wenn du ihn schließt alle Callbacks die er selbst aktiviert wieder auf Default zurück. Das ist aber kein Standardverhalten der Firmware oder sowas, das macht der aktiv.

Dass erklärt so manchen Bug... kann man dieses Verhalten ausschaltbar machen?

[borg]

kann man dieses Verhalten ausschaltbar machen?

Ob wir die Callbacks jetzt am Ende wieder ausschalten oder nicht ändert ja nichts daran das Brickv an den Einstellungen rumstellt. Entweder Brickv zeigt Daten an und stellt auch entsprechend dafür alles ein oder Brickv zeigt keine Daten an.

 

Man könnte höchstens Brickv so umstricken, das nur noch getter verwendet werden. Das ist aber bei Sachen die reaktionsschnell seien sollen (IO-4/16, Ind. Digital In etc) blöd, da man dadurch Lag reinbekommt.

[remotecontrol]

Ich finde das Verhalten vom brickv OK.

 

Ich frage mich aber dennoch ob es prinzipiell überhaupt möglich wäre, einen Event zu verteilen, wenn durch eine andere Anwendung callbacks gelöscht werden. Das geht dann doch in Richtung Firmware.

 

Für den normalen Betrieb ist das eher ein Sonderfall, da nicht zwei Anwendungen gegen einen Stack arbeiten sollten.

 

Aber das "mal eben den Detailstatus auslesen" z. B. über brickv ist doch nicht so selten. Dann wäre es gut, wenn die Anwendung solche Fälle erkennen kann.

[Loetkolben]

Ich versuche es mal so:

 

* Einmal mit dem Brickviewer auf den Stack geclickt und ein produktives System ist "im Eimer". ?!

 

* Ich kann mir auch gut vorstellen, dass man mehrere Bricklets hat, wobei ein Bricklet produktiv/testhalber Callbacks sendet und man mit einer anderen Software/Brickviewer an den anderen Bricklets arbeitet. Um es einfach zu machen sollte man die Brickletcallbacks pro Bricklet im Brickviewer enablen/disablen koennen. ...

 

Hier kommt mir die Frage nach dem Zugriff von aussen wieder in den Sinn!  ;D

 

Der Loetkolben

[AuronX]

Ich denke einen "non-intrusive-mode" im Brick-Viewer kann man schon gebrauchen. Eben mit Hinweis, dass das nicht so hochwertige Daten sind (gerade was kurzfristige Änderungen auf den IO-Bricklets betrifft).