1-Wire OWX Update 23.1.2013

Prof. Dr. Peter Henning · 23 Januar 2013, 09:00:14

Guten Morgen Liste,

neue Module:

OWX.pm
OWAD.pm
OWCOUNT.pm
OWMULTI.pm
OWSWITCH.pm
OWTHERM.pm

Änderungen:
- Bessere Stabilität von OWX mit CUNO/COC durch Umgehen einiger Teile aus dem CUL-Modul
- Alarm-Setting und Darstellung von OWAD und OWTHERM geändert
- Alle fünf letztgenannten Module laufen auch mit OWServer zusammen. Dazu muss allerdings das jeweilige Modul in die "Clients"-Liste von OWServer eingetragen werden.
- Diverse kleinere Fixes.

LG

pah

det. · 23 Januar 2013, 09:58:33

Hallo Peter,

vielen Dank für die Weiterentwicklung Deiner Module. Hab sie soeben eingespielt und gleich eine Warnung an weitere Test - willige: die Einträge für tempHigh und tempLow in fhem.cfg müssen vor dem Neustart auskommentiert oder gelöscht werden, sonst (zumindest bei mir) stirbt FHEM beim Neustart ab mit z.B. folgender Fehlermeldung im LOG:

Code Auswählen

OWTHERM: Set with wrong value 60 for tempHigh, range is  [-0.0,0.0]
OWTHERM: Set with wrong value 15 for tempLow, range is  [-0.0,0.0]

Nach Löschen dieser tempHigh und tempLow Zeilen funktioniert alles wie gewünscht und die Einträge werden auch automatisch neu auf die früher mal gewählten Werte wieder in die fhem.cfg eingetragen.
Keine Ahnung, was uns der Meister damit sagen wollte.
Andere frühere Scheusslichkeiten wie die 85° vor dem ersten reding sind weg und es sieht alles wirklich gut aus.
Eine schon mal geäußerte Bitte zum Schluß - wie bekomme ich bei die Darstellung in ein einheitliches Format ohne das völlig sinnlose Wort temperature siehe Bild:?

(siehe Anhang / see attachement)

Tobias · 23 Januar 2013, 10:34:02

Zitat von: det. schrieb am Mi, 23 Januar 2013 09:58Eine schon mal geäußerte Bitte zum Schluß - wie bekomme ich bei die Darstellung in ein einheitliches Format ohne das völlig sinnlose Wort temperature siehe Bild:?
(siehe Anhang / see attachement)

ist das Attribut stateformat vorhanden? Schonmal dieses ausprobiert? Damit kannst du selbst festlegen wie es aussehen soll.

det. · 23 Januar 2013, 10:42:23

Hallo Tobias,

wenn Du vorher selbst nachgeschaut hättest: das Attribut heißt nicht stateformat sondern stateFormat und ist eben genau in pah's Modulen (noch) nicht vorhanden. Was meinst Du, wieso ich die Darstellung der Temperaturwerte der 3 HMS Sensoren auf dem Bild so hinbekommen habe:

Code Auswählen

stateFormat {sprintf("%.1f",ReadingsVal("Garage_KG","temperature",0))."°C"}

Prof. Dr. Peter Henning · 23 Januar 2013, 11:21:01

Oops, das soll nicht sein.

Werde ich heute nachmittag fixen.

LG

pah

Prof. Dr. Peter Henning · 23 Januar 2013, 11:25:16

"Noch" ist das richtige Wort. Das sollte eigentlich in dieses Release schon rein, weil die Voraussetzungen dafür schon vollständig existieren. Habe ich aber zeitlich nicht geschafft, kommt demnächst.

LG

pah

det. · 23 Januar 2013, 12:07:23

Hallo Peter,

"Noch" klingt doch gut. Freue mich, wenn es kommt. Dann kann man die Anzeigen einheitlich gestalten, egal was für eine Technik dahinter werkelt.
Bis jetzt geht noch alles nach dem Update genau wie gewünscht.
Eine weitere Kleinigkeit hab ich noch als Wunsch für eines der nächsten Updates:

(siehe Anhang / see attachement)

Prof. Dr. Peter Henning · 23 Januar 2013, 20:53:38

OK, das Problem mit den Alarm Settings in der Konfigurationsdatei ist gelöst - war etwas aufwändiger, als erhofft. OWAD und OWTHERM sind gefixt, bei den anderen tritt das Problem gar nicht auf.

Das Bild im obigen Post seh eich zwar - aber was ist nun der Wunsch ?

LG

pah

det. · 23 Januar 2013, 21:03:58

Der state von dem Switch sollte A: OFF B: ON< sein, ist er eigentlich auch, nur angezeigt wird output A OFF . Von B: steht nichts da. Dabei habe ich schon eine include.cfg eingebunden, die den Switch nach dem Systemrestart noch mal initialisiert. Das tritt nur bei dem Switch auf dem Boden auf. sollte ich vielleicht auch so einen Tiefpass einbauen, wie Herr Tostmann das letztens für den COC mit längerem Bus empfahl und es liegt gar nicht am Modul?

