Dieser Beitrag beschreibt meine ersten Gehversuche & Erfahrungen mit OpenHab und Zwave, beides neue Systeme für mich.

---

Werbung

Die meisten Links auf dieser Seite sind Affiliate-Links, durch die ich eine kleine Provision erhalte, wenn du etwas darüber kaufst. Die Preise bleiben für dich unverändert. Affiliate-Link-Kürzel:  AM = Amazon, EB = Ebay, FT = FastTech, GB  = Gearbest, AL = Aliexpress

Inhalt

• Vorwort
• Die allerersten Tests & Eindrücke
• OpenHab, die dritte Installation
• Erster Reichweiten-Check
• Fazit
• Links & Kommentare

Vorwort

Vieles von dem folgenden löst / klärt sich später. Betrachte es als Dokumentation wie es einem DAU anfangs ergehen kann…

OpenHab 2.2 ist auf den ersten Blick für mich ein Durcheinander aus UI’s, einem Ersatz für den Eclipse SmartHome Designer, der vielversprechend aussah, aber für die Version 2 leider nicht mehr angesagt ist. Ein HomeBuilder ist nun als Web-App integriert, recht rudimentär. Immerhin braucht man dafür dann kein Windows, und vielleicht wird’s ja noch…

Vieles in OpenHab, und den Zwave-Devices ist nicht, oder nicht gut erklärt, und zB eine Sitemap oder Items-Datei funktionieren gar nicht, auch nicht nach stundenlangem Probieren und Foren-lesen…
Ich kenne das selbst. Eine funktionelle Software schreiben ist eine Sache. Eine GANZ andere Sache ist es sie so zu schreiben das sie für Fachfremde gut benutzbar wird. Das steigert den Code-Umfang, die potenziellen Fehlerquellen, und den Testbedarf um ein vielfaches. DAZU auch noch eine gute Anleitung zu schreiben, das ist alles eine riesige Aufgabe und ein Arsch voll Arbeit. Falls dies jemand der Programmierer hier liest – ich bitte das folgende Gemaule mit einer gewissen Gelassenheit zu betrachten. 😉

Ein großes Problem das man als kompletter Neuling eines Systems hat, ist es gar nicht abschätzen zu können wo ein Problem liegt, warum etwas nicht funktioniert: Ist es OpenHab, die Oberfläche im Browser, die Hardware auf der das Ganze läuft, Java, der Zwave-Controller, das Binding, das Zwave-Gerät, eine falsche Konfigurationseinstellung, …

Die allerersten Tests & Eindrücke

Beim Einrichten des Bewegungsmelders ist es schön das man alle Parameter des Melders in OpenHab einstellen kann, und sogar Erklärungen für die Parameter dabei sind, allerdings fast immer zu dürftig. So kommt es das man viel ausprobieren muss wie der Melder sich in der Praxis verhält, und wie die Parameter zusammenspielen.
Problem: Die Parameter werden nur übertragen wenn das Gerät „aufwacht“, was es standardmäßig nur einmal pro Tag (oder so) tut. Ok, etwas später habe ich dann gelesen das man das Aufwachen durch Knopfdruck am Gerät forcieren kann. Trotzdem bleibt es etwas Glücksspiel WANN die Parameter, UND WIEVIEL davon tatsächlich an das Gerät übertragen werden. So wie ich vermute ist das ein generelles Problem des Protokolls, und es kostet unfassbar viel Zeit, weil das Testen eh schon ewig dauert, aber wenn man nicht genau weiß ob der Melder die aktuellen Parameter nun schon gefressen hat dann wird die Testerei zum Blindflug.
Besser wäre es wenn Zwave-Geräte einen „Einrichtungsmodus“ hätten, welcher automatisch aktiv wird sobald das Gerät merkt das an ihm herumgefummelt wird (oder halt per x-mal Tastenklick). In diesem Modus sollte keine Rücksicht auf die Batterie genommen werden, und Werte & Parameter sehr häufig & vollständig übertragen werden, das würde die Sache SEHR erleichtern. Zudem würde ein Status „Parameter übertragen am Datum/Uhrzeit“ sehr hilfreich sein um zu wissen ob und wann es geklappt hat.

Der Bewegungsmelder funktioniert nicht wie erwartet. Nach einer Auslösung darf für ca. 8 Sekunden (auch wenn ich 5 Sekunden (das Minimum) eingestellt habe) keinerlei Bewegung vorhanden sein, sonst löst er für weitere 10 Sekunden nicht mehr aus. Heißt: Habe ich in OpenHab eine Regel die mir Licht für 15 Sekunden einschaltet, dann geht das auch dann nach 15 Sekunden aus obwohl ich mich noch im Raum bewege.
Das Ganze funktioniert nur dann wenn ich den Melder direkt per Association, also an OpenHab vorbei, mit der Steckdose kopple. Dann wird „silent“ (ohne sichtbare LED-Auslösung am Melder) immer wieder ein Befehl an die Steckdose gesendet, und sie bleibt an. Ich möchte OpenHab aber nicht umgehen, weil ich bei Dimmern zB verschiedene Dimm-Level haben möchte, in Abhängigkeit anderer Dinge…

OpenHab soll bei mir auf’m Raspberry laufen, läuft bei mir in der Testphase aber auf’m Mac, weil das bequemer ist wenn was nicht funktioniert. Meine erste Testinstallation, Version 2.2, lief schon merkwürdig, ohne das ich abschätzen konnte ob es wirklich ein Problem gab, denn ich hatte noch keine Geräte. Die kamen dann, so konnte ich mal in Zwave was inkludieren. Dann sah ich das OpenHab 2.3 vefügbar war und habe das per Terminal-Befehl aktualisiert, klappte. Nach dem Update habe ich OpenHab beendet und meinen „OpenHab 2.2“ Ordner in „OpenHab“ umbenannt, was in einem heillosen Datei- und Ordner-Durcheinander endetet, da OpenHab nicht mehr wußte welchen Ordner es für was es denn nun nehmen sollte. Offensichtlich gibt es im Code nicht nur EINEN Master-Pfad zum OpenHab Verzeichnis…

Egal, das lief sowieso alles komisch, und ich hab natürlich auch viel dran rumgefummelt von Dingen die nicht erklärt sind und die man dann halt einfach ausprobiert, und ggf. auch kaputtspielt, keine Ahnung… (und davon viel)

Also OpenHabe 2.3 komplett neu und jungfräulich installieren. Ich installiere den „Simple“-Mode – ich kann ja später nachinstallieren, dachte ich. Habpanel habe ich noch gesehen, aber das ganze andere Zeug finde ich nicht mehr, kann es nicht nachinstallieren.
Auch das FS20-Binding will nicht mehr auftauchen, auch nicht mit Legacy 1.0 Bindings aktiviert…
Davon ab, hat OpenHab scheinbar auch Probleme mit Leerzeichen im Pfad, gut, also auf den Desktop gezogen, dann startete es überhaupt erst… Das ist ein schönes Beispiel von vielen Problemen auf deren Lösung man nur kommen kann wenn man ein Computer-Freak ist.

Das Inkludieren der Geräte ist seltsam. Ich muss die Geräte gar nicht aktiv in den Inklusionsmodus bringen, sie werden trotzdem gefunden. Auch wenn ich sie aus der Inbox lösche poppen sie schnell wieder auf. Anfangs nur mit „Unbekanntes Gerät, Node 2“ und ähnlich… Die Schaltsteckdose hat sich irgendwann mit Namen zu erkennen gegeben, der Bewegungsmelder zieht es vor dauerhaft anonym zu bleiben, unter „grzlhmpf Node 3“.

OpenHab-Rules funktionierten anfangs, dann habe ich weitere hinzugefügt, dann funktionierten sie nicht mehr. Ob DAS wirklich die Ursache war ist ungewiss, da man ja nicht nur an einer Sache herumfummelt, aber eigentlich hatte ich sonst nur die Parameter des Bewegungsmelders in den Griffeln… Interessanterweise funktionieren die Rules nun manchmal EINMAL nachdem ich den Bewegungsmelder aufgeweckt habe, dann gleich alle, was sich in gleichzeitigem Bellen, Klingeln, und Schalter AN bemerkbar macht…

Bei den Rules gibt’s noch mehr Kritik, so finde ich die Oberfläche unbequem , und das man beim Watt-Wert keinen Zahlenschwellwert einstellen kann, nun ja, es ist noch als „experimental“ ausgewiesen – das ist es wohl.

In den Thing-Parametern des Bewegungsmelders werden plötzlich Minus-Werte für 2 Parameter angezeigt (die sind dort gar nicht zulässig).

Der Steckdosen-Status wurde anfangs korrekt aktualisiert wenn ich die Steckdose an der Hardware schalte, später nicht mehr. OpenHab neu gestartet, dann ging es wieder, später wieder nicht mehr…

OpenHab (Java) hat 200% CPU-Auslastung, nachdem ich den USB-Controller abgezogen habe.

So, das war längst nicht alles an Merkwürdigkeiten. Ich will mir aber auch nicht die Finger wund tippen… Das waren jetzt mindestens 8 Teststunden. Eines fällt mir aber noch ein: Anfangs ging gar nichts, weil der 8080-Port schon von etwas anderem belegt war. Wie man den Port ändert habe ich nicht herausgefunden, also musste ich ihn für den anderen Service ändern, was dann auch wieder einen kleinen Rattenschwanz hinter sich herzog…

