OWServer / OWDevice

dougie · 13 Januar 2013, 10:24:42

Guten Morgen zusammen!! Wieder mal mehr als nur beeindrucken, was hier abläuft! Ich denke wir alle stehen tief in eurer Schuld!

Aber ich hab da was, was ich sagen soll?! :-))

2013.01.13 10:11:30 0: Server shutdown
2013.01.13 10:11:35 1: Including /etc/fhem.cfg
2013.01.13 10:11:37 3: tPort: port 7072 opened
2013.01.13 10:11:38 3: WEB: port 8083 opened
2013.01.13 10:11:38 3: WEBphone: port 8084 opened
2013.01.13 10:11:38 3: WEBtablet: port 8085 opened
2013.01.13 10:11:39 3: Opening CUL_0 device /dev/ttyACM0
2013.01.13 10:11:40 3: Setting CUL_0 baudrate to 9600
2013.01.13 10:11:40 3: CUL_0 device opened
2013.01.13 10:11:40 3: CUL_0: Possible commands: BCFiAGMRTVWXefmltux
2013.01.13 10:11:40 3: Opening COC_1 device /dev/ttyAMA0
2013.01.13 10:11:40 3: Setting COC_1 baudrate to 38400
2013.01.13 10:11:40 3: COC_1 device opened
2013.01.13 10:11:40 3: COC_1: Possible commands: mBCFAZOGMRTVWXefltux
2013.01.13 10:11:40 2: Switched COC_1 rfmode to HomeMatic
2013.01.13 10:11:45 3: Opening CUNO_DMX device 192.168.1.24:2323
2013.01.13 10:11:45 3: CUNO_DMX device opened
2013.01.13 10:11:45 3: CUNO_DMX: Possible commands: mBCFDiAGMRTVWXOefltuxEcq
2013.01.13 10:11:46 3: OW_Temp_Test: I/O device is OWS_Casa
2013.01.13 10:11:47 3: OW_Switch_Test: I/O device is OWS_Casa
2013.01.13 10:11:47 3: LCD: I/O device is OWS_Casa
2013.01.13 10:11:47 3: OWServer_1ID: I/O device is OWS_Casa
2013.01.13 10:11:48 3: OW_Remote_Temp: I/O device is OWS_MansCave
2013.01.13 10:11:49 1: Including /var/log/fhem/fhem.save
2013.01.13 10:11:51 2: OWS_Casa: Autocreate: unknown familycode '10' found. Please report this!
2013.01.13 10:11:51 0: Server started (version Fhem 5.3 (DEVELOPMENT), $Id: fhem.pl 2459 2013-01-09 09:14:30Z rudolfkoenig $, pid 3065)

Martin Fischer · 13 Januar 2013, 21:02:40

OWServer / OWDevice:

- Lokalisierung von ID Devices (DS2401 DS1990A)[1]
- unknown familycode gefixed

[1] "Serial Number 1-wire Slaves" haben ein neues reading "location". Dadurch ist es möglich, die Position des Slaves, z.B ein iButton, im 1-Wire Bus zu ermitteln. Bei Busmastern mit Serial Number wird ebenfalls ein reading "location" erzeugt, um anzuzeigen für welchen 1-Wire Bus diese eingesetzt werden.

Beispiele:

Busmaster:

Code Auswählen

   Readings:
     2013-01-13 20:30:25   id              A7C02F000000
     2013-01-13 20:30:25   location        bus.2
     2013-01-13 20:30:25   present         1
     2013-01-13 20:30:25   state           present: 1

iButton an Probe im "bus.0":

Code Auswählen

   Readings:
     2013-01-13 20:32:28   id              18B0B4140000
     2013-01-13 20:32:28   location        bus.0
     2013-01-13 20:32:28   present         1
     2013-01-13 20:32:28   state           present: 1

Selbiger iButton an Probe im "bus.2":

Code Auswählen

   Readings:
     2013-01-13 20:33:57   id              18B0B4140000
     2013-01-13 20:33:57   location        bus.2
     2013-01-13 20:33:57   present         1
     2013-01-13 20:33:57   state           present: 1

Selber iButton ist auf Reise, also "abwesend":

Code Auswählen

   Readings:
     2013-01-13 20:35:30   id              18B0B4140000
     2013-01-13 20:35:30   location        absent
     2013-01-13 20:35:30   present         0
     2013-01-13 20:35:30   state           present: 0

Anmerkung:
Um z.B. iButtons zu "verfolgen" muss man sein 1-Wire Netz in mehrere Busse unterteilt haben. Z.B. nach Kellergeschoß, Erdgeschoß, Obergeschoß, Garage, etc. Für jedes "Teilnetz" wird ein eigener Busmaster eingesetzt. Welcher das ist (seriell, USB, i2c, etc.) spielt dabei keine Rolle.