Prof. Dr. Peter Henning · 24 Januar 2013, 10:46:39

Muss ich überprüfen - B ON sollte auf jeden Fall im State mit drin sein. Schaue heute nachmittag mal drauf.

Prof. Dr. Peter Henning · 25 Januar 2013, 14:33:44

Nein, tritt bei mir nicht auf, wird ganz korrekt angezeigt. Bitte mitteilen, welches Release das ist.

LG

pah

det. · 25 Januar 2013, 16:38:57

Code Auswählen

# $Id: 21_OWSWITCH.pm 2556 2013-01-23 07:54:06Z pahenning $

tritt aber nur an dem Switch auf dem Boden auf - vieleicht doch ein Problem - Tiefpass - Leitungslänge (ca. 30 m geschirmter Klingeldraht)?

Prof. Dr. Peter Henning · 25 Januar 2013, 17:04:19

Hm,

sehe ich das erste Mal. Könnte höchstens sein, dass die Returns von dem DS2413 auf einen inkonsistenten Zustand des Schalters hinweisen (Gemessen OFF=Offen, aber gesetzt ON=Geschlossen).

Das wäre der vierte Zustand neben ON, OFF und ON > - und er kann eigl. nur vorkommen, wenn irgendetwas den Ausgangstransistor gekillt hat.

In Zeilen 957/958 des Modules wird die innere Konsistenz der Daten überprüft: Die ersten vier Bit sind das Komplement der zweiten 4 Bit. Bitte einfach mal den Zahlenwert ord($data[1]) ausgeben lassen an dieser Stelle.

LG

pah

Schorsch · 28 Januar 2013, 11:11:26

Zitat von: Prof. Dr. Peter Henning schrieb am Mi, 23 Januar 2013 09:00- Alle fünf letztgenannten Module laufen auch mit OWServer zusammen. Dazu muss allerdings das jeweilige Modul in die "Clients"-Liste von OWServer eingetragen werden.

Hallo Peter,

das wollte ich mal ausprobieren, aber wo finde ich die angeprochene "Clients"-Liste? Im OWServer-Modul selbst? Das würde ich nur ungern selbst ändern, denn damit klinke ich mich ja aus dem Update-Prozess aus. Das einfache Definieren eines OWDevice namens OWCOUNT scheint es jedenfalls nicht zu sein oder ich mache was falsch. Wie sieht ein Beispieleintrag aus?

OWServer und OWDevice an sich laufen hier und finden alles - aber Deine Module würde ich gern weiter nutzen. Denn ich schätze ein paar Sachen an Deinen Modulen sehr für den simplen täglichen Einsatz (insbesondere integrierte Ratenberechnung, Offset, Einheiten etc. bei OWCOUNT, die einfache Einbindung von OWAD, sinnige automatische States auch bei DS1820 und nicht nur bei 18B20, etc.) und daher würde ich die wirklich gern mit OWServer nutzen.

Mit OWX funktionierte bei mir alles, zumindest im parasitären Modus. Da ich aber dabei bin, den Bus neu zu bauen und alle bis auf einen Counter (das GP1-Modul geht nur parasitär) mit 5V versorge, hatte ich mal Buspower "real" probiert und das scheitert leider (GP1 wird nicht gefunden, die versorgten Sachen schon - Timing-Issue denke ich). Daher OWServer getestet und der findet alles, obwohl er auch nicht im ganz langsamen Modus läuft (dem Blinken am Hub nach zu urteilen).

Danke und Grüße!
Georg

Prof. Dr. Peter Henning · 28 Januar 2013, 12:02:32

Der Modulname (z.B. OWCOUNT) muss eigentlich in die Liste, die im 10_OWServer.pm in der subroutine OWServer_Initialize unter hash->{Clients} steht.

Geht aber auch ohne, wenn man brutal beim OWCOUNT-Device das IODev auf den OWServer umsetzt. Dann kann es aber sein, dass das Modul nicht richtig startet, wenn kein zusätzliches OWX-Device vorhanden ist.

Hier also bitte den Maintainer von OWServer bitten, den Eintrag vorzunehmen - von mir hat er die Bitte schon bekommen, sie aber bisher ignoriert.

Bin den Rest der Woche über vollkommen eingespannt in andere Dinge, sorry.

LG

pah

ntruchsess · 30 Januar 2013, 01:41:44

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 · 30 Januar 2013, 01:47:17

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 · 30 Januar 2013, 07:48:08

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 · 30 Januar 2013, 13:48:28

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 · 31 Januar 2013, 18:54:12

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 Hot
attr 1W.T_Gartenhaus stateAL Cool
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 · 01 Februar 2013, 08:38:21

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 · 01 Februar 2013, 08:41:20

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 · 01 Februar 2013, 13:25:25

