Openhab + OneWire + iButton

[ArPa]

Hi zusammen,

jemand hier, der diese Kombination im Einsatz hat?

Mache gerade einen Testaufbau zum Einsatz des iButtons als Schlüsselersatz. Allerdings habe ich gerade das Gefühl, dass die aktuelle Implementierung das gar nicht zulassen wird.

Ich mache jede Sekunde (damit man später nicht 20 Sekunden vor der Tür steht, bis der Schlüssel gelesen wird) ein Polling auf eine DeviceId. Wenn die DeviceId dann da ist, lese ich die r_id des iButton Holders aus und lasse Sie mir im Moment in der Openhab Oberfläche anzeigen. Funktioniert soweit prima.

Entferne ich nun den iButton Holder vom iButton Probe, sehe ich die r_id noch sehr lange in der Oberfläche. Egal ob ich

onewire: post_only_changed_values=false

oder

true

setze.

Würd mich gerne mal mit jemandem austauschen der den iButton mit dem OWServer und dem One-Wire Binding nutzt.

Beste Grüße,
Artur

[ArPa]

Hmm, dachte mir schon, dass das nicht soo viele sein werden Naja, ich werde dann mal berichten wenn ich das stabil zum laufen bekommen habe...

[michaeljk]

Ich habe das ganze zwar noch nicht selbst im Einsatz, würde aber künftig gerne ein "digitales Schlüsselbrett" realisieren. Angedacht waren hierzu verschiedene iButtons welche am Schlüsselbund der jeweiligen Personen befestigt werden - sobald der Kontakt hergestellt wird, wüsste die Zentrale das die jeweilige Person im Haus/Stockwerk ist. Natürlich wäre es mir auch wichtig den Status zeitnah aktualisieren zu können. Hast du bereits nachgeschaut, ob die Aktualisierung seitens des OWServer oder von openHAB aus solange dauert?

[abodenbe]

Hallo,

mich interessiert es auch, hatte schon mal dazu einen Feature Request gestellt. Nach meiner Ansicht unterstützt das Binding nur Werte für einen bestimmten Sensor wie z.B Nr/ temperature oder Nr/Countach open
Bei ibutton stellt sich die Frage ist Nr present oder nicht present.
Gruß Ansgar

[ArPa]

Hi zusammen,

schön, dass es doch den einen oder anderen gibt, den diese Kombination interessiert. Ich kann zunächst mal soviel sagen, als dass die Digitale ID eines iButtons ausgelesen werden kann. Der OWServer liefert das Attribut "r_id" aus. Das ist gut, denn diese "geheime" ID soll ja später dazu dienen zu entscheiden, darf jemand durch die Tür oder nicht, bzw. bei Dir michaeljk, wer ist zu Hause und wer nicht.

Zwei kleine Probleme habe ich bisher festgestellt. Ich habe dazu auch schon probiert jemanden im offiziellen Openhab Diskussionsforum zu erwischen aber noch keine Rückmeldung erhalten. Wahrscheinlich wird es darauf hinaus laufen, dass ich zumindest den Error Log Eintrag irgendwie selber im Binding fixen muss, wenn ich da keinen antreffe, der sich zuständig fühlt.

Das andere Thema sind etwa 120 Sekunden, bis OWServer oder One-Wire Binding merken, dass ein iButton nicht mehr am Kontakt ist. Das finde ich etwas lang. Das muss irgend ein Timeout Wert sein. Hier versuche ich mal was in den Dokumentationen zu finden.

Beste Grüße,
Artur

PS: Openhab Thema ist unter: https://community.openhab.org/t/one-...g-ibutton/4395
33 Hits aber noch keine Antwort. Wahrscheinlich mache ich einfach nur wieder Dinge, die noch nie jemand mit Openhab in der Kombination gemacht hat

[Dennis650]

Hi,

ich habe das OneWireBinding neulich mal grundlegend überarbeitet und um einige Features erweitert. Eine Anforderung bezgl. iButtons innerhalb einer anderen Anforderung hatte ich gefunden. Nach einer Rückfrage hat sich der Ersteller des Tickets scheinbar dazu nicht gemeldet. Ich meine das Ticket wurde daraufhin geschlossen und nicht umgesetzt.

