zunächst erst mal ein festes Dankeschön! Soviel Zeit muss sein…
Zum testen…
Ich habe deine vier Möglichkeiten gefunden und dort meine Preferenz ‚Eingänge high, Ausgänge high‘ eingestellt. Und voila, dass Ergebnis ist schon fast perfekt!
Nur ein kurzes Zucken beim reboot des Raspi oder wenn ich den IPS Dienst neu starte stört noch. Man kann es kaum in dem Objektbaum sehen, weil es so schnell geht, aber auch dort kommt kurz ein ‚AUS‘ und dann ein ‚EIN‘. An meinen LEDs (Relais Simulatoren), die an den Pins hängen, sieht man es wesentlich deutlicher. Schätze das Aufblitzen auf ca. 0,5 Sekunden, sicher zumindest lang genug das auch Relais anziehen würden.
Vielleicht kannst da ja noch einmal schauen, ob es im Code, beim reconnect, eine Stelle gibt, die dazu führt das trotz der Einstellung ‚Eingänge high, Ausgänge high‘ kurzfristig zuerst doch ein ‚LOW‘ gesendet wird? Gefolgt dann von dem korrekten ‚HIGH‘…
Vielen Dank erstmal…
Ralf
PS:
Zu den vier Möglichkeiten…, ich denke die Einstellungen mit ‚Eingänge low‘, die kannst du entfernen, dass verwirrt eher, weil der Baustein ja nur als Eingang funktioniert wenn die Pins, die als Eingang fungieren sollen, auf HIGH (1) Signal gesetzt werden. Kurz gesagt, Eingänge MÜSSEN immer auf High(1) gesetzt werden. Also würde es reichen die beiden Einstellungen „Ausgang high“ oder „Ausgang low“ anzubieten. Das sollte reichen. Aber ansonsten wunderbar! Jeder kann so je nach Gusto und Anforderung seine optimale Einstellung wählen!
mag das am Power On des PCF8574 liegen? Im Datasheet auf Seite 18 steht etwas dazu. Möglicherweise ist aber dieser PCF8574 initial state? hilfreicher?
Wenn es dem normalen Power on-Verhalten des PCF8574 resultiert, dann wäre es vielleicht tatsächlich besser dieses auch durch eine Invertierung auf der Hardware-Seite abzufangen?
ich habe heute nochmal die Werte des BH1750 mitgeschrieben und angeschaut. Der Tagesverlauf schaut gut aus. Bis 13:45 lief er im HT2-Mode, von 13:45 bis 15:45 im HR-Mode, von 15:45-16:45 im LR-Mode und danach wieder im HR2-Mode. Soweit keine Auffälligkeiten.
Am Morgen kamen die ersten Werte ab ~07:30. Von den Werten her auch kleiner 1.0 , HT2 scheint also zu funktionieren.
Am Abend kam der letzte Werte so um ~17:30. Auch hier vorher Werte kleiner 1.0
Jetzt scheint also alles zu passen und unsere Aktivitäten haben dazu geführt, dass der Sensor nun bei 0,5 Lux (vorher 1 Lux) aktiv wird. Die immer wieder genannten 0,11 Lux erschließen sich mir daher nicht. Das ist aber schon wieder Jammern auf hohem Niveau. Für den Preis liefert der BH1750 im Alltagsgeschäft eine super Leistung, bei sehr geringen Lichtstärken muss man halt zu anderen Mitteln greifen.
Eines wäre z.B. einen hochauflösenden ADC-Wandler in deinem Modul anzusprechen zu können und dann die ganze Sensorpalette mit 0-10 Volt Ausgängen nutzen zu können. Der PCF8591 mit seinen 8 bit reicht sicher nicht aus, der ADS1115 (16 bit, ~5 €) oder noch besser MCP3424 (18 bit!, ~13 €) schon eher.
Was meinst du, könnte man dies in dein Modul einbauen?
also zu dem Startup Verhalten des Bausteins…
Ich habe, bei meinen Tests die Spannung nicht ausgeschaltet, sondern den Raspi durch ‚sudo init 6‘ neu gestartet. Die Spannungsversorgung wurde also nicht unterbrochen. Ausserdem passierte das Blitzen erst deutlich später nach dem reboot. Also etwa zu dem Zeitpunkt wo PIGPIO wieder lief.
PIGPIO als Ursache schliesse ich aus, weil PIGPIO nicht weiß welche Bausteintypen am I2C Bus hängen. Also wird daher auch keine Initialisierung gesendet.
Auch wenn ich die I2C Leitungen kappe, und den Strom ausschalte und wieder einschalte kommt es nicht zu diesem Verhalten. Das wird auch durch ein Zitat aus deinem Thread auf den du verlinkt hast bestätigt.
Zitat:
At power on, the I/Os are high.
Und die Lösung die wir jetzt erarbeitet haben ist sicher so korrekt, denn das hat dort auch jemand so gemacht:
Zitat:
Hi,
my solution for this problem was to switch the Ground.
In your case I think you need a assembly part that invert the signal, like eg a PNP Transistor.
Then you have to write a zero to the Output to switch the divice on.
MfG Jago
Also was meiner Meinung nach noch bleibt ist ein Befehl der vom IPS an den Baustein gesendet wird, beim reconnect des Raspi an das IPS…
Fällt dir vielleicht noch etwas ein?
Kannst du vielleicht Debug Ausgaben in die Sendebefehle an den Chip einbauen, dann könnte ich vielelicht sehen woher es kommt ?
es läuft jetzt super! Kein kurzzeitiges Aktivieren der Ausgänge mehr, kein Aufblitzen meiner Test LED’s…! Trotz das ich schon mehrfach den Raspi rebootet und auch den IPS Dienst neu gestartet habe. Und nebenbei ist es jetzt natürlich auch so, dass wenn ein Ausgang aktiv ist (also Last (evtl. ein Motor)läuft ) und man dann rebootet, dass dieser nach dem Reboot dann ausgeschaltet wird. Also alles auf der sicheren Seite!
Vielen Dank dafür!
Gruß
Ralf
PS:
Werde jetzt meine Testplatine löten und mich dann in das Abenteuer IPS Scripting stürzen…
da ich im Hinterkopf immer noch meinen „Smarten Briefkasten“ habe und dafür für das Wägeelement so etwas gebrauchen könnte - obwohl an der Stelle auch mit Kanonen auf Spatzen geschossen - werde ich mir den MCP3424 mal bestellen. Verwunderlich, dass ich den nicht für wenig Geld als Breakout in China gefunden habe…
Ja, da kann man schon erstaunliche Sachen damit machen. Die Beispiel [LINK]zeigt den Aufbau einer Wägezelle für Bienen mit dem MCP3424.
Warum man den MCP3424 nicht billig als Chinaware bekommt hat mich auch gewundert. Den ADS1115 gibt’s im Überfluss. Na ja, hat auch was Gutes, dass man dann nicht 30 Tage warten muss, biss das Schiff aus Asien angekommen ist.
ich habe meinen MCP3424 bei komputer.de bestellt und Gestern bekommen. Ich habe mal „quick and dirty“ ein Python Script gebastelt, welches ich in IP Symcon mit shell_exec aufrufe. Erste Ergebnisse von dem AD-Wandler mit seinen 18 bit sind echt beeindruckend. Da kriegt man z.B. die geringsten Spannungsveränderungen bei einer Batterieentladung mit. Grundrauschen war auch so gut wie nicht festzustellen (siehe Grafik der Spannung einer AAA-Zelle in mV)
#! /usr/bin/python
# MCP3424.py
import smbus
import time
from smbus import SMBus
bus = smbus.SMBus(1)
delay = 1.0
i = 0
while(i==0):
result = bus.read_i2c_block_data(0x68, 0b00011100) #18 bit resolution
if(result[0]&0x80):
value = (((result[0]^0xff)&0x7f)<<16) + ((result[1]^0xff)<<8) + (result[2]^0xff)
value = wert *(-1)
else:
value = ((result[0]&0xff)<<16) + (result[1]<<8) + (result[2])
value = 15.625 * value / 1000
print value
i = 1;
# time.sleep(delay)
gerne, ich habe es gerade getestet. Als Spannungsquelle diente eine AAA-Alkaliebatterie. Auf meinem Multimeter wurde damit eine Spannung von 1,426 Volt angezeigt. Mit deinem Modul wurde folgendes erfasst:
12 bit = 1,412 V
14 bit = 1,4115 V
16 bit = 0 V
18 bit = 0 V (beim ersten Anlegen der Instanz und setzen auf 18 bit kamen kurz 1,41175 V ging dann aber 0)
Mein „dirty“ Python Script liefert bei 18 bit kontinuierlich 1411,3XXXXX mV. Ich initialisiere am Anfang aber immer komplett durch.
…der Plan ist erst halb fertig. Ich werde zusehen, dass ich ihn am WE fertig bekomme. Dann werde ich ihn gerne posten…
Es wird sich dabei um eine Schaltung handeln die als Interface zwischen dem Raspi und meiner im Haus verbauten Schaltung dient. Bereits jetzt ist überall in jedem Rolladenkasten eine kleine Relaisplatine enthalten deren Ansteuerung dann in insgesamt vier Schaltkästen im Haus zusammenläuft. Dort werden dann letztlich vier Raspis mit den Platinen eingesetzt.
1 Instanzen vom Typ „IPS2GPIO_OUTPUT“ angelegt - Steuern funktioniert auch.
Und jetzt kommts: Komischerweise ist das Relais aber invertiert. Im Status der Symcon steht Aus obwohl es angesteuert ist. Auch schaltet das Relais direkt ein wenn ich Symcon mal neustarte. Das 2te, welches ich nocht nicht in Symcon angelegt habe, bleibt aber inaktiv. Kann mir hier vll. einer auf die Sprünge helfen?
Klasse!
