RFID per 1Wire an Raspberry möglich ?

[Skusi]

Hallo,
ich bin gerade über dieses hier gestoplpert:

http://www.fuchs-shop.com/de/shop/43/1/13372662/

Ich frage mich ob es möglich ist diesen Reader an dem 1Wire Bus zu betreiben den ich für Temperatursensoren schon an meinem Raspberry in Betrieb habe.

Ich würde den Reader gerne an der Hauswand anbringen um dann per RFID Tag meine Alarmanlage zu schalten.
Kann man so einen 1Wire Teilnehmer einfach an den Bus hängen ? und wie wir das dann in Fhem ausgewertet ?

Ich finde das Ding echt interessant. Gerade auch wegen der integrierten Duo LED.

Hat mal jemand ne Einschätzung, oder besser noch, Erfahrung damit ?

Gruß Skusi

[ak323]

Klingt interessant ...

Warum soll das nicht funktionieren ? "Nach hinten" sieht der 1-wire Bus einen iButton.
Fraglich nur wie das mit dem Vorhalten der Karte und der 1-wire Bus Abfrage aussieht..,

Ich mache das ganze per "klassischem" iButton

VG ak323

[ext23]

Je nachdem für was man das gante benutzen möchte. Das Teil liest nur die UID der Karte aus. Die kann man natürlich simulieren oder es gibt auch UID Writable MiFare Karten. Also meine Eingangstür würde ich damit nicht absichern.

Dann lieber direkt ein Leser an den Raspberry und die Karten entsprechend absichern, alle Blocke mit Key versehen und etwas "spezielles" meinetwegen auch eine Art Seriennummer aus dem Speicherbereich auslesen. Das ist sicherer (in dem Fall Security by Obscurity). Wenn alle Blöcke mit Key versehen sind kann man diese schonmal nicht mehr ohne weiteres auslesen (Hier gibts ein Bug in dem Random Generator bei alten Karten). Und am "vorbeigehen" kommt man an die Daten schonmal garnicht.

/Daniel

[Skusi]

Ok, das das ganze nicht sicher ist, nehm ich in Kauf. Ich will damit auch nicht meine Haustür öffnen, sondern meine kleine Alarmanlage unscharf schalten.

Bisher hab ich das mit einer billigen Pollin Fernbedienung gemacht. Aber das gab immer wieder Probleme mit dem Empfang. Wenn wir verreist waren und die Katzenmutti vorbei kam, hat es regelmäßig Fehlalarm gegeben weil die FB nicht richtig geschaltet hatte (oder Mutti nicht richtig gerdückt )

Nun wollte ich diesen RFID Leser ausserhalb des Hauses anbringen und den entsprechenden Leutchen die Tags geben. Über die integrierte LED wird dann per GPIO der Status der Anlage angezeigt.

Da der Leser nicht an der Fronttür angebracht wird, und ich nicht glaube das der Gelegenheits-Einbrecher sich mit dem auslesen und kopieren eines Tags beschäftigt, denke ich kann ich die Unsicherheit des System verschmerzen.

Ich wollte nur was schöneres als einen Schlüsselschalter bauen. Und wenn ein Tag verloren geht kann ich die UID einfach löschen.

Frage ist, wie ich das anlegen eines Tags in Fhem mitbekomme und dann die UID in ein reading schreiben kann. Per DOIF könnte ich dann ja jede beliebige Aktion auslösen wenn die UID mit einer der berechtigten verglichen wird.

Also was macht der Leser wenn ein Tag davorgehalten wird. Schreibt er dann die UID in eine Textdatei auf dem Raspberry, und wie kann ich die per Fhem in ein reading bekommen.

Meine 1Wire Temp Sensoren machen das doch ähnlich. Die erstellen doch einen eigenen Ordner und schreiben die gemessenen Werte in eine Datei.

z.B:

/sys/devices/w1_bus_master1/28-0215833a1cff/

Fragen über Fragen....

[Prof. Dr. Peter Henning]

