I2C AD-Wandler ADS1115 von Texas Instruments

[schlawiano]

Anbei jetzt im ersten Eintrag die aktuelle Version

Status: ist immer noch Beta,  bis ausreichend getestet wurde.

Baut zufällig jemand an einem Modul für den I2C AD-Wandler ADS1115 von Texas Instruments

( Ich frage, weil ich ein Modul gerade ein Modul für den BH1750FV gebaut habe - 2 Tage später war dann ein weiteres drin.)


Falls nein, können gerne Anregungen und Ideen genannt werden für meine Umsetzung genannt werden.



Hier nur ein paar Anwendungsbeispiele, für was ich das Ganze nutzen möchte

1) Lichtsensor derzeit per Poti-Einstellung an Digitalausgang getriggert - das ist nicht fein genug. Besser ist den Analog-Ausgang zu messen und den Schwellwert per Software zu bestimmen.

2) beim CO-Gas-Detector (z.B. M2) wird über einen Heizdraht der Widerstand ausgewertet. Ist es im Zimmer warm gibt es ständig Fehlalarme, auch hier wäre eine Messung am Analog-Ausgang und Meldung unter Berücksichtigung der Zimmertemperatur sinnvoll.

3) Regensensor (Modul YL-38). Es interessiert auch hier, nicht nur ob es regnet, sondern auch wie stark.

[locutus]

Ich kann zwar nicht mitentwickeln, aber interessiert bin ich schon.
Ursprünglich wollte ich einen SCT-013 non-invasive AC Current Sensor am ADS1115 betreiben, um damit den Stromverbrauch zu erfassen.
Bsp.: http://www.seeedstudio.com/recipe/377-esp8266-iot-energy-monitor.html

[schlawiano]

Mitentwickeln erwarte ich gar nicht. Eher mal mittesten, wenn ich es auf einen brauchbaren Stand gebracht habe;-)

Na dann mach ich mich mal die nächsten Tage ans Werk. Bei dem Regenwetter ist es nicht schlecht mal am PC zu tüfteln.

[kpl]

Hallo schlawiano,
Ich kann auch gerne mit testen. Ich verwende den ADS1115 zur Batteriespannung und Strommessung über LEM HTFS 400-P/SP2 Stromwandler einer Insel Solaranlage.
Derzeit übertrage ich die Messwerte noch über ein python script an FHEM.
Gruß, kpl

[schlawiano]

Ich komme nächste Woche noch mal auf Euch zu
Danke für die Rückmeldung

[schlawiano]

Vll. hat jemand eine Idee oder Anregung.

1) Frage
Der Chip unterstützt 4 Eingänge, dazu können diese noch unterschiedlich miteinander verglichen werden.

Theoretisch wären 2-4 Readings (Messungen) der Werte möglich.

Für jede Messung  soll man (Enabled, SamplingRate, Gain, GültigerRahmen) verschieden einstellen können.
Nun meine Frage, wie sollte man am besten die Attribute gestalten ?

z.B.
SINGLE_2_Config_Gain
SINGLE_2_Config_DataRate
SINGLE_2_Config_LowThreshold
SINGLE_2_Config_HighThreshold

und das ganze 8 mal ?
oder besser

SINGLE_2_Config mit einen Wert der geparst wird ?

oder gibs so was wie Unterattribute ?

Eine Idee wäre auch Untermodule für die Eingänge zu machen, die man dann mit dem ADS1115 verknüpft


2) geplant ist derzeit nur ein Polling. Sprich Auslesen aller gewünschten Readings. Wäre das ok, oder braucht jemand
verschiedene Timings für verschiedene Eingänge ?

[klausw]

Vll. hat jemand eine Idee oder Anregung.

1) Frage
Der Chip unterstützt 4 Eingänge, dazu können diese noch unterschiedlich miteinander verglichen werden.

Theoretisch wären 2-4 Readings (Messungen) der Werte möglich.

