EZMotion 3-in-1 / SENSOR_MULTILEVEL / WAKE_UP Patches

Begonnen von rudolfkoenig, 28 Dezember 2013, 17:10:13

Vorheriges Thema - Nächstes Thema

rudolfkoenig

Ich versuche gerade ein EZMotion 3-in-1 besser mit FHEM bekanntzumachen, und habe deswegen SENSOR_MULTILEVEL Parse vervollstaendigt, es dekodiert jetzt alle mir bekannten 22 Typen.

Weiterhin habe ich ermoglicht, dass man bei einem wakeup: notification per notify an die angeschlossenen Kanaele ein GET (smStatus) senden kann, was sofort abgearbeitet werden sollte, das sollte alle batteriebetriebenen Geraete betreffen.

Ich wuerde mich freuen wenn mir jemand erklaert, wie man das o.g. Geraet dazu noetigt, eine Nachricht bei Bewegung loszuschicken. Bisher ist es nur ein etwas beschraenkter Temperatur und Lichtsensor. Der Sensor funktioniert: es blinkt sofort bei jeder Bewegung.

Mx112

Zitat von: rudolfkoenig am 28 Dezember 2013, 17:10:13
Weiterhin habe ich ermoglicht, dass man bei einem wakeup: notification per notify an die angeschlossenen Kanaele ein GET (smStatus) senden kann, was sofort abgearbeitet werden sollte, das sollte alle batteriebetriebenen Geraete betreffen.
Gibt es da jetzt was zu beachten? Ich hab im comandref part des Modules im SVN auf die schnelle nichts gefunden. Bisher funktioniert

DEF KG.k1.EM.Sicherungskasten:wakeup.* get KG.k1.EM.Sicherungskasten config 9

ganz gut. Damit hole ich den pulse count des Stromzählers ab. Kann aber sein das ich damit ein Wakeup Zyklus Versatz habe was zu unschönen plots führt. Zu mehr mache ich ggf. einen neuen Thread auf.
Zitat
Ich wuerde mich freuen wenn mir jemand erklaert, wie man das o.g. Geraet dazu noetigt, eine Nachricht bei Bewegung loszuschicken. Bisher ist es nur ein etwas beschraenkter Temperatur und Lichtsensor. Der Sensor funktioniert: es blinkt sofort bei jeder Bewegung.
Welches ist das? pepper 1 listet 2 Varianten: http://www.pepper1.net/zwavedb/?filter_manufacturer=83

Das sieht so aus als wenn der Melder direkt mit einem Aktor assozieiert werden muss da er einen Einschaltbefehl bei Bewegung sendet.
Könnte gut sein das der ZWDongle den Befehl dann ignoriert wenn er assoziiert ist.
FHEM 5.5 SVN - FB7390 FRITZ!OS 06.03 - RaspberryPi - Z-Wave - FBDECT

rudolfkoenig

pepper 1 listet 2 Varianten:

Ich verstehe den Unterschied nicht zwischen den beiden. Ansonsten, ja, so schaut das Ding aus.

Könnte gut sein das der ZWDongle den Befehl dann ignoriert wenn er assoziiert ist.

Das wuerde bedeuten, dass ich ein Geraet sinnlos paaren muss, wenn ich eine Schaltung von weiteren Bedingungen abhaengig machen will. Muss ich wohl ausprobieren.

Off-Topic: Hast du Probleme beim gemeinsamen schalten von mehreren Geraeten?
Ich meine das geht z.Zt nicht (nur mit einem sleep dazwischen), ich versuche gerade eine bessere Loesung zu finden.

Mx112

Das sind wohl 2 Revisionen die sich in den Command Klassen unterscheiden. Der eine hat 3 Endpoints und der andere sendet Helligkeit und Temeratur über SENSOR_MULTILEVEL und Bewegung über SENSOR_BINARY.

Zitat von: rudolfkoenig am 29 Dezember 2013, 09:50:22
Off-Topic: Hast du Probleme beim gemeinsamen schalten von mehreren Geraeten?
Ich meine das geht z.Zt nicht (nur mit einem sleep dazwischen), ich versuche gerade eine bessere Loesung zu finden.

Hab ich so nicht im Einsatz, kann ich aber gerne mal probierern. Was meinst du genau? Per notify mehrere devices schalten?
FHEM 5.5 SVN - FB7390 FRITZ!OS 06.03 - RaspberryPi - Z-Wave - FBDECT

