Zwave Eurotronic Comet, wie richtig benutzen

Begonnen von CaSch1306, 30 Dezember 2015, 07:07:14

Vorheriges Thema - Nächstes Thema

CaSch1306

Hallo liebes Forum,

ich habe eine Frage, die ich weder durch die Suche im Forum noch durch Google lösen kann.

Ich befinde mich ganz am Anfang meiner Hausautomation.
Zur Info ich nutze einen Banana Pi mit zwave USB Stick als Basis.
Im Moment habe ich nur das Gäste-WC mit Komponenten ausgestattet, das sind 1x Fibaro Fensterkontakt, 1x Fibaro Relayswitch und eben das Eurotronic COmet Thermostat

Ich habe mich vorher im Internet ein wenig schlau gemacht wegen den Thermostaten und bin auf 3 für mich mögliche Thermostate gestoßen. Das Danfoss, das zu Danfoss baugleiche Devolo und eben das Comet.

Ein Bericht auf siio.de hat mich dann bekräftigt das günstigste zu nehmen, da es laut dem Bericht nur die Eigenheit hat, bei manueller Betätigung diesen Zustand für 2 Stunden zu behalten und darüber keine Rückmeldung zu geben, damit könnte ich aber gut leben. Beim Danfoss würde mich stören, das es die Temperatur wohl nicht zurückmelden kann und die Position der "Anzeige" sowie der Tasten. Und Devolo scheint wohl ein eigenes Süppchen zu kochen, was die Firmware angeht, da war halt die Frage ob alles unterstützt werden würde.

Bevor ich alles "verbaut" habe, habe ich die einzelnen Komponenten erstmal im Arbeitszimmer angelernt --> soweit alles gut.
Bei passender Gelegenheit habe ich dann Fensterkontakt und Thermostat verbaut. Der Fensterkontakt tut was er soll das Thermostat hat erstmal nicht mit fhem kommuniziert, dafür musste ich erste den Relayswitch montieren, da dieser wohl das Signal routet, ich habe jedenfalls vorher keine Rückmeldung bekommen.

Nun ist es so, dass ich zunächst keinerlei weitere Infos des Thermostats in fhem hatte. Nach einem Update und einem get model habe ich dann zumindest noch Temperatur und ein paar andere Infos bekommen. Ich konnte das Wakeupinterval auf 15 Minuten setzen.

Jetzt zum eigentlichen Thema, den Problemen:

  • Bei jedem Wakeup kann ich immer nur ein get absetzen, setze ich mehrere gets ab, wird nur der erste ausgeführt
  • Ich habe in der Auswahlliste der set Befehle keine Ahnung, was ich absetzen muss, damit sich die Temperatur ändern lässt
  • Es gibt auch ein DIM, was wohl für die prozentuale Öffnung des Ventils steht, ein Set dim scheint aber nicht zu greifen
  • Ich bekomme keine automatischen Statusupdates

Hat einer von euch das Eurotronic Comet als ZWave Gerät im Einsatz und kann mich dabei unterstützen?
Was kann ich tun um Infos zu liefern?

Ein paar Infos, die vielleicht Helfen:

model: 0x0148 0x0002 0x0001
modelId: 0148-0002-0001


Internals:

DEF  ea1c45a1 5
IODev ZWAVE1
LASTInputDev ZWAVE1
MSGCNT 48
NAME GWC.Heizung
NR 27
STATE dim 11
TYPE ZWave
ZWAVE1_MSGCNT 48
ZWAVE1_RAWMSG 00040005063105012200d7
ZWAVE1_TIME 2015-12-30 06:58:03
homeId ea1c45a1
isWakeUp 1
lastMsgSent 1451455083.00554
nodeIdHex 05


Readings:

CMD ZW_APPLICATION_UPDATE 2015-12-22 07:22:04
basicReport ff 2015-12-28 22:29:47
battery 100 % 2015-12-30 06:42:58
model 0x0148 0x0002 0x0001 2015-12-29 22:09:22
modelId 0148-0002-0001 2015-12-29 22:09:22
reportedState dim 11 2015-12-29 22:54:40
state dim 11 2015-12-29 22:54:40
temperature 21.5 C 2015-12-30 06:58:03
transmit OK 2015-12-30 06:58:05
versionClass_20 01 2015-12-28 18:42:17
wakeup notification 2015-12-30 06:58:03


