Posts by meigrafd

    Es ist etwas verwirrend wenn du manuell /etc/rc.local ausführst und die Ausgabe postest... Zumal du /etc/rc.local dem Interpreter sh übergibst... Ist die Datei selbst ausführbar? Wenn nicht = Fail.


    /bin/sleep 180 && /home/pi/LS_s.py ist ebenfalls etwas komisch... Wieso möchtest du /etc/rc.local um 180 Sekunden verzögern bevor dein Python Script ausgeführt wird?


    Die Fehlermeldung sieht zudem so aus als würde das Script nicht vom Shebang verarbeitet werden... Schon mal versucht bei Ausführung die Datei direkt dem Interpreter zu übergeben? (die Zeile über deiner künstlichen Verzögerung)

    Ansonsten: Shebang direkt auf den Interpreter setzen.


    Das Script selbst sieht ebenfalls komisch aus... Welchen Zweck erfüllt socket?

    Und zu guter letzt: Du setzt nicht überall den absoluten Pfad zur bild.jpg. Das kann dir irgendwann zum Verhängnis werden.





    PS: Mach lieber dein Telegram_Bot_TOKEN unkenntlich, sonst kapert dir den jemand.

    Du musst vorher ein apt-get update ausführen, um die Paketinformation zu aktualisieren - wenn das letzte update einige Tage zurück liegt.

    sondern durch den Tastendruck ein zweites Script ausgeführt wird.

    Sowas tut man nicht - da haut dir hier (eigentlich) jeder mit nem Rohrstock auf die Finger für, zu Recht.


    Bitte mehr Details nennen - sonst ist Hilfestellung weiterhin nicht möglich. Zum Beispiel: Was ist das für ein anderes Script und was steht da drin?


    Lasst euch doch bitte nicht alles einzeln aus der Nase ziehen.

    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
    import machine
    from irq_debounce import DebouncedSwitch
    
    def interrupt_event(arg):
        r, pin = arg
        print('{} pin change {}'.format(utime.strftime("%M:%S", r.now()), pin))
    
    rtc = machine.RTC()
    interrupt_pin = machine.Pin(25, machine.Pin.IN, machine.Pin.PULL_UP)
    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:

    Sorry jetzt bin ich etwas verwirrt... Hast Du und Hofei das gleiche Anliegen, oder kaperst du gerade den Thread? :-/


    Erst mal festhalten: Ein einzelner ESP32 Chip verbraucht selbstverständlich weniger Strom, als ein Development-Board mit integriertem USB-TTL und Spannungswandler etc..


    Ich versteh aber auch weiterhin nicht wieso Du überhaupt einen ESP32 für einfache Messungen in Betracht ziehst - zumal du kein WLAN nutzen willst sondern GSM, da wäre selbst ein ESP8266 die falsche Wahl...


    Wodurch zeichnet sich ein ESP32 aus?


    - integriertes WLAN und Bluetooth... Hast du vor das in deinem Projekt zu nutzen?

    - Dualcore 160MHz... Brauchst du wirklich so viel Rechenleistung?

    - 4MB Flash und erweiterbarer RAM auf bis zu 16MB... Brauchst du das für deine einfache Messung?

    - Viele GPIO's (PWM, ADC, DAC, I/O, etc..)... Wie viele GPIO's benötigt dein Projekt?


    Du scheinst auch bereits eine Vorgabe von dem was maximal verbraucht werden darf zu haben und solltest dann eher Klein anfangen. Es macht wie ich finde wenig Sinn von vorneherein mit großer Hardware anzufangen und irgendwie zu versuchen dessen Verbrauch zu kastrieren.


    Es gibt genug µC die mit Sensoren und GSM sprechen können - evtl. kommst du sogar ohne GSM aus, je nachdem wie die Umgebung aussieht könnte evtl. LoRa reichen. Allgemein haben Mobilfunksysteme eine zu hohe Leistungsaufnahme und sind im Unterhalt eigentlich auch zu teuer. Mittlerweile gibt es gerade wegen IoT immer mehr nutzbare Alternativen, siehe dazu https://de.wikipedia.org/wiki/Low_Power_Wide_Area_Network

    Oder wäre es z.B. möglich, dass ich einen reinen ESP-WROOM-32 Chip nehme, einen USB-TTL-Converter anstecke zum Programmieren und dann für den Betrieb wirklich nur den blanken Chip [1] nutze?

    Ja.

    Bei mir am Board ist ein Chip mit der Bezeichnung ESP-WROOM-32 verbaut.

    Aber die Werte von Heise.de beziehen sich nicht auf den ESP32, da sie einen ESP31B hatten ...


    Sind meine Erwartungen zu hoch, dass man damit eine Messeinheit auch > 6 Monate hinweg sinnvoll für kleines Geld betreiben kann?

    Wäre der ESP32 dafür nicht etwas oversized? Was spricht gegen den ESP8266 ?

    Naja wie raspiprojekt bereits indirekt anmerkte, habt ihr nicht nur einen nackten ESP-WROOM-32 sondern es befindet sich auch noch ein USB-TTL-Converter uf der Platine.


    Je nach dem wie der verschaltet ist kann es durch aus sein dass der ebenfalls permanent mit Strom versorgt wird, auch wenn ihr ihn gar nicht verwendet/nutzt.


    Die Effizienz des AMS1117 ist vermutlich auch nicht berauschend, würde aber IMHO nicht so einen signifikaten Unterschied ausmachen... Laut deiner Seite sind es 4mA die der AMS1117 verpuffen lässt. Wenn du den also abklemmst sinkt dein Verbrauch auf 4,5mA?


    Zu beachten ist übrigens auch zu dem von Heise.de angeblich verwendeten ESP32:

    Quote

    Wir haben uns das Developer Board des ESP32 angeschaut. Bisher haben erst 200 Beta-Tester weltweit ein ESP32-Entwicklerboard bekommen. Auf diesem ESP-WROOM-03 ist ein Chip mit der Bezeichnung "ESP31B" verbaut, der sich zu dem endgültigen Chip noch unterscheiden kann.

    Quelle: Den von Hofei genannten Artikel ;)

    Die einzige zusätzliche Beschaltung bei dem von Hofei verwendeten ESP-WROOM-32-Module, ist der USB-TTL-Converter.



    Unterschiede machen sich bereits durch unterschiedliche Toolchains bemerkbar... Da kann der exakt selbe Code mit einer älteren Toolchain noch 10µA verbrauchen, eine aktuelle Toolchain hingegen verballert 30µA.


    Verändert hat sich zum Beispiel dass im deep_sleep zusätzlich der "fast and slow RTC ram" an bleibt, der zuvor aber auch abgeschaltet wurde, was mit einem Bug der ESP32 Revision zu tun hat.

    Das geht mit folgendem abzuschalten:

    Code
    esp_deep_sleep_pd_config(ESP_PD_DOMAIN_RTC_PERIPH, ESP_PD_OPTION_OFF);
    esp_deep_sleep_pd_config(ESP_PD_DOMAIN_RTC_SLOW_MEM, ESP_PD_OPTION_OFF);
    esp_deep_sleep_pd_config(ESP_PD_DOMAIN_RTC_FAST_MEM, ESP_PD_OPTION_OFF);
    esp_deep_sleep_start();

    Quelle: https://esp32.com/viewtopic.ph…87ab41bfb997983023fd74ebf


    Siehe dazu auch

    https://www.espressif.com/site…_for_bugs_in_esp32_en.pdf

    https://forum.micropython.org/viewtopic.php?t=3555

    https://forum.sparkfun.com/viewtopic.php?t=45931

    https://pcbreflux.blogspot.de/…2-deep-sleep-example.html

    https://hackaday.com/2016/09/1…hands-on-awesome-promise/

    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
    def sleep(secs):
        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
    >>> import queues
    >>> queue = queues.Queue()
    >>> try:
    ...     queue.get(timeout=20)
    ... except queues.Empty:
    ...     pass
    ... 
    >>>

    :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.

    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.

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


    Code
    >>> import socket
    >>> import ssl
    >>> s = socket.socket()
    >>> ai = socket.getaddrinfo("google.com", 443)
    >>> addr = ai[0][-1]
    >>> s.connect(addr)
    >>> s = ssl.wrap_socket(s)
    >>>

    ...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

    Quote

    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:

    Quote

    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:

    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:

    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
    >>> import telegram
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/sd/scripts/telegram.py", line 2, in <module>
      File "/sd/lib/requests/__init__.py", line 43, in <module>
      File "/sd/lib/urllib3/__init__.py", line 4, in <module>
    ImportError: no module named '__future__.absolute_import'
    >>>


    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:

    Meine Frag ist, wie bekomme ich den an meinen Raspberry angeschlossen?


    Es gibt hierzu leider keine Tutorials mit denen ich sonst immer arbeite ..

    Für Taster gibt es mehr als genug Tutorials.


    Leider lieferst du viel zu wenig Infos um dir weiter helfen zu können... zB was du schalten willst (230V AC?), was dadurch geschaltet werden soll und überhaupt, was das Ziel sein soll

    Um den Flash Speicher des ESP32 zu schonen, empfehle ich nach flashen des Images alle zusätzlich zu installierenden Module usw auf die SD-Card zu installieren. Die hierfür nötige Modifikation sähe wie folgt aus:


    Direkt auf dem /flash/ des ESP32 die boot.py mit folgender ersetzen:

    Die SD Karte dann mit FAT32 formatieren und 2 Verzeichnisse erstellen:

    lib

    scripts


    Installiert man dann über upip weitere Python-Module, werden die nach /sd/lib/ installiert ;)

    Eure individuellen Scripts legt ihr in /sd/scripts/ ab ... Kann auch anders lauten das Verzeichnis, wie ihr lustig seid (boot.py anpassen!).

    Python
    import upip
    
    upip.install('micropython-urequests')
    ## alternativ:
    upip.install('micropython-urequests', install_path='/flash/lib/')

    Wer irgendwelche Module trotzdem auf dem internen Flash ablegen will kann den 2.Befehl verwenden.



    Sieht bei mir aktuell so aus:

    ...meine /sd/scripts/main.py initialisiert wlan usw...



    //EDIT: Nicht vergessen die SD vor dem herausziehen jedes mal auszuhängen: uos.umountsd()

    Nachtrag ... 3 Dinge die ich vergessen hab zu erwähnen:


    1) Mein neu erworbenes Modul TTGO T8 hat ein anderes OLED Display, nämlich ein 1,3" SH1106. Dementsprechend bedarf es einer anderen Ansteuerung: https://github.com/robert-hh/SH1106


    2) Zwischenzeitlich fand ich auch heraus dass man ein 16MB W25Q128 SPI Flash via VSPI an den ESP32 anschließen kann - ein NOR-Flash Baustein. Wäre eine Alternative zur SD-Karte gewesen aber nu hab ich ja erstmal das TTGO-T8 Modul zum rumspieln ;)


    3) Der TF-Slot (SD Karte) beim TTGO T8, besitzt keine Feder. Die Karte steht leider relativ weit über.

    Die Verwendete Pinbelegung ist:

    SD name ESP32 pin SPI pin
    D0 2 MISO
    D1 NC NC
    D2 NC NC
    D3 13 CS
    CLK 14 SCK
    CMD 15 MOSI

    Demzufolge kommt nur SPI- und SD-Mode in Frage. 1LINE und 4LINE nicht.



    Ich erstelle mir gemäß Beitrag#116 wieder eine angepasste Firmware. TimeZone muss by-the-way nicht auf CET sondern CET-1CEST,M3.5.0,M10.5.0/3 gestellt sein. Siehe dazu aber auch https://github.com/loboris/Mic…icropython/docs/zones.csv ... https://loboris.eu/forum/Threa…justing-time?pid=21#pid21



    Anyway... Zum einbinden der SDCard bedarf es nicht viel:


    :angel:

    Kurzes Update.... 24.02 verschickt, 13.03 erhalten: https://www.aliexpress.com/ite…-IPEX-3D/32853967430.html

    Kam in einer kleinen Plastikbox, also Transportschutz. Wirkt sehr hochwertig, gut verarbeitet.


    Natürlich gehen für den SD-Karten-Slot, dem OLED Display und dem Nav-Button ein paar GPIO's unwiderruflich verloren, aber die Features sind echt nett:

    - Auf die SD Karte kann flexibler Code gepackt werden, ohne jedes mal das Teil neu flashen zu müssen.

    - Das OLED Display werde ich zur Visualisierung heutiger Klingler verwenden.

    - Den Nav-Button zum durchblättern aufm OLED, zB. "Heute", "Gestern", "Diesen Monat" o.ä..

    Muss mir dafür nur noch ein kleines Gehäuse drucken lassen ;)


    Gibt man Strom auf das Modul erscheint auch direkt eine kleine Demo auf dem OLED Display. Das einzige was mich aktuell etwas stört ist die Ligthshow der "Battery Status"-LED's die leider ziemlich grell sind... https://youtu.be/Q7qn9qUrP2A



    Nun brauch ich natürlich eine andere Firmware => esp32_psram_all


    Flashen tu ich das Modul über einen meiner Pi's mit der /boot/config.txt Einstellung max_usb_current=1 weil der USB-3-Port-Strom am PC nicht ausreicht.
    Vor dem flashen erst löschen:

    Und dann natürlich:


    Weiter arbeiten tue ich nun mit pip3 install rshell wobei ich mir einen alias für die Zeile rshell -e nano -p /dev/ttyUSB0 erstellt habe...

    Die Handhabung ist anfangs etwas gewöhnungsbedürftig, hat man den Dreh erst mal raus ist rshell eine echt bequeme Sache ;)

    :angel:


    Nu bastel ich erst mal'n bissal rum und such mir auch ne freie SD Karte ;)




    .... to be continued ...