Hallo Peter,

hier das Ergebnis der Handsetzung.

1: SETTING DEVICE with 1W.T_Gartenhaus tempHigh 23 and present=1 and state= 6.38 °C Cool
1: SETTING DEVICE with 1W.T_Gartenhaus tempLow 3 and present=1 and state= 6.38 °C Cool

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 · 03 Februar 2013, 18:13:35

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 Hot<
2013.02.03 17:19:14 5: Cmd: >attr 1W.T_Gartenhaus stateAL Cool<
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 · 03 Februar 2013, 19:22:02

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 · 04 Februar 2013, 10:25:03

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 · 04 Februar 2013, 19:11:12

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 · 04 Februar 2013, 20:41:25

OK, da habe ich wirklich einen Fehler eingebaut gehabt.

Ist behoben und eingecheckt - bitte testen.

LG

pah

B50one · 04 Februar 2013, 21:38:58

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. · 05 Februar 2013, 08:11:55

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.

B50one · 05 Februar 2013, 08:32:38

Hallo Peter,

hier ein kleiner Nachtrag. Bei der manuellen Setzung der tempHigh und temLow Werte
scheint es noch ein kleines Problem zu geben. Sie werden bei mir nicht in die Übersicht
der attr übernommen.

Laut LOG werden sie jedoch gesendet.

Hier ein Beispiel.

5: Cmd: >set 1W.T_Gartenhaus tempLow 5<
4: OWTHERM: Set 1W.T_Gartenhaus tempLow 5
5: Triggering 1W.T_Gartenhaus (1 changes)
5: Notify loop for 1W.T_Gartenhaus tempLow 5

Gruß Klaus

Tobias · 05 Februar 2013, 08:41:56

Zitat von: B50one schrieb am Di, 05 Februar 2013 08:32Hallo Peter,
hier ein kleiner Nachtrag. Bei der manuellen Setzung der tempHigh und temLow Werte
scheint es noch ein kleines Problem zu geben. Sie werden bei mir nicht in die Übersicht
der attr übernommen.

Das ist korrekt, laut Manual ist das so das ein "set" nur temporär ändert.

B50one · 05 Februar 2013, 09:32:28

ZitatDas ist korrekt, laut Manual ist das so das ein "set" nur temporär ändert.

Wenn die Änderung nicht bei der attr Übersicht eingetragen wird, greift ein darauf bezogenes Notify doch nicht.

Oder sehe ich das falsch?

Prof. Dr. Peter Henning · 05 Februar 2013, 10:06:12

Na ja, so groß wie zwischen Diesel und Benzin ist der Unterschied nun wieder nicht...

War aber anders geplant - der doofe Fehler kam eben beim Einbau des stateFormat dazwischen. Bitte also, den Kollateralschaden zu verzeihen...

LG

pah

det. · 05 Februar 2013, 13:11:38

Zitat von: Prof. Dr. Peter Henning schrieb am Di, 05 Februar 2013 10:06Na ja, so groß wie zwischen Diesel und Benzin ist der Unterschied nun wieder nicht...

War aber anders geplant - der doofe Fehler kam eben beim Einbau des stateFormat dazwischen. Bitte also, den Kollateralschaden zu verzeihen...

LG

pah

Hallo Peter,

kein Problem weiter, wird alles wieder - wenn ich heute Abend von Arbeit zurück bin fixe ich noch die vergessene Stelle, die mir alle paar Minuten eine Mail sendet, weil der Tiefkühler angeblich 20°C hat. Wie ist man doch inzwischen abhängig von der Technik, früher ist das Zeugs drin einfach vergammelt, weil ich nach der Nutzung der Steckdose für die Bohrmaschine den Tiefkühler nicht wieder reingesteckt hatte...
Der von Dir geplante Einbau des stateFormat wird jedenfalls schon mal freudig erwartet.

B50one · 07 Februar 2013, 15:43:39

Zitat von: B50one schrieb am Di, 05 Februar 2013 08:32Hallo Peter,

hier ein kleiner Nachtrag. Bei der manuellen Setzung der tempHigh und temLow Werte
scheint es noch ein kleines Problem zu geben. Sie werden bei mir nicht in die Übersicht
der attr übernommen.

Laut LOG werden sie jedoch gesendet.

Hier ein Beispiel.

5: Cmd: >set 1W.T_Gartenhaus tempLow 5<
4: OWTHERM: Set 1W.T_Gartenhaus tempLow 5
5: Triggering 1W.T_Gartenhaus (1 changes)
5: Notify loop for 1W.T_Gartenhaus tempLow 5

Gruß Klaus

Hallo Peter,

ich möchte dieses Sache nochmals aufgreifen. Ist das so gewollt oder ein Bug?