Ich habe das Problem, dass ich keine iButtons habe, mich mit dem Funktionsprinzip von iButtons noch nicht beschäftigt habe, nicht ausprobieren konnte wie sich diese Verhalten und somit auch schlecht was dazu programmieren konnte.

Ich habe gerade nicht die Zeit alles hier konzentriert zu lesen und bin nur zufällig darauf gestoßen. Ich habe im Moment nicht viel Zeit für OpenHab. Gibt es jetzt irgendwelche Dinge die das Binding nicht auslesen kann oder es zu Fehlern kommt? Was muss angepasst werden? Falls ich was implementieren soll, kann mir jemanden einen Leihweise für die Implementierungs- und Testphase zur Verfügung stellen?

Das der iButton so lange benötigt, bis er aus dem owserver verschindet, liegt vermutlich am ow-Konfigurationsparameter:
--timeout_presence=120
Seconds until the presence and bus location of a 1-wire device expires in the cache.Can be changed dynamically at /settings/timeout/presence
(siehe http://owfs.org/uploads/owserver.html).

Der owserver cached sehr viel, um Traffic auf dem Bus einzusparen: http://owfs.org/index.php?page=what-is-uncached

Evtl. hilft es das Device mit uncached/28.67C6697351FF anzusprechen.

Gruß
Dennis

[ArPa]

Hi,

schön von Dir zu lesen. Also das witzige ist ja, dass der OWServer glaube ich in dieser Hinsicht nicht sauber funktioniert. Das Binding kann da gar nichts dafür, wenn ich das richtig sehe.

Jedenfalls sind diese cached und uncached Pfade völlig wertlos. Zumindest bei mir. Das kann jeder mal ausprobieren.

Wenn ich im Openhab nun ein item konfiguriere, sagen wir mal z.B. so

String OneWireKeyBlack "Schlüssel Schwarz [%s]" <key> {onewire="deviceId=uncached/01.234567890000;propertyName=r_id;refreshinterval=2"}

Dann ist das dem Binding scheinbar egal ob da vorne eine uncached steht oder nicht. Auch hier ziehen die 120 Sekunden bis der String wieder nichts anzeigt.

Rufe ich den OWServer aber direkt auf z.B. so http://<serverIP>:2121/uncached/01.234567890000 dann sehe ich kurz danach im Openhab Log, dass auch Openhab keinen Wert mehr zu dem iButton bekommt weil die Device ID nicht mehr vorhanden ist (auch nach deutlich weniger als 120 Sekunden). Witzigerweise baut sich die OWServer Seite unter http://<serverIP>:2121/uncached/01.234567890000 erst einmal auf, bevor es beim zweiten Mal auch im Browser keine Daten mehr gibt.

Ich kann es mir gerade nicht so recht erklären. Also entweder ruft das Binding die Daten nicht richtig uncached auf oder der OWServer reagiert nur auf einen echten HTTP Request im uncached Zweig. Irgendwas in der Richtung wird es sein.

Das zweite Problem sind wie erwähnt die Exceptions im Log. Wenn man einen iButton benutzt muss man ein Polling auf Device IDs machen die tatsächlich nicht da sind, so lange nicht der korrekte iButton Holder dran gehalten wird. Das Log läuft voll von Exceptions für Device IDs die es nicht gibt. Leider ist aber genau das die korrekte Vorgehensweise bei dem iButton. Eine Device ID ist erst erreichbar wenn der Holder am Probe ist. Es ist also der Normalfall. Hier müsste man das Exception Logging so umbauen, dass in einem solchen Fall vielleicht eine Debug Information geloggt wird aber keinesfalls eine Exception. Erhöht man das Log Level auf Error, würde man solche Infos dann los werden.

Ich werde dazu mal in den nächsten Tagen Log Ausgaben generieren im Debug Modus. Vielleicht wird es dann klarer...

Beste Grüße,
Artur

PS: So ein iButton Probe und iButton Holder kosten zusammen nicht mehr als 20€ inkl. Versand

[abodenbe]

Hallo,

wobei ich das Verhalten des uncahced Verzeichnisses nachvollziehen kann.
Die Button ID verschwindet sofort aus dem uncahced Verzeichniss, der Wert der r-ID nicht, der braucht 120s.
Versuche es mal ohne Webroweser direkt mit owdir und owread in der Kommandozeile.
Ansgar

[Dennis650]

Hi,

das mit dem uncached war nur ne Idee für eine alternative Lösung. Die bessere, saubere und einfachere Lösung ist einfach den Wert timeout_presence auf die gewünschte Zeit zu setzen :-)