Das ist ganz einfach: Der Busmaster muss in kurzen Abständen (ergonomisch sinnvoll < 0,4 Sekunden) eine Bussuche durchführen. Findet er ein neues Device, wird dessen Seriennummer mit den bereits registrierten verglichen und eine von mehreren möglichen Aktionen ausgelöst.

Wegen der notwendigen Rate halte ich nicht viel davon, das direkt an den Raspberry zu koppeln. Ein kleiner Arduino Micro für 10 € dazwischen macht nur die Bussuche und hat die zulässigen IDs hart codiert.

Dieses System kommt bei mir inzwischen an 3 Stellen zum Einsatz (jeweils mit einem echten iButton-Leser): Garagentor, Hoftür und Haustür.

Die Anwendung für Garagentor und Hoftür habe ich im SmartHome Hacks-Buch beschrieben, die für die Haustür hier: http://www.fhemwiki.de/wiki/DoorPi_und_FHEM

Der einzige Unterschied ist, dass bei den echten iButtons der physische Kontakt zum Reader hergestellt werden muss. Dafür aber sind sie nicht im Vorbeigehen auslesbar.

Für ein sicherheitskritisches System eignet sich das natürlich nur bedingt, ist eben wegen der prinzipiellen Fälschbarkeit der iButtons und RFID-Karten nicht sicherer, als der gute alte Hausschlüssel. Darum wird das bei der Haustüranwendung mit der PIN kombiniert.

LG

pah

[ext23]

Was pah sagt ist aber wichtig, "Am Vorbeigehen auslesen"... das ist genau das Problem bei RFID wenn man nur mit der (U)ID arbeitet, passiert beim iButton nicht. Der verhält sich wie ein echter Schlüssel und kann nur kopiert werden wenn man ihn aus der hand gibt. (Natürlich die Seriennummer abkratzen vom iButton )

/Daniel

[Skusi]

@pah

Ich habe den Wiki Eintrag gelesen. Sehr interessant. Die Variante mit den Ibuttons ist auch klingt gut.
Ich habe hier auch noch ein paar Arduino Nanos rumliegen. Ich könnte also den 1Wire RFID Leser oder einen iButton Reader an diesen Nano anschließen. Welchen sketch flashe ich dann auf den Nano ?
Geht das über die Configurable Firmata und OWX in Fhem ?

Oder brauche ich einen speziellen Sketch der auf dem Arduino ständig nach neuen Devices sucht ?

Das ganze vom Raspberry fern zu halten finde ich schonmal eine gute Idee. Nun bin ich aber nicht der Arduino Programmier- experte und brauche da mal Unterstützung.

Ich hab gesehen das Du auf deinen Arduino´s einen eigenen Sketch geflasht hast, der unter anderem die iButtons ausließt. Cool wäre also eine abgespeckte Fassung ohne die Display Steuerung.
Eine Duo Led wäre auch noch fein, um den Status anzuzeigen. Also über einen DO ansteuerbar aus Fhem.

Was ich noch nicht begriffen habe ist wie ich dann ein Event in Fhem bekomme wenn ein iButton gelsesen wird, und wie dessen ID ist.

[Prof. Dr. Peter Henning]

Welchen sketch flashe ich dann auf den Nano ?

Geht das über die Configurable Firmata und OWX in Fhem ?

Oder brauche ich einen speziellen Sketch der auf dem Arduino ständig nach neuen Devices sucht ?

Was ich noch nicht begriffen habe ist wie ich dann ein Event in Fhem bekomme wenn ein iButton gelsesen wird, und wie dessen ID ist.

1. Sketch "Garagentoröffner" steht mit Erläuterung im SmartHome-Hacks Buch, zum Download auf http://ice-karlsruhe.de/projekte/smarthome/smarthome-hacks-links-und-ergaenzungen/
2. Nein.
3. Ja, genau das macht er, ist also ein eigener Busmaster. Hat auch die IDs drin.
4. Kann man an einen beliebigen Tastensensor anschließen - z.B. an ein entsprechendes HomeMatic-Modul. Prinzipiell auch denkbar, ihn nach "innen" hin auch noch als 1-Wire-Device laufen zu lassen.

LG

pah

[Skusi]

