[mit Happy End] Kromschröder BK G4 von 1993 auslesen

Begonnen von andies, 06 Mai 2017, 18:01:47

Vorheriges Thema - Nächstes Thema

andies

Ich bin fast am aufgeben. Ich habe einen Kromschröder BK G4 Gaszähler, der keinen Einschub für ein Reedrelais enthält. Auf der 6 ist ein kleines Silberplättchen abgedruckt. Ich will das Ding optisch auslesen und habe mir bereits eine grandiose Konstruktion gebastelt, siehe Foto unten. Dazu kam eine IR-Diode zum Einsatz (Kodenshi Corp, SG128IR von conrad), die an GPIO 0 eines Raspberry Zero angeschlossen wird und dann das Reflexionssignal abgreifen soll. So weit, so gut. Nun fangen die Probleme an.

Die Transmitter-Diode wird mit 5V gespeist und sendet schön. Die Empfangsdiode meldet sich auch, allerdings ist die Voltzahl problematisch: Der Signalpegel schwankt zwischen 2 V ("LOW", das ich nicht lache) und 2.5V ("HIGH", ok, das ist high). Am RPi steht natürlich ständig "1111111". Ich weiß nicht, wie ich das "Signal" so verändern kann, dass es im RPi verständlich wird.

Zudem habe ich bis jetzt noch nicht prüfen können, ob das Silberplättchen überhaupt ein Signal verursacht oder gar nicht messbar ist.

Hat hier jemand eine Idee, wie ich weitermachen kann? Die Gasag hat bisher auf den Wunsch, das Gerät zu tauschen, nicht reagiert (ich bleibe aber dran).
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

andies

#1
PS Die Schaltung.
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Pfriemler

Sowas sieht in der Theorie immer schön aus, macht aber praktisch Probleme. Schon die Wahl des Vorwiderstands für den Fototransistor ist kritisch, aber bei 2-2.5V in Ruhe biste eigentlich schon optimal. Aber: je nachdem wie gut das Plättchen reflektiert werden die Schwankungen im Zehntelvoltbereich liegen.
Hier wäre es sinnvoll, auf einen A/D zu setzen, der das Signal richtig misst, und einen Algorithmus, der aus den Schwankungen den "Nullpunkt" und die Reflexionen selbst ermittelt. Für einen Arduino ein Klacks, eigentlich müsste das sogar mit einem ESP8266 gehen. 
Praktisch wäre ein sog. Ferrariszählersensor (für Stromzähler mit Drehscheibe) auch das Richtige für Dich.
Jm2c.

Gesendet von meinem SM-G900FD mit Tapatalk

"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

andies

Udo hat so was ja auch im Angebot... Aber muss ich da ebenfalls im 1/10V-Bereich messen? Also einen Arduino o.Ä. vorschalten?
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

andies

OK, ich lese schon: MCP3008 usw. Also wieder basteln  ;D
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

andies

Ich habe mal mit einem digitalen Multimeter gemessen. Die gute Nachricht: Es geht. Die schlechte: Die Spannung fällt von 3,20V auf 3,16V, allerdings wirklich nur dann, wenn die silberne Sechs durchläuft.

Wenn man das Messgerät allerdings um etwa 2mm verschiebt (oder dranstößt, was wahrscheinlicher sein dürfte), ist der Spannungsabfall nur noch auf 3,18V. Also das ist wirklich minimal. Mal schauen, ob ich das hinbekomme. Wenn ja, melde ich mich mal wieder.

PS Drehscheibe habe ich nicht.
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Klaus0815

Ich habe auch ewig mit Reedkontakten, Hallsensor,  IR-LED usw herumprobiert, alles nicht sehr zufriedenzustellend....
(Mein Zähler hatte allerdings eine Aussparung für den Reedkontakt)

Letztendlich läuft es jetzt seit 2 Jahren mit einem Magnetfeldsensor (+Arduino) zuverlässig

Versuch doch mal mit Handy und entsprechender App, ob sich das Magnetfeld bei einem Durchlauf ändert?
Das Handy zeigt dir das Magnetfeld als X, Y und Z-Vektor an, wenn sich einer ausreichend ändert hast gewonnen




Pfriemler

Zitat von: andies am 06 Mai 2017, 20:05:50
Die Spannung fällt von 3,20V auf 3,16V, allerdings wirklich nur dann, wenn die silberne Sechs durchläuft.
Das ist arg wenig.

ZitatPS Drehscheibe habe ich nicht.
Natürlich nicht. Aber die Sensoren für Stromzähler sind auf minimale Reflexionsunterschiede optimiert.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

andies

Ich habe vorhin mal das Handy rangehalten und nix gesehen. Allerdings kam es auf die genaue Haltung an - wo sind denn da die Sensoren (iPhone 6) und Messe ich die silberne 6 oder die internen Scheiben?


Gesendet von iPad mit Tapatalk Pro
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Klaus0815

ich habe kein Iphone :-)

Normalerweise ist der Magnet hinter der silbernen Reflektionsstelle
Die Position des Handys ist unkritisch, falls ein Magnet verbaut ist siehst Du die Änderung sofort


andies

#10
Ein (etwas frustriertes) update zu meinem Kromschröder. Also die nbb Netzgesellschaft will 153 Euro für die Installation eines lesefähigen Gaszählers haben; die gute Nachricht ist: da ist die MWSt schon drin. Das lehne ich schon mal aus Prinzip ab.

Also habe ich weiter gebastelt. Es war ja so, dass ich mit meinem digitalen Multimeter sehr deutliche Spannungsschwankungen gesehen habe, auch wenn die wirklich gering waren. Dann habe ich mir einfach einen AC-Wandler besorgt, MCP3201. Da legt man diese Eingangsspannung dran und daneben eine Referenzspannung (die vom RPi) und das Gerät gibt einem den Quotienten aus beiden zurück. Versorgungsspannung ist 5V, weil dann das Gerät wohl stabiler liefert.

Nun steht der Gaszähler gerade, also habe ich mal etwa eine Minute aufgezeichnet. Das Bild ist im Anhang (jeder Datenpunkt eine Aufzeichnung, siehe Code unten). Damit kann ich doch nichts anfangen?! Angeblich schwankt die Eingangsspannung, die beim digitalen Voltmeter immer über 3V lag, beständig und zufällig zwischen null und 3,3V. Irgendwas stimmt da nicht. Der Chip wird nicht hinüber sein, oder?   

#!/usr/bin/env python3
import sys
import gpiozero
import time
while True:
  f = open('/home/pi/gas.log', "a")
  with gpiozero.MCP3201() as Nummer:
    f.write(str(Nummer.value) + '\n')
  f.close()
  time.sleep(0.1)


PS Insbesondere appelliere ich an Pfriemler: "geht nich gips nich" ;-)
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

andies

#11
Getreu dem Motto von Pfriemler machen wir also weiter  8)
Ich habe im Netz ein Stück Python-Code gefunden, der völlig andere und auch konsistente Ergebnisse liefert, mithin ist gpiozero fehlerhaft (das ist natürlich ärgerlich, wenn man das erst so merkt). Wenn ich dieses Programm (von mir minimal verändert) laufen lasse
import RPi.GPIO as GPIO
from time import sleep

# name pins
clock = 11
miso = 9
cs = 8

# set up pins
GPIO.setmode(GPIO.BCM)
GPIO.setup(clock, GPIO.OUT)
GPIO.setup(miso,GPIO.IN)
GPIO.setup(cs,GPIO.OUT)

# bring clock and cs high
GPIO.output(clock,True)
GPIO.output(cs,True)

# begin loop to print a stream of data
try:

  while True:
    # bring cs low
    GPIO.output(cs,False)

    # create a string to store the bits
    data = str()

    # begin loop to take in data
    for i in range(16):

        # bring clock low
        GPIO.output(clock, False)

        # read miso pin
        if GPIO.input(miso):
            data += "1"
        else:
            data += "0"

        # bring clock high
        GPIO.output(clock, True)

    # remove the first 4 bits from the data
    data = data.replace(' ','')[4:15]

    # convert the data from binary to decimal
    data = str(int(data,2)*(3.3/2045))
   
    # print data, mit nur zwei Nachkommastellen
    print (data[0:4])

    # bring cs high
    GPIO.output(cs, True)

    #short sleep
    sleep(.1)
   
except: #aufräumen
    GPIO.cleanup()
    print ("\nGPIO cleanup finished")
 
dann kriege ich stabile 3.17V bis 3.3V als Rückmeldung. Also setze ich da mal fort.
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Pfriemler

Ich hab's wohl gelesen, aber diesbezüglich ratlos. Bin mehr der Analogelektroniker. Aber mach weiter so!
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

andies

#13
OK, mit dem neuen Code kann ich sinnvollere Werte produzieren. Die habe ich normiert, so dass sie zwischen 0 und 2050 liegen. Aber das System ist zu instabil. Zuerst hatte ich bei drei Umläufen des Zählers die Daten im 0.1-Sekundentakt eingelesen und gespeichert. Wenn das ein ideales System wäre, hätte ich insgesamt an ca 9% der Werte einen niedrige Zahl (immer dann, wenn die silberne 6 da ist) und in 91% der Werte (alle anderen zehn Ziffern) eine hohe Zahl. Das sah aber nicht so aus, die Werte schwanken zwischen 1900 und 2050 und vor allem nicht im Verhältnis 1:10.

Also habe ich gewartet, bis der Zähler an der 1 feststand - und da ist nichts silbernes etc dran. Also habe ich ca drei Minuten aufgezeichnet, alles mit Stillstand. Bei einem idealen System wäre immer dieselbe Zahl erschienen. Hier nicht. Zudem schwanken die Werte bei Stillstand genau so stark wie beim Durchgang der silbernen 6! Das sieht man im Häufigkeitsdiagramm unten. Also leider ist es so, dass ich auf diese Weise nichts erfassen kann - die Störung bei Stillstand ist größer als der Effekt beim Durchgang des silbernen Plättchens. Mist.

Ich vermute, dass das an einer nicht konstanten Referenz-Spannung am MCP liegt. Die Zahl, die ich kriege, wird ja errechnet aus dem Quotienten aus Pegelspannung an der Diode dividiert durch Referenzspannung (mal 2048 und davon der ganze Teil).  Wenn nun die Referenzspannung zu stark schwankt, was sie vermutlich tut, ist der Quotient Mist.

Ich werde mal versuchen, aus den 5V mit einem Spannungsteiler eine Referenzspannung zu konstruieren. Vielleicht geht das besser. Mit dem digitalen Messgerät konnte ich ja zwar gering, aber deutlich einen Spannungseinbruch an der silbernen 6 sehen.
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

andies

PS Hier noch einmal das Häufigkeitsdiagramm bei insgesamt drei Umläufen. Da ist also dreimal eine silberne 6 drin. Nur wo versteckt sie sich ;-)
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

andies

#15
Auch an der sleep-Dauer liegt es nicht (war noch so eine Vermutung von mir): Ich habe 0.1 und 0.25 getestet, wobei in beiden Aufnahmeperioden der Gaszähler exakt an der gleichen Stelle still stand. Die kürzere Sleep-Dauer wurde 30 Sekunden aufgezeichnet, die längere eine Minute. Noch kürzere sleep-Dauern gehen nicht, weil dann vermutlich der CP heißläuft, noch längere gehen wohl nicht, weil man dann die sechs verpassen könnte. Es gibt keinen Unterschied zwischen beiden sleep-Zeiten, wie der Vergleich der Häufigkeitsdiagramme zeigt. In beiden Fällen gibt es gleich viel Rauschen (ca 5% des Basiswertes).
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

andies

#16
Die Idee mit den 5V ist doch Quatsch. Wenn ich die 3,3V oberhalb des 15k-Widerstandes vor der Diode entnehme, messe ich doch unabhängig von der Spannungshöhe die Veränderung des Widerstandes der Lichtdiode im Verhältnis zu 15k. Genau das ist es, was ich brauche. Also muss ich nochmal nachdenken, wo da der Haken ist.


Gesendet von iPhone mit Tapatalk Pro
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Pfriemler

Puh. Das ist eine Herausforderung.
Aber so nett das mit der Häufigkeitsverteilung auch ist: Hast Du mal ein Quotientendiagramm über die Zeit bei Stillstand und Durchlauf?
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

andies

Nein - was genau ist das? Also welcher Quotient?

Danke!


Gesendet von iPhone mit Tapatalk Pro
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Pfriemler

ZitatDie Zahl, die ich kriege, wird ja errechnet aus dem Quotienten aus Pegelspannung an der Diode dividiert durch Referenzspannung (mal 2048 und davon der ganze Teil).

Sprich: Den Verlauf der Pegelspannung  über die Zeit. X als eine Zeit, Y als der Quotient (von 1900-2050, wenn ich das richtig sehe).
Hintergrund: Mich würde interessieren, ob die Reflexionsmarke vielleicht nur extrem kurz auftaucht und deswegen in der Häufigkeitsverteilung keine Rolle spielt.

Auffällig bleibt ja doch eine gewisse Häufung von Werten, die von einem Rauschen flankiert wird. Aber wie es zeitlich rauscht, wenn die Markierung vorbeischippert, wäre doch vielleicht auch auswertungswürdig.

Sicher ist das aber alles so oder so nicht, mehr eine Studie  ;)
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

andies

Witzig, das habe ich gerade gemacht. Dabei habe ich aber nicht die einzelnen Werte geplottet, sondern gleitende Mittelwerte gebildet - ich habe nämlich gesehen, dass alle sieben bis zehn Einträge ein Einbruch bei den Daten vorliegt, den ich nicht erklären kann. Also habe ich jeweils immer zehn beieinander liegende Werte addiert und diese Summe ausgedruckt (ich wollte die Division durch zehn vermeiden). Das Bild unten zeigt den Zeitablauf von etwa einer Minute, in der es exakt zehn Durchgänge der silbernen Sechs gab. Die Räder haben sich die ganze Zeit gedreht.

Ich kann durchaus Veränderungen erkennen, aber exakt zehn Durchgänge kann ich so schlecht identifizieren. Ich vermute mal, ich brauche bessere IR-Dioden.
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

andies

FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Pfriemler

Glättung ist gut, aber ich würde wirklich gleitenden Mittlerwert berechnen. Es zeigen sich eigentlich deutlich neun Peaks und 3 recht undefinierte. Ich würde es mal mit Steilheit der Änderung (1. Ableitung) nach Mittelung versuchen (hier mit der Weite mal experimentieren) und darauf triggern. Das Problem: höherer Gasverbrauch wird durch höhere Steilheit der Änderung besser erkannt, geringer Verbrauch wird wieder im Rauschen untergehen.
Bliebe der Vergleich Extremwerte gegen Mittelwert. Dann zähle ich elf Durchgänge.

Ich würde jetzt über die 135-Euro-Investition nachdenken  8)
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

andies

Zitat von: Pfriemler am 15 Mai 2017, 22:58:50
Ich würde jetzt über die 135-Euro-Investition nachdenken  8)
153!!

(Und 30 Cent.)
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Wuppi68

ein Pi ist schon da ...

ich würde über eine Kamera und OCR nachdenken

Kannst Du mal versuchen die Referenzspannung via Batterie zur Verfügung zu stellen? Die sollte zum testen konstant bleiben.

Deck doch mal die Scheibe vom Zähler ab, dass kein Fremdlicht mehr die Messung verfälschen kann, vielleicht wird der Signalabstand dann etwas größer oder präziser
Jetzt auf nem I3 und primär Homematic - kein Support für cfg Editierer

Support heißt nicht wenn die Frau zu Ihrem Mann sagt: Geh mal bitte zum Frauenarzt, ich habe Bauchschmerzen

andies

#25
Vielen Dank für Euren Mut!

Ich habe ein wenig weiter gemacht; es gibt noch ein Detail, das ich nicht verstehe (SPI geht nicht, aber GPIO schon?), aber das soll mal nicht aufhalten. Ich habe jetzt die Werte bei der Erfassung iteriert. Also kein gleitender Durchschnitt, sondern es werden statt einem jetzt 75 Werte eingelesen und gemittelt. Das dauert pro Wert 0.032 Sekunden und ist damit in meinen Augen völlig akzeptabel (mit SPI müsste es noch schneller gehen, siehe oben).