Das Ganze kann man mit einem owserver (owfs) an dem alle Busmaster hängen realisieren aber auch mit mehreren owservern (owfs) die untereinander bekannt sind machen. Wie das in owserver (owfs) konfiguriert wird, entnimmt man bitte den entsprechenden manuals (owfs.conf).

Hier nur kurz ein Beispiel für mehrere USB Busmaster (DS9490R) an einem owserver:

Code Auswählen

# setup owserver's port
server: port = 4304
# all programs BUT not owserver see this line
!server: server = localhost:4304

# setup owserver's device
# only owserver connects to the USB device
server: usb = all

# setup owhttpd's port
http: port = 3001

Entscheidend ist der Eintrag "usb = all". Jeder DS9490R ist dann als eigenständiger Bus zu sehen. Aktuell wird das "Aufspüren" der Serial Number Slaves nur in einer Dimension erkannt. Das heisst, dass bei Slaves mit Serial Number nur der erste Bus zu erkennen ist.

Beispiel:
bus.0
- erster DS9490R Busmaster => location = bus.0
bus.1
- zweiter DS9490R Busmaster => location = bus.1
bus.2
- erster IP-Extender, TCP-Verbindung => location = bus.2
bus.2/bus.0
- erster DS9490R Busmaster am IP-Extender => location = bus.2 (oder aber auch leer, da ich dazu aktuell keine Testumgebung aufgebaut habe)

Nicht beirren lassen:
Schaut man sich das Ganze über owhttpd an, dann stellt die Verbindung vom owhttpd zum owserver ebenfalls ein Bus dar. Obiges Beispiel wird in owhttpd wie folgt abgebildet:
bus.0
- verbindung owhttpd zum owserver
bus.0/bus.0
- erster DS9490R Busmaster => location = bus.0
bus.0/bus.1
- zweiter DS9490R Busmaster => location = bus.1
bus.0/bus.2
- erster IP-Extender, TCP-Verbindung => location = bus.2
bus.0/bus.2/bus.0
- erster DS9490R Busmaster am IP-Extender => location = bus.2 (oder aber auch leer, da ich dazu aktuell keine Testumgebung aufgebaut habe)

Dies ist jedoch nur die Struktur aus Sicht von owhttp.

Viel Spaß damit!

Gruß Martin

eppi · 14 Januar 2013, 08:40:51

Hallo Martin

Zitatweiss aber noch nicht in welchem zeitraum ich das schaffe,
wobei ich jetzt nicht von monaten spreche. muss mir da noch 'ne saubere logik überlegen

Das hast du wieder in Rekordzeit geschafft! :=) HERZLICHEN DANK!

Funktioniert perfekt! Ich habe an je einem Busmaster einen iButton angeschlossen. Dies sieht so aus:
iButton01:

Code Auswählen

Internals:
   DEF        01.684A9A150000 2
   IODev      OWFS
   NAME       ibutton01
   NR         740
   STATE      present: 1
   TYPE       OWDevice
   Readings:
     2013-01-14 08:19:53   address         01684A9A1500008E
     2013-01-14 08:33:37   id              684A9A150000
     2013-01-14 08:33:37   location        bus.0
     2013-01-14 08:33:37   present         1
     2013-01-14 08:33:37   state           present: 1
   Fhem:
     address    01.684A9A150000
     alerting   0
     bus        bus.1
     interfaces id
     interval   2
     getters:
       address
       crc8
       family
       id
       locator
       r_address
       r_id
       r_locator
       type
     polls:
       id
     setters:
     state:
Attributes:
   model      DS2401

iButton02:

Code Auswählen



Internals:
   DEF        01.E1619A150000 02
   IODev      OWFS
   NAME       ibutton02
   NR         741
   STATE      present: 1
   TYPE       OWDevice
   Readings:
     2013-01-14 08:19:53   address         01E1619A1500007A
     2013-01-14 08:37:35   id              E1619A150000
     2013-01-14 08:37:35   location        bus.1
     2013-01-14 08:37:35   present         1
     2013-01-14 08:37:35   state           present: 1
   Fhem:
     address    01.E1619A150000
     alerting   0
     bus        bus.1
     interfaces id
     interval   02
     getters:
       address
       crc8
       family
       id
       locator
       r_address
       r_id
       r_locator
       type
     polls:
       id
     setters:
     state:
Attributes:
   model      DS2401

Cool!!!