Ich setze jetzt alles noch mal neu auf, und resette vor Anschluss sämtliche Hardware. Vielleicht sind ja Rückläufer dabei, und dann könnten zB im USB-Controller noch Geräte anderer Kunden gespeichert sein?

OpenHab, die dritte Installation

Damit es nicht so’n durcheinander ist, werde ich diesmal strenger mitschreiben was ich tue und was passiert:

Ich installiere OpenHab diesmal nicht dort wo ich es gern hätte, sondern im Applications Folder, nur um sicherzugehen, falls einer der Programmierer es dort erwartet…
Allerdings benenne ich den Ordner von „openhab-2.3.0“ in „openhab“ um, weil die Versionsnummer irgendwann eh nicht mehr stimmt…

Terminal: /Applications/openhab/start.sh
Browser: localhost:8080
Was passiert wenn ich „Skip the package selection….“ klicke, kann ich dann einzeln wählen was ich installieren will? Nein, ich hab dann ein unbenutzbares OpenHab, also im  Terminal beenden, wegschmeißen, ZIP wieder auspacken, Ordner umbennenen, Neustart.
Diesmal wähle ich den vorgeschlagenden „Standard“-Mode. Obwohl „Expert“ Mode „Best for 1.x Users“ sein soll – bekomme ich nur da das alte FS20-Binding zu sehen?
Ok, ich mach’s mal anders: Ich erstelle verschiedene OpenHab-Ordner mit denen ich dann rumtesten kann:

• openhab-standard (Aha, „Standard“ installiert:
  Paper UI, Basic UI, Habpanel, Home Builder)
• openhab-expert (Bei „Expert“ wird installiert:
  Paper UI, Basic UI, Habpanel, REST Api, Classic UI, Habmin)

Um den Port 8080 zu ändern gibt es mittlerweile eine Anleitung, die jedoch auf’m Mac nicht funktioniert. Per Multifile-Textsearch finde ich die Port-Einträge in
openhab-expert/runtime/bin/setenv
und
openhab-expert/runtime/bin/setenv.bat

Für meine „Standart„-Installation vergebe ich den Port 8082.
Für meine „Expert„-Installation vergebe ich den Port 8083.
Funzt. Nun könnte ich sogar beide parallel laufen lassen.
Ich befasse mich aber erstmal nur mit der Standard-Installation, in der übrigens die Rule-Enginge nicht installiert ist, aber hier kann ich nun von der UI aus alles nach Belieben nachinstallieren, im Gegensatz zur „Simple“-Installation…

Die Hardware setzte ich vor der Einbindung in OpenHab wieder komplett zurück, ist ja noch sehr übersichtlich:
1x Controller (Link zum Reset)
1x Bewegungsmelder (Link).
1x Steckdose (Link)

Zwave-Binding installiert.
Controller an USB stecken, Search, auswählen. Für den Serial Port wähle ich aus dem Popup „/dev/cu.usbmodem …“, stelle die Heal-Time auf 4am, und fummel sonst nicht rum.

Der Controller wird als „Online“ gemeldet, taucht aber nicht unter „Control“ auf. Aha, unter Configuration–>System–>Item Linking ist der Simple Mode aus. Ich lass ihn mal aus, merke aber schnell das ich mit den Items/Channels noch nicht klar komme, stelle den Auto-Modus wieder an, und kann dann einfach auf die Eigenschaften des Controllers klicken, womit die Channels für das Contorller-Item erstellt werden.
Ich kann nun aber nirgends die Items oder deren Channels bearbeiten…
Ich hab auch keinen Link um aus der PaperUI rauszukommen. Also ins Browser-URL-Feld: localhost:8082
Ich gehe erstmal in den HomeBuilder, erstelle eine Sitemap und Items, die ich mit TextWrangler als „cris.items“ und „cris.sitemap“ entsprechend abspeichere:
/Applications/openhab-standard/conf/items/cris.items
/Applications/openhab-standard/conf/sitemaps/cris.sitemap
Ich wechsle in die BasicUI – die Dateien bleiben für OpenHab nicht-existent, wie bei meinen allerersten Versuchen auch.
Ach Du Scheiße, darf nicht wahr sein: Ich ändere das Text-Encoding von UTF8 auf das steinzeituralte „Mac OS Roman“ – und es geht! Kränk! Kinners, UTF8 gibt es seit 900 Jahren auf’m Mac (ich glaub es war sogar das erste Betriebssystem das es unterstützt hat), und da wird auch nichts anderes mehr verwendet! Mannmannmann, SO kann isch net ahbeide! :-/ 😀

Zurück im HomeBuilder – ich kann nur Objects für den First Floor anlegen, im Ground Floor kann ich nur Räume hinzufügen. Ich klick mich tot – geht einfach nicht.

Egal, erstmal zu den Basics zurück – dem Inkludieren der Zwave-Geräte:
Unter Control habe ich ja nun den Zwave-Controller, und kann sehen ob was gesendet wird.