Das mit dem unterdrücken des Error-Loggings müsste konfigurierbar gemacht werden für ein Item. Dann haben auch gleich die anderen User mit instabilen Bus eine Möglichkeit Fehlermeldungen zu unterdrücken, das war hier auch schonmal Thema.

[CODE]PS: So ein iButton Probe und iButton Holder kosten zusammen nicht mehr als 20€ inkl. Versand [/QUOTE]

Wie soll ich das nun verstehen? Ich habe es so verstanden:
Ich opfere meine Freizeit um Euch was zu programmieren, an dem ich überhaupt kein Interesse habe, soll dafür auch noch 20 EUR ausgeben zum Testen und entsorge das Ding hinterher?

Gruß
Dennis

[ArPa]

Hi,

das mit dem uncached war nur ne Idee für eine alternative Lösung. Die bessere, saubere und einfachere Lösung ist einfach den Wert timeout_presence auf die gewünschte Zeit zu setzen :-)

Das mit dem unterdrücken des Error-Loggings müsste konfigurierbar gemacht werden für ein Item. Dann haben auch gleich die anderen User mit instabilen Bus eine Möglichkeit Fehlermeldungen zu unterdrücken, das war hier auch schonmal Thema.

PS: So ein iButton Probe und iButton Holder kosten zusammen nicht mehr als 20€ inkl. Versand

Wie soll ich das nun verstehen? Ich habe es so verstanden:
Ich opfere meine Freizeit um Euch was zu programmieren, an dem ich überhaupt kein Interesse habe, soll dafür auch noch 20 EUR ausgeben zum Testen und entsorge das Ding hinterher?

Gruß
Dennis

Hmm, ob das nicht etwas zu weit geschossen ist? Ich mein, das wäre ja dann so, dass man das Log-Level pro One-Wire Item definieren könnte. Würde ich zwar nicht so machen aber ist ein Ansatz.

Und das mit dem Preis für eine Minimalausrüstung eines iButtons war jetzt so gar nicht gemeint. Nicht böse verstehen. Ich hab jetzt nicht gedacht, dass Du das so einschätzt, dass Du Zeit und Geld opferst für etwas an dem Du "überhaupt kein Interesse" hast. Wenn das so ist, würde ich da auch keinen Cent für ausgeben. Alles gut... Dachte nur, wenn jemand an so einem Binding arbeitet, wird er/sie das sicherlich auch im Einsatz haben...

Ich mache mich dann mal auf die Suche, nach dem timeout_presence Wert und schaue wie sich das System da verhält.

Jetzt mal eine andere Frage: Ich bin selbst sehr erfahrener Software Engineer und spiele schon länger mit dem Gedanken direkt an der Entwicklung von Openhab/Bindings mit zu wirken. Im Falle des One-Wire Bindings kann ich Probleme und Fixes praktisch aus erster Hand Analysieren und an Lösungen arbeiten.

Was muss ich tun und was brauche ich, um Dich bei der Entwicklung des Bindings aktiv in Sachen Quellcode zu unterstützen?

Beste Grüße,
Artur

[ArPa]

Hallo,

wobei ich das Verhalten des uncahced Verzeichnisses nachvollziehen kann.
Die Button ID verschwindet sofort aus dem uncahced Verzeichniss, der Wert der r-ID nicht, der braucht 120s.
Versuche es mal ohne Webroweser direkt mit owdir und owread in der Kommandozeile.
Ansgar