Jetzt muss ich mir nur noch den Notify überlegen, der das "location" Reading berücksichtigt...

Danke nochmals und Gruess Dani

Martin Fischer · 14 Januar 2013, 10:22:25

hallo dani,

schön, das es zitat "perfekt funktioniert" ;-)

mir ist da noch was aufgefallen:
das readings "address" wird nicht mehr gesetzt, da ich dieses durch das reading "id" ersetzt habe. entweder löscht du es manuell über einen "perleinzeiler" (wenn du weisst wie) oder du beendest fhem kurz und editierst die fhem.save.

anderer punkt:

Code Auswählen

Internals:
   Readings:
     2013-01-14 08:19:53   address         01684A9A1500008E
     2013-01-14 08:33:37   id              684A9A150000
     2013-01-14 08:33:37   location        bus.0
     2013-01-14 08:33:37   present         1
     2013-01-14 08:33:37   state           present: 1
   Fhem:
     address    01.684A9A150000
     alerting   0
     bus        bus.1
[...]

hier ist mir aufgefallen, das in den readings "bus.0" in dem modulinterna aber "bus.1" steht, was durchaus richtig sein "kann". ich schliesse daraus, dass du den ibutton während der der devicedefinition an bus.1 hattest und ihn bei dem obigen beispiel an einem probe an bus.0 hast. korrekt?

es spielt zwar keine rolle für die "verfolgung" des ibuttons aber es könnte ggf. auch ein fehler im modul sein.

gruss martin

dougie · 14 Januar 2013, 10:31:12

...ich hab noch was "kosmetisches"...

Beim Start des Systems arbeitet fhem die OWDevices offensichtlich entlang ihrer Definition in der fhem.cfg ab.
Im Falle meies 2413 und 2450 am Ende der Konfig (sind zuletzt dazu gekommen), werden die zunächst automatisch dem falschen (von zwei) OWServer zugeordnet, und generieren die Fehlermeldung.
Im Anschluss erkennen sie aber auch automatisch das gesetzte attr mit dem richtigen Server, und laufen einwandfrei.

VG
Ralf

Code Auswählen