Für jede Messung  soll man (Enabled, SamplingRate, Gain, GültigerRahmen) verschieden einstellen können.
Nun meine Frage, wie sollte man am besten die Attribute gestalten ?

z.B.
SINGLE_2_Config_Gain
SINGLE_2_Config_DataRate
SINGLE_2_Config_LowThreshold
SINGLE_2_Config_HighThreshold

und das ganze 8 mal ?
oder besser

SINGLE_2_Config mit einen Wert der geparst wird ?

Das ist eher eine philosophische Frage. Zum einen ist weniger oft mehr. Zum anderen bietet FHEM bei den Attributen Checkboxen, Dropdown Menüs, Drag&Drop die eine Konfiguration recht komfortabel machen.

Gibt es unterschiede bei den Konfiguration zwischen Absolut und Differenzmessung?
Evtl. kommen da weitere Attribute hinzu.

oder gibs so was wie Unterattribute ?

gibt es leider nicht
die Attribute lassen sich auch leider nicht dynamisch anpassen (...obwohl, evtl. kann man $hash->{AttrList} dynamisch modifizieren... das wäre einen Versuch wert, wenn du das versuchst halte mich bitte auf dem Laufenden  )

Eine Idee wäre auch Untermodule für die Eingänge zu machen, die man dann mit dem ADS1115 verknüpft

Oder direkt Module, die jeweils nur einen Eingang lesen (also im Define I2C-Adresse und Kanal angeben /bzw. 2 Kanäle bei Differenzmessung)
Das ist natürlich elegant, aber auch komplex, da unterschiedliche Kanäle evtl. auf gleiche Register zugreifen.
Ausserdem musst du beim anlegen nachprüfen, ob es bereits ein define für den gleichen Kanal gibt.

2) geplant ist derzeit nur ein Polling. Sprich Auslesen aller gewünschten Readings. Wäre das ok, oder braucht jemand
verschiedene Timings für verschiedene Eingänge ?

Das polling machst du bestimmt über ein Attribut einstllbar?
Es ist sicher am sinnvollsten, alle Werte auszulesen. Unterschiedliche Pollzeiten machen die Abfrageroutine recht komplex.
Allerdings hat der ADS1115 noch einen ALERT Ausgang. Ich habe das Datenblatt nur überflogen, aber wenn ich es richtig verstanden habe, kannst du Schwellwerte programmieren, deren unter/überschreiten den ALERT Pin toggelt.
Attribute für das Setup dieses Pins wären sicher super.
Dann kannst du über einen GPIO Interrupts bei Änderung auslösen und Ereignisgesteuert die Werte auslesen.

[schlawiano]

Hallo Klaus,

danke für die Rückmeldung.

Ich habe gestern mal ein Perl-Skript gebastelt um zu schauen, wie der Sensor sich real verhält
und bin gerade am Testen.



Hier einige Gedanken um Deine  Idee mit dem "pro Modul getrennten Eingang" weiterzuspinnen.
- bei kleiner  SamplingRate , minimal 8SPS, d.h. Lesedauer dann mit 125 ms sollte das Ganze asynchron laufen
um nicht andere Prozesse zu blockieren. Bei pro Eingang getrennten Modulen müsste man sicherstellen,
dass andere Module nicht zeitgleich auf den Sensor zugreifen(Semaphoren) und die Aufgaben danach trotzdem abarbeiten (queues).

Wenn man schon so weit geht, kann man dann auch ein getrenntes Polling erlauben.

Semaphoren und queues müssten für den Sensor zentral abgelegt werden.


Wenn ein Messvorgang zum ALERT/RDY meldete, sollte man wissen, was zuletzt gemessen wurde (also wo die Grenze verletzt wurde).
Auch wäre eine zentrale Stelle sinnvoll.

Da ich so oft die zentrale Stelle betone, merkst Du sicher dass ich auf 2 Module hinaus möchte


