Z-Wave.Me Zwischenstecker Schalter IP20 Z-Wave ZME_064374

Begonnen von waver, 30 August 2015, 13:11:32

Vorheriges Thema - Nächstes Thema

krikan

Zitat von: waver am 30 August 2015, 19:24:04
Ich vermute mal, der Popp und dieser ZME_064374 dürften ziemlich ähnlich sein, oder?
Vermutung unterstütze ich wegen Optik und Erfahrungen aus der Vergangenheit. Das ist aber kein Wissen.
Das die Klassen im Handbuch stehen hatte ich auch gesehen. Aber ich finde es immer alles noch mehr als merkwürdig.
SDK 4.5 ist aus 2009
SDK 6.5x ist aus 2013 und wurde mit 500er ICs vorgestellt.

Zu den Gets:
Siehst Du die Box mit Angabe des Timeouts? Das sollte nicht regelmäßig sein; normalerweise nur in Ausnahmefällen.

waver

Zitat von: krikan am 30 August 2015, 19:47:19
Vermutung unterstütze ich wegen Optik und Erfahrungen aus der Vergangenheit. Das ist aber kein Wissen.
Das die Klassen im Handbuch stehen hatte ich auch gesehen. Aber ich finde es immer alles noch mehr als merkwürdig.
SDK 4.5 ist aus 2009
SDK 6.5x ist aus 2013 und wurde mit 500er ICs vorgestellt.
Unterstützt dann mein ZME_064374 Z-Wave Plus komplett? Oder nur teilweise? Oder gar nicht?

Zitat von: krikan am 30 August 2015, 19:47:19
Zu den Gets:
Siehst Du die Box mit Angabe des Timeouts? Das sollte nicht regelmäßig sein; normalerweise nur in Ausnahmefällen.
Du meinst das Popup von FHEM? Ja, sehe ich. Da steht aber keine Zeit drin: "Timeout reading answer for get mcEndpoints"
Die Timeouts kommen schon öfters.

Wieso steht das Ergebnis der Abfrage dann aber im List wenn ich das Popup mit dem Timeout bekommen habe?

krikan

ZitatUnterstützt dann mein ZME_064374 Z-Wave Plus komplett? Oder nur teilweise? Oder gar nicht?
Keine Ahnung. Die Command Classes scheint das Ding zu kennen. Ob der Chip der neue ist? Was jetzt genau dahintersteckt, ist so kaum festzustellen. Hersteller fragen, ob 500er Chipsatz und warum kein SDK6.5 und hier berichten.

ZitatDie Timeouts kommen schon öfters.
Dann stimmt etwas nicht. Ich ahne Deine Frage, kann sie aber nicht beantworten ;-) Alle Assoziationen korrekt,....

ZitatWieso steht das Ergebnis der Abfrage dann aber im List wenn ich das Popup mit dem Timeout bekommen habe?
Nach einer Sekunde denkt Fhem, das nichts mehr kommt und zeigt die Box. Wenn später, so wie bei Dir, doch noch die Antwort eintrifft, verarbeitet Fhem sie und sie steht deshalb im list.

waver

Welches SDK ist es dann bei dem Teil mit der alten Firmware? Wegen der größeren Lib hätte ich vorher auf neuer getppt aber das kann ja nicht sein. Gibt es da irgendwo eine Liste wo man das nachschauen kann?

version:Lib 6 Prot 2.51 App 1.0


Gibt es eigentlich eine CommandClass für das OTA Firmware-Update mit dem Popp wirbt oder läuft das ganz anders ab?

krikan

Zitat von: waver am 30 August 2015, 21:06:09
Welches SDK ist es dann bei dem Teil mit der alten Firmware? Wegen der größeren Lib hätte ich vorher auf neuer getppt aber das kann ja nicht sein. Gibt es da irgendwo eine Liste wo man das nachschauen kann?

version:Lib 6 Prot 2.51 App 1.0

http://wiki.micasaverde.com/index.php/ZWave_Protocol_Version : SDK 5.02
Es gibt für mich keine erkennbare Logik in der Vergabe der ProtId->SDK-Übersetzung. Das ist genauso seltsam, wie ein SDK 5.x das älter ist als SDK 4.5.

ZitatCommandClass für das OTA Firmware-Update
Das soll mit der Command Class FIRMWARE_UPDATE_MD gehen.

waver

Zitat von: krikan am 30 August 2015, 21:28:48
http://wiki.micasaverde.com/index.php/ZWave_Protocol_Version : SDK 5.02
Es gibt für mich keine erkennbare Logik in der Vergabe der ProtId->SDK-Übersetzung. Das ist genauso seltsam, wie ein SDK 5.x das älter ist als SDK 4.5.
Danke, die Liste ist schon super aber leider nicht aktuell deswegen kann ich Deine Aussage jetzt nicht ganz nachvollziehen. Lib und App scheinen keine Rolle zu spielen.

Zitat von: krikan am 30 August 2015, 21:28:48
Das soll mit der Command Class FIRMWARE_UPDATE_MD gehen.
Die der Popp zumindest laut Manual gar nicht hat genau wie mein ZME_064374. Könnte es vielleicht mit MANUFACTURER_SPECIFIC gehen?

