Openhab + OneWire + iButton

[ArPa]

Hmm, muss ich heute noch Mal mit 6s testen, vielleicht gibt es ja ein Limit nach unten von 5s oder so? Jedenfalls bringt die im github HowTo angegebene timeout_presence von 2s überhaupt nichts.

[abodenbe]

Hallo,
ja das funktioniert, allerdings nur mit dem Eintrag "timeout_presence = 6s" in der /etc/owfs.con ansonsten dauert es 120s.

[ArPa]

Hallo Dennis,
hat gekplappt. Habe in der owfs.conf derzeit den timeout_presence auf 6s gesetzt.

Und das funktioniert wirklich abodenbe ? Ich meine, ändert sich der Status nach spätestens 6 Sekunden wieder auf "Undefined" wenn Du den iButton entfernst?

Also bei mir (openhab 2 + OneWire Binding 1.9.0.RC1) kann ich machen was ich will, das entfernen des iButtons merkt openhab erst nach ziemlich genau 120 Sekunden.

==> /var/log/openhab2/scripts.log <==
2017-06-12 16:17:01.852 [INFO ] [home.model.script.99-DummyTest.rules] - iButton state changed to: XXXXXXXXXXXX
2017-06-12 16:19:00.987 [INFO ] [home.model.script.99-DummyTest.rules] - iButton state changed to: UNDEF

Der Parameter ";ignoreReadErrors" hilft bei mir zumindest auch die ständigen Exceptions im Log zu unterdrücken.

[Dennis650]

Hallo,

Thomas hat den PullRequest gemerged.

Er bat darum den Wiki Eintrag anzupassen (mit einem Hinweis auf Release 1.8): https://github.com/openhab/openhab/p...vent-491552100

Kannst Du das erledigen? Sonnst kann ich da auch machen.

Gruß
Dennis

[abodenbe]

Hallo Dennis,
hat gekplappt. Habe in der owfs.conf derzeit den timeout_presence auf 6s gesetzt.
Wiki nehme ich mir die nächsten Tage mal vor.
Vielen Dank für deine schnelle Arbeit.
Überlege gerade was ich damit noch alles basteln kann, das ist ein nettes Feature, hatte auch mal iBeacons überlegt, aber das Telefon schleppe ich nicht immer mit rum.
Gruß Ansgar

[Dennis650]

Hallo,

ich habe einen PullRequest erstellt: https://github.com/openhab/openhab/pull/3534

Gruß
Dennis

[Dennis650]

Hi.

prima. Ich erstelle dann einen PullRequest. Vermutlich morgen Abend. Wenn Du willst kannst Du ja das WiKi schon anpassen, mit dem Hinweis, dass der PullRequest noch nicht in der Nightly enthalten ist und einen Link auf die DropBox Testversion setzen. Wenn der PullRequest gemerged wurde, kann ich den Hinweis dann einfach entfernen.

Das mit dem Parameter timeout_presence klappt auch wie gedacht?

Vielen Dank und Gruß
Dennis

[abodenbe]

Hallo Denis,

ja habe es seit zwei Tagen am laufen. Hier ein Auszug aus der Konsole:

16:13:04.514 INFO runtime.busevents[:26] - OneWireKeyRed state updated to Undefined
16:13:06.433 INFO runtime.busevents[:26] - OneWireKeyRed state updated to 00001111111

Fehler sind bis jetzt noch nicht aufgetreten.
Vielen Dank.

Doku im Wiki würde ich dich unterstützen, wenn du Interesse hast.

Gruß Ansgar

[Dennis650]

Hi,

konntest Du schon testen? Am 16.12. wird wohl CodeFreeze für die 1.8 Version von OpenHab sein. Dann könnte ich noch einen PullRequest mit den Änderungen für das Release machen.

Gruß
Dennis

[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

[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,

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

[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

[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

[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