Macht man das und zeichnet alle 0.1 Sekunden auf, ergibt sich ein anderes Bild. Unten sieht man eine Aufzeichnung über ein paar Sekunden, in denen es exakt drei Durchgänge der Sechs gab. Da ist was draus zu machen. Zwar ist da immer noch dieser kleine vierte Abfall, und das wäre immerhin eine Fehlerquote von 33%, aber wir kommen der Sache schon näher.   

Als nächstes werde ich den Widerstand ändern. 15kOhm sind zu wenig. Wenn an der Empfangs-Diode zwischen 3.26 und 3,17 anfallen, kann ich da ruhig auf 150kOhm gehen.

(Btw: Ich glaube, in diesem Forum sind nur Leute unterwegs, die eher 900 Euro für ein Oszilloskop ausgeben als 153,30 für den impulsgebenden Zähler.)

Zur Info noch der python-Code
#!/usr/bin/env python3
## siehe https://www.raspberrypi.org/forums/viewtopic.php?t=48810&p=433174
import sys
import RPi.GPIO as GPIO
import time

# name pins
clock = 11
miso = 9
cs = 8
start_time = time.time()
NrAverage = 75
#   50 values =>  0.021 sec
#  100 values =>  0.041 sec
#  200 values =>  0.077 sec
#  300 values =>  0.12 sec

# function to actually read values, using averages
def getSPI():
    #values for evaluating averages
    average=0
    s=0
       
    while s<NrAverage:
        # bring cs low
        GPIO.output(cs,False)
       
        # create a string to store the bits
        data = str()
        # begin loop to take in data
        for i in range(16):
            # bring clock low
            GPIO.output(clock, False)
            # read miso pin
            if GPIO.input(miso):
                data += "1"
            else:
                data += "0"
            # bring clock high
            GPIO.output(clock, True)
       
        # remove the first 4 bits from the data
        data = data.replace(' ','')[4:15]
       
        # convert the data from binary to decimal and print them
        ## average  ausrechnen   
        average += int(data,2)
         
        # bring cs high
        GPIO.output(cs, True)
        s += 1     
    return (average/s)   

# set up pins
GPIO.setmode(GPIO.BCM)
GPIO.setup(clock, GPIO.OUT)
GPIO.setup(miso,GPIO.IN)
GPIO.setup(cs,GPIO.OUT)

#Datei vorbereiten
f = open('/home/pi/gas.log', "w")
f.write('#0.1 sleep mit average 75\n')
f.close()

# bring clock and cs high
GPIO.output(clock,True)
GPIO.output(cs,True)

# main loop to print a stream of data
try:
    while True:
        ## in Datei speichern
        f = open('/home/pi/gas.log', "a")
        f.write(str(getSPI()) + '\n')
        f.close()
        ## in Anzeige ausgeben
        #sys.stdout.write(str(getSPI()) + '\n')
        #sys.stdout.flush()
        time.sleep(0.1)

except:
    GPIO.cleanup()
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Pfriemler

Na, das sieht doch schon eher nach was aus.
Waren wir nicht schon mal bei 2-2,5V? 3,und sind natürlich wirklich zu viel, bei 3,3V Grundspannung.

Und zu
Zitat(Btw: Ich glaube, in diesem Forum sind nur Leute unterwegs, die eher 900 Euro für ein Oszilloskop ausgeben als 153,30 für den impulsgebenden Zähler.)

Man muss ganz klar Prioritäten setzen.
Meint einer, dessen Oszi nur 350 Euro gekostet hat, was aber auch schon ein paar Tage her ist...
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

andies

Noch ein wenig gespielt (das SPI-Problem habe ich übrigens durch einen Neustart gelöst). Ich war mir nicht sicher, ob ich besser 25 oder 50 oder gar 75 Werte zusammenfasse und daraus den Durchschnitt bilde. Also habe ich mal jeweils 100 mal Datenpunkte gemittelt und dann gespeichert sowie das dazugehörige Bild gezeichnet. Das ist nicht ganz passend, weil bei weniger Durchschnittszahlen ja ein kürzerer Zeitraum beobachtet wird (25 Mittelungen gehen viel schneller von statten als 100) und die Linien nicht ganz vergleichbar sind. Dennoch hatte ich erwartet, dass bei 75 wenig Schwankungen, bei 50 etwas Schwankungen und bei 25 viel Schwankungen auftauchen und ohne Mittelung sehr starke Schwankungen zu sehen sind.

So sieht das Bild aber nur teilweise aus. Ich entnehme daraus: 1) Durchschnitt ist sinnvoll  (das sieht man an der nicht durchschnittsgemittelten, grauen Linie). 2) Aber ab einer bestimmten Anzahl von Durchschnitten (sagen wir 25) wird, wenn man die Zahl erhöht, nicht mehr Genauigkeit produziert. Das widerspricht eigentlich dem Gesetz der Großen Zahlen oder aber hier gibt es anscheinend externe Einflüsse, die ich nicht unter Kontrolle habe (derzeit liegt ein Lappen über der ganzen Anlage, damit Außenlicht nicht stört). Aber die wichtigsten störenden Effekte werden beseitigt, wenn man etwas Durchschnittsbildung betreibt, danach kostet das nur noch Rechenkapazität.

150kOhm kommt am Wochenende.
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

andies

#28
So, gestern abend habe ich aus dem 15kOhm-Widerstand insgesamt 215kOhm gemacht. Da ist dann schon mehr zu sehen. Jedenfalls habe ich das Gerät 40 Minuten aufzeichnen lassen (alle 0.7 Sekunden ein Wert). Gegen Ende der Aufzeichnungsphase gab es genau einen Durchlauf der silbernen Sechs. Man sieht unten das Gesamtbild mit fast 33.000 Einträgen. Die Sechs ist ganz deutlich zu erkennen.

Anhand dieser vielen Daten habe ich nebenbei folgendes herausbekommen. Der AD-Wandler hat bei mir eine Fehlerquote von 5%. Und dabei muss man den genau "einpegeln": Läuft er zu schnell getaktet, steigt die Quote bis 10% und mehr! Das finde ich nicht berauschend, zumal andere Webseiten eine Quote von 0,5% angeben. Die Fehlerquote ist durch den dicken Balken gut sichtbar.

Um nun trotz hoher Fehlerquote auszulesen, mache ich das so, dass erst bei einem sehr niedrigen Wert eine Erhöhung des internen Gaszählers vorgenommen wird; gleichzeitig wird der interne Zähler "gesperrt".  Erst dann, wenn danach ein sehr hoher Wert kommt, wird der Zähler entsperrt ("https://de.wikipedia.org/wiki/Schmitt-Trigger"). Ich teste nun mal langfristig, ob man damit den Zählerstand besser erfassen kann.

#!/usr/bin/env python3
##https://www.raspberrypi.org/forums/viewtopic.php?t=48810&p=1163539
import time
import sys
import spidev

spi = spidev.SpiDev()
spi.open(0, 0)
spi.max_speed_hz = 50000
numdata = 100
WasHigh = True

def GetADC():
    Msum = 0
    s = 0
    while s < numdata:
        adc = spi.xfer2([0, 0])
        hi = (adc[0] & 0x1F);
        low = (adc[1] & 0xFE);  # FE for B, FC for C chip (MCP3201-B/C) Danil
        data = (hi << 8) | low;
        Msum += int(data)/numdata
        s += 1
    return (Msum/4)

def gaszaehler():
   try:
      f = open('/home/pi/gas.txt', "r") ## Wert auslesen
      s = f.readline()
      i = int(s.strip())
      f.close()
      f = open('/home/pi/gas.txt', "w") ## Wert hochzaehlen und in die Datei schreiben
      f.write(str(i+1))
      f.close()
   except IOError as err: ## braucht man das alles?!
      print("I/O error: {0}".format(err))
   except ValueError:
      print("Kann Zaehlerstand nicht in Ganzzahl umwandeln")
   except:
      print("Unbekannter Fehler:", sys.exc_info()[0])
      raise
   return
   
while True:
   time.sleep(0.07)
   No = GetADC()
   if (No < 1700) and WasHigh:
      WasHigh = False
      gaszaehler()
      time.sleep(1) # Hysterese: nach einer 6 kann 1 sec keine weitere 6 kommen
   elif (No > 1800) and not (WasHigh):
      WasHigh = True
      time.sleep(0.2) # Hysterese: wenn zurueck auf 7, kann 0.2 sec nichts passieren

spi.close()


Eventuell hätte ich diesen Unsinn mit dem AD-Wandler gar nicht gebraucht, man hätte das mit einem Potentiometer alles machen können? Bei einem so deutlichem Abfall der Spannung wäre das eventuell auch mit GPIO gegangen.
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

rippi46

Hallo andies,

ich hatte ähnliches Problem und habe das mit einer Reflexionslichtschranke gelöst.

Schau die mal folgende Beitrage an. Vielleicht ist da was Passendes dabei.

https://forum.fhem.de/index.php/topic,60658.msg520469.html#msg520469

und dort den Beitrag 10.


Gruß rippi
FHEM, LMS, VDR ,Dell 9010 Ubuntu 20.04,Raspimatic, HM/HMIP, Max, Elro, Brennenstuhl u. Intertechno mit Connair.
Picoreplayer, Raspi IR-Lanadapter, Firmata(wifi), LaCrosse,
nanocul433, nanocul868, Signalduino, Connexoon,
MySensor-GW+Sensoren, RGBWW, Zigbee2mqtt,Xiaomi,Nextion,LEDMatrix,Alexa

andies

#30
Hast du dir ein Datenblatt der Lichtschranke vorher angeschaut? Ich habe ja auch eine dran, Infrarot, von Conrad, https://www.pacer.co.uk/Assets/User/1067-SG128IR.pdf Angeblich hat die einen "besten" Abstand von 8mm, deshalb habe ich da ein paar Cent mehr ausgegeben.


Gesendet von iPhone mit Tapatalk Pro
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

andies

Also der Test über Nacht war nicht so erfolgreich. Gravierende Abweichungen. Also habe ich mir einen Sechs-Durchgang noch einmal genauer angeschaut. Der sieht so aus wie im Anhang. Daraufhin habe ich den Code erneut geändert,
while True:
   time.sleep(0.07)
   No = GetADC()
   if (No < 1740) and WasHigh:
      WasHigh = False
      gaszaehler()
      time.sleep(0.5) # Hysterese: nach einer 6 kann mindestens 0.5+0.07 sec keine weitere 6 kommen
   elif (No > 1800) and not (WasHigh):
      WasHigh = True
      time.sleep(0.5) # Hysterese: wenn zurueck auf 7, kann 0.5+0.07 sec nichts passieren

Mal sehen, wie das läuft.

PS Vielleicht sind die anderen Dioden in der Reichweite eventuell geringer, dafür aber fehlertoleranter?
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

andies

#32
Es läuft nicht und inzwischen weiß ich auch, warum. Es ist die Glasscheibe vor dem Gaszähler.

Ich habe bei der IR-Diode getestet, ob sie messen kann, wenn Gegenstände in der Nähe sind. Das ist deutlich erkennbar. Je weiter weg der Gegenstand von der Diode, desto kleiner die Zahl, die mir in python angezeigt wird (=die Spannung, die an der Diode anfällt). Das variiert wirklich sehr stark, ohne Reflexion sind das 600 bis 800. Legt man einen Gegenstand unmittelbar davor, steigt die Zahl auf 1800 und mehr.

Führe ich nun die Diode an den Gaszähler, so muss ich sie sehr nah dranbringen (siehe gleich unten). Sofort messe ich ca 1800-1900 und damit bin ich schon bei der höchsten Spannung, die ich bisher beobachtet habe. Das wird durch die Glasplatte ausgelöst. Ein zusätzliches Metallplättchen an der 6 bringt dann nichts mehr an höherer Reflexion und demzufolge auch keine Veränderung der Spannung. Das Gerät erfasst einfach nicht, wenn die 6 durchläuft. Ich habe das zweimal unmittelbar am Gaszähler beobachtet.

Ich dachte, ich bin besonders schlau und habe dann die Diode wenige cm entfernt angebracht. Dann würde sie nicht von der Glasscheibe reflektieren, sondern nur der silbernen 6. Aber auch das klappt nicht, wie ein Test zeigt. Das silberne Plättchen wird einfach durch die Glasscheibe hindurch nicht deutlich genug erkannt. Die Glasplatte "überstrahlt" die silberne 6. So geht es leider nicht. Ich muss mir was neues überlegen. Vermutlich brauche ich eine andere Diode oder ein anderes Messinstrument.
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

andies

PS Ich habe jetzt mal im Raum das Licht ausgemacht und weiter gemessen. Da ging die Ausgabe von 1890 auf 1200 runter (!). Solche Einbrüche hatte ich mir die ganze Zeit gewünscht.

OK. Ich messe wirklich eine Menge, aber eben nicht die silberne 6, sondern alles mögliche. Und wenn ich früher in den Keller bin und den drehenden Zähler beobachtet habe, lagen die Messergebnisse daran, dass ich beim Rausgehen das Licht ausgemacht habe  ::)

Ich brauche einen anderen Sensor. Oder ein Oszilloskop  8) 
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Klaus0815

Du steckst ja richtig viel Zeit rein, willst Du es nicht vielleicht doch noch mal mit einem Magnetfeldsensor ( Handy) versuchen?

Falls ja, such mal nach einer App und teste es z.B. mit einem Schraubendreher den Du ans Handy hältst


andies

Das hatte ich ja schon - ohne Ergebnis. Ich habe das Handy gedreht, was das Zeug hält und bekam kein Ergebnis.


Gesendet von iPad mit Tapatalk Pro
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

andies

Conrad hat mir eine neue Lichtschranke geschickt, die angeblich auch einen Tageslichtfilter hat (IR-Version, https://www.conrad.de/de/reflexions-lichtschranke-sg128ir-kodenshi-auk-1-st-399631.html). Wenn die Lichtschranke aber auf etwas reagiert, dann ist das Tageslicht und das sofort. Die Diode ist einfach unbrauchbar und mich wundert, dass das immer noch im Angebot ist. Jedenfalls habe ich das reklamiert und warte derzeit auf die Lichtschranken aus China, die sollen auch IR sein. Mal sehen, wie das geht.
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

fiedel

Ich hab sehr gute Erfahrungen mit Industrie- Lichtleitersensoren gemacht. Sollte für deinen Fall auch gut gehen. Ist vielleicht mal ein anderer Ansatz...

Gruß
Frank
FeatureLevel: 6.1 auf Wyse N03D ; Deb. 11 ; Perl: v5.14.2 ; IO: HM-MOD-RPI-PCB + VCCU|CUL 868 V 1.66|LinkUSBi |TEK603
HM: SEC-SCO|SCI-3-FM|LC-SW4-PCB|ES-PMSW1-PL|RC-4-2|SEN-MDIR-O|SEC-WDS-2
CUL: HMS100TF|FS20 S4A-2 ; OWDevice: DS18S20|DS2401|DS2406|DS2423

andies

Zitat von: fiedel am 31 Mai 2017, 06:57:47
Ich hab sehr gute Erfahrungen mit Industrie- Lichtleitersensoren

Danke! Bisher habe ich bei Conrad immer nur LEDs gesehen, die höchstens 1000h oder so drauf hatten. Da wäre dann in absehbarer Zeit Schluss gewesen. Wie lange läuft das schon störungsfrei bei Dir?


Gesendet von iPhone mit Tapatalk Pro
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

fiedel

Zitat von: andies am 31 Mai 2017, 07:39:32
Wie lange läuft das schon störungsfrei bei Dir?

Das läuft schon seit 2012 und dieser Sensor ist von der Sorte "Einbauen, einstellen, vergessen..."  ;)
FeatureLevel: 6.1 auf Wyse N03D ; Deb. 11 ; Perl: v5.14.2 ; IO: HM-MOD-RPI-PCB + VCCU|CUL 868 V 1.66|LinkUSBi |TEK603
HM: SEC-SCO|SCI-3-FM|LC-SW4-PCB|ES-PMSW1-PL|RC-4-2|SEN-MDIR-O|SEC-WDS-2
CUL: HMS100TF|FS20 S4A-2 ; OWDevice: DS18S20|DS2401|DS2406|DS2423

andies

Wow! Kannst du mal (in diesem oder Deinem ursprünglichen) Thread beschreiben, wie das genau angeschlossen wird? Ich sehe da ein 1-wire und anscheinend mehrere Mikroprozessoren, aber was braucht man wirklich? Und welchen der vielen keyence würdest du empfehlen?


Gesendet von iPhone mit Tapatalk Pro
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

fiedel

Das geht fast mit allen von diesen schmalen Auswerteeinheiten in Verbindung mit einem Reflex- Lichtleiter (Sender und Empfänger gemeinsam in einer "Spitze"). Ich hab diesen Sensor und diesen Lichtleiter.

Die "Prozessoren" sind nichts weiter als Optokoppler (ich hab CNY17). Damit bringe ich den Ausgang des Sensors "Spannung/keine Spannung" auf ein S0- Signal "Kurzschluss/ kein Kurzschluss". Das versteht der 1-Wire- Zähler dann als Impuls. Vorteil: Wenn du später einen S0- Strom- oder Gaszähler bekommst, kannst du den direkt (ohne den Sensor und ohne Optokoppler) dort anschließen. Es sind 2 Koppler auf der Platine, weil ich auch noch Gas zähle. Zum Glück kann ich dort einen Hall- Sensor (auch aus der Industrie) verwenden und muss deshalb auch hier das Signal umwandeln. Der Zähler hat 2 Kanäle.

Die Diode des Kopplers wird einfach mit einem Vorwiderstand (ca. 1,5 - 2,5 kOhm) an den Ausgang des Sensors angeschlossen. Der Transistor kommt direkt, oder mit einem kleinen Widerstand (ca. 50 Ohm) an den Eingang des Zählers. Da es ein Transistor ist und kein Reedkontakt, muss natürlich die Polung stimmen.
FeatureLevel: 6.1 auf Wyse N03D ; Deb. 11 ; Perl: v5.14.2 ; IO: HM-MOD-RPI-PCB + VCCU|CUL 868 V 1.66|LinkUSBi |TEK603
HM: SEC-SCO|SCI-3-FM|LC-SW4-PCB|ES-PMSW1-PL|RC-4-2|SEN-MDIR-O|SEC-WDS-2
CUL: HMS100TF|FS20 S4A-2 ; OWDevice: DS18S20|DS2401|DS2406|DS2423

andies

Ich habe nach langer Zeit wieder mal versucht hier vorwärts zu kommen. Ich habe mir bei reichelt und nicht bei conrad (die übrigens den defekten Optokoppler zurückgenommen haben, dazu gleich mehr) einen anderen Koppler gekauft, CNY70. Und eingebaut.

Und siehe da, es taucht exakt das gleiche Problem auf. Mache ich das Licht an, geht die Spannung runter. Darf eigentlich nicht sein!

Nun kann es aber nicht sein, dass zwei verschiedene Optokoppler von zwei verschiedenen Lieferanten beide den gleichen Fehler haben. Eher muss das Problem bei mir liegen. Also habe ich mal auf die Lampe geschaut, die da im Keller hängt um Licht zu machen: Eine Halogenlampe, die ordentlich Wärme produziert. Entfernung zur Diode: 2m. Anscheinend reicht die Hitze, die da produziert wird, aus, um das Gerät anzusprechen. Und die Hitze scheint stärker zu sein als das, was die interne Diode liefert. Es lag also immer schon an mir und nicht an dem Gerät, das ich bei conrad gekauft hatte. Peinlich.

Also ich benötige als nächste eine Beleuchtung, die keine Hitze produziert und dann messe ich nochmal. Ich hätte nicht gedacht, dass das alles so aufwendig wird.
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

fiedel

Vermutlich wird eher das starke Licht "schuld" sein und weniger die Wärme. LED- Leuchtmittel sind ja immer eine gute Idee und ansonsten solltest du die Meßstelle einfach etwas abschatten (Fotos!?). 
FeatureLevel: 6.1 auf Wyse N03D ; Deb. 11 ; Perl: v5.14.2 ; IO: HM-MOD-RPI-PCB + VCCU|CUL 868 V 1.66|LinkUSBi |TEK603
HM: SEC-SCO|SCI-3-FM|LC-SW4-PCB|ES-PMSW1-PL|RC-4-2|SEN-MDIR-O|SEC-WDS-2
CUL: HMS100TF|FS20 S4A-2 ; OWDevice: DS18S20|DS2401|DS2406|DS2423

andies

#44
Ich dachte immer, die hätten starke IR-Filter!



Gesendet von iPhone mit Tapatalk Pro
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

andies

Habe gerade das hier gefunden: "Der Anteil von IR-Licht am Tageslicht beträgt etwa 40%, der von Glühlampenlicht sogar um die 90%." Das erklärt einiges.


Gesendet von iPhone mit Tapatalk Pro
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

andies

Zitat von: Pfriemler am 06 Mai 2017, 18:19:11
Sowas sieht in der Theorie immer schön aus, macht aber praktisch Probleme.
Ja, das musste ich nun endlich auch akzeptieren. Also wie gesagt, das Tageslicht hat mir ständig falsche Fährten geliefert. Also habe ich das Licht ausgelassen (=keine externen Störfaktoren mehr) und ich habe zwei oder drei Durchgänge mit der zweiten Diode gemessen. Man sieht unten: NICHTS. Also so geht das nicht. Mit dieser Technik wird die silberne Sechs nicht erfasst, die Glasplatte davor streut zu stark.

Eventuell könnte man eine "echte" Laserdiode ansteuern und dann schauen, wann die ordentlich reflektiert wird. Das scheint mir auch die Lösung zu sein, die fiedel vorgeschlagen hatte. Dafür bräuchte ich dann, wenn ich das richtig sehe, erstmal 24V.
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