Ich lasse das Zwave-Binding suchen, klicke 3x den Knopf des Bewegungsmelders, dann erscheint „Node2, Unknown Device“ in der Inbox. Gut, ich nehme es hin und füge das mal stumpf hinzu, und hoffe das es sich bald von selbst repariert.
Mit der Steckdose gehe ich genauso vor, die erscheint auch erst als „Node 3 …“, das ändert sich aber nach einer Sekunde in
„Z-Wave Node 3: NAS-WR01ZE Metered Wall Plug Switch“
So soll das sein.

Unter Control, in der Location „GA“ taucht er nicht auf, sondern unter „Other“. Kein Problem, ändern wir schnell mal sein Location auf „GA“. Klappt nicht, der Wert wird nicht abgespeichert, offenbar gibt es da in der Programmierung kein „changed“-event, erst als ich einen der anderen Parameter leicht änderer wird auch die Location mit abgespeichert…

Der Bewegungsmelder ist online, aber was das für ein Gerät ist ist weiterhin unbekannt. Da ich nicht 100 Jahre warten will bis sich der Bewegungsmelder korrekt angemeldet hat drücke ich seinen Knopf, zum „aufwachen“, und hoffentlich Daten-austauschen…
Beim rumspielen ob die Daten schon da sind kommt von OpenHab gelegentlich ein „Server 500“ Error, nun ja..
Es passiert nix, ich drücke noch mal. Man kann vor dem Drücken in Control gehen und die „Start Frames“-Zahl vom Controller anschauen – die sollten so um 100 hochrattern wenn die Daten übertragen werden…
Ich warte ein paar Minuten. Es passiert nix.
Noch mal. Warten… Nix.
Noch mal. Noch mal. Noch mal. Noch mal. Nix.
Ich probiere was anderes. Ich ziehe den Controller ab, bringe ihn in den Exclusion Modus, exkludiere den Melder (3x klicken), verbinde den Controller wieder, nun müsste das Gerät weg sein? Nein, noch da, OpenHab restart, aha, nun wird Node 2 immerhin als Offline gemeldet, obwohl der im Controller ja gelöscht sein müsste. Ok, manuell löschen.
Controller abziehen, in Inklusions-Modus, Melder inkludiert, Controller einstecken, Search for Things….nichts.
Ok, noch mal. Hm, OpenHab merkt auch nicht das der Controller nicht mehr am USB ist, er ist immer noch „Online“. OpenHab restart. Der dauert übrigens auch immer ewig, vor allem der logout, aber auch nach launch ist er nicht gleich voll da, gibt dann erstmal 404-Errors…
So, nun wird alles brav als Offline gemeldet.
Den Controller stecke ich nun wieder an, und erwarte das der eben inkludierte Melder nun in OpenHab sichtbar wird – hoffentlich gleich mit allen Eigenschaften…
Es passiert nichts. Da ich nicht weiß ob/wann/wie/wo die Browser-UI den Status ändert wechsle ich zwischen der Control-Ansicht und der Things-Ansicht hin und her…
Nix. Aha, in der Things-Ansicht, wenn ich den Controller konfigurieren will, steht „Status: OFFLINE – COMMUNICATION_ERROR Serial Error: Port /dev/cu.usbmodem1481 does not exist“.
Na super. OpenHab restart. Gähn, warten, warten…
Controller wieder Online. Kann ich nun endlich den vorher inkludierten Melder korrekt hinzufügen? Search Things… „Zwave Node 4, unknown Device“…
Michse geben auf.
Ok, ich drücke noch mal den Melder-Knopf. Starte noch mal Search… Drücke noch mal…
Meine Fresse. Den ganzen Tag habe ich nun wieder an dem Kram rumprobiert, für heute reicht es mir. Ich füge das unbekannte Gerät hinzu und schaue später ob er irgendwann die Gerätedaten übertragen hat…

2 Stunden später, nix.
Ich mache einen Factory-Reset beim Melder, ein Fehler, entferne ihn aus OpenHab, nun habe ich das in der Inbox: Node 4 ist vermutlich der inkludierte aus dem Controller-Stick selbst, und Node 5 der Factory-Reset. Wie bekomme ich den Mist jetzt bereinigt?

