Readme und Wiki überarbeiten about doorpi HOT 19 CLOSED

kann dir gerne helfen. welche Teile sollten denn im speziell zuerst überarbeitet werden?

from doorpi.

Eigentlich einmal alles und zwar so, dass es nicht nur der Entwickler versteht.

1. Die Readme.md sollte überarbeitet werden und das Projekt beschreiben und nicht meine Umgebung zu Hause.
2. Die Installationsanleitung sollte zweisprachig vorhanden und auf einem aktuellen Stand sein.
3. Die Ersteinrichtung sollte genauer beschrieben sein (z.B. Config anpassen).
4. die Konfigurationsmöglichkeiten sollten besser / überhaupt beschrieben werden
5. Zu Schluss noch eine FAQ aus den Issues die mit FAQ markiert sind - kurz Problem (Fehlermeldung) und Lösung dazu.

DoorPi ermöglicht mit der Config-Datei so viel, aber nur ein Bruchteil ist beschrieben und aktuell.
Wenn ich die Doku schreibe, dann verstehe ich es - aber in einigen Fällen kein Anderer.

Wenn die Readme fertig wäre, dann würde ich daraus gern eine Seite erzeugen lassen (https://pages.github.com/) und dort versuchen es übersichtlich zu gestalten.

from doorpi.

https://github.com/Schwa-l-be/DoorPi/wiki/Installation-DE

ein Vorschlag zur Installationsanleitung auf Deutsch.
Sollte das ganze noch ausführlicher sein oder ist das ok?

from doorpi.

Du musst noch ein chmod +x doorpi.sh setzen
Sonst kannst du es nicht ausführen

Lg

from doorpi.

geändert.

Sollt DoorPi wie im Skript unter /home/DoorPI installiert werden oder wie zu Beginn unter /home/pi/DoorPi?

from doorpi.

WOW - ich bekomme die Kinnlade nicht mehr zu. Wie lange war ich weg?
Super Leistung!

from doorpi.

@Schwa-l-be Kannst Du mir bitte eine Mail an [email protected] schicken? Danke...

from doorpi.

Hallo , vielleicht könnte man in das Installations Todo noch optional den download aus der konsole anbiten, somit fält FTP und sonstiges flach.

wget http://raspberrypi.roxxs.org/EPSPi/packs/DoorPI.sh

from doorpi.

Bezüglich der config Datei: wird sich nach Umsetzung von issue #54 viel ändern, so dass es sich lohnt zu warten oder bleibt der Großteil gleich?

from doorpi.

Inhaltlich bleibt alles gleich. Problem aktuell ist, dass die Leute die fertige cfg nicht anpassen und dann sich fragen, warum es nicht geht. Deshalb soll die cfg gelöscht werden und es werden demo.cfg bereit gestellt. Aus den ganzen Demo-cfg kann sich dann jeder seine eigene cfg zusammenbauen.
Also bleibt die cfg inhaltlich gleich, sowohl Aufbau als auch Parameter. Somit kann auch die Doku dafür gleich bleiben, es kommt nur der Hinweis auf die Demo-cfgs dazu.
Oder stellen wir die demo-Konfigurationen komplett nur ins Wiki und man muss die sich dann von dort rauskopieren?

from doorpi.

Ich hoffe ja mal dass die Leute die DoorPi installieren wollen das Wiki auch lesen und somit sollte es meiner Meinung ausreichen, dort die Demo-Konfig zu beschreiben.
Dadurch dass sie sich bereits beim konfigurieren mit dem Wiki auseinander setzen, könnte helfen, dass auch das FAQ benutzt wird bevor gefragt wird.

from doorpi.

Und das auch aufs Wiki verwiesen wird, kann ich im Quellcode mit entsprechenden Fehlermeldungen verankern. So sollte es klappen... (#56)

from doorpi.

Jetzt muss ich mal nachfragen...
Wollte gerade am Konfig Wiki was tun aber versteh die virtuelle Tastatur nicht :D
Wenn ich jetzt Pin 5 für 3 Sekunden schalten will wie muss ich das dann definieren?

from doorpi.

Du musst einen einen passenden OutputPin definiere, z.B.

[boardgpio_OutputPins]
5 = Tueroeffner

und dann mit einer aktion diesen Pin zuerst auf 1 und dann auf 0 schalten, mit Verzögerung 3

... = out:Tueroeffner,1,0,3

Das kann passieren als DTMF Aktion

[DTMF]
"#" = out:Tueroeffner,1,0,3

aber genauso auf Knopfdruck eines Input Pins eines anderen keyboars

[rfidreader_InputPins]
1234567 = out:Tueroeffner,1,0,3

Zur Vollständigkeit halber noch meine Keyboard Definitionen

[keyboards]
boardgpio = gpio
rfidreader = rdm6300

from doorpi.

soweit klar nur wie sieht das ganze dann mit SSH Befehl aus wie in #36 ?
Also ich frag mich wie ich das damit anspreche

from doorpi.

Ach so, verstehe. Sorry, kenne die Historie aus #36 nicht so gut, aber nach dem, was ich gelesen habe, ist die Idee:

[keyboards]
virtuell = filesystem

#======== Config for Filesystem Keyboard =========
[virtuell_keyboard]
reset_input = true
base_path_input = /var/DoorPI/keyboard/inputs/
base_path_output = /var/DoorPI/keyboard/outputs/

[virtuell_InputPins]
tueroeffnertaste = out:Tueroeffner,1,0,3

und man muss den türöffnern mit folgendem Shell-Befehl über SSH betätigen:

echo 1 > /var/DoorPI/keyboard/inputs/tueroeffnertaste

from doorpi.

Ist so vollkommen richtig...

from doorpi.

Bezüglich Wiki, sollte unbedingt eine Anleitung bezüglich Absicherung (User/Group) vom Webinterface rein.

---> von motom001 gepostet am http://www.forum-raspberrypi.de:
Wenn es um eine Weboberfläche geht, dann sollte diese auch abgesichert sein.
Dazu gibt es Nutzer (User) die in Gruppen (Groups) zusammengefasst sind.
Diesen Groups sind Bereiche (AREA) zugeteilt, die lesend oder schreibend genutzt werden können.
Die Bereiche (AREA) sind virtuelle und reale Ressourcen, die sich speziell an der URL unterscheiden (daher kam auch die Idee es in Bereiche einzuteilen).
Die Bestandteile eines Bereiches werden mittels RegEx definiert.

Zuordnung in der Sektion User ist:
[Benutzername] = [Passwort]

Bei der Group Sektion ist es:
[GroupName] = [Benutzername1],[Benutzername2],[...]

Dann gibt es die beiden Sektionen WritePermission und ReadPermission mit der Zuordnung:
[GroupName] = [AreaName]

Ganz unten gibt es dann beliebig viele Areas mit unterschiedlichen Namen. Jeder Area sind RegEx zugeordnet, die gegen die URL geprüft werden.
Eine Sonderform ist die AREA_public. Diese fasst alle Ressourcen zusammen, die von jedem eingesehen werden dürfen, da es sich hierbei um Javascript,CSS und ähnliche Dateien handelt.
Nötig wurde das, da die login.html auch Javascript-Dateien geladen hatte. Mitlerweile habe ich mich von der login.html einw enig verabschiedet und bin Richtung HTTP Status-Code 401 mit base64 codiertem Benutzername/Passwort gegangen. Das lässt sich später auch automatisch durchführen, so dass Webservice-Aktionen mit Authentifizierung auf einem sehr einfachen standardisierten Level möglich sind.

Ist bestimmt nicht einfach meinen Quatsch-Gedanken zu folgen, zumal viel Salitos geflossen ist, während ich programmiere. Aber dafür klappt es ganz gut Icon_smile

Beispiel:

Code: Alles markieren
[User]
moto = moto
doorpiweb = doorpiweb
visitor = visitor
door = pi

[Group]
administrator = doorpiweb,motom001,moto,door
visitors = visitor

[WritePermission]
administrator = dashboard,status,config

[ReadPermission]
visitors = dashboard

[AREA_config]
/control/config_value_get
/control/config_value_set
/control/config_value_delete
/control/config_save
/control/config_get_configfile

[AREA_status]
/status
/mirror

[AREA_dashboard]
/dashboard/pages/.*html

[AREA_public]
/dashboard/bower_components/.*
/dashboard/dist/.*
/dashboard/js/.*
/dashboard/less/.*
/login.html
/favicon.ico

from doorpi.

Das Wiki kann jeder bearbeiten - kannste gern mit einfügen - wäre sogar sehr froh drüber.
Allerdings ist das eben noch nicht 100% fertig - ob Read und Write bleibt, weiß ich noch nicht.

from doorpi.