andies

#47
Ein Vierteljahr später: Ende gut, alles gut. Fiedel hat mir den richtigen Tipp gegeben und geholfen, einen Industriesensor von keyence einzurichten. Der tut nun seit gestern seine Arbeit wie ein Schweizer Uhrwerk, siehe unten. Gasverbrauch ist in FHEM.

Wieder was gelernt: Die Alibaba-Sensoren sind gut, um vorbeilaufende Elefanten zu erfassen. Für kleine Silberscheiben auf der Sechs eines Gaszählers sind sie eher weniger geeignet. Da muss man schon Profigeräte nehmen.
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

andies

#48
PS Hier noch der Code, mit dem ausgelesen wird:


import RPi.GPIO as GPIO

# RPi.GPIO Layout verwenden (wie Pin-Nummern)
GPIO.setmode(GPIO.BCM)
# Pin 17 auf Input setzen, dort ist der keyence angeschlossen
GPIO.setup(17, GPIO.IN)

def Gaszaehler():
   try:
      f = open('/home/pi/gas.txt', "r") # auslesen
      s = f.readline()
      i = int(s.strip())
      f.close()
      f = open('/home/pi/gas.txt', "w") # loeschen und neu schreiben
      f.write(str(i+1))
      f.close()
   except IOError as err:
      print("I/O error: {0}".format(err))
   except ValueError:
      print("Kann Zaehlerstand nicht in Ganzzahl umwandeln")
   except:
      print("Unbekannter Fehler:", sys.exc_info()[0])
      raise
   return

WasHigh = False

try:
    while True:
        #load = 1 verhindern (die pausen unten sind nur unter bestimmten Bedingungen aktiv)
        time.sleep(0.07)

       #jetzt Gas auslesen, zuerst pruefen ob 6 anliegt
        if (WasHigh) and (GPIO.input(17) == GPIO.LOW):
            WasHigh = False
            Gaszaehler() # Zaehlerstand erhoehen
            time.sleep(0.5) # Hysterese: nach einer 6 kann mindestens 0.5+0.07 sec keine weitere 6 kommen
        elif not (WasHigh) and (GPIO.input(17) == GPIO.HIGH):
            WasHigh = True
            time.sleep(0.5) # Hysterese: wenn zurueck auf 7, kann in den naechsten 0.5+0.07 sec keine 6 erscheinen

Der Inhalt von gas.txt wird dann auf einem Webserver ausgegeben:

<?php
$gas 
file_get_contents('/home/pi/gas.txt');
echo 
"gas=".$gas;
?>

und via HTTPMOD abgefragt, da sich am Gaszähler ein separater RPi-Zero mit WLAN-Zugang befindet.
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

klausdor

Hallo,

die Gaspreise erfordern Reaktion !!!

Mein BK G4  (von 2007) hat schon den Magnetimpuls.

Mein kleine (Wunsch-) Lösung wäre diesen mit dem guten alten (vorhandenen)  ESA1000WZ in FHEM  einzubinden.

Hat das schon jemand gemacht oder Tipps zum Vorgehen?

Grüße
Klaus
-------------------------------
Raspi2 mit V6.1; HMLAN; CUL868; ESA1000WZ-LED am Q3BA; FHT80TF-2; HM-CC-RT-DN und andere HM-Komponenten; 3x DECT200; xTrend9200_enigma2; Z-Wave als Versuch mit Einbaukomponenten hinter dem Schalter...

Pfriemler

#50
Zitat von: klausdor am 02 März 2022, 16:49:11
die Gaspreise erfordern Reaktion !!!
Ja, ganz unsmart: Umgekehrt proportional zum Kontostand die Heizkörper herunterdrehen und die Duschintervalle verlängern ... ;)

mangels Wissen drauflosorakelt:
Der ESA1000WZ ist meines Wissens der IR-Sensor für Ferraris. Für Gaszähler mit Magnet gab es den ESA1000GAS, letztlich nicht mehr als ein Reed-Kontakt im Gehäuse. Beide an den Funksender mit Kabel angeclipst. (Möglicherweise Irrung, könnte auch sein dass die fest verbunden waren.) Wenn Du einen Magnetkontakt eh schon hast, sollte mit Kenntnis der Schnittstelle des Funksenders eine direkte Anbindung möglich sein, Zählerkonstante etc ist im Hauptgerät bzw. FHEM einzustellen. Funkanbindung war m.W. CUL 868. Ich hatte mal vor Urzeiten sowas, leider alles verkauft.
Für die Auswertung von Kontakten gibt es darüberhinaus unzählige weitere Möglichkeiten, vom Tür/Fensterkontakt bis zum Tasmota aufm WEMOS.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

klausdor

Hallo Pfriemler,

danke für die Tipps.

Mit meinem Ferraris-Zähler hatte ich das so 2015 für Strom in FHEM. Lief und war dann durch einen digitalen Q3BA irgenwie überflüssig und nicht mehr in Funktion.

Ist aber auch so lange her....

Daher habe ich die Sendeeinheit schon mal.
Muß mich nun mal wieder eingehend mit FHEM befassen.

Daher freue ich mich, wenn jemand diese GAS-Einbindung laufen hätte.

Grüße
Klaus
-------------------------------
Raspi2 mit V6.1; HMLAN; CUL868; ESA1000WZ-LED am Q3BA; FHT80TF-2; HM-CC-RT-DN und andere HM-Komponenten; 3x DECT200; xTrend9200_enigma2; Z-Wave als Versuch mit Einbaukomponenten hinter dem Schalter...