Erschließt sich mir jetzt zwar nicht so ganz als besonders logisch, denn uncached bedeutet nach meinem Verständnis, dass ich komplett uncached arbeite, also egal ob nun Device ID oder irgendwelche Werte zu diesem Device aber gut... Ich probiere wie gesagt mal mit der timeout_presence rum zu spielen und begebe mich am Wochenende mal auf die Suche, wo diese hinterlegt wird...

Danke und beste Grüße,
Artur

[Dennis650]

Hmm, ob das nicht etwas zu weit geschossen ist? Ich mein, das wäre ja dann so, dass man das Log-Level pro One-Wire Item definieren könnte. Würde ich zwar nicht so machen aber ist ein Ansatz.

Hi,

was schlägst Du vor?

Aus meiner Sicht wird das ein Parameter, mit dem man gezielt die Fehlermeldungen bei nicht finden der DeviceID umwandelt in DEBUG-Ausgaben. Das ist doch genau das, was benötigt wird, um nicht das Log vollzuschreiben.
Hat man andere OneWireDevices im Bus will man von denen (Default) natürlich die Fehler sehen, wenn ein Device nicht gefunden wird (z.B. Temperatursensoren, Schaltbausteine, ...). Es geht hier um die gezielte Unterdrückung der Exceptions für einzelne Devices, eigentlich nur für iButtons. Das wäre kein großer Aufwand.

Jetzt mal eine andere Frage: Ich bin selbst sehr erfahrener Software Engineer und spiele schon länger mit dem Gedanken direkt an der Entwicklung von Openhab/Bindings mit zu wirken. Im Falle des One-Wire Bindings kann ich Probleme und Fixes praktisch aus erster Hand Analysieren und an Lösungen arbeiten.

Was muss ich tun und was brauche ich, um Dich bei der Entwicklung des Bindings aktiv in Sachen Quellcode zu unterstützen?

Beste Grüße,
Artur

Wie man sich eine Entwicklungsumgebung einrichtet, das ist perfekt im WIKI beschrieben. Dann kann jeder seine Änderungen über einen Pull Request einreichen. Die Änderungen sollten aber vorher im offiziellen englischen OpenHab Forum diskutiert werden, nicht das man sich Arbeit macht und der PullRequest abgelehnt wird.

Ich bin noch nicht so ganz warm mit git und github. Da ensteht für micht immer der meiste Aufwand. Die Implementierung von solchen Features / BugFixes ist bei einem Binding ja keine große Arbeit.

Gruß
Dennis

[Dennis650]

Hi,

ich habe das Unterdrücken von Fehlern beim Lesen von einzelnen Items implementiert.

Hier eine Version des Bindings zum Testen:
https://www.dropbox.com/s/veov5iz412...42124.jar?dl=0

Der neue Parameter heißt: ignoreReadErrors

Also wäre eine Konfiguration:

String OneWireKeyBlack "Schlüssel Schwarz [%s]" &lt;key&gt; {onewire="deviceId=01.234567890000;propertyName=r_ id;refreshinterval=2;ignoreReadErrors"}

Könnt ihr das mal Testen und Feedback geben?

Was macht die Einstellung: timeout_presence
Hat das funktioniert?

Gruß
Dennis

[abodenbe]

Hallo Dennis,

vielen Dank ich habe das Binding ausprobiert. Das Mapping auf die r_id funktioniert, auch die Fehlerunterdrückung.

Wenn allerdings der iButton nicht präsent ist, ist der Status unknown. Für diesem Fall erscheint ständig (im Sekundentakt) ein "runtime.busevents" mit der Meldung "status unknown".

Gruss Ansgar

[Dennis650]

Hi Ansgar,

>>>"runtime.busevents" mit der Meldung "status unknown".
Kannst Du da mal eine Zeile aus dem Log File posten. Status unknown ist mir nicht bekannt.

Eigentlich sollte das so aussehen. Im Fehlerfall wird beim Lesen der Typ Undefined für ein Item gesetzt. iButton state updated to Undefined

Um etwas Last vom Bus zu nehmen habe ich auch im Fehlerfall nun das Caching (sofern aktiviert <- default) eingebaut.

Hier eine neue Version: https://www.dropbox.com/s/jrwe67zp2b...72256.jar?dl=0

Gruß
Dennis