Türklingel erweitern

  • Leider stoße ich auf einige Probleme, die dem abgespeckten micropython geschuldet sind...

    Zum Beispiel ist kein queue enthalten, muss man also irgendwie selber implementieren...

    Mein größtes Problem ist allerdings dass urequests nicht vollständig dem Original entspricht und ich bei jedem Abfragen eine TLS Fehlermeldung erhalte... Das soll man beim Original durch den zusätzlichen Parameter verify=False abschalten können, aber im urequests gibts das nicht :dau1: Also hab ich einfach das original requests Module manuell auf die SD kopiert, aber das wäre ja zu einfach gewesen: urllib3 wird benötigt, Ok, also auch das drauf kopiert dann leider das nächste Problem: __future__ wird benötigt.... :dau2:


    Tja und am letzten kau ich jetzt schon seit einigen Stunden :motz:


    Hab mir https://pypi.python.org/pypi/future geladen, das src/future Verzeichnis in __future__ umbenannt und in /sd/lib/ abgelegt. Klappt leider nicht:

    Code
    1. >>> import telegram
    2. Traceback (most recent call last):
    3. File "<stdin>", line 1, in <module>
    4. File "/sd/scripts/telegram.py", line 2, in <module>
    5. File "/sd/lib/requests/__init__.py", line 43, in <module>
    6. File "/sd/lib/urllib3/__init__.py", line 4, in <module>
    7. ImportError: no module named '__future__.absolute_import'
    8. >>>


    Das Absurde ist das in der setup.py von dem Module auch bereits __future__ importiert wird ... *what the fuck?*:-/



    Weiß hier jemand nen Tipp?

    :danke_ATDE:

  • Ist das eventuell eine Option? https://pypi.python.org/pypi/micropython-future/0.0.3

    MicroPython ist doch Python 3.5 oder sowas kompatibel, da solltest du die meisten future-Imports nicht brauchen. Und obiges Modul ist ein Dummy, um ImportErrors zu vermeiden.

    Mein größtes Problem ist allerdings dass urequests nicht vollständig dem Original entspricht und ich bei jedem Abfragen eine TLS Fehlermeldung erhalte...

    Magst du vielleicht ein kleines Codebeispiel und die Fehlermeldung posten? Ich denke kaum, dass auf das große requests umzusteigen hier eine wirkliche Lösung ist. Es hat schon einen Grund, warum viele Module mit dem Präfix u versehen und abgespeckt/neu programmiert wurden... die Performance dürfte nicht so der Brüller sein, der Speicherverbrauch auch nicht.


    Eventuell gibt's ne andere Lösung.


    Edit: ich dachte gerade, ich hätte was zu queue gefunden... soll wohl ein Witz sein :-/

    https://github.com/micropython…hon-lib/tree/master/queue


    leer...

  • MicroPython ist doch Python 3.5 oder sowas kompatibel, da solltest du die meisten future-Imports nicht brauchen. Und obiges Modul ist ein Dummy, um ImportErrors zu vermeiden.

    Tja aber leider funktioniert das im Fall von urllib3 nicht :X

    Es hat schon einen Grund, warum viele Module mit dem Präfix u versehen und abgespeckt/neu programmiert wurden... die Performance dürfte nicht so der Brüller sein, der Speicherverbrauch auch nicht.

    Das ist schon klar... Aber letztlich war mir erst mal nur wichtig, es irgendwie ans laufen zu kriegen...

    Magst du vielleicht ein kleines Codebeispiel und die Fehlermeldung posten?

    Edit: ich dachte gerade, ich hätte was zu queue gefunden... soll wohl ein Witz sein

    https://github.com/micropython…hon-lib/tree/master/queue


    leer...

    Jep... So gehts mir quasi schon die ganze Zeit - es sind viele Module noch nicht implementiert, nur leere dummy Dateien... :stumm:

  • Ein weiterer Tag der für dieses SSL//TLS Problem drauf ging, auch Linus wusste' nicht so recht mit dem Problem anzufangen...


    Code
    1. >>> import socket
    2. >>> import ssl
    3. >>> s = socket.socket()
    4. >>> ai = socket.getaddrinfo("google.com", 443)
    5. >>> addr = ai[0][-1]
    6. >>> s.connect(addr)
    7. >>> s = ssl.wrap_socket(s)
    8. >>>

    ...funktioniert... aber:

    ...funktioniert nicht :conf:



    Ich hab dann den Entwickler der MicroPython_ESP32_psRAM_LoBo Firmware auf das Problem angesprochen und die Lösung versteckt sich hier: https://github.com/loboris/Mic…SP32_psRAM_LoBo/wiki/curl

    Zitat

    Note:
    If TLS is enabled, the module uses mbedTLS and more memory is required.
    If not using psRAM, you may need to lower the MicroPython heap (72 KB will usually be enough).
    You may try to set
    → Component config → mbedTLS → TLS maximum message content length
    to a lower value than default 16 kB, for example to 4 kB. It will usually work, but the TLS may fail if the server side does not support TLS Maximum Fragment Length Negotiation Extension.

    Er schrieb dazu außerdem:

    Zitat

    If using psRAM and you can build your own firmware, you may compile with → Component config → mbedTLS → TLS maximum message content length set to the 16384.

    The precompiled firmwares were built with this value set to 4096, which may be the reason for the error.

    On next update I will set the velue to 16384 for psRAM firmwares.


    Nach der Anpassung funktioniert es in der Tat einwandfrei :bravo2:

  • So, ich poste dann jetzt noch mal so als Zwischen-Bereicht meine bisherigen Scripts und versuche auch eine Installationsanleitung zu erstellen.



    => https://github.com/meigrafd/ESP32_Klingel


    Meine Scripts sind (wie vorher schon mal beschrieben) so aufgebaut das alle Scripts und Module nur auf der SD-Karte liegen. Die einzige Datei die nach dem flashen einer Firmware verändert wird ist /flash/boot.py.

    Die SD-Karte wird standardmäßig immer nach /sd/ gemounted, das lässt sich nicht beeinflussen.


    Standardmäßig ist in der Firmware ein FTP-Server enabled. Es fehlt dann nur noch die Aktivierung via Script, siehe dazu main.py ... Genaueres steht hier: https://github.com/loboris/Mic…psRAM_LoBo/wiki/ftpserver

    Tipp: Sehr zu empfehlendes Feature ;)



    Leider funktioniert die Sache mit queue noch nicht, deshalb wird der untere Teil der main.py auch ignoriert, weil vorher ein sys.exit(0) das Script vorzeitig beendet.

  • Aktuell bin ich dabei das queue Problem zu lösen indem ich mir eine eigene Queue Klasse bastel und dabei natürlich nah ans Original ran möchte.

    Nun ist mir ein Problem, wenn man so will, aufgefallen:


    Blockiert ein Script zu lange (für ca. 15 sec) wird es vom Task watchdog abgebrochen. Sieht dann zum Beispiel so aus:

    https://docs.micropython.org/e…/library/machine.WDT.html

    https://docs.micropython.org/e…/library/machine.WDT.html

    https://docs.micropython.org/e…ibrary/machine.Timer.html


    Dieses Feature lässt sich zwar über menuconfig abschalten, aber hat ja eigentlich auch was gutes: Nix kann mehr crashen und sich aufhängen.


    Eigentlich dachte ich dieses Problem mit dem folgenden sleep umgangen zu haben - allerdings funktioniert das nicht:

    Python
    1. def sleep(secs):
    2. yield int(secs * 1000)

    :denker:

    ...Also Problem ist ja, dass time.sleep blockiert, es müsste aber innerhalb einer bestimmten Zeit einfach nur eine Kleinigkeit am Code verarbeitet werden um diesen 'Hard Reset' zu verhindern, wie zum Beispiel irgendein Flag zu ändern.


    Meine jetzige Lösung sieht vielleicht etwas dirty aus, funktioniert aber :daumendreh2:



    Meine derzeitige Eigenkreation vom queue.py sieht derzeit wie folgt aus: https://github.com/meigrafd/ES…aster/sd/scripts/queue.py


    Test:

    Code
    1. >>> import queues
    2. >>> queue = queues.Queue()
    3. >>> try:
    4. ... queue.get(timeout=20)
    5. ... except queues.Empty:
    6. ... pass
    7. ...
    8. >>>

    :angel:


    Nächstes Problem: Ein GPIO-Interrupt prellt ganz schön arg .... ein 'bouncetime' gibt es aber irgendwie nicht, muss ich also auch selberbauen :X Aber zuvor schau ich erst obs einen Unterschied zum https://docs.micropython.org/e…brary/machine.Signal.html gibt



    //EDIT: Die ganze Mühe bzgl. _msleep() war für die Tonne... utime.sleep_ms(x) füttert (feed) automatisch den Watchdog. Dh mein _msleep() einfach durch utime.sleep_ms() ersetzen und gut ist's.

  • Ich hab jetzt eine Lösung für das "debounce"-Problem gefunden, bzw da gibt es mehrere:

    1. https://gist.github.com/SpotlightKid/0a0aac56606286a80f860b116423c94f
    2. https://github.com/peterhinch/…blob/master/pushbutton.py
    3. https://github.com/peterhinch/…nc/blob/master/aswitch.py

    In meinem Fall hab ich das 1) Script leicht modifiziert, und zwar so dass es nur auf RISING_EDGE reagiert.

    Beispiel:

    Python
    1. import machine
    2. from irq_debounce import DebouncedSwitch
    3. def interrupt_event(arg):
    4. r, pin = arg
    5. print('{} pin change {}'.format(utime.strftime("%M:%S", r.now()), pin))
    6. rtc = machine.RTC()
    7. interrupt_pin = machine.Pin(25, machine.Pin.IN, machine.Pin.PULL_UP)
    8. pushbutton = DebouncedSwitch(sw=interrupt_pin, cb=interrupt_event, arg=(rtc, 25))

    Das funktioniert soweit wie erwartet. Dank des Debug-Modes von der Firmware sieht man öfters auftretende Events aber die interrupt_event() Funktion wird tatsächlich entprellt.


    Jetzt wirds allerdings kurios:

    Sobald ich das ganze wie vom RaspberryPi gewohnt auf queue umstelle, fängt es wieder an zu prellen :-/ :wallbash:

    Beispiel:

    Ausgabe:

    Die ersten 3 Zeilen sind die Debug-Ausgaben der Firmware, und sagt glaub ich soviel aus wie " 3x irq aufgetreten". Wieso dann aber 6 Einträge ins Queue gemacht werden macht mich etwas stutzig....


    :helpnew: