1-Wire OWX Update 23.1.2013

[ntruchsess]

Ich habe grade im 10_FRM.pm Modul die Unterstützung für OWX eingebaut (Also Funktionen für OWX_Reset, OWX_Complex und OWX_Discover implementiert, so dass man einen Arduino als Busmaster nutzen kann).

Die nötigen Änderungen (ein paar Zeilen in der Define-funtion und jeweils OWX_Reset, OWX_Complex und OWX_Discover) habe ich noch nicht commitet. Soll ich dafür erst mal einen Branch im SVN zum Review erstellen oder ein diff hier reinhängen?

Ich konnte das jedenfalls grade schon erfolgreich mit 2 DS18B20 testen, die werden vom OWX zügig gefunden und als OWTERM-devices angelegt. Dann noch schnell das Intervall auf 10 Sekunden runtergedreht und schon waren die ersten Temperaturwerte da :-)
Andere 1Wire-chips zum Testen habe ich leider (noch) nicht zur Hand.

Gruß,

Norbert

[ntruchsess]

also die Änderungen im 10_FRM.pm sind schon im SVN. Über Feedback würde ich mich freuen.

Mit 'nicht committeten Änderungen' meine ich das 00_OWX.pm modul. Da sind es ein paar Zeilen um es als 10_FRM-client laufen zu lassen anzupassen, nur mag ich natürlich nicht ohne Abstimmung ein fremdes Modul im SVN verändern. (Deshalb ist der 'eigentliche' code erstmal auch im FRM-modul, obwohl er im OWX-modul möglicherweise passender untergebracht wäre).

Gruß,

Norbert

[Prof. Dr. Peter Henning]

Die Änderungen können gerne in 00_OWX.pm eingebaut und hochgeladen werde - bitte irgendwie markieren, damit ich sie finde. Ich selbst komme nicht vor dem Wochenende dazu, an den Modulen auch nur ein Komma zu setzen.

Finde ich gut, denn damit unterstützt OWX noch eine weitere Schnittstelle. Es fehlt bisher nur noch die zum DS2490 Busmaster - daran arbeite ich. Ist nicht einfach, weil die Zusammenarbeit von perl mit den neueren Versionen der libusb nicht gut funktioniert.

Da OWX auch die wackelige 1-Wire-Anbindung von COC und CUNO bespielt, bin ich mal gespannt, wie sich hier der Arduino positionieren kann.

LG

pah

[ntruchsess]

die Änderungen an 00_OWX.pm sind commitet. Sind alle kommentiert, aber sowieso leicht zu finden, es wird nach dem jeweiligen if ($hash->{INTERFACE}="firmata") ja nur an die in FRM implementierten Funktionen deligiert. In OWX ist keine echte Funktionalität reingekommen.

Ich bin mir aber nicht sicher, ob das Design an sich so schlau ist (ein Modul mit einer gemeinsamen Konfiguration für ganz unterschiedliche Hardware). Das ist ja ziemlich unübersichtlich. Und man braucht für die unterschiedliche Hardware ja auch unterschiedliche Attribute. FRM beispielsweise ist über IODev angebunden (wenn man mehrere FRMs definiert hat). CUNO geht über den Device-namen und alles Serielle über die (OS-spezifische) Schnittstellenbezeichnung. Man könnte genauso ein OWC_SER, OWX_CUNO und OWX_FRM machen, dafür muss man ja nicht substanziell code neuschreiben, Eine Init und Define-methode reichen ja. Dann die jeweiligen 'OWX_xxx_CCC'/'OWX_xxx_SER'/'OWX_xxx_FRM'-methoden in die passenden module schieben und fertig. In OWX wären dann nur noch die für die eigentlichen OW-devices nötigen einheitlichen Interfacemethoden drin, die dann an die jeweiligen hardwarespezifischen methoden deligieren.

Gruß,

Norbert

[B50one]

Hallo Peter,

mit dem aktuellen Modul 21_OWTHERM wird tempHigh und tempLow nicht richtig übernommen.

Es hatte lange einwandfrei funktioniert :-)  


Hier ein Auszug aus meiner FHEM.cfg

define 1W.T_Gartenhaus OWTHERM DS18B20 AAD2B5020000
attr 1W.T_Gartenhaus IODev DS9097
attr 1W.T_Gartenhaus model DS18B20
attr 1W.T_Gartenhaus room .1Wire
attr 1W.T_Gartenhaus stateAH <span style="color:red">Hot</span>
attr 1W.T_Gartenhaus stateAL <span style="color:blue">Cool</span>
attr 1W.T_Gartenhaus tempHigh 23
attr 1W.T_Gartenhaus tempLow 3

Hier die Initialisierung

(siehe Anhang / see attachement)