Controller vom USB abstöpseln, exkludieren, nun habe ich nur noch den Node 4 in der Inbox.
Aha, nebenbei sehe ich das die Schaltsteckdose gar nicht mehr funzt.
OpenHab restart… Keine Ahnung, sollte ich vielleicht auch mal einen „system:restart“ machen? Im Terminal steht:
„Hit ‚<ctrl-d>‘ or type ’system:shutdown‘ or ‚logout‘ to shutdown openHAB.“
Demnach ist es völlig wumpe was man macht, dann weiß ich nur nicht warum es zwei Befehle für ein und dasselbe gibt…
Egal, Schaltsteckdose geht wieder, und ich inkludiere „Node 4“ wieder.
Immer noch keine Datenübertragung.
Ich ändere im Controller-Thing auf „Low Power Inclusion“, irgendwas muss man ja probieren… Nix. Node 4 wieder entfernt.
OpenHab restart.
Node 4 wurde nicht entfernt. Noch mal entfernen, noch mal restart.
Meine Fresse, ist das eine Scheiße. Und ich fuddel hier nur mit 2 Geräten rum…
So. Wieder inkludieren. Tja, ich find’s seltsam das ich am Melder gar nichts machen muss (3x klicken) – der Node 4 taucht sofort wieder auf sobald ich auf Search gehe…
Test: Ich entferne die Batterie aus dem Melder. Search, immer noch da. Also ist das gecachet, oder im Controller-Stick gespeichert…
OpenHab restart. Hatten wir heute ja auch erst 100x.
Node 4 immer noch da.
Controller-Reset. Immer noch da.
OpenHab shutdown, Controller-Reset.
Immer noch da. Vermutung: Der Controller wurde nicht resettet. Es reicht nicht den Reset-Knopf zu drücken bis das rote Licht blinkt, es muss stattdessen ca. 30 Sekunden lang gedrückt werden, bis das rote Blinken, und das blaue Blinken vorbei ist??? (Ist natürlich nicht dokumentiert).
Controller an USB, OpenHab launch.
Endlich, Node 4 ist Geschichte, wird nicht mehr gefunden.
Ich setze die Batterie wieder in den Melder, und warte über 20 Sekunden (Handbuch).
OpenHab: Search, nichts wird gefunden, so wie erwartet.
Search, und 3x Klick beim Melder: Nun erscheint „Node 2, unknown Device“.
Add.
Shit, die Schaltsteckdose geht schon wieder nicht, also klemmt eh wieder irgendwas bei OpenHab. Grrrrrrr.
OpenHab restart. Steckdose geht immer noch nicht, aber eeeendlich rattern mal knapp 200 „Start Fames“ über den Controller, das sollte die Übertragung gewesen sein…
Yup, nun habe ich „Node 2, Motion Sensor PIR Motion Sensor“. Hat ja kaum 100 Jahre gedauert…
Ich fummel jetzt erstmal nicht an den Parametern, sondern setze nur die Location auf „GA“, aber was sehe ich da bei „Basic Set Level“: -1. Den Wert gibt es gar nicht. Grrr. Egal, ich ignoriere es erstmal.

So. Endlich habe ich wieder alle 3 Geräte in der Control-Ansicht. Meine Schaltsteckdose repariere ich wie? Genau…
OpenHab restart. Oder auch nicht. Geht nicht mehr. Ich vermute weil ich den Controller-Stick resettet habe… Also die Steckdose wieder aus OpenHab entfernen…
Inkludieren, mehrmals versucht, wird nicht gefunden *heul*.
OpenHab restart. Hilft nix.
Controller abziehen, Exclusion Mode, Steckdose exdkludieren.
Steckdose Factory Reset.
OpenHab logout, Controller dran, OpenHab launch.
Serach, „Node 3 NAS-WR01ZE Metered Wall Plug Switch“ wird gefunden, add.
Steckdose geht wieder. Meine Fresse…
Oh, die Watt-Angabe fehlt (Switch, Amps, kWh, Volts sind da). Hm, der Channel ist linked, ich ändere an den Thing-Properties was, aha, nun taucht es in der Control Ansicht auf, warum auch immer.

Im Homebuilder mache ich noch mal Items und Sitemap. Wie ich den Kram dann mit den Things verheirate muss ich mir in der Doku später ansehen…

Ich schaue nach den FS20 Binding – ist jetzt installierbar (war im „Simple“-Install nicht auffindbar).

Um die experimentelle Rule Engine (unter Add Ons -> Misc) komme ich wohl nicht herum, denn was soll eine Heimautomation ohne Regelwerk…

Ich installiere noch „Mary Text-to-Speech“, keine Ahnung was der Unterschied zur Mac-Sprachausgabe sein soll, mal gucken – erklärt wird da nix.

So, Regeln installiert, aber nicht sichtbar. In den Ansichten springen bringt nichts. http://localhost:8082 eingeben, Paper UI neu aufrufen, nun sind sie da.
Mit zwei Geräten bekomme ich schon eine stattliche Auswahlliste, und man bekommt keine Klarnamen der Geräte, sondern nur einen kryptischen Identifier, in dem man immerhin „node2“ rauslesen kann. Wie man Regeln erstellen soll ohne irre zu werden, wenn man 10 oder mehr Geräte hat weiß ich allerdings nicht.
Juchhu, es funktioniert mal was auf Anhieb: „Ich bin an“ sagt die Steckdose nun wenn sie eingeschaltet wird.

