[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

#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 RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
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 RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
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 RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
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 RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
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 RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
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 RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
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 RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
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 RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
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 RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
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