52_I2C_ADS1115_Channel
   Attribute:
      Mux (SINGLE0..3, oder einen DIFF_X_Y)
      Interval
      Gain
      DataRate
      LowerThreshold,
      UpperThreshold,
      ComparatorMode
      ComparatorPolarity
      LatchingComparator
      Offset ( Verschiebung des Messwertes nach dem Lesen)
      Faktor   ( Multiplikation  des Messwertes nach dem Lesen)
   Readings:
      State
      


52_I2C_ADS1115
   Define
      I2C-Adresse
   Internal
      MODUL_STATE (DEFINED, ERROR, )
      DEVICE_STATE (READY, CONFIGURE, MEASURING)
      LAST_CHANNEL (Name vom 52_I2C_ADS1115_Channel)
      CURRENT_CHANNEL (Name vom 52_I2C_ADS1115_Channel)
   
   Queues
   Clients


Was denkst Du ? Viel Arbeit, aber wahrscheinlich ein guter Weg ?

Viele Grüße
Karsten

[klausw]

Moin Karsten,

stimmt sobald ein asynchroner Zugriff notwendig ist machen 2 Module durchaus Sinn.
Der Aufwand ist schon höher aber sicher überschaubar.
Die Frage ist eher, ob du Lust hast es zu machen Sauberer ist die Lösung sicherlich.

Ein Modul wird für gewöhnlich einmal definiert und dann ist gut. Wenn du nicht über Hilfsmodule wir readings Proxy gehen musst wird es natürlich einfacher. Aber wie gesagt, das machst du nur einmal.

[Prof. Dr. Peter Henning]

Vlt. mal ansehen, wie ich das beim Modul OWAD (4-fach A/D-Wandler) gelöst habe. Der Witz ist dort, dass die Kanalnamen, Attribute und Skalenfunktionen per Attribut gesetzt werden können.

Es ist nämlich sinnvoller, in den Readings gleich den korrekt umgerechneten Datenwert "CO-Gehalt" angezeigt zu bekommen, als einen kryptischen Spannungswert.

LG

pah

[schlawiano]

Hallo Prof. Dr. Peter Henning,

leider sah ich Ihre Info zu spät. Inzwischen habe ich einen großen Teil schon umgesetzt.
Ihr Ansatz ist durchaus interessant. Bei 4 Kanälen sind die 24 Attribute durchaus überschaubar. Man nutzt ja nicht alle.
Beim ADS 1115 kommen noch die 4 Differenz-Messungen zwischen einzelnen Kanälen dazu. Das wären dann 8 Varianten * Konfigurationsparameter. Auch da scheint auf den ersten Blick der ADS1115 mehr Möglichkeiten zur Konfiguration  zu bieten. Hier würde es den Nutzer an Attributen erschlagen.
Ich empfinde die jetzige Lösung als ganz praktikabel. Jeder Eingang ist eine eigene Modulinstanz. Man kann diese nach dem Kontext benennen und den Wert dort direkt abgreifen. Pro Eingang kann man nun ein eigenes Polling definieren.
Je nach dem was ich messen möchte, könnte sich das als nützlich erweisen. Z.B. würde ich aus Faulheit einen Eingang den Bewegungsmelder (TTL) dranhängen. Hier sollte jede Sekunde gemessen werden, an einen anderen Eingang den Lichtsensor mit analogen Ausgang, wo ich nur aller 5 Minuten den Wert abfragen möchte.

Technisch läuft das derzeit so:

Das Sensor-Modul, ADS1115
   Verwaltete die Verbindung, Lesen und Schreiben zum I2C-Bus.
   Synchronisiert die Anfragen von Eingängen (semaphoren, queue)

Das Eingangs-Modul, ADS1115_AI
   Hält die Konfiguration, die Schwellen (in Volt),  den Verweis auf das Sensor-Modul
   hat ein Reading auch in Volt (Umrechnung mittels Gain)
   jeder Eingang sendet per Polling oder manuell eine Anfrage an das Sensor – Modul

