1-Wire Update

[Guest]

Originally posted by: <email address deleted>

On 6 Mrz., 19:55, "Prof. Dr. Peter A. Henning"
wrote:
> 09er ist der ID-Chip im 9097.
>
> Kann derzeit nur als "vorhanden" abgefragt werden.

o.k., Sogar 110°C kommen an

dazu gibts noch eine Warnung aus OWID.pm :
1: define: OWID: OWX_09_5B6D03050000 ID 5B6D03050000
invalid, specify a 12 digit value

ein paar Zeilen später

0: Strange call for typeless OWX_09_5B6D03050000: AttrFn
Use of uninitialized value in substr at 00_OWX.pm line 525

Bernhard

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hallo kollegen
Frage: Wieso serielle 1wire interfaces?
Ich habe 3 Cuno und auch ds9490.
Kann ich die Module einfach auf ein anderes device ändern?

Danke und gruss
Remo

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

@bernhard, OK, schau ich an. Mein DS9097-U009 ist im Moment lahmgelegt,
versuche gerade zu verstehen, welche meiner Umsteckaktionen ihn gekillt
hat. Betreffend Deine Messungen in kurzen Abständen: Warum nicht eine
Alarmtemperatur setzen, und nur dann Messungen vornehmen, wenn eines der
Devices einen Alarm gemeldet hat ? Das wäre wesentlich performanter, als
eine Messung pro Sekunde.

@appi: CUNO mappt die 1-Wire-Sensoren auf ein HomeMatic-Interface. Den
DS9490 betreibst Du vermutlich über das One-Wire-Filesystem OWFS.

Die neuen Module hingegen arbeiten direkt auf einer seriellen bzw.
USB-Schnittstelle OWX, ohne OWFS und ohne CUNO. Speziell das von mir
geschriebene Modul OWTEMP.pm  ist als Ersatz für das bestehende OWTEMP
gedacht, denn es arbeitet sowohl mit dem OWFS, als auch mit dem neuen
direkten Interface.

Martin Fischer, der Autor des OWFS-Moduls, hat auch andere Module in
Betrieb, die über OWFS solche Dinge wie Switches und A/D-Konverter
ansteuern. Diese Module hat er aber noch nicht veröffentlicht - sonst hätte
ich sie ebenfalls mit den meinen zusammengeworfen.

Mittelfristig ist folgendes geplant: die Sensoren und Aktoren werden
jeweils über dezidierte Module angebunden, wie etwa OWTEMP, OWAD, OWID etc.
In diesen Modulen sind aber Routinen implementiert, die mit jedem der drei
möglichen Interfaces zurecht kommen: CUNO, OWFS oder der direkte Anschluss
via Modul OWX. Für die OWFS- und CUNO-Teile fühle ich mich aber nicht
zuständig, das würde meine Zeit auch nicht erlauben.

Der langen Rede kurzer Sinn: Wer nur Temperatursensoren betreibt, kann
derzeit bereits wählen zwischen der Anbindung via OWFS und dem direkten
Anschluss via OWX (oder dem Betrieb an CUNO). Wer einen A/D-Konverter
betreiben möchte, kann derzeit nur via OWX anschließen (bis Martin Fischer
seine Sachen veröffentlicht hat).

LG

pah

 

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

> @bernhard, OK, schau ich an. Mein DS9097-U009 ist im Moment lahmgelegt,
> versuche gerade zu verstehen, welche meiner Umsteckaktionen ihn gekillt
> hat. Betreffend Deine Messungen in kurzen Abständen: Warum nicht eine
> Alarmtemperatur setzen, und nur dann Messungen vornehmen, wenn eines der
> Devices einen Alarm gemeldet hat ? Das wäre wesentlich performanter, als
> eine Messung pro Sekunde.

Danke für den Hinweis. Werde ich angucken.
Bisher habe ich die Sensoren mit LogTemp ausgelesen und protokolliert
und den Rest danach errechnet.

Wie und wann werden die Alarme gemeldet/erkannt?  Einfach per notify?

Gruß
Bernhard

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Das ist bisher noch nicht ordentlich implementiert (auch im alten
OWFS-Modul nicht ...). Problem ist: Werden die Sensoren parasitär versorgt,
oder mit Spannung versehen ? Man müsste mal ausprobieren, ob die parasitär
versorgten auch von sich aus das Alarm-Flag setzen ohne dass man sie
anstößt.

LG

pah

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

> OWFS-Modul nicht ...). Problem ist: Werden die Sensoren parasitär versorgt,
> oder mit Spannung versehen ? Man müsste mal ausprobieren, ob die parasitär

parasitär - ganz im Einklang mit mir

> versorgten auch von sich aus das Alarm-Flag setzen ohne dass man sie
> anstößt.

kann ich dazu etwas beitragen?




Bernhard

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

danke pah für die Erläuterungen. Das Ziel, die Zusammenführung ist
sehr spannend.
Ich werde abwarten und weiterlesen.

besten dank

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

