ja...
Auch wenn ich glaube, dass damit das Rad zum n-ten Male erfunden wird: So etwas sollte dann einfach als Client auf einen OWFS-Server zugreifen.
LG
pah
Client auf einen OWFS-Server
Das Thema ist für mich neu und ich würde gern mehr darüber erfahren.
Kannst Du mir passende Schlagworte oder Links geben um sich in das Thema einzulesen?
Danke..
Ja, bitte. Darf ich mal fragen welche Du bestellt hast?
Wieso sollte man hier einen OWFS Server auf dem Pi installieren wenn es DoorPi ebenfalls durch ein keyboard kann?
OK, also zum Mitschreiben:
iButtons (alle 1-Wire Devices) sind passiv. Sie warten, bis sie adressiert werden - und können dann ggf. weitere Daten liefern.
Wenn man iButtons zum Türöffnen verwenden will, müssen diese also in kurzen Abständen sozusagen gepollt werden. Die Regeln der Mensch-Maschine-Interaktion sagen hier ganz klar: Alles oberhalb von 0,4 Sekunden Responsezeit wird als unbefriedigend empfunden.
Pollen heißt genauer: Adressierungszyklus, also Suche, was auf dem Bus da ist. Ein Busmaster muss also in Abständen von < 0,4 Sekunden auf dem Bus nachsehen:
- Ist ein Device da ?
- Wenn ja, starte Adressierungszyklus (=64 Bit Code)
- Erst danach weiß der Busmaster, welches 1-Wire Device da ist.
Diese Adressierung ist zeitkritisch, es ist deshalb gewagt, so etwas in der Software auf einem Rechner mit mehreren anderen Aufgaben zu realisieren (Ansteuerung über GPIO-Ports des Raspberry Pi ist möglich, führt aber immer wieder zu Problemen). Besser ist immer die Verwendung eines dezidierten Busmasters DS2480B, der über eine serielle Schnittstelle angesteuert wird und einen Teil der Bussuche (=des Adressierungszyklus) selbst übernimmt.
Für FHEM habe ich vor 5 Jahren Frontend-und Backendmodule in Perl geschrieben, die diese Bussuche (mit und ohne DS2480B) durchführen und die Daten aller möglichen 1-Wire Devices auslesen. Das war eine Heidenarbeit, und an einer asynchronen Version hänge ich immer noch dran (Modulfamilie OWX, OWTHERM, OWID, OWAD, OWMULTI, OWSWITCH, OWCOUNT, OWLCD und OWVAR).
Es gibt aber schon seit langer Zeit OWFS (auch für den Raspberry Pi), das als separater Server (auch netzwerktransparent auf einer anderen Kiste) läuft und ebenfalls diese Arbeit durchführt. Und zwar mit ganz unterschiedlicher Hardware zur Busanbindung: via GPIO, via Busmaster USB/Seriell/I2C. Das zum zweiten Mal zu erfinden halte ich für kaum machbar.
Also Lösungsvorschlag in diesem Falle: Irgendwo einen OWFS-Server installieren, der den 1-Wire Bus bedient. Auf dieses OWFS dann per dezidiertem Python-Modul aus DoorPi zugreifen. So wird es auch im Konkurrenzprodukt für FHEM gemacht: Modul OWServer greift auf ein (lokales oder entferntes OWFS) zurück. Klar, dass meine Frontendmodule in FHEM auch damit zurecht kommen.
Die Alternative, die ich für die gegenwärtige Aufgabe bevorzuge: Busmaster ist ein kleiner Arduino Micro, mit dem ich Abfrageintervalle von 250 ms problemlos hinbekomme. Kommunikation des Arduino mit dem DoorPi z.B. über serielle Schnittstelle (wenn man das braucht) - oder einfach über GPIO (Signal "Button erkannt").
In meinem konkreten Fall bedient der Arduino auch noch das Display.
LG
pah
Konkurrenzprodukt für FHEM
Ich hoffe nicht, dass es zu einem Konkurrenz-Produkt wird und sehe noch deutliche Abgrenzungen zueinander. Ich hoffe eher auf langfristige Integration beider Systeme.
Ein Busmaster muss also in Abständen von < 0,4 Sekunden auf dem Bus nachsehen
Ich hätte nach der Doku erwartet / gedacht, dass der DS2480(B) bereits diese Aufgaben übernimmt.
dabei Teile des Timing sowie des Suchalgorithmus übernimmt.
Nei-en, Missverständnis.
OWX/OWServer sind Konkurrenzprodukte, nicht DoorPi und FHEM.
Wobei meine Frontendmodule auch mit OWServer als Backend zurecht kommen, nicht nur mit OWX. Das von den OWServer-Leuten gelieferte Frontend ist das "one-for-all" OWDevice.
ZitatIch hätte nach der Doku erwartet / gedacht, dass der DS2480(B) bereits diese Aufgaben übernimmt.
Nein, das macht er nicht. Und bei der Ansteuerung über USB/Serielle Schnittstelle kommt man kaum auf Intervalle < 1s.
Betreffend die Leseeinheiten: An Garage und Hoftür habe ich diese hier mit separater Tricolor-LED
http://www.fuchs-shop.com/de/shop/16/1/13372564/
Eigentlich hatte ich vor, an der Türstation diese hier zu verwenden (habe ich noch herumliegen):
http://www.fuchs-shop.com/de/shop/16/1/13372377/
Ist möglicherweise aber korrosionsanfällig.
LG
pah
Alles anzeigenOK, also zum Mitschreiben:
iButtons (alle 1-Wire Devices) sind passiv. Sie warten, bis sie adressiert werden - und können dann ggf. weitere Daten liefern.
Wenn man iButtons zum Türöffnen verwenden will, müssen diese also in kurzen Abständen sozusagen gepollt werden. Die Regeln der Mensch-Maschine-Interaktion sagen hier ganz klar: Alles oberhalb von 0,4 Sekunden Responsezeit wird als unbefriedigend empfunden.
Pollen heißt genauer: Adressierungszyklus, also Suche, was auf dem Bus da ist. Ein Busmaster muss also in Abständen von < 0,4 Sekunden auf dem Bus nachsehen:
- Ist ein Device da ?
- Wenn ja, starte Adressierungszyklus (=64 Bit Code)
- Erst danach weiß der Busmaster, welches 1-Wire Device da ist.
Diese Adressierung ist zeitkritisch, es ist deshalb gewagt, so etwas in der Software auf einem Rechner mit mehreren anderen Aufgaben zu realisieren (Ansteuerung über GPIO-Ports des Raspberry Pi ist möglich, führt aber immer wieder zu Problemen). Besser ist immer die Verwendung eines dezidierten Busmasters DS2480B, der über eine serielle Schnittstelle angesteuert wird und einen Teil der Bussuche (=des Adressierungszyklus) selbst übernimmt.
Für FHEM habe ich vor 5 Jahren Frontend-und Backendmodule in Perl geschrieben, die diese Bussuche (mit und ohne DS2480B) durchführen und die Daten aller möglichen 1-Wire Devices auslesen. Das war eine Heidenarbeit, und an einer asynchronen Version hänge ich immer noch dran (Modulfamilie OWX, OWTHERM, OWID, OWAD, OWMULTI, OWSWITCH, OWCOUNT, OWLCD und OWVAR).
Es gibt aber schon seit langer Zeit OWFS (auch für den Raspberry Pi), das als separater Server (auch netzwerktransparent auf einer anderen Kiste) läuft und ebenfalls diese Arbeit durchführt. Und zwar mit ganz unterschiedlicher Hardware zur Busanbindung: via GPIO, via Busmaster USB/Seriell/I2C. Das zum zweiten Mal zu erfinden halte ich für kaum machbar.
Also Lösungsvorschlag in diesem Falle: Irgendwo einen OWFS-Server installieren, der den 1-Wire Bus bedient. Auf dieses OWFS dann per dezidiertem Python-Modul aus DoorPi zugreifen. So wird es auch im Konkurrenzprodukt für FHEM gemacht: Modul OWServer greift auf ein (lokales oder entferntes OWFS) zurück. Klar, dass meine Frontendmodule in FHEM auch damit zurecht kommen.
Die Alternative, die ich für die gegenwärtige Aufgabe bevorzuge: Busmaster ist ein kleiner Arduino Micro, mit dem ich Abfrageintervalle von 250 ms problemlos hinbekomme. Kommunikation des Arduino mit dem DoorPi z.B. über serielle Schnittstelle (wenn man das braucht) - oder einfach über GPIO (Signal "Button erkannt").
In meinem konkreten Fall bedient der Arduino auch noch das Display.
LG
pah
So, jetzt mal langsam pah und ebenfalls zum mitschreiben,
die Erklärung ist wirklich super aber wir reden hier über eine Anwendung die nicht besonders zeitkritisch ist. Ich gebe Dir Recht das es komforttabler wäre wenn wir hier in Echtzeit bzw. < 0,4 sek. die Türe, oder was auch immer, geöffnet bekommt. Wir reden hier aber von 0,6 sek. Differenz, wenn es denn wirklich 0,6 sek. sind. Zu glauben dass dies ein Pi3 anhand der verfügbaren Rechenleistung nicht schaffen könnte ist so auch nicht wahr.
Ich unterstelle hier mal das in diesen 0,6 sek. keiner einen Schlüssel in das Schlüsselloch bekommt geschweige denn gedreht und wieder herausgezogen. Warum wird alles immer so kompliziert gehandhabt? Für jede popelige Anwendung einen eigenständigen Rechner hängen nur damit wir eine Ersparnis von +-0,6 sek. bekommen, wenn überhaupt.
Auch wenn jetzt manche denken werden es ist doch besser wenn alles separat und eigenständig ist damit die Ausfallwahrscheinlichkeiten reduziert wird das stimmt so aber oft nicht da, meistens, nicht alles redundant
abgesichert ist auch wenn es nur ein kleiner Netzwerk Switch, Accespoint oder USB-Hub ist, denn fällt eines dieser Geräte aus was ist dann, dann steht alles. Die Wahrscheinlichkeit das ein Gerät ausfällt erhöht sich exponentiell mit der Anzahl der eingesetzten Hardware. Oder möchtest Du die Logik auf die verschiedenen Geräte verteilen?
Wenn man unbedingt möchte könnte man sich ja einen 2. Pi zwischenrein setzen der dann bei einem Ausfall des 1. Pi alle funktionen übernimmt und, zusätzlich, eine Meldung an den Eigentümer versendet.
Es gibt immer zwei Seiten einer Münze und ich wollte hiermit nur mal klarstellen das nicht alles immer so toll ist wie es hier manche schreiben.
Da der Raspberry über GPIO4 einen vollwertigen 1-Wire Anschluss verfügt kann man hier auch sehr einfach auch 1-Wire Hardware verwenden und das bis zu 10 unterschiedliche 1-Wire Geräte. Es würden zwar wohl auch bis zu 15 Geräte angesprochen werden können doch das ist nicht zu empfehlen da hier die parasitäre Spannung von dem Pi wohl nicht ausreicht.
Ich bin etwas irritiert von dieser Antwort, weil sie mit meinem Post nicht viel zu tun hat. Vor allem verwechselt sie das zeitkritische Bustiming (das sich eben in einer Software-Emulation nicht genau genug realisieren lässt) mit der Frage, ob eine Response-Zeit von > 0,4 s akzeptabel ist.
Die Response-Zeit bemisst sich auch nicht bis zum Öffnen der Türe - sondern bis zum Eintritt überhaupt einer Reaktion, z.B. dem Aufleuchten der Tricolor-LED in der dem iButton zugeordneten Farbe. Natürlich kann man auch ein System bauen, dass das erst nach 4 Sekunden macht. Allerdings wird das außer beim Bastler nicht sehr viel Akzeptanz erzeugen. Das ist auch keine persönliche Meinung von mir, sondern bombenfest etabliertes Grundlagenwissen der Usabilty.
Dass Abfrageintervalle von 0,4 Sekunden mit dem RPi nur in Ausnahmefällen nicht hinzubekommen sind, ist ferner keine Frage der Rechenleistung. Sondern genau dieses kritischen Bustimings.
Vehement widerspreche ich, dass der RPi einen "vollwertigen 1-Wire Anschluss hat". Gerade das kritische Timing auf dem Bus verhindert, dass mehr als nur ein paar 1-Wire Devices an GPIO4 angeschlossen werden können - keineswegs die Spannung, und schon gar keine "parasitäre Spannung" - das ließe sich darüber hinaus mit einem Mosfet und drei Widerständen korrigieren. Auch solche Dinge wie erweiterte Reset-Pulse etc. werden nur von einem echten vollwertigen Busmaster gehandhabt. Tasache also: RPi mit GPIO4 ist eben KEIN vollwertiger Busmaster. An einem solchen Busmaster (z.B. dem DS25480B, der inklusive USB-Adapter für weniger als 20 € zu haben ist) sind nämlich bis zu 100 1-Wire Devices anschließbar.
pula: Schau mal hier, da ist alles, was man braucht: http://owfs.sourceforge.net/owpython.html
LG
pah
Das mit dem vollwertigem 1-Wire Bus nehme ich natürlich, so wie ich es geschrieben habe, zurück. Das wollte ich aber auch damit nicht sagen. Für die meisten Anwendungen ist dieser als, fast, vollwertig anzusehen. Ob es von nöten ist hier 100 1-Wire Devices an zu schließen vermag ich nicht zu sagen oder für andere zu sprechen aber auch hier denke ich das meisten User hier weniger brauchen oder bräuchten. Damit wäre das wieder ein Nice to have für eine Handvoll Nutzer aber wirklich benötigt wird es eher nicht in der breiten Masse der User die sich hier wiederspiegeln.
Wie Du schon, richtig, gesagt hast sind diese 0,4 sek. zeitkritisch aber diese Zeit wurde so gewählt um auch weiter entfernte 1-Wire Devices unterschiedlichster Hersteller zu finden. Das sollte auch ein Pi beherschen können. Das 1-Wire System basiert ja so auf eine ähnlich Art PWM nur misst ja hier der Pi die Zeit zwischen High und Low-Signal und da sind 0,4 sek. Welten.
Mir ist schon bewusst was hier mit Response Zeit gemeint ist. Nur wieviel Zeit verstreicht denn danach? Das abarbeiten eines solchen Befehles bzw. Dein umschalten der Tricolor LED geschieht, nach der Response Zeit, in der Regel in wenigen 100erstel sek. diese Zeit ist aber normalerweise gleich da hier die Logik der Pi übernimmt egal ob ein Busmaster oder ein Pi das Device sucht und findet. Das abarbeiten des scriptes übernimmt doch der Pi da in diesem ja die ID des Button abgelegt ist und auch hier wird erst verglichen ob die ID identisch ist oder auch nicht. Erst danach leuchtet doch Deine Tricolor LED anderst. Das mit den 4 Sekunden ist natürlich stark übertrieben und selbst wenn wie oft würde denn das passieren?
Wenn die Hardware bei mir angekommen ist und Pula hier das keyboard fertig gestellt hat werde ich mir ein solches System testweise mal aufbauen und meine Annahme bzw. These zu untermauern.
Das mit zusätzlicher Hardware sprich einem Mosfet hier die parasitäre Spannung stabilisierter wird bei mehreren 1-Wire Devices ist logisch und hättest Du nicht erwähnen müssen, die frage ist doch aber brauche ich so viel mehr solcher Devices? Wobei wir wieder bei der eigentlichen Frage sind "must have" oder ein "nice to have"?
Sollte sich herausstellen das ich hier einen groben Denkfehler habe oder auch nicht werde ich, natürlich, meine Beiträge anpassen bzw. ergänzen. Wie gesagt Hardware ist bestellt fehlt nur noch das Keyboard für die Anbindung an DoorPi und Zeit 
Gruß Andreas
Hallo zusammen
Ich war jetzt mal faul und habe einfach den I2C Adapter "RPI2" auf den Pi gesteckt: http://www.sheepwalkelectronic…t_info.php?products_id=30
Kein Basteln, Fummeln oder ähnliches. Funktioniert einfach. UART ist frei (den brauche ich für das Nextion). Den Rest macht OWFS (ohne den Webserver). Rein Theoretisch könnte man das sogar direkt als Filesystem Keyboard in DoorPi nutzen, da man owfs im Dateisystem mounten kann (fuse). Es wäre also nicht mal nötig ein Keyboard zu programmieren. Zumindest in der Theorie. Ausprobiert habe ich das aber bisher nicht, da es sich beharrlich weigert zu mounten. OWDIR, OWREAD etc. funktioniert einwandfrei.
Da ich den iButton ja nicht in DoorPi integrieren möchte, würde ich aber lieber das Python Modul nutzen, bin aber anscheinend zu doof das zu finden. War da schon jemand fündig?
P.S.: Thema mehrere Devices: Ich habe vor darüber mindestens noch 2 Temperatursensoren (einen in der Sprechstelle und einen innen im Pi Gehäuse) zu verbauen. Wenn ich es schaffe, wollte ich auch noch den Bewegungssensor und den Lichtsensor auf 1Wire umbauen, allein um Adern zu sparen.
Interessant 
Ich denke, sobald die iButtons da sind, werde ich das mal mittels Arduino und I2C anbinden - macht für mich persönlich am meisten Sinn, weil ich das sowieso schon auf dem Basteltisch habe und der Arduino das "bisschen" Mehrarbeit locker packen sollte. Nachdem, was @pahenning geschrieben hat und nach den Erfahrungen von @AndyGR42 erscheint mir das am einfachsten und vermutlich auch am stabilsten und billigsten...
Also, mit dem RPI2 läuft das wirklich super stabil. Zu meinem Glück fehlt mir nur noch einen Python (oder von mir aus auch C#, Pearl, oder weis der Geier) Bibliothek um ein passendes Programm zu schreiben.
BTW, pah hat in Sachen timing nicht ganz unrecht. Wenn da nur der Serial iButton am Bus hängt ist das sich kein Problem. Das Auslesen dauert wenige ms. Bei einem Temperatursensor aber schon mal gerne eine ganze Sekunde. So lange ist der Bus belegt. Bei mehreren Sensoren kann sich das schnell aufsummieren und in ungünstigen Fällen zu Verzögerungen führen.
OWFS arbeitet da mit einem Cache. Unterschiedliche Device Typen und Aktionen können im Cacheverhalten unterschiedlich konfiguriert werden. Das alles noch mal neu zu programmieren wäre in meinen Augen sinnbefreit. OWFS kümmert sich im Hintergrund um alles. Um das auslesen, Cache, timing, etc.
Ob man dafür nun eine zweite CPU einsetzt oder einen Adapter wie RPI2 / USB / UART ist in meinen Augen nicht so das Thema. Ein Adapter ist in meinen Augen einfacher.
Ich würde mich auf die beiden Punkte konzentrieren:
Zu meinem Glück fehlt mir nur noch einen Python ... Bibliothek
Sollte bei der Installation von OWFS mit dabei sein:
http://owfs.sourceforge.net/owpython.html
installiert unter (eventuell abweichende Python-Version):
/usr/lib/python2.3/site-packages/ow/__init__.py
Also in der Shell mal folgendes Probieren:
import ow
print "Installationsort: %s" % ow.__file__
ow.init('/dev/ttyS0')
for s in Sensor( '/' ).find( ):
print "- gefundener Sensor: %s" % s
ow.finish()Je nachdem wie Du die Verbindung hergestellt hast:
Alles anzeigen
init(iface)Initialize the OWFS library by specifying the interface mechanism
to be used for communications to the 1-wire network.
Examples:
ow.init( 'u' )
Will initialize the 1-wire interface to use the USB controller.
ow.init( '/dev/ttyS0' )
Will initialize the 1-wire interface to use the /dev/ttyS0 serial
port.
ow.init( 'remote_system:3003' )
Will initialize the 1-wire interface to use the owserver running
on remote_system on port 3003.
Danke für die Hilfe, aber irgendwie ist das nicht ans Laufen zu bekommen. Daher habe ich die Pakete von OWFS und Fuse runter geschmissen und die Quellen selbst kompiliert. Ich glaube, SWIG fehlte für owpython. Da scheint es bei owfs auf keine Abhängigkeit zu geben. Erst beim configure kommt die entsprechende Warnung. Welches Paket (fuse oder owfs) jetzt für das Problem mit dem mount verantwortlich war, kann ich nicht mehr sagen.
OWPHYTON ist jetzt vorhanden. Ausprobiert habe ich es aber noch nicht.
sudo apt-get install swig
https://github.com/libfuse/libfuse/releases
cd /home/pi/fuse-2.9.6/
sudo chmod 744 configure
./configure
make -j8
sudo make install
https://sourceforge.net/projects/owfs/files/owfs/3.1p1/
cd /home/pi/owfs-3.1p1/
sudo chmod 744 configure
./configure --enable-usb --enable-owpython --with-python=/usr/bin/python2.7 --with-pythonconfig=/usr/bin/python2.7-config
make
sudo make install
Ich kann nun ein 1-Wire über den I2C Bus ansprechen und mounten:
sudo /opt/owfs/bin/owfs --i2c=/dev/i2c-1:ALL /var/1wire
Auflisten:
sudo ls /var/1wire
28.FF0DE6711502 alarm bus.0 settings simultaneous statistics structure system uncached
Und auslesen:
sudo cat /var/1wire/28.FF0DE6711502/temperature
Allerdings lässt sich seltsamerweise USB nicht aktivieren, obwohl dazu keine Warnungen ausgegeben werden. Selbst wenn ich die Optionen und Module explizit angebe:
Current configuration:
Deployment location: /opt/owfs
Compile-time options:
USB is DISABLED
AVAHI is DISABLED
I2C is enabled
W1 is enabled
Parallel port DS1410E is enabled
Zeroconf/Bonjour is enabled
Debug-output is enabled
Mutexdebug is enabled
Profiling is DISABLED
Tracing memory allocation is DISABLED
Module configuration:
owlib is enabled
owshell is enabled
owfs is enabled
owhttpd is enabled
owftpd is enabled
owserver is enabled
owexternal is enabled
ownet is enabled
ownetlib is enabled
owtap is enabled
owmon is enabled
owcapi is enabled
swig is enabled
owperl is enabled
owphp is DISABLED
owpython is enabled
owtcl is DISABLEDDie einzigen Warnungen oder Fehler haben IMHO nix mit USB zu tun:
/bin/rm: cannot remove 'conftest*': No such file or directory
/bin/rm: cannot remove 'conftest*': No such file or directory
configure: WARNING: Cannot find php binary. Install php or php5 package
configure: WARNING: OWPHP is disabled because php binary is not found
configure: WARNING: Can't find Tcl configuration definitions
configure: WARNING: OWTCL is disabled because tclConfig.sh is not found
configure: WARNING: LD_EXTRALIBS= OSLIBS=
configure: WARNING: Cannot find libavahi-common
configure: WARNING: libavahi not found, avahi will be disabled
AVAHI und PHP kann ich auch deaktivieren, dann sind die Meldungen weg.
BTW, ein Python Code Sample: http://jack-kelly.com/getting_…_file_system_owfs_to_work
Hallo Zusammen,
ist einer von Euch schon weiter, die Lösung von pula, fand ich für mich ganz passend.
Eigenständig würde ich das niemals alleine schaffen, daher würde ich mich über einen Tipp freuen.
Herzliche Grüße aus der Eifel
Holger