Ankündigung

Einklappen
Keine Ankündigung bisher.

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

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • greentux
    antwortet
    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...

    Einen Kommentar schreiben:


  • Robert
    antwortet
    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):
    Code:
            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'}
         else:
             logger.info("1-Wire: unknown sensor {0} {1}".format(addr, typ))
             autokeys = [entry.split("/")[-2] for entry in self.dir(path)]
             return {entry: entry for entry in autokeys}

    Einen Kommentar schreiben:


  • greentux
    antwortet
    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?

    Einen Kommentar schreiben:


  • MatthiasS
    antwortet
    Zitat von Robert Beitrag anzeigen
    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.

    Einen Kommentar schreiben:


  • Robert
    antwortet
    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:
    Code:
                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

    Einen Kommentar schreiben:


  • callidomus
    antwortet
    Hallo Robert,



    Zitat von Robert Beitrag anzeigen
    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

    Einen Kommentar schreiben:


  • 2ndsky
    antwortet
    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.

    Einen Kommentar schreiben:


  • Robert
    antwortet
    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.

    Einen Kommentar schreiben:


  • callidomus
    antwortet
    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

    Einen Kommentar schreiben:


  • Robert
    antwortet
    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...

    Code:
    eval = ((((sh.foo.Kombisensor.Spannungsmessung() / sh.foo.Kombisensor.Versorgungsspannung()) * 161.29) - 25.81) / (1.0546 - (0.00216 * sh.foo.Temperatursensor.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...

    Einen Kommentar schreiben:


  • Robert
    antwortet
    Zitat von StefanW Beitrag anzeigen
    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.

    Einen Kommentar schreiben:


  • callidomus
    antwortet
    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

    Einen Kommentar schreiben:


  • StefanW
    antwortet
    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

    Einen Kommentar schreiben:


  • Robert
    antwortet
    Zitat von greentux Beitrag anzeigen
    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?

    Einen Kommentar schreiben:


  • 2ndsky
    antwortet
    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).

    Einen Kommentar schreiben:

Lädt...
X