@pah

Hallo Peter,

nun ist schon ne Menge Zeit vergangen, aber wie das so ist, das Hobby steht ganz hinten an. Nun da ich nach einer Hand OP zu Hause sitzen muß, habe ich viel Zeit und deshalb bin ich Deinen Tips endlich nachgekommen. Ich habe heute erfolgreich einen Arduino Nano mit deinem Garagentor Sketch gefüttert, es etwas abgeändert und es läuft super.
Ich kann also nun meine 10 IButtons am autark laufenden Nano einlesen und per LED Farbe signalisieren ob sie berechtigt sind oder nicht.
Soweit schon echt Klasse, danke schon mal für die Starthilfe.

Nun muß ich die Sache noch irgendwie in Fhem integrieren sodass ich meine Alarmanlage damit scharf/unscharf schalten kann und der aktuelle Status über die im IButton Leser integrierte LED angezeigt wird.

Am liebsten wäre mir wenn ich die digital Pins die in dem Sketch zur Unterscheidung der Buttons verwendet werden (9-11) über Fhem abfragen könnte, bzw ein Notify darauf horchen würde. So könnte ich über die Kombination dieses 3 Bit verfahrens immerhin 8 Buttons unterscheiden.

Da aber ja auf dem Nano kein Firmata sketch drauf ist, weiß ich nicht wie ich das bewerkstelligen soll.

Meine laienhafte Idee ist nun einen zweiten Nano mit LanFirmata (Lan ist in der Nähe) oder auch USB Firmata (Raspberry ist auch erreichbar) oder sogar GPIO vom Raspberry  zu benutzen, und die Pins 9-11 des Auswert-Nanos mit 3 Digital Inputs des zweit Nanos (Raspberry) zu verbinden um diese dann abzufragen.

Ist sicherlich eine Holzhammer Methode und nicht wirklich elegant, könnte aber funktionieren. Mit ist hals auch wichtig das ich unterscheiden kann welcher Button benutzt wurde.

Prinzipiell auch denkbar, ihn nach "innen" hin auch noch als 1-Wire-Device laufen zu lassen.

Was genau meinst Du damit ? Siehst Du noch eine schönere Möglichkeit mein Ziel zu erreichen

Gruß Skusi

[Skusi]

Ich weiß, das es nun langsam off-topic wird, aber ich weiß nicht wie man das Thema ändert.

Ich habe nun mal die Geschichte auf einem Breedboard aufgebaut. Funktioniert auch soweit.
Ich frage mich nun ob ich beim Verbinden den D Pins des einen Arduino zu dem zweiten, der dann die Firmata Auswertung macht noch Hardware dazwischen schalten sollte.

Da beide Arduinos von der Selben Spannungsquelle versorgt werden kann ich die Pegel doch einfach verbinden oder ?
Ein Optokoppler dazwischen macht doch keinen Sinn - oder ?

Komisch ist das ich in der Leitung von DO Arduino1 zu DI Arduino2  ca 40 mA messen kann wenn der Pegel auf High geht. Ist das nicht einwenig viel ?

Bin mir unsicher ob die Geschichte so auch lange durchhält. Schöner wäre halt eine elegantere Lösung die Schlüssel in Fhem mit zu loggen ...

[blade-of-fire]

Hallo Skusi,

ich bin an einer sehr ähnlichen Stelle wie du.
Ich habe den Garagentor-Sketch auf meinem Nano angepasst und geflasht und kann damit meine iButtons auslesen. Mir fehlt jetzt nur noch die Verbindung zu FHEM. Es muss doch irgendwie möglich sein, die OneWire-Informationen über ConfigurableFirmata an FHEM zu senden und da zu verwalten. Ich habe mich noch nicht näher mit dem Quellcode der ConfigurableFirmata auseinander gesetzt, aber grundsätzlich ist ja die OneWire-Funktion gegeben. Wenn ich allerdings an einen OWX-Device "get devices" schicke, bekomme ich nur die Meldung "OWX: 1-Wire devices found on bus OWio5 ()".

