OWServer / OWDevice

[Martin Fischer]

hiya @all,

Boris und ich werden in nächster Zeit gemeinsam an OWServer / OWDevice arbeiten. Aktuell habe ich eine neue Version von OWDevice eingecheckt. Es werden nun folgende 1-Wire Devices _vollständig_ (also inkl. _aller_ Special Properties, also z.B. auch direktes beschreiben / auslesen des Speichers sofern vorhanden, u.v.m.) unterstützt:

DS2401 - Silicon Serial Number
DS1990A - Serial Number iButton
DS2405 - Addressable Switch
DS18S20 - High-Precision 1-Wire Digital Thermometer
DS1920 - iButton version of the thermometer
DS2406, DS2407 - Dual Addressable Switch with 1kbit Memory
DS2436 - Battery ID/Monitor Chip
DS2423 - 4kbit 1-Wire RAM with Counter
DS2450 - Quad A/D Converter
DS1822 - Econo 1-Wire Digital Thermometer
DS2415 - 1-Wire Time Chip
DS1904 - RTC iButton
DS2438 - Smart Battery Monitor
DS2417 - 1-Wire Time Chip with Interrupt
DS18B20 - Programmable Resolution 1-Wire Digital Thermometer
DS2408 - 1-Wire 8 Channel Addressable Switch
DS2413 - Dual Channel Addressable Switch
DS1825 - Programmable Resolution 1-Wire Digital Thermometer with ID
LCD - LCD controller by Louis Swart

Darüber hinaus wird nun auch ein Hitachi HD44780 LCD controller in 4-bit/8-bit mode an einem DS2408 unterstützt.

Für eine ausführliche Beschreibung der möglichen Befehle sind die entsprechenden Manuals der obigen Devices unter owfs.org einzusehen.

Modulintern wurden einige Umstellungen im Bereich der Variablendeklaration vorgenommen, so dass der State nun ggf. anders aussehen wird. Im nächsten Schritt kommt die Alarmbehandlung sowie die Behandlung von iButtons (Stichwort: Present) hinzu, bei Countern das Setzen von einem festgelegtem Offset und Boris wird sich um die Möglichkeit von Berechnungen kümmern.

Wir bemühen uns, die Module weiterhin absolut generisch zu entwickeln, so dass jederzeit weitere Devices hinzugenommen werden können. Im Moment kann es daher noch zu einigen Anpassungen / Veränderungen kommen.

Gruß Martin

[dougie]

...00:16?! Du bist/ihr seid fleissig!

Habe gerade geupdated!

DS2413 - Dual Channel Addressable Switch

Stati der Ports werden jetzt einwandfrei erfasst! Vielen Dank!
Ich denke ich werde am Wochenende mit meiner Konfiguration "umziehen".

VG
Ralf

[Martin Fischer]

- alarm-handling für alle Devices die eine Alarmierung unterstützen hinzugefügt[1]
- Erkennung ob ID Devices (DS2401,DS1990A) präsent sind oder nicht

[1] Da OWDevice generisch ist, wird lediglich ein Alarm-Event für das jeweiligen Device erzeugt. Die Prüfung, welcher Alarm eingetreten ist muss manuell vorgenommen werden (z.B. via notify).

Gruss Martin

[Martin Fischer]

- autodiscovery hinzugefügt

Beim Start von FHEM werden alle noch nicht definierten 1-Wire Devices automatisch im Raum OWDevice angelegt.

Gruß Martin

