Aeon Labs Z-Wave Multisensor 6 (AEOEZW100) Probleme beim Anlernen

[krikan]

Ich zitiere mal Andreas:

Falls Du das Gerät mit USB betreibst sollte das Ding eigentlich immer "an" sein und nicht schlafen gehen, dann müsstest Du allerdings zwingend das "WakeUP" aus dem Attribute "classes" entfernen und die Config speichern, damit FHEM das Gerät dann als normales Netzbetriebenes Gerät betrachtet.

Meinen Hinweis dazu findest Du ein paar Beiträge höher und der verwies doch glatt auf den Anfang dieses Threads  .

[A.Harrenberg]

Hi,

mach mal ein "list ZWave_SENSOR_MULTILEVEL_6", da dürften dann jede Menge alte Befehle hinter "WakeUp:" stehen. Um die zu löschen ist es am einfachsten erst einmal "Save Config" in FHEM zu machen und FHEM danach neu zu starten.

Anschliessend würde ich das "Wake_UP" aud dem Attribut "classes" löschen, dann wieder "Save Config" und FHEM zur Sicherheit noch mal neu starten.

Danach sollte es dann aber funktionieren...

Gruß,
Andreas.

[A.Harrenberg]

Hi,

Hab mittlerweile  8 Eintraege im Nodelist ..

was sind das denn für Einträge? Sind das alles (alte) Einträge von dem Sensor? Gibt es noch "passende" Devices in FHEM oder existieren nur die Einträge in der Nodelist vom Controller?

FRAGE:
Die Werte holt er doch wohl per Funk ?

Ja, natürlich per ZWave, eine Übertragung per USB ist an der Stelle nicht möglich...

Gruß,
Andreas.

[harway2007]

nach x Neustarts:
am USB ohne den wakeup - alles programmierbar
hab schon x readings ausgelesen und per notify ausgwertet aber bei:
alarm HomeSecurity: Motion Detection, Unknown Location, arg 0000
des Sensor scheitere ich ...
wie habt ihr den Alarm ausgewertet ?

[harway2007]

 
gefunden hab ich:
ZWave_SENSOR_MULTILEVEL_8:basicSet..ff set MyTTS tts ein Hinweis vom neuen Sensor
.. löst bei Motion aus .. der klappt .. verstehe nicht warum .. der Tip Stand im
https://groups.google.com/forum/#!topic/fhem-users/ePuDQFgpZ1s von 10.2012 !

MFG Harway

[A.Harrenberg]

Hallo Rudi,

ich habe mir jetzt auch so einen Sensor zum Testen zugelegt und habe gleich mal zwei Probleme damit...

1.) Das Ding meldet sich auch mit WAKE_UP Class wenn es per USB angeschlossen ist und in dem Zustand angelernt wird. Man muss dann manuell die Klasse entfernen und FHEM neu starten. Leider habe ich keine passenden Batterien (sind leider diese CR123A Spezialbatterien) für den Sensor, kann also momentan nicht ausprobieren ob der Sensor irgendwas meldet wenn man den USB-Strom entfernt oder anschliesst. Hier wäre interessant ob der Sensor USB und Batteriebetrieb im listening-bit unterscheidet. Hier müssen wir dann evtl. nicht nur auf das Vorhandensein der Klasse prüfen sondern auch irgendwie das Listening-bit abfragen...

2.) Nach dem autocreate des Device geht FHEM durch das Vorhandensein der WakeUP-class erst mal davon aus das der Sensor batteriebetrieben ist UND der WU-Sendstack ist sofort aktiv! D.h. alle Befehle nach der Inklusion landen erst mal im Sendstack, dadurch funktioniert die Inklusion mit Security auch nicht.

Ich schau mir das zweite Problem am Sonntag mal an, hierfür sollte sich ein einfacher Workaround finden lassen der das Gerät nach/während der Inklusion erst mal als "wach" deklariert und den Sendstack damit abschaltet, damit wenigstens erst mal die erste Kommunikation durchlaufen kann.

Das erste Problem kann ich mir erst richtig ansehen wenn ich auch Batterien für den Sensor habe, sind bestellt, das dauert aber noch ein paar Tage, ist aber auch nicht wirklich dringend...

Das alles nur zur Info, da ich mir für den Sendstack wegen der Steuerung für SECURITY sowieso etwas einfallen lassen muss werde ich mich darum kümmern falls das für Dich ok ist.

Gruß,
Andreas.

[rudolfkoenig]

Verstehe nicht genau, was du von mir erwartest: soll ich die Spezialbatterien suchen, oder in deinem fhem.cfg WAKE_UP loeschen?

[A.Harrenberg]

Hallo Rudi,

Verstehe nicht genau, was du von mir erwartest: soll ich die Spezialbatterien suchen, oder in deinem fhem.cfg WAKE_UP loeschen?

also die Batterien sind bestellt und sollten den Weg zu mir finden, da benötige ich also keine Hilfe beim Suchen.

