Onewire-Plugin: "Unbekannte" DS2438 sollten auch generisch unterstützt werden

[Robert]

Das Onewire-Binding liest momentan page.3 aus, um dann nur "sinnvolle" Felder zur Abfrage (ow_sensor = xxx) anzubieten. Gut gemeint, allerdings gibt es auch genug DS2438 Produkte, die dieses Schema nicht unterstützen (wollen). Diese werden in der momentanen Version mit einer Fehlermeldung komplett ignoriert!

Da man vom mündigen Benutzer ausgehen sollte, würde ich vorschlagen prinzipiell alle Felder frei zu schalten (also zumindest die beiden Spannungen, Temperatur und "berechnete" Feuchtigkeit immer) und vor allem diese auch bei unbekannten Sensoren zurückzuliefern. Sonst stehen nämlich alle Selber-Bauer auf dem Schlauch.

diff --git a/plugins/onewire/__init__.py b/plugins/onewire/__init__.py
index b50f14f..60d4b27 100755
--- a/plugins/onewire/__init__.py
+++ b/plugins/onewire/__init__.py
@@ -181,9 +181,9 @@ class OwBase():
             except Exception:
                 vis = 0
             if vis > 0:
-                keys = {'T': 'temperature', 'H': 'HIH4000/humidity', 'L': 'vis'}
+                keys = {'T': 'temperature', 'H': 'HIH4000/humidity', 'V': 'VAD', 'VDD': 'VDD', 'L': 'vis'}
             else:
-                keys = {'T': 'temperature', 'H': 'HIH4000/humidity'}
+                keys = {'T': 'temperature', 'H': 'HIH4000/humidity', 'V': 'VAD', 'VDD': 'VDD'}
             try:
                 vdd = float(self.read(path + 'VDD'))
             except Exception:
@@ -204,6 +204,7 @@ class OwBase():
                 return keys
             else:
                 logger.info("1-Wire: unknown sensor {0} {1} page3: {2}".format(addr, typ, page3))
+                return keys
         elif typ == 'DS2401':  # iButton
             return {'B': 'iButton'}
         elif typ in ['DS2413', 'DS2406']:  # I/O

Grüße
Robert

[greentux]

Selberbauer könnten aber auch was in page.3 schreiben.
Generell geht es ja um die Frage, ob man "irgendwas" supported oder nur die Sensoren, die mal einer auf dem Schreibtisch hatte.
Man könnte alternativ noch eine Option im Plugin angeben:
"experimental-sensors = y".

[2ndsky]

Ich kenn mich bei 1Wire ja nicht so aus, aber was spricht dagegen auch "irgendwas" zu supporten? Im schlimmsten Fall werden unbrauchbare Daten ausgelesen. Kaputt gehen tut dabei ja nichts.

[Robert]

Viele der User würden die page.3 nicht mal finden (über owhttpd) - zumal: Wieso nicht das anbieten, was der Sensor über owfs eh anbietet? Warum "filtern"? Ich persönlich erkenne nicht mal den Sinn darin, die Elabnet-Sensoren dort direkt zu parsen - wenn ich weiß was dran hängt, wähle ich die entsprechenden "keys", wenn ich das nicht weiß helfen mir die "gefilterten" keys auch nicht...

Es ist ja nicht so, als ob diese "verwirrenden" Einträge irgendwo ohne zutun sichtbar wären - vielmehr muss sie der Benutzer eh "händisch" eintragen.

Momentan kommt beim Initialisieren des Plugins eine Meldung, dass es den "key" nicht gibt (oder nicht - bin gar nicht mal sicher) - so würde es halt beim Lesen eines möglicherweise nicht existenten Eintrages ein "Problem reading xx.yyyyyyy/foo" geben.

[greentux]

