iButtons als Zugangssystem..?

[Prof. Dr. Peter Henning]

Nö, kann eigentlich nicht sein.

Das mit den Klammern ist reingerutscht, als ich meine eigenen 1-Wire ID's gelöscht habe. Ist gerade auch schon im Downloadbereich behoben worden.

Der Code ist genau so bei mir im Einsatz und tuckert 24 h pro Tag vor sich hin.

"Nur Müll" auf dem LED-Ausgang bedeutet was ?

Das Blinken zeigt den Bus-Zugriff an. Wenn das gar nicht aufhört, wird kein Bus-Device erkannt. Wenn das aufhört, aber sonst nichts passiert => Zusätzliche Fehlermeldung nach Zeile 150 einbauen. Ach ja, selbstverständlich müssen auch die // vor den println-Befehlen raus.

LG

pah

[UweH]

Müll im Sinne von alle RGB-Ausgänge auf HIGH.
Die Ausgänge 7, 8, 9, 10 und 11 sind nach dem Sketch-Upload auf HIGH, 13 blinkt im 250ms-Takt. Zur Sicherheit auch auf einem Uno und einem zweiten nano getestet, überall gleich.

Kompilieren und Upload funktioniert, es gibt aber auch Warnungen während des Kompilierens:

Code Auswählen Erweitern

/usr/share/arduino/hardware/arduino/cores/arduino/HardwareSerial.cpp: In function 'void store_char(unsigned char, ring_buffer*)':
/usr/share/arduino/hardware/arduino/cores/arduino/HardwareSerial.cpp:100:20: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
   if (i != buffer->tail) {
                    ^
/usr/share/arduino/hardware/arduino/cores/arduino/HardwareSerial.cpp: In function 'void __vector_18()':
/usr/share/arduino/hardware/arduino/cores/arduino/HardwareSerial.cpp:129:21: warning: unused variable 'c' [-Wunused-variable]
       unsigned char c = UDR0;
                     ^
/usr/share/arduino/hardware/arduino/cores/arduino/HardwareSerial.cpp: In member function 'void HardwareSerial::begin(long unsigned int, byte)':
/usr/share/arduino/hardware/arduino/cores/arduino/HardwareSerial.cpp:370:11: warning: unused variable 'current_config' [-Wunused-variable]
   uint8_t current_config;
           ^
/usr/share/arduino/hardware/arduino/cores/arduino/HardwareSerial.cpp: In member function 'virtual size_t HardwareSerial::write(uint8_t)':
/usr/share/arduino/hardware/arduino/cores/arduino/HardwareSerial.cpp:469:27: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
   while (i == _tx_buffer->tail)

[UweH]

Ich habe noch Warnungen unterschlagen...

Code Auswählen Erweitern

iButton.ino:52:93: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings]
iButton.ino:52:93: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings]
iButton.ino:52:93: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings]
iButton.ino:52:93: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings]
iButton.ino:52:93: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings]
iButton.ino:52:93: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings]
iButton.ino: In function 'void loop()':
iButton.ino:109:15: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings]
iButton.ino:153:13: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings]
iButton.ino:84:9: warning: variable 'device' set but not used [-Wunused-but-set-variable]
iButton.ino:85:7: warning: unused variable 'ledState' [-Wunused-variable]

[Prof. Dr. Peter Henning]

Nun ja:

Code Auswählen Erweitern