Wie geschrieben war das wirklich nur "zur Info" gedacht. Das Geräte mit WakeUp command class nach/während der Inklusion als schlafend angesehen werden ist unschön und sollte geändert werden. Das wollte ich mir anschauen, ich muss mir aber auch noch ansehen was Du im Security Thread vorgeschlagen hast.

Das Batteriegeräte die command class WAKE_UP melden obwohl sie netzbetrieben werden ist zwar nicht so verwunderlich, da das Vorhandensein der Klasse neben dem Zeitstempel der letzten Nachricht aber aktuell das Kriterium für den Sendstack darstellt sehe ich hier auch noch ein Verbesserungspotenzial, wenn auch mit niedriger Priorität.

Gruß,
Andreas.

[harway2007]

kann man den Sensor nicht einfach an ein 5 Volt Smartphone USB Netzteil hängen ?

[A.Harrenberg]

Hi,

kann man den Sensor nicht einfach an ein 5 Volt Smartphone USB Netzteil hängen ?

klar kann man das, ist bei mir aktuell auch am Netzteil und nicht am Rechner dran.

Ich denke aber das ich am vorgesehenen Einsatzort KEINE 5V-USB zur Verfügung haben werde.

Gruß,
Andreas.

[A.Harrenberg]

Hallo Rudi,

Das Geräte mit WakeUp command class nach/während der Inklusion als schlafend angesehen werden ist unschön und sollte geändert werden.

anbei mal ein Patch mit zwei kleinen Änderungen:

1. Auslösen von ZWave_wakeupTimer in ZWave_Parse nach der Inklusion (protocolDone), damit werden WakeUp-Geräte erst mal als "wach" angensehen.
2. Ignorieren von SECURITY in der secClasses Liste -> der AEOEZW100 Sensor meldet SECURITY selbst auch als verschlüsselte Klasse, das hat zu einer unendlichen Rekursion geführt...

Mit diesen Änderungen kann ich den Sensor mit SECURITY einbinden.

Ich habe etliche Zeilen mit angehängtem Leerzeichen als Unterschied im Patchfile gehabt, daher habe ich das Patchfile  wieder manuell editiert, hoffe aber das ich es diesmal nicht "kaputt" gemacht habe...

Wegen der Änderungen am Stack überlege ich noch...

Gruß,
Andreas.

[harway2007]

  mein Sensor macht jetzt fast was ich will ..
nur der Wert von UV bleibt 0 - obwohl ich ihn heute in den Garten gelegt habe (Sonne pur)
er macht keine Updates seit
000_ZME_UZB1,ZWave  0 UV    2015-10-07 20:05:33
steht 1 5 6 7 Bit Binär in der Hilfe für 225 ?
( 1 + 32 + 64 +128) ?

Gruss Harway

[A.Harrenberg]

Hi,

mein Sensor macht jetzt fast was ich will ..
nur der Wert von UV bleibt 0 - obwohl ich ihn heute in den Garten gelegt habe (Sonne pur)

schön!
Ich habe noch gar nicht viel mit dem Ding gespielt, habe mich erst mal ein wenig um Security gekümmert. Und auf meinem Schreibtisch hat es nachts auch nur "0 UV"...

er macht keine Updates seit
000_ZME_UZB1,ZWave  0 UV    2015-10-07 20:05:33
steht 1 5 6 7 Bit Binär in der Hilfe für 225 ?
( 1 + 32 + 64 +128) ?

Du sprichst in Rätseln...

Ist das ein Teil einer Logmessage?

Code Auswählen Erweitern

000_ZME_UZB1,ZWave  0 UV    2015-10-07 20:05:33

In welcher "Hilfe" steht das?

Code Auswählen Erweitern

steht 1 5 6 7 Bit Binär in der Hilfe für 225 ?
( 1 + 32 + 64 +128) ?
(2^1 wäre 2 und nicht 1...)

Vielleicht doch mal ein wenig großzügiger umschreiben ,-)

Gruß,
Andreas.

[harway2007]

a. ja stimmt 2 ist der Wert - dann ist das Ergebnis 226

b. wenn man in der set Zeile des Sensors "configGroup1Reports"
aufruft kommt diese Hilfe:

Help for configGroup1Reports:
Which reports need to send automatically in timing intervals for group 1. Bitsets: 0 -> Battery report, 1 -> Ultraviolet, 5 -> Temperature, 6 -> Humidity, 7 -> Luminosity

der Begriff "Bitsets" brachte mich auf die Idee

MFG Harway

[A.Harrenberg]

Hi,

ja, an der Stelle ist das richtig so. Mit 226 sollten dann alle verfügbaren Werte übertragen werden.

Allerdings scheint da in der Config von dem Sensor noch einiges nicht i.O. zu sein. Wenn ich configGroup1Reports abrufe wird ein Reading configLuminanceReportThreshold (mit dem Wert 100) angelegt.

@Krikan: Kannst Du was dazu sagen woher diese Namen kommen? Stammen die aus dem XML oder aus dem FHEM-Code?

Gruß,
Andreas.