Gruß
Carsten
Raspberry Pi 2, ZWAVE ZME.USB MAXCUBE mit CUNO Firmware

A.Harrenberg

Hi Carsten,

könntest Du bitte noch ein "list" von dem Device machen (http://www.fhemwiki.de/wiki/Z-Wave#Welche_Infos_sollten_Anfragen_im_ZWave-Forum_enthalten.3F) und hier posten?

Meine Thermostate sind "HomeMatic", daher kenne ich das Ding auch nicht. Normalerweise sollte das Gerät die Klasse "THERMOSTAT_SETPOINT" melden und dann bei set den Befehl "setpointheating" anbieten, damit solltest Du die Temperatur setzen können. So wie ich das momentan aus dem FHEM-code sehe, ist das eine Zahl ohne Dezimalstelle, d.h. Du kanns dort aktuell nur "ganze" Grad einstellen.

Hier könnte man aber bei Gelegenheit den Code mal erweitern, die Klasse erlaubt da auch Nachkommastellen, das ist aber momentan nicht implementiert und man müsste auch erst mal herausbekommen was Dein Thermostat unterstützt.

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

krikan

Hallo Carsten,

von mir nur der Link zu einem Test des Thermostates http://www.zwave-review.com/tests/heizungssteuerung.php.

FHEM bietet grundsätzlich alle von FHEM unterstützten Funktionen/Befehle einer vom Gerät gemeldeten Command Class zur Auswahl an. Dies unabhängig davon, ob das Gerät eine spezielle Funktion/Befehl der Command Class unterstützt oder (gegen den Standard) nicht unterstützt. Zudem wird von FHEM nicht berücksichtigt, welche Version der Command Class das Gerät hat; es werden Funktionen/Befehle aller in FHEM eingebauten Versionen angeboten.

Gruß, Christian

CaSch1306

#3
Hallo Andreas,

hier ein List:

Internals:
   DEF        ea1c45a1 5
   IODev      ZWAVE1
   NAME       GWC.Heizung
   NR         27
   STATE      dim 11
   TYPE       ZWave
   homeId     ea1c45a1
   nodeIdHex  05
   Readings:
     2015-12-22 07:22:04   CMD             ZW_APPLICATION_UPDATE
     2015-12-28 22:29:47   basicReport     ff
     2015-12-30 06:42:58   battery         100 %
     2015-12-29 22:09:22   model           0x0148 0x0002 0x0001
     2015-12-29 22:09:22   modelId         0148-0002-0001
     2015-12-30 07:43:23   reportedState   dim 11
     2015-12-30 07:43:23   state           dim 11
     2015-12-30 07:43:24   temperature     21.5 C
     2015-12-30 08:13:37   transmit        OK
     2015-12-28 18:42:17   versionClass_20 01
     2015-12-30 08:13:35   wakeup          notification
Attributes:
   IODev      ZWAVE1
   classes    BASIC SWITCH_MULTILEVEL SENSOR_MULTILEVEL THERMOSTAT_MODE THERMOSTAT_SETPOINT NODE_NAMING BATTERY WAKE_UP MANUFACTURER_SPECIFIC VERSION
   group      Heizung
   icon       sani_heating
   room       Gäste WC,ZWave


setpointheating ist auch in der Auswahlliste, ich habe den set setpointheating auch schon mehrfach ausgeführt, nur hat es nie funktioniert.

Hallo Christian,

den Test hatte ich auch schon gesehen und auch nochmal "überflogen" und dabei gesehen, dass die Werte nicht automatisch übermittelt werden. Ich habe mir jetzt beholfen indem ich mehrere Notifies definiert habe, die Abfragen nach dem notify starten:

define GWC.update notify GWC.Heizung:wakeup:.* get GWC.Heizung smStatus
define GWC.update1 notify GWC.Heizung:wakeup:.* get GWC.Heizung swmStatus
define GWC.update2 notify GWC.Heizung:wakeup:.* get GWC.Heizung thermostatMode


damit bekomme ich nun Temperatur (smStatus), Dim Status (swmStatus) und den Modus (z.B. heating) (thermostatMode) zurück. Allerdings überschreiben sich swmStatus und thermostatMode direkt nacheinander.

Ich habe nun nochmal dsetpointHeating definiert und werde mal schauen was passiert.

Gruß
Carsten
Raspberry Pi 2, ZWAVE ZME.USB MAXCUBE mit CUNO Firmware

krikan

Hallo Carsten,
könntest Du bitte die im Fhemwiki-Link von Andreas beschriebenen Befehle ausführen und das Ergebnis abwarten. Dann das list bitte noch einmal posten. Es fehlen sonst wichtige Infos, wie Versionen der Command Classes, gesetzte Assoziationen und Co. Das würde die Hilfe erleichtern.
Link in der Detailansicht zu pepper1 ist vermutlich http://www.pepper1.net/zwavedb/device/858 ?
Danke und Gruß, Christian

krikan

Sehe gerade, dass das Geräte überhaupt keine Asssoziationen kann. "set <device> associationRequestAll" kannst Du Dir sparen.
Interessant ist fast nur noch die Abfrage von "get <device> wakeupInterval", wenn die Versionen der Classes zu pepper1 passen. Bei noch im Zwave-Zertifizierungsprozeß befindlichen Geräten, habe ich nur immer die Sorge, dass pepper1 nicht passt.

CaSch1306

Hallo Christian,

pepper scheint zu passen.

wakeupintervall ist auf 15minuten und das passt auch

Ansonsten

List nach versionclassrequest:

Internals:
   DEF        ea1c45a1 5
   IODev      ZWAVE1
   LASTInputDev ZWAVE1
   MSGCNT     2
   NAME       GWC.Heizung
   NR         27
   STATE      TRANSMIT_NO_ACK
   TYPE       ZWave
   ZWAVE1_MSGCNT 2
   ZWAVE1_RAWMSG 00130501026b
   ZWAVE1_TIME 2015-12-30 08:59:05
   homeId     ea1c45a1
   isWakeUp   1
   lastMsgSent 1451462339.1232
   nodeIdHex  05
   Readings:
     2015-12-22 07:22:04   CMD             ZW_APPLICATION_UPDATE
     2015-12-28 22:29:47   basicReport     ff
     2015-12-30 06:42:58   battery         100 %
     2015-12-29 22:09:22   model           0x0148 0x0002 0x0001
     2015-12-29 22:09:22   modelId         0148-0002-0001
     2015-12-30 08:43:49   reportedState   heating
     2015-12-30 08:59:05   state           TRANSMIT_NO_ACK
     2015-12-30 08:43:48   temperature     21.5 C
     2015-12-30 08:59:05   transmit        NO_ACK
     2015-12-28 18:42:17   versionClass_20 01
     2015-12-30 08:58:55   wakeup          notification
   SendStack:
     sent:13050226022505
     13050240022505
     13050231042505
   Versionhash:
     BASIC
     BATTERY    01
     MANUFACTURER_SPECIFIC
     NODE_NAMING
     SENSOR_MULTILEVEL
     SWITCH_MULTILEVEL
     THERMOSTAT_MODE
     THERMOSTAT_SETPOINT
     VERSION
     WAKE_UP
Attributes:
   IODev      ZWAVE1
   classes    BASIC SWITCH_MULTILEVEL SENSOR_MULTILEVEL THERMOSTAT_MODE THERMOSTAT_SETPOINT NODE_NAMING BATTERY WAKE_UP MANUFACTURER_SPECIFIC VERSION
   group      Heizung
   icon       sani_heating
   room       Gäste WC,ZWave


configRequestAll liefert allerdings genau wie associationRequestAll einen Fehler:

Unknown argument associationRequestAll, choose one of basicSet basicValue dim location name neighborUpdate off on setpointCooling setpointHeating stop tmCooling tmHeating tmManual tmOff versionClassRequest wakeupInterval wakeupNoMoreInformation blink off-till-overnight on-for-timer on-till-overnight off-till on-till off-for-timer toggle intervals
Raspberry Pi 2, ZWAVE ZME.USB MAXCUBE mit CUNO Firmware

krikan

Hallo Carsten,

sorry, wenn ich zu ungenau bin, da ich Deinen Infostand zu ZWave nicht kenne.

Die Befehle im Wiki müssen erst noch vom Gerät beantwortet werden. Bei den WAKE_UP-Geräten erfolgt das erst beim nächsten Aufwachen. Du hast zwar die Befehle abgesetzt, aber die sind noch nicht an das Gerät verschickt bzw. beantwortet. Sieht man hieran:
   SendStack:
     sent:13050226022505
     13050240022505
     13050231042505
   Versionhash:
     BASIC
     BATTERY    01
     MANUFACTURER_SPECIFIC
     NODE_NAMING
     SENSOR_MULTILEVEL
     SWITCH_MULTILEVEL
     THERMOSTAT_MODE
     THERMOSTAT_SETPOINT
     VERSION
     WAKE_UP


Oder liegt das an nur einem Befehl pro wakeupNotification?

Mich würde wakeupInterval interessieren, weil man dann erkennen kann, ob Empfänger der wakeupNotification der Controller ist, oder ob das noch fälschlicherweise auf Broadcast steht und es deshalb Ansteuerungsprobleme gibt.

configRequestAll kann auch nicht funktionieren, da das Gerät keine Command Class CONFIG besitzt. Deshalb findest Du den Befehl auch nicht auf der Detailansicht des Gerätes zur Auswahl angeboten.
Zitat
Allerdings überschreiben sich swmStatus und thermostatMode direkt nacheinander.
Das ist richtig und mMn nach nicht ideal.
Wir hatten das Thema mehrere "state" bei einem ZWave-Device schon einmal. Ich kann mich nur leider nicht mehr erinnern bzw. finden, ob das im Modul so bleiben soll oder nicht. (Rudi?)

Gruß, Christian

CaSch1306

#8
Hallo Christian,

mein Wissensstand ist, naja sagen wir mal so ich bin am Anfang.

Natürlich ist mir klar, dass ich einen Wakeup warten muss, was ich auch getan hatte, nach dem ich den versionClassRequest abgesetzt hatte und den List Befehl ausgeführt habe.

Das wakeupinterval hatte ich per set wakeupinteral 900 01 und auch mit 900 1 gesetzt, die Zeit zumindest passt, das kann ich aus den Logs sehen.

Ich habe jetzt eine abfrage nach dem Interval gestartet. und werde berichten.

Allerdings sehe ich jetzt im allgemeinen Log (nach verbose 5) mehrfach:

ZWDongle_ReadAnswer: select timeout

und dann anhand meiner notifies jeweils: return value: Timeout reading answer for get smStatus / swmStatus / thermostatMode
Und der Status steht auf TRANSMIT_NO_ACK sowie transmit NO_ACK

Ich kann gerne die notifies nochmal deaktivieren und dann für jeden der Befehle einzeln warten.

Allerdings scheint das setpointheating funktioniert zu haben
Raspberry Pi 2, ZWAVE ZME.USB MAXCUBE mit CUNO Firmware

krikan

Zitat von: CaSch1306 am 30 Dezember 2015, 10:17:09
Das wakeupinterval hatte ich per set wakeupinteral 900 01 und auch mit 900 1 gesetzt, die Zeit zumindest passt, das kann ich aus den Logs sehen.
Das wird eigentlich seit Kurzem auch schon durch FHEM bei Inklusion gesetzt, aber Sicherheit gibt Dir nur die Abfrage mit "get <device> wakeupInterval". Nur wenn dort in der Antwort das Dongle als Empfänger auftaucht, kannst Du der korrekten Verarbeitung sicher sein. Insbesondere, wenn sich das Ding so zickig zeigt.

Zitat
ZWDongle_ReadAnswer: select timeout

und dann anhand meiner notifies jeweils: return value: Timeout reading answer for get smStatus / swmStatus / thermostatMode
Und der Status steht auf TRANSMIT_NO_ACK
Das, insbesondere erstes, finde ich merkwürdig. Kannst Du mal ein Log mit Attribut verbose 5 beim Gateway/Dongle "attr <ZWDongle> verbose 5" und "attr global mseclog 1" für die Kommunikationsfehler zeigen. Die notifys auf jeden Fall dabei aktiviert lassen und die Abarbeitung sollte im Log sein.

rudolfkoenig

ZitatUnd der Status steht auf TRANSMIT_NO_ACK
Das bedeutet entweder, dass das Geraet nach dem wakeup zu frueh eingeschlafen ist, oder dass es Probleme bei der Uebertragung gibt. Ich tippe auf Letzteres, wobei das Problem nicht unbeding an der Entfernung / Abschirmung liegen muss, sondern evtl. an der schlechten routing Tabellen. Diese kann man manchmal mit neighborUpdate verbessern, mir ist aber nicht bekannt, wie man diese auslesen kann.

CaSch1306

#11
So mal abwarten was passiert.

Zum Default wert, hier mal der Auszug aus der Log beim Anlernen des Thermostats:

2015.12.22 07:19:16 2: autocreate: define ZWave_THERMOSTAT_5 ZWave ea1c45a1 5 20263140437780847286
2015.12.22 07:19:16 2: autocreate: define FileLog_ZWave_THERMOSTAT_5 FileLog ./log/ZWave_THERMOSTAT_5-%Y.log ZWave_THERMOSTAT_5
2015.12.22 07:19:17 2: ZWave set ZWave_THERMOSTAT_5 wakeupInterval 86400 01
2015.12.22 07:19:18 2: ZWave get ZWave_THERMOSTAT_5 model
2015.12.22 07:19:18 1: ZWAVE INIT: get ZWave_THERMOSTAT_5 model: model:0x0148 0x0002 0x0001
modelId:0148-0002-0001
model:0x0148 0x0002 0x0001
2015.12.22 07:20:13 2: autocreate: renamed FileLog_ZWave_THERMOSTAT_5 to FileLog_GWC.Heizung


Ich habe die notifies aktiv, verbose auf 5 mseclog auf 1

werde jetzt noch ein wakeup warten und dann den Auszug aus dem Log posten.

So Edit:
Der Wakeup ist durchgelaufen, diesmal gab es keine timeouts

2015.12.30 10:44:57.595 4: ZWDongle_Read ZWAVE1: sending ACK, processing 00040005028407
2015.12.30 10:44:57.596 5: SW: 06
2015.12.30 10:44:57.598 5: ZWAVE1 dispatch 00040005028407
2015.12.30 10:44:57.652 4: ZWAVE1 CMD:APPLICATION_COMMAND_HANDLER ID:05 ARG:028407
2015.12.30 10:44:57.660 2: ZWave get GWC.Heizung battery
2015.12.30 10:44:57.661 5: ZWDongle_Write 0013050280022505 (ea1c45a1)
2015.12.30 10:44:57.662 5: SW: 0109001305028002250540
2015.12.30 10:44:57.664 4: ZWDongle_ReadAnswer arg:battery regexp:^00040005..80
2015.12.30 10:44:57.665 5: ACK received, WaitForAck=>2 for 0109001305028002250540
2015.12.30 10:44:57.671 4: ZWDongle_Read ZWAVE1: sending ACK, processing 011301
2015.12.30 10:44:57.671 5: SW: 06
2015.12.30 10:44:57.673 5: ZWAVE1 dispatch 011301
2015.12.30 10:44:57.709 4: ZWDongle_Read ZWAVE1: sending ACK, processing 001305000004
2015.12.30 10:44:57.709 5: SW: 06
2015.12.30 10:44:57.711 5: device ack reveived, removing 0109001305028002250540 from dongle sendstack
2015.12.30 10:44:57.712 5: ZWAVE1 dispatch 001305000004
2015.12.30 10:44:57.712 4: ZWAVE1 CMD:ZW_SEND_DATA ID:00 ARG:0004
2015.12.30 10:44:57.713 4: ZWAVE1 transmit OK for 05
2015.12.30 10:44:57.754 4: ZWDongle_Read ZWAVE1: sending ACK, processing 0004000503800364
2015.12.30 10:44:57.754 5: SW: 06
2015.12.30 10:44:57.756 4: ZWDongle_ReadAnswer for battery: 0004000503800364
2015.12.30 10:44:57.757 4: ZWAVE1 CMD:APPLICATION_COMMAND_HANDLER ID:05 ARG:03800364
2015.12.30 10:44:57.759 3: GWC.heizung_update_batt return value: battery:100 %
2015.12.30 10:44:57.763 2: ZWave get GWC.Heizung swmStatus
2015.12.30 10:44:57.764 5: ZWDongle_Write 0013050226022505 (ea1c45a1)
2015.12.30 10:44:57.765 5: SW: 01090013050226022505e6
2015.12.30 10:44:57.766 4: ZWDongle_ReadAnswer arg:swmStatus regexp:^00040005..26
2015.12.30 10:44:57.767 5: ACK received, WaitForAck=>2 for 01090013050226022505e6
2015.12.30 10:44:57.774 4: ZWDongle_Read ZWAVE1: sending ACK, processing 011301
2015.12.30 10:44:57.774 5: SW: 06
2015.12.30 10:44:57.776 5: ZWAVE1 dispatch 011301
2015.12.30 10:44:57.874 4: ZWDongle_Read ZWAVE1: sending ACK, processing 00130500000a
2015.12.30 10:44:57.875 5: SW: 06
2015.12.30 10:44:57.876 5: device ack reveived, removing 01090013050226022505e6 from dongle sendstack
2015.12.30 10:44:57.877 5: ZWAVE1 dispatch 00130500000a
2015.12.30 10:44:57.878 4: ZWAVE1 CMD:ZW_SEND_DATA ID:00 ARG:000a
2015.12.30 10:44:57.878 4: ZWAVE1 transmit OK for 05
2015.12.30 10:44:58.000 4: ZWDongle_Read ZWAVE1: sending ACK, processing 0004000503260315
2015.12.30 10:44:58.000 5: SW: 06
2015.12.30 10:44:58.002 4: ZWDongle_ReadAnswer for swmStatus: 0004000503260315
2015.12.30 10:44:58.003 4: ZWAVE1 CMD:APPLICATION_COMMAND_HANDLER ID:05 ARG:03260315
2015.12.30 10:44:58.006 3: GWC.heizung_update_dim return value: state:dim 21
2015.12.30 10:44:58.010 2: ZWave get GWC.Heizung thermostatMode
2015.12.30 10:44:58.011 5: ZWDongle_Write 0013050240022505 (ea1c45a1)
2015.12.30 10:44:58.011 5: SW: 0109001305024002250580
2015.12.30 10:44:58.013 4: ZWDongle_ReadAnswer arg:thermostatMode regexp:^00040005..40
2015.12.30 10:44:58.014 5: ACK received, WaitForAck=>2 for 0109001305024002250580
2015.12.30 10:44:58.020 4: ZWDongle_Read ZWAVE1: sending ACK, processing 011301
2015.12.30 10:44:58.020 5: SW: 06
2015.12.30 10:44:58.022 5: ZWAVE1 dispatch 011301
2015.12.30 10:44:58.110 4: ZWDongle_Read ZWAVE1: sending ACK, processing 001305000009
2015.12.30 10:44:58.110 5: SW: 06
2015.12.30 10:44:58.112 5: device ack reveived, removing 0109001305024002250580 from dongle sendstack
2015.12.30 10:44:58.113 5: ZWAVE1 dispatch 001305000009
2015.12.30 10:44:58.113 4: ZWAVE1 CMD:ZW_SEND_DATA ID:00 ARG:0009
2015.12.30 10:44:58.114 4: ZWAVE1 transmit OK for 05
2015.12.30 10:44:58.156 4: ZWDongle_Read ZWAVE1: sending ACK, processing 0004000503400301
2015.12.30 10:44:58.156 5: SW: 06
2015.12.30 10:44:58.158 4: ZWDongle_ReadAnswer for thermostatMode: 0004000503400301
2015.12.30 10:44:58.159 4: ZWAVE1 CMD:APPLICATION_COMMAND_HANDLER ID:05 ARG:03400301
2015.12.30 10:44:58.161 3: GWC.heizung_update_mode return value: state:heating
2015.12.30 10:44:58.165 2: ZWave get GWC.Heizung smStatus
2015.12.30 10:44:58.174 5: ZWDongle_Write 0013050231042505 (ea1c45a1)
2015.12.30 10:44:58.174 5: SW: 01090013050231042505f7
2015.12.30 10:44:58.176 4: ZWDongle_ReadAnswer arg:smStatus regexp:^00040005..31
2015.12.30 10:44:58.177 5: ACK received, WaitForAck=>2 for 01090013050231042505f7
2015.12.30 10:44:58.183 4: ZWDongle_Read ZWAVE1: sending ACK, processing 011301
2015.12.30 10:44:58.183 5: SW: 06
2015.12.30 10:44:58.185 5: ZWAVE1 dispatch 011301
2015.12.30 10:44:58.270 4: ZWDongle_Read ZWAVE1: sending ACK, processing 001305000009
2015.12.30 10:44:58.270 5: SW: 06
2015.12.30 10:44:58.272 5: device ack reveived, removing 01090013050231042505f7 from dongle sendstack
2015.12.30 10:44:58.273 5: ZWAVE1 dispatch 001305000009
2015.12.30 10:44:58.273 4: ZWAVE1 CMD:ZW_SEND_DATA ID:00 ARG:0009
2015.12.30 10:44:58.274 4: ZWAVE1 transmit OK for 05
2015.12.30 10:44:58.402 4: ZWDongle_Read ZWAVE1: sending ACK, processing 00040005063105012200eb
2015.12.30 10:44:58.402 5: SW: 06
2015.12.30 10:44:58.404 4: ZWDongle_ReadAnswer for smStatus: 00040005063105012200eb
2015.12.30 10:44:58.405 4: ZWAVE1 CMD:APPLICATION_COMMAND_HANDLER ID:05 ARG:063105012200eb
2015.12.30 10:44:58.409 3: GWC.heizung_update_temp return value: temperature:23.5 C
2015.12.30 10:45:00.235 5: ZWDongle_Write 0013050284082505 (ea1c45a1)
2015.12.30 10:45:00.236 5: SW: 010900130502840825054e
2015.12.30 10:45:00.238 5: ACK received, WaitForAck=>2 for 010900130502840825054e
2015.12.30 10:45:00.245 4: ZWDongle_Read ZWAVE1: sending ACK, processing 011301
2015.12.30 10:45:00.245 5: SW: 06
2015.12.30 10:45:00.247 5: ZWAVE1 dispatch 011301
2015.12.30 10:45:00.283 4: ZWDongle_Read ZWAVE1: sending ACK, processing 001305000004
2015.12.30 10:45:00.284 5: SW: 06
2015.12.30 10:45:00.285 5: device ack reveived, removing 010900130502840825054e from dongle sendstack
2015.12.30 10:45:00.286 5: ZWAVE1 dispatch 001305000004
2015.12.30 10:45:00.287 4: ZWAVE1 CMD:ZW_SEND_DATA ID:00 ARG:0004
2015.12.30 10:45:00.287 4: ZWAVE1 transmit OK for 05


Jetzt setzte ich noch einen get wakeupinterval dazu und hoffe dass dann mehr Infos kommen.
Raspberry Pi 2, ZWAVE ZME.USB MAXCUBE mit CUNO Firmware

A.Harrenberg

Hallo Carsten,
Zitat von: CaSch1306 am 30 Dezember 2015, 10:17:09
Allerdings sehe ich jetzt im allgemeinen Log (nach verbose 5) mehrfach:

ZWDongle_ReadAnswer: select timeout

und dann anhand meiner notifies jeweils: return value: Timeout reading answer for get smStatus / swmStatus / thermostatMode
Und der Status steht auf TRANSMIT_NO_ACK sowie transmit NO_ACK
das mit dem "select timeout" passiert manchmal und ist normalerweise eine Fehlermeldung wenn auf ein get keine entsprechende Antwort kommt. Allerdings kann es momentan leider auch passieren das diese Abfrage startet BEVOR der get-Befehl vom Sendestack überhaupt gesendet wurde. Dann wird auf eine Antwort gewartet die nicht kommen kann... Das ist bei normalen Geräten nicht schlimm, der get-Befehl wird anschliessend verschickt und die Antwort wird selbstverstänlich auch verarbeitet (allerdings ohne das evtl. "Pop-Up"-Fenster).

Bei WakeUp-Geräte führt das aber in der Regel dazu das das Gerät während der Wartezeit auf die Antwort wieder einschläft. Wenn FHEM danach versucht noch Befehle zu verschicken (zum Beispiel den noch "offenen" get-Befehl, oder auch die "geh-wieder-schlafen" (WakeUpNoMoreInformation) Nachricht, dann antwortet das Gerät natürlich nicht mehr, was mit dem NO_ACK endet.

Hier müsste man mal in ein Logfile schauen was da genau in welcher Reihenfolge passiert.

Zitat von: CaSch1306 am 30 Dezember 2015, 10:17:09
Ich kann gerne die notifies nochmal deaktivieren und dann für jeden der Befehle einzeln warten.
Das deaktivieren der notifies dürfte die Kommunikation verbessern, genaueres kann man aber nur mit Logfile sagen (mit aktivierten mseclog=1, siehe wiki-eintrag).

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

rudolfkoenig

ZitatWir hatten das Thema mehrere "state" bei einem ZWave-Device schon einmal. Ich kann mich nur leider nicht mehr erinnern bzw. finden, ob das im Modul so bleiben soll oder nicht. (Rudi?)

Eigentlich darf es nicht moeglich sein, dass ein Geraet mit zwei Klassen was sendet, was im state landet, da der Benutzer nur die letzten sieht. Das ein thermostat sich als dimmer anbietet, kommt mir komisch vor, aber vermutlich deswegen, damit man es mit einer Fernbedienung paaren kann. Ich habe hiermit die Antwort von get thermostatMode von state nach thermostatMode geaendert.

CaSch1306

So,

ich hatte die notifies nochmal deaktiviert, da ich mit der Abfrage des wakeupintervals wieder einen Timeout bekommen habe.

Jetzt habe ich nochmal das wakeupinterval und die commandclasses abgefragt (jeweils einzeln) und hier nun das Listing:


Internals:
   DEF        ea1c45a1 5
   IODev      ZWAVE1
   LASTInputDev ZWAVE1
   MSGCNT     17
   NAME       GWC.Heizung
   NR         27
   STATE      versionClassRequest NODE_NAMING
   TYPE       ZWave
   ZWAVE1_MSGCNT 17
   ZWAVE1_RAWMSG 00040005028407
   ZWAVE1_TIME 2015-12-30 11:30:22
   homeId     ea1c45a1
   isWakeUp   1
   lastMsgSent 1451471423.984
   nodeIdHex  05
   Readings:
     2015-12-22 07:22:04   CMD             ZW_APPLICATION_UPDATE
     2015-12-28 22:29:47   basicReport     ff
     2015-12-30 11:00:09   battery         100 %
     2015-12-29 22:09:22   model           0x0148 0x0002 0x0001
     2015-12-29 22:09:22   modelId         0148-0002-0001
     2015-12-30 11:00:10   reportedState   dim 21
     2015-12-30 11:30:23   state           versionClassRequest NODE_NAMING
     2015-12-30 11:15:14   temperature     23.0 C
     2015-12-30 11:30:26   transmit        OK
     2015-12-28 18:42:17   versionClass_20 01
     2015-12-30 11:30:22   wakeup          notification
     2015-12-30 11:15:18   wakeupReport    interval 900 target 1
Attributes:
   IODev      ZWAVE1
   classes    BASIC SWITCH_MULTILEVEL SENSOR_MULTILEVEL THERMOSTAT_MODE THERMOSTAT_SETPOINT NODE_NAMING BATTERY WAKE_UP MANUFACTURER_SPECIFIC VERSION
   group      Heizung
   icon       sani_heating
   room       Gäste WC,ZWave
   vclasses   BASIC:01 BATTERY:01 MANUFACTURER_SPECIFIC:01 NODE_NAMING:01 SENSOR_MULTILEVEL:04 SWITCH_MULTILEVEL:03 THERMOSTAT_MODE:03 THERMOSTAT_SETPOINT:03 VERSION:01 WAKE_UP:02
Raspberry Pi 2, ZWAVE ZME.USB MAXCUBE mit CUNO Firmware