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

[callidomus]

Hallo Robert,

Ich habe jetzt einen "ElabNET AMSv2 TH" und möchte den, so wie es der wiregated-ow auch macht,

Du meinst Du haste einen emulierten "ElabNET AMSv2 TH"?
Dann lösche doch die Page.3 wieder.

Welche Feuchtigkeit möchtest Du denn berechnen, absolute oder relativ?
Woher hast Du die Formel?

Und bitte lasse die ElabNET-Seitenhiebe, das hilft niemanden.
Ich finde sie machen gute 1-Wire Hardware und geben sich mühe Ihre Software zu Supporten.

Bis bald

Marcus

[Robert]

Nein, das "ich habe jetzt" sollte die hypothetische Annahme verdeutlichen, dass es jetzt einen Nutzer gibt, der das machen will.

Letzter Versuch:

Die ElabNET AMSv2 TH haben laut Code den Hex-Wert 0xF3 in der page.3. Diese bekommen daher das Mapping "V: VAD" nicht "freigeschaltet".

Code des Onewire-Plugin:

            elif page3[:2] == 'F3':  # AMSv2 TH
                return keys
            elif page3[:2] == 'F4':  # AMSv2 V
                return {'V': 'VAD'}

Das bedeutet, das jemand, der einen originalen "AMSv2 TH" hat und nicht an page.3 rumspielen möchte, nicht an "VAD" rankommt, was er aber benötigt, um die Korrektur der Luftfeuchtigkeit basierend auf dem ebenfalls auf dem "AMSv2 TH" enthaltenen DS18B20 Temperatursensor vorzunehmen (so wie es eben auch der wiregated-ow macht).

Die Formeln stammen aus dem Datenblatt des Honeywell HIH-4031 (bzw. wurden von mir passend umgestellt).

An dieser Stelle ist für mich Schluss. Alle freien Sensoren funktionieren jetzt, Besitzer eines "ElabNET AMSv2 TH" müssen dann eben mit der normalen Berechnung basierend auf dem Temperatursensor des DS2438 auskommen. Ich weiß auch nicht mehr wie ich es anders erklären soll.

Seitenhiebe von meiner gab es hier übrigens keine wenn man noch mal in Ruhe nachliest. Nur lasse ich "schon wieder" Äußerungen nicht gerne stehen wenn "schon wieder" gar nicht begründet ist.

Grüße
Robert

[MatthiasS]

Seitenhiebe von meiner Seite gab es hier übrigens keine wenn man noch mal in Ruhe nachliest.

Sehe ich auch so.

Ich würde dringend darum bitten, das sich JEDER ohne solche Bemerkungen und Unterstellungen zukünftig nur um die Sache kümmert. Ich weiß nicht, warum das ausgerechnet beim WG so ausartet. Ist wahrscheinlich historisch bedingt

Kontroverse Diskussionen ja, Worte wie Stänkern etc. (der Fall wird auch noch geklärt) wird hier im gesamten Forum niemand mehr lesen müssen.

[greentux]

Ich glaube, ich habs jetzt verstanden Robert.
Zum einen meinte Marcus mit "Plugin" wohl das 1wire Plugin. Da sind wir uns also schonmal einig

Zum anderen ist die Elabnet Idee ja gar nicht schlecht, die Adresse des 18B20 mit in einer Page abzulegen...

Anyway, ich finde nicht die Stelle im wiregated-ow, wo die Temp genutzt wird, um Humidity zu korrigieren. Lediglich für abs. Feuchte und Taupunkt wird die Temperatur vom 18B20 genutzt. Meinst Du das?

[Robert]

Hi!

Plugin - ja, hatte ich so verstanden. Ich bin nur der (unerheblichen) Meinung, dann ein Plugin nur "Rohdaten" anbieten sollte, die "Verarbeitung" aber so flexibel wie möglich im Kern erfolgen sollte. So erhält man größtmögliche Flexibilität und schlanke Plugins die gut zu pflegen sind.

Ablegen der ID in der page: Ja, klar, ist sehr komfortabel und zweckmäßig, wenn man dem Benutzer plug&play aufbereitete Werte anbieten will. Da das Wiregate dem Benutzer keinen Einfluss auf die Werteberechnung bzw. die Kombination der verwendeten Rohdaten anbietet läuft das so automatisch. Aber: Es geht ja auch gar nicht anders, da dem Webinterface die entsprechenden Eingabemöglichkeiten fehlen. So bliebe nur der Umweg über ein "Wiregate-Plugin". Das hatten wir beide übrigens schon mal diskutiert: https://knx-user-forum.de/diy-do-you....html?langid=4 - da sieht man auch, das unsere Ansichten fast gleich geblieben sind ;-)

Was die Berechnungen angeht: Habe schon ne Weile nicht mehr im wiregated-ow.pl rumgewühlt. Kann sein, dass es da nicht überall genutzt wird.

Man muss hier aber auch mal ganz klar sagen, dass der Unterschied von +-1°C im Bereich von 0,5% liegt. Das ganze macht also nur dann (abgesehen von dem akademischen Streben nach bestmöglicher Genauigkeit ;-) ) was aus, wenn die Messpunkte evtl. nicht optimal gewählt wurden und die Temperaturwerte größere Abweichungen haben. Von daher ist das Beispiel auch nur exemplarisch zu betrachten.

Daher war von "Feuchtigkeitssensor" in meinen ersten drei Beiträgen (Seite 1) auch kein Wort erwähnt. Mir geht es um Sensoren die entweder Selbstbauten sind oder die noch unbekannt sind. Diese sollten im Zweifelsfall alles "frei" haben.

Aktuelles Beispiel gefällig? - https://knx-user-forum.de/code-schnipsel/28563-wasserstandsmessung-ueber-drucksonde-und-1-wire.html

Den beiden Benutzern könnte smarthome.py out-of-the-box helfen, wenn z.B. alle Einträge des owhttpd als "ow_sensor" Keys 1:1 gemappt würden. Die würden einfach ihre Items anlegen, hart Mappen und das Endergebnis per Logik oder Eval berechnen. Ganz ohne Unterstützung der Maintainer oder page.3! Smart, oder?

Grüße
Robert

Hack (ungetestet, evtl. nicht lauffähig!, ggfl. kann man "böse" Standardfelder rausfiltern):

        elif typ == 'DS2401':  # iButton
            return {'B': 'iButton'}
        elif typ in ['DS2413', 'DS2406']:  # I/O
            return {'IA': 'sensed.A', 'IB': 'sensed.B', 'OA': 'PIO.A', 'OB': 'PIO.B'}
        elif typ == 'DS1420':  # Busmaster
            return {'BM': 'Busmaster'}
[B]     else:[/B]
[B]         logger.info("1-Wire: unknown sensor {0} {1}".format(addr, typ))[/B]
[B][COLOR=red]         autokeys = [entry.split("/")[-2] for entry in self.dir(path)][/COLOR][/B]
[B][COLOR=red]         return {entry: entry for entry in autokeys}[/COLOR][/B]

[greentux]

Naja, da nimmt der Kollege ja nen 2450. Der würde ja nicht unter das 2438 matching fallen
Egal. Also dann bin ich weiter für eine "pro Item" config a la "nocheck = 1", so dass man dann direkt den owfs dir angeben kann...