Dann werden hier 1000 Fragen gestellt Die gleichen Probleme, die die WG Jungs quasi haben. 1wire Sensoren sind leider nicht alle gleich. Im 2438 benutzt man quasi einen Chip, der eigentlich zum Laden von Akkus gedacht ist, um ein paar Spannungen/Ströme zu messen. Daraus gibts dann mit ner Formel Feuchte, Helligkeit, etc.
Die Beschaltung kann so oder so oder so sein. Es kann dieser oder jener Feuchtesensor dran hängen. Insofern sollte man wenigstens eine kleine "Hürde" einbauen, so dass es "bewusst" ist, was man da macht. Selbstbauer meistern diese Hürde meistens

[greentux]

Robert, Du sprachst von "Selbstbauer". Die finden die page.3
Darauf bezog ich mich.

Ich selber habe ja mal einen "unbekannten 2438 Temp/Feuchte" gekauft, den DATANAB (Edelstahlröhrchen). Der war halt "anders". Man musste anders suchen, um die richtigen Werte zu bekommen.

Wie gesagt, ich bin nur dafür zwischen den, die mal einer hier im Forum auf dem Tisch hatte und komplett unbekannten Sensoren zu "unterscheiden".

[2ndsky]

Ansonsten kommen halt fragen, warum dieser und jener Sensor nicht unterstützt wird und ob man bitte die Unterstützung einbauen könnte (siehe WG Forum).

[Robert]

Wie gesagt, ich bin nur dafür zwischen den, die mal einer hier im Forum auf dem Tisch hatte und komplett unbekannten Sensoren zu "unterscheiden".

Ok, noch mal auf Start:

Ich habe hier einen werks-frischen DS2438 in meiner FOO-Anwendung. Frage: Warum muss ich jetzt irgendwo eine ID "klauen", damit ich die Werte sehe die mir owfs bei jedem DS2438 von sich aus anzeigt?

[StefanW]

Weil es schon wieder so dargestellt wird, als wäre das der "ElabNET-Sonderweg":

• Die IDs in Page.3 gab es schon bevor wir mit dem ersten Multisensor begonnen haben - in den Multisensoren des US-Wettbewerbs.
• Das OWFS nimmt bereits selbst eine Bewertung des entsprechenden DS2438 und an diesem angeschlossenen Sensoren anhand der Angaben in Page.3 vor.
• Um mit dem OFWS und anderen Produkten kompatibel zu sein, haben wir dies dann eben genauso gehandhabt, das hilft auch denjenigen, die unsere Sensoren ohne WireGate einsetzen.

==> Es ist also eine Art "Industriestandard", den wir respektiert haben.



lg


Stefan

[callidomus]

Hallo,

erst einmal, es heißt nicht Binding sondern Plugin. Ich ändere den Thread-Titel mal ab. Wir wollen doch hier niemanden zusätzlich verwirren.

Den Vorschlag von greentux mit dem zuätzlichen Keyword finde ich gut.
Ich denke hier an ein globales Keyword: go_without_support=yes
Leider ist das zu Aufwendig für diese Kleinigkeit.

Bezüglich der Filterung, ich habe bewusst die Werte herausgefiltert um es normalen Benutzern möglichst einfach zu machen.
Den Selbstbauern traue ich zu die Page.3 zu modifizieren um eine Kompatibilität mit etablierten/bekannten Lösungen herzustellen.

Ich den Patch von Robert etwas abgewandelt und commited: https://github.com/mknx/smarthome/co...4a5f3dbdd46251

Dadurch wird VAD und VDD nur bei unbekannten Sensoren angefügt.

Bis bald

Marcus

[Robert]

Weil es schon wieder so dargestellt wird, als wäre das der "ElabNET-Sonderweg"

Nein. "Schon wieder" sehe ich nur, das man sich nicht zum Thema Onewire (das sind Produkte der Firma maxim integrated!) äußern kann, ohne dass man "korrigiert" wird.

makki hat das Kennzeichnungsschema halt seinerzeit ganz pragmatisch übernommen (OWFS Developers - iButton Multisensor detection). Ist doch total in Ordnung und war an sich auch gar nicht Thema.