Deine angedachte Lösung, einen 2. Arduino zu nehmen, finde ich ganz gut, vor allem wenn es darum geht, den Arduino zur Zutrittsberechtigung zu nutzen. Für meinen Anwendungsfall allerdings möchte ich das Ganze nur zu Anwesenheitserkennung in Form eines digitalen Schlüsselbretts nutzen und finde einen 2. Nano dann doch überflüssig.

Konntest du deine Testaufbau weiter testen?

Viele Grüße,
Blade

[fstefan1960]

Hallo,

ich habe gerade Tage damit verbracht, genau diesem Phänomen nachzugehen. Die aktuelle ConfigurableFirmata wird von FHEM nicht unterstützt. Es darf max. die 2.06 sein. Siehe dazu den Thread https://forum.fhem.de/index.php/topic,67196.0.html.
Als ich die geflasht habe, kam ich dann weiter.

[blade-of-fire]

Vielen Dank für die Info.
Ich hatte gestern schon deinen Thread entdeckt und auch deine Lösung erfolgreich getestet. Ich verstehe allerdings nicht so ganz, wieso diese Funktionalität in den neueren Versionen nicht auch gegeben ist.

Nach ein paar Tests muss ich allerdings sagen, dass ich das erkennen der iButtons sehr träge empfinde. Auch wenn man die Intervalle auf den niedrigsten Wert stellt (OWX->15, OWID->1), wird der Zustand nicht innerhalb dieser Intervalle aktualisiert. Wenn der iButton eine Weile entfernt wurde, wird der ganze OWID-Device entfernt, bei neu Anlegen wird dann wieder der Standardinterval-Wert (300) verwendet.
Ich glaube, für mich kommt in dem Fall dann nur in Frage, doch einen 2. Nano zu verwenden, der mit einem eigenen Sketch bespielt wird, der sich nur um die iButtons kümmert und mittels der digitalen Kanäle den Status an einen den ersten Nano übergibt.
Wenn es dahingehend bessere Vorschläge gibt, bin ich daran sehr interessiert. Ich muss dazu sagen, dass ich mich erst seit wenigen Tagen mit 1-Wire beschäftigt habe und daher noch am lernen bin, wie das alles funktioniert.

Gruß,
Blade

[blade-of-fire]

Ich habe noch ein wenig rumprobiert.

Wenn ich den OWID-Eintrag manuell anlege, wird er nicht gelöscht. Soweit, so gut.
Wenn man nun mittels AT den owx zyklisch abfragt, funktioniert das erkennen der iButtons ganz gut.
Jetzt habe ich aber eine Frage, die nichts direkt mit 1-Wire zu tun hat.
Bei allen get-Befehlen, wird immer ein Log-Eintrag mit dem Ergebnis angelegt. Bei einem Abfrageinterval von 5 Sekunden lässt das das Logfile in kurzer Zeit immens anwachsen. Kann man den Log-Eintrag irgendwie unterbinden? Ich habe danach schon hier im Forum gesucht und auch gegooglet, hab allerdings nichts gefunden.

Danke schonmal.

[blade-of-fire]

Hallo zusammen,
ich bin mit dem Auslesen der iButtons immer noch nicht zufrieden.
Beim durchschauen der ConfigurableFirmata ist mir aufgefallen, dass in der Loop zum Beispiel die DigitalInputs per Report abgefragt werden. Onewire ist in der Loop nicht zu finden. Könnte man das dort nicht auch noch implementieren? Ich kenne mich mit der Syntax der Arduino-Sketche leider zu wenig aus. Die OnewireFirmata-Bibliothek enthält leider keine Routine "report" so wie die anderen Bibliotheken.

Es wäre doch in meinen Augen am besten, wenn das erkennen eines iButtons vom Arduino gepusht wird und nicht vom OWX abgefragt werden muss. Es gibt ja auch iButtons, die nur kurz vor den Leser gehalten werden. Diese würden in der kurzen Zeit ja dann niemals erkannt werden.

Viele Grüße,

Blade

[Prof. Dr. Peter Henning]

Vlt. etwas mehr Grundlagen anlesen, insbesondere was das "Pushen" von Events angeht.