Beim Controller ZME_UZB1 ist mir inzwischen aufgefallen, dass es da auch etliche UNKNOWN_xy gibt. Kann ich das auch mit einem Update beheben.
Oder muss ich den Controller quasi neu Inkludieren wie den Switch zuerst? Beim Controller weiß ich aber gar nicht wie das geht.

Vers:5 Rev:1 ManufID:0115 ProductType:0400 ProductID:0001 SERIAL_API_GET_INIT_DATA SERIAL_API_APPL_NODE_INFORMATION APPLICATION_COMMAND_HANDLER ZW_GET_CONTROLLER_CAPABILITIES SERIAL_API_SET_TIMEOUTS SERIAL_API_GET_CAPABILITIES SERIAL_API_SOFT_RESET UNKNOWN_09 UNKNOWN_0a ZW_SET_R_F_RECEIVE_MODE ZW_SET_SLEEP_MODE ZW_SEND_NODE_INFORMATION ZW_SEND_DATA ZW_SEND_DATA_MULTI ZW_GET_VERSION ZW_SEND_DATA_ABORT ZW_R_F_POWER_LEVEL_SET ZW_SEND_DATA_META ZW_GET_RANDOM MEMORY_GET_ID MEMORY_GET_BYTE MEMORY_PUT_BYTE MEMORY_GET_BUFFER MEMORY_PUT_BUFFER FLASH_AUTO_PROG_SET UNKNOWN_28 NVM_GET_ID NVM_EXT_READ_LONG_BUFFER NVM_EXT_WRITE_LONG_BUFFER NVM_EXT_READ_LONG_BYTE NVM_EXT_WRITE_LONG_BYTE ZW_GET_NODE_PROTOCOL_INFO ZW_SET_DEFAULT ZW_REPLICATION_COMMAND_COMPLETE ZW_REPLICATION_SEND_DATA ZW_ASSIGN_RETURN_ROUTE ZW_DELETE_RETURN_ROUTE ZW_REQUEST_NODE_NEIGHBOR_UPDATE ZW_APPLICATION_UPDATE ZW_ADD_NODE_TO_NETWORK ZW_REMOVE_NODE_FROM_NETWORK ZW_CREATE_NEW_PRIMARY ZW_CONTROLLER_CHANGE ZW_SET_LEARN_MODE ZW_ASSIGN_SUC_RETURN_ROUTE ZW_REQUEST_NETWORK_UPDATE ZW_SET_SUC_NODE_ID ZW_DELETE_SUC_RETURN_ROUTE ZW_GET_SUC_NODE_ID ZW_SEND_SUC_ID ZW_EXPLORE_REQUEST_INCLUSION ZW_REQUEST_NODE_INFO ZW_REMOVE_FAILED_NODE_ID ZW_IS_FAILED_NODE ZW_REPLACE_FAILED_NODE UNKNOWN_66 UNKNOWN_67 UNKNOWN_78 GET_ROUTING_TABLE_LINE LOCK_ROUTE_RESPONSE UNKNOWN_92 UNKNOWN_93 UNKNOWN_98 UNKNOWN_b4 ZW_WATCHDOG_ENABLE ZW_WATCHDOG_DISABLE ZW_WATCHDOG_CHECK ZW_SET_EXT_INT_LEVEL ZW_RF_POWERLEVEL_GET ZW_TYPE_LIBRARY ZW_SEND_TEST_FRAME ZW_GET_PROTOCOL_STATUS WATCHDOG_START WATCHDOG_STOP UNKNOWN_d4 UNKNOWN_ef ZME_FREQ_CHANGE ZME_BOOTLOADER_FLASH UNKNOWN_f5

krikan

Zitat von: waver am 30 August 2015, 22:55:16
Danke, die Liste ist schon super aber leider nicht aktuell deswegen kann ich Deine Aussage jetzt nicht ganz nachvollziehen. Lib und App scheinen keine Rolle zu spielen.
Ich kann (eher will zeitlich) nicht alles im Detail belegen und nachweisen. Sorry. Zu Quellen musst Du Dich bitte durchs Wiki/Forum quälen und Internetsuche bemühen. Versuche zwar möglichst fundiert zu antworten, aber da mein Wissen nur aus verstreuten Sekundärquellen stammt (wir haben keinen Zugriff auf offizielle Sigma-Quellen), kann man Fehler nicht ausschließen. Und dann hoffe ich hier im Forum auf Protest, um mich/uns weiterzubringen.

Beim Controller kennen wir eben auch nicht alle Bezeichnungen der caps; darum UNKOWN_xy und selbst wenn wir die Bezeichnung kennen, bedeutet es nicht, das es implementiert ist.

ZitatKönnte es vielleicht mit MANUFACTURER_SPECIFIC gehen?
Eher unwahrscheinlich. CC hat eine andere Funktion.

Zu Deinem ZME/Popp: Ich finde es mehr als merkwürdig und würde mal beim Hersteller(n) nachfragen. Nur der kann diese Dinge mit Sicherheit aufklären, wenn er will. Und dann natürlich hier berichten ;-).