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 (//owfs.org/index.php?page=family-code-list) 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
...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
- 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
- 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 :-(
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
Hallo Dani,
Zitat von: eppi schrieb am Sa, 12 Januar 2013 17:29Hallo 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.
Zitat von: eppi schrieb am Sa, 12 Januar 2013 17:29Ich 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:
/opt/owfs/bin/owserver -u -p 45678 --timeout_directory 3 --timeout_presence 3Grüße,
Markus
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
Hallo Markus
Danke für deine Hilfe!
ZitatDa 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
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
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
> 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
Hallo Martin
Danke für deine Hilfe!
Zitatauf 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:
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 DS2401OWServer:
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?
Zitatja, 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
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
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
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
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)
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:
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":
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":
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":
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:
# 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
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:
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 DS2401iButton02:
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
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:
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
...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
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)
...fheminfo meint übrigens ich hätte DREI owserver....
Wo der dritte ist, müsste ich aber suchen :-)
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
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
Zitat von: eppi schrieb am Mo, 14 Januar 2013 11:50Zitatich 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 ;-)
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
...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
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
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
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
Hehehe - leute nicht so schnell mit den Updates!
Ich komme nicht mehr hinterher ;-)
Tolle Arbeit macht ihr da!
Gruß,
Thorsten
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
OWDevice:
- uncached reading hinzugefügt[1]
[1] Über das neue Attribut "uncached" bei OWDevice holt OWServer die Daten nicht aus dem Cache. Ich empfehle folgende Erläuterung What is uncached? (//owfs.org/index.php?page=what-is-uncached) zu lesen, bevor man pauschal alles auf "uncached" setzt. Oft ist dies nicht notwendig, da das caching vom owserver schon gut abgestimmt ist.
Beispiel:
define myTempSens OWDevice 10.123456789012 60
attr myTempSens uncached 1
Viel Spaß damit..
Gruß Martin
Hallo,
Kompliment an Martin Fischer und Boris Neubert! Hatte den COC schon eingemottet und war kurz davor, den hier zum Verkauf freizugeben. Gestern doch mal aus Neugier OWFS auf dem RaspPi installiert und an die COC 1-wire Schnittstelle insg. 5 Sensoren angeschlossen -> das läuft einfach prima! Für Fragen, wie ich mit dem DS2438 mit angeschlossenen HIH4000 temperatur+spannungsbereinigte Luftdruckwerte berechne ist sicher noch zu früh.
Was ich allerdings nicht verstehe ist die Anzahl der erkannten Sensoren - es sind 2 mehr, als erwartet.
Internals:
DEF 10.67C6697351FF 300
IODev OWServer
NAME DS18S20_10.67C6697351FF
NR 27
STATE 95.6°C
TYPE OWDevice
Readings:
2013-01-14 21:56:51 alarm 0
2013-01-14 21:56:51 state temperature: 58.864 alarm: 0
2013-01-14 21:56:51 temperature 95.6468
Fhem:
address 10.67C6697351FF
alerting 1
bus bus.0
interfaces temperature
interval 300
und
Internals:
DEF 05.4AEC29CDBAAB 60
IODev OWServer
NAME DS2405_4AEC29CDBAAB
NR 31
STATE sensed: 0
TYPE OWDevice
Readings:
2013-01-14 22:12:58 sensed 1
2013-01-14 22:12:58 state sensed: 0
Fhem:
address 05.4AEC29CDBAAB
alerting 0
bus bus.0
interfaces state
interval 60
und dann auf bus.1 die 5 Stück, welche ich physisch wirklich angehangen habe.
Gibt es ggf. dafür eine einfache Erklärung? Die Temperaturwerte des angeblichen DS18S20 springen auch wild von 0-100°C...
Das hat mich auch mehrere graue Haare und Anfragen hier im Forum gekostet, bis ich auf die Spur gebracht wurde...das sind die beiden Fake Devices aus der owfs.conf.
Zitat von: det. schrieb am Mo, 14 Januar 2013 22:18Für Fragen, wie ich mit dem DS2438 mit angeschlossenen HIH4000 temperatur+spannungsbereinigte Luftdruckwerte berechne ist sicher noch zu früh.
kommt demnächst in diesem theater.. boris hat da schon was vorbereitet, wir testen gerade ;-)
ABER: ich habs jetzt nicht um kopf und bin gerade zu faul zum nachsehen:
hast du bei dem DS2438 nicht das reading HIH4000/humidity?
na gut, ich schau mal eben nach..
siehe:
DS2438 - Smart Battery Monitor
SYNOPSIS
Temperature Voltages and Current.
26 [.]XXXXXXXXXXXX[XX][/[ CA | EE | date | disconnect/date | disconnect/udate | endcharge/date | endcharge/udate | IAD |
offset | pages/page.[0-7|ALL] | temperature | udate | VAD | VDD | vis | address | crc8 | id | locator | r_address | r_id
| r_locator | type ]]
Humidity sensor
26 [.]XXXXXXXXXXXX[XX][/[ HIH4000/humidity | HTM1735/humidity | DATANAB/reset | DATANAB/humidity | humidity | temperature
]]
Barometer
26 [.]XXXXXXXXXXXX[XX][/[ B1-R1-A/pressure | B1-R1-A/gain | B1-R1-A/offset | ]]
Light
26 [.]XXXXXXXXXXXX[XX][/[ S3-R1-A/current | S3-R1-A/illuminance | S3-R1-A/gain ]]
FAMILY CODE
26meinte ich doch... bei den ganzen slaves, die ich zugefügt habe, hatte ich das nicht im kopf... _alle_ obigen readings kannst du sofort auswerten! beachte: humidity ungleich HIH4000/humidity!
humidity
read-only, floating point
Relative humidity, as percent (1-100 scale).
The DS2438 actually does not read humidity, but a widely available and publicised circuit based on the chip, does. This
design is for the common Honeywell HIH-3610 humidity chip. The mostly compatible HIH-4000 chip uses different temperature
compensation, so is better read from the HIH4000/humidity value. See the datasheets for details.
If the chip is instead a DATANAB design, the DATANAB/humidity value will be automatically used.
ZitatWas ich allerdings nicht verstehe ist die Anzahl der erkannten Sensoren - es sind 2 mehr, als erwartet.
das hat uwe glaub ich schon beantwortet.. nimm statt FAKE lieber TESTER. dann springen die werte nicht mehr :-) just kiddin'
nein, kommentier den FAKE eintrag einfach aus der owfs.conf
gruss martin
Hallo zusammen
ev ein wenig OT, aber Fragen kann man ja mal...
Ich habe für meine iButton folgende Routine angelegt:
sub ibutton01_bus1{
my $ibutton = ReadingsVal("ibutton01","present","off");
my $bus = ReadingsVal("ibutton01","location","off");
if($ibutton eq "1" && $bus eq "bus.1" && OldValue("ibutton01") ne "present: 1"){
fhem "set dummy6 on";
}
}
und über nachfolgenden Notify wird getriggert:
define ibutton01_test notify (ibutton01) { ibutton01_bus1() }
Sobald ich den entsprechenden iButton am entsprechenden Bus anschliesse wird auch getriggert, jedoch 4x nacheinander!
Log:
2013.01.15 06:50:47 2: dummy set dummy6 on
2013.01.15 06:50:47 2: dummy set dummy6 on
2013.01.15 06:50:48 2: dummy set dummy6 on
2013.01.15 06:50:49 2: dummy set dummy6 on
Da ich den "OldValue" abfrage, sollte doch nur ein notify getriggert werden? Wie kann man das noch besser verriegeln, dass nur einmal getriggert wird?
Danke vielmals, Gruess Dani
vielen Dank - funktioniert wie beschrieben!
M1 43.1% -> stateFormat {sprintf("%.1f",ReadingsVal("M1","HIH4000/humidity",0))."%"}
S1 sensed.A: 1 sensed.B: 1 alarm: 1
T1 20.6°C
T3 20.6°C
T4 20.6°C
Um auf der Zeile neben der Luftfeuchte auch noch die Temperatur angezeigt zu bekommen, muß ich noch etwas probieren...
M1 43.1% -> stateFormat {sprintf("%.1f%% %.1f°C",ReadingsVal("M1","HIH4000/humidity",0), ReadingsVal("<mytempsens>","temperature",0))}
Zitat von: Martin Fischer schrieb am Di, 15 Januar 2013 20:21
M1 43.1% -> stateFormat {sprintf("%.1f%% %.1f°C",ReadingsVal("M1","HIH4000/humidity",0), ReadingsVal("<mytempsens>","temperature",0))}
Danke, da hätte ich lange probieren müssen, um das so hinzubekommen.
Eine Frage hab ich zu dem reading noch, es kommt entweder die Temperatur vom DS2438 oder die Luftfeuchte. Beide Werte zusammen offenbar nicht?
(siehe Anhang / see attachement)
> Eine Frage hab ich zu dem reading noch, es kommt entweder die Temperatur vom DS2438
> oder die Luftfeuchte. Beide Werte zusammen offenbar nicht?
was steht denn in state? stehen da beide werte?
gruss martin
jein - ich poste mal den Screenshot davon:
(siehe Anhang / see attachement)
> jein - ich poste mal den Screenshot davon:
also erstmal solltest du noch das sprintf anpassen, damit es analog zu den anderen state temp/hum) aussieht. das war von mir nur ein "quick'n'dirty".. musst du natürlich nicht. :-)
was ich aber nicht ganz verstehe, warum du humidity von M1 nimmst und temperature von T1? das dürfte (wahrscheinlich) auch die ursache sein, dass dein plot nicht funktioniert. der ds2438 liefert doch beiden temp und hum. also demnach sollte es wie folgt aussehen:
M1 H: 43.1 T: 21.5 -> stateFormat {sprintf("H: %.1f% T: %.1f",ReadingsVal("M1","HIH4000/humidity",0), ReadingsVal("M1","temperature",0))}
gruss martin
Hallo Martin,
so hatte ich es ja seit Gestern und jetzt wieder. Das ist genau das Problem, jetzt bleibt der Feuchtigkeitswert auf dem reading von 20:37 Uhr stehen.
Mit Auswahl eines daneben liegenden Temperatursensores (T1) bekomme ich die erwartete Grafik, obwohl es schon schöner wäre, den intern vorhandenen Temperatursensor anzuzeigen.
(siehe Anhang / see attachement)
Das entscheidet jetzt aber nicht den Krieg! Nur falls es ein Fehler ist, lässt es sich ggf. irgendwann mit abstellen, wenn Ihr Zeit dazu habt.
> so hatte ich es ja seit Gestern und jetzt wieder. Das ist genau das Problem,
> jetzt bleibt der Feuchtigkeitswert auf dem reading von 20:37 Uhr stehen.
ok. das du das schon so hattest, habe ich nicht gesehen.
> Mit Auswahl eines daneben liegenden Temperatursensores (T1) bekomme ich die
> erwartete Grafik, obwohl es schon schöner wäre, den intern vorhandenen Temperatursensor anzuzeigen.
so sollte es sein.
> Das entscheidet jetzt aber nicht den Krieg! Nur falls es ein Fehler ist, lässt es
> sich ggf. irgendwann mit abstellen, wenn Ihr Zeit dazu habt.
nun. seitens des OWDevice bekommst du ja die readings, wenn du kein stateformat einsetzt. und das auch regelmäßig. hier ist also kein fehler. ich vermute mal, das es mit stateFormat zusammenhängt. das ist eine modulübergreifende funktion und ein "kind" von rudi. ich sprech mal mit ihm.
gruss
Martin hat mich gebeten hier reinzuschauen, weil er meint, dass es mit stateFormat zusammenhaengt.
Wenn ich es richtig verstehe, habt Ihr die Vermutung, dass events ausbleiben, wenn man stateFormat setzt. Ich meine das kann nicht sein, da stateFormat nur eine Variable (STATE) setzt, und hat sonst keine Auswirkung auf events.
Ein Beweis koennte man fuehren, indem man in readingsBulkUpdate Log-Ausgaben einbaut, und diese mit den Daten in der Plot-Logfile vergleicht.
boris will sich das am wochenende mal näher anschauen. dann sehen wir weiter.
gruss martin
OWServer:
- neues Attribut "nonblocking".[1]
- Dokumentation der get und set Befehle ergänzt.
[1] Die Abfrage der Werte kann dazu führen, das FHEM bis zur Antwort des owservers geblockt ist. Dies bewegt sich in der Regel im Milisekunden-Bereich. Für zeitkritische Module wie z.B. CUL_HM ist dies Kontraproduktiv. Über das Attribut "nonblocking" werden die Abfragen in einem Hintergrundprozess vorgenommen, so dass FHEM an dieser Stelle nicht blockiert ist.
Viel Spaß damit!
Gruß Martin
Hallo zusammen
Könnte mir bitte jemand einen Tipp geben?
Ich habe für meine iButton folgende Routine angelegt:
sub ibutton01_bus1{
my $ibutton = ReadingsVal("ibutton01","present","off");
my $bus = ReadingsVal("ibutton01","location","off");
if($ibutton eq "1" && $bus eq "bus.1" && OldValue("ibutton01") ne "present: 1"){
fhem "set dummy6 on";
}
}
und über nachfolgenden Notify wird getriggert:
define ibutton01_test notify (ibutton01) { ibutton01_bus1() }
Sobald ich den entsprechenden iButton am entsprechenden Bus anschliesse wird auch getriggert, jedoch 4x nacheinander!
Log:
2013.01.15 06:50:47 2: dummy set dummy6 on
2013.01.15 06:50:47 2: dummy set dummy6 on
2013.01.15 06:50:48 2: dummy set dummy6 on
2013.01.15 06:50:49 2: dummy set dummy6 on
Da ich den "OldValue" abfrage, sollte doch nur ein notify getriggert werden? Wie kann man das noch besser verriegeln, dass nur einmal getriggert wird?
Danke vielmals, Gruess Dani
PS: Entschuldigt das Double-Posting...
Zitat von: Martin Fischer schrieb am Do, 17 Januar 2013 11:55- neues Attribut "nonblocking".[1]
---8<------8<------8<------8<------8<---
Über das Attribut "nonblocking" werden die Abfragen in einem Hintergrundprozess vorgenommen...
Dazu mal eine Frage:
attr myowserver nonblocking 1 verhindert auch, dass fhem total hängt, wenn der OWServer mal weg ist? Ich hatte vermutlich gerade den Fall mit einer Version vom 15.01.2012: Ich hatte den OWServer runtergefahren, rumgebastelt und neu hochgefahren. Dann habe ich kurze Zeit später festgestellt, dass fhem total hing. Nur ein kill -9 half da noch... Danach war alles wieder i.O....
Gruß
Holger
Zitat von: rudolfkoenig schrieb am Mi, 16 Januar 2013 22:27Ein Beweis koennte man fuehren, indem man in readingsBulkUpdate Log-Ausgaben einbaut, und diese mit den Daten in der Plot-Logfile vergleicht.
Ich habe es mir angesehen und ich verstehe nicht, wie es dazu kommt.
Bitte poste mal die Ausgabe von list für das in Rede stehende Device und ersetze bitte außerdem in
fhem.pl in der sub readingsBulkUpdate (ca. ab Zeile 3065) den Code am Ende durch
my $rv = "$reading: $value";
Debug "$name: $rv";
if($changed) {
$rv = "$value" if($reading eq "state");
Debug "$name: event $rv";
addEvent($hash, $rv);
}
return $rv;
und poste den Output, und zwar bitte nur den, der sich auf das kritische Device bezieht.
Danke
Boris
Hallo Boris,
das betraf glaube ich meine Frage. Den Code in die FHEM.pl baue ich asap ein (sobald im im Büro bin und direkten Zugriff auf den RaspbPi habe), oder geht das über die Web Oberfläche?
hier nun die Ausgabe nach list:
Internals:
DEF 26.E8B804000000 60
IODev OWServer
NAME M1
NR 21
STATE H: 37.3 T: 19.5°C
TYPE OWDevice
Readings:
2013-01-19 17:17:32 HIH4000/humidity 37.2745
2013-01-19 10:17:25 VAD 1.79
2013-01-19 10:17:25 VDD 4.62
2013-01-19 17:17:32 state VAD: 1.79 VDD: 4.62 temperature: 19.4688
2013-01-19 10:17:25 temperature 19.4688
2013-01-18 21:33:46 udate 1
Fhem:
address 26.E8B804000000
alerting 0
bus bus.0
interfaces multisensor
interval 60
getters:
B1-R1-A/gain
B1-R1-A/offset
B1-R1-A/pressure
CA
DATANAB/humidity
EE
HIH4000/humidity
HTM1735/humidity
IAD
MultiSensor/type
S3-R1-A/current
S3-R1-A/gain
S3-R1-A/illumination
VAD
VDD
address
crc8
date
disconnect/date
disconnect/udate
endcharge/date
endcharge/udate
family
humidity
id
locator
offset
pages/page.0
pages/page.1
pages/page.2
pages/page.3
pages/page.4
pages/page.5
pages/page.6
pages/page.7
pages/page.ALL
r_address
r_id
r_locator
temperature
type
udate
vis
polls:
HIH4000/humidity
setters:
B1-R1-A/gain
B1-R1-A/offset
CA
DATANAB/reset
EE
IAD
S3-R1-A/gain
date
disconnect/date
disconnect/udate
endcharge/date
endcharge/udate
offset
pages/page.0
pages/page.1
pages/page.2
pages/page.3
pages/page.4
pages/page.5
pages/page.6
pages/page.7
pages/page.ALL
udate
state:
VAD
VDD
temperature
Attributes:
IODev OWServer
model DS2438
polls HIH4000/humidity
room Server
stateFormat {sprintf("H: %.1f T: %.1f°C",ReadingsVal("M1","HIH4000/humidity",0), ReadingsVal("M1","temperature",0))}
Zitat von: det. schrieb am Sa, 19 Januar 2013 17:28hier nun die Ausgabe nach list:
Internals:
...
polls:
HIH4000/humidity
...
Attributes:
polls HIH4000/humidity
...
stateFormat {sprintf("H: %.1f T: %.1f°C",ReadingsVal("M1","HIH4000/humidity",0), ReadingsVal("M1","temperature",0))}
Moment mal, da steht, daß nur HIH4000/humidity gepollt wird. Dann werden andere Readings natürlich nicht mehr aktualisiert. Bitte setze bei den polls auch M1, also
attr ... polls HIH4000/humidity,M1
Das hat gar nichts mit dem stateFormat zu tun.
Viele Grüße
Boris
Hallo Boris,
danke für die Hilfe. Jetzt geht es mit
attr ... polls HIH4000/humidity,temperature
und dank Reinerlein aus einem Post von heute früh klappt auch das LOG:
[code][REGEXP
M1:.*HIH4000/humidity:.*|M1:temperature:\s*-{0,1}\d+[\.\d]*$
/code]
hallo holger,
> attr myowserver nonblocking 1 verhindert auch, dass fhem total hängt, wenn der OWServer mal weg ist?
leider nein. es gäbe einen weg, den wir allerdings im moment noch nicht umsetzen, da ein direkter dialog mit den owfs entwicklern steht. der fehler kommt zustande, da in dem entspr. ownet.pm keine rückmeldung kommt, wenn ein abbruch erfolgt ist.
das wollen sie nun fixen. wenn es aber länger dauert, werden boris und ich "plan b" umsetzen, der das ebenfalls verhindert und nicht sonderlich aufwendig ist.
aber der erstere weg ist halt der elegantere, wenn es am ursprung gefixed wird.
gruss martin
OWDevice:
- neuer set Befehl "interval" [1]
[1] Über den neuen set Befehl "interval" kann während der Laufzeit der Intervall zum Auslesen der Daten geändert werden. Beispiel:
set mySens interval 30
Der geänderte Wert wird nicht gespeichert. Nach einem Neustart gilt der während des define gesetzte Intervall.
Viel Spaß
Martin
Zitat von: Martin Fischer schrieb am Do, 24 Januar 2013 16:01OWDevice:
- neuer set Befehl "interval" [1]
[1] Über den neuen set Befehl "interval" kann während der Laufzeit der Intervall zum Auslesen der Daten geändert werden. Beispiel:
set mySens interval 30
Der geänderte Wert wird nicht gespeichert. Nach einem Neustart gilt der während des define gesetzte Intervall.
Sehr schön.... so kann - wenn die Alarmanlage scharf ist - das Abfrageintervall der DS2406 Fensterkontakte von zb. 15sek auf 3sek erhöht werden.
Auch von mir ein Dankeschön!
Kurzes Feedback: der Eintrag wird bei mir aber nirgendwo im Device angezeigt (taucht aber als STATE auf) und den Eintrag im Log vermag ich nicht zu interpretieren :-)
2013.01.25 10:46:19 3: set OW_TankSensor interval 1800 : 1359108979
2013.01.25 10:46:19 3: 1359108979
VG
Ralf
> Kurzes Feedback: der Eintrag wird bei mir aber nirgendwo im Device angezeigt
beim aufruf von
fhem> list OW_TankSensor
siehst du es im abschnitt "Fhem:"
> (taucht aber als STATE auf) und den Eintrag im Log vermag ich nicht zu interpretieren :-)
> 2013.01.25 10:46:19 3: set OW_TankSensor interval 1800 : 1359108979
> 2013.01.25 10:46:19 3: 1359108979[/code]
ich kann das nicht nachstellen, weiss im moment auch nicht woher der eintrag ": 1359108979" kommt.
kann das noch wer bestätigen?
gruss martin
Hallo,
zunächst möchte ich mich bei den Entwicklern bedanken für die Arbeit. Ich nutze FEHM seit einem Jahr und mache jetzt die ersten Gehversuche mit 1-wire.
Ich habe einen Temperatur/Luftdrucksensor EDS0066 und habe diesen mit folgendem Code in OWDevice eingebunden:
$owdevice{"7E"} = {
# EDS0066 - Multisensor temperature Pressure
"read" => [ qw(EDS0066/temperature),
qw(EDS0066/pressure)],
"write" => [],
"poll" => [ qw(EDS0066/temperature EDS0066/pressure) ],
"state" => [ qw(EDS0066/temperature EDS0066/pressure) ],
"interface" => "multisensor",
};
Für mich reichen diese Minimal-Daten. Ist es möglich diesen Code in die Quelle zu übernehmen, damit nicht nach jedem Update eine manuelle Erweiterung notwendig ist ?
Ohne Erweiterung kommt folgende Fehlermeldung:
"myLocalOWServer: Autocreate: unknown familycode '7E' found. Please report this!"
Zitat von: MNeugebauer schrieb am Mo, 28 Januar 2013 18:33Für mich reichen diese Minimal-Daten. Ist es möglich diesen Code in die Quelle zu übernehmen, damit nicht nach jedem Update eine manuelle Erweiterung notwendig ist
Mit einer Modifikation eingecheckt.
Danke und Grüße
Boris
Moin!
Erstmal großes Kompliment: Steige gerade auf OWServer/OWDevice um und alle meine Devices werden problemlos erkannt! Die meisten Ausgaben habe ich dank fhemwiki mit stateFormat anpassen können.
Ein Problem habe ich nur mit den Zählern, denn hier muss ich mit userReadings arbeiten und obwohl ich Boris Ankündigung und commandref gelesen habe, hakt es wegen meiner unzureichenden Perl-Kenntnisse.
Vom Zähler kommt dieses state:
counters.A:881591 counters.B:1Behandeln muss ich es wie folgt:
- nur counters.A verwenden
- Wert counters.A mit Faktor 0.01 versehen (1 Impuls = 0,01 m3, ich möchte m3)
- Ergebnis von Schritt 2. erhöhen um 1394735 (Stand des Gaszählers in m3, als ich den DS2423 mit Stand "0" dran gehängt habe
Wenn ich jetzt die Erklärung von Boris aus http://forum.fhem.de/index.php?t=msg&goto=58918&rid=0&srch=userReadings#msg_58918 (//forum.fhem.de/index.php?t=msg&goto=58918&rid=0&srch=userReadings#msg_58918) herannehme (in der commandref steht eher weniger) und beginne, das für mich anzupassen, komme ich auf das hier:
attr myGasMeter userReadings erdgas { (ReadingsVal("myGasMeter","counters.A",0)+AttrVal("myGasMeter","myBasis",0))/100.0;; }Darin steckt schon der Faktor 0.01. Unklar ist mir aber "myBasis" - kommt hier der Offset um 1394735 rein? Oder wofür steht myBasis? Dazu habe ich nichts gefunden. Wo würde man den Offset addieren?
Danke!
Georg
Zitat von: Schorsch schrieb am Di, 29 Januar 2013 10:30attr myGasMeter userReadings erdgas { (ReadingsVal("myGasMeter","counters.A",0)+AttrVal("myGasMeter","myBasis",0))/100.0;; }
Darin steckt schon der Faktor 0.01. Unklar ist mir aber "myBasis" - kommt hier der Offset um 1394735 rein? Oder wofür steht myBasis? Dazu habe ich nichts gefunden. Wo würde man den Offset addieren?
Na, Du bist doch schon fertig. Mit
attr myGasMeter myBasis 1394735 hast Du es geschafft. Du mußt Dir lediglich noch myBasis als userattr definieren.
Viele Grüße
Boris
Danke Boris! Musste nur noch ein attr global userattr myBasis einfügen, jetzt läuft's prima!
Hier noch meine Device Definition, falls sie jemand anderem hilft:
define myGasmeter OWDevice 1D.nnnnnnnnnnnn 60
attr myGasmeter model DS2423
attr myGasmeter myBasis 1394735
attr myGasmeter userReadings erdgas { (ReadingsVal("myGasmeter","counters.A",0)+AttrVal("myGasmeter","myBasis",0))/100.0;; }
attr myGasmeter stateFormat {sprintf("%.2f",ReadingsVal("myGasmeter","erdgas",0))."m3"}
attr myGasmeter room K.Heizung
Als nächstes muss ich Ratenberechnung verstehen - gibt's da eine Quelle zum Einlesen? Müsste ja wohl OldValue mit Timestamp zum aktuellen Value / Timestamp ins Verhältnis setzen und dann auf eine Stunde hochrechnen...
Muss ich grundsätzlich verstehen, brauche ich auch für die Stromzähler :-)
Viele Grüße,
Georg
Ich schaffe es nicht, mit einem DS9490R als USB/1wire-Adapter durch OWDevice DS2406 bei einer gelesenen Zustandsänderung ein event in fhem ausgelöst zu bekommen.
Nur wenn das Device periodisch gepollt wird, bekomme ich ein event. Ich möchte aber schnell auf eine Zustandsänderung am PIO reagieren und hoffe das das feature schon unterstützt wird.
set-alarm steht auf 331.
Gibt es hierzu schon Erfahrungen? Oder eine Theorie?
> Nur wenn das Device periodisch gepollt wird, bekomme ich ein event. Ich möchte
> aber schnell auf eine Zustandsänderung am PIO reagieren und hoffe das das feature
> schon unterstützt wird.
das ist die funktionsweise von 1-wire. ohne periodischem polling kommt da nichts automatisch.
gruss martin
Verstanden! Statt nun aber alle OWDevices zu pollen, reichte es doch, für zeitkritische Fälle nur das owfs-Verzeichnis "alarm" zu pollen. Hier stehen genau die OWDevices drin, für die ein neuer Alarm auftrat. Dies dürfte i.d.R. eine viel kleinere Teilmenge sein.
Ich schlagen vor, dass dieses Verzeichnis unabhängig von den OWDevice Intervallen mit einem vergleichsweise kurzen Intervall gepollt werden kann.
Für jedes neu im owfs-Verzeichnis "alarm" auftauchende OWDevice sollte dann einmalig ein event ausgelöst werden, damit spontane Alarmbehandlung erfolgen kann.
Mit dieser Erweiterung für OWServer_Get und "get <myOWServer> alarms" werden die OWDevices im Alarmzustand ausgegeben und die poll-Readings aktualisiert:
} elsif($cmd eq "alarms") {
my $path= "alarm";
my @dir= split(",", $owserver->dir($path));
my $ret= "";
for my $device (@dir) {
$device =~ s|/alarm/||g;
my $name;
foreach my $d (keys %defs) {
next if($defs{$d}{TYPE} ne "OWDevice");
if(defined($defs{$d}{fhem}) &&
defined($defs{$d}{fhem}{address}) && $defs{$d}{fhem}{address} eq $device) {
$name = $defs{$d}{NAME};
OWDevice_UpdateValues($defs{$d});
next;
}
}
$ret .= "$name\n";
}
return $ret;
Wir bräuchten ein Attribut für OWServer, mit dem das Alarm-Polling eingestellt wird und dann die Poll-Readings aller Alarm-OWDevices regelmäßig gepollt werden würden. Das würde dann die Events auslösen, von denen ich träume - ohne dass sämtliche OWDevices gepollt werden müssen...
nur mal kurz zum Verständniss: auch das owfs pollt die OW-devices auf dem Bus, d.h. Devices deren Status auf 'Alarmed' wechselt tauchen genauso erst mit einer gewissen Verzögerung im owfs 'alarm' Verzeichniss auf. Es ist einfach nicht vorgesehen, dass sich die Devices selbstständig melden.
Bei den beliebten DS18B20 muss z.B. muss dafür nicht nur ein search nach alarmed-devices auf dem Bus gemacht werden - damit die Sensoren überhaupt in den Status alarmed gehen, muss man erst mal eine Messung (selbstverständlich auch über den 1-Wire Bus) auslösen. Das Ganze ist also vom Prinzip her nicht für unmittelbare Reaktionen beim Über- oder Unterschreiten eines Schwellwerts geeignet, eine gewisse Verzögerung ist hierbei schlichtweg unvermeitlich.
Natürlich ist es trotzdem sinnvoll das 'alarm'-verzeichnis des owfs öfter zu pollen als die Gesammtheit der Devices...
Gruß,
Norbert
genau so, wie es norbert geschrieben hat verhält es sich.
OWServer wird auch noch das "alarmpolling" bekommen, das steht schon auf meiner todo, da ich es in meinen alten (nicht veröffentlichten OW modulen) auch schon so hatte.
das setzt aber voraus, das vorher auch gemessen wurde. also: das eine geht nicht ohne dem anderen. demnach wird man nicht drum kommen, die messung im device zu machen und das liefert eh den alarmzustand zurück. über den OWServer wäre halt nur noch eine "nice to have" funktion, die zentral alarme ausgibt, die aber eh von jedem device bei einem reading kommen.
gruss martin
Das hört sich super an, Martin!
Bei den PIOs des DS2406 ist der Alertstatus wohl etwas anders gehandhabt als beim DS18B20, wo eine eigene Temperaturmessung erforderlich ist. Ich habe reichlich viele der PIOs und muss dank der Alerts nicht alle PIOs nacheinander pollen, um zu sehen, welches Fenster offen ist.
Ich bin kein perler, aber hier ist mein patch für die Alarme. Dann sähe die Eventbehandlung zB. so aus:
define myOWServer OWServer localhost:4304
attr myOWServer alarms 1 #poll every sec the alarms of owfs
define C_Keller OWDevice 12.EFBA7B000000 300
attr C_Keller model DS2406
attr C_Keller room 000_Keller
define X_C_Keller notify C_Keller {if(ReadingsVal("C_Keller","alarm",0) eq 1) { ....dosomething;; set C_Keller latch.BYTE 0"}}
mit latch.BYTE setze ich den Alarm zurück.
Vielleicht könnt Ihr es gebrauchen.
> Ich bin kein perler, aber hier ist mein patch für die Alarme. Dann sähe die Eventbehandlung zB. so aus:
ich werds mir die tage mal näher anschauen..
gruss martin
zum Alarmsearch möchte ich da gerne noch ein wichtiges Detail anmerken:
Man kann auf dem Bus ein Reset/Skip/Convertcommand abschicken, bei dem kein Device explizit addressiert wird und sich alle angesprochen fühlen. Dann starten alle DS18B20 ihre A/D-Wandlung parallel. 1 Sekunde später führt man dann einfach den Alarm-search durch und fragt nur die Devices explizit ab, die sich im Alarmsearch gemeldet haben.
Das ist deutlich effektiver als alle Devices in Gänze zu pollen (wobei man das Alarm-flag natürlich auch mitkriegt).
Gruß,
Norbert
Hallo,
kann mir einer Sagen warum bei mir stateformat die Readings nicht ersetzt?
attr 1wire_hub stateformat +5V:volt.B +5V:5V_Spannung
Es existiert ein REading volt.B als auch ein UserReading 5V_Spannung.
Leider hat STATE aber hinterher extakt diesen String, die Readings wurden nicht durch den jeweiligen Wert ersetzt.
Idee was ich falsch mache?
STATE +5V:volt.B +5V:5V_Spannung
habs workaroundmäßig jetzt so gelöst:
userreading:
12V_Spannung {ReadingsVal("$name", "volt.B",0) * 2.67;}, 5V_Spannung {ReadingsVal("$name", "volt.D",0) * 1.11}, 12V_Strom {((ReadingsVal("$name", "volt.A",0) - 0.028) / 19.55) * 1000}, 5V_Strom {((ReadingsVal("$name", "volt.C",0)- 0.028) / 19.55) * 1000}
stateformat:
{sprintf("+5V: %0.2fV %0.2fmA | +12V: %0.2fV %0.2fmA", ReadingsVal("$name", "5V_Spannung",0), ReadingsVal("$name", "5V_Strom",0), ReadingsVal("$name", "12V_Spannung",0), ReadingsVal("$name", "12V_Strom",0))}
Schnieke! Da muss bei userReadings denke ich nur das Semikolon hier * 2.67;} raus. Geht bei mir jedenfalls nur ohne. Dann aber umso schöner :-)
Hi,
Zitat von: MNeugebauer schrieb am Mo, 28 Januar 2013 18:33...
Ich habe einen Temperatur/Luftdrucksensor EDS0066 und habe diesen mit folgendem Code in OWDevice eingebunden:
$owdevice{"7E"} = {
# EDS0066 - Multisensor temperature Pressure
...
Für mich reichen diese Minimal-Daten. ...
bin gerade über diesen Thread gestolpert und habe dabei festgestellt, das meine Frage
hier, eigentlich besser hier direkt rein gepasst hätte. Bzgl. der EDS-Geräte - ich habe genau zwei andere...
... und da funktioniert das mit der Minimal-Version nicht mehr :-(
Hallo,
Zitat von: eppi schrieb am Sa, 12 Januar 2013 17:29Ich 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 bin jetzt auch auf ein ähnliches Problem gestoßen. Ich baue mir gerade ein Schlüsselbrett mit 3 Probes und ich möchte, dass die LEDs anzeigen ob der iButton erkannt wurde. Geht natürlich nicht weil man nicht weiß auf welchen Port der steckt...
Aber mal eine andere Idee, ich hab die Schlüsselanhänger-Variante mit den Magneten (Was übrigens als Schlüsselanhänger ziemlich schei**e ist wenn man sein Schlüssel neben die Geldbörse packt wo auch die ganzen Magnetkarten drin sind) und man könnte doch mit einem kleinen Reed Kontakt hinter dem Probe erkennen wo gerade der iButton aufgesetzt wurde. Ich weiß nicht ob das Mechanisch geht, also ob das Magnetfeld reicht und zuverlässig schaltet aber wäre das eine Variante? Ich würde das mal testen am Wochenende, aber die Frage ist viel mehr: Kann man dann mit FHEM auswerten wenn 1-Wire I/O Pin X gesetzt und Seriennummer Y in einem Zeitfenster von 1-2s erscheint, dann steckt die Seriennummer Y auf Port X? Oder ist das Schwachsinn und in der Umsetzung zu kompliziert?
Die Idee kam mir nur eben im Flieger, aber ich wollt mal in die Runde Fragen ob das Sinn macht.
Gruß
Daniel
Hallo ich versuche die ganze Zeit den Tagesverbrauch meines Stromzählers zu Logen
ohne Erfolg meine Config sieht so aus.
define Strom_Counter OWDevice 1D.A2D988000002 300
attr Strom_Counter alias Gesamtverbrauch
attr Strom_Counter fp_Grundriss 110,300,0,
attr Strom_Counter group Energie
attr Strom_Counter model DS2423
attr Strom_Counter offset 19197.7
attr Strom_Counter polls counters.A,counters.B
attr Strom_Counter room Energie
attr Strom_Counter stateFormat { sprintf("%.3f kWh %.3f Watt", ReadingsVal("Strom_Counter","energy","KW"), ReadingsVal("Strom_Counter","power","KW"));; }
attr Strom_Counter userReadings energy { ReadingsVal("Strom_Counter","counters.A",0)/375+AttrVal("Strom_Counter","offset",0);; }, power differential { 3.6*ReadingsVal("Strom_Counter","counters.A",0);; }
define Log_Strom_Counter FileLog ./log/Strom_Counter-%Y-%m.log Strom_Counter:counters.A.*|Strom_Counter:energy.*|Strom_Counter:daily.*|Strom_Counter:power.*
attr Log_Strom_Counter logtype Counter4:Plot,text
attr Log_Strom_Counter room Energie
define Strom weblink fileplot Log_Strom_Counter:Counter4:CURRENT
attr Strom label "Stromzähler"
attr Strom room Energie
Ich bekomme den momentan verbrauch unter Power und der Zählerstand wir auch aktualisiert (daily) so nun hätte ich gerne den Tagesgesamt Verbrauch wie mache ich das??
Also ein log der so aussehen könnte 01.05.2013 10 KW
Kann da einer helfen Bitte
Gruß
Martin
Hallo ich noch mal also ich bin immer noch nicht weiter mit dem Tageswert zu Loggen ??
Ich habe vieles gelesen einiges ausprobiert aber es will mir nicht gelingen.
Erkenntnis des heutigen Tages ich brauche wohl den Befehl AMode
So wie hier in meiner Config habe ich es verstanden leider geht das nicht
define Strom_Counter OWDevice 1D.A2D988000002 300
attr Strom_Counter room Energie
attr Strom_Counter alias Stromverbrauch
attr Strom_Counter comment hex11
attr Strom_Counter fp_Grundriss 110,300,0,
attr Strom_Counter group Energie
attr Strom_Counter model DS2423
attr Strom_Counter offset 19197.0
attr Strom_Counter polls counters.A,counters.B
attr Strom_Counter AMode daily
attr Strom_Counter stateFormat { sprintf("%.3f kWh %.3f Watt", ReadingsVal("Strom_Counter","energy","?"), ReadingsVal("Strom_Counter","power","KW"));; }
attr Strom_Counter userReadings energy { ReadingsVal("Strom_Counter","counters.A",0)/375+AttrVal("Strom_Counter","offset",0);; }, consumption differential { 3.6*ReadingsVal("Strom_Counter","counters.A",0);; },daily
define Log_Strom_Counter FileLog ./log/Strom_Counter-%Y-%m.log Strom_Counter:counters.A.*|Strom_Counter:consumption.*|Strom_Counter:daily.*|Strom_Counter:day.*
attr Log_Strom_Counter logtype Counter4:Plot,text
attr Log_Strom_Counter room Energie
define Strom weblink fileplot Log_Strom_Counter:Counter4:CURRENT
attr Strom label "Stromzähler"
attr Strom room Energie
darauf bekomme ich diese Fehlermeldung
Strom_Counter: unknown attribute AMode
Kann mir einer weiter helfen bitte ???
Gruß
Martin
...ist doch gar nicht so schwer: definier dir eine Dummy Variable, und ein at, das um Mitternacht aufgerufen wird.
In dem at kopierst du dir den aktuellen Counter-Stand in die dummy Variable und vergleichst mit dem Wert vom Vortag.
VG
Ralf
Ja Super mit meinen Programmier Kenntnissen bringt mich das leider auch nicht weiter.
Aber hab trotzdem Dank geht das denn nicht auch anders ??
Du machst das doch auch mit den Tageswerten schreiben oder nicht?
Gruß
Martin
sub
prg_Daily_Stat()
{
#
# Zunächst Differenz aktueller Wert - Wert von Gestern berechnen
$data{DPval} = ReadingsVal("OW_Counter","displayA",0) - Value("DailyPowerDiff");
# Tagesverbrauch in DailyPower speichern
fhem ("set DailyPower $data{DPval}");
# Aktuellen Wert speichern
$data{DPval} = ReadingsVal("OW_Counter","displayA",0);
fhem ("set DailyPowerDiff $data{DPval}");
}
#
Hallo ich noch mal ;)
also ich muss in der Config Fhem dann
define prg_Daily_Stat dummy
define Log_prg_Daily_Stat FileLog ./log/prg_Daily_Stat-%Y-%m.log DailyPower
eingeben ist das Richtig ??
Gruß
Martin
Nein.
prg_Daily_Stat() ist ein Programm in deiner 99_MyUtils.pm, welches du mit einem at jeweils um Mitternacht aufrufst.
Richtig ist, das du dann ein LogFile brauchst, das die Werte dann "einsammelt"
Beispiel:
define Log_Casa_Energy FileLog /var/InternerSpeicher/SMI-USBDISK-01/log/Casa_Energy-%Y.log DailyPower.*|DailyPowerDiff.*
So habe ich es jetzt gemacht
define Strom_Tag notify Strom_tag {prg_Daily_Stat}
attr Strom_Tag room Strom-Tag
attr Strom_Tag userReadings 1
define Log_Strom_Tag FileLog ./log/prg_Daily_Stat-%Y.log DailyPower.*|DailyPowerDiff.*
attr Log_Strom_Tag logtype Counter4:Plot,text
aber geht nicht ist wahrscheinlich auch alles falsch oder?
Gruß
Martin
Martin, ohne dir jetzt zu nahe treten zu wollen...
Ich hab dir mehrfach gesagt, das du ein "at" brauchst, das einmal um Mitternacht ausgeführt wird. Du hast ein "notify" definiert.
Es tut mir leid, aber wenn du den Unterschied zwischen at und notify noch nicht kennst, sehe ich mich zeitlich ausser stande hier weiter zu helfen. Da ist erst mal Selbststudium angesagt.
VG
Ralf
PS: gib mal {prg_Daily_Stat} in der Kommandozeile ein, und schau was passiert. :-)
Hallo da kommt Please define DailyPowerDiff first
aber Danke für deine Hilfe ja ich lese ja schon alles mögliche
im Forum um da weiter zu kommen aber leider habe ich nicht gefunden.
Gruß
Martin
Zitat von: Martin Fischer schrieb am Mi, 23 Januar 2013 01:54> attr myowserver nonblocking 1 verhindert auch, dass fhem total hängt, wenn der OWServer mal weg ist?
leider nein.
.....
aber der erstere weg ist halt der elegantere, wenn es am ursprung gefixed wird.
Ist das in der Version
http://owfs-developers.1086194.n5.nabble.com/New-release-2-9p0-td6812.html behoben?
...ja, das war die Idee. Boris wollte da die entsprechende Abfrage zu einbauen. Hab leider noch nicht getestet, ob das jetzt schon läuft. Meine RPis hängen sich seit einiger Zeit einfach nicht mehr auf :)