Ich hab nun zwei Rules die mir den Status des Melders mitteilen. An dessen Settings fummle ich nun rum, für mein geplantes „Walk-Light“ brauche ich Bewegungsmeldungen in möglichst geringem Zeitabstand… Ich mache die Settings und muss den Melder erstmal wieder „aufwecken“ um ihn zum Daten-abholen zu überreden, klappt mal wieder nicht auf Anhieb, immerhin beim zweiten mal.
Und jetzt funzen die Melder-Rules nicht mehr, die von der Steckdose aber schon, zum bekloppt werden…
OpenHab restart.
Randnotiz: Die Batterie des Melders ist nun, nach einem Tag Spielerei, auf 83%.
Schade, ich hab eben nicht auf die Rules geschaut, aber nach Restart funktioniert keine mehr und sind alle „Uninitialised„, toll.
Einmal disablen / enablen, sind sie „Idle“, funktionieren aber trotzdem nicht, bis auf die Steckdosen-Rule.
Ich lösche die Melder-ON Rule und erstelle sie neu, hab ja eh nix anderes zu tun. Hilft nix.
Ich füge den Rules Kommandos hinzu die Steckdose EIN/Auszuschalten, zusätzlich zur Soundausgabe. Nix.

Persistence (Werte beim Beenden abspeichern und bei Starten laden): Ich installiere die Sqlite Variante. Werte werden nicht gespeichert/geladen. Hätte mich auch gewundert das mal was klappt…
Ich installiere die RRD4j Persistence (und setze sie natürlich auch unter Configuration->System). Klappt auch nicht. Dafür haben in der Controls-Ansicht der „Binary Sensor“, der „Alarm (burglar)“ plötzlich Schalter in der UI. Nun ja. Ich kann sie switchen, da passiert aber nichts (die Rules hätten ja ausgelöst werden können *hust* haha). 

Zur Abwechlsung, weil der Melder gar nicht so tut wie er tun soll, schaue ich mal wieder beim Melder-Thing in die Settings, und sehe das wieder Nonsens-Werte drin sind, und ein vormals gesetzter Wert wieder auf Default steht.
Ich werd irre. Und bekomme Lust dem ganzen Müll per secure-delete 7x zu überschreiben. 😀

Soll ich vielleicht mal den nightly build von OpenHab installieren? Oder zurück auf Version 2.2 gehen? SO hat das alles wohl keinen Zweck. Oder liegt’s vielleicht daran das es auf’m Mac läuft? Liegt’s vielleicht am USB-Verlängerungskabel mit dem der Controller am Mac hängt? KANN letzlich alles sein… Und der Controller funktioniert tatsächlich nicht an meinen 7-Port HooToo-Hub, scheint also ein USB-Mimöschen zu sein.
Gut, da ich den Inklusions-Kram hinter mir habe:
OpenHab aus, Controller ab, direkt an den Mac angeschlossen, OpenHab start.
Es werden immer noch Nonsense Werte im Melder-Thing angezeigt, vor allem der -1 Wert könnte, wenn er im Gerät real gelandet ist, dafür sorgen das die Rules auch nicht mehr triggern… Ich korrigiere das, habe wieder die Arie mit der Parameter-Übertragung, und dann:
Aha, die Rules sind mal wieder nicht initialisiert, wieder aus / an, wie gehabt, nur die Steckdosen-Rule funzt. Nebenbei sind die Schalter in der UI wieder weg. Läuft wirklich alles sehr konsistent und stabil hier, muhaha. 🙁
Wieder in die Melder-Thing Settings. Wieder Nonsense-Werte drin. -106 für den „Sensitivity Level“ und -1 für den „Basic Set Level“. Immerhin, nun ist mein „On/Off Duration auf 5 gespeichert geblieben. Ich setze den „Sensitivity Level“ nun mal nicht auf 150, sondern 100. Vielleicht hilft Voodoo ja. Den „Basic Set Level“ muss ich wieder auf 255 setzen, sonst sendet der keinen ON Befehl. Speichern, wieder aufrufen, ok, Werte noch unversehrt. Daten übertragen… Wow, diesmal beim ersten Melder-Button-Klick. Werte im Thing noch ok? Ja. Funzt der Melder und die Rules nun? Nein. Nebenbei, die Werte für Helligkeit, Temperatur und Batterielevel werden ganz brav übertragen.

Neue Idee. Ich setze im Melder-Thing die Association-Group 2 auf den Controller. Denn ich hatte mit dieser Association ja schon die Steckdose direkt erfolgreich verheiratet – nun schicke ich das an den Controller – eigentlich doppelt gemoppelt, aber verzweifelten Heimautomationstestkaninchen wäre es mitterweile egal ob es „richtig“, WENN das Gebämse nur endlich funktionieren würde. *schluchz*
Ach was soll der Geiz – ich trage in alle 4 Association Groups den Controller ein.

