Hallo Zusammen,
ich habe mir in den Kopf gesetzt verschiedene Türöffner mithilfe von iButtons zu steuern und hierzu nun erstmal eine technische frage...
Bekomme ich eine meldung darüber welcher Button an welchem Reader war, oder geht nur ein reines der Button ist im Bus?
Um die verschiedenen öffnungs-szenarien geschickt ablaufen zu lassen bräuchte ich nämlich die Information an welcher Station der Button gesichtet wurde. Oder geht der weg nur wenn jeder Reader einen eigenen Bus hat?
Ich werfe mal in den Raum das ich acht Reader brauche, manche sind sich physikalisch sehr nach ( innen und aussen am Tor ) Mehr als drei verschieden Button konfigurationen wird es nicht geben...
ich meine das geht nicht wenn alles an einem bus hängt.
aber du kannst jeden reader an einen eigenen bus hängen und bekommst dann in der owfs/OWServer/OWDevice variante ein location reading in dem die bus id steht.
wie das bei den anderen OW modulen ausschaut weiss ich nicht.
gruss
andre
Die "Reader" sind nur elektrische Kontakte - woher sollte ein Busmaster die unterscheiden können ? Das geht also nicht, es sei denn, jeder "Reader" hat einen eigenen Bus. Wäre z.B. machbar, indem ein Arduino (Kleinsversion reicht) nach außen als Busmaster auftritt. Dann würde ich ihn aber nach innen nichtals 1-Wire ankoppeln (wg. pull-Prinzip des 1-Wire Bus), sondern z.B. mit einem Funksender.
LG
pah
Würde das auch mit einer Lan verbindung funktionieren?
Eine Drahtlose verbindung würde ich lieber vermeiden...
Sicher.
LG
pah
Also gilt es einen Arduino mit Ethernet Anschluss zu benutzen. Wäre es denn möglich an einem Arduino zwei unterscheiden zu können? Wie würde es mit der Response ausschauen? Diese Arduinos könnten ja dann auch direkt den Türöffner betätigen - die meldung zu FHEM ist mir zwar wichtig, aber nicht so Zeitkritisch wie das betätigen des des Öffners.
Welche Modelle kommen in frage und wo würden die Kosten liegen?
Danke schonmal für die Unterstützung.
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.
Gruß
Spielmann
Hm, also so richtig rund wird die sache so noch nicht...
Hat jemand erfahrungen mit http://www.fuchs-shop.com/de/shop/20/1/13372120/ (http://www.fuchs-shop.com/de/shop/20/1/13372120/) diesen Teilen?
Das macht den Spaß aber auch recht teuer.
Aha, auch nicht schlecht, aber teuer das stimmt. Da ist die Variante die pah angesprochen hat wohl besser. Sprich einen kleinen AVR zwischen hängen der mehrere 1-Wire Busmaster bereitstellt und dann an jedem ein iButton Halter. Auf der anderen Seite könnte man das ja dann geschickt auf den normalen 1-Wire Bus bringen. Oder eben per Funk oder LAN wegschicken.
Ich hab nur ein Schlüsselkasten, da ist es im Prinzip egal wo ich mein Schlüssel anhänge, wichtig ist nur, dass ich weiß, welcher Schlüssel da ist. Gut Nachteil ist, dass ich eben nicht pro iButton Halter die LED grün schalten kann wenn dieser erkannt wurde sondern nur alle Halter auf einmal.
btw: "LinkLocator nur in Verbindung mit einigen 1-Wire Adaptern vom Hersteller iButtonLink eingesetzt werden können" mhh
/Daniel
Hi,
ich gebe gerne noch einen Denkanstoß, ähnlich wurde er auch schon von PAH ins Spiel gebracht.
Ich stand vor einiger Zeit vor der selben Herausforderung und bin bei der ausgiebigen Suche nach Alternativen (ähnlich deines letzten Links) dazu übergegangen, einen Arduino mit passendem 1Wire Code zu versehen, dieser erkennt ob der jeweilige iButton berechtigt ist und schließt, in diesem Moment, für eine einstellbare Dauer einen Kontakt, welcher auf einen 1Wire DS2408 Eingang geht.
Anhand der DS2408 Eingänge kann ich erkennen, wo der iButton benutzt wurde, eine entsprechend kurze Abtastdauer des DS2408 wird benötigt, alternativ kann natürlich auch ein anderes, bei dir evtl. genutzte System genutzt werden, z.B. Homematic http://www.elv.de/homematic-8-kanal-empfangsmodul.html oder MySensors oder oder oder.
Gleichzeitig lassen sich mit dem Arduino noch die LED bzw. Mehrfarben LEDs schalten, welche einige iButton Leseeinheiten mitbringen.
Das der Arduino und seine abgehenden Leitungen möglichst nicht ohne größe Aufbrucharbeiten zugänglich sein sollten versteht sich von selbst ;)
Greetz
Eldrik
Mhh naja auch ne Idee ;-) gefrickel eben, aber wenn schon denn schon, dann kann man dem AVR auch ne Ethernet Schnittstelle verpassen um neue Seriennummern anzulernen ;-)
man sollte wenn möglich immer latched verenden. dann muss man mit der abfragezeit nicht ganz so weit runter und verpasst trotzdem kein signal.
gruss
andre
Wenn nach Dem lesen des richtigen Buttons unverzüglich ein Schliesser betätigt wird, welcher die Türöffner betätigt ist das schon toll - Wenn FHEM die Info über Button und Leser im Bereich 10-30 sek. bekommt reicht das vollkommen aus.
Vielleicht ein Leser direkt an der Haustür der etwas schneller reagiert um unscharf zu schalten...
Hier der Arduino-Sketch, der in Abständen von 250 ms den Reader abfragt und bei passendem Button die Tür öffnet. Und natürlich die RGB-LED ansteuert. Selbstverständlich haben meine iButton-Carrier die Farbe, in der dann die LED leuchtet:
http://ice-karlsruhe.de/projekte/smarthome/smarthome-hacks-links-und-ergaenzungen/#k6
LG
pah
Zitat von: Prof. Dr. Peter Henning am 14 April 2016, 18:24:27
Hier der Arduino-Sketch
Hallo pah,
ich habe den Sketch (Garagenöffner) sowohl auf einen nano als auch auf einen Uno geladen. Mal von zwei Klammern zu viel abgesehen (Zeile 50 u. 52) läuft das Kompilieren mit den eigenen iButton-IDs durch.
Nun der Huch-Effekt:
Danach geht PIN 13 im 250ms-Takt auf HIGH (wie die Status-LED auf dem Arduino), die RGB zeigt dauerhaft Müll an (alle PINs HIGH) und PIN 7 und 8 sind auch auf HIGH. Der serielle Monitor zeigt mir auch nichts...
Also eigentlich geht gar nichts... ;)
Habe ich was übersehen?
Gruß
Uwe
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
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:
/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)
Ich habe noch Warnungen unterschlagen...
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]
Nun ja:
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
Zitat von: Prof. Dr. Peter Henning am 17 April 2016, 12:58:49
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
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
Ah, Danke, verstanden. Somit läuft's jetzt auch :)
Hallo zusammen,
weiter ober schrieb ich:
ZitatHallo 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
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
@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
@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
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
Zitat von: ext23 am 30 April 2016, 12:11:34
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
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
Zitat von: Prof. Dr. Peter Henning am 30 April 2016, 15:39:35
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.
Es geht mir nicht um das schnelle aufschließen. Mein Schlüssel ist da wo auch der iButton dran ist, ich habe die Tür mit einem Schlüssel bestimmt schneller offen als jedes Motorschloß ;-)
Es geht mir um Sicherheit. Schlüssel verlieren, Zeitbegrenzung, logging etc.
/Daniel
@UweH: Na, erstens sind unsere Trinkgewohnheiten wohl unterschiedlich. Und zweitens kann man ja durchaus drauf verzichten, und für den Partyabend die Sicherheitsüberprüfung weniger stark einstellen.
LG
pah
Zitat von: ext23 am 30 April 2016, 17:01:38
ich habe die Tür mit einem Schlüssel bestimmt schneller offen als jedes Motorschloß ;-)
Ich will jetzt nicht einen altbekannten Vergleich bemühen, aber ich habe eben ein kleines Video gemacht... Ich finde, die Tür geht schon recht schnell auf (Fuhr Multitronic 881).
https://vimeo.com/164831880 (https://vimeo.com/164831880)
*lol* Die war aber nicht verschlossen oder? Aber naja das schaffe ich mit Schlüssel auch noch, aber mit 35 geht das auch noch, ohne 3 Atü aufm Kessel natürlich :-)
/Daniel
Klar war die verschlossen.
Oha, na das ist dann wirklich verdammt schnell wenn der zwei mal kurbelt. Das klang dem Geräusch nach nur als wenn der ne Schnapper Sperre löst und dann öffnet.
Unsere Türen im Büro sind da richtig am Leiern, da muss ich locker 3 Sekunden warten bis man ziehen kann.
Die will ich. Ich antworte mir auf die Frage nach dem Preis mal selbst: https://www.groheshop.com/Shop/Search?term=fuhr
LG
pah
Jupp, aber für das Komplett Set muss man ja fast noch sagen, dass der Preis noch OK ist.
Ich lese nur immer "Funk" ich hoffe das kann man auch deaktivieren, sonst würde ich mir zumindest nicht so ein System kaufen ;-)
Einen schönen 1. Mai!
/Daniel
Ich habe das System (http://www.fuhr.de/fuhr/de/produkte/prod_tuer_881.php) zusammen mit der Tür gekauft bzw. direkt einbauen lassen und somit sind da noch ein paar Prozente bei rausgekommen. Natürlich ist es bei diesem System wie beim iPhone...man weiß, dass man zu viel bezahlt, aber man will es trotzdem haben.
Der Funkempfänger auf der Steuerelektronik ist abnehmbar (s. Screenshot), die Elektronik extern ansteuerbar.
Gruß
Uwe
Ja nicht schlecht, gefällt mir.
Hallo Fhem- Gemeinde
auch nach dem lesen gefühlter 1000 Seiten und Beiträge habe ich leider noch nicht rausgefunden, mit welchen
I-Button, I-Button Reader und 1wire Busmaster der Raspberry Pi3 zuverlässig zusammen arbeitet?
Der I-Button Reader sollte auch halbwegs Regenfest sein. (aussen an der Haustür)
Ist der 1wire Busmaster event. der gleiche Typ der auch für die Dallas Temperaturfühler DS18B20 funktioniert.
Ich wäre den Fachleuten hier sehr dankbar wenn man mir hier eine Typ/ Hersteller Empfehlung geben könnte.
Eine Einkaufsquelle werde ich dann hoffentlich auch selber finden.
So am Rande, ursprünglich wollte ich die Haustür ja mit RFID öffnen. Das die Einbrecher hier bei uns auf dem Land schon so aufgerüstet sind kann ich mir nicht vorstellen. Da aber die Zutrittskontrolle auch morgen noch sicher sein soll folge ich jetzt doch der Sichtweise von Prof. Dr. PAH. Vielen Dank für die Informationen.
Schöne Grüße
NewRasPi
Alle Details sind hier schon veröffentlicht worden - sowohl im Forum, als auch im Wiki. Klar geht das auch in kurz zusammengefasster Form - aber sorry, ich schreibe nicht ein ganzes Buch über den Kram, um das dann kostenlos der Allgemeinheit zur Verfügung zu stellen.
http://www.oreilly.de/buecher/12387/9783960090120-smarthome-hacks.html
Ist ab 12. Mai in den Buchläden, E-Book in Vorbereitung.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 04 Mai 2016, 08:51:50
Alle Details sind hier schon veröffentlicht worden - sowohl im Forum, als auch im Wiki. Klar geht das auch in kurz zusammengefasster Form - aber sorry, ich schreibe nicht ein ganzes Buch über den Kram, um das dann kostenlos der Allgemeinheit zur Verfügung zu stellen.
http://www.oreilly.de/buecher/12387/9783960090120-smarthome-hacks.html
Ist ab 12. Mai in den Buchläden, E-Book in Vorbereitung.
LG
pah
Noch mal kurz hallo, dieses Buch ist schon bei unserem Buchhändler vorbestellt. ;)
Gerne hätte ich bis dahin auch schon die Bauteile bestellt. Bei manchen Versandhändlern dauert das ja auch einige Zeit.
Trotzdem vielen Dank für alle bisherigen Info`s
Noch ein Versuch :-)
Kann jemand der sich damit auskennt mir kurz "Rückendeckung" geben?
Ich bin dabei die folgenden I- Button Teile zu bestellen.
1. 1-wire USB Adapter DS9490R# (zwei Stück) a. 21,90
("Der DS9490R basiert auf dem DS2490 USB to 1-Wire Bridge Chip")
http://www.fuchs-shop.com/de/shop/17/1/13372016/
2. DS1990A-F5+ iButtons (10 Stück) a. 1,60
http://www.fuchs-shop.com/de/shop/4/1/13372072/
3. DG9092L2-M20-ST-MG2 iButtonreader (drei Stück) a. 8,90
http://www.fuchs-shop.com/de/shop/16/1/13372563/
(zuzüglich Halter z.B. DS9093A in Schwarz und Kabel)
aus dem Fuchs Elektronik Versand.
Klasse wäre es, wenn schon jemand weiß ob dieser 1-wire USB Adapter am Raspberry Pi2 / Pi3 einzurichten geht/ erkannt wird.
Vielen Dank für Eure Hilfe. (so genaue Details habe ich leider nirgends gefunden)
Schöne Grüße
NewRasPi
Hallo NewRaspi,
hier ein paar Anmerkungen zu den Teilen:
zu 2: Ich habe mir 20 Stück DS1990R-F5 geholt, da er zum DS1990A kompatibel ist und zusätzlich ein Preset Impuls sendet (ob das ein Vorteil ist weiß ich nicht) und habe mir diese gleich mit dem Halter DS9093 konfektionieren lassen (http://www.fuchs-shop.com/de/shop/30/1/13372161/). Ich denke diese 9 ct pro Button waren eine gute Investition, da diese bombenfest im Halter sitzen und ich mir vorstellen kann, dass das Hineindrücken schwierig sein könnte.
zu 3: Ich habe diesen Halter und den Halter http://www.fuchs-shop.com/de/shop/16/1/13372018/ mit taktilem Feedback. Der letztere hat eine sehr gute Kontaktierung (gefederter Kontakt und konisch geformter Rand), jedoch keine LEDs und die Befestigung erfolgt über eine Klemmbrille.
Ich habe mich letztendlich für den DG9092L2-M20-ST-MG2 entschieden, da ich aufgrund der rauen Umgebung und täglicher Benutzung von ca. 15 Personen keine beweglichen Teile wollte - auch wenn man den Button zur Kontaktierung etwas zum Rand drücken muss.
Gruß
Spielmann
ZitatDS2490 USB to 1-Wire Bridge Chip"
Geht nicht mit jeder Software, derzeit nur mit OWFS.
ZitatPreset Impuls sendet (ob das ein Vorteil ist weiß ich nicht)
Jein. Der Busmaster kann an Hand des Reset-Impulses feststellen ob sich etwas am Bus befindet - aber nicht, WAS.
ZitatHineindrücken schwierig sein könnte.
Nicht wirklich.
Mit Readern OHNE taktiles Feedback habe ich beste Erfahrungen gemacht - es kommt nur auf einen kurzen Kontakt für 1/4 Sekunde an.
LG
pah
Hallo Gemeinde
meine Teilebestellung ist heute eingetroffen. :D
@ Spielmann; Vielen Dank für Deine Auskunft. Das Konvektionieren habe ich mir bei Fuchs natürlich auch gegönnt.
Ist der Gedanke, der Sabotage Sicherheit auf dem 1wire Bus am Leser schon etwas weiter gereift?
Ein erster Ansatz zum Schutz gegen Überspannungen wäre eine Zehnerdiode, zumindest wenn die das Nutzsignal, den eigentlichen Bus nicht stört.
Andererseits, eine Überspannung am i-Button Leser würde ja schlimmstenfalls den 1wire Adapter und eventl. den Raspi schädigen, eine daran angeschlossene Relaisplatine (die das öffnen der Haustür übernimmt) würde dadurch nicht reagieren. Es wäre meiner Meinung nach dann nur ein Vandalismusschutz.
Eine unerwünschte Manipulation sollte am sicheren Zutrittssystem i-Button damit nicht möglich sein, oder?
Hat schon mal jemand versucht, ob der Bus (am Leser) tatsächlich "Kurzschlussfest" ist?
Auch Dir/Ihnen vielen Dank für die Hilfe:
Zitat von: Prof. Dr. Peter Henning am 10 Mai 2016, 19:16:24
Geht nicht mit jeder Software, derzeit nur mit OWFS.
...
LG
pah
So wirklich habe ich nur immer noch nicht erkannt ob das die Zutrittsschaltung/ Erkennung und Auswertung ermöglicht. In der Commandref ist OWFS nur in Englisch :-(
Mit dieser Anleitung hoffe ich das es einzurichten geht.
Zitat von: locutus am 26 Februar 2015, 23:52:25
1. Benötigte Pakete installieren:
sudo apt-get install owserver ow-shell
2. Das System neu starten:
sudo reboot
3. OWFS konfigurieren:
sudo nano /etc/owfs.conf
Die Konfigurationsdatei wie folgt ändern:
server: device = /dev/ttyUSB0
http: port = 2121
ftp: port = 2120
server: port = localhost:4304
Mit "Strg+x" den Editor verlassen. Die Rückfrage, ob die Datei gespeichert werden soll, mit "y" beantworten und mit der Eingabetaste bestätigen.
4. Am 1-Wire-Bus angeschlossene Devices abfragen:
owdir -s localhost:4304
5. OWServer in FHEM definieren:
define myLocalOWServer OWServer localhost:4304
Hoffentlich klappt jetzt heute Abend auch das Einrichten am Raspi.
Schöne Grüße
NewRasPi
Hier mein neuer Beitrag zum iButton-Zugangssystem
https://forum.fhem.de/index.php/topic,49877.msg450708.html#msg450708
LG
pah