2013.01.14 10:22:15 1: Including /etc/fhem.cfg
2013.01.14 10:22:17 3: tPort: port 7072 opened
2013.01.14 10:22:18 3: WEB: port 8083 opened
2013.01.14 10:22:18 3: WEBphone: port 8084 opened
2013.01.14 10:22:19 3: WEBtablet: port 8085 opened
2013.01.14 10:22:20 3: Opening CUL_0 device /dev/ttyACM0
2013.01.14 10:22:20 3: Setting CUL_0 baudrate to 9600
2013.01.14 10:22:20 3: CUL_0 device opened
2013.01.14 10:22:21 3: CUL_0: Possible commands: BCFiAGMRTVWXefmltux
2013.01.14 10:22:21 3: Opening COC_1 device /dev/ttyAMA0
2013.01.14 10:22:21 3: Setting COC_1 baudrate to 38400
2013.01.14 10:22:21 3: COC_1 device opened
2013.01.14 10:22:21 3: COC_1: Possible commands: mBCFAZOGMRTVWXefltux
2013.01.14 10:22:21 2: Switched COC_1 rfmode to HomeMatic
2013.01.14 10:22:26 3: Opening CUNO_DMX device 192.168.1.24:2323
2013.01.14 10:22:26 3: CUNO_DMX device opened
2013.01.14 10:22:26 3: CUNO_DMX: Possible commands: mBCFDiAGMRTVWXOefltuxEcq
2013.01.14 10:22:27 3: OW_Temp_Test: I/O device is OWS_Casa
2013.01.14 10:22:28 3: OW_Switch_Test: I/O device is OWS_Casa
2013.01.14 10:22:29 3: LCD: I/O device is OWS_Casa
2013.01.14 10:22:30 3: OW_Remote_Temp: I/O device is OWS_MansCave
2013.01.14 10:22:31 3: OWServer_1ID: I/O device is OWS_MansCave
2013.01.14 10:22:31 3: OW_Casa_TankSensor: I/O device is OWS_MansCave
2013.01.14 10:22:31 3: OW_Casa_TankSensor: reading type did not return a value
2013.01.14 10:22:31 3: OW_Casa_TankSensor: reading PIO.A did not return a value
2013.01.14 10:22:31 3: OW_Casa_TankSensor: reading PIO.B did not return a value
2013.01.14 10:22:31 3: OW_Casa_TankSensor: reading PIO.C did not return a value
2013.01.14 10:22:31 3: OW_Casa_TankSensor: reading PIO.D did not return a value
2013.01.14 10:22:31 3: OW_Casa_TankSensor: reading volt.A did not return a value
2013.01.14 10:22:31 3: OW_Casa_TankSensor: reading volt.B did not return a value
2013.01.14 10:22:31 3: OW_Casa_TankSensor: reading volt.C did not return a value
2013.01.14 10:22:31 3: OW_Casa_TankSensor: reading volt.D did not return a value
2013.01.14 10:22:31 3: OW_Casa_TankSensor: reading volt2.A did not return a value
2013.01.14 10:22:31 3: OW_Casa_TankSensor: reading volt2.B did not return a value
2013.01.14 10:22:31 3: OW_Casa_TankSensor: reading volt2.C did not return a value
2013.01.14 10:22:31 3: OW_Casa_TankSensor: reading volt2.D did not return a value
2013.01.14 10:22:31 3: OW_Casa_TankSensor: reading PIO.A did not return a value
2013.01.14 10:22:31 3: OW_Casa_TankSensor: reading PIO.B did not return a value
2013.01.14 10:22:32 3: OW_Casa_TankSensor: reading PIO.C did not return a value
2013.01.14 10:22:32 3: OW_Casa_TankSensor: reading PIO.D did not return a value
2013.01.14 10:22:32 3: OW_Casa_TankSensor: reading volt.A did not return a value
2013.01.14 10:22:32 3: OW_Casa_TankSensor: reading volt.B did not return a value
2013.01.14 10:22:32 3: OW_Casa_TankSensor: reading volt.C did not return a value
2013.01.14 10:22:32 3: OW_Casa_TankSensor: reading volt.D did not return a value
2013.01.14 10:22:32 3: OW_Casa_TankSensor: reading volt2.A did not return a value
2013.01.14 10:22:32 3: OW_Casa_TankSensor: reading volt2.B did not return a value
2013.01.14 10:22:32 3: OW_Casa_TankSensor: reading volt2.C did not return a value
2013.01.14 10:22:32 3: OW_Casa_TankSensor: reading volt2.D did not return a value
2013.01.14 10:22:32 3: OW_Casa_TankSensor_Switch: I/O device is OWS_MansCave
2013.01.14 10:22:32 3: OW_Casa_TankSensor_Switch: reading type did not return a value
2013.01.14 10:22:32 3: OW_Casa_TankSensor_Switch: reading sensed.A did not return a value
2013.01.14 10:22:32 3: OW_Casa_TankSensor_Switch: reading sensed.B did not return a value
2013.01.14 10:22:32 3: OW_Casa_TankSensor_Switch: reading sensed.A did not return a value
2013.01.14 10:22:32 3: OW_Casa_TankSensor_Switch: reading sensed.B did not return a value
2013.01.14 10:22:32 1: Including /var/log/fhem/fhem.save
2013.01.14 10:22:34 0: Server started (version Fhem 5.3 (DEVELOPMENT), $Id: fhem.pl 2505 2013-01-13 15:16:31Z borisneubert $, pid 409)

dougie · 14 Januar 2013, 10:34:15

...fheminfo meint übrigens ich hätte DREI owserver....

Wo der dritte ist, müsste ich aber suchen :-)

Code Auswählen

Fhem info:
  Release  : 5.3
  Branch   : DEVELOPMENT
  OS       : linux
  Arch     : arm-linux-gnueabihf-thread-multi-64int
  Perl     : v5.14.2
  uniqueID : c4a87d04e3f0c5af69974648e4da2fd7

Defined modules:
  CUL        : 3
  CUL_HM     : 36
  FHEMWEB    : 4
  FLOORPLAN  : 1
  FS20       : 20
  FileLog    : 11
  Global     : 1
  OWDevice   : 7
  OWServer   : 3
  at         : 1
  autocreate : 1
  telnet     : 1

Defined models per module:
  CUL        : CUN
  CUL_HM     : HM-CC-TC,HM-CC-VD,HM-Dis-TD-T,HM-OU-LED16,HM-SEN-MDIR-SM
  OWDevice   : DS18S20,DS2401,DS2413,LCD

eppi · 14 Januar 2013, 11:50:12

Hallo Martin
Ich habe in fhem.save das Reading "address" gelöscht und wieder gestartet!

Zitatich schliesse daraus, dass du den ibutton während der der devicedefinition an bus.1 hattest und ihn bei dem obigen beispiel an einem probe an bus.0 hast. korrekt?

Genau so ist es :=) !

Danke und Gruss Dani

Martin Fischer · 14 Januar 2013, 12:05:55

