SDK 6.7 / UZB1/Razberry-Firmwares > 5.07

[krikan]

Kann man die Bootloader-Version irgendwo rauslesen?

Mir ist nichts bekannt.

Andererseits gibt es bei mir auch mit 5.22 einen Unterschied:

Merkwürdig. Hatte kein einziges Mal unterschiedliche Werte.

Aktualisierung zu Firmware über 5.22 war meiner Erinnerung nach speziell: Angeboten wurden mir nur 5.22, aber aus der textlichen Erlaeuterung in z-way neben der angezeigten 5.22 ergab sich, dass es 5.23 oder höher war. Nach den diversen Updates ist mein UZB1 jetzt auf 5.27. Changelog habe ich immer noch nicht gefunden.

[krikan]

0013 - ACK - Antworten sind deutlich laenger:

SDK 6.7 - Beispiel

Code Auswählen Erweitern

2017.11.20 20:01:33.083 4: ZWDongle_Read ZWDongle_0: rcvd 00134700000702b57f7f7f7f000003271e000003010000 (request ZW_SEND_DATA), sending ACK
2017.11.20 20:01:33.083 5: SW: 06
2017.11.20 20:01:33.085 5: device ack reveived, removing 01090013130226022547b2 from dongle sendstack
2017.11.20 20:01:33.086 5: ZWDongle_0: dispatch 00134700000702b57f7f7f7f000003271e000003010000
2017.11.20 20:01:33.086 4: CMD:ZW_SEND_DATA ID:00 ARG:000702b57f7f7f7f000003271e000003010000 CB:47

SDK 6.5 - Beispiel

Code Auswählen Erweitern

2017.11.20 19:26:55.063 4: ZWDongle_Read ZWDongle_0: rcvd 001339000003 (request ZW_SEND_DATA), sending ACK
2017.11.20 19:26:55.063 5: SW: 06
2017.11.20 19:26:55.064 5: device ack reveived, removing 010a001323032501002539fe from dongle sendstack
2017.11.20 19:26:55.065 5: ZWDongle_0: dispatch 001339000003
2017.11.20 19:26:55.066 4: CMD:ZW_SEND_DATA ID:00 ARG:0003 CB:39

ARG-Laenge ist im jeweiligen SDK bei CMD:ZW_SEND_DATA ID:00 anscheinend immer gleich. Bedeutung: ?

Erklärungen zu den letzten beiden Bytes in den 0013 ACK-Antworten in SDK 6.51 ff. (suche nach INS12712 in Suchmaschine) -> Telegrammlaufzeit von ZW_SENDDATA bis Callback in 10ms-> stichprobenartiger Vergleich mit "unserem" Internal timeToAck bestätigt das.

Erklärungen zu den (noch) längeren 0013 ACK -Antworten ab SDK 6.6 finden sich in dem PDF aus https://forum.fhem.de/index.php/topic,88585.msg821571.html#msg821571 unter "SerialAPI targets supporting IMA"
-> Analysedaten zur Funkkommunikation

[krikan]

Habe in meinem FHEM die Auswertung der 0013-Antworten ab SDK 6.6 mit anhängendem Patch-Entwurf eingebaut und testweise laufen lassen.

Persönlich finde ich das hilfreich/spannend, aber da es bei ZW_SENDATA jedesmal durchlaufen wird, ist das evtl. ein überflüssiger Zeitfresser!?
Falls man das einbaut, dann per Attribut steuerbar und/oder ausgelagert in separater sub?

Rudi, bräuchte erst einmal nur Hinweise/Anmerkungen. Falls es einbaut werden kann/soll, würde ich vorher noch an dem Code arbeiten. Mir fehlen auch noch ein paar Ideen zur Interpretation der Rückgabewerte (scheme, lastFailed,..).

[rudolfkoenig]

Meine Bemerkungen:
- die Pruefung auf die Laenge (38) kommt mir komisch vor, ich habe die Spec aber nicht gelesen.
- bitte das Ganze in eine Funktion auslagern
- verstehe ich richtig: die Erweiterung erstellt ein routeInfo Reading, dein Screenshot zeigt dieses Reading fuer mehrere Geraete- ich fuerchte wir brauchen auch eine Beschreibung des Inhalts, sonst muss man doch die Spec studieren, bevor man was versteht.


Sonst ist das sicher sinnvoll zum Debuggen von Verbindungsproblemen, und kann u.U. ein ZWCUL ersparen.Waere auch ein Vergleich mit neighborList interessant.

[krikan]

- die Pruefung auf die Laenge (38) kommt mir komisch vor, ich habe die Spec aber nicht gelesen.

Nach meiner bisherigen Beobachtung ist die Laenge in SDK 6.5 = 4 und ab SDK 6.6 = 38; Abweichungen hatte ich nicht.
Angesichts der typischen Abwaertskompatibilitaet koennte man die Laengenprüfung weglassen und nur die zurückgelieferten Bytes interpretieren. Überlege ich noch.

- verstehe ich richtig: die Erweiterung erstellt ein routeInfo Reading, dein Screenshot zeigt dieses Reading fuer mehrere Geraete- ich fuerchte wir brauchen auch eine Beschreibung des Inhalts, sonst muss man doch die Spec studieren, bevor man was versteht.

Ja, Reading routeInfo wird erstellt. Screenshot zeigt einen Ausschnitt aus einer readingsGroup mit routeInfo von diversen ZWave-Devices.
In  http://zwavepublic.com/sites/default/files/command_class_specs_2017A/SDS13784-5%20Z-Wave%20Network-Protocol%20Command%20Class%20Specification.pdf unter "4.11.3.3.2 Transmission Time (4 bytes)" und in den folgenden Abschnitten werden die Rückgabewerte erlaeutert. Kürzer kann ich es fast nicht erlaeutern, überlege aber mal wie man das anders zusammenfassen kann.

Interpretation der Readings routeInfo überlasse ich jedem selbst. Die Umsetzung und Verdichtung der Werte nach einem in den Specs erlaeuterten Test- und Rechenverfahren in Routenqualitaetsinfos mit Ampelsymbolen/farben für die einzelnen Nodes gefaellt mir persönlich nicht.