Hier nach der Initialisierung. temHigh und tempLow haben andere Werte :-(

Warum?

(siehe Anhang / see attachement)


Woran kann ich noch schrauben?

Gruß Klaus

[Prof. Dr. Peter Henning]

Wie aus dem Wert 23 42 werden kann und aus 3 die 20 ??? Erstaunlich, versuche ich erst einmal nachzuvollziehen.

Bitte mal probieren, was das Log sagt, wenn man die korrekten werte von Hand setzt.

LG

pah

[Prof. Dr. Peter Henning]

Das ist durchaus auch so geplant, darum schon die verschiedenen Bezeichnungen für die einzelnen Interface-Routinen.
00_OWX.pm ist einfach zu groß geworden, um noch gut wartbar zu sein. Hat aber natürlich historische Gründe, insofern bitte ich auch um etwas Geduld.

LG

pah

[B50one]

Hallo Peter,

hier das Ergebnis der Handsetzung.

1: SETTING DEVICE with 1W.T_Gartenhaus tempHigh 23 and present=1 and state=  6.38 &deg;C <span style="color:blue">Cool</span>
1: SETTING DEVICE with 1W.T_Gartenhaus tempLow 3 and present=1 and state=  6.38 &deg;C <span style="color:blue">Cool</span>

Hier die grafische Ausgabe nach der Handsetzung.

Wobei ich in der Vergangenheit auch die Erfahrung machen musste, dass teilweise
falsche Werte nach der nächsten Abfrage eingetragen wurden.

(siehe Anhang / see attachement)

Gruß Klaus

Hier die grafische Ausgabe nach einem anschließendem shutdown restart nach der Initialisierung.

(siehe Anhang / see attachement)

[B50one]

Hallo Peter, hier noch einige Fakten.

Ich habe die Initialisierung meiner Temperaturfühler nochmals überprüft.
Es wird das ausgeführt was in der FHEM.cfg eingetragen ist.

Hier exemplarisch der Fühler vom Gartenhaus

2013.02.03 17:19:14 5: Cmd: >attr 1W.T_Gartenhaus IODev DS9097<
2013.02.03 17:19:14 5: Cmd: >attr 1W.T_Gartenhaus fp_Erdgeschoss 390,860,1,Gartenhaus<
2013.02.03 17:19:14 5: Cmd: >attr 1W.T_Gartenhaus icon icoTempBaum.png<
2013.02.03 17:19:14 5: Cmd: >attr 1W.T_Gartenhaus model DS18B20<
2013.02.03 17:19:14 5: Cmd: >attr 1W.T_Gartenhaus room .1Wire<
2013.02.03 17:19:14 5: Cmd: >attr 1W.T_Gartenhaus stateAH <span style="color:red">Hot</span><
2013.02.03 17:19:14 5: Cmd: >attr 1W.T_Gartenhaus stateAL <span style="color:blue">Cool</span><
2013.02.03 17:19:14 5: Cmd: >attr 1W.T_Gartenhaus tempHigh 23<
2013.02.03 17:19:14 5: Cmd: >attr 1W.T_Gartenhaus tempLow 3<

Bei allen 9 Temperaturfühlern steht nach der Initialisierung tempHigh auf 45 bzw. auf tempLow 28.

(siehe Anhang / see attachement)

Bei zwei Fühlern sind diese Werte in der FHEM.cfg wirlich gesetzt. 1W.T_Wasser 1W.T_Zirkulation
Alle anderen Fühler haben andere Werte für tempHigh und tempLow.


Gruß Klaus

[B50one]

Hier noch ein Nachtag :-(

Ich habe tmpHigh und tempLow für den Temperaturfühler Gartenhaus manuell gestellt.

Das Ergebnis, danach haben alle 9 Temperaturfühler in den den Attributen den gleichen Wert.

Diese Verhalten kann durch setzen der Werte bei unterschiedlichen Fühlern beobachtet werden.


Gruß Klaus

[Prof. Dr. Peter Henning]

Hm, übel.

Lass mich mal zusammenfassen

- 9 Stück DS18B20 (an welchem Interface ?)
- Attributwerte aus tempLow/tempHigh werden falsch aus der Config übernommen und ersetzt durch die beiden Werte 28/45, diese
  beiden Werte gibtes aber tatsächlich bei zwei der 9 Sensoren (stehen diese zufällig als Letztes in der Config ?)
- Manuelles Setzen von tempLow und tempHigh wirkt sich auf die Anzeige aller 9 Sensoren aus

Sieht so aus, als ob die Daten der Alarmtemperaturen irgendwo im Programm herumgeistern und bei den falschen Sensoren angezeigt werden.

Muss ich überprüfen, werde dazu heute nachmittag einen Testaufbau mit mehreren T-Sensoren machen.

LG

pah

[B50one]

Hallo Peter,

ich verwende folgendes Interface -> LinkUSBi http://www.fuchs-shop.com/de/shop/17/1/13372210/

Hinweis: Hatte bis dato keine Probleme mit dem Interface

Die Sensoren stehen nicht an letzter Stelle. -> Siehe Anhang.

Nach meinem gestrigen Test wirkte sich die Einstellung auf alle Sensoren aus ;-(


Gruß Klaus

[Prof. Dr. Peter Henning]

OK, da habe ich wirklich einen Fehler eingebaut gehabt.

Ist behoben und eingecheckt - bitte testen.

LG

pah

[B50one]

Hallo Peter,

der erste Eindruck, funktioniert wieder :-)

Sollte sich etwas anderes ergeben, melde ich mich wieder.

Die Änderung mit dem T: ist in Ordnung. Die Ausgabe 'temperature' hatte ich im Modul immer manuell entfernt.
War nur nach einem Update immer etwas nervig. Die Krönung, über ein attr einstellbar :-)  

Danke.


Gruß Klaus

[det.]

Hallo Peter,

ich hatte den Fehler die ganze Zeit auch und still auf ein Update gehofft - Danke, der ist jetzt weg. Du hattest früher allerdings mal auf die Investition im Zusammenhang mit FHEM hingewiesen...
So hätte ich doch eine Warnung erwartet, wenn Du stillschweigend die Maschine von Benzin auf Diesel umstellst. Nach Wegfall temperature - Änderung in T - schaltet und "anzeigt" bei mir erst mal nichts mehr wie erwartet. Gut das mein erster Termin heute erst um 9 ist, da konnte ich das für über 20 Sensoren in einer ungeplanten Frühschicht fixen.
Im Zuge einer ganz sicher empfehlenswerten Vereinheitlichung möchte ich meinen Wunsch noch mal wiederholen: auch die stateFormat Befehle in die OWX Module einzuführen und im STATE auf jegliche Sonderwege verzichten, das fördert bestimmt die Akzeptanz und Benutzerfreundlichkeit.