So, inhaltlich hatte ich bisher nicht überprüft, einfach die Daten so
genommen, wie waren - (in die Irre geführt, weil ein Sensor
tatsächlich entrsprechende Werte "sehen" könnte").

Die 22-er sensoren (die anderen habe ich noch nicht angesehen) liefern
falsche Werte - vermutlich 1 Bit falsch ausgewertet.
Beispiel.1.  Sensor zeigt  118,x °C und pendelt etwas , tatsächliche
Temp um 18°C - aber jetzt nichzt annehmen, dass Komma falsch gesetzt.
2. Sensor läuft bei steigender Temperatur Rückwärts, hat auch kein
Problem mit Über-/Unterläufen  (128) und zählt einfach weiter.
Tatsächliche Temperatur im Bereich von ca. 35 ..... 90°C

Es gibt auch irgendwo im Sensor etwas, das erkennen lässt, dass der
normale Messbereich nicht ausreicht und dann längere Wandlungszeiten
benötigt.

Die 10-er-Sensoren schau ich mir noch extra an.

Bernhard




--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

OK, kann sein, muss ich überprüfen - möglicherweise ein anderer Algorithmus
bei den 22er Sensoren. Da ich die selbst nicht benutze, habe ich natürlich
gehofft, dass sie auch dieselben Bits liefern wie die 10er. Ist dann aber
kein großer Akt, das im Modul einzubauen.

Die 10er sind natürlich geprüft, laufen astrein.

Das Problem mit dem nicht erkannten 09er ist gefixt - da war noch ein
logischer Fehler bei der Unterscheidung zwischen Groß- und Kleinschreibung.






--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

OK, ist gefixt und schon im SVN.

DS1822 hat die gleiche Einteilung des Temperatur-Registers wie der DS18B20
- und mit dem habe ich es getestet.

Damit sind Tests gelaufen mit DS2502, DS18S20, DS18B20, DS2450.

Noch nicht implementiert beim Temperaturmodul: verringerte Auflösung von
weniger als 12 Bit. Außerdem werde ich noch ein regelmäßiges Alarm-Polling
in OWX.pm einbauen.

LG

pah

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Klasse, jetzt scheint es zu stimmen.


Schön - auch wenn es unverschämt scheint - wenn die Werte jetzt noch
in der Oberfläche auftauchen würden - neben Alarmed ....

Danke.
Bernhard

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Stimmte leider noch nicht ganz - ich hatt enunfür die 10er Sensoren noch
einen Fehler eingebaut.

"In der Oberfläche" bedeutet hier, in der $hash->{STATE}-Variablen.

Das muss ich erst noch etwas abwägen - denn eigentlich sollte diese den
internen Zustand des Sensors widersprigeln. Macht sie aber in vielen
anderen FHEM-Modulen auch nicht.

Dazu schwebt mir eher eine frei konfigurierbare Fassung vor, bei der jeder
selbst bestimmen kann, was in der STATE-Variablen steht.

LG

pah

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Stimmte leider noch nicht ganz - ich hatte nun für die 10er Sensoren noch
einen Fehler eingebaut.

"In der Oberfläche" bedeutet hier, in der $hash->{STATE}-Variablen.

Das muss ich erst noch etwas abwägen - denn eigentlich sollte diese den
internen Zustand des Sensors widersprigeln. Macht sie aber in vielen
anderen FHEM-Modulen auch nicht.

Dazu schwebt mir eher eine frei konfigurierbare Fassung vor, bei der jeder
selbst bestimmen kann, was in der STATE-Variablen steht.

LG

pah

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

wäre ja schon die Komfort-Version

Bernhard

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Seit geraumer Zeit verwende ich den 1Wirebus unter OWFS.
Habe heute einmal versucht meine Temperaturfühler unter
der aktuellen 21_OWTEMP.pm von Peter A. Henning in Betrieb
zu nehmen, fruchtet bei mir leider nicht. Nach Austausch
der Datei von Martin Fischer mit der von Peter A. Henning
kommt es folgender Hinweis ins LOG:

OWTEMP: Parameter [alarminterval] is obsolete now - must be set with I/
O-Device

So wie ich es lesen konnte, kann bei Austausch der beiden Dateien
das OWFS weiter genutzt werden. Hatte die Family ID der alte
Datei von Martin Fischer folgender Maßen angepasst.

  "family"      => "28",

Habe es auch mit dem neuen Modul 00_OWX.pm versucht, mein Adapter
wird aber nicht initialisiert.

Hier ein Auszug aus meiner FHEM.cfg

define DS9097 OWFS 127.0.0.1:4304 DS9097
attr DS9097 room 1Wire
attr DS9097 temp-scale C

define 1W.T_Gartenhaus OWTEMP B75EB4020000 300 180
attr 1W.T_Gartenhaus room 1Wire

etc.


Was mache ich falsch?

Wie wird der Adapter unter dem neuen Modul 00_OWX.pm richtig
initialisiert?

Nutze übrigens folgenden Adapter: http://www.fuchs-shop.com/de/shop/17/1/13372210/


MfG

Klaus




--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com