Weil ich bisher das Testprogramm händisch gestartet habe. Und ich dabei 2 Minuten lang den Inhalt der Datei als Antwort zurück bekommen habe, bis dann die Fehlermeldung kommt.
warum denke ich wieder an fflush :s oder fsync sync
Weil ich bisher das Testprogramm händisch gestartet habe. Und ich dabei 2 Minuten lang den Inhalt der Datei als Antwort zurück bekommen habe, bis dann die Fehlermeldung kommt.
warum denke ich wieder an fflush :s oder fsync sync
1wire-Ordner schneller löschen lassen? Schau mal ob du hier fündig wirst!
Hallo,
langsam bin ich am Ende. Ich schreibe noch mal ganz genau, was ich jetzt gemacht habe. Ich habe folgendes Programm (uebung.py) geschrieben:
#!/usr/bin/python
import time
n = 150
sum = 0
i = -5
while i <= n:
sum = sum + i
i = i + 5
zeit=time.strftime("%H:%M,%S")
#
#
print "Stoppzeit: ",i," Uhrzeit: ",zeit
pfad = "/sys/devices/w1_bus_master1/01-0000161f6f4e/"
dateiname="name"
datei = pfad+dateiname
in_file = open(datei,"r")
text = in_file.read()
in_file.close()
print text
pfad = "/sys/bus/w1/devices/01-0000161f6f4e/"
dateiname="name"
datei = pfad+dateiname
in_file = open(datei,"r")
text = in_file.read()
in_file.close()
print text
``time.sleep(5)``
print "regulaeres Ende"
Alles anzeigen
Meiner Meinung nach erfüllt das die Hauptforderung, dass eine Datei eines Sensors geöffnet wird, ausgelesen wird und wieder geschlossen wird.
Nun starte ich das Programm händisch und ziehe innerhalb der nächsten Sekunde den Sensor. Die Leitung zwischen Sensor-DATA und GPIO4 ist definitiv getrennt.
Als Ausgabe erhalte ich Folgendes:
./uebung.py
12:42,54
Stoppzeit: 0 Uhrzeit: 12:42,54
01-0000161f6f4e
01-0000161f6f4e
Stoppzeit: 5 Uhrzeit: 12:42,59
01-0000161f6f4e
01-0000161f6f4e
Stoppzeit: 10 Uhrzeit: 12:43,04
01-0000161f6f4e
01-0000161f6f4e
...
Stoppzeit: 95 Uhrzeit: 12:44,29
01-0000161f6f4e
01-0000161f6f4e
Stoppzeit: 100 Uhrzeit: 12:44,34
01-0000161f6f4e
01-0000161f6f4e
Stoppzeit: 105 Uhrzeit: 12:44,39
Traceback (most recent call last):
File "./uebung.py", line 23, in <module>
in_file = open(datei,"r")
IOError: [Errno 2] No such file or directory: '/sys/devices/w1_bus_master1/01-0000161f6f4e/name'
Alles anzeigen
Und das kann ich wiederholen, so oft ich will. Es ist immer exakt diese Zeit, also immer zwischen 100 und 105 Sekunden nach der Trennung des Sensors. Auch wenn ich die Abfragefrequenz der Temperatursensoren erhöhe, ändert sich nicht diese Zeit. Das hat offensichtlich keinen Einfluss (wie wir weiter vorn vermutet hatten).
Wenn bei diesem Programm bei euch die Fehlermeldung schneller kommt, muss bei mir noch etwas anderes wirken, was ihr nicht habt. Anders kann ich es mir nicht mehr erklären.
EDIT:
Ich habe das ganz genau so mit einem Temperatursensor gemacht, also auch den Inhalt seiner Datei Name ausgelesen. Es verhält sich bei mir ganz genau so, es gibt keinen Unterschied zwischen Temperatur- und Adress-Sensor.
PHP neigt auch dazu einem solche Streiche zu spielen.
Da ist manchmal http://php.net/manual/de/function.clearstatcache.php eine Abhilfe.
Vielleicht gibts für/in Python ja was vergleichbares....
Hallo docadams.
Ich habe mal Dein aus #36 Programm genommen und für meinen DS2401 umgestrickt und laufen lassen.
Was soll ich sagen... nu steh ich auch da und weiss nicht weiter.
Ob C oder Python ist (muss ja auch) egal.
Es reagiert wie erwartet.
Ob im 5, 10 oder x sec Zyklus, wenn ich ziehe ist er sofort beim nächsten Zyklus weg.
Wenn nicht, wäre das da wider jeder Logik.
Wenn ich ein Proggi brauche, das zB. im 5sec Takt diesen Sensor überwachen müsste, und der aber nach ~100 sec reagiert...kann ich gleich aufhören...
ZitatWenn bei diesem Programm bei euch die Fehlermeldung schneller kommt, muss bei mir noch etwas anderes wirken, was ihr nicht habt. Anders kann ich es mir nicht mehr erklären.
Das wäre ne Möglichkeit.
Mal dumme Frage... läuft bei Dir irgendwas im Hintergrund, das dieses 1-wire Modul blockiert oder sowas....wie auch immer...
Aber ansonsten muss ich jetzt auch passen, warum das bei Dir anders ist.
gruß root
Tja, hier kommen jetzt alle meine Sünden des letzten Jahres zum Vorschein:
ps -ax
warning: bad ps syntax, perhaps a bogus '-'?
See http://gitorious.org/procps/procps/blobs/master/Documentation/FAQ
PID TTY STAT TIME COMMAND
1 ? Ss 0:02 init [2]
2 ? S 0:00 [kthreadd]
3 ? S 0:01 [ksoftirqd/0]
5 ? S< 0:00 [kworker/0:0H]
7 ? S 0:07 [rcu_preempt]
8 ? S 0:00 [rcu_bh]
9 ? S 0:00 [rcu_sched]
10 ? S< 0:00 [khelper]
11 ? S 0:00 [kdevtmpfs]
12 ? S< 0:00 [netns]
13 ? S< 0:00 [writeback]
14 ? S< 0:00 [bioset]
15 ? S< 0:00 [crypto]
16 ? S< 0:00 [kblockd]
17 ? S 0:00 [khubd]
19 ? S< 0:00 [rpciod]
20 ? S 0:00 [khungtaskd]
21 ? S 0:00 [kswapd0]
22 ? S 0:00 [fsnotify_mark]
23 ? S< 0:00 [nfsiod]
29 ? S< 0:00 [kthrotld]
30 ? S< 0:00 [VCHIQ-0]
31 ? S< 0:00 [VCHIQr-0]
32 ? S< 0:00 [VCHIQs-0]
33 ? S< 0:00 [iscsi_eh]
34 ? S< 0:00 [dwc_otg]
35 ? S< 0:00 [DWC Notificatio]
37 ? S< 0:00 [deferwq]
38 ? S 0:02 [kworker/u2:2]
39 ? S 2:33 [mmcqd/0]
40 ? S 0:00 [jbd2/mmcblk0p2-]
41 ? S< 0:00 [ext4-rsv-conver]
156 ? Ss 0:00 udevd --daemon
664 ? S 3:44 [w1_bus_master1]
871 ? Ss 0:00 sshd: pi [priv]
887 ? S 0:00 sshd: pi@pts/0
888 pts/0 Ss 0:01 -bash
1011 pts/2 S+ 0:00 sleep 1
1012 pts/0 R+ 0:00 ps -ax
1604 ? S 0:03 /usr/sbin/ifplugd -i lo -q -f -u0 -d10 -w -I
1666 ? S 0:13 /usr/sbin/ifplugd -i eth0 -q -f -u0 -d10 -w -I
1942 ? Sl 0:14 /usr/sbin/rsyslogd -c5
2007 ? Ss 0:00 dhclient -v -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases eth0
2036 ? Ss 0:02 /usr/sbin/apache2 -k start
2074 ? S 0:00 /usr/sbin/apache2 -k start
2075 ? S 0:00 /usr/sbin/apache2 -k start
2077 ? S 0:00 /usr/sbin/apache2 -k start
2078 ? S 0:00 /usr/sbin/apache2 -k start
2084 ? S 0:00 /usr/sbin/apache2 -k start
2096 ? Ss 0:00 /usr/sbin/cron
2104 ? Ss 0:00 /usr/bin/dbus-daemon --system
2165 ? Ss 0:03 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -c /var/lib/ntp/ntp.conf.dhcp -u 102:104
2214 ? Ss 0:00 /usr/sbin/sshd
2248 ? Ss 0:00 /usr/sbin/thd --daemon --triggers /etc/triggerhappy/triggers.d/ --socket /var/run/thd.socket --pidfile /var/ru
2297 ? S 0:00 udevd --daemon
2300 ? S 0:00 sudo python /home/pi/skripte/taster/shutdown.py
2302 ? Ss 0:00 startpar -f -- rc.local
2306 ? S 0:00 udevd --daemon
2324 ? S 0:06 python /home/pi/skripte/taster/shutdown.py
2359 tty1 Ss+ 0:00 /sbin/getty --noclear 38400 tty1
2360 tty2 Ss+ 0:00 /sbin/getty 38400 tty2
2361 tty3 Ss+ 0:00 /sbin/getty 38400 tty3
2362 tty4 Ss+ 0:00 /sbin/getty 38400 tty4
2363 tty5 Ss+ 0:00 /sbin/getty 38400 tty5
2364 tty6 Ss+ 0:00 /sbin/getty 38400 tty6
2365 ? Ss+ 0:00 /sbin/getty -L ttyAMA0 115200 vt100
2417 ? S 0:00 /usr/sbin/apache2 -k start
2419 ? S 0:00 /usr/sbin/apache2 -k start
2420 ? S 0:00 /usr/sbin/apache2 -k start
2421 ? S 0:00 /usr/sbin/apache2 -k start
2422 ? S 0:00 /usr/sbin/apache2 -k start
2577 ? Ss 0:00 SCREEN -S rollo /home/pi/skripte/fhem/./rollo-web.sh start
2578 pts/2 Ss+ 1:15 /bin/bash /home/pi/skripte/fhem/./rollo-web.sh start
4477 ? S 0:00 [kworker/0:0]
11502 ? S 0:00 [kworker/u2:0]
18579 ? S 0:01 [kworker/0:2]
31586 ? Ss 0:00 sshd: pi [priv]
31591 ? S 0:00 sshd: pi@notty
31592 ? Ss 0:00 /usr/lib/openssh/sftp-server
31986 ? Ss 0:00 sshd: pi [priv]
31991 ? S 0:00 sshd: pi@notty
31992 ? Ss 0:00 /usr/lib/openssh/sftp-server
Alles anzeigen
Kann man da was erkennen?
Ich greife über Putty und WinSCP auf den RasPi zu. Ich brauche einen Webserver, mit dessen Hilfe ich eine Webseite mit den Zimmer- und Außentemperaturen angezeigt bekomme sowie eine Seite zur händischen Steuerung der Rollos. Es läuft permanent ein Script, mit dem ich einen Taster zum An-/Ausschalten des RasPis überwache (shutdown.py). Unter SCREEN läuft derzeit noch das Script zur webbasierten Steuerung der Rollos (im LAN), weil ich es noch nicht gepackt habe, das anders automatisch zu starten (Prozess 2577+2578). Etwas anderes fällt mir jetzt bewusst nicht ein, was ich gewollt nutze.
Dazu kenn ich Linux zu wenig, sag mir nicht viel.
Irgendwelche Prozesse, die da im Hintergrund laufen...
Ich würde mal folgendes machen.
Mach mit Win32DiskImager ein Image Deiner aktuellen SD.
Installiere nit Noobs ein neues System, lade nur das w1-Modul des DS2401, und starte dein Programm per Hand .
jar hat ja den Vorschlag mit fflush gemacht, aber warum geht das bei mir ohne ?.
Wenn es dann funktioniert, und es muss ja ... raspi ist raspi.. dann wäre geklärt, dass da was querschiest.
Neuinstallation dauert bißchen, aber was solls, must Du entscheiden.
gruß root
Hallo zusammen,
diesen Thread habe ich am Anfang verfolgt - und nicht so recht verstanden, warum hier ein Problem besteht. Wie bekannt, habe ich es nicht so mit Python. Aber folgende Zeilen
sind zu hinterfragen:
1. Was passiert, wenn die Datei nicht geöffnet werden kann? Ist in_file in diesem Fall definiert?
2. Wenn in_file nicht definiert ist, "scheitert" dann in_file.read() - und text ist undefiniert? Oder behält text den Wert, den es hatte, als in_file noch definiert war (die Datei geöffnet werden konnte)?
Ich könnte mir vorstellen, dass ein solches Verhalten durch irgendwelche Konfigurationen gesetzt werden könnte. Der eine hat irgendwas unwissentlich genauso gesetzt wie DocAdams, der andere hat eine andere Konfiguration bevorzugt - und kann das Verhalten nicht reproduzieren?
Wie gesagt, Python spricht nicht zu mir, aber in Icon programmiere ich es so:
text := &null # Text undefiniert
if in_file := open(datei, "r") then
{ text := read(in_file)
close(in_file)
}
Dann gibt es zwei Möglichkeiten für den Inhalt von text
text = &null ==> undefiniert, weil in_file nicht geöffnet werde konnte
text = Zeichenkette (Dateiinhalt)
Wenn die Datei das nächste Mal geöffnet werden soll, wiederholt sich das Spielchen. Auf diese Weise besteht nicht die Gefahr, das sich Variablen-Inhalte über die Lebenszeit von Dateien hinaus "am Leben" erhalten können.
Beste Grüsse
Andreas
Hallo,
ich kann es nur wiederholen: Danke für eure intensive Anteilnahme an meinem Problem. Alles, was ich hier so von mir gebe, ist eher eine Glaubenssache, weniger wissen. Es sind Gedankengänge eines Nichtprogrammierers.
Andreas,
mein Problem ist ja nicht nur, dass Variablen länger leben, als Dateien da sind, sondern, dass sogar die Dateien länger leben, als der Sensor aktiv ist. Ich glaube, das kann man mit keiner weiteren Programmiersprache lösen.
@root,
in mir ist heute Nacht auch der Gedanke gereift, noch mal richtig bei Null anzufangen. Neues System, nur die Dinge drauf, um von Außen auf den RasPi zugreifen zu können und dann 1w einrichten. Wenn es sich dann so verhält, wie bei euch, liegt es nicht an der Hardware oder Verkabelung.
Dann muss ich nach und nach die anderen Dinge nachinstallieren, die ich noch brauche. Mir graut zwar davor, weil ich nicht mehr genau weiß, was ich wann warum und wie im Laufe des letzten Jahres so installiert hatte. Tjaaa, fehlende Dokumentation... Aber das wird wohl die sauberste Lösung sein.
Auf alle Fälle weiß ich jetzt, dass es so gehen muss, wie ich es mir ursprünglich gedacht hatte. Für diese Erkenntnis danke ich euch.
Und ich muss nicht auf solche verkomplizierte Wege gehen, wie ich es zunächst dachte, mit anderen Reedkontakten und Umkehrung der Fragestellung usw.
Hallo docadams.
Letzter Beitrag zu diesem Thema von mir.. ich versprechs um das nicht unnötig lange hinzuziehen.
Ich glaube ich hab die Lösung...bin vorsichtig geworden, deswegen sage ich, ich glaube.
Ich kann Dein Problem nachvolltziehen, auch an meinem rpi.
Auf die Idee gekommen bin ich durch Andreas's Fragen
Zitat1. Was passiert, wenn die Datei nicht geöffnet werden kann? Ist in_file in diesem Fall definiert?
2. Wenn in_file nicht definiert ist, "scheitert" dann in_file.read() - und text ist undefiniert? Oder behält text den Wert, den es hatte, als in_file noch definiert war (die Datei geöffnet werden konnte)?
Ich hab dieses Progrämmchen von dir übernommen und bischen umgestrickt.
aus:
#!/usr/bin/python
# -*- coding: utf-8 -*-
#
pfad = "/sys/bus/w1/devices/01-0000161f6f4e/"
dateiname="name"
datei = pfad+dateiname
in_file = open(datei,"r")
text = in_file.read()
in_file.close()
print text
hab ich das:
#!/usr/bin/python
# -*- coding: utf-8 -*-
#
while True
text = "nix"
pfad = "/sys/bus/w1/devices/neinesensornummer/"
dateiname="meinname"
datei = pfad+dateiname
in_file = open(datei,"r")
text = in_file.read()
in_file.close()
print text
time.sleep ( 5 )
Alles anzeigen
gemacht.
Das funktioniert bei mir problemlos.
Wenn der Sensor gezogen wird, schreibt er nach ~5 sec halt "nix" am Bildschirm.
Warum bei Dir nicht???
Etzt weiss ich, warum ich Python hasse.
Das, was ich jetzt schreibe kann ich provozieren.
Ich hab mir irgendwann mal angewöhnt, ne Variable die ich beschreibe oder auch nicht immer vor den Schreibvorgang zu initialsieren.
Ich hab das beim ändern quasi unbewusst gemacht, und gar nicht nachgedacht.
In diesem Fall mit "nix".
Sensor ist drin und das Proggi läuft inner Endlosschleife und fragt alle 5 sec.
Wenn Sensor drinnen bleint.. alles ok.. ich gucke parallel mit dem PC über RDP dieses Dir am raspi an.
Jetzt kommts.
Wenn ich die Zeile:
rausschmeise hab ich den gleiche Effekt wie bei Dir.
RDP sagt aber... da ist nix mehr da...
Nach erstmal dumm gucken, kann ich es mir nur so erkären:
Wenn "text" nicht initialisiert wird, und der Sensor gefunden wird, wird die nummer da reingeschrieben ok.
Sensor wird gezogen, open schlägt fehl, da durch open das 1wire-modul zum scannen und lesen aktiviert wird, aber nix findet, und das File löscht.
Aber...
Wenn open fehlschlägt passiert in Python nix, weil ein open nicht abgefragt wird ob erfolgreich oder nicht.
Wenn nicht erfolgreich passiert nix.. er kann halt nicht.
Wenn aber open fehschlägt, schlägt auch logischerweise
fehl.
so, wenn das auch fehlschlägt,der vorgehende Versuch aber erfolgreich war, wird die Variable nicht überschrieben, sondern in Ruhe gelassen, und der alte Wert steht noch drin.
Der gaukelt also was vor, was gar nicht mehr existiert.
Jetzt aber warum ~ 2min... kA.
Ich hab weiter oben geschrieben, dass es 2 Dir's gibt in dem das File auftaucht.
Das ist auch bei C so, dass eines erst nach ~2min gelöscht wird .... kA. warum.
Wie gesagt.. ich mag Python nicht... hab mal gegoogelt ... evtl. kann man das Prob umgehen mit:
import os.path
os.path.exists(file_path)
This returns True for both files and directories.
Use os.path.isfile to test if it's a file specifically.
Iwie so, aber glaube nicht, dass das greift, denn das File existiert ja trotz ziehen, weil damit nur "geguckt" wird ob File noch da.
Erst ein open Versuch in Python lässt es leben oder verschwinden.
Ich hab es nicht probiert, und probiere es auch nicht.
Bei Python ist es so, dass zB: nach if() Befehlen, die nächste Zeilen "eingerückt" werden muss damit die Struktur greift.. ist mir zu dämlich in C hab ich einrücken, "{" und "}" bei mehr Befehlen, und der Editor zeigt senkrechte Balken bei Einrückungen die sauber passen müssen, das sagt mir mehr.
Wenn man das einrücken bei Python vergisst, fällt man voll auf die Schnauze.
Bei C auch, aber das seh ich bereits im Editor...
Ob man open in Python auf Erfolg oder Misserfolg abfragen kann... kA. nix gefunden oder falsch gesucht.
Mit nem initialisieren der text Variablen vor jedem open Versuch geht's ja, ich kanns ja nachvollziehen.
Ehrlich gesagt, ich fasse Python nimmer an
Das ganze Problem stellt sich in C nicht weil, einfach ausgedrückt:
if ( (fd = fopen(file_1,"r")) == NULL)
//Fehlschlag setze Flag = 0
if (Flag == 0) {
//File konnte nicht geöffnet werden
//mach was
}
if (Flag <> 0) {
//File iss da, mach was
//lösche das Flag wieder
}
Das passiert in Python nicht, es wird versucht zu öffnen, aber eben ohne Rückmeldung, dann wird egal ob Erfolg oder Nichterfolg "blind" gelesen.
Aber da sind Python'er gefragt.
So, genung der Diskussion, hoffe ich hab mich einigermaßen verständlich ausgedrückt.
~2 Std. versucht was zu formulieren
...und mir qualmt das Hirn, aber etzt gönne ick mir en Pilsken...
gruß root
Hallo Root,
vielen Dank für Deinen Einsatz!
Äh, ... :s ... wenn eine Programmiersprache so elementar wichtige Dinge wie "Datei öffnen können oder nüsch" nicht rückmeldet, dann fehlt dem Programmierer die Grundlage, darauf reagieren zu können.
Denn: Kann eine Datei zum Lesen nicht geöffnet werden (Pfad / Datei existiert nicht, ...), dann darf ich auch nicht mehr versuchen, etwas daraus zu lesen. Die Daten sind nicht valide. Mit nichtvaliden Daten zu Arbeiten ist ganz übel - dies nicht zu erkennen ist blöd - aber das nicht erkennen zu können stellt in Frage, ob die Wahl der Mittel (Programmiersprache) denn in Bereichen, die sicherheitskritisch sind, überhaupt eingesetzt werden darf. ...
Oder: Konnte die Datei nicht zum Schreiben geöffnet werden (Pfad existiert nicht, Medium schreibgeschützt oder zu voll, ...) dann erübrigt sich der Versuch, irgendwas zu schreiben - da muss eine Fehlermeldung her, weil ansonsten die Daten futsch sind. =(
... Nachdenklich wegen Python...
Wie sagt Ihr Pythonier das denn in Eurer Sprache? oder
Beste Grüsse
Andreas
Hallo....Andreas
uff... 2 die meine Theorie offensichtlich nachvollziehen können...
Wenn das ganze jetzt noch docadams nachvollziehen könnte, wär's ja perfekt.
Das würde dann bedeuten:
1. Warum ist das keinem Python'er hier aufgefallen ... irgendeiner hat das doch auch mitgelesen...
2. Auch 'n alter Knacker kann noch logisch denken ...
Aber, ohne Deine beiden Fragen die mich stutzig machten,hätte ich nicht weiter nachgegrast
da ich wie gesagt das initialisieren der Variablen ganz unbewusst, ohne nachzudenken gemacht habe.
na gut.. in diesem Sinne.
gruß root
----------------------------------
Nachtrag an docadams
----------------------------------
Mir noch eingefallen...
Wenn Du versuchst das nachzuvollziehen, gibt's noch ne Falle...
Du startest Dein Programm und gehst wie auch immer paralle dazu über den Linux-Dateimanager zu eben diesem DIR und guckst Dir das DIR an, bleibst also drin und ziehst oder steckst den Sensor...bummmm Du wirst keine Änderung feststellen...
Der Dateimanager reagiert offensichtlich nicht "on the fly" d.h. er lässt die Anzeige "statisch".
Also nach jedem ziehen und lesen, im Dateinanager eine Ebene zurück.. dann in diese Ebene wieder vor, damit wird er ja gezwungen, neu zu lesen...
Nur so nebenbei...:D
Hallo,
Ich kanns jetzt nicht mehr beweisen, aber innerlich bin ich ganz stolz auf mich, dass ich gestern den gleichen Gedanken auch hatte. Ich habe es nur nicht so elegant umgesetzt, wie Root um 01.05 Uhr. Mein Code sah zuletzt so aus:
#!/usr/bin/python
import time
n = 150
sum = 0
i = -5
zeit=time.strftime("%H:%M,%S")
while i <= n:
sum = sum + i
i = i + 5
zeit=time.strftime("%H:%M,%S")
text1 = "text geloescht"
text2 = "text geloescht"
print "Stoppzeit: ",i," Uhrzeit: ",zeit
pfad = "/sys/devices/w1_bus_master1/01-0000161f6f4e/"
dateiname="name"
datei = pfad+dateiname
in_file = open(datei,"r")
text1 = in_file.read()
in_file.close()
print text1
pfad = "/sys/bus/w1/devices/01-0000161f6f4e/"
dateiname="name"
datei = pfad+dateiname
in_file = open(datei,"r")
text2 = in_file.read()
in_file.close()
print text2
``time.sleep(5)``
print "regulaeres Ende"
Alles anzeigen
Was aber auch nicht mein Problem gelöst hat. Und zur Sicherheit habe ich soeben auch noch mal deinen Code übertragen, ohne Erfolg.
Ich denke schon, dass da noch eine Kraft wirkt, die ich nicht kenne.
Ich lasse das hier noch offen, weil ich mich auf alle Fälle noch mal melden werde, sobald ich ein System völlig neu aufgesetzt habe und ich Erfolg oder Misserfolg vermelden kann. Ich kann aber noch nicht sagen, wann das sein wird.
EDIT: ich mache das schon immer, dass ich, wenn ich mir mit dem MC die Dateien anschaue, ständig die Ordnerebenen wechsle.
Hallo DocAdams, hallo Root,
wie wäre es mit etwas wie:
try:
f = open(datei, "r")
x = f.read()
f.close()
except:
print("Datei kann nicht geöffnet werden oder ist leer")
Beste Grüsse
Andreas
Hallo Root,
Hallo....Andreas
uff... 2 die meine Theorie offensichtlich nachvollziehen können...
... :s ... Du ... ich ... wer noch? :s
Das würde dann bedeuten:
1. Warum ist das keinem Python'er hier aufgefallen ... irgendeiner hat das doch auch mitgelesen...
Vielleicht tippen die Pythonier / Pythonologen ( ) nur fertige Programme ab?
2. Auch 'n alter Knacker kann noch logisch denken ...
Alte Programmierer-Schule!
Aber selbst das wäre in Icon noch nicht mal erforderlich:
infile := open(datei, "r") | stop("Nix open")
wert := read(infile) | wert := "Nix da in der Datei"
close(infile)
write(wert)
Kann die Datei nicht geöffnet werden, versucht das Programm mit etwas anderem in der Zeile "Erfolg" zu haben. Ist eine Alternative angegeben, dann wird eben was anderes gemacht. In dem dummen Beispiel - nicht fein - das Programm mit einer Meldung abgebrochen.
Ist die Datei leer, dann scheitert read(), die Variable wert wird zwangsbesetzt.
Datei wird geschlossen, die Variable wert ausgegeben.
Hm, schmeiss ich meine Python-Bücher jetzt weg - oder arbeite ich mich da irgendwann mal durch. Eigentlich will ich keine weitere Programmiersprache mehr lernen. 15 sind genug. Basta!
Beste Grüsse und noch viel Erfolg beim Forschen!
Andreas
Vielleicht tippen die Pythonier / Pythonologen ( ) nur fertige Programme ab?
So einen kenn ich persönlich in unserem Ort hier.
Der gute Mann ist 30 und seit ~3 Monaten stolzer Besitzer eines rpi's .... Python ist sein spezialgebiet.
4 heisse Projekte hat er schon realisiert ... komplizierte versteht sich, und alle Fehler selbst gefunden... er:"was glaubste was ich geschwitzt hab"...
Hab mir mal eines erklären lassen... ja ,da gabs was zu denken.
ich :"den Source-code haste selbst geschrieben ?"
er:"Source-code???"
ich:"na, ich meine das Python Programm"
er:"nö wozu, das hab ich abgetippt, aber was meinste was da für Fehler drin waren"
ich:"ähmmm.. meinste Abtippfehler ???"
er:"logisch, sagte doch, bis ich die alle gefunden hatte..."
ich:"ok, jetzt kannste also Python"
er:"klar, mich kann jetzt nix mehr in Python erschüttern... finde ja alles..."
...
STOPP
will damit absolut keine Python'er Pythonianer oder wie auch immer angreifen oder schlechtmachen.:thumbs1:
Solche und solche gibt es ausnamslos in jeder Sparte.
Eigentlich will ich keine weitere Programmiersprache mehr lernen. 15 sind genug. Basta!
...So in der Gegend liege ich auch, und fasse Python nicht mehr an.
Nix für ungut an alle die Python mögen... warum nicht... bringt ja für nen Anfänger relativ schnell erste Erfogserlebnisse.
gruß root
Hallo,
ich zähle mal ganz genau auf, was ich jetzt gemacht habe, denn ich verstehe die Welt nicht mehr
* einen anderen Rasperry genommen
* neues System aufgesetzt, Basis ist wheezy-raspian vom 09.09.2014
* das notwendigste konfiguriert (dt.Sprache und Tastatur, 900MHz)
* WLAN aktiviert, kann jetzt via PuTTY und winSCP zugreifen
* dann
sudo apt-get install mc
sudo apt-get update
sudo apt-get upgrade
sudo modprobe w1-gpio pullup=1
sudo modprobe w1-therm
sudo nano /etc/modules
eingetragen:
w1-gpio pullup=1
w1-therm
Alles anzeigen
* Neustart
* Testaufbau mit einem Temperatursensor (zur Kontrolle) und einem Adressgeber parallel. Der Aufbau wurde nach Jörgs Anleitung für lange Leitungen erstellt.
* Der Temperatursensor funktioniert, der Adresssensor funktioniert.
* dann dieses Programm gestartet:
#!/usr/bin/python
import time
while True:
text = "gelöscht"
pfad = "/sys/devices/w1_bus_master1/01-0000161ed6bf/"
dateiname="name"
datei = pfad+dateiname
in_file = open(datei,"r")
text = in_file.read()
in_file.close()
zeit=time.strftime("%H:%M,%S")
print zeit
print text
time.sleep ( 5 )
Alles anzeigen
Erst nach knapp 90 Sekunden (20s eher als beim anderen System) kam die Fehlermeldung:
18:07,59
01-0000161ed6bf
Traceback (most recent call last):
File "./uebung2.py", line 17, in <module>
in_file = open(datei,"r")
IOError: [Errno 2] No such file or directory: '/sys/devices/w1_bus_master1/01-0000161ed6bf/name'
Tjaaa...
Hallo DocAdams,
bist du hier schon weitergekommen ?
Habe nämlich das selbe Problem, und es lässt sich alles reproduzieren, was du geschrieben hast
Auch ich will die Fenster mit Reedkontakten und dem DS2401 abfragen. Siehe meinen Beitrag hier.
Hänge jetzt an der gleichen Stelle fest.
Habe hier:
evtl. eine Erklärung gefunden. Und zwar unten, bei den Kommentaren:
Suchen nach: Von Patrick (vor 8 Wochen)
Hier wird als Lösung owfs mit einem 1-wire-USB-Adapter vorgeschlagen. Patrick hatte offensichtlich das gleiche Problem wie wir.
Gruß, Matthias
hier mal lesen, mir scheinen die DS2401 tückisch zu sein
http://forum.loxone.com/dede/hardware-…n-lasung-4.html
Ich würde dann wenn denn an Umschalter Reed denken und je Fenster einen auf den open Kontakt und einen auf den clos Kontakt zu legen, dann wären abwechselnd mindest in 5 Sekunden Abstand 2 Sensoren zu lesen, wenn das nicht ist der Fall ist -> Fehler! und mit einmal feststellen ist auch nicht, also mindestens 15 Sekunden bis zur Aktionsauslösung wenn 3x hintereinander offen oder zu erkannt wurde.
eventuell ganz den PI und Phyton dafür verlassen und das zum Atmel auslagern.
Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!