rudolfkoenig

Meine ist dann wohl "die eine".

set sb1,sb2 on
sollte schiefgehen, und nur sb1 schalten. Workaround:
set sb1 on;; sleep 0.2;; set sb2 on

Mx112

Geht bei mir beides nicht. Schaltet jeweis nur das erste device.
FHEM 5.5 SVN - FB7390 FRITZ!OS 06.03 - RaspberryPi - Z-Wave - FBDECT

rudolfkoenig

Zweiter Versuch:
- "set sb1,sb2 on" sollte jetzt gehen, fuer manche Fehler gibts jetzt auch ein resend.
- mehrere gets an batteriebetriebene Geraete scheint jetzt auch zu funktionieren.

Mx112

Zitat von: rudolfkoenig am 02 Januar 2014, 12:38:12
- "set sb1,sb2 on" sollte jetzt gehen, fuer manche Fehler gibts jetzt auch ein resend.

Geht. Jetzt bau ich mir einen all-off Button  ;)
Zitat
- mehrere gets an batteriebetriebene Geraete scheint jetzt auch zu funktionieren.

Wie ist das gemeint?

get devicename battery,wakeupInteral

meldet
Unknown argument battery,wakeupInterval, choose one of basicStatus battery config version wakeupInterval

Mehrere gets wurden bei mir schon immer bis zum nächsten wakeup "gesammelt".
FHEM 5.5 SVN - FB7390 FRITZ!OS 06.03 - RaspberryPi - Z-Wave - FBDECT

rudolfkoenig

Zitatget devicename battery,wakeupInteral
Nein, so war das nicht gemeint, die gets muessen weiterhin einzeln abgesetzt werden.

ZitatMehrere gets wurden bei mir schon immer bis zum nächsten wakeup "gesammelt".
Ja, aber ich kann dir nicht erklaeren, warum (wenn ueberhaupt) sie funktioniert haben.

Ich habe heute gelernt, dass der Dongle nur einen ausstehenden Auftrag haben darf, und habe deswegen eine zweite Schlange fuer ihn eingebaut, deswegen funktioniert jetzt "set sb1,sb2 on". Habe auch gelernt, dass er den Auftrag mit Cancel (18) verwerfen darf, jetzt schickt ZWave.pm das Paket erneut an ihm.

Es fehlt noch ein Zaehler um Endlosschleife zu vermeiden, und ein Timer, falls dem Dongle gar nicht zum antworten zumute ist. Aber immerhin kann ich jetzt von diesem 3in1 Geraet Temperatur und Helligkeit zuverlaessig abholen. Ich muesste ihn nur dazu ueberreden, Bewegung zu melden, ohne eine Lampe schalten zu wollen.

Mx112

#9
Das ist ja interesannt. Vieleicht handhabt das jeder Controller etwas anders. Ich weiß leider nicht genau was ich für einen habe, dem Gehäuse nach könnte es ein Goodway sein. Bin aber nicht sicher - war white gelabelt beim Strommesser dabei. Jedefalls sind meine "get config xx" bisher alle beim nächste wakeup gemeldet worden.

Was macht denn jetzt Dein Sensor? Laut pepper1 sollte er ja 3 Endpoints haben die per SENSOR_MULTILEVEL kommunizieren. Siehst Du da nur zwei? Oder 3 - wo nur einer nichts sendet? Hab leider selbst kein Device mit mehreren Endpoints und kann daher nur mit recherchen weiterhelfen.

Edit:
Das hab ich hier gefunden: http://wiki.micasaverde.com/index.php/ExpressControls3in1#Associations

Zitat
Associations allow EZMotion to directly control up to 3 devices (EZMotion supports 4 but Vera needs 1). The main advantage of direct control of a device by EZMotion is that it is very quick and it will work even if Vera is not running. This means that as soon as EZMotion detects motion, it will instantly turn on the associated devices. EZMotion will also inform Vera that motion was detected and Vera can then do more advanced event triggering.
     Click on Device Options and scroll down to Associations
    Enter "1" in the Group ID and click on Add Group
    Click on Set
        This brings up a list of other devices that can be associated. Click on no more than 3 of these. Then click on Back to ZWave Options
    Click on the Settings tab
    Click on Configure Node Right Now