Probleme sehe ich derzeit, wenn der Sensor so programmiert wird, dass der Alert/Rdy-Pin ausgewertet werden soll. Meine Idee passt nicht zu jedem Modus. Z.B. bei eingeschalteten Comparator-Latch bleibt das Signal erhalten bis man das conversion-Register ausliest. Das dürfte man in dem Fall nicht sofort machen, sondern müsste jemand von außen veranlassen. Bis dahin würde der Sensor stehen ?
Auch funktioniert alles im Single-Shot-Modus.  Der Continuous-Mode ist schnell, aber funktioniert nur, wenn man die Konfiguration nicht ändert. (was bei wechselnden Eingängen der Fall wäre). Das zu prüfen, ob die letzte Konfiguration noch der aktuellen entspricht. Das würde vermutlich genauso viel Zeit verbrennen wie man mit dem Continuous-Mode gut macht. Also es gibt noch offen Fragen.

Die kommende Version wird sicher noch wacklig laufen und für einigen Gesprächsstoff sorgen.

LG Karsten

[schlawiano]

So ein MIST 

Fast fertig und dann Transfer-Fehler

[klausw]

So ein MIST 

Fast fertig und dann Transfer-Fehler

Sag nicht du hast keine Sicherungen gemacht.

[schlawiano]

Hatte mich ein bisschen zu sehr auf Notepad++ und WinSCP aus Bequemlichkeit verlassen und hatte den Umfang auch etwas unterschätzt.. Alles außer dem Pi hat Komplettsicherung... naja... so ungefähr weiß ich noch was ich programmiert habe und das Testscript gibt es auch noch.... 3-4 Feierabende werde ich nun noch mal investieren müssen... trotzdem ärgerlich...

[schlawiano]

So nun ein erster Prototyp... ich weiß es gibt noch viel  zu tun... also 100% stabil läuft er noch nicht, Doku wurde auch nicht hinterlegt.

Generell gibt es 2 Module

I2C_ADS1115 ist die Steuerung des Sensors

Hier landen vom Eingang oder Eingängen die Befehle, diese werden der Reihe nach ausgeführt (Qeue)
Nur er schreibt und liest vom I2C-Bus

Daher muss er auch wie ein anderes I2C-Gerät definiert werden

Code Auswählen Erweitern

define myADS1115 I2C_ADS1115 0x48 # I2C-Adresse des ADS1115
attr myADS1115 IODev raspBerryBus # z.B. vom TYP RPII2C
attr myADS1115 verbose 5


I2C_ADS1115_AI ist der Eingang bzw. Eingangsdifferenz


Per Define legt man des zugehörige Sensor - Modul fest.

z.B.

Code Auswählen Erweitern

define myADS1115_AI I2C_ADS1115_AI myADS1115
attr myADS1115_AI Threshold_Low_Voltage 3
attr myADS1115_AI interval 5 # in Minuten


Hier kann alles mögliche Sensor-typische konfiguriert werden.

AUTO_READ sollte man nur abschalten, wenn man selber den Sensor z.B. nach
über den Rdy/Alert Pin steuern möchte. In diesem Fall bleibt der Sensor nach der Konfiguration
in dem Zustand. Der Nutzer muss dann per Update des Eingangs oder per ReleaseLastOrder
im Sensor-Modul dafür sorgen, dass es weiter gehen kann.

OPERATION_MODE= Continuously funktioniert nur mit einem Eingang. Der Nutzer muss selbst einmalig vom
Eingang einen Configure-Befehl (Set) senden und danach werden via Polling oder Update-Befehl (Set
die Werte vom Eingang gelesen.

OPERATION_MODE= SingleShot, hier wird alles automatisch gemacht. Beliebig viele Eingänge können geschalten
werden.

Vll. hat ja jemand Lust zum Spielen.

Bei Problemen bitte mal verbose auf 5 setzen und das Log zuschicken.
Sollte ich was falsch verstanden oder umgesetzt haben, wäre natürlich auch eine Rückmeldung Klasse.