if (i != buffer->tail) {
                    ^
       unsigned char c = UDR0;
                     ^
   uint8_t current_config;
           ^
[-Wsign-compare]
   while (i == _tx_buffer->tail)


stammen aus einem fehlerhaften Setup der Arduino-IDE - nicht aus meinem Programmcode.

Vielleicht erst einmal so lange mit den Bibliotheken der IDE die mitgelieferten Beispiele compilieren, bis diese ohne Fehler laufen. Dabei kann ich aus der Entfernung nun leider wirklich nicht helfen.

LG

pah

[UweH]

Dabei kann ich aus der Entfernung nun leider wirklich nicht helfen.

Nö...sorry für die Zeitverschwendung, ich habe wohl einen kolossalen Denkfehler begangen...die RGB-LED im iButton-Reader hat eine gemeinsame Anode. In Ermangelung solchen Teiles habe ich einen "normalen" Reader angeschlossen und eine separate RGB-LED...mit gemeinsamer Kathode *lautidiotschrei* Konnte also nur "Müll" anzeigen. Kurioserweise hat diese LED gleich mal den gesamten Arduino durcheinander gebracht. Soweit funktioniert das jetzt also.
Sehe ich das richtig, dass auch Pin 13 (steuert den Toröffner an?) beim Erkennen eines berechtigten iButtons für 250ms auf LOW geht?

Danke und Gruß
Uwe

[Prof. Dr. Peter Henning]

Nein. Pin 13 blinkt lustig im Takt der Buszugriffe.

Pin 7 = okPin setzt für 1 Sekunde den Öffner auf Low (das ist bei mir der angezapte Tasteneingang eines HomeMatic-AKTORS). Warum Aktor ? Damit ich den zusätzlich per Funk schalten kann.

LG

pah

[UweH]

Ah, Danke, verstanden. Somit läuft's jetzt auch 

[Spielmann]

Hallo zusammen,
weiter ober schrieb ich:

Hallo Lolo,
ich versuche schon seit 2 Jahren (mit langen Unterbrechungen) eine Tankstelle mit einem Raspi und einem Arduino über Ethernet mit configurablen Firmata in Gang zu bekommen. Am Arduino habe ich zwei 1-wire Busmaster definiert (direkt am Arduino) - einer für die i-Buttons (20 Buttons) zur Zugangsberechtigung und einen für einen DS2423 um die getankte Menge zu zählen. Zudem sind am Arduino Ein- und Ausgänge definiert. Es müsste also gehen über mehrere definierte Busmaster am Arduino eine Zuordnung zu bekommen und einem Türöffner zu schalten. Der Arduino mit der configurablen Firmata läuft allerdings nicht autark - die Verbindung mit fhem muss bestehen.

Mein Arduino verabschiedet sich allerdings nach mehreren Stunden und muss diesen wieder reseten um die Verbindung wieder herzustellen. Dabei habe ich folgendes schon getestet bzw. ist bei mir aufgetreten (mit wheezy und jessie):
OWX:
- Vorteil: Prozessorlast geringer als OWX_ASYNC
- Nachteil: in fhem polle ich jede Sekunde nach den Buttons (at +1s get devices). Der Arduino verabschiedet sich schon nach wenigen Minuten bis Stunden vom Netz. Ich muss mein OWID-Device zwei mal definieren, dass der Button beim pollen erkannt wird (also 40x OWID bei 20 i-Buttons).

QWX_ASYNC:
- Vorteil: Die OWID-Devices müssen nur einmal definiert werden und das pollen funktioniert automatisch. Der Arduino läuft über getestete zwei Tage ohne Netzprobleme.
- Nachteil: Der Prozessor wird bis zum Stehkragen belastet (nach Optimierung ist die Auslastung bei 85-90% bei übertaktetem Raspi)

Mein Problem ist jetzt noch: Sobald ich noch einen Samba-Server installiere (benötige ich um von Windows auf die Tankliste im Raspi zuzugreifen), schmiert mir mein Arduino nach Stunden wieder ab.

Ich hoffe jetzt auf pahs neuem OWX.

Falls jemand interessiert:
Die Prozessorlast konnte ich erheblich reduzieren (von 85-100% auf 10-15%) indem ich OWID nicht mehr definiere sondern per Poll im 1s-Takt nach Devices suche, d.h:

alt: 20 x Devices wurden mit OWID angelegt und diese nach dem present im notify abgefragt.

neu: OWID wird im Programm nicht mehr vorher angelegt (alle OWID-Devices gelöscht). Im 1s-Takt wird nach neuen Devices gesucht und dann die erkannte OWID-Device im notify die ID abgefragt. Ich polle jetzt zwar wieder aktiv den Busmaster an (at +1s get devices) und muss den iButton schlimmstenfalls bis 1s an die Kontaktfläche halten - jedoch ist das das kleinere Übel.

Das Ganze läuft jetzt stabiler und auch mein Samba-Server läuft. Mal schauen ob die Verbindung über mehrere Tage zum Arduino hält.

Gruß
Spielmann

[Prof. Dr. Peter Henning]

Irgendwie habe ich das Gefühl, das nicht dazu gesagt zu haben: Auch auf dem Arduino mache ich keine Abfrage, ob ein bestimmtes Device da ist (viel zu langsam !!). Sondern eine generelle Bussuche - mit Vegleich, ob diese ID in der Liste steht.

LG

pah

[ext23]

@Spielmann: Mhh dann macht das vermutlich bei meinem Schlüsselkasten auch Sinn. Ich habe da 3 iButtons dran, dazu noch ein LCD und das wars. Vielleicht sollte ich das auch mal so machen. Ich hab zwar keine Probleme mit CPU Last, da mein FHEM auf einem, ich sag mal recht performanten Server läuft, aber wenn ich apptime so beobachten haben die 1-Wire Module recht lange Laufzeiten.

/Daniel

[Spielmann]

@ext23: Der Arduino mit configurablem Firmata hat halt den gewissen Charme, dass man über das Netzwerk alles was man so braucht erfassen bzw. schalten kann ohne noch viel Hardware bis auf ein paar Widerstände bzw. Schutzdioden zu benötigen (bei mir LCD, 3 x Relais, ein Taster, Tastenblock (über analoge Eingänge - aber frag mich nicht wie ich das umgesetzt habe), DS2324 Zähler, 20 x iButtons) Wichtig ist auch ein gut funktionierendes Ethernet-Shield und stabile Stromversorgung. Wahrscheinlich werde ich das ganze noch mit einem Watchdog versehen, falls die Verbindung doch mal abschmiert.

Gruß
Spielmann 

[ext23]

Ich hab mir auch mal pah sein Beispiel Programm installiert, läuft auch Anhieb (Wenn man die Anzahl der iButtons von 7 auf 6 senkt, sonst hängt der sich auf bei einem nicht vorhandenem iButton).

Ich muss mal schauen wie ich im Sommer so Zeit finde, aber ich würde gerne ein RC522 RFID Reader (MiFare, NFC) rann hängen und ein PinPad. Und die ganzen Seriennummern kommen in den eeprom. So das man diese über UART ändern kann (Später dann vielleicht MQTT oder sowas).

Bei MiFare würde ich dann noch im Datenbereich verschlüsselt die UID ablegen, hat den Grund, dass man die UID sehr leicht auf so genannte UID writeable Cards kopieren kann. Die vorhandenen Speicherbereiche mit default Key werden auch geändert! Da sonst Tools wie mfoc die chance haben den Key auszulesen. Bei iButton bzw. NFC könnte man dann zusätzlich das Ganze mit einer PIN absichern. Hat den Grund, dass es möglich ist die iButton Seriennummer auch "simulieren" und die NFC UID erst recht. Bei den iButtons ist die Gefahr natürlich gering, da man dazu den Button irgendwann mal aus der Hand geben muss. Bei NFC ist es schon wahrscheinlicher.

Aber das schwirrt mir nur alles so im Kopf rum im Moment. Ich weiß nicht ob man das alles auf ein AVR bekommt oder lieber gleich ein RPi für sowas benutzt.

/Daniel

[UweH]

Bei iButton bzw. NFC könnte man dann zusätzlich das Ganze mit einer PIN absichern.

Dann kannst Du auch den Schlüssel aus der Tasche ziehen und aufschließen. Bei Deinem angedachten Prozedere wäre (für mich jedenfalls) der Vorteil des schnellen Türöffnens dahin.
Eine ähnliche Diskussion haben wir an anderer Stelle schon mal geführt... Der durchschnittliche Einbrecher aus dem ganz ganz nahen Osten kommt mit dem Kuhfuß, nicht mit moderner Snifferelektronik und benutzt die Rückseite des Hauses, nicht die Haustür.

Gruß
Uwe

[Prof. Dr. Peter Henning]

Alles richtig. Darum sind die Rückseiten und Fenster abzusichern. Und an der Haustür habe ich zum "normalen" Öffnen künftig iButtons - so wie am Garagentor und an der Hoftür. Hinzu kommt bei erhöhtem Verriegelungsbedarf ein smartes Namensschild, bestehend aus einem resistiven Touchpad vor einem LCD.

Ich überlege noch, ob ich nach dem Auflegen des iButtons schnell nacheinander binär zu beantwortende Fragen aus einem Pool, oder ein stinknormales Keyboard mit PIN-Abfrage anzeigen lasse.

Steuerung über eine DoorPi-Instanz.

LG

pah

[UweH]

schnell nacheinander binär zu beantwortende Fragen

*rofl* hoch drei...mir stehen die Tränen in den Augen. Ich sehe mich gerade leicht beschwipst vor der Tür, nachts 2 Uhr...und dann stellt mir diese dämliche Tür auch noch Fragen.
Verrückt.