Posts by Tastenknecht

    Danke für die Antworten, wie schon erwartet gibt es wohl keine Lösung für das Problem. Im englischen Forum schreiben ja einige sie hätten das Display längere Zeit nicht benutzt und das Problem sei danach aufgetreten, das muß natürlich nicht unbedingt miteinander zusammenhängen. Andere erwähnen nicht ob dem Fehler eine längerer Pause vorausging. Mein Display war zumindest über mehrere Jahre rund um die Uhr an einem aktiven Raspberry angeschlossen dabei war der Touch natürlich immer aktiv und weckte mit der ersten Berührung den Bildschirm aus dem Standby. Als Programmier- und Testumgebung erfüllt es immherin noch einen Zweck, es lebt also weiter.

    Ich besitze seit mehreren Jahren das o.g. Display. Bereits vor einiger Zeit ist mir aufgefallen, daß es auf Berührungen am Rand immer schlechter bis gar nicht reagierte. Dort tippe ich eher selten hin während häufiger benutzte Bereiche nach wie vor tadellos funktionieren, Abnutzung schließe ich daher aus. Auch das Entfernen der Schutzfolie brachte keine Verbesserung. Ich habe es heute getauscht und mit dem anderen Display funktioniert wieder alles einwandfrei, es ist also selbst eine etwaige softwareseitige Ursache auszuschließen. Daher meine Frage, gibt es eine Möglichkeit dieses Verhalten zu korrigieren oder genauer zu analysieren? Ich vermute einen schleichenden, irreparablen Hardwaredefekt. Als alleiniges Display funktionierte es jedoch noch einwandfrei.

    Es gibt Unterschiede zwischen den beiden python Versionen. Es macht sicher Sinn das script an phyton3 anzupassen, das sollte nicht schwierig sein. Welche das sind kann ich dir aber aus dem Stand nicht sagen.

    Ich habe den gleichen Sensor und benutze als Basis das gleiche Script ControlEverythingCommunity / TSL2561auf dem offensichtlich auch deins basiert. Ich habe jetzt mal dein Script ausprobiert und als einzige Änderung nicht

    #/!usr/bin/python3

    sondern

    #/!usr/bin/python

    verwendet und damit läuft es einwandfrei und ohne den von dir beschrieben Effekt.

    Hallo,

    ich habe hier noch einen CHAMPTEK MCR-12 USB Barcodescanner rumliegen, den ich gerne fest verbauen würde. Aus Platzgründen möchte ich das beigelegte Kabel nicht verwenden, ich möchte es aber auch nicht zerschneiden und auch nicht an der Platine herumlöten. Darum bin ich auf der Suche nach einer Bezugsquelle für den passenden Stecker mit bereits angeschlossenen Kabeln, da ich mir für ein oder zwei Kabel nicht extra das Werkzeug kaufen möchte. Laut Datenblatt handelt es sich um eine MOLEX 11P Pitch 1.25 Steckverbindung, die so aussieht: Unterseite mit Buchse. Ich vermute es handelt sich um MOLEX PICOBLADE Stecker und Buchsen Datenblatt bei Reichelt, bin mir aber nicht sicher. Reichelt führt die Serie, allerdings nicht die 11 polige Version und ohnehin ohne Kabel. Gibt es die Stecker mit Kabeln also irgendwo, möglichst in kleinen Mengen, zu kaufen?

    Ich habs nur überflogen und php kennen ich nicht im Detail. Du bekommst keine Session ID weil die

    Code
    /home/pi/Wohnzimmer/skripte/DECT/SIDerzeugen.sh

    fehlt. Bekommst du eigentlich keine Fehlermeldung? Das o.g. Script soll das fehlende Scripot ersetzen und erzeugt eine Session ID, in der Hoffnung, daß es das richtige Format ist. Die Fritzxbox.dat brauchst du dann eigentlich nicht mehr. Zu dem Rest kann ich nichts sagen. Das Ganze ist ein ziemliches Flickwerk. Alles ungetestet und ohne Gewähr. Passe es einfach mal an und starte dein Script wie zuvor.


    Noch besser ist es im ersten Schritt das SIDerzeugen.sh direkt zu starten und danach in die Datei /tmp/last.SID zu schauen.

    Trage mal deine Daten ein:

    Bash
    #!/bin/bash
    # Quelle: https://raspberrypiandstuff.wordpress.com/tag/fritzdect/
    FBF="http://fritz.box" #<-- ggf. Anpassen
    USER="" # <--- hier
    PASS="" # < -- Hier
    CHALLENGE=$(curl -s "${FBF}/login_sid.lua" | grep -Po '(?<=<Challenge>).*(?=</Challenge>)')
    MD5=$(echo -n ${CHALLENGE}"-"${PASS} | iconv -f ISO8859-1 -t UTF-16LE | md5sum -b | awk '{print substr($0,1,32)}')
    RESPONSE="${CHALLENGE}-${MD5}"
    SID=$(curl -i -s -k -d "response=${RESPONSE}&username=${USER}" "${FBF}" | grep -Po -m 1 '(?<=sid=)[a-f\d]+')
    echo $SID > /tmp/last.SID

    und speichere das Script unter:

    Code
    /home/pi/Wohnzimmer/skripte/DECT/SIDerzeugen.sh

    Das ist zwar alles ein ziemleiches Durcheinander, aber vielleicht geht es fürs Erste.

    Prinzipiell ist das gleich - einfach die serielle Schnittstelle. Die Frage ist, wie gut die Signale durch die selbstgebastelte Variante sind. Ich persönlich würde sowas ohne Zugriff auf ein oszilloskop nicht bauen.

    Und selbst wenn man das hinbekommen hat lauert schon das nächste Problem minimalistische Lesekopf:

    Quote

    Nicht zu unterschätzen ist die Positionierung des Fototransistors, ich bin mit Klebeband/Knete gescheitert, deswegen ein Halter der per 3D-Drucker hergestellt werden kann. Besser wäre der Magnetring, meine Werkstatt gab leider nur Rundmagnete her.

    Man kann fertige SLK für wenig Geld kaufen, die dann auch einen Ringmangenten zur einfachen Befestigung haben. Die etwas teureren haben auf der Rückseite noch eine Kontroll LED, die bei korrekter Positionierung blinkt, was die Monatge nochmals vereinfacht.

    Natürlich kann man auch den steinigen Weg des Eigenbaus gehen, beim Gelingen ist das Erfolgserlebnis natürlich größer.:thumbup:

    Das sollte auch mit einem selbstgebauten ir schreib/lesekopf funktionieren oder?


    Was bedeutet die Schnittstelle muss angepasst werden. Ich habe momentan den uart auf dem raspberry pi aktiviert für die serielle Kommunikation. Nicht den mini uart. Ich habe Bluetooth jetzt momentan auf dem Mini uart.

    Die Beschreibung ist ja für einen USB Schreib-/Lesekopf und zeigt das grundsätzliche Handling für diesen über die Konsole. Es wird also ohne Anpassung für die serielle Schnittstelle nicht funktioniern. Ob es nun reicht für einem selbstgebauten ir schreib/lesekopf einfach /dev/ttyUSB0 durch /dev/ttyAMA0 zu ersetzen kann ich dir, wenn das überhaupt richtig sein sollte, nicht sagen, das mußt du ausprobieren.

    Ich habe mir damals, weil ich soweit unten nicht anfangen und baldmöglichst die Daten haben wollte, einen fertigen USB Schreib-/Lesekop gekauft und daher diese ganze Problematik übersprungen.

    Du hast doch das gleiche Kabel wie auf der Seite vom maker-tutorials Link mit dem HAT Modul. Da spielt es doch keine Rolle ob du dieses auf ein HAT Modul steckst, das du nicht hast, oder direkt auf das Display. Die Zuordnung der Kabelfarbe zu den Raspberry PINs gilt doch trotzdem und ist dort auf mehreren Fotos und Grafiken gut und eindeutig dargestellt, siehe Abschnitt: "Es ist auch möglich das Driver HAT per Kabel mit den GPIO Pins zu verbinden (siehe nachfolgende GPIO Pin-Belegung)". Also z.B. violett (Busy) auf PIN18, weiß (RST) auf PIN11 des Raspberries usw.

    Vielleicht bevor ich konkret mit meinen Problemen anfange, kannst du mir sagen wie dein Aufbau ist? Vielleicht hilft mir das schon.

    Ich betreibe snapcast auf 2 Raspberries, einer ist Server und Client und der andere ist nur Client, verbunden sind sie per WLAN und als Quelle dient MPD. Die Wiedergabe erfolgt beim Server über den AUX Eingang eines Radio bzw. beim Client über eine aktive Box die per USB direkt von diesem gespeist wird. Aufgabe ist die Hintergrundbeschallung per Zufallswiedergabe aus einer Playlist mit ca. 70 Titeln, manuelle Bedienung ist nicht vorgesehen. Alles startet beim Hochfahren der Raspberries automatisch.

    Vielleicht ist aber moodeaudio ohnehin für deine Zwecke besser geignet, ansonsten melde dich wieder.

    Da die Fritzbox anscheinend eine entsprechende Funktion nicht implementiert hat mußt du tricksen. Das ist dann aber von deiner Infrastuktur abhängig und die kennst nur du. Irgendetwas per Script aus- und wieder einzuschalten ist ja sicher nicht das Problem. Die eventullen Kosten, die Vor- und Nachteile der Lösungen sowie die Auswirkungen auf andere Dienste mußt du selber abschätzen.

    In X_voipSCPD.pdf steht aber:

    Quote

    X_AVM-DE_DialHangup

    Disconnect the dialling process.

    Ob es ein laufendes Gespräch beendet ist eher ungewiß, außerdem gilt es wohl nur für VOIP.

    Unter Entwicklungssupport findest du eine Liste mit Schnittstellenbeschreibungen, wahrscheinlich kennst du sie schon. Nr. 8, 9,10 sind für Telefonie. Die enthalten eine Menge Parametrierungs- und Abfragefunktionen, auch um kommende Gespräche abzuweisen, aber wohl nicht um laufende Gespräche zu beenden.

    Ansonsten auf die harte Tour und entweder die Stromzufuhr oder die Anschlußleitung des Telefons kurz unterbrechen. Ich habe allerdings keine Ahnung ob des evtl. irgendwelche Nebenwirkung hat wenn man das öfter macht und es wird aufwändig, wenn mehrere Telefone berücksichtigt werden müssen. Bei schnurlose Telefonen mit Akku hilft auch das nichts.