RFID per 1Wire an Raspberry möglich ?

Begonnen von Skusi, 25 Oktober 2016, 20:08:42

Vorheriges Thema - Nächstes Thema

Prof. Dr. Peter Henning

Vlt. etwas mehr Grundlagen anlesen, insbesondere was das "Pushen" von Events angeht.
ZitatIch 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
VM mit Ubuntu und FHEM-Instanz (Hauptinstanz)
FHEM2FHEM
Raspberry Pi 3 B+ mit Eigenbau-Platine + Relais-Platine + Cul-Stick + FHEMDuino

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
RPI3B, SIGNALduino, NanoCul868 (a-culfw), JeeLink Clone (LaCrosse), Firmata  für FB Heizung,Wasser+Gas+Klingel+Lux, Somfy Rolladen, Pollin Steckd.,TX29DTH,ESPEasy an S0 Stromz., MAX Fensterkontakte, IButton, SonOff Tasmota, ESP LED Controler

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
VM mit Ubuntu und FHEM-Instanz (Hauptinstanz)
FHEM2FHEM
Raspberry Pi 3 B+ mit Eigenbau-Platine + Relais-Platine + Cul-Stick + FHEMDuino

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:


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

FHEM mit Raspi (Zentrale)
Raspberrymatic (Heizung)
Siemens LOGO8 (Lichtsteuerung)
Philips HUE Gedöns
Diesel-Tankstelle mit fhem und ESP (eine ewige Baustelle)

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

VM mit Ubuntu und FHEM-Instanz (Hauptinstanz)
FHEM2FHEM
Raspberry Pi 3 B+ mit Eigenbau-Platine + Relais-Platine + Cul-Stick + FHEMDuino