Was owfs aber nicht macht, ist abhängig von dieser Erkennung irgendwelche Felder auszublenden - und das obwohl das an dieser Stelle sogar noch am ehesten Sinn machen würde (weil sonst eben alle Felder im filesystem (owfs), ftp (owftpd) oder web (httpd) angezeigt werden.

Momentan ist es aber so, dass ich mich als "AMS v2" der Firma ElabNET "ausgeben" müsste, um an das Feld "VAD" zu kommen. Das ist - um den nächsten absehbaren Einwand vorweg zu nehmen - überhaupt nicht euer Fehler. Daher auch der notwendige Verweis auf ElabNET! Mach nicht immer so ein riesen Ding aus allem!

Riesen Diskussion! Dabei will ich nur bei meinen Feuchtesensoren (die wie alle anderen auf einer uralten Application Note von maxim basieren...) die Kennlinie gemäß Datenblatt (von Honeywell) korrigieren, ohne aus den Sensor einen "gefälschten ElabNET AMS v2" zu machen.

Ich warte jetzt erst mal darauf was Marcus sagt.

Entspannte Grüße
Robert

/edit: Danke Marcus, hat sich überschnitten.

[Robert]

Ok, die Lösung ist für mich jetzt ok, aber ich setzt jetzt noch einen drauf (haltet euch gut fest ):

Ich habe jetzt einen "ElabNET AMSv2 TH" und möchte den, so wie es der wiregated-ow auch macht, mit dem zusätzlichen DS18B20 (besser) temperaturkompensieren: Geht nicht, kein "VAD" um die Feuchtigkeit händisch in einem "eval" zu berechnen...

eval = ((((sh.foo.[COLOR="red"][U][I][B]Kombisensor.Spannungsmessung[/B][/I][/U][/COLOR]() / sh.foo.Kombisensor.Versorgungsspannung()) * 161.29) - 25.81) / (1.0546 - (0.00216 * sh.foo.[B][I][U][COLOR="Red"]Temperatursensor[/COLOR][/U][/I][/B].Temperatur())))
eval_trigger = foo.Kombisensor.Spannungsmessung, foo.Kombisensor.Versorgungsspannung, foo.Temperatursensor.Temperatur

P.S.: Wehe es kommt jetzt einer und sagt, man solle die owfs-interne Korrektur rausrechnen und die mit dem externen Sensor wieder reinrechnen...

[callidomus]

Hallo Robert,

ich verstehe Dein Problem nicht ganz.

Wenn Du einen AMSv2 hast, dann wird VAD als V geliefert.

Die eigentliche Umrechnung sollte man wohl aber besser in das Plugin packen.

Bis bald

Marcus

[Robert]

Nicht vom "AMSv2 TH" mit 0xF3.

Umrechnung im Plugin: Bitte bitte nicht - genau so entsteht aufgeblähter, schwer wartbarer Code der in vielen Fällen dann doch nicht die Anforderungen abdeckt und die dann folgenden Quirks unnötig kompliziert macht... Zudem: es wird ja eben ein weiterer DS18B20 hinzugezogen. ElabNET schreibt dessen ID in irgend eine page - DAS aber jetzt jedem anderen zuzumuten, der dieses Feature haben will, geht dann doch etwas zu weit denke ich. Daher: Einfach die zwei Zeilen von oben verwenden, fertig. Müssen halt nur die Felder für da sein.

[2ndsky]

Wie gesagt, ich habe keine Ahnung von dem 1Wire Zeugs (nutze nur einige Tempsensoren übers WG selber). Aber wäre es nicht möglich, im 1Wire Plugin Verzeichnis für die diversen Typen eine Art Umrechnungstabelle je Typ abzulegen? Das 1Wire Plugin liest dann den Typ aus und schaut nach, ob es ein File mit dem Typname gibt. Wenn ja wird dieses File nachgeladen und die Umrechnungsfunktion aufgerufen. Wenn nicht werden die Werte plain zurückgeliefert.