Ich kenne mich mit der Syntax der Arduino-Sketche leider zu wenig aus

Wenn da schon "leider" steht: Diesem bedauerlichen Umstand kann man doch durch das Erlernen abhelfen, oder ? So haben wir es jedenfalls gemacht, ich wüsste nicht, dass das inzwischen nicht mehr geht.

LG

pah

[blade-of-fire]

Dagegen möchte ich mich auch gar nicht wären. Es geht mehr darum, dass es ja vielleicht einen besonderen Grund gibt, warum Onewire nicht in der Loop abgefragt wird, der sich mir im Moment nicht erschließt.
Im Thread https://forum.fhem.de/index.php/topic,67196.0.html wurde ja bereits erklärt, dass ab der ConfigurableFirmata Version 2.0.6 die Abfrage der iButtons gar nicht mehr funktioniert, was ich auch bestätigen kann. Ich konnte aber nirgends eine Begründung dafür finden.

Im Thread https://forum.fhem.de/index.php/topic,66567.0.html geht es quasi um das gleiche Thema (Habe ich eben erst entdeckt). Ist es überhaupt realistisch, mein Vorhaben mit dem Arduino und Configurable Firmata umzusetzen, oder sollte ich das besser mit einem DS2409 umsetzen?

Grüße,
Blade

[Skusi]

Hallo blade,

entschuldigt das ich mich erst jetzt wieder melde, aber ich hatte den Thread aus den Augen verloren.

Sehr interessant heir zu lesen was Ihr so für Lösungsansätze ausprobiert habt. Ich habe es letztendlich dann so realisiert das ich den sketch von pah (vielen dank an dieser Stelle) angepasst und auf einen Nano geflasht habe. An diesem Nano ist dann nur der Ibutton Leser dran und der sketch testet 4 x pro sek ob eine Button da ist.

Ist eine Button erkannt, wird dessen Id mit der hard codierten Liste verglichen und bei Übereinstimmung werden entsprechende DO Pins geschaltet.

Ich habe dazu Pins für "OK", "nicht OK", Bit1, Bit2, Bit3 definiert.

Diese Pins sind mit DI Pins eines zweiten Nano verbunden auf dem eine Configurabel Firmata geflasht ist. Bei anhalten eines berechtigten Buttons wird dann der OK Pin und eine Kombination der Bit1-3 Pins abhängig von der erkannten ID für 1 sek gesetzt.

Diese Statusänderungen werte ich dann per FRM in Fhem aus, und kann so Aktionen auslösen und durch die Bits den gelesenen Schlüssel zuordnen.

Zusätzlich schalte ich dann über den Nano mit Firmata noch die LED im Leser um den Status der Alarmanlage anzuzeigen.

Für mich wichtiger Vorteil: Keine große Last auf Fhem, da das Suchen nach Buttons im 250 msek Takt autark im Arduino passiert.

Läuft sehr gut und Störungsfrei sei gut 3 Monaten.
Und sogar der WAF Faktor ist recht hoch !

---Skusi

[blade-of-fire]

Hallo Skusi,

kein Problem, das kenne ich nur zu gut.

Die Idee klingt echt gut. Ich werde das ganze aber wohl in einer leicht abgewandelten Variante realisieren.
Grundsätzlich finde ich die Firmatafunktionen sehr gut, daher möchte ich sie auch beibehalten.
Die Informationen direkt per IO-Schaltzustände zu übermitteln wäre zum jetzigen Zeitpunkt auch bei mir noch möglich, allerdings wäre ich somit auf meine 2 iButtons beschränkt, also zumindest in meinem Szenario.
In meinem Fall dient der iButton ja gleichzeitig als Schlüsselhalter. Wenn die beiden Bewohner zuhause sind, werden also beide Reader dauerhaft blockiert. Sollten mir nun weitere Anwendungsfälle für weitere iButtons einfallen, müsste ich da wieder umplanen.
Daher werde ich mir mit dem MQTT-Protokoll auf einem 2. Arduino die jeweilige iButton-SN an FHEM senden und dann per FRM die LEDs-Schalten. Somit kann ich beliebig viele iButtons verwenden.

