Hallo zusammen!
Ich bin im Zuge meines geplanten Energiemonitorings zu 1-wire gekommen.
Meine Config sieht folgendermaßen aus:
- FHEM auf raspbian(wheezy)
- OW-Server-ENET-2 mit 4 DS18B20 (Temp. werden im Webfrontend korrekt angezeigt)
- owserver (2.8p15) gestartet mit: "sudo owserver --enet=192.168.154.11 -p 4304"
- in FHEM mit "define myOWFS OWServer localhost:4304" den owserver definiert
Aktueller Stand:
- die 4 Sensoren werden gefunden und in FHEM mit ihrer Adresse angelegt
- ich kann z.B auch crc8 auslesen
- beim state steht jedoch nur: temperature: n/a alarm: 1
Im logfile findet man bei jedem Auslesen:
2014.05.28 23:03:23 3: DS18B20_9CE9BD030000: reading temperature did not return a value
2014.05.28 23:03:38 3: DS18B20_CB0DBE030000: reading temperature did not return a value
2014.05.28 23:03:41 3: DS18B20_38E0BD030000: reading temperature did not return a value
2014.05.28 23:03:44 3: DS18B20_65D9BD030000: reading temperature did not return a value
Hier (http://forum.fhem.de/index.php/topic,17513.msg115040.html#msg115040) wird angegeben, dass meine owserver-Version zu alt sei, jedoch hat eine selbst kompilierte 2.9er Version auch nichts geändert.
Ausserdem muss der OW-SERVER-ENET sich ansprechen lassen, denn sonst würden ja nichteinmal die Sensoren gefunden.
Hat hier jemand eine Erklärung bzw. eine Lösung für dieses Problem?
Mir wäre schon geholfen, wenn ich Tipps für die Fhlerdiagnose bekommen würde :-)
Danke!
lg
Hugo
hat es evtl damit zu tun daß OW nach dem neustart eine ganze weile zeit braucht um lozulegen? sind die geloggten fehler direkt nach neustarts oder tauchen die ständig auf?
tail -f /opt/fhem/log/fhem.log
LG, florian
Hi Hugo,
wie es aussieht, bist du auf dem Raspi (1-Wire- mäßig) nicht mit dem ENET verbunden. Die Einstellungen in deiner owfs.conf auf dem Raspi sollten der Schlüssel sein. Poste die mal und auch die IP- Adressen deiner anderen Geräte (FB, Raspi, ENET). Ich vermute hier stimmt eine IP- oder Porteinstellung noch nicht.
Gruß
Frank
Hallo!
@epsrw1: Nein das ist leider ein Dauerzustand
@fiedel:
Meine Config sieht folgendermaßen aus:
raspi: 192.168.154.20
ENET: 192.168.154.11 port:8080
wofür steht FB?
Da ich das initscript in /etc/init.d nicht nutze, verwende ich die owfs.conf nicht. (ich hoffe die steht nicht hardcoded im binary, aber das nehme ich nicht an)
Hier trotzdem der Inhalt meiner owfs.conf:
server: server = 192.168.154.11:8080
#server: -opt enet=192.168.154.11:8080
server: port = localhost:4304
Mit "/etc/init.d/owserver start" startet der owserver, jedoch bekomme ich als reading dann keine Temperatur und alarm:0
Starte ich den owserver mit "sudo owserver --enet=192.168.154.11 -p 4304" bekomme ich keine Temperatur und alarm:1
Was micht stutzig macht ist, dass man den parameter --enet nirgends findet, ausser hier: http://owfs.org/index.php?page=ow-server-enet ganz unten.
Auf mich wirkt das nicht so, als ob eine Verbindung bestehen würde. Was absolut dafür spricht ist, dass die 4 Sensorne in FHEM angelegt wurden.
lg
Hugo
Hi Hugo,
mit FB meinte ich Fritzbox. ;o) Wenn du auf der Konsole: "owserver --help=device" eingibst, erscheint u.a. auch: "--ENET=address OWServer-Enet bus master". Ist also alles im Grünen. Fehler 1 bedeutet: "1. Startup - command line parameters invalid" Deshalb:
Erster Versuch jetzt gleich mal: Das "--ENET" wie gezeigt groß schreiben!
Zweiter Versuch: Mal die unten stehende owfs.conf übernehmen und den owserver per "owserver -c /etc/owfs.conf" oder "sudo owserver -c /etc/owfs.conf" starten. Zur Not erst mal die "FAKE"- Devices freischalten und in FHEM so weit einrichten, bis diese zu sehen sind. Dann weiterprobieren mit ENET. Dazu mal den enet- Eintrag variieren, da es scheinbar kein "offizielles" Beispiel gibt.
# server: -opt enet=192.168.154.11
enet=192.168.154.11
! server: server = localhost:4304
# random simulated device
# FAKE = DS18S20,DS2405
owfs: mountpoint = /mnt/1wire
#allow_other
# use syslog
error_print = 1
# server: port = 2125
server: port = 4304
http: port = 2121
# ftp: port = 3131
ftp: port = 2120
Celsius
Aber es scheint ja doch so zu sein, dass die LAN- und OW-Verbindung zum ENET steht, er jedoch die Daten nicht übergibt. Irgendwo hatte ich da auch was von einem Bug gelesen.
Falls das also alles nichts wird, könntest du noch versuchen die Daten per direkter Abfrage in FHEM zu bekommen. Ein Ansatz dazu wäre das hier (https://code.google.com/p/openhab-samples/wiki/BindingConfig#How_to_get_temperatures_from_OW-SERVER_via_HTTP_binding).
Ist denn die Meßstelle so weit vom Raspi weg? Falls nicht, nimm doch lieber ein Interface, welches hier häufig erfolgreich eingesetzt wird. Die LAN- Verkabelung kannst du auch als OW- Kabel zweckentfremden. Oder du nimmst einen CUNO. Der kann zwar nur eingeschränkt OW (bis zu 10 1820 Temp.- Sensoren gemappt als HMS- Sensoren - für "richtiges" OW ist er zu schlapp ), aber der läuft dann wenigstens mit FHEM.
Viel Erfolg!
Frank
Danke für die Tipps! Leider hat alles nichts gebracht.
Die Kommuniktion zwischen owserver und ENET funktioniert am Anfang anscheinend, bricht aber dann ab.
Die OWDevices werden ja in FHEM angelegt, können dann aber nicht abgefragt werden:
root@fhem-srv:/opt/owfs/bin# ./owserver --ENET=192.168.154.11:8080 -p 4304 --debug -m /mnt/1wire/
DEBUG MODE
libow version:
2.9p5
DEBUG: ow_daemon.c:(166) main thread id = 3069313024
CONNECT: ow_avahi_link.c:(68) No Avahi support. Library libavahi-client couldn't be loaded
CONNECT: ow_dnssd.c:(82) Zeroconf/Bonjour is disabled since dnssd library isn't found
CALL: ow_parsename.c:(102) path=[]
DEBUG: owlib.c:(81) Globals temp limits 0C 100C (for simulated adapters)
DEBUG: ow_net_client.c:(85) IP address=[192.168.154.11] port=[8080]
DEBUG: ow_server_enet.c:(183) Add 2nd ENET2 port
DEBUG: ow_server_enet.c:(190) Add 3rd ENET2 port
DEBUG: ow_tcp_read.c:(64) attempt 3 bytes Time: 0.6000000 seconds
DEBUG: ow_tcp_read.c:(114) read: 3 - 0 = 3
DEBUG: ow_tcp_read.c:(64) attempt 24 bytes Time: 10.000000 seconds
DEBUG: ow_tcp_read.c:(114) read: 24 - 0 = 24
DEBUG: from_client.c:(66) FromClient payload=2 size=0 type=4 sg=0x104 offset=0
DEBUG: from_client.c:(74) FromClient (no servermessage) payload=2 size=0 type=4 controlflags=0x104 offset=0
DEBUG: ow_tcp_read.c:(64) attempt 2 bytes Time: 10.000000 seconds
DEBUG: ow_tcp_read.c:(114) read: 2 - 0 = 2
DEBUG: handler.c:(73) Persistence requested
DEBUG: handler.c:(153) START handler /
CALL: data.c:(104) DataHandler: parse path=/
DEBUG: ow_parseobject.c:(164) /
CALL: ow_parsename.c:(102) path=[/]
CALL: data.c:(160) Directory message (one at a time)
CALL: dir.c:(74) DirHandler: pn->path=/
DEBUG: dir.c:(79) OWSERVER SpecifiedBus=0 path=/
DEBUG: ow_dir.c:(78) path=/
CALL: ow_dir.c:(102) path=/
DEBUG: ow_cache.c:(854) Looking for directory 00 00 00 00 00 00 00 00
DEBUG: ow_cache.c:(867) Get from cache sn 00 00 00 00 00 00 00 00 pointer=0xb6ef5248 extension=2
DEBUG: ow_cache.c:(896) Dir not found in cache
DEBUG: ow_search.c:(32) Start of directory path=/ device=00 00 00 00 00 00 00 00
CONNECT: ow_com_write.c:(155) [Broken pipe] Trouble writing to 192.168.154.11:8080
DEBUG: ow_cache.c:(854) Looking for directory 00 00 00 00 00 00 00 00
DEBUG: ow_cache.c:(867) Get from cache sn 00 00 00 00 00 00 00 00 pointer=0xb6ef5248 extension=1
DEBUG: ow_cache.c:(896) Dir not found in cache
DEBUG: ow_cache.c:(854) Looking for directory 00 00 00 00 00 00 00 00
DEBUG: ow_cache.c:(867) Get from cache sn 00 00 00 00 00 00 00 00 pointer=0xb6ef5248 extension=0
DEBUG: ow_cache.c:(896) Dir not found in cache
DEBUG: ow_tcp_read.c:(64) attempt 3 bytes Time: 0.6000000 seconds
DEBUG: ow_tcp_read.c:(114) read: 3 - 0 = 3
DEBUG: ow_tcp_read.c:(64) attempt 3 bytes Time: 0.6000000 seconds
DEBUG: ow_tcp_read.c:(114) read: 3 - 3 = 0
CONNECT: ow_read_telnet.c:(117) Telnet (ethernet) error
DEBUG: ow_server_enet.c:(315) directory error
DEBUG: ow_com_write.c:(117) Writing to closed device 15552080
DEBUG: loop.c:(110) Taking too long, send a keep-alive pulse
DEBUG: to_client.c:(76) payload=-1 size=0, ret=0, sg=0x0 offset=0
DEBUG: to_client.c:(83) Send delay message (ping)
DEBUG: loop.c:(110) Taking too long, send a keep-alive pulse
DEBUG: to_client.c:(76) payload=-1 size=0, ret=0, sg=0x0 offset=0
DEBUG: to_client.c:(83) Send delay message (ping)
DEBUG: loop.c:(110) Taking too long, send a keep-alive pulse
DEBUG: to_client.c:(76) payload=-1 size=0, ret=0, sg=0x0 offset=0
Was noch komisch ist: auf meinem ENET ist Firmware 1.35 oben aber EDS behauptet aktuell ist 1.19
Ich habe gerade ein Mail an den EDS Support geschickt und bin gespannt was die zu dem Thema sagen.
Ansosnsten werde ich mich mal bei den OWFS Leuten anklopfen.
Bis dahin werde ich die von Frank vorgeschlagene Auswertung der XML Dateien machen.
Danke!
Hugo
Ich hatte das selbe Problem mit dem owserver enet 2 in Kombination mit owfs owserver.
Der Fehler ist bei mir nur dann aufgetreten, wenn ich mehr als einen Port des enet 2 genutzt habe.
Schließt man alle Sensoren an nur einen Port an, tritt das Problem nicht mehr auf.
Ich vermute, dass hier ein Bug in owfs owserver vorliegt, denn im Web-Interface des enet werden die Sensor-Messwerte auch dann korrekt angezeigt, wenn diese an mehrere Ports angeschlossen werden.
Viele Grüße,
Guido
Gut zu wissen, dass es jemanden gibt bei dem diese Kombination funktioniet!
Bei mir stecken die vier Sensoren alle über einen 1wire-HUB auf Kanal 1.
D.h. dieses Problem scheidet aus.
Kannst du mir bitte deine Config zukommen lassen?
ENET: Firmware, Portnummer des TCP Dienstes
owserver: Version, owfs.conf, Aufrufparameter von owserver
FHEM: Definition des OWSERVERs und evtl. der Devices
bzw. alles was dir sonst noch einfällt.
Ich hoffe, dass sich das mit einem Port nicht bewahrheitet, denn ich brauche im Endausbau alle 3
Danke!
Hugo
Hallo!
Problem gelöst!
1. OW-SERVER-ENET-V2 wir erst ab OWFS 2.8p20 unterstützt! (lt. EDS-Support durch die zusätzlich eingeführte Adressierung der 3 Kanäle)
2. Firmware 1.35 ist die aktuelle Version --> ist jetzt auch auf der Webseite von EDS zu finden.
3. Der bei mir funktionierende Aufruf von owserver ist: "./owserver --ENET=192.168.154.11:8080"
Ich nehme an, dass die Version 2.9p5 die ich kompiliert habe immer funktioniert hätte, jedoch dürfte durch das Herumprobieren mit verschiedenen Versionen irgendetwas hängen geblieben sein, denn das einzige was ich gemacht habe war ein reboot des Raspi
Nachdem der owserver funktionierte (--DEBUG hat erfolgreiche Kommunikation mit ENET gezeigt) habe ich in FHEM den OWSERVER und die devices gelöscht und FHEM neu gestartet. Nach dem neu Anlegen des owservers wurden die devices neu angelegt und plötzlich hatte ich alle Werte!
Danke nochmals für alle Tipps! Problem ist nun gelöst und war ursächlich nur ein Versionsproblem von OWFS
Hugo