iButtons als Zugangssystem..?

Begonnen von der-Lolo, 05 April 2016, 20:39:07

Vorheriges Thema - Nächstes Thema

der-Lolo

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...

justme1968

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
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Prof. Dr. Peter Henning

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

der-Lolo

Würde das auch mit einer Lan verbindung funktionieren?
Eine Drahtlose verbindung würde ich lieber vermeiden...

Prof. Dr. Peter Henning


der-Lolo

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.


Spielmann

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
FHEM mit Raspi (Zentrale)
Raspberrymatic (Heizung)
Siemens LOGO8 (Lichtsteuerung)
Philips HUE Gedöns
Diesel-Tankstelle mit fhem und ESP (eine ewige Baustelle)

der-Lolo

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/ diesen Teilen?
Das macht den Spaß aber auch recht teuer.

ext23

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
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

eldrik

#9
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

ext23

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 ;-)
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

justme1968

#11
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
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

der-Lolo

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...

Prof. Dr. Peter Henning

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

UweH

#14
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