Vision CO Detector, sendet falsche Class

[PeterCu]

Hallo,

ich bastele ein wenig mit ZWave herum.

Wenn ich die Rawmsg des Geräts richtig interpretiere, dann enthält die Klasse (Byte 7) den Wert 32 (Meter) oder 33 (Color_Control) statt 30 (Sensor_Binary).

Die interpretierten Werte sind dann natürlich Nonsens.

Ist das Phänomen schon jemandem bekannt ? Wie wäre eine korrekte Fehlerbehandlung, ausser im ZWave-Modul für meine NodeID das Byte umschießen.

Protokoll:

2017-02-16_01:20:03 Z_CoDetector undef:  0.1 undef
2017-02-16_02:18:04 Z_CoDetector undef:  0 undef
2017-02-16_05:27:03 Z_CoDetector power:  6553.6 W
2017-02-16_18:16:04 Z_CoDetector undef:  0.1 undef
2017-02-16_21:03:04 Z_CoDetector undef:  0.1 undef
2017-02-17_01:34:04 Z_CoDetector undef:  0.1 undef
2017-02-17_06:17:04 Z_CoDetector UNPARSED: COLOR_CONTROL 0e3302213400000000000000000000
2017-02-17_09:22:04 Z_CoDetector undef:  0 undef

Gruß

Peter

PS: Dies ist mein erster Beitrag hier im Forum.

[rudolfkoenig]

Ich bin ein bisschen von den vielen undef ueberrascht: verwendest du die FHEM ZWave und ZWDongle Module?
Wenn ja: kannst du bitte einen Log-Mitschnitt mit "attr ZWDongle verbose 5" hier anhaengen?

[A.Harrenberg]

Hi,

vielleicht auch das Device auf verbose 5 umstellen...
"attr Z_CoDetector verbose 5"

Müsste noch mal in der Spec nachschauen, aus dem Kopf würde ich aber sagen das CO in "unserer" Liste drin ist. Firmwarefehler ist aber nicht auszuschließen.

Gruß,
Andreas.

[PeterCu]

Hallo,

ich habe Folgendes im Log gefunden:

Filelog Z_CODetector: 2017-02-17_17:26:04 Z_CoDetector undef:  0 undef
Filelog:
2017.02.17 17:26:04 4: ZWDongle_Read zvision: sending ACK, processing 0004000b0e3202213400000000000000000000
2017.02.17 17:26:04 5: SW: 06
2017.02.17 17:26:04 5: zvision dispatch 0004000b0e3202213400000000000000000000
2017.02.17 17:26:04 4: zvision CMD:APPLICATION_COMMAND_HANDLER ID:0b ARG:0e3202213400000000000000000000
2017.02.17 17:26:04 4: ZWDongle_Read zvision: sending ACK, processing 0004000a0e3202203400000000000000000000
2017.02.17 17:26:04 5: SW: 06
2017.02.17 17:26:04 5: zvision dispatch 0004000a0e3202203400000000000000000000
2017.02.17 17:26:04 4: zvision CMD:APPLICATION_COMMAND_HANDLER ID:0a ARG:0e3202203400000000000000000000

FileLog Funksteckdose:
2017-01-30_17:25:29 ZWave_SWITCH_BINARY_11 power:  0.7 W
2017-01-30_17:26:29 ZWave_SWITCH_BINARY_11 power:  0.6 W

Das finde ich seltsam, Device 0x0a ist der CODetector (alte Version ohne ZWavePlus), Device 0x0b ist eine Funkschaltsteckdose von Devolo, diese hat wohl die Klasse METER.

Routet die Steckdose die Message vom CO-Detector 'aufbereitet' weiter ? Im Log der Funksteckdose finde ich zu diesem Zeitpunkt keinen Eintrag.

Gruß

Peter

[A.Harrenberg]

Hi,

kannst Du bitte mal ein

Code Auswählen Erweitern

list Z_CODetector
machen und den Output posten (In "code-tags", das ist die Schaltfläche mit dem "#")?

Und bitte einen größeren Ausschnitt aus dem logfile.

Gruß,
Andreas.

[A.Harrenberg]

Hi,

also laut dem Eintrag in der Datenbank der ZWave-Alliance hat das Ding nur die folgenden Klassen

Model: CO Detector (ZS6301EU-5)
Z-Wave Certification Number: ZC10-15110003
Supported Command Classes

        Association
        Association Group Information
        Battery
        Device Reset Local
        Firmware Update Meta Data
        Manufacturer Specific
        Notification
        Powerlevel
        Security
        Version
        Wake Up
        ZWavePlus Info


Controlled Command Classes

        Basic

Wenn Dein "list" eine Klasse METER anzeigt dann ist da bei der Inklusion was schief gelaufen (oder der Eintrag in der Datenbank stimmt nicht).

Ich habe auch noch mal nachgeschaut, die METER Klasse ist nur für den Verbrauch von POWER/WATER/GAS gedacht, nicht für irgendwelche Konzentrationen. Daher würde es auch wenig Sinn machen wenn das Ding die METER Klasse unterstützen würde.

Eigentlich sollte alles über die NOTIFICATION Klasse ablaufen. Die Klasse wurde von SIGMA mal umebenannt und heißt in FHEM aus Kompatibilitätsgründen weiterhin ALARM.
Über die Assoziation sollte es dann möglich sein auch eine on/off Befehle an die assozierte Node zu verschicken. Der Controller braucht diese Info eigentlich nicht, er sollte die ALARM/NOTIFICATION bekommen.

Gruß,
Andreas.

