Highlights {#highlights}
Änderungen an den Geräteeinstellungen werden nun synchron an alle Client-Sitzungen übertragen, die dieses Gerät nutzen, und nicht mehr nur an diejenige, von der aus die Änderung vorgenommen wurde.Der zweite Client führt keine Abfrage mehr durch, sondern nutzt stattdessen seine eigene In dieser Sitzung aktualisiert Ereignisaktualisierung – Jede Sitzung, die dieses Gerät nutzt, erhält genau ein Ereignis; der Absender erhält auf keinen Fall zwei.
Nun kann der tatsächliche Installationsort des Geräts an den Client gemeldet werden, anstatt stets die in der Sitzung konfigurierte Installationsart zu übermitteln.Die Beschriftung, die angibt, um welche Art von Einbaulage es sich gerade handelt, ist nun konstruktiv so gestaltet, dass ihre Richtigkeit gewährleistet ist, und gilt für alle Ausgabeformate.
Wenn das Gerät die Referenzwerte selbstständig aktualisiert, passt der Server diese Änderungen an. Zuvor gab der Server die beim Start des Geräts erfassten Werte zurück, die danach nie erneut überprüft wurden.Nun kann der Server diesen Referenzwert je nach dem Rendering-Rhythmus des Clients bedarfsgerecht aktualisieren und dabei auf Serverseite eine Ratenbegrenzung vornehmen, um zu verhindern, dass Clients mit hoher Aktualisierungsfrequenz die Geräteverbindung überlasten, und Änderungen erst dann melden, wenn tatsächlich eine Drehung in der Einbaurichtung stattgefunden hat.
Interne Verbesserungen {#internal-improvements}
Experimentelle automatische Korrektur der Gierdrift des Griffs. Das neu hinzugefügte Servicemodul bietet eine Closed-Loop-Korrektur für die Trägheits-Yaw-Drift des Wireless VerseGrip: Es gleicht den absoluten Yaw-Winkel des Griffs mit der Bewegung des daran befestigten, gekoppelten „ Inverse3 “ oder „Minverse“ ab; sobald eine Reihe von Qualitätsschwellenwerten vollständig erfüllt ist, wird ein Korrekturwert in die Firmware des Griffs geschrieben. Diese Funktionist standardmäßig deaktiviert und nur verfügbar, wenn der Schalter für den experimentellen Modus aktiviert ist. Sie verfügt über einen Laufzeitschalter,der, sobald er umgeschaltet wird, alle online befindlichen Griffe dazu zwingt, diese Funktion sofort zu deaktivieren – was für Funktionen, die in die Geräte-Firmware schreiben, unerlässlich ist.Das Schreiben von Konfigurationen für alle Geräte erfolgt nun nach dem „Alles-oder-nichts“-Prinzip. Bevor Änderungen an einem Gerät vorgenommen werden, überprüft das System zunächst die gesamte Auswahl (einschließlich der Firmware-Fähigkeiten und des Betriebszustands der Geräte). Daher verbleibt eine Gruppe von Geräten mit unterschiedlichen Firmware-Versionen nicht mehr in einem halbfertigen Umstellungszustand, wenn beim zweiten Gerät ein Fehler auftritt.Die Bestätigungssignale der Handle-Firmware werden nun für jede Anfrage separat nachverfolgt. Zuvor teilten sich alle Anfragen einen gemeinsamen Ergebnis-Slot, sodass zwei parallel laufende Aufrufer möglicherweise die Antworten des jeweils anderen überschrieben; derselbe mehrdeutige Wert stand gleichzeitig für „abgelehnt“ und „noch kein Ergebnis“,was dazu führen konnte, dass eine Ablehnung fälschlicherweise als Wiederholungsversuch interpretiert wurde und somit eine Wiederholungssturm auslöste. Nun ist jede Anfrage mit einem eigenen Token versehen; nie tatsächlich gesendete Anfragen hinterlassen keine Spuren, und verlorene Antworten werden als fehlgeschlagen markiert, anstatt einen Stillstand zu verursachen. Der Cleanup-Prozess, der dies durchführt, verursacht keinen Overhead, wenn keine ausstehenden Anfragen vorhanden sind.Die Kalibrierung der Inkwell-Dockingstation wird von der neuen Funktionsprüfung der Griff-Firmware nicht beeinflusst. Beim Einsetzen des Stifts in die Dockingstation wird eine vollständige Neukalibrierung der Lage durchgeführt; dies gilt für alle ausgelieferten Stifte, unabhängig von der Firmware-Version. Dieser Ablauf ist ausdrücklich von der für die berechnete Kurskorrektur eingeführten Mindestanforderung ausgenommen, wobei die Ausnahmebedingung an der Aufrufstelle ausdrücklich angegeben ist und nicht abgeleitet werden muss.Korrekturen {#fixes}
Durch das Zurücksetzen der Schwerkraftkompensation werden nun die tatsächlichen Standardwerte wiederhergestellt, anstatt eine übermäßige Kompensation vorzunehmen. Trotz dieses Namens,config/Schwerkraftkompensation auf Skalierungsfaktor Das Feld ist kein Multiplikator: Es handelt sich um die Masse der Endantriebslast (in Kilogramm), die das Gerät zusätzlich zu seinem Eigengewicht ausgleicht. Bei der vorherigen Zurücksetzung wurde diese Bezeichnung wörtlich genommen und der Wert auf den „neutralen“ Koeffizienten zurückgesetzt. 1——das heißt, eine fiktive Last von einem Kilogramm——daher drückt das Gerät nach dem Zurücksetzen den Hebel nach oben, was jedoch nicht dem Verhalten eines neu angeschlossenen Geräts entspricht. Durch das Zurücksetzen werden nun die tatsächlichen Standardwerte wiederhergestellt: Die Kompensation ist aktiviert, und Skalierungsfaktor für 0… bedeutet, dass das Gerät nur sein Eigengewicht trägt und keine Last angenommen wird. Falls Sie in Ihrer Anwendung bisher die Kompensationsstärke durch Zurücksetzen erhöht haben, sollten Sie stattdessen den gewünschten Wert explizit festlegen.Die Funktion „Zurücksetzen“ schaltet das Gerät nun tatsächlich wieder ein. Zuvor, in Bezug auf config/home_return Durch das Zurücksetzen wird die Rückstellfunktion deaktiviert, dem Aufrufer wird jedoch mitgeteilt, dass diese Funktion aktiviert ist. Jetzt werden durch das Zurücksetzen tatsächlich die Werkseinstellungen (aktiviert) wiederhergestellt, und der Wert, den die Anwendung anschließend ausliest, entspricht dem tatsächlich vom Gerät verwendeten Wert.Das Schreiben von geräteweiten Einstellungs- oder Ausrichtungsdaten führt nicht mehr dazu, dass die Daten anderer Clients veraltet sind. Vor Version 3.5.6 wurde beim Schreiben auf das Gerät selbst (das von allen Sitzungen, die dieses Gerät nutzen, gemeinsam genutzt wird) lediglich die Konfiguration des Clients aktualisiert, der den Schreibvorgang initiiert hatte, während geräteweite Routen für niemanden aktualisiert wurden. Andere Clients auf demselben Gerät zeigten weiterhin die alten Werte an, bis sie aktiv eine Abfrage durchführten. Jetzt erhalten alle Sitzungen, die dieses Gerät nutzen, eine Benachrichtigung.Wiederholte Andockversuche des Inkwell-Sockels werden nach einer einzigen Ablehnung nicht mehr abgebrochen. Der Status des vorherigen Andockversuchs bleibt zwischen mehreren Andockversuchen erhalten, sodass der zweite Andockversuch die erste Ablehnung als Ende des Wiederholungsfensters betrachtet. Nun wird das Wiederholungsfenster bei jedem Andockversuch zurückgesetzt.Ein Datenkonflikt im Tick-Zyklus des Wireless VerseGrip-Geräts wurde behoben. Die Gerätekennung wurde möglicherweise im Verbindungsthread neu zugewiesen, während gleichzeitig ein Zwischenpfad diese Kennung unter Verwendung einer anderen Sperre auslas. Nun wird unter dem richtigen Sperrschutz ein einheitlicher Snapshot dieser Kennung erstellt, und jeder darunterliegende Pfad (einschließlich Ablehnungsfälle) arbeitet auf der Grundlage dieser Kopie.Ein Problem mit nicht synchronisierten Nachrichtenpuffern auf vier Wireless VerseGrip-Sendern wurde behoben. Bei diesen vier ausgehenden Nachrichtenpfaden wurde beim Zusammenstellen der Nutzdaten und der Prüfsumme sowie bei der Anforderung zum Versand keine Schreibsperre erworben, sodass es bei zwei Sendern zu einer Überlappung im gemeinsam genutzten Puffer kommen konnte.Mögliche Änderungen mit Kompatibilitätsproblemen {#potential-breaking-changes}
Es gibt keine Änderungen an der API, den Kommunikationsprotokollen oder den Einstellungen. Die Standardausgabe stimmt Byte für Byte mit Version 3.5.5 überein; es wurden keine Routing-Pfade entfernt oder geändert, die öffentliche C-API weist keine Unterschiede auf, und es wurden keine Einstellungsschlüssel umbenannt, entfernt oder mit neuen Standardwerten versehen. Anwendungen, bei denen die SDK-Vorschau oder experimentelle Schnittstellen aktiviertsind, müssendie Migration in diesem Zyklus abschließen. Dies umfasst eine Änderung auf Schalterebene sowie eine Reihe entfernter Token-Sätze; jeder Schritt ist im zugehörigen Update-Protokoll des Projekts dokumentiert.Der von der Schwerkraftkompensation zurückgegebenen Wert unterscheidet sich von dem in 3.5.5. Es haben sich keine Felder, Routen oder Antwortstrukturen geändert, doch das Zurücksetzen der Abhängigkeiten wird Skalierungsfaktor geschrieben als 1 Bei der Anwendung werden nun die werkseitigen Standardwerte übernommen. 0——Die Kompensationsfunktion bleibt in jedem Fall aktiviert. Bitte legen Sie diesen Wert explizit fest, anstatt sich auf das Zurücksetzen zu verlassen; siehe die oben stehenden Anweisungen zur Fehlerbehebung.Nach dem Zurücksetzen bleibt die Rücksetzfunktion nun aktiviert und wird nicht deaktiviert. Es haben sich keine Änderungen an Feldern, Routen oder Antwortstrukturen ergeben, aber Anwendungen, die auf das Zurücksetzen angewiesen sind, umdie Rücksetzfunktion zu deaktivieren, stellen nun fest, dass diese Funktion aktiviert ist. Um sie zu deaktivieren, setzen Sie sie nach dem Zurücksetzen bitte explizit auf „Aus“; siehe die oben stehenden Hinweise zur Behebung des Problems.Der Client erhält zusätzliche Konfigurationsereignisse. Ursprünglich wurde angenommen, dass In dieser Sitzung aktualisiert Anwendungen, die das Ereignis bisher nur aufgrund der eigenen Eintragung erhielten, erhalten es nun auch, wenn ein anderer Client das gemeinsam genutzte Gerät wechselt; anschließend erhalten sie zudem eine vollständige Konfigurationsdarstellung. Dies ist das erwartete Ergebnis des oben beschriebenen Fan-out-Mechanismus; Clients, die die Daten erst nach Eintreffen des Ereignisses neu einlesen, müssen keine Änderungen vornehmen.