To test if the associations are working, turn the associated lights off, then press EZMotions blue button while it is facing away from you and hold it steady, wait 3 seconds, then move EZMotion and the lights should turn on. If they don't, repeat the steps above.

Das sieht so aus als muss der Controller assoziert sein um die Statusmeldungen zu empfangen (... Vera needs 1 ...), (... do more advanced triggering ...).

Reicht es jetzt aus nur den Controller zu assozieren, oder muss zwingend ein weiteres Device assoziiert sein damit Nachrichten an den Controller geschickt werden?
FHEM 5.5 SVN - FB7390 FRITZ!OS 06.03 - RaspberryPi - Z-Wave - FBDECT

rudolfkoenig

Das Geraet hat 3 "Endpunkte", jeweils eins fuer Bewegung (generalPurpose), Temperatur und Licht. Und wenn es wie konfiguriert (z.Bsp zweimal pro Stunde) aufwacht, kann ich alle drei abfragen. Fuer Temp&Licht ist das ok, aber fuer Bewegung etwas albern.

Den Link habe ich auch schon gesehen&gelesen, ich habe aber keinen Aktor uebrig, den ich bei Bewegung schalten kann. Den Sensor habe ich natuerlich mit dem Controller gepaart, sowohl Assotiation Gruppe 1 als auch 2. Leider ist das Experimentieren mit Bewegung z.Zt. etwas umstaendlich, da das Geraet in einem leerstehenden Wohnung steht :)

Mx112

Und wenn Du dem einen nicht vorhanden Node assoziierst? Ich hab's grad mal probiert, bei der Assoziation wird nicht geprüft ob der Node existiert.


Sent from my iPad using Tapatalk
FHEM 5.5 SVN - FB7390 FRITZ!OS 06.03 - RaspberryPi - Z-Wave - FBDECT

timm

Mein Philio Slim Multi-Sensor PSM02-1 sendet ebenfalls bei Bewegung und Fenster-Senser lediglich Helligkeit und Temperatur. In der Anleitung steht jedoch, dass ebenfalls "unsolicited events" an Geräte in Assoziations-Gruppe 1 gesendet werden. Die Events enthalten den Sensor-Typ (Motion=0C Door=0A Tamper=08 Temperature=01 Illumination=09). Ich habe 10_ZWave.pm etwas verändert, um die reinen Event-Codes zu bekommen und erhalte nun die Fenster samt 00/ff für den Zustand sowie 0c mit ff für Bewegung.


  SENSOR_BINARY            => { id => '30',
    get   => { sbStatus    => "02",       },
    parse => { "03300300"  => "state:closed",
               "033003ff"  => "state:open",
               "04300.(..)(.*)"=> '"event_$2:$1"',



rudolfkoenig

1. wenn Patch, dann bitte mit Doku
2. laut meinem (zugegebenerweise nicht ganz neuen) Doku kann die Klasse SENSOR_BINARY beim Nachricht Report nur ein Byte mit zwei Werten (00 oder FF) senden. Kannst Du mir sagen, woher du dein Info hast?

Mx112

Ich hab jetzt hier auch einen Philio PSP01 www.pepper1.net/zwavedb/device/477 der bei Bewegung
043003ff0c sendet.

Ich vermute mal das das 0c aus der Version 2 des SENSOR_BINARY kommt. Meine Spec enthällt aber nur V1 wo nach ff Schluss ist. Was neueres finde ich leider nicht.

@Rudi:
Siehst Du eine Möglichkeit solche "Erkenntnisse" an geeigneter Stelle im Modul aufzunnehmen? Ich Verstehe das nur der Spezifikation entsprechende Funktionen im Modul drin sein sollten, aber es ist auch nicht toll nach jedem Update wieder manuell das Modul zu editieren. Daher die Idee einer "experimental" oder "undocumented" Sektion.

Die Doku dazu würde ich übernehmen.

2. Idee: Schick wäre natürich auch wenn messages die nicht vom Modul erwischt werden als reading auftauchen würden. In etwa so 043003ff0c: please implement
Das würde das reverse engeneering erleichtern


FHEM 5.5 SVN - FB7390 FRITZ!OS 06.03 - RaspberryPi - Z-Wave - FBDECT