Viele Grüße,
Blade

[Spielmann]

hallo blade-of-fire (noch etwas off Topic)
vor einem Jahr habe ich eine Tankstellensteuerung mit der configurablen Firmata in Betrieb genommen ( https://forum.fhem.de/index.php/topic,51840.msg441137.html#msg441137 ). Das System ist produktiv - läuft jedoch nicht immer stabil und suche nach einer besseren Lösung. Ein Arduino mit der configurablen Firmata war damals für mich eine optimale Lösung (1wire,IOs,LCD... per Netzwerk ansteuerbar). Das MQTT Protokoll in Verbindung mit einem ESP macht einen stabileren Eindruck und erkennt den iButton mit dem sketch von lenoxef superschnell (wie wir unter https://forum.fhem.de/index.php/topic,67427.30.html herausgefunden haben). Zudem wird die Verbindung nach einem Spannungsaufall nach Sekunden wieder aufgebaut.
Ich versuche in allen Richtungen mein Ergebnis zu verbessern. Falls nötig werde ich zunächst parallel den configurablen firmata Arduino mit dem ESP betreiben und dann möglichst viele Funktionen auf den ESP übertragen.
Leider sind diese Arduino-Sketche für einen Laien schon sehr anspruchsvoll und schwer zu verstehen. Ich würde es toll finden, wenn es irgendwann mal ein configurable mqtt auf einen Arduino oder ESP geben würde (man darf ja träumen).

Zum Thema iButton erkennen. Die ID der Buttons wird  angezeigt bzw. beim Erkennen wird ein OWID mit ID angelegt. Ich habe das so getan:

Code Auswählen Erweitern


define Reader OWX_ASYNC 43
attr Reader IODev FIRMATA
attr Reader interval 1

dann alle 2s pollen mit:
define Abfrage at +*00:00:02 get Reader devices
attr Abfrage verbose 0

und die erkannten OWIDs werden den Dummys Schluessel und Schluessel_ID zugeordnet (3 Buttons im Beispiel):
define iButton1.present notify OWX_01_123456780000:present.*1 IF ([Schluessel:state] eq "off") (set Schluessel on , set Schluessel_ID 1)
define iButton2.present notify OWX_01_234567890000:present.*1 IF ([Schluessel:state] eq "off") (set Schluessel on , set Schluessel_ID 2)
define iButton3.present notify OWX_01_987654320000:present.*1 IF ([Schluessel:state] eq "off") (set Schluessel on , set Schluessel_ID 3)


Ich lege zwar immer nur ein iButton an, jedoch dürfte es doch kein Problem sein auf einem Bus mehrere Buttons parallel zu betreiben.


Gruß
Spielmann

[blade-of-fire]

Hallo Spielmann,
ich betreibe die iButtons ja bereits schon mit FRM bzw. OWX. Grundsätzlich funktioniert das ganz gut, allerdings habe ich das Problem, dass er bei mir beim Pollen durch den OWX jedesmal einen Logeintrag erzeugt.
Da ich 2 iButton-Reader an getrennten IOs habe, bekomme ich jedesmal 2 Log-Einträge. Ich habe die Reader bewusst an 2 unterschiedlichen IOs, damit ich zuordnen kann, an welchem Reader welcher Button hängt.
Das ganze ist bei mir noch mit einem Bewegungsmelder gekoppelt, sodass die Log-einträge nur stattfinden, wenn Bewegung erkannt wurde. Es summiert sich aber dennoch und ich finde das einfach unschön.
Ich habe auch schon mit den Logleveln rumgespielt und einen Extra Thread dazu aufgemacht, aber ich bekomme diesen Log-Eintrag beim "get reader devices" einfach nicht weg. Außerdem denke ich, dass das Pollen durch FHEM nicht unbedingt die eleganteste Variante ist. Das sollte lieber der Arduino machen und den Status an FHEM pushen.

Der einzige Unterschied bei meinem Szenario ist, dass ich OWX und nicht OWX_ASYNC verwende.

Gruß,
Blade