Ich werd bekloppt – es geht. Alles, auch die Rules. Es funktioniert jetzt genauso wie wenn der Melder direkt mit der Steckdose gekoppelt ist, nur eben über den Controller / OpenHab, was ich auch daran sehe das gefunkt wird wenn vor dem Melder kontinuierlich Bewegung ist – und die Lampe dann auch an bleibt…
SOOOO kann man arbeiten…

Bin ich einfach ’n Happen blöd? Ich lese noch mal die Anleitung, und kann da nicht erkennen das es NÖTIG wäre den Controller per Association anzusprechen, zumal es zeitweise ja auch ohne geklappt hat.
Keine Ahnung ob das nun evtl. nachteilig für den Batterieverbrauch ist, aber es funzt nun hervorragend.

Gegenprobe: Alle Association Groups aus, ja, nun geht wieder nix mehr.
Group 1: Geht. Sendet 2-3 Frames. Seltsam: Wenn ich die Thing-Parameter wieder aufrufe ist in der Group 1 meist nichts mehr eingetragen. Auch ist das Popup dort ohne Checkboxen – man wählt das Item direkt.
Group 2: Geht nicht.
Group 3: Geht nicht.
Group 4: Geht. Sendet 1 Frame. Ok, energiesparender. Helligkeit und Temperatur werden  trotzdem ausreichend oft gesendet, Batterielevel sowieso…

Erster Reichweiten-Check

Gut, ich verbringe den Melder ein paar Meter weiter, ins Erdgeschoss. Keine geschlossene Tür, kein Beton, aber trotzdem kein Wuffwuff mehr (der Hunde-Sound per Rule bei Auslösung). Heißt: Kein Funkkontakt. Gut, nun soll Zwave ja so mega-smart sein, vielleicht funkt der Melder extra schwach um Energie zu sparen – er war ja den ganzen Tag nur wenige cm vom Controller… Also fummel ich an ganix rum und vertraue auf die selbstheilenden Kräfte des Funknetzes. Spätestens ja wohl um 4 Uhr morgens, wo die „Heal Time“ des Controllers eingestellt ist.

Nix, Wauwi hat Bellpause. Um den Controller-Stick günstiger zum Erdgeschoss zu positionieren stecke ich ihn an einen anderen Hub. Erstmal gibt’s aber ’ne Kernel-Panic, als ich den Stick rausziehe (steckt direkt am Mac), supi.

In den Melder-Things Settings stehen wieder Schrottwerte, und bei Association Group 4 ist der Controller nicht mehr eingetragen!!? Weil ich ihn an einem anderen USB-Port habe? Kann ja wohl kaum sein…
Und wieder das Spiel, Werte korrigieren, Save, in die Controller-Ansicht, Button in Melder drücken, paar Sekunden warten, die Frames rattern, ok – Daten übertragen, testen.
Geht nicht. Ah, die uninitialisierten Rules waren es wieder…
So, nun geht’s wieder.

Zwischendurch bekam ich mal neues, beim Beenden von OpenHab:
WARNING: EventAdmin: Exception: java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.FutureTask@339f0d0a rejected from java.util.concurrent.ThreadPoolExecutor@3d58e509[Shutting down, pool size = 2, active threads = 0, queued tasks = 0, completed tasks = 5248] (java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.FutureTask@339f0d0a rejected from java.util.concurrent.ThreadPoolExecutor@3d58e509[Shutting down, pool size = 2, active threads = 0, queued tasks = 0, completed tasks = 5248])

Um den Parameter-Murks mal methodisch anzugehen:
Parameter mehrmals eingestellt, übertragen. Sind nun im Thing ok.
Ich fummel nun nix rum, sondern gehe nur mit dem Melder durch dir Wohnung, Funk-Reichweite checken…
(Die Thing-Werte scheinen nun stabil zu bleiben, die nächsten 24h gab es keinen Murks mehr.)

Es läuft nun alles soweit. Hat ja kaum 100 Jahre gedauert, endlich Reichweite testen ohne ständig anderen Murks zu haben.

Ich bin mit der Reichweite zufrieden, aber nicht übermäßig beeindruckt. An den Stellen wo FS20-Melder stehen funzt es, mit Ausnahme des FS20-Melders der vom Controller aus gesehen hinter dem Kühlschrank & Toaster steht. Das macht allerdings gar nichts, denn den Melder würde ich eh lieber AUF dem Kühlschrank platzieren, was mit dem FS20-Melder nicht so wirklich ging. Da sind die Coolcam-Melder 5000x besser, weil megaaaa-frei einstellbar. Von der Größe und der Unauffälligkeit ganz zu schweigen…

Repeater

