Hallo zusammen
Ich hab gestern den aufsteckbaren Funkempfänger RaZberry für das Raspberry Pi bekommen und gleich ausprobiert.
Der Sensor (Türkontakt) wurde vom FHEM erkannt und ich hab mich auch an die folgende Anleitung im fhemwiki gehalten.
http://www.fhemwiki.de/wiki/Z-Wave
Ich habe den Controller mit dem Sensor assoziiert, so wie es dort im wiki in der Anleitung unter Assoziation steht. Hat auch funktioniert.
Jetzt wird aber der Status vom Sensor leider noch nicht erkannt. Im WebInterface von FHEM stehen da nur 3 Fragezeichen..
ZWave_SENSOR_BINARY_2 ? ? ?
Hat jemand von euch Erfahrung damit und kann mit weiterhelfen?
Ich bin sehr froh um jeden Tipp!
Danke schon mal und liebe Grüsse
Bekommst Du überhaupt irgendwelche Events?
Kannst Du bitte mal die Ausgabe von "list ZWave_SENSOR_BINARY_2" posten?
Edit: Wenn man im list nicht die Modellbezeichnung des Senors sieht, dann bitte auch angeben.
Hallo krikan, danke für die Antwort!
Also ich habe gerade jetzt den ersten closed status bekommen :)
ich hab get ZWave_SENSOR_BINARY_2 sdStatus eingestellt, dann habe ich closed zurück bekommen beim wakeup, aber dann beim nächsten wake up gleich wieder nur eine wakeup notification..? Sollt so nicht immer der Status geschickt werden, wenn das Wakeup an den Sensor gesendet wird?
2015-04-02_20:51:31 ZWave_SENSOR_BINARY_2 wakeup: notification
2015-04-02_20:51:31 ZWave_SENSOR_BINARY_2 wakeup: notification
2015-04-02_20:52:31 ZWave_SENSOR_BINARY_2 wakeup: notification
2015-04-02_20:52:31 ZWave_SENSOR_BINARY_2 wakeup: notification
2015-04-02_20:53:31 ZWave_SENSOR_BINARY_2 wakeup: notification
2015-04-02_20:53:31 ZWave_SENSOR_BINARY_2 wakeup: notification
2015-04-02_20:53:31 ZWave_SENSOR_BINARY_2 closed
2015-04-02_20:53:31 ZWave_SENSOR_BINARY_2 reportedState: closed
2015-04-02_20:54:31 ZWave_SENSOR_BINARY_2 wakeup: notification
2015-04-02_20:54:31 ZWave_SENSOR_BINARY_2 wakeup: notification
2015-04-02_20:54:31 ZWave_SENSOR_BINARY_2 closed
2015-04-02_20:54:31 ZWave_SENSOR_BINARY_2 reportedState: closed
2015-04-02_20:55:31 ZWave_SENSOR_BINARY_2 wakeup: notification
2015-04-02_20:55:31 ZWave_SENSOR_BINARY_2 wakeup: notification
Ich kann leider die ausgabe von "list ZWave_SENSOR_BINARY_2" nicht komplett posten, weil die Anzeige vom Filelog irgendwie immer erscheint und die list ausgabe überdeckt.. die erste hälfte der ausgabe ist eben hinter diesem Filelog Text versteckt..
Das was ich sehen kann sieht so aus:
2015-04-02 20:54:31 reportedState closed
2015-04-02 20:54:31 state closed
2015-04-02 20:09:25 version Lib 6 Prot 2.9 App 1.0
2015-04-02 21:04:32 wakeup notification
WakeUp:
Attributes:
classes SENSOR_BINARY CONFIGURATION WAKE_UP MANUFACTURER_SPECIFIC VERSION ASSOCIATION BATTERY MARK BASIC
room ZWave
Kann es sein dass dieser Sensor nur immer seinen zustand sendet, wenn ein Wakeup kommt, und nicht auch zwischendurch von sich aus?
Zitat von: Melissa am 02 April 2015, 21:10:25
ich hab get ZWave_SENSOR_BINARY_2 sdStatus eingestellt, dann habe ich closed zurück bekommen beim wakeup, aber dann beim nächsten wake up gleich wieder nur eine wakeup notification..? Sollt so nicht immer der Status geschickt werden, wenn das Wakeup an den Sensor gesendet wird?
Wenn Du den Sensor manuell mit get abfragst, wird das einmalig bei der nächsten wakeup-notification verarbeitet und beantwortet. Oder hast Du das automatisiert (at)
Zitat von: Melissa am 02 April 2015, 21:10:25
Kann es sein dass dieser Sensor nur immer seinen zustand sendet, wenn ein Wakeup kommt, und nicht auch zwischendurch von sich aus?
Eher ungewöhnlich. Normalerweise sollte bei jeder Zustandsänderung eine Nachricht kommen, wenn die Assoziationen korrekt gesetzt sind. Was hast Du für einen Sensor. Leider kann ich das nicht erkennen, da Du "get ZWave_SENSOR_BINARY_2 model" nicht abgefragt hast.
Danke noch mal!
Nein wenn das so ist hab ich das nicht automatisiert.
Hab gedacht, dass wenn ich das eingebe dass das dann irgendwo gespeichert ist, und so immer den status schickt..
Wenn ich get ZWave_SENSOR_BINARY_2 model eingebe, bekomme ich folgende Meldung:
Unknown argument model, choose one of association basicStatus battery config sbStatus version wakeupInterval
Aber ich hab einen Türkontakt von EMINENT e-DOMOTICA
Für die Assotiation habe ich Set ZWave_SENSOR_BINARY_2 associationAdd ZWAVE1 1 eingegeben
Bin mir aber nicht 100% sicher, ob das korrekt ist. Also "ZWAVE1" heisst mein Controller bestimmt, aber die "1" habe ich vom wiki so übernommen.
Die Einstellungen vom Sensor sehen so aus:
Internals:
DEF ec706ew6 2
IODev ZWAVE1
LASTInputDev ZWAVE1
MSGCNT 198
NAME ZWave_SENSOR_BINARY_2
NR 49
STATE closed
TYPE ZWave
ZWAVE1_MSGCNT 198
ZWAVE1_RAWMSG 00040002028407
ZWAVE1_TIME 2015-04-02 21:31:36
homeId ec706ew6
id 02
Readings:
alarm_type_01 level 11 2015-04-02 19:36:14
assocGroup_01 Max 05 Nodes 01 2015-04-02 19:55:22
basicReport 00 2015-04-02 20:47:31
reportedState closed 2015-04-02 20:54:31
state closed 2015-04-02 20:54:31
version Lib 6 Prot 2.9 App 1.0 2015-04-02 20:09:25
wakeup notification 2015-04-02 21:31:36
Also der state bleibt jetzt immer auf closed, der ändert sich nicht.. :(
Muss ich da evtl noch andere Assotiationen setzen oder irgend eine Konfiguration machen?
Zitat von: Melissa am 02 April 2015, 21:38:12
Hab gedacht, dass wenn ich das eingebe dass das dann irgendwo gespeichert ist, und so immer den status schickt..
Nein, das ist eine einmalige Abfrage. Normalerweise wird der Zustandsreport bei den mir bekannten Sensoren in den Standardeinstellungen regelmäßig gesendet. Ansonsten kann man das typischerweise konfigurieren.
Zitat von: Melissa am 02 April 2015, 21:38:12
Wenn ich get ZWave_SENSOR_BINARY_2 model eingebe, bekomme ich folgende Meldung:
Unknown argument model, choose one of association basicStatus battery config sbStatus version wakeupInterval
Bitte mache ein update von Fhem (update ins Befehls-Eingabefeld von Fhem eintippen); scheinst eine alte Verssion zu nutzen.
Zitat von: Melissa am 02 April 2015, 21:38:12
Muss ich da evtl noch andere Assotiationen setzen oder irgend eine Konfiguration machen?
Kann gut sein, dazu Anleitung genau durchlesen. Hast Du einen Link?
Ok, hab update eingeben. Der Befehl "get ... model" hat leider immer noch nicht funktioniert.
Oder muss ich evtl noch ein Neustart machen?
Ja ich habe hier denk Link:
http://www.fhemwiki.de/wiki/Z-Wave
Das was unter dem Punkt Konfiguration steht, hab ich nicht gemacht. Mir fehlen die <Parameternummer> und der <Parameterwert>. Die hab ich nicht bekommen weil der model Befehl nicht funktioniert..
Aber wenn ich die Anleitung richtig verstehe ist einfach die Assozitation wichtig.
Ich bekomme ja auch den Status, aber nur wenn ich die Abfrage starte. Und komischerweise ist der status immer closed, nie open, auch wenn ich ihn öffne..?
Muss ich da evtl noch was ins fhem.cfg file eintragen?
Danke
Neustart="shutdown restart" ist zwingend, sonst wird das update nicht aktiv. Bitte vorher Save config anklicken. Danach muss auch "get ... model" funktionieren. Mich interessiert die Ausgabe von get model für Deinen Sensor. Ich finde in den bekannten Datenbanken (pepper1,zwave,..) keine Infos zu dem Sensor. Auch das Handbuch des Herstellers liefert NULL-Zwave-Infos. Wenn das nicht ein umgelabelter Sensor eines anderen Herstellers ist, wirst Du ohne die Parameter für die Konfiguration wenig Freude haben.
Von der fhem.cfg lass bitte unbedingt die Finger. Die brauchst Du nicht direkt bearbeiten, da alles mittlerweile über Fhemweb geht. Machst Dir sonst das Fhem-Leben unnötig schwer.
Ah super, danke, jetzt klappts mit dem model
Internals:
DEF ec706ea6 2
IODev ZWAVE1
LASTInputDev ZWAVE1
MSGCNT 15
NAME ZWave_SENSOR_BINARY_2
NR 49
STATE closed
TYPE ZWave
ZWAVE1_MSGCNT 15
ZWAVE1_RAWMSG 00040002028407
ZWAVE1_TIME 2015-04-02 22:31:42
homeId ec706ea6
id 02
lastMsgTimestamp 1428006702
Readings:
2015-04-02 22:26:52 CMD ZW_APPLICATION_UPDATE
2015-04-02 22:26:49 alarm_type_01 level 11
2015-04-02 19:55:22 assocGroup_01 Max 05 Nodes 01
2015-04-02 22:21:05 basicReport 00
2015-04-02 22:25:42 model Everspring SM103 Door/Window Sensor
2015-04-02 22:25:42 modelConfig everspring/sm103.xml
2015-04-02 22:25:42 modelId 0060-0202-0001
2015-04-02 22:07:41 reportedState closed
2015-04-02 22:07:41 state closed
2015-04-02 22:25:42 transmit OK
2015-04-02 22:02:40 version Lib 6 Prot 2.9 App 1.0
2015-04-02 22:31:42 wakeup notification
WakeUp:
13020272040502
Attributes:
IODev ZWAVE1
classes SENSOR_BINARY CONFIGURATION WAKE_UP MANUFACTURER_SPECIFIC VERSION ASSOCIATION BATTERY MARK BASIC
room ZWave
get ZWave_SENSOR_BINARY_2 model gibt:
2015-04-02 22:32:42 ZWave ZWave_SENSOR_BINARY_2 wakeup: notification
2015-04-02 22:32:42 ZWave ZWave_SENSOR_BINARY_2 modelConfig: everspring/sm103.xml
2015-04-02 22:32:42 ZWave ZWave_SENSOR_BINARY_2 modelId: 0060-0202-0001
2015-04-02 22:32:42 ZWave ZWave_SENSOR_BINARY_2 model: Everspring SM103 Door/Window Sensor
Was wäre jetzt hier wohl die Parameternummer und der Parameter Wert?
Kenne den Sensor von Everspring nicht, kann also auch nur tippen. Immerhin ist es etwas umgelabeltes. Du hast jetzt im Auswahlmenü von set Konfigurationsparameter (config...) mit Hilfe . Wähle das mal aus und versuche es zu verstehen. Ansonsten müsstest Du mal das Handbuch von Everspring suchen und durcharbeiten.
Was mir auffällt: Laut openzwave nutzt Dein Sensor die Class ALARM, verschickt diese Info aber nicht ans Gateway. Vielleicht ist das schon die Lösung: Bitte ergänze zuerst das Attribut classes um ALARM und probiere, ob der Status dann kommt.
@krikan: kennst du einen bestaetigten Fall, wo das Geraet bei der Inklusion nicht alle seine unterstuetzten Klassen erzaehlt hat? Ich war am Anfang sehr unsicher, nur deswegen ist class ein Attribut und kein Reading.
Keine eigene Erfahrung mit meinen Devices, aber:
Kenne das aus den openzwave-Infos (wie hier im XML) und aus der Pepper1-Datenbank, dort finden sich häufiger Einträge, dass Klassen nicht im NIF enthalten sind. Openhab hat sogar die Klassen in den Config-XMLs komplett erfasst (https://github.com/cdjackson/HABmin2/wiki/Z-Wave-Product-Database) Meine auch, wir hatten vor Kurzem hier einen Fall, bei dem BASIC manuell hinzugefügt werden musste; finde das gerade aber nicht. Darum hatte ich auch schon überlegt die Infos aus den Config-XMLs zu den Classes mit in Fhem automatisch zu berücksichtigen. Es dann aber verworfen, da mir zuviel Automatik, oder siehst Du das anders?
Beim AeonLabs MulitSensor mit USB- und Batteriebetrieb ist die Attributlösung hilfreich. Hatten wir hier vor Kurzem: Durch Löschen der WAKE_UP Class aus dem Attribut ist Nutzung einfacher/besser. Aus den NodeInfos http://forum.fhem.de/index.php/topic,34505.msg268810.html#msg268810 konnte ich den USB-Anschluss nicht erkennen, um das ohne Änderungen am Attribut zu erreichen.
Darum aus meiner Sicht: Attributlösung bei "classes" ist korrekt.
@krikan: Vielen Dank für den Tipp! Also ich soll im fhem.cfg File die Zeilen
attr ZWave_SENSOR_BINARY_2 classes SENSOR_BINARY CONFIGURATION WAKE_UP MANUFACTURER_SPECIF$
mit ALARM ergänzen, sehe ich das richtig?
Also bisher habe ich einige kleinere Erfolge gehabt.
Wenn ich get ZWave_SENSOR_BINARY_2 sbStatus eingeben, bekomme ich bei einem wakeup das an den Sensor geschickt wird, den Status open oder closed zurück.
Diese open und closed Status habe ich dann mit einem notify verknüpft, welches dann erfolgreich ausgeführt wird.
Aber leider nur immer wenn ich das einmalig mit dem oben erwähnten get Befehl einstelle. Und leider nicht zu jeder Zeit, wenn ich den Sensor bewege.
Im Eventmonitor bekomme ich folgendes, wenn ich den Sensor bewege:
2015-04-04 11:53:15 ZWave ZWave_SENSOR_BINARY_2 basicReport: ff
2015-04-04 11:53:17 ZWave ZWave_SENSOR_BINARY_2 basicReport: 00
2015-04-04 11:53:17 ZWave ZWave_SENSOR_BINARY_2 basicReport: ff
2015-04-04 11:53:19 ZWave ZWave_SENSOR_BINARY_2 basicReport: 00
Ich habe versucht das notify auf diesen "basicReport: 00" einzustellen mit
define act_zwave_2 notify ZWave_SENSOR_BINARY_2:basicReport: 00 {system("sudo /pfad/zum/skript.sh &")}
Klappt wohl nicht, wegen dem Leerschlag.. Und auch mit
define act_zwave_2 notify ZWave_SENSOR_BINARY_2:00 {system("sudo /pfad/zum/skript.sh &")}
Hats nicht funktioniert.
Das sollte doch aber irgendwie so klappen, oder irre ich mich da?
Danke für eure Hilfe, und liebe Grüsse
Schaut doch gut aus; obwohl mich interessieren würde, wo Dein Problem lag, damit das im Wiki ggfs. angepast werden kann.
Im Detail:
mit ALARM ergänzen, sehe ich das richtig?Korrekt, aber laut http://www.smarthomeusa.com/product_images/h/HomeSeer/HS-SM103-1/HSSM1031_Guide.pdf zeigt das nur den Tamperalarm und hat nichts mit dem Öffnungszustand zu tuen.
open/closed wird bei Dir anscheinend über die BASIC-Class als 00=closed und FF=opend verschickt. Um das in den STATE zu packen, wo es scheinbar nicht lande (korrekt?), schau Dir das Attribut stateFormat an.
Die Abfrage mit dem notify sollte nicht notwendig sein. Leerzeichen musst Du mit einem "." ersetzen.
EDIT: open/closed geht laut Handbuch nicht allein über BASIC-Class, sondern
ZitatBasic Set Command:
Event Present:
[Command Class Basic, Basic Set, Value = 255 (0xFF)]
Event Clear:
[Command Class Switch Binary, Switch Binary Report, Value = 0x00(0)]
Verstehe ich gerade nicht...
Ahh, jetzt erst gesehen: Bitte beim Attribut classes auch BASIC ergänzen, wenn das wirklich nicht mehr drin steht. Vorher war es in Deinen list-Ausgaben drin. Es sollten im Attribut classes alle CLASS'es laut Anleitung mit den Fhem-Entsprechungen drinstehen.
Hallo Krikan, ich habs jetzt hin bekommen.
Vielen Dank für Deine Hilfe!! Bin Sehr froh dass es jetzt endlich klappt! :D
Die drei ? ? ? die ich zu Beginn hatte, waren kein Problem. Im Event Monitor hat es immer geklappt. Aber der Status wird nur mit einem
get ZWave_SENSOR_BINARY_2 sbStatus dort einmalig hin geschrieben. Aber im Event Monitor bekommt man trotzdem den reportedState: 00/ff
Dieser habe ich danach verwendet für das notify.
open/closed wird wirklich mit ff = open, 00 = closed verschickt.
Ich habe beim
Leerschlag einen
Punkt eingefügt, wie du gesagt hast, dann hats funktioniert :)
define act_zwave_2 notify ZWave_SENSOR_BINARY_2:basicReport:.00 {system("sudo /pfad/zum/skript.sh &")}Das Attribut Alarm und stateFormat habe ich nicht benötigt dazu.
Zusammenfassend, für alle die diesen Sensor (Everspring SM103 Door/Window Sensor) oder andere mit Z-Wave auch mal antreffen:
Definition vom Empfänger:
define ZWAVE1 ZWDongle /dev/ttyAMA0@115200 Ich musste die Sensoren einlesen mit
set ZWDongle_1 addNode onDann den Sensor 3 mal bewegen (Kontakt auf der Rückseite)
set ZWDongle_1 addNode offsteht auch im wiki unter Hinzufügen eines neuen Z-Wave Geräts / Inklusion
http://www.fhemwiki.de/wiki/Z-Wave
Danach Assoziation auch wider vom wiki:
set <name> associationAdd <associationGroup> <CtrlNodeId>
Konkret:
set ZWave_BINARY_SENSOR_2 associationAdd ZWAVE1 1Danach noch optional das notify welches oben beschrieben wurde.
Vielen Dank nochmal an krikan!! :)
Zitatset ZWave_BINARY_SENSOR_2 associationAdd ZWAVE1 1
Kleine Korrektur: das kann nicht funktionieren, da associationAdd zwei (oder mehr) Zahlen erwartet,
wie das auch im commandref.html steht. Sollte aber auch nicht notwendig sein, und das steht auch da:
ZitatassociationAdd groupId nodeId ...
Add the specified list of nodeIds to the assotion group groupId.
Note: upon creating a fhem-device for the first time fhem will automatically add the controller to the first association group of the node corresponding to
the fhem device, i.e it issues a "set name associationAdd 1 controllerNodeId"
Danke für den Hinweis rudolfkoenig.
Also macht es automatisch eine Assoziation und die die ich eingegeben habe war unnötig? und falsch..?
Ich verstehe das mit den Nodes noch nicht richtig..
Stimmt es, dass ich pro Node 5 Devices anhängen kann, und dann aber beliebig viele Nodes erstellen kann?
Weiss evtl. jemand wie viele Sensoren sich mit dem RaZberry einlernen lassen, und wie gross die Reichweite ist? Kann das beim Hersteller nirgends finden..
Die Frage nach der Reichweite ist etwas kniffliger.
Hast du dir den Wikipedia Artikel durchgelesen?
Zitat
Es können insgesamt 232 einzelne Geräte in einem Netz adressiert werden.
Und
Zitat
Als Resultat wird eine Funkreichweite von ca. 150 m im Freifeld erreicht. Eine Funkreichweite von 40 m in geschlossenen Gebäuden ist eine Mindestanforderung an Z-Wave-Geräte.
Aber:
Zitat
Das damit entstehende vermaschte Netz wird ebenfalls vom Primärcontroller gesteuert und die Routen bei Veränderungen des Netzes aktualisiert. Routen können sich über bis zu 4 Zwischen-Hops erstrecken
Das bedeutet, dass die Reichweite auf 4x150m erweitert werden kann :)
Mfg
Micha
P.s. Ich hoffe richtig aus der Wikipedia zitiert zu haben und kein Ärger zu bekommen
http://de.m.wikipedia.org/wiki/Z-Wave
Super, vielen Dank mich80 :)
Nein ich hab den Wikipedia Artikel nicht gelesen zuvor, aber jetzt schon.
Du hast alles richtig zitiert, danke!
Wuesste gerne, wie Wikipedia auf "40 m in geschlossenen Gebäuden ist eine Mindestanforderung" kommt.
Die 40m Meter gelten für Z-Wave plus zertifizierte Geräte; bei Z-Wave zertifizierten (ohne Plus) sind es nur 25m. So schreibt es zumindest Dr. Paetz, aber ohne für mich erkennbare direkte Angabe ob Innen oder Freifeld.
Angaben im Gebäude: http://zwave.de/index.php/kunena/fragen-zu-z-wave-produkten/20-500-chip-z-wave-plus#55
Jetzt würde mich nur interessieren, welche Gebäudeeigenschaft dem zugrundeliegen...
Achtung: Bei meinem Z-Wave-Plus Sensor PST02-1A mit 500er-Chip wird in der Anleitung darauf hingewiesen, dass die Vorteile von Z-wave Plus (Reichweite, 100kbps Geschwindigkeit und besserer Multi-chanel Support) nur greifen, wenn alle Geräte im Netz einen 500er-Serie-Chip haben.
Danke krikan für die ausführliche Antwort!
Das beseitigt alle meine Unklarheiten :)