Zitat von: eppi schrieb am Mo, 14 Januar 2013 11:50
Zitatich schliesse daraus, dass du den ibutton während der der devicedefinition an bus.1 hattest und ihn bei dem obigen beispiel an einem probe an bus.0 hast. korrekt?
Genau so ist es : !

prima

dougie · 14 Januar 2013, 13:38:38

Heute endlich mal wieder die commandref gelesen. Immer wieder gut zu wissen was da steht, da sich dort auch viel tut :-)

Somit bitte meinen Post von oben ignorieren. Steht ja klar drin, in welcher Reihenfolge ich die Devices definieren muss/soll.

Andere Frage: ich habe meinen DS2413 dual IO in Betrieb genommen und kann die Ausgänge auch einwandfrei mit

set <OWDevice> PIO.A [1|0]

schalten. Gibt es auch hier die Möglichkeit für die einzelnen Ports einen Namen/Alias zu vergeben?
Toll wäre am Ende so was wie

set <OWDevice> Zirkulationspumpe An

oder

set <OWDevice> Garagentor Auf

Oder soll ich das besser mit Hilfe von nem Dummy und ein paar Zeilen Code realisieren?

VG
Ralf

dougie · 14 Januar 2013, 13:47:57

...achso: den dritten OWServer hab ich auch gefunden.

Da ich es mir abgewöhnt habe, die fhem.cfg direkt zu editieren, schaue ich da nicht so oft rein.
Irgendwie ist dort ein OWServer stehen geblieben, obwohl ich ihn meinte mit dem delete Befehl gelöscht zu haben.

Reihenfolge der OWServer und OWDevices habe ich korrigiert, und jetzt sieht das absolut falbelhaft aus. :-)

VG
Ralf

Martin Fischer · 14 Januar 2013, 15:29:40

Zitat von: dougie schrieb am Mo, 14 Januar 2013 13:38schalten. Gibt es auch hier die Möglichkeit für die einzelnen Ports einen Namen/Alias zu vergeben?

im moment noch nicht, aber bestimmt auch demnächst in diesem theater ;-) (siehe userReadings)

gruss

Damian · 14 Januar 2013, 17:40:54

Hallo,

ich würde gerne bei mir den OWSERVER ausprobieren. Z. Zt. habe ich DS18B20 über OWX über USB-Adapter laufen.

Bisheriger Eintrag war: define OWIO1 OWX COM7

Nun sind mir noch ein paar Sachen nicht ganz klar (gibt es überhaupt eine Doku zum OWSERVER?)

Meine Vorgehensweise

1.) in der fhem.cfg eingetragen:

define MY_OWServer OWServer <meine IP>:4304

2.) in der owfs.conf (wo muss die hin unter Windows? Habe die im Hauptverzeichnis neben fhem.cfg abgelegt) eingetragen:

server: device = COM7

3. Nach dem Start von FHEM im Log keine Fehlermeldugen (verbose 3)

MY_OWServer wurde in FHEM angelegt und initialiert

4. autocreate ist active

5. Kein Device wird gefunden

Was mache ich falsch?

Gruß

Damian

dougie · 14 Januar 2013, 18:17:51

Zitat von: Damian schrieb am Mo, 14 Januar 2013 17:401.) in der fhem.cfg eingetragen:

define MY_OWServer OWServer <meine IP>:4304

Bei Windows bin ich nicht ganz sicher, aber auf meinem RPi unter Linux funktioniert die nach "aussen" präsentierte IP nicht.
Ich habe

define MY_OWServer OWServer localhost:4304

genommen, das funktioniert bei mir einwandfrei.

Zitat von: Damian schrieb am Mo, 14 Januar 2013 17:402.) in der owfs.conf Habe die im Hauptverzeichnis neben fhem.cfg abgelegt) eingetragen:

server: device = COM7

Sollte klappen.
Hast du auch die anderen Settings in der owfs.conf?

VG
Ralf

thoweiss · 14 Januar 2013, 18:20:24

Hehehe - leute nicht so schnell mit den Updates!

Ich komme nicht mehr hinterher ;-)

Tolle Arbeit macht ihr da!

Gruß,
Thorsten

Damian · 14 Januar 2013, 18:34:29

Zitat von: dougie schrieb am Mo, 14 Januar 2013 18:17Hast du auch die anderen Settings in der owfs.conf?

hatte zuvor noch in der owfs.conf

http: port = 2121
ftp: port = 2120

drin stehen, allerdings auch ohne Erfolg. Weiß eben noch nicht, ob man das alles beim USB-Adapter (aus Polen) braucht?

Ich habe das Gefühl, dass die owfs.conf gar nicht angezogen wird. Ohne Fehlermeldungen komme ich da nicht weiter.

Gruß

Damian