Da sich noch ein Fehler eingeschlichen hat, wird die Funktion erst im Laufe des Wochenendes freigeschaltet!
Es war dann wohl doch etwas zu spät (oder früh) am morgen :-(

[eppi]

Hallo Martin
Ich habe heute die iButton in OWDevice eingebunden. GANZ GROSSES KINO, FUNKTIONIERT 1A - VIELEN DANK!

Wenn der Button auf dem Probe ist, wechselt der State auf "present: 1".

Ich habe mir erhofft, dass der iButton-Probe ebenfalls eine ID besitzt und somit ausgewertet werden kann, auf welchem Probe der iButton angebracht ist. Jedoch ist die einzige Elektronik die auf dem Probe vorhanden ist, die 2 LED's. Ich wollte verschiedene Probe einsetzen für Presence mit dem Schlüsselbrett aber auch um mein Garagentor zu öffnen, das geht nun aber nicht mit dem selben iButton. Oder hat da noch jemand eine Idee?

Ich habe zudem auch noch folgende Frage:
Wenn ich den iButton auf den Probe lege, dauert es einige Zeit (gefühlte 60 Sekunden) bis OWServer/OWFS merkt, dass ein Button hier ist. Wo kann ich diese Zeit einstellen (in owfs.conf)?

Danke und Gruss Dani

[MarkusN]

Hallo Dani,

Hallo Martin
Ich habe heute die iButton in OWDevice eingebunden. GANZ GROSSES KINO, FUNKTIONIERT 1A - VIELEN DANK!

Wenn der Button auf dem Probe ist, wechselt der State auf "present: 1".

Ich habe mir erhofft, dass der iButton-Probe ebenfalls eine ID besitzt und somit ausgewertet werden kann, auf welchem Probe der iButton angebracht ist. Jedoch ist die einzige Elektronik die auf dem Probe vorhanden ist, die 2 LED's. Ich wollte verschiedene Probe einsetzen für Presence mit dem Schlüsselbrett aber auch um mein Garagentor zu öffnen, das geht nun aber nicht mit dem selben iButton. Oder hat da noch jemand eine Idee?

Da hilft leider nur ein zweiter Busmaster.

Ich habe zudem auch noch folgende Frage:
Wenn ich den iButton auf den Probe lege, dauert es einige Zeit (gefühlte 60 Sekunden) bis OWServer/OWFS merkt, dass ein Button hier ist. Wo kann ich diese Zeit einstellen (in owfs.conf)?

Danke und Gruss Dani

Dafür gibt es verschiedene Möglichkeiten. OWFS selbst hat einen Cache. Jedoch kann man die Devices auch explizit uncached abfragen. Hier stellt sich mir die Frage welchen Weg owserver geht, vielleicht kann einer der Entwickler was dazu sagen?

Du hast jedenfalls die Möglichkeit in das Caching von OWFS anzupassen. Eine gute Anlaufstelle dafür ist diese Seite. Mein OWFS-Aufruf sieht bspw. so aus:

Code Auswählen Erweitern

/opt/owfs/bin/owserver -u -p 45678 --timeout_directory 3 --timeout_presence 3

Grüße,

Markus

[Martin Fischer]

hallo dani,

> Ich habe mir erhofft, dass der iButton-Probe ebenfalls eine ID besitzt und somit ausgewertet
> werden kann, auf welchem Probe der iButton angebracht ist.

leider nein. die probes haben leider keine eigene adresse. da kann auch ich nichts dran machen ;-)

> die auf dem Probe vorhanden ist, die 2 LED's. Ich wollte verschiedene Probe einsetzen für
> Presence mit dem Schlüsselbrett aber auch um mein Garagentor zu öffnen, das geht nun aber
> nicht mit dem selben iButton. Oder hat da noch jemand eine Idee?

da wird dir nur ein zweiter ibutton weiterhelfen oder du musst dein vorhaben so umstellen, das der
eine ibutton sowohl zu anwesenheitserkennung als auch als garagenöffner dient. denn wer will schon
mit einem schlüsselbund voller ibuttons rumlaufen?

> Ich habe zudem auch noch folgende Frage:
> Wenn ich den iButton auf den Probe lege, dauert es einige Zeit (gefühlte 60 Sekunden) bis
> OWServer/OWFS merkt, dass ein Button hier ist. Wo kann ich diese Zeit einstellen (in owfs.conf)?

auf was hast du denn den interval bei der device definition gesetzt? als ich das gestern eingebaut
hatte, da hatte ich zum testen immer 10 sekunden polling bei fhem. der owserver selber hat ihn
innerhalb von sekunden sofort gesehen. es kommt halt auch drauf an, in welchem interval fhem die
infos abholt.

darüber hinaus erfolgt die abfrage beim owserver über das caching, was aber nicht solch delays hat.
dennoch hatte ich schon mit boris besprochen, das ich demnächst noch einbauen werde, ob cached oder
uncached gelesen wird.

gruss martin

[eppi]

Hallo Markus
Danke für deine Hilfe!

Da hilft leider nur ein zweiter Busmaster.

Heisst das, dass OWFS einen zweiten Busmaster verwalten kann (zwei DS9490R) und dadurch die ID des iButton anderst aussehen würde? Wenn ja, wäre das durch aus eine Alternative für mich.

Das schnellere aktualisieren der Presence Time funktioniert perfekt, Danke für den Tip!

Gruss Dani

[MarkusN]

Hallo Dani,

die ID des iButtons ändert sich durch mehrere Busmaster nicht, owfs unterteilt den Bus dann jedoch auf mehrere logische Busse. Inwiefern man das mit FHEM und speziell mit owserver berücksichtigen kann/können wird können wieder nur die Entwickler beantworten ;).

Grüße,

Markus

[Martin Fischer]

hallo markus,

> Dafür gibt es verschiedene Möglichkeiten. OWFS selbst hat einen Cache. Jedoch kann
> man die Devices auch explizit uncached abfragen. Hier stellt sich mir die Frage
> welchen Weg owserver geht, vielleicht kann einer der Entwickler was dazu sagen?

hatte ich ja schon zuvor beantwortet. in meinen fhem 1-wire modulen hatte ich es
konfigurierbar. also ob cached oder uncached. das werde ich bei den neuen modulen
noch nachziehen.

gruss martin

[Martin Fischer]

> die ID des iButtons ändert sich durch mehrere Busmaster nicht, owfs unterteilt
> den Bus dann jedoch auf mehrere logische Busse. Inwiefern man das mit FHEM und
> speziell mit owserver berücksichtigen kann/können wird können wieder nur die
> Entwickler beantworten ;).

och menno. mein frauchen hat heute geburtstag, daher kommst du mir zuvor :-)

ja, owserver kann mehrere busmaster (und die können sogar unterschiedlich sein)
verwalten.

je busmaster hast du einen bus und diese werden von 0 beginned inkrementell
hochgezählt. im moment wird nur der "root"-pfad ausgewertet aber auch das thema
steht schon auf der todo.

es stehen noch weitere funktionen auf der todo aber erstmal müssen die grundfunktionen
soweit stehen.

gruss martin

[eppi]

Hallo Martin
Danke für deine Hilfe!

auf was hast du denn den interval bei der device definition gesetzt? als ich das gestern eingebaut
hatte, da hatte ich zum testen immer 10 sekunden polling bei fhem. der owserver selber hat ihn
innerhalb von sekunden sofort gesehen. es kommt halt auch drauf an, in welchem interval fhem die
infos abholt.

Meine Definition sieht so aus:

Code Auswählen Erweitern

Internals:
   DEF        01.684A9A150000 2
   IODev      OWFS
   NAME       ibutton01
   NR         741
   STATE      present: 1
   TYPE       OWDevice
   Readings:
     2013-01-12 20:15:55   address         01684A9A1500008E
     2013-01-12 20:15:55   present         1
     2013-01-12 20:15:55   state           present: 1
   Fhem:
     address    01.684A9A150000
     alerting   0
     interfaces id
     interval   2
     getters:
       address
       crc8
       family
       id
       locator
       r_address
       r_id
       r_locator
       type
     polls:
       address
     setters:
     state:
Attributes:
   model      DS2401

OWServer:

Code Auswählen Erweitern



Internals:
   CFGFN      /usr/share/fhem/FHEM/fhem_1wire.cfg
   DEF        192.168.2.5:4304
   NAME       OWFS
   NR         39
   STATE      Initialized
   TYPE       OWServer
   Fhem:
     protocol   192.168.2.5:4304
Attributes:



Kann da noch etwas bezüglich der Presence-Time optimiert werden?

ja, owserver kann mehrere busmaster (und die können sogar unterschiedlich sein)
verwalten.

je busmaster hast du einen bus und diese werden von 0 beginned inkrementell
hochgezählt. im moment wird nur der "root"-pfad ausgewertet aber auch das thema
steht schon auf der todo.

Heisst das Martin, dass OWServer/OWDevices demnächst auswerten können auf welchem Bus ein 1-Wire Device (bei mir iButton) angeschlossen ist? Damit erspare ich mir den "Hausmeisterschlüsselbund" :=)

Danke und Gruss Dani

[Martin Fischer]

hallo dani,

> Danke für deine Hilfe!

büdde, büdde :-)

> Meine Definition sieht so aus:
> [...]
> Kann da noch etwas bezüglich der Presence-Time optimiert werden?

also auf den ersten blick kann ich da nichts weiter erkennen. du pollst in 2 sec.
abstand und wenn ich deinen obigen beitrag richtig in erinnerung habe, hast du den
tip mit dem presence_timeout von markus schon befolgt.

einzig die möglichkeit des "uncached" auslesen _könnte_ es noch etwas pushen. kommt
aber auf einen test an.

> Heisst das Martin, dass OWServer/OWDevices demnächst auswerten können auf welchem
> Bus ein 1-Wire Device (bei mir iButton) angeschlossen ist? Damit erspare ich mir
> den "Hausmeisterschlüsselbund" :=)

jepp! genau das heisst es :-) weiss aber noch nicht in welchem zeitraum ich das schaffe,
wobei ich jetzt nicht von monaten spreche. muss mir da noch 'ne saubere logik überlegen.

gruss martin

[Martin Fischer]

OWServer:

- autodiscovery überarbeitet

Beim Starten von FHEM werden alle erkannten 1-Wire Devices im Raum "OWDevice" angelegt und alle 60 Sekunden gepollt, sofern das FHEM-eigene "autocreate" aktiviert ist. Bereits definierte 1-Wire Devices werden erkannt und übersprungen. Nicht mehr vorhandene 1-Wire Devices werden _nicht_ gelöscht.

"Puristen" die "autocreate" disabled oder nicht definiert haben, legen die 1-Wire Devices wie gewohnt an.

Gruss Martin

[Martin Fischer]

OWServer:

- owserver (owfs) einstellungen als readings hinzugefügt[1]
- owserver (owfs) einstellungen können zur laufzeit aus fhem gesetzt werden[2]
- owserver (owfs) fehler statistiken können abgerufen werden[3]

[1] folgende readings werden während der device definition (oder manuell via "get" befehl) ausgelesen:
/settings/timeout/directory
/settings/timeout/ftp
/settings/timeout/ha7
/settings/timeout/network
/settings/timeout/presence
/settings/timeout/serial
/settings/timeout/server
/settings/timeout/stable
/settings/timeout/uncached
/settings/timeout/usb
/settings/timeout/volatile
/settings/timeout/w1
/settings/units/pressure_scale
/settings/units/temperature_scale

[2] zum setzen der einstellungen des owservers (owfs) werden folgende befehle akzeptiert:
timeout/directory
timeout/ftp
timeout/ha7
timeout/network
timeout/presence
timeout/serial
timeout/server
timeout/stable
timeout/uncached
timeout/usb
timeout/volatile
timeout/w1
units/pressure_scale
units/temperature_scale

[3] folgende fehlerstatistiken können via "get <name> errors" angerufen werden:
BUS bit errors
BUS byte errors
BUS detect errors
BUS echo errors
BUS level errors
BUS next alarm errors
BUS next errors
BUS readin data errors
BUS status errors
BUS tcsetattr errors
CRC16 errors
CRC16 tries
CRC8 errors
CRC8 tries
DS2480 level docheck errors
DS2480 read fd isset
DS2480 read null
DS2480 read read
NET accept errors
NET connection errors
NET read errors
max delay

TODO:
die set / get befehle in die doku aufnehmen..

viel spaß und gute nacht...

martin