Im Zimmer schräg unter mir klappt es mit dem Bewegungsmelder noch bis zur Raummitte (Holzdecke), in der hintersten Ecke aber nicht mehr. Ich setzte nun die Schaltsteckdose in den Flur, vor der Zimmertür – das müsste dann ja repeaten und funzen:
Geht nicht – ich müsste nun wohl die Selbstorganisation des vermaschten Netzes abwarten, will ich natürlich nicht.
Im Melder-Thing, unter Show More, wähle ich „Heal the device“. 19:50 Uhr.
2-3 Minuten warten, nix.
Ich „heale“ auch die Steckdose. Aha, im Control sehe ich das der Controller haufenweise Frames sendet. Ob er das auch beim Melder-heal gemacht hatte weiß ich nicht, da war ich vielleich nicht schnell genug auf den Control-Pane.
Nix. Ich heale den Melder noch mal. Keine Frames. Noch mal. 5 Frames gesendet. Test: Nix. OpenHab relaunch (da soll wohl angeblich auch etwas Re-Organisation passieren. Nix.
Da ich die Reichweite von Gerät zu Gerät nicht kenne: Steckdose in den Raum gesetzt, Abstand nun 4-5 Meter zwischen Melder und Dose, sollte ja wohl auf jeden Fall reichen.
Scheiße, hatte vergessen das ich die Rules ja Aus/An machen muss, sonst geht eh nix…
Nebenbei werden Werte von der der Steckdose nicht mehr übertragen, außer Volt. Schalten kann ich sie aber.
Heal Steckdose, ca. 80 Frames gesendet.
Heal Melder, keine Frames werden gesendet.
OpenHab relaunch, Rules Aus/An.
Steckdose meldet immer noch nichts. Ähnlich wie im Melder, trage ich den Controller für Group 1 ein. Save, Thing wieder aufmachen – Group 1 Eintrag weg. Grrr. Ich trage den Controller in alle 3 Gruppen ein. Save. Tja, mehrmals, nur die Group 1 und 2 Einträge werden gesichert.
OpenHab relaunch, Rules…, Steckdosen-Werte kommen wieder. Schön, weiter im vermaschten Netz…
Werte vom Melder kommen nicht, und wenig überraschend passiert auch bei Auslösung nichts.
Werte von der Steckdose kamen auch nur einmal, nun wieder nix, außer Volt.
Für heute reicht’s – ich warte auf die wundersame nächtliche Selbstheilung, glaube aber irgendwie nicht dran…

Über Nacht hat der Melder einen Zufallstreffer gelandet, Helligkeit und Temperatur wurden mindestens einmal übertragen, Batteriestand aber nicht. Und Bewegungsereignisse werden weiterhin gar nicht übertragen.

Die Steckdose überträgt nun wieder alles, mehr oder minder, denn das Update für Amp und Watt kam früher mal nach spätestens ca. 5 Sekunden, es dauert nun viele viele Minuten. Randnotiz: kWh wurden noch nie übertragen.

Fazit

So weit, so schlecht. Es ergibt keinen Sinn das nun weiter zu testen, da sind SO viele Probleme drin das ich mal einen Bewegungsmelder und Steckdose eines anderen Herstellers bräuchte um zu prüfen welche Ungereimtheiten an OpenHab und welche möglicherweise an der Hardware liegen.

Außerdem muss ich mir mal HabMin anschauen, da kann man wohl das vermaschte Netz bewundern, dann muss man nicht völlig blind testen was den Status der Selbstorganisation des Netzes betrifft.
So wie ich das verstehe hätte der Melder selbst dafür sorgen müssen das er die Steckdose als Repeater nimmt, bzw die Steckdose dafür sorgen müssen das empfangene an den Controller zu leiten, und der muss dann kapieren das der Melderfunk repeated ist und eine Neu-Organisation einleiten… Das die Abstände irgendwo zu groß waren halte für sehr unwahrscheinlich. 4-5 Meter vom Melder zur Steckdose, das gleiche von Steckdose zum Controller.

Ich kann es nur vermuten, und glaube das in OpenHab die meisten Fehlerquellen liegen. Der Werte-Murks in den Thing-Settings, Thing-Settings die teilweise nicht abgespeichert werden, auch obwohl ich den Feld-muss-Fokus-verlieren-Bug beachtet habe, das Geräte als „Online“ angezeigt werden die offensichtlich außer Funk-Reichweite sind, und einiges mehr.
Es kann natürlich auch das Zwave-Binding sein, oder der Umstand das OpenHab bei mir auf’m Mac läuft, oder ein Java-Konstellations-Bug, … Da kann man nur raten… Der Controller-Stick käme natürlich auch noch in Frage.

Wenn man gar keine Erfahrung mit SÄMTLICHEN Komponenten hat und deren Qualität & Eigenschaften noch gar nicht einschätzen kann, dann ist man echt am Arsch. 🙄 😀

Links & Kommentare