P.S.: Wie testet man so ein CO-Detector eigentlich??

[PeterCu]

Listing:
Internals:
   DEF        ec1e939c 10
   IODev      zvision
   NAME       Z_CoDetector
   NR         48
   STATE     
   TYPE       ZWave
   homeId     ec1e939c
   nodeIdHex  0a
   Readings:
     2017-02-17 06:17:04   UNPARSED        COLOR_CONTROL 0e3302213400000000000000000000
     2017-02-17 15:20:51   neighborList    zvision Z_Repeater
     2017-02-16 05:27:03   power           6553.6 W
     2017-02-18 05:14:04   undef           0.1 undef
Attributes:
   IODev      zvision
   classes    SENSOR_BINARY ALARM MANUFACTURER_SPECIFIC VERSION ASSOCIATION BATTERY WAKE_UP
   room       Erdgeschoss,Sicherheit,ZWave
   verbose    5

CO-Detector testen ? Funktionstest im Prinzip wie ein Rauchmelder, Taste drücken, dann wird er laut, sollte auch eine Message an die den Controller senden, aber die kommt nie an ... da stimmt halt was nicht. Den echten CO-Alarm konnte ich (zum Glück) noch nicht testen.

[A.Harrenberg]

Hi Peter,

also mir fällt auf das Du kein Reading vclasses hast, kein Reading mit der model id und auch keine SECURITY Klasse hast.

Um welches Geräte handelt es sich GENAU, dh. ist es der von mir gefundene oder vielleicht ein älteres Model davon.

Ist Dein FHEM aktuell? Wann hast Du das Gerät inkludiert?

Die Readings Power und "Undef" kommen aus der METER Klasse die das Ding ja gar nicht hat...

Kann es sein das Du vielleicht Übertraungsprobleme hast und das da kaputte Pakete (mit intakter Checksumme, ja das gibt es leider da die Checksumme sehr einfach gebildet wird) ankommen und ausgewertet werden?

CO-Detector testen ? Funktionstest im Prinzip wie ein Rauchmelder, Taste drücken, dann wird er laut, sollte auch eine Message an die den Controller senden, aber die kommt nie an ... da stimmt halt was nicht. Den echten CO-Alarm konnte ich (zum Glück) noch nicht testen.

Na das ist ja nur eine "elektrischer" Test... Für Rauchmelder gibt es ja Testspray oder besondere Streichhölzer mit denem man die "echte" Erkennung über den Sensor testen kann. Für CO wäre das ja keine so gute Idee... Daher die Frage wie man so ein Ding "real" testet. Keine Ahnung wie empfindlich der reagiert, dann könnte man evtl. in einen Beutel atmen... Aber der Mensch produziert denke ich eher CO2 und so gut wie kein CO...

Gruß,
Andreas.

[PeterCu]

Hallo Andreas,
es handelt sich um das Modell ZS6301 (altes Modell) nicht um die neue Variante ZS6301EU-5.
Ich habe inzwischen (dank verbose 5 beim Dongle) fast die Funksteckdose von Devolo in Verdacht, ich werde den CO-Sensor mal direkt neben dem Dongle platzieren und sehen, ob sich die Messages ändern.
Gruß
Peter

PS: Einen echten Funktionstest mit CO habe ich noch nicht gemacht, ich hoffe nur, dass er sensibler auf meinen Kamin reagiert als ich.

[A.Harrenberg]

Hi Peter,

trotzdem nochmal die Frage ob Dein FHEM aktuell ist und wann Du das Gerät inkludiert hast? Bei aktuellem FHEM und einer "neuen" Inklusion sollten dort die von mir angesprochenen Readings sein. (Bei aktuellem FHEM aber inklusion vor langer Zeit könnten die auch noch fehlen...)

Ich denke nicht das die "0b" in dem Logfile wirklich darauf hindeutet das die Steckdose dazwischengefunkt hat. Das Routing kriegt man mMn auf der Protokollebene gar nicht mit und soweit ich mich erinnere ist die ID bei den Controllerantworten NICHT die Node-ID sondern Teil der Nachricht, was aber an der Stelle wo die Ausgabe gemacht wird nicht unterschieden wird.

Interessant wäre ob Du im Logfile von Fhem (also nicht in den einzelnen Logfiles) Hinweise wie NO_ACK, CAN, device not responding findest die auf Übertragungsfehler hinweisen könnten.

Gruß,
Andreas.

[PeterCu]

fhem 5.7
Das Gerät habe ich im Januar inkludiert, aber auch schon mal vor 2 Jahren, allerdings ist die NodeID neu, somit sollte die alte Konfiguration hinfällig sein.
Der CO-Sensor liegt jetzt neben dem Dongle, mal sehen, ob sich da etwas ändert. Der State ist nicht belegt, somit auch kein TRANSMIT_NO_ACK.

[PeterCu]

OK, Problem ist wohl die Funkdose, neben dem Dongle sieht die Meldung so aus:

alarm
CO: Event cleared: detected, Unknown Location
2017-02-18 15:57:13

[A.Harrenberg]

Hi,

dann bleibt aber nur das die Funksteckdose völlig kaputte Pakete losschickt die dann zufällig dem CO-Detektor zugewiesen wurden da sowohl Node-ID als auch der Inhalt nicht i.O. ist. Dann müsste aber bei der Steckdose auch mal ein NO_ACK oder retry im Log zu erkennen sein. Falls der Steckdosenschalter die Nachricht beim Routen kaputt macht (keine Ahnung wie man das nachweisen sollte...) würde ich den aber ziemlich weit werfen...

Gruß,
Andreas.