Hallo zusammen,
nachdem ich hier seit etwa einem Jahr still mitlese, kam gestern mein Raspberry Pi an und erfreut sich seitdem mit einer Debian/FHEM-Installation.
Nun möchte ich mit der Automatisierung starten und habe mich für Z-Wave Plus als Funknetz der Wahl entschieden. Hier suche ich nun Fenstersensoren. Meine Anforderungen sind wie folgt:
- Zwingend Z-Wave Plus
- Breite inkl. Magnet höchstens 3,5 cm (mehr passt nicht neben meine Fensterrahmen)
Leider erkenne ich bei vielen Sensoren nicht, ob sie Z-Wave Plus oder "nur" normal Z-Wave unterstützen. Z.B. werden bei dem Katalog der Z-Wave Alliance (http://products.z-wavealliance.org/regions/1/categories) die Fibaro-Fenstersensoren mit der gleichen Typbezeichnung einmal als Z-Wave Plus und einmal als Z-Wave aufgeführt.
Ich habe daher erst einmal den Fenstersensor von Vision (VISEZD2102-5) ins Auge gefasst. Nun zu meinen Fragen:
- Ich finde keine Maße des Vision-Sensors. Setzt diesen jemand ein und kann mir sagen, ob dafür 3,5 cm Platz zwischen Fenster und Wand ausreichen?
- Funktioniert der Sensor (VISEZD2102-5) komplett mit FHEM?
Alternativ:
Kann mir jemand mit FHEM gut funktionierende Z-Wave Plus-Sensoren empfehlen, die in eine 3,5 cm-Lücke passen?
Vielen Dank im Voraus!
Nutzt hier niemand Z-Wave Plus-Fenstersensoren? Ich bin auch für negative Erfahrungen, die mich von einem Kauf abhalten, sehr dankbar.
Hallo!
Mir bekannte, im Handel erhältliche ZWave-Plus-Fenstersensoren:
- Philio PST02-x bzw. die entsprechenden Devolo/D-Link/Zipato,... Abkömmlinge; funktionieren mit FHEM problemlos, nutze ich; aber mit ca. 3,8 cm zu breit
- zd2102-5; funktionieren mit FHEM. Den Thread müsstest Du per SuFu finden. Maße ohne Magnet finde ich per Google, Magnet selbst aber nicht..
- Sensative Strips; interessante Sonderlösung; kaum verfügbar; Erfahrungen mit FHEM unbekannt
Fibaro Sensor mit ZWavePlus ist mWn nicht im Handel erhältlich, auch wenn seit Ewigkeiten bei der Alliance gelistet.
Aeotec hat auch einen neuen ZWavePlus Door/Window Sensor 6 im Vorlauf. Wann der kommt: ?.
Gruß, Christian
Klebt ihr die Magneten seitlich an die Fenster, so dass die Breite für beides reichen muss?
Hab bei meinen Fibaro den Magneten auf den Fensterrahmen und nur das Hauptelement daneben geklebt.
Hätte bei einigen Räumen sonst sicher auch nicht gereicht..
Wenn man sich die 2 kleinen Linien an den Seitenflächen von Gerät und Magnetkontakt anschaut, sieht das auch so gewollt aus beim Fibaro.
Sonst sind die Linien nicht parallel anbringbar.
Zitat von: Thyraz am 04 Februar 2016, 14:55:37
Hab bei meinen Fibaro den Magneten auf den Fensterrahmen und nur das Hauptelement daneben geklebt.
Hätte bei einigen Räumen sonst sicher auch nicht gereicht..
Danke für den Hinweis. Daran habe ich noch gar nicht gedacht. Das eröffnet ggf. neue Möglichkeiten.
Kurze Info zu den VISION ZD2102 Sensoren:
Größe Sensor:
9,0cm lang; 2,5cm breit; 2,2cm hoch
Größe des Magneten:
4,0cm lang; 1,2cm breit; 1,3cm hoch
Die minimal mögliche Einbausituation bei mir braucht 3,8cm - das ist dann aber ohne Luft zwischen Sensor und Magnet im geschlossenen Zustand.
Nicht optimal und ein Versehen, da ich die Löcher für den Sensor zu dicht am Fensterflügel gebohrt habe.
Alle anderen Einbausituationen mit etwas Luft haben 4,0 bis 4,5cm Platzbedarf.
Im Bild die etwas ungünstige knappe Variante (der Platz über dem Sensor ist natürlich nicht mitberecjhnet worden)
Zitat von: Spook112 am 04 Februar 2016, 21:43:12
Kurze Info zu den VISION ZD2102 Sensoren:
Größe Sensor:
9,0cm lang; 2,5cm breit; 2,2cm hoch
Größe des Magneten:
4,0cm lang; 1,2cm breit; 1,3cm hoch
Vielen Dank! Das hilft mir sehr!
Also ich habe so einen Sensative Strip seit ner Weile.
Beim Einbau muss man sich Zeit lassen da die Positionierung von Magnet und Strip schwer ist. Fand ich zumindest. Es gibt zwar eine Art Vorkleben, mit einem recht kleinem und nicht so festem Klebeband. Hat aber trotzdem etwa ne Stunde gedauert bis ich das richtig positioniert hab.
Pfrimelei gibts auch bei den Meldungen, das Teil gibt in den Readings ein alarm aus, nämlich:
alarm AccessControl: Window/Door is open, arg 0000
bei state tut sich da nichts, habs dann mittels userreadings und split zerstückelt sodass man eine verwendbare state meldung hat
status:alarm.* {(split(',', ReadingsVal("Tuer_Terrasse","alarm",""), 2))[0]},
state:status.* {(split(' ', ReadingsVal("Tuer_Terrasse","status",""), 4))[3]}
danach ists soweit sogut (:
ZitatPfrimelei gibts auch bei den Meldungen, das Teil gibt in den Readings ein alarm aus, nämlich:
Du solltest vielleicht das Attribut "extendAlarmReadings" auf 1 setzen, damit Du die Events/Readings nicht im alten Kompatibilitätsmodus für CC Alarm V1, sondern in der ausführlichen Variante bekommst.
Zitatbei state tut sich da nichts, habs dann mittels userreadings und split zerstückelt sodass man eine verwendbare state meldung hat
Dir ist bekannt, dass man den STATE mit dem Attribut stateFormat beeinflußen kann? Mir ist nicht klar, warum Du userReadings einsetzt.
Gruß, Christian
hm, wenn ich das "extendAlarmReadings" auf 1 setze, dann hab ich ein reading:
alarm_AccessControl - Window/Door is closed, arg 0000, notificationIsOn
finde das genauso unhandlich wie das erste.
denn ich will nur wissen ob open oder close. der rest von der meldung ist doch uninteressant, oder seh ich das falsch? Opne close will ich dann noch an nem notify weiterverwenden. wenn ich das mit $EVTPART zerhacke hab ich immer noch das , dabei. das hat mich jedesmal stolpern lassen. bin da leider kein perl pro sodass mir das alles einfach von der hand ginge.
was ist denn so falsch daran, wenn ich mir mit den beiden userreadings ein state erzeuge den ich einfach weiterverwenden kann?
Bitte nicht mißverstehen: Falsch habe ich nicht geschrieben und ein Perl Pro bin ich mit Sicherheit auch nicht; versuche nur Dein Vorgehen und insb. die Gründe zu verstehen. :)
Wenn Du folgendes setzt, ist das nicht genau das, was Du haben möchtest (ohne userReadings)?
attr <device> extendedAlarmReadings 1
attr <device> stateFormat {(split(/,|is /, ReadingsVal($name,"alarm_AccessControl","")))[1]}Bin mir aber nicht sicher, ob das Dein ","-Problem mitlöst, da ich das nicht begriffen habe.
Zitatalarm_AccessControl - Window/Door is closed, arg 0000, notificationIsOn
finde das genauso unhandlich wie das erste.
Geschmacksfrage.
Mit extendedAlarmReadings bekommt man zuindest für jeden Alarmtyp einen detaillierteren Event und hat separate Readings.
Gruß, Christian
na, wenn du das auseinanderschneidest, dann steht da "closed," oder halt "open,"
wenn ich dann irgendwas mit $EVENT oder $EVTPARTx mach dann hab ich da in dem ausdruck immer ein , dann muss man da wohl immer irgendwas mit (" rumbauen. hat aber nicht wirklich geklappt. nachdem ichs mit dem userreading geschafft hab und nen schönes open oder closed hatte hab ichs halt so gelassen.
bin aber offen für besseres (:
Um das userReading/$EVTPARTxs/state Thema zu umgehen, kannst Du die vom Sensor verschickte Nachricht bei Statusaenderungen von CC Alarm auf CC SENSOR_BINARY mit
Zitatset <device> configNotificationType BinarySensorReport
umstellen, dann bekommst Du AFAIK nur noch "open" und "closed" im state ohne die anderen Klimmzüge machen zu müssen.
Gruß, Christian
hm, das wäre in der tat besser, bloß der sensor kennt anscheinend configNotificationType nicht /:
Zitat von: Firefield am 11 September 2016, 16:52:22
hm, das wäre in der tat besser, bloß der sensor kennt anscheinend configNotificationType nicht /:
Warum nicht? :o
Bei modelId 019a-0003-0003 des Strips ist das vorhanden.
Und wenn ich das Handbuch lese, finde ich die Einstellung in der Konfiguration auch..
äh, ja, keine ahnung...? -_-
im dropdown ists nicht vorhanden bei eingabe von
set Tuer_Terrasse configNotificationType BinarySensorReport
kommt
Unknown argument configNotificationType, choose one of alarmnotification associationAdd associationDel configByte configDefault configLong configWord neighborUpdate powerlevel powerlevelTest returnRouteAdd returnRouteDel sucRouteAdd sucRouteDel wakeupInterval wakeupNoMoreInformation
Gibt es denn überhaupt die modelId in den readings? Hast Du einen pepper1-Link?
Laut Handbuch ist Parameter 1 auf 0 (SENSOR_BINARY_REPORT) zu setzen.
(Du kannst es auch so lassen, wie es ist, wenn es funktioniert :). Bevor ich Dich ganz verwirre :-[ )
http://www.pepper1.net/zwavedb/device/831
oder
http://www.pepper1.net/zwavedb/device/978
modellID rückt das ding leider nicht raus und der parameter war in der tat auf 1 statt auf 0. ich bastel an so klasseneinstellungen eigentlich nur rum, wenn das gerät nicht das macht was es soll.
verwirren tust du mich momentan noch nicht (: , wenn man dem teil ein einfaches open/close entlocken kann bin ich dafür zu haben. denn das ist der erste tür/fenstersensor den ich hab und ich wollte eigentlich noch ein paar
FHEM setzt den Link auf http://www.pepper1.net/zwavedb/device/831. Der andere Link ist die US-Version.
Zitat
modellID rückt das ding leider nicht raus
Dann musst Du noch mal "get <device> model" absetzen und den Sensor einmal manuell aufwecken, damit das kommt. Dann müssen auch die fehlenden configNotificationType und configLedIndication auftauchen.
Zitatparameter war in der tat auf 1 statt auf 0.
Ist eben die Standardeinstellung der Konfiguration ab Werk.
Zitatich bastel an so klasseneinstellungen eigentlich nur rum, wenn das gerät nicht das macht was es soll.
Das ist eine reine Konfigurationseinstellung, die Du nach Deinen Wünschen anpassen kannst, so wie man bspw. bei den Temperatursensoren in der Konfiguration auf Celsius umstellen kann.
Zitatwenn man dem teil ein einfaches open/close
Bis zum Beweis des Gegenteils gehe ich davon aus. 8)
schaunwamal
get <device> model
hab ich bereits gemacht und den dann aufgeweckt. ne modelid kam nicht. warum auch immer
selbiges mit version, VersionClassAll und zwavePlusInfo und auch powerlevel.
derzeit funzts ja, vielleicht erbarmt sich der sensor und gibt irgendwann seine modellid preis
Das ist seltsam. Der Strips sendet die modelId defintiv und FHEM wertet es korrekt aus.
Ich habe eben zur Sicherheit/Test einen Strips inkludiert und bekomme das:
Readings:
2016-09-11 19:46:14 CMD ZW_APPLICATION_UPDATE
2016-09-11 19:27:49 model Sensative AB Strips
2016-09-11 19:27:49 modelConfig sensative/strips.xml
2016-09-11 19:27:49 modelId 019a-0003-0003
2016-09-11 19:46:42 reportedState open
2016-09-11 19:46:42 state open
2016-09-11 19:46:16 timeToAck 0.028
2016-09-11 19:46:16 transmit OK
Dann habe ich den configNotificationType auf BinarySensorReport gesetzt. Das Ergebnis siehst Du auch oben und sollte dem Wunsch entsprechen. Also es geht. Keine Ahnung, wo bei Deinem System der Haken sitzt.
echt keine ahnung warum das bei mir nicht will.
hatte halt zu anfang nicht gleich das mit modelid, version etc gemacht, wegen dem gefummle mit der ausrichtung des magneten. da gabs dann jede menge events. evtl ging da was schief?
sieht so aus als hättest du recht unds würde bei mir auch bestimmt so gehen, wenns funktionieren würde.
daher vllt als tipp für andere user: erst in fhem einrichten, dann an der tür anbringen.
und, äh, woher bekommt man am sonntagabend auf anhieb son teil her???
Also die manufId lässt sich auch nachträglich mit "get<device> model" abrufen. Das manuelle wakeUp ist ein wenig "tricky", aber funktioniert (runden Magneten 3x innerhalb 10 Sek über runde Ende Sensor halten)
hm, in der tat. kaum macht mans richtig, schon funktionierts...
du hast recht, das aufwecken ist nicht ganz banal. dreimal tür auf zu hat da anscheinend nicht funktioniert. selbst mit dem magnet davorhalten hats erst beim ~3 mal geklappt. hatte extra gewartet bis dunkler ist damit ich die led sehe
Hallo,
ich habe einen DCH-Z110 mydlink Türkontakt gekauft. Diesen natürlich an den Fensterrahmen gebracht und in Fhem eingebunden.
Ungünstigerweise ist die Temperaturmessung am Fensterahmen nicht die Korrekte. Momentan sind Draußen Minusgrade. Der Sensor zeigt 17°C obwohl im Raum direkt gemessen um die 23°C vorhanden sind.
Angeblich kann man am Sensor einen Temperaturversatz einstellen.
Weiß denn Jemand wo man das Parameter findet?
Die Temperaturinformation direkt am Fensterrahmen ist nicht sonderlich aussagekräftig :(
Vielleicht hat jemand ein ähnliches Problem. Per Google scheint es kein Thema zu sein.
Viele Grüße
Zitat von: lestat.le am 05 Januar 2017, 20:40:40
Angeblich kann man am Sensor einen Temperaturversatz einstellen.
Woher stammt denn die "Angeblich" Info? Im Handbuch zum DCH-Z110 und den XMLs finde ich dazu nichts.
Dann könnte man sich das bspw. anpassen mit:
https://fhem.de/commandref.html#readingsChange oder
https://fhem.de/commandref.html#userReadings oder ..
Gruß, Christian
Die Info stammt von jemanden der diese Sensoren ebenfalls benutzt, allerdings mit einer Z-Wave Zentrale.
Nach langem suchen hattee ich eine Info darüber bei den Sensoren von Fibaro gefunden.
Bei den MyDlink Sensoren oder Baugleichen konnte ich nicht darüber lesen.
Hallo!
Ich greife mal diesen alten Beitrag auf, da es hier scheinbar ein paar Leute gibt, die mit den Sensative Strips schon Erfahrungen gesammelt haben.
Vor kurzem hab ich mir zwei der Strips besorgt und will diese mittels Razberry2-Aufsteckmodul auf einem RPi3 nutzen. Leider scheitere ich schon bei der Includierung der Strips.
Kann mich vielleicht hier jemand unterstützen? Ich hab's natürlich schon mit den begrenzten Möglichkeiten, die in der Anleitung dokumentiert sind. versucht, aber irgendwie klappt das nicht. Einen Reset mit 3x Magnet innerhalb 10s ans runde Ende, jeweils blinken abwarten, beim dritten mal drauf lassen und dann soll's nach ca. 10s lange leuchten, hab ich auch noch nicht geschafft. Egal was ich mache, ich bekomme beide nicht inkludiert. Jetzt bin ich mir nicht sicher, ob das Razberry2-Modul wirklich kompatibel ist. Die SuFu und Google spucken dazu leider nichts brauchbares aus - zumindest hab ich noch nichts dazu gefunden.
Welches GW benutzt ihr dazu und hattet ihr auch kleinere oder grössere Probleme damit?
Zugegeben - in Sachen Z-Wave bin ich noch Neuling, allerdings hab ich einen Bewegungsmelder von Devolo schon mal erfolgreich inkludieren können - die Basis funktioniert also grundsätzlich.
hm, also das anmelden war kein prob, selbst mit der minianleitung nicht.
hast das razberry auf anmelden gestellt und autocreate an? hab das razberry allerdings aufm rpi2.
Erst mal Danke für deine schnelle Maldung zu meinem Problem!!
Ich hab autocreat nicht explizit aktiviert, aber das ist auch die Standardeinstellung. Der Bewegungssensor wurde jedenfalls automatisch erkannt und auch so eingebunden, damit würde ich behaupten, dass das soweit i.O sein sollte.
Mit anmelden meinst du sicher, ob ich im GW (Device "ZW_Dongle") dann "set <device_name> addNode on" bzw. "set <device_name> addNode onNW" aktiviert habe. Klar hab ich das gemacht - mit beiden Varianten, wobei ich mir halt nicht sicher bin, ob dann auch die Strips jeweils im "Anmelde-Modus" standen, da sie mir ja auch einiges Rätselraten aufgeben. Ich dachte - zumindest sagen das die Youtube-Clips - sollte ein Reset dazu führen, dass sie dann wieder neu angemeldet werden können - sprich nach Reset-Prozedur und folgendem Wake-Up, nachdem das GW im Anmelde-Mode steht. Ob das auch ohne vorherigem Reset klappt, weiss ich nicht.
Zur Info noch - die Anmeldung mit dem Bewegunssensor hat auch nicht auf Anhieb geklappt, da ich den schon vor der Aktivierung des GW in den Anmelde-Modus gebracht hatte. Nach einem Reset des Sensors hat's aber recht schnelle funktioniert.
Vielleicht liegt's auch noch an der Entfernung. Der RPi ist im Keller und der Versuch, u.a. die Strips anzumelden, erfolgt im EG mit ca. 5..6m Entfernung. Keine Ahnung, ob das schon zu viel sein könnte.
Was steht denn im Event-Monitor beim Includieren?
da kommt leider nichts weiter...
2018-03-09 08:42:28 ZWDongle ZW_GW addNode on
2018-03-09 08:42:28 ZWDongle ZW_GW ZW_ADD_NODE_TO_NETWORK learnReady
bzw.
2018-03-09 08:43:38 ZWDongle ZW_GW addNode onNw
2018-03-09 08:43:38 ZWDongle ZW_GW ZW_ADD_NODE_TO_NETWORK learnReady
Beim Anlernen des Bewegunsmelders kam natürlich mehr und da war's auch klar, da per autocreate das neue device angelegt wurde.
Ich hab übrigens gestern noch versucht, einen Devolo-Soundgeber anzulernen und da bin ich auch gescheitert - zumindest bisher.. - hatte aber um elf Uhr abends keine große Motivation mehr, dem auf die Spur zu gehen. Ob der Bewegunssesnor auch funktional tut, bin ich mir im Moment auch nicht sicher. Der sollte eigentlich kurz rot aufleuchten, wenn er auslöst - tut er aber grad nicht und damit weiss ich nicht, ob damit überhaupt in FHEM was ankommt.
Wenn ich "get ZW_GW nodeList" ausführe, bekomme ich aber zumindest das includierte Gerät angezeigt ZW_GW nodeList => ZW_GW BewSensHT
Das alles ist grad recht unzufriedenstellend, da ich echt keinen Dunst hab, ob's jetzt an FHEM, dem Modul, an den noch nicht inkludierten Geräten, dem Razberry2, oder oder... liegt. Wahrscheinlich liegt's am Device zwischen den Ohren... ???
Habt ihr eine Idee, wie man dem auf die Spur kommen kann?
ZitatBeim Anlernen des Bewegunsmelders kam natürlich mehr und da war's auch klar, da per autocreate das neue device angelegt wurde.
Jetzt bin ich verwirrt. Wir haben eben von den Sensative Strips gesprochen, nicht von Bewegungsmeldern?
Was genau hast du jetzt gemacht? Die Strips sind includiert und per Autocreate angelegt? Wenn nein, dann einmal machen. Was steht dann im Eventlog?
ZitatIch hab übrigens gestern noch versucht, einen Devolo-Soundgeber anzulernen und da bin ich auch gescheitert
Kümmere dich doch erst mal um ein Problem, bevor du mehrere Baustellen gleichzeitig hast. So wird es nur unnötig kompliziert den Fehler zu finden.
Ein list auf dein GW kann vielleicht auch nicht schaden.
Edit:
Das Wiki hast du berücksichtigt? https://wiki.fhem.de/wiki/Z-Wave#Autocreate_des_Gateways
Besonders:
Zitat
Z-Wave.Me Razberry in Verbindung mit Raspberry Pi (1. Generation: Z-Wave, 2. Generation: Gen5-Razberry mit Z-Wave Plus[2])
Die seriellen Schnittstelle /dev/ttyAMA0 muss am Raspberry Pi freigeschaltet werden, damit das Razberry-Modul funktionsfähig ist: Beitrag)
Beim Raspberry Pi 3 muss der GPIO-Port auf den Hardware-UART0 umgestellt werden: Raspberry Pi 3: GPIO-Port Module und Bluetooth
Sorry für die Verwirrung... - vielleicht hab ich's bisschen zu kryptisch beschrieben...
Es geht ganz klar um die Sensative Strips, die sich nicht includieren lassen.
Die Info zum Bewegungsmelder sollen nur sagen, dass ich schon mal erfolgreich ein Device per autocreate einbinden konnte.
Das bedeutet implizit, dass das Razberry-Modul auf jeden Fall schon funktioniert hat.
Deinen Link auf die Besonderheit des Razberry-Moduls habe ich bereits gesehen und genau so erfolgreich durchgeführt. Lediglich das Update habe ich bisher nicht gemacht, da darin auch steht, dass es nur bei Bedarf sein muss. Konkret habe ich die Schritte 3, 4 und 5 bisher nicht gemacht, u.a. da ich BT auf dem RPi bisher nicht verwende.
Den Soundgeber wollte ich nur testweise versuchen zu inkludieren, um generell zu checken, ob's an den Strips liegt. Da ich aber nun aus der Tatsache, dass sich dieser bisher auch nicht zufügen liess und ich beim bereits erfolgreich includierten Bewegunsenor nicht sicher bin, ob die Funktion dessen selbst und wenn ja, der dann in FHEM auch über das Razberry-Modul aktuell funktioniert, überhaupt in der Lage bin, die Strips zuzufügen oder ich vielleicht ein ganz anderes Problem habe, tappe ich grad im Dunkeln.
Zur Info noch - meine FHEM-Installation ist aktuell ca. ein Monat alt. Ich hatte davor schon eine lauffähige Installation auf dem RPi mit FHEM 5.7, jedoch habe ich mir bei einem manuellen Eingriff die SD-Karte mechanisch geschrottet. Bei der Neuinstallation wurde grad FHEM 5.8 veröffentlich, das ich auch gleich beim Neuaufsetzten installiert habe. Da jedoch alle anderen Konfigurationen, die wieder eingespielt habe, mit 5.7 gemacht wurden, habe ich aktuell noch "attr global featurelevel 5.7" gesetzt. Ob das einen Einfluss hat, weiss ich aber nicht, kann ich aber auch mal rausnehmen.
Was ich gestern auch noch gesehen habe... - es gibt ja die XML-Config-Informationen für die Z-Wave-Geräte.
Es gibt scheinbar mehrere Versionen der Strips. Ob die Beschreibung der unterschiedlichen Versionen auch unterschiedlich sind, weiss ich aber (noch) nicht. Jedenfalls gibt's eine recht neue Beschreibung
(ca. zwei Wochen alt) und die hab ich wahrscheinlich sicher nicht in meiner FHEM-Installation - dafür ist sie "zu alt". Könnte das vielleicht auch die Lösung des Problems sein? Wie bekomme ich die neue XML-Beschreibung testweise rein? ..oder muss ich dazu FHEM komplett updaten - sprich Schritt 4 und 5 doch durchführen (was ich aktuell ungern tun müsste - never change a running system)?
Also ich kann dir auf deine Fragen nur teilweise Antworten:
Zitat(was ich aktuell ungern tun müsste - never change a running system)?
Diese Einstellung kann ich leider nicht nachvollziehen. Wenn du möchtest, dass dir hier geholfen wird, solltest du deinerseits auch bereit sein ein aktuelles System vorzuhalten.
Wenn du ein aktuelles System hast, können wir gerne mit der Fehleranalyse weiter machen. Ab so gibt es meiner Meinung nach zu viele Unbekannte Faktoren.
Die Umstellung von 5.7. auf 5.8 ist auch kein Hexenwerk. Und wenn du vorher ein ordentliches Backup hast, kann auch fast nichts mehr schief gehen.
Und ob Konfig-Files im Format 5.7 in einer 5.8 Probleme machen kann ich auch nicht sagen.
Notfalls kann man ja auch ein 5.7 System aufsetzen und aktualisieren. Müsste doch über das SVN gehen. Aber das wäre ein extra Thema.
Ich will mich ja nicht verwehren, alles nötige zu tun... - bitte nicht falsch verstehen!!
Erfahrungen in diversen Software-Projekten - beruflich und privat - über die letzten 20 Jahre zeigten eben, dass eine Aktualisierung auch nicht gerade selten zu noch grösseren Problemen führen können.
Dass es aktuell viele unbekannte Fktoren gibt und ich leider mit Z-Wave bisher noch keine Erfahrungen habe, sowie FHEM auch erst seit gut zwei Monaten nutze, stört mich ja auch, aber ich muss mich auch erst langsam herantasten, um den Wald vor lauter Bäumen sehen zu können. Ich hoffe du kannst das nachvollziehen.
Wie gesagt - FHEM 5.8 ist ja drauf, nur auf Level 5.7 reduziert und kann per Attributänderung in Sekunden umgestelt werden, was ich auch testen werde (jedoch erst gegen Abend, da ich grad nicht vor Ort bin).
Lediglich zwischenzeitlich erfolgte Updates verschiedener Module habe ich vielleicht noch nicht mit drin - sofern es welche gab. Ich glaube, dass meine aktuelle Ausgangsbasis noch nicht so schlecht sein sollte.
Mir würde schon helfen, zu wissen, wie man generell prüfen könnte, ob das Razzberry-Modul i.O. ist und wie sich die Strips sicher in den Anlernmodus bekomme.
Wie schon beschrieben, schaffe ich es nicht, den Reset durchzuführen. Hin und wieder gelingt es mir auch nur, dass beim Drüberhalten des Magneten ans runde Ende die LED nur einmal oder zwei mal leuchtet. Schaffe ich es, dass sie auch beim dritten Drüberhalten innerhalb 10s leuchtet und ich den Magneten auch drauf lasse, was den Reset durchführen soll, erhalte ich jedoch die Quittierung nicht, was mich annehmen lässt, dass der Reset nicht durchgeführt wurde. Zudem bin ich mir nicht sicher, ob die Stripes überhaupt einen Reset annehmen, sofern diese noch nie includiert waren - sie sind ja nagelneu.
Muss ich dann die WakeUp-Prozedur, wenn der Reset mal gelungen wäre, zusätzlich noch ausführen oder folgt nach Reset unmittelbar die Bereitschaft zur Inkludierung?
Ich denke hier muss ich erst mal ansetzen, um den nötigen Ablauf korrekt machen zu können. Was hilft's an der Z-Wave-Installtion, RPi und Modul-Konfiguration zu "schrauben", wenn der Anlernvorgang vielleicht nie korrekt durchgeführt wird.
Zitat von: parabacus am 09 März 2018, 10:00:14
Was ich gestern auch noch gesehen habe... - es gibt ja die XML-Config-Informationen für die Z-Wave-Geräte.
Es gibt scheinbar mehrere Versionen der Strips. Ob die Beschreibung der unterschiedlichen Versionen auch unterschiedlich sind, weiss ich aber (noch) nicht. Jedenfalls gibt's eine recht neue Beschreibung
(ca. zwei Wochen alt) und die hab ich wahrscheinlich sicher nicht in meiner FHEM-Installation - dafür ist sie "zu alt". Könnte das vielleicht auch die Lösung des Problems sein? Wie bekomme ich die neue XML-Beschreibung testweise rein? ..oder muss ich dazu FHEM komplett updaten - sprich Schritt 4 und 5 doch durchführen (was ich aktuell ungern tun müsste - never change a running system)?
Die XML sind für die Inklusion und insgesamt für die Funktionsfähigkeit von ZWave-Geräten mit FHEM unwichtig. Das sind "nur" Anwenderhilfen. Mehr in https://wiki.fhem.de/wiki/Z-Wave
Zum update: FHEM wird kontinuierlich weiterentwickelt. Die Installationspakete -mit Ausnahme debian.fhem.de nightly- sind nur ein Startpunkt und ohne "update" ist das fhem-5.8-Installationspaket total veraltet.
Hallo Kirkan,
das sind zwei Aussage, die ich dann auch verstehe - Danke...!
Das war mir so noch nicht bewusst und bisher hatte ich auch noch keine negative Erfahrungen mit dem aktuellen Installations-Stand.
Bedeutet das, dass man täglich..wöchentlich ein update machen sollte oder eben bei festgestellen Problemen?
Dann mach ich heute erst mal ein Backup, aktualisiere und berichte.
Jetzt doch nochmal eine konkrete Frage...
Den Schritt 4 - rpi-update - würde ich dennoch noch nicht ausführen.
FHEM kann ich ja explizit mit Befehl update aktualisieren und muss erst mal noch nicht mit Schritt 3 (sudo apt-get update / sudo apt-get upgrade) alles aktualisieren.
update check zeigt zumidest schon mal, dass die Module ZWDongle und ZWave eine Aktualisierung bekamen.
Wäre das so sinvoll oder wie würdest du das als erfahrener Anweder und Programmierer machen?
Was man soll oder nicht mag ich nicht festlegen ;) . Wenn es läuft, dann läuft es.
Aber bei Problemen und Supportwünschen ist update quasi Pflicht, damit wir nicht alten Problemen hinterherrennen. Darum habe ich hier: https://wiki.fhem.de/wiki/Z-Wave#Welche_Infos_sollten_Anfragen_im_ZWave-Forum_enthalten.3F auch ein aktuelles FHEM mal als "Pflicht" gewünscht.
Am Rande: Durch FHEM verursachte Inklusionsprobleme gab es aber afaik nie.
Wenn das Dongle funktioniert, würde ich persönlich nicht am Betriebssystem schrauben. Indiz: Dongle-Abfragen von homeId, caps und Co funktionieren (Schau bitte auch ins globale Logfile).
Gruß, Christian
Btw: Bin kein Programmierer, sondern "nur" Anwender.
So kommen wir der Sache vielleicht schon langsam näher... ;D
Du empfiehlst also ein Update der gesamten FHEM-Installation und nicht nur der Module explzit, die grad im Fokus stehen? Hab ich das richtig verstanden?
Das BS will ich ja auch nicht zwangsweise gleich ändern. Bisher bin ich ja auch der Meinung, dass mir der Inklusions-Vorgang speziell zu den Strips die Probleme verursacht.
Die Dongle-Abfrage funktioniert ja, aber damit liest man ja auch nur Speicherzellen und Register aus FHEM und vielleicht aus dem Razberry-Modul aus. Ob das dann physikalisch auch funktioniert - sprich sendet und empfängt, lässt sich aber damit vielleicht nicht konkret feststellen - oder? Die Infos bzgl. nodeID, caps, nodeList sind jedenfalls auslesbar.
Zitat von: parabacus am 09 März 2018, 13:05:51
Du empfiehlst also ein Update der gesamten FHEM-Installation und nicht nur der Module explzit, die grad im Fokus stehen? Hab ich das richtig verstanden?
Ja. Es kann Abhängigkeiten zwischen den FHEM-Komponenten (Module, fhem.pl, *.js, ...) geben, die bei einem nur modulbezogenen Update neue Probleme bringen.
Zudem müssen wir bei einer gemeinsamen Fehlersuche doch eine möglichst einfache gemeinsame Basis haben; darum geht es letztlich.
Zitat
Ob das dann physikalisch auch funktioniert - sprich sendet und empfängt, lässt sich aber damit vielleicht nicht konkret feststellen - oder?
Ja. Deshalb schrieb ich von "Indiz". ;)
Hast Du eigentlich zwischendurch einmal den Raspberry kurz vom Strom genommen?
Alles klar.. - dann machich mal ein Full-Update....
Eine Empfehlung, wie regelemässig man ein Update i.d.R. erfahrungsgemäss so als Power-Anwender (wie du..) macht, wäre noch interessant für mich. Wenn man natürlich in kürzeren Abständen ein Update macht, kann man ggf. auftretende Probleme schneller gezielt eingrenzen.
Deinen Ansatz zur gemeinsamen Ausgangsbasis kann ich natürlich voll und ganz nachvoziehen.
Den Raspi hab ich vorgestern mal komplett vom Netz genommen, als ich das Razberry-Modul drauf gemacht hab. Seit dem nicht mehr, allerdings FEHM schon mal einen "shutdown restart" verpasst
Auch wenn ich noch nicht die Lösung des Problems gefunden habe - trotzdem Danke für die geduldige Hilfe und schrittweise Durchführung...
Zitat von: parabacus am 09 März 2018, 14:33:52
Eine Empfehlung, wie regelemässig man ein Update i.d.R. erfahrungsgemäss so als Power-Anwender (wie du..) macht, wäre noch interessant für mich. Wenn man natürlich in kürzeren Abständen ein Update macht, kann man ggf. auftretende Probleme schneller gezielt eingrenzen.
Mag keine Empfehlung abgeben; bleibt jedem selbst überlassen. Produktivsystem rühre ich persönlich eigentlich nur sehr selten an. Was läuft, läuft und es gibt nicht unbedingt so oft etwas neues, was ich brauche.
ZitatDen Raspi hab ich vorgestern mal komplett vom Netz genommen, als ich das Razberry-Modul drauf gemacht hab. Seit dem nicht mehr, allerdings FEHM schon mal einen "shutdown restart" verpasst
Typische Indizien für "klemmendes" Dongle habe ich zwar nicht erkannt, aber es kommt immer wieder vor. Dann hilft nur, das Ding komplett stromlos zu machen. "shutdown restart" genügt dann nicht.
hehe.. - also doch auch lieber ein fnktionierendes System nicht anrühren.. :o
Na ja - ich hoffe, dass alles andere dann noch funktioniert. In der kurzen Zeit, in der ich mich mit FHEM und all dem drum herum beschäftige, ist schon einiges zusammen gekommen - hätte ich anfangs erwartet.
Leider hab ich bisher nur eine Spiel-Produktiv-Wiese... - daher mein gelegentliches Zögern.
Dem Dongle verpasse ich nacher, wenn ich daheim bin, gleich mal einen Reset - vielleicht war's das dann schon.
Zitat von: parabacus am 09 März 2018, 14:50:32
na ja - ich hoffe, dass alles andere dann noch funktioniert.
Den Rückweg eröffnet doch immer ein zuvor erstelltes, vollständiges backup. ;)
Jetzt bin ich wieder synchron - hab das Update ausgeführt und dem RasPi einen General-Reset verpasst.
Alle bisher verwendeten Sachen funktionieren schon mal genauso wie vorher, was mich beruhigt.
Im FHEM-Logfile finde ich jetzt noch folgende Infos für ZWDongle:
mehrfach diese Logeinträge:
2018.03.07 16:11:09 3: Probing CUL device /dev/ttyAMA0
2018.03.07 16:11:09 3: Probing TCM_ESP3 device /dev/ttyAMA0
2018.03.07 16:11:10 3: Probing ZWDongle device /dev/ttyAMA0
2018.03.07 16:11:10 3: Probing FRM device /dev/ttyAMA0
..dann diesen:
2018.03.07 16:33:59 3: Probing CUL device /dev/ttyAMA0
2018.03.07 16:33:59 3: Probing TCM_ESP3 device /dev/ttyAMA0
2018.03.07 16:33:59 3: Probing ZWDongle device /dev/ttyAMA0
2018.03.07 16:33:59 3: Probing FRM device /dev/ttyAMA0
2018.03.07 16:34:05 3: Probing CUL device /dev/ttyS0
2018.03.07 16:34:05 3: Can't open /dev/ttyS0: Permission denied
Die Fehlermeldung kommt meiner Meinung nach noch von der zu dem Zeitpunkt noch nicht vollständig durchgeführten Konfiguration des Razberry2-Moduls.
seitdem das
2018.03.07 16:58:46 2: ZWDongle_ProcessSendStack: no ACK, resending message 01030007fb
2018.03.07 16:58:46 1: ERROR: max send retries reached, removing 01030007fb from dongle sendstack
2018.03.07 16:58:41 2: ZWDongle_ProcessSendStack: no ACK, resending message 01030007fb
2018.03.07 16:58:42 2: ZWDongle_ProcessSendStack: no ACK, resending message 01030007fb
2018.03.07 16:58:43 2: ZWDongle_ProcessSendStack: no ACK, resending message 01030007fb
2018.03.07 16:58:46 2: ZWDongle_ProcessSendStack: no ACK, resending message 01030007fb
2018.03.07 16:58:46 1: ERROR: max send retries reached, removing 01030007fb from dongle sendstack
Diese Fehlermeldung kann ich nicht ganz interpretieren, glaube aber auch an die noch nicht ganz korrekte Konfiguration des Moduls - danach klappt ja die Einbindung des Bewegungsmelders:
2018.03.07 20:10:03 3: ZWave: cannot load Crypt::Rijndael, SECURITY class disabled
2018.03.07 20:41:00 2: autocreate: define ZWave_SENSOR_NOTIFICATION_2 ZWave ecfa496a 2 5e80718570728630318459735a8f987aef20
2018.03.07 20:41:00 2: autocreate: define FileLog_ZWave_SENSOR_NOTIFICATION_2 FileLog ./log/ZWave_SENSOR_NOTIFICATION_2-%Y-%m.log ZWave_SENSOR_NOTIFICATION_2
2018.03.07 20:41:01 3: ZWave get ZWave_SENSOR_NOTIFICATION_2 versionClass ALARM
2018.03.07 20:41:01 3: ZWave get ZWave_SENSOR_NOTIFICATION_2 versionClass ASSOCIATION
2018.03.07 20:41:01 3: ZWave get ZWave_SENSOR_NOTIFICATION_2 versionClass ASSOCIATION_GRP_INFO
2018.03.07 20:41:01 3: ZWave get ZWave_SENSOR_NOTIFICATION_2 versionClass BASIC
2018.03.07 20:41:01 3: ZWave get ZWave_SENSOR_NOTIFICATION_2 versionClass BATTERY
2018.03.07 20:41:01 3: ZWave get ZWave_SENSOR_NOTIFICATION_2 versionClass CONFIGURATION
2018.03.07 20:41:01 3: ZWave get ZWave_SENSOR_NOTIFICATION_2 versionClass DEVICE_RESET_LOCALLY
2018.03.07 20:41:01 3: ZWave get ZWave_SENSOR_NOTIFICATION_2 versionClass FIRMWARE_UPDATE_MD
2018.03.07 20:41:01 3: ZWave get ZWave_SENSOR_NOTIFICATION_2 versionClass MANUFACTURER_SPECIFIC
2018.03.07 20:41:01 3: ZWave get ZWave_SENSOR_NOTIFICATION_2 versionClass MULTI_CMD
2018.03.07 20:41:01 3: ZWave get ZWave_SENSOR_NOTIFICATION_2 versionClass POWERLEVEL
2018.03.07 20:41:01 3: ZWave get ZWave_SENSOR_NOTIFICATION_2 versionClass SECURITY
2018.03.07 20:41:01 3: ZWave get ZWave_SENSOR_NOTIFICATION_2 versionClass SENSOR_BINARY
2018.03.07 20:41:01 3: ZWave get ZWave_SENSOR_NOTIFICATION_2 versionClass SENSOR_MULTILEVEL
2018.03.07 20:41:01 3: ZWave get ZWave_SENSOR_NOTIFICATION_2 versionClass VERSION
2018.03.07 20:41:01 3: ZWave get ZWave_SENSOR_NOTIFICATION_2 versionClass WAKE_UP
2018.03.07 20:41:01 3: ZWave get ZWave_SENSOR_NOTIFICATION_2 versionClass ZWAVEPLUS_INFO
2018.03.07 20:41:01 1: ZWAVE INIT: get ZWave_SENSOR_NOTIFICATION_2 versionClassAll: Scheduled get requests for sending after WAKEUP, check the vclasses attribute
2018.03.07 20:41:01 3: ZWave set ZWave_SENSOR_NOTIFICATION_2 associationAdd 1 1
2018.03.07 20:41:01 3: ZWave set ZWave_SENSOR_NOTIFICATION_2 wakeupInterval 86400 1
2018.03.07 20:41:01 3: ZWave get ZWave_SENSOR_NOTIFICATION_2 model
2018.03.07 20:44:25 3: ZWave get ZWave_SENSOR_NOTIFICATION_2 battery
2018.03.07 20:44:45 3: ZWave get ZWave_SENSOR_NOTIFICATION_2 powerlevel
2018.03.07 20:44:51 3: ZWave get ZWave_SENSOR_NOTIFICATION_2 version
2018.03.07 20:45:00 3: ZWave get ZWave_SENSOR_NOTIFICATION_2 zwavePlusInfo
2018.03.07 20:59:27 2: autocreate: renamed FileLog_ZWave_SENSOR_NOTIFICATION_2 to FileLog_BewSensHT
2018.03.08 21:35:59 3: ZWave: cannot load Crypt::Rijndael, SECURITY class disabled
Da fehlt wohl noch das Perl-Modul Crypt-Rijndael - SECURITY wird vom Bewegunsmelder unterstützt. ==> Ist das aktuell entscheiden?
Den Sensor-Device-Namen hab ich umbenannt... - hat auch geklappt:
2018.03.08 21:59:19 3: ZWave get BewSensHT model
2018.03.08 22:03:15 3: ZWave get BewSensHT powerlevel
2018.03.08 22:31:44 3: ZWave get BewSensHT zwavePlusInfo
2018.03.08 22:31:52 3: ZWave get BewSensHT wakeupIntervalCapabilities
2018.03.08 22:32:03 3: ZWave get BewSensHT versionClass ALARM
2018.03.08 22:32:03 3: ZWave get BewSensHT versionClass ASSOCIATION
2018.03.08 22:32:03 3: ZWave get BewSensHT versionClass ASSOCIATION_GRP_INFO
2018.03.08 22:32:03 3: ZWave get BewSensHT versionClass BASIC
2018.03.08 22:32:03 3: ZWave get BewSensHT versionClass BATTERY
2018.03.08 22:32:03 3: ZWave get BewSensHT versionClass CONFIGURATION
2018.03.08 22:32:03 3: ZWave get BewSensHT versionClass DEVICE_RESET_LOCALLY
2018.03.08 22:32:03 3: ZWave get BewSensHT versionClass FIRMWARE_UPDATE_MD
2018.03.08 22:32:03 3: ZWave get BewSensHT versionClass MANUFACTURER_SPECIFIC
2018.03.08 22:32:03 3: ZWave get BewSensHT versionClass MULTI_CMD
2018.03.08 22:32:03 3: ZWave get BewSensHT versionClass POWERLEVEL
2018.03.08 22:32:03 3: ZWave get BewSensHT versionClass SECURITY
2018.03.08 22:32:03 3: ZWave get BewSensHT versionClass SENSOR_BINARY
2018.03.08 22:32:03 3: ZWave get BewSensHT versionClass SENSOR_MULTILEVEL
2018.03.08 22:32:03 3: ZWave get BewSensHT versionClass VERSION
2018.03.08 22:32:03 3: ZWave get BewSensHT versionClass WAKE_UP
2018.03.08 22:32:03 3: ZWave get BewSensHT versionClass ZWAVEPLUS_INFO
2018.03.08 22:32:39 3: ZWave get BewSensHT basicStatus
2018.03.08 22:32:55 3: ZWave get BewSensHT associationGroups
Irgendeinen Hinweis auf den Versuch, dass ein Stripe versucht wird zu includieren, kann ich bisher nicht finden.
Lediglich diese Fehlermeldung hält sich:
2018.03.09 16:37:41 2: ZWDongle_ProcessSendStack: no ACK, resending message 0107000301020100f9
..und eben kam das noch, wobei die Readings des Bewegunssensors aktualisiert wurden:
2018.03.09 18:00:41 2: ZW_GW transmit NO_ACK for CB 02, target BewSensHT
2018.03.09 18:00:41 2: ZW_GW transmit NO_ACK for CB 02, target BewSensHT
2018.03.09 18:00:41 2: ZW_GW transmit NO_ACK for CB 02, target BewSensHT
2018.03.09 18:00:41 2: ZW_GW transmit NO_ACK for CB 02, target BewSensHT
Damit würd ich erst mal interpretieren, dass die Kommunikation zumindest zwischen den beiden prinzipiell funktioniert und ich damit das Razperry-Modul selbst und die Einbindung dessen als Fehlerquelle ausschliessen kann.
@Christian: Wie sieht das dein erfahrenes Anwender-Auge?
Da wird der Hund in der Pfanne verrückt... - irgendwo war doch wirklich der Klemmer...
Der Devolo-Soundgeber hat sich jetzt auf Anhieb inkludieren lassen... - die Stripes weigern sich aber noch und da bin ich jetzt schon recht sicher, dass dabei die Reset- und/oder Wakeup-Prozedur irgendwie nicht klappt.
Könnte es auch daran liegen...? - siehe unter Add - Punkt 5
https://www.stripsbysensative.com/wp-content/uploads/2017/05/Strips_guard_English.pdf (https://www.stripsbysensative.com/wp-content/uploads/2017/05/Strips_guard_English.pdf)
If your Z-Wave system doesn't respond, you may need to change Strips' notification type from the controller.
Zitat von: parabacus am 09 März 2018, 20:55:58
Könnte es auch daran liegen...? - siehe unter Add - Punkt 5
https://www.stripsbysensative.com/wp-content/uploads/2017/05/Strips_guard_English.pdf (https://www.stripsbysensative.com/wp-content/uploads/2017/05/Strips_guard_English.pdf)
If your Z-Wave system doesn't respond, you may need to change Strips' notification type from the controller.
Schließe ich aus, obwohl die Anleitung dort für mich verwirrend ist.
Der Notification Type ist die Festlegung der Command Class zur Mitteilung von auf/zu mittels der Class CONFIGURATION. Das ist erst nach der Inklusion durch den Controller möglich. FHEM unterstützt alle aufgeführten Command Classes zur Mitteilung.
Dann bin ich langsam am Ende mit meinem Latein... - ich hab's inzwischen bestimmt schon 50 mal probiert.
Wie es scheint bin ich aber nicht der erste mit Problemen, die Strips einzubinden... https://forum.fhem.de/index.php?topic=71644.0 (https://forum.fhem.de/index.php?topic=71644.0)
Es klingt vielleicht unwahrscheinlich, dass gleich zwei defekt sind, aber ausschliessen kann man's auch wieder nicht.
Ich hab jetzt dem Support von Sensative mein Problem geschildert - mal sehen, was da kommt.
Mit den beiden anderen Devolo-Geräten komme ich auch noch nicht ganz klar - da steht im Log bisher nur "...transmit: NO_ACK" - das aber dann in einem anderen Thread
Na also... - jetzt hab ich beide einbinden können, wobei einer noch immer zickt.
Das Problem war übrigens mehr als banal.... - Thema Reichweite! :-\
Der RPi ist im Keller und zwischen der Stelle, wo er hängt und meinem Schreibtisch liegen grad mal so 4..5m - halt mit Betondecke, in der natürlich das ein oder andere Eisen steckt. Das genügt aber schon, dass praktisch gar nix geht. Seltsam ist das auch noch mit den beiden anderen Geräten - includieren ging noch, aber dann Daten austauschen.. "Fehlanzeige".
Zumindest klappt's mit dem Bewegungssenor jetzt auch über grössere Entfernung, nachdem ich ihn und das GW mal wortwörtlich näher gebracht hatte.
Analoges gilt für die Sirene - auch die hat nun auch ihre Daten ausgetauscht, als ich sie in unmittelbare Nähe des GWs gebracht hatte.
Leider stellt mich das nun vor die nächste "bauliche" Frage. Den RPi kann ich örtlich nicht wo anders installieren, da der an einigen Geräten (Heizung, Stromzähler, ...) per USB hängt. Ich hätte gehofft, dass das Razberry2-Modul mit verbesserter Antenne das schafft. Dann muss ich wohl noch eine ext. Antenne dran bauen und die irgendwie ins EG bekommen - oder irgenwie mit Repeater experimentieren.
Inzwischen hab ich einen der beiden Sensoren schon an einer Tür verbaut und er liefert fleissig und bisher recht zuverlässig seine Informationen zum Zustand der Tür.
Ich hab jedoch das Problem, dass ich nicht weiss, wie ich die Information "einfach" verarbeiten kann.
Im Log liefert der Stripe das:
2018-03-11_13:29:31 ZWHausTuer alarm: AccessControl: Window/Door is open, arg 0000
2018-03-11_13:29:37 ZWHausTuer alarm: AccessControl: Window/Door is closed, arg 0000
Wie lässt sich das substituieren oder gibt's einen Trick, wie man den Sensor nur "open" bzw. "closed" liefern lassen kann?
Edit: Das ist der Notification type! - Possible values: BasicReport (2), BinarySensorReport (0), NotificationReport (1) - Stellt man ihn auf 2, kommt "open" bzw. closed und bei 0 kommt 0 bzw. 255.
Der zweite Sensor hat sich jetzt auch nochmals integrieren lassen. Ohne dass ich es wollte, hab ich ihm aber jetzt einen Reset verpasst, während ich den Stripe aufwecken wollte, um ihn per "set <ZW_Dongle> removeNode on" zu entfernen.
Damit war er auch gleich wach und sofort nach dem Reset im Inklusions-Modus, weshalb er sich dann auch gleich neu angemeldet hat.
Leider hab ich jetzt soz. eine Leiche im System... - wenn ich jetzt get <ZWDongle> nodeList ausführe, bekomme ich den "alten" mit angezeigt:
ZW_GW nodeList => ZW_GW BewSensHT ZWSirene ZWKellerTuer ZWHausTuer ZWave_SENSOR_NOTIFICATION_7
Ich nehme mal stark an, dass es nicht genügt, das Device einfach aus FHEM zu löschen?
Zitat von: parabacus am 11 März 2018, 19:45:47
Edit: Ist das der Notification type? - Possible values: BasicReport (2), BinarySensorReport (0), NotificationReport (1)
BinarySensorReport liefert einfaches open/close
Oder lässt NotificationReport und übt so FHEM. ;) Beispielsweise: https://wiki.fhem.de/wiki/Z-Wave-PHI_PST02-1A-T%C3%BCr-,_Bewegungs-,_Helligkeits-,_Temperatursensor#STATE_mit_open.2Fclosed_anzeigen
Zitat
Ich nehme mal stark an, dass es nicht genügt, das Device einfach aus FHEM zu löschen?
Korrekt. inkludierte Nodes sind auf dem Stick gespeichert.
Lösung: https://wiki.fhem.de/wiki/Z-Wave#Wie_kann_man_ohne_Exklusion_Nodes_des_Controllers_l.C3.B6schen.3F
Du bist ein wandelndes Lexikon... - mein Respekt!
Jetzt bist du mit deiner Antwort parall mit meinem EDIT gekommen - hab's eben selbst probiert und auf BinarySensorReport (0) umgestellt - und für alle ratlosen gleich dokumentiert.. ;D
FHEM üben wäre sicher auch angebracht - da bin ich noch längst kein routinierter Anwender. Bisher konnte ich mir das meiste aber "abgucken" :o
Danek für die Links - das werd ich auch noch schaffen! ;)