SDK 6.7 / UZB1/Razberry-Firmwares > 5.07

Begonnen von krikan, 20 November 2017, 20:54:33

Vorheriges Thema - Nächstes Thema

krikan

Fortsetzung/Ausgliederung aus https://forum.fhem.de/index.php/topic,79659.0.html zum Thema neues SDK 6.7 (UZB1/Razberry-Firmware > 5.07)

Changelog zu den neuen Firmwares bisher nicht bekannt.

Bisheriges:

"APPLICATION_COMMAND_HANDLER ID:" Nachrichten sind 2 Bytes laenger.
https://forum.fhem.de/index.php/topic,79659.msg717511.html#msg717511:
ZitatIn dem letzten Log sind die zwei Bytes fuer "APPLICATION_COMMAND_HANDLER ID:05" 25-mal 7e00 und einmal dd00. Bei den anderen Nachrichten bin ich unsicher, ob was zusaetzlich angehaengt ist, oder nicht. Es waere toll, wenn wir wuessten, was diese zwei Bytes sind, und wie man sie bestellt bzw. abbestellt.

Theorie zu den Bytes:
https://forum.fhem.de/index.php/topic,79659.msg718293.html#msg718293:
ZitatDas 1. Byte gibt vermutlich Infos zu den Empfangseigenschaften an.
Es bleibt (relativ) gleich, wenn man die Position zwischen Controller und ZWave-Gerät nicht verändert.
Folgende Werte des Bytes ergaben sich beispielsweise, wenn ich die Entfernung zwischen Controller und Gen5-Gerät schrittweise erhöht habe:
0x7e ; 0xA5 ; 0xAE ; 0xC9 ; 0xD5
Bei einem Gen3-Gerät steigen diese Werte schneller; würde zu schlechteren Funkeigenschaften passen.

Das 2. Byte ist in meinen Experimenten bisher immer 0x00.

krikan

0013 - ACK - Antworten sind deutlich laenger:

SDK 6.7 - Beispiel
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
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: ?

krikan

Mini-Patch mit Namen von SDK 6.7(?) Funktionen

rudolfkoenig


krikan

#4
Anhaengend Patch, der die backgroundRSSI-Funktion in ZWDongle einbaut. Beim Code bin ich besonders bei substr unsicher. Wenn der so übernommen wird, bitte noch einmal gegenchecken, ob bei Aufrufen von substr mit OFFSET und LENGTH außerhalb des Strings $msg wirklich immer "" = 0 zurückgegeben wird (Channel3 wird derzeit nie gemeldet, wodurch dieser Fall immer zutrifft.). Hiernach https://perldoc.perl.org/functions/substr.html verstehe ich das so und Windows-Strawberry-Perl schluckt die Aufrufe ohne Warnung und Funktionsprobleme.

Infos stammen aus http://zwavepublic.com/sites/default/files/command_class_specs_2017A/SDS13784-4%20Z-Wave%20Network-Protocol%20Command%20Class%20Specification.pdf unter "4.4.13.1.1 RSSI Get Command"
Hinweise zur Interpretation der Werte in https://github.com/Z-Wave-Me/Z-Way-Manual/raw/3.0/ZWayManual.pdf unter "8.1 RadioLayer"

Könnte man mit regelmaeßigem Aufruf dieser Funktion nicht erkennen, ob die Funkkommunikation durch externe Störungen verhindert wird? Quasi eine Art Manipulatonsschutz?

Anhand der Skala für die RSSI-Werte sehe ich die RSSI-Theorie zum 1.  durch das SDK 6.7 angehaengten Byte (siehe #1) erst einmal gestaerkt.

edit: Versuch substr-Problem(?) besser zu erklären.

rudolfkoenig

#5
Habs eingecheckt.

ZitatBeim Code bin ich besonders bei substr unsicher.
Habe den Code leicht angepasst in:
    my $maxlen = (length($msg) >= 10 ? 10 : length($msg));
    for(my $off=4; $off<$maxlen; $off+=2) {

aber bitte testen.

Apropos testen: ich kann mein Stick nicht updaten, weder unter OSX, noch unter Linux, mit keinem der beiden Firmwaredateien. Ergebnis ist immer identisch: timeout. Mit FHEM funktioniert das Ding aber prima, sowohl vor, als auch nach dem Versuch. Faellt jemandem was offensichtlich Falsches auf?
Zitat% python ZStickUpdater.py -d /dev/cu.usbmodemfa141 -f ../Z-Stick5.ehex
2017-11-23 22:34:57,663 Serial.INFO     Open serial port /dev/cu.usbmodemfa141
2017-11-23 22:34:57,696 Serial.INFO     Putting stick into reflash mode
2017-11-23 22:34:57,798 Serial.INFO     Got Ack. Z-Stick is now in reflash mode (if supported)
2017-11-23 22:34:57,798 Serial.INFO     Waiting for relaxation
2017-11-23 22:35:01,302 Serial.ERROR    Operation timeout on page 127
2017-11-23 22:35:01,807 Serial.ERROR    Operation timeout on page 127
2017-11-23 22:35:02,312 Serial.ERROR    Operation timeout on page 127

Eidt: Code-Anpassung angepasst

krikan

Zitat von: rudolfkoenig am 23 November 2017, 22:44:53
Apropos testen: ich kann mein Stick nicht updaten, weder unter OSX, noch unter Linux, mit keinem der beiden Firmwaredateien. Ergebnis ist immer identisch: timeout. Mit FHEM funktioniert das Ding aber prima, sowohl vor, als auch nach dem Versuch. Faellt jemandem was offensichtlich Falsches auf?
Das Log zeigt afaik einen Firmwareupdateversuch des UZB1 mit einer Firmware für den Vorgaenger-Stick Z-Stick.
Die UZB1-Firmware wird über z-way aktulisiert: http://razberry.z-wave.me/index.php?id=32
z-way-Installations-Hinweise unter http://razberry.z-wave.me/index.php?id=24 und Download unter http://razberry.z-wave.me/z-way-server/

krikan

if($dec == 127 || $dec == 0)
kann jetzt abgeaendert werden in:
if($dec == 127)
$dec==0 fing in meiner Version etws unsauber den leeren ch3 (Rückgabe substr="") als Sonderfall ab. Eigentlich ist 0 auch "reservedValue".

Ob es sinnvoller ist, ch3 -wie in Deiner Fassung- nur bei Werten anzugeben oder -wie bei mir- immer, bin ich unentschieden.

Ansonsten: Funktioniert.  :)

rudolfkoenig


rudolfkoenig

ZitatDie UZB1-Firmware wird über z-way aktulisiert:
Ich habe unter "http://linuxvm:8083/expert/#/uzb" ein "Angebot", Bootloader und Firmware zu aktualisieren, habe beides gemacht (bootloader von 5.01 auf 34A9, firmware von 5.01 auf 5.02), beides hat 'ne Weile gedauert, jede menge Output in der Konsole produziert, und zum Schluss ein reset des Sticks gemacht. Aber danach scheint es immer noch 5.01 zu sein, jedenfalls behauptet das FHEM, und unter dem Link kann ich wieder von 5.01 auf 5.02 aktualisieren. z-way will mich aergern. Oder ich stelle mich doof an, auch nicht ausgeschlossen :)

krikan

Schwierigkeiten habe ich teilweise auch und muss Updates mehrfach anstoßen.
Mir hat (gefühlt) geholfen:
z-way erst beenden, wenn im z-way expert-UI unter ControllerInfo die neue Firmwareversion angezeigt wird. Im z-way-server.log kann man den Ablauf auch nachvollziehen.



throbin

Hi,

es kann auch sein, dass die GUI hängt, d.h. es gibt kein Feedback, ob das Update erfolgreich war oder nicht etc. Ich hatte das Problem sowohl nach dem Bootloader Update als auch bei der FW. Ich habe, nachdem der Stick aufhörte zu leuchten ein Paar Minuten (ca. 2) gewartet und danach den Pi neu gestartet, danach war das Update "anscheinend" installiert. Unter Windows gab es auch die Möglichkeit die Updates auszuführen... Die Software ist alles andere als stabil oder "logisch".

Bei mir zeigt es als FW 5.22 an (hatte vorher die 5.06).

Nach dem Update war alles wieder da (also alle Devices etc.), nur die Routen sind verloren gegangen. Nach dem "set neighbor update", läuft wieder alles flott.

Gruß
throbin

rudolfkoenig

ZitatSchwierigkeiten habe ich teilweise auch und muss Updates mehrfach anstoßen.
Das scheint zu stimmen, jetzt habe ich es auch geschafft. 5.01 -> 5.02 -> 5.06 -> Firmware Update -> 5.22. Die ersten beiden Schritte haben 3 Versuche benoetigt, die letzten zwei jeweils einen.
Und danke fuer die Links. Der Noise-Gauge aus Kapitel 8.1 erinnert mich an mein "Report raw RSSI data" in culfw (X, Bit 7).

krikan

Zitat von: rudolfkoenig am 03 Dezember 2017, 20:42:50
Das scheint zu stimmen, jetzt habe ich es auch geschafft. 5.01 -> 5.02 -> 5.06 -> Firmware Update -> 5.22.
Die 5.22 hat bei mir auf den channels den gleichen "background noise" gemeldet. Erst nach einem Update auf 5.23 und höher gab es Unterschiede zwischen den channels, was ich für plausibler halte.

rudolfkoenig

Und ich dachte, ich haette dich ueberholt :)

Bei mir wird jetzt nur ein Bootloader Upgrade angeboten (5.22 auf 40196), und ich habe keine Ahnung, ob es gelingt, da es ja immer wieder angeboten wird, auch wenn im Log nur was von Success steht. Ich habe es jetzt 5-mal durchgefuehrt, das reicht :) Kann man die Bootloader-Version irgendwo rauslesen?
Andererseits gibt es bei mir auch mit 5.22 einen Unterschied:
Zitatzwd backgroundRSSI => ch1:-89 dBm ch2:-94 dBm