Mit QR Code ein Event auslösen oder Befehl absetzen

[TomLee]

Hallo,

suche nach einer Lösung das jeder (auch ausserhalb meines Netzwerk) ein Event oder Befehl mit einem QR Code auslösen kann.

Die Möglichkeiten auf die ich bisher gekommen bin:

Über eine URL eine HTTP-Anfrage abzusetzen.Geht aber nur in meinem Netzwerk ? Das erfordert vom User nur das scannen des Codes und einmalig das aufrufen der übergebenen URL.

Ausserhalb des Netzwerk ginge es mit Hilfe von mailcheck, der QR Code liefert die Emailadresse und den Betreff. Was mir dabei weniger gefällt ist das damit drei Schritte vonnöten wären (scannen, Übergabe an die Mail App, absenden der Mail).

Hätte gerne eine Lösung die nur mit zwei Schritten auskommt, scannen und "absetzen".

Hat hier irgendwer eine Idee wie man das noch umsetzen könnte ?

Thomas

[Wernieman]

Du kannst doch auch von außerhalb code pr http senden ... must "nur" ein Gateway bauen.

ABER: Dir ist klar, das jeder den QR Code analysieren kann. Also auch Leute, welche Du nicht so "gerne magst", eventuelle Schwachstellen rausuchen können?

[TomLee]

Du kannst doch auch von außerhalb code pr http senden ... must "nur" ein Gateway bauen.

Keine Ahnung davon, gibts ein paar Stichworte dazu ?
Darum auch meine zweite Lösung über mailcheck.

ABER: Dir ist klar, das jeder den QR Code analysieren kann. Also auch Leute, welche Du nicht so "gerne magst", eventuelle Schwachstellen rausuchen können?

Je nach Lösung, Event oder Befehl, wäre nach meinen bisherigen Gedanken dazu, der jeweilige Eventhandler oder das Device, nur in einem von mir bestimmten/erwarteten Zeitraum, einmal aktiv.

[JoWiemann]

Muss es unbedingt ein QR sein. Es gibt doch auch gute Lösungen mit Telegram.

Grüße Jörg

[TomLee]

Nicht jeder nutzt Telegram, ein Barcodescanner dagegen, so mein Gedanke dahinter, ist auf fast jedem Smartphone (was mittlerweile jeder 24/7 mit sich rumträgt) meist Standard.

[frank]

was soll denn eigentlich passieren?
wie ist das scenario?

[TomLee]

Es werden jetzt viele die Hände über dem Kopf zusammenschlagen -> Türöffner.

Wie gesagt wird es ja nur in einem von mir erwarteten/bestimmten Zeitraum möglich sein.

[frank]

Es werden jetzt viele die Hände über dem Kopf zusammenschlagen -> Türöffner.

Wie gesagt wird es ja nur in einem von mir erwarteten/bestimmten Zeitraum möglich sein.

die person ruft dich an und du machst die tür selber remote auf.

[MadMax-FHEM]

Es werden jetzt viele die Hände über dem Kopf zusammenschlagen -> Türöffner.

Wie gesagt wird es ja nur in einem von mir erwarteten/bestimmten Zeitraum möglich sein.

Und wie soll der Ablauf sein?

Du hast einen QR-Code an der Tür kleben, jemand kommt und scannt den und kommt rein (wenn das erwartete Zeitfenster zutrifft)?

Du schickst jemandem einen QR-Code und der scannt den mit dem Smartphone...
...hmmm, geht ja nicht, die Kamera kann ja nicht "fotografieren", was nur auf dem Bildschirm zu sehen ist (oder liege ich da daneben?)...

Jeder der bei dir (zu bestimmten, erwarteten Zeiten) rein darf hat eine Karte mit QR-Code und scannt die -> Tür geht auf (selbst wenn derjenige auf Hawaii Urlaub macht und "einfach so" mal scannt)...

Irgendwie habe ich da noch keine Vorstellung wie das ablaufen soll...

Gruß, Joachim

[TomLee]

die person ruft dich an und du machst die tür selber remote auf.

Oldschool, da wär ich auch sofort mit dabei wenn alles so bleiben würde wie es immer war, Schlüssel hinterlegen war bisher immer gut, die Leute brauchen (meiner Meinung nach) aber heutzutage so "Ferz".

[TomLee]

Du hast einen QR-Code an der Tür kleben, jemand kommt und scannt den und kommt rein (wenn das erwartete Zeitfenster zutrifft)?

Ja, so.

[tomster]

Türöffner.

Auch wenn ich immer noch nicht verstanden habe, was genau Du womit, warum und wozu scannen willst:
QR geht bei meiner Türsprechstelle (Esenta SIAS) out-of-the-box. Einfach QR-Code am Handydisplay vor die Kamera halten und die Tür geht auf (auf Wunsch auch mit Zeitfenster). Geht aber (bislang) nur mit numerischen Codes.

--edit--
Antwort hat sich überschnitten.
Nochmal langsam, damit ich es auch verstehe.
Du klebst einen QR-Code neben die Tür. Dieser wird von "jemand" mit dem Handy gescannt (wohl URL o.Ä.). Den Link muss der "Jemand" dann anclicken. Über z.B. HTTP-Request wird dann der Event-Trigger via "mobile Daten" und Dein Internet an Dein FHEM geschickt und die Tür geht auf. Klingt kompliziert.. Und - mit Verlaub - auch nicht sonderlich sicher, weil es ja durchaus mehrere "Jemands" geben könnte...

Wäre es da nicht einfacher z.B. einen ESP32CAM hinter das Küchenfenster zu klemmen, welcher den zuvor per SMS/Email/Whatsapp/etc. an genau EINE Person versendeten QR-Code erkennt und den Trigger via deinem lokalen WLAN z.B. per MQTT an FHEM schickt?
Auch wenn ich selbst dafür keine Patentanleitung parat habe (Tante Google hat da sicher was), dürfte sowas in der Art doch etwas einfacher und deutlich "sicherer" sein, oder?

[TomLee]

Jeder der bei dir (zu bestimmten, erwarteten Zeiten) rein darf hat eine Karte mit QR-Code und scannt die -> Tür geht auf (selbst wenn derjenige auf Hawaii Urlaub macht und "einfach so" mal scannt)...

In meinem Fall macht er aber mit Sicherheit keinen Urlaub auf Hawaii, der kommt 100 % zu dem Zeitpunkt +/- den er mir zuvor mitgeteilt hat.

[TomLee]

QR geht bei meiner Türsprechstelle (Esenta SIAS) out-of-the-box.

Hab ich ja nicht. Aber es genau andersrum anzugehen wie meine Gedanken dazu bisher find ich gut, muss ich mal recherchieren, gibts bestimmt ne Bastellösung mit ESP32 und Kameramodul.

[tomster]

War auch mein Ansatz -> siehe edit oben (der sich wieder überschnitten hat).

[tomster]

Oder mit einem alten Smartphone (ungetestet):
https://www.bytebang.at/Blog/Use+your+smartphone+as+IoT+enabled+QR+Scanner

[TomLee]

Das scannen mit der Html-Seite klappt zum Test am Notebook, eine Verbindung zum MQTT2_SERVER hab ich bis jetzt aber noch nicht hinbekommen, egal ob mit oder ohne aktiviertem TLS (auf beiden Seiten).

Wie soll sowas aber in der Realität aussehen, das Smartphone hat dann ständig die Webseite offen / das Display an ?

Edit. Vorstellen kann ich mir das man da was drehen kann mit einem Android Handy aber bei einem alten Iphone ?

[tomster]

Keine Ahnung, hab's ja nicht getestet
Aber vielleicht geht da ja was auf Android mit Fully wenn es der Handybrowser/Displaysperre nicht kann...

[TomLee]

Das Dialogfeld welches aufpoppt um den Zugriff auf die Kamera zu erlauben klappt nur über die URL bei mir:
https://tinyurl.com/qr2mqtt

Wenn ich die Seite bei mir lokal speichere und aufrufe kommt die Abfrage nicht, hmm.

[TomLee]

eine Verbindung zum MQTT2_SERVER hab ich bis jetzt aber noch nicht hinbekommen, egal ob mit oder ohne aktiviertem TLS (auf beiden Seiten).

Hier gings auch um die gleiche Meldung die ich habe, nur steht am Ende nicht des Rätsels Lösung, nur das es plötzlich klappt.

[tomster]

Schreib den user doch an...

P.S. Der Link in Deinem Post geht nicht. Da steht ein "," anstatt eines "="

[Otto123]

Hallo Thomas,

genau genommen ist doch Deine ursprüngliche Idee nur ein umständlicher Knopf der auch noch übers Internet geht.
Aber so etwas gab es schon als Lösung: https://forum.fhem.de/index.php?topic=125319.0

Den umgekehrten Ansatz finde ich interessanter. Die ESP32 Cam Videos zur QR Code Erkennungen sehen für mich allerdings eher nach Problem anstatt Lösung aus.

Nur mal laut gedacht:
Wenn es keine gescheite QR Erkennungs App mit MQTT Anbindung gibt was wäre mit so etwas wie einem Smartphone / Raspberry o.ä. mit Motion Eye und dann die Bilder an den Linux Rechner schicken dort erkennen und auswerten?
Hier im Forum gibt es doch so einen Ansatz mit Gesichtserkennung, kann man das nicht auf QR um basteln? QR muss doch leichter sein als Gesicht?
https://forum.fhem.de/index.php?topic=95604.0

Gruß Otto

[tomster]

Wenn Raspis nur nicht so teuer geworden wären in letzter Zeit...
Für openCV, o.Ä. brauchst Du schon ganz schon Rechenleistung auf dem Pi.
Hier gibt es eine relativ neues Projekt mit Pi, allerdings wohl mit "echtem" QR-Scanner. Dafür mit Codeverwaltung, etc.:
https://forums.raspberrypi.com/viewtopic.php?t=337959

--edit--
Laut deren insta-Account haben die Jungs dort wohl letztendlich auch auf einen ESP32 gesetzt. Ich hab nur noch keine Details auf der Website gefunden!

Ich weiß noch nicht, ob @TomLee die Mimik als dauerhafte Zutrittskontrolle nutzen möchte oder nur für ein paar Mal Handwerker. Ich bin bislang von Letzterem ausgegangen.
Bei Ersterem mag es vielleicht sogar günstiger sein, einen fertigen (Wiegand-)Scanner zu installieren und diesen an FHEM anzubinden.

[Wernieman]

So blöd es sich anhört, würde ich bei solchen Probleme auf ein Zahlencode/eingabe setzen. Kann man auch relativ leich als "Einmalcode" realisieren. Hat den Vorteil, das der Entsprechende wirklich da sein muß, wo er sein sollte (Wie eben auch bei QR-Code erkennung)

Alles andere sehe ich irgendwann als "Overengeneering".

@Otto:
Ja es gibt Biblioteken dafür. Wird ja auch bei anderen Maschienen so gemacht. Diese sind sogar (Meines Wissens) Open Source

Edit
tomster war schneller, trotzdem wollte ich absenden ...

Edit2:
tomster hat auch Recht mit einer Fertigen Lösung. Gibt schließlich ausgereifte (und bezahlbare) Produkte dafür ....

[frank]

für den spieltrieb sicher alles schöne ideen. 
wenn aber eine taube auf den OR code kackt, gibt es schon die ersten probleme.

oldscool anrufen macht zwar kein spass, aber funktioniert und ist einigermassen sicher, da erstens die zeit passen muss und zweitens die telefonnumer und drittens die stimme.

[TomLee]

Hab mich gestern noch ewig, auch wenn klar war das es sinnfrei ist / nie umgesetzt wird, mit dem qr2mqtt beschäftigt. Das die Seite sich nicht mit dem MQTT2_SERVER verbindet liegt mein ich daran das qr2mqtt darauf basiert:

https://github.com/eclipse/paho.mqtt.javascript?utm_source=cdnjs&utm_medium=cdnjs_link&utm_campaign=cdnjs_library

Dazu hab ich den Thread ausgemacht und glaube das wird halt weiterhin nicht vom MQTT2_SERVER unterstützt.

Nächstes Bastelprojekt wird auf jeden Fall die ESP32-Cam Variante, hab ich mir gestern mal bestellt, auch wenns nur Erfahrung wird die dabei rumkommt.

Mir geht auch durch den Kopf sowas mit einem Klingeltaster (der long, short, double-click etc. kann) und einer Tastenkombination umzusetzen, aber das kann ich mir vorstellen das man das nicht jedem antun darf/kann -> vermutlich auch sinnfrei.

So ein Tastenfeld (Edelstahl -> weil ich da sowieso drauf stehe) wäre eigentlich die vernünftigste Lösung, die geht mir sowieso schon Ewigkeiten durch den Kopf, vorallem weil sowieso eine neue Haustür geplant ist (zwecks Einbau in den Rahmen).

wenn aber eine taube auf den OR code kackt, gibt es schon die ersten probleme.

Hallo, die ursprüngliche Idee den Code neben der Tür anzubringen ist schon längst verworfen 

oldscool anrufen macht zwar kein spass, aber funktioniert und ist einigermassen sicher, da erstens die zeit passen muss und zweitens die telefonnumer und drittens die stimme.

Nachts um 2 Uhr ja, ja. Irgendwann will man aber auch seine Ruhe haben.

[Beta-User]

Vielleicht auch eine praktikable Alternative, wenn du den Anruf nicht selbst engegennehmen willst: https://wiki.fhem.de/wiki/SIP-Client#Auf_Anruf_warten_und_DTMF-T.C3.B6ne_empfangen

[TomLee]

Thx, SIP will ich sowieso endlich mal anschauen (geht mir schon seit Tagen auch durch den Kopf), weil ich mich schon immer Frage ob ich die Relais des 2TSM Modul meiner Auerswald Commander Basic (die ist nur noch wegen dem 2TSM-Modul in Betrieb) damit steuern kann. War ich gestern/heute sogar dran deswegen (an der Anlage), aber wie solls anders sein beim TomLee -> immer nur Probleme, kein Systemtelefon mehr, neueste FritzBox USB-Fernanschluss (bzw. egal welche Version) lässt sich nicht mehr auf dem alten PC (Win7) und auf dem neusten (Win11) installieren -> also nur noch direkt an der Anlage (USB->Seriell-Kabel, COM1) Zugriff auf die Anlage.

[TomLee]

Bevor jemand jetzt mit LAN-CAPI kommt, ja da will ich mich auch einlesen.

[TomLee]

Mir wird gerade bewusst das ich hier im Thread bisher etwas entscheidendes ausgelassen habe, anscheinend weils für mich normal ist, die Tür kann ich einfach anrufen zum öffnen, seit mittlerweile mehr als 20 Jahren.

[TomLee]

Der ESP32 ist schon da und ich hab noch nicht wirklich ein QR-Code-Reader Projekt ausgemacht ...

[betateilchen]

Warum muss ich die ganze Zeit an "Fuhr multitronic 881" denken?

[TomLee]

... oder nur für ein paar Mal Handwerker

Es gibt genau sechs User hier im Forum, die in Frage kommen, das du das so formulierst, schliesse mindestens drei, eher vier, aus.
Mich fuchsts mit wem du Kontakt hast ?

[Otto123]

Der ESP32 ist schon da und ich hab noch nicht wirklich ein QR-Code-Reader Projekt ausgemacht ...

Ich habe mir gestern das angeschaut. Das ist aber wenig überzeugend https://www.youtube.com/watch?v=tDk3hqSfmGw

[TomLee]

Wegen dem wenig überzeugend frag ich ja, danke aber das dir überhaupt Gedanken darüber gemacht / damit beschäftigt hast.

[Otto123]

Mein Modul ist heute auch gekommen    aber hatte noch keine Zeit.

[tomster]

In diesem Projekt wird ESP32Cam nur als "Webcam" genutzt. Die Auswertung erfolgt dann via openCV auf einem PC, Raspi o.Ä.
https://how2electronics.com/qr-code-scanner-with-esp32-cam-module-opencv/

Wie aber bereits geschrieben, würde ich auf "was Fertiges" setzen. Alles in einem Gehäuse, Wiegand, 4 Drähte. Feddich

Und nein, ich hatte mit niemandem Kontakt. Ich nutze die QR Funktion in meiner Türstation eben genau dafür. QR Code an Handwerker geschickt und er kann auch kommen, wenn keiner da ist.

[TomLee]

Vielleicht auch eine praktikable Alternative, wenn du den Anruf nicht selbst engegennehmen willst: https://wiki.fhem.de/wiki/SIP-Client#Auf_Anruf_warten_und_DTMF-T.C3.B6ne_empfangen

Ich frage mich wegen der Anmerkung:

Die verwendete Library Net::SIP fordert mehr Ressourcen als RaspberryPi, BananaPi & Co hergeben.

ob ich das meinem FHEM-Server (RasPi3b+) antun soll, da läuft eigentlich nicht wirklich viel drauf, CPU-Last liegt i.d.R. bei 5-6 %, ab und an kurzzeitig bei +/- max 20% ?

[Beta-User]

Ich frage mich wegen der Anmerkung:

ob ich das meinem FHEM-Server (RasPi3b+) antun soll, da läuft eigentlich nicht wirklich viel drauf, CPU-Last liegt i.d.R. bei 5-6 %, ab und an kurzzeitig bei +/- max 20% ?

Hmm, weiß nicht. Bei mir läuft FHEM schon "ewig" auf einer x86-Maschine. Habe das Modul aber auch schon sehr ewig im Einsatz, und wenn, ist auch ein 2-er Pi mit "nur FHEM" deswegen nicht komplett in die Knie gegangen. Ist vielleicht einen Test wert.

[TomLee]

Ok, danke, ich fahr jetzt runter, mach ein Backup der SD, und freu mich schon drauf das ich das jetzt endlich teste.

[TomLee]

Toll, hab in der Vergangenheit schon mit einigen Wemos D1 Mini hantiert, bei keinem einzigen hatte sich bisher die Mikro-USB-Buchse gelöst, bei dem ESP32 Modul das ich jetzt bekommen habe war das nach zwei drei Mal flashen gleich der Fall 

[TomLee]

https://how2electronics.com/qr-code-scanner-with-esp32-cam-module-opencv/

Hi,

damit hab ich mich die Tage beschäftigt und das Python-Script auf das nötigste angepasst:

Code Auswählen Erweitern


#!/usr/bin/python3

# https://how2electronics.com/qr-code-scanner-with-esp32-cam-module-opencv/

import cv2
import numpy as np
import pyzbar.pyzbar as pyzbar
import urllib.request
import time
import paho.mqtt.client as mqtt

# MQTT
broker = 'bli'
port = 1883
clientid = 'doorpen'
username = 'bla'
password = 'blub'


url = 'bleb/'


prev = ""
pres = ""
while True:
    img_resp = urllib.request.urlopen(url+'cam-hi.jpg')
    imgnp = np.array(bytearray(img_resp.read()), dtype=np.uint8)
    frame = cv2.imdecode(imgnp, -1)
    #_, frame = cap.read()

    decodedObjects = pyzbar.decode(frame)
    for obj in decodedObjects:
        pres = obj.data
        if prev == pres:           
            pass
        else:
            print("Data: ", obj.data)
            # MQTT Connection
            client1 = mqtt.Client(clientid)
            client1.username_pw_set(username, password)
            client1.connect(broker, port)
            client1.loop_start()
            client1.publish("house/doorqr", obj.data)
            client1.disconnect()
            client1.loop_stop()
            prev = pres
            #time.sleep(15)
            #prev = ""

Ja, via MQTT, paho.mqtt.client hab ich sowieso installiert und wie es mit telnet umgesetzt wird hab ich keine Lust bisher gehabt mich mit zu beschäftigen.

Das if verhindert das der QR Code mehrfach ausgelesen wird, hält man den QR Code vor die Kamera wird der sonst mehrfach (sehr oft) ausgelesen, je nachdem wie lange man ihn davor hält.
Der Nachteil dabei, mag ich den gleichen QR Code mehrfach verwenden muss if prev == pres: erstmal wieder nicht zutreffen, weil prev halt solange pres bleibt bis ein anderer Code ausgelesen wird.

Meine Idee momentan, keine Ahnung ob ich da jetzt auf dem Holzweg bin, nach einem Schleifendurchgang 15 Sekunden zu warten (nichts zu tun) und dann prev einfach auf "nichts" zu setzen.
Mein Versuch das mit time.sleep  zu machen geht schonmal nicht, dann wird nach 15 Sekunden trotzdem der zuvor ausgelesene Code ausgegeben. Mit wait hab ich auch schon experimentiert, aber auch nicht hinbekommen.

Gibts hier jemanden der sich mit Python auskennt und mir sagen kann wie man das am besten angeht ?

[TomLee]

Oh man, 

Code Auswählen Erweitern


...
time.sleep(15)
pres = ""

und nicht:

Code Auswählen Erweitern


...
time.sleep(15)
prev = ""

Trotzdem passt was noch nicht, wenn man den Code ein paar Sekunden vor die Kamera hält, wird er zwar nur einmal übertragen, nach 15 Sekunden aber ein weiteres mal und je nachdem wie länge man den Code vorgehalten hat kann es passieren das nach weiteren 15 Sekunden wieder eine Ausgabe erfolgt.

[Otto123]

Wenn ich diesen Code verstehen würde 
Dieser Code macht eine Erkennung des QR Codes aus den Bildern des Live Streams?
Erkennt man ob ein qr code erkannt wurde oder ob das Bild leer ist?

[TomLee]

Wenn ich diesen Code verstehen würde 

Frag ja auch nicht dich sondern nach irgend jemandem der sich mit Python auskennt 

Hab vor ein paar Tagen auch null verstanden, wenn man aber Stück für Stück die wenigen verbliebenen "Kommandos" ( urllib.request.urlopen, np.array, img_resp.read, cv2.imdecode ...) in dem Skript nachliest (https://docs.opencv.org oder https://www.geeksforgeeks.org), ist es ganz einfach nachvollziehbar 

Dieser Code macht eine Erkennung des QR Codes aus den Bildern des Live Streams?

Ja, genau. Alles andere hab ich aus dem Skript rausgeworfen, da gehts nur drum das ein Fenster mit dem QR-Code in der Shell angezeigt wird.

Erkennt man ob ein qr code erkannt wurde oder ob das Bild leer ist?

Da sollte eigentlich alles passen, das funktioniert mMn alles sehr gut.

Ich könnte am Ende das prev = pres einfach weglassen, dann wird aber zig mal in nur nur kurzer wo man den QR Code in die Kamera hält die Schleife durchgegangen -> der "Code" gesendet ->Event in FHEM erzeugt. Das könnt ich mit event-min-interval abfangen am Ende. Gefällt mir aber nicht, der "Verkehr" bleibt ja trotzdem.

Ich hätte gerne eine Lösung das die Schleife nur alle 15 Sekunden durchgegangen wird, so hab ich es zumindest mir bis jetzt zusammengereimt könnte ene vernünftige Lösung sein.

[Otto123]

nochmal nachgefragt: ist pres z.B. leer wenn kein qr code erkannt wurde? Oder gibt es ein anderes Ergebnis wenn in der Schleife kein qr Code erkannt wurde?

Wenn ja würde ich diesen Teil abfragen und dann erstmal verzögern. Nach einer Zeit wieder in den Teil der Schleife wo der erste qr Code gewinnt.

[TomLee]

nochmal nachgefragt: ist pres z.B. leer wenn kein qr code erkannt wurde? Oder gibt es ein anderes Ergebnis wenn in der Schleife kein qr Code erkannt wurde?

'nicht-erkannt' Ereignisse gibts nicht, pres ist solange der alte QR Code bis irgendein anderer erkannt wird.

Wenn ja würde ich diesen Teil abfragen und dann erstmal verzögern. Nach einer Zeit wieder in den Teil der Schleife wo der erste qr Code gewinnt.

Brauch jetzt erstmal vermutlich was im Bauch, dann schau ich nochmal ob ich versteh wie das gemeint ist, nach dem if prev == pres: hab ich auf jedenfall auch schonmal probiert.

[Otto123]

aber wenn Du pres vor der Zeile pres = obj.data mit etwas anderem bestückst, wird es dann von obj.data nur überschrieben wenn qr erkannt oder immer mit dem letzten erkannten?

[TomLee]

Erst was essen, dann schau ich vlt. nochmal heute, wann nicht, morgen.

[TomLee]

Hab mir eben mal den Sketch angesehen:

https://www.makeuseof.com/scanning-qr-codes-with-esp32-cam/

Hier wird auch ständig/solange der Code ausgelesen wie man ihn vor die Kamera hält.

Payload: https://www.makeuseof.com/author/marcio-teixeira/

Code Auswählen Erweitern

Found QRCode
Invalid: ECC failure

Found QRCode
Payload: https://www.makeuseof.com/author/marcio-teixeira/

Found QRCode
Invalid: ECC failure

Found QRCode
Payload: https://www.makeuseof.com/author/marcio-teixeira/

Found QRCode
Payload: https://www.makeuseof.com/author/marcio-teixeira/

Found QRCode
Invalid: ECC failure

Mir gefällt das aber, alles mit nur einem Sketch umzusetzen, statt zusätzlich noch ein Pythonscript zu bemühen zum auswerten.
Allerdings ist die Erkennung besser bei der Lösung mit OpenCV.
Hier muss man schon in bestimmtem Abstand zur Kamera den Code hinhalten.
Schau jetzt mal ob ich das mit pubsubclient hinbekomme die Daten dann direkt via MQTT zu übertragen. Wenn das klappt dann ist das halt für ein paar Sekunden so das es viel "Verkehr" gibt, soviel ist es ja auch nicht, etwas mehr wie einmal pro Sekunde und ich lös das mit event-min-interval.

[TomLee]

Also der Ansatz es nur mit dem zuletzt verlinkten Sketch umzusetzen gefällt mir zwar, die Auswertung ist aber Sch...

Das hat was von der Self-Checkout-Kasse bei uns im Hornbach, da stellt man seit Monaten eine Mitarbeiterin an die Ausgangsschranke (die sich nur mit dem auf dem Kassenzettel befindlichen Barcode öffnet), weil nur sie genau weiß wie der Barcode auf den Scanner zu legen ist damit sich die Schranke sofort öffnet.

Ich bin wieder bei dem OpenCV-Python-Script, da klappt das auslesen im Abstand von ca. 10-50 cm einwandfrei, egal wie man das Handy hält oder der Code auf der falschen Seite liegt.

Code Auswählen Erweitern


#!/usr/bin/python3

import cv2
import numpy as np
import pyzbar.pyzbar as pyzbar
import urllib.request
import time
import paho.mqtt.client as mqtt

# MQTT
broker = 'bli'
port = 1883
clientid = 'doorpen'
username = 'bla'
password = 'blub'


url = 'ble'


prev = ""
pres = ""
while True:
    img_resp = urllib.request.urlopen(url+'cam-hi.jpg')
    imgnp = np.array(bytearray(img_resp.read()), dtype=np.uint8)
    frame = cv2.imdecode(imgnp, -1)
    #_, frame = cap.read()

    decodedObjects = pyzbar.decode(frame)
    for obj in decodedObjects:
        pres = obj.data
        if prev == pres:
            pass
        else:
            print("Data: ", obj.data)
            # MQTT Connection
            client1 = mqtt.Client(clientid)
            client1.username_pw_set(username, password)
            client1.connect(broker, port)
            client1.loop_start()
            client1.publish("house/qrcode", obj.data)
            client1.disconnect()
            client1.loop_stop()

Ich lass das prev = pres am Ende einfach weg , die Schleife irgendwie zu verzögern ist glaub ich der falsche Ansatz, hab das noch nicht ganz geblickt aber vermute doch mal das die while Schleife

Code Auswählen Erweitern

while True:
    img_resp = urllib.request.urlopen(url+'cam-hi.jpg') dafür verantwortlich ist wie oft die for Schleife durchgegangen wird. Was ist denn wahr was den URL-Aufruf verursacht ? Müsste man in dem Sketch vlt. die Zeiten anpassen wie oft ein Bild bereitgestellt wird ? Damit werd ich mich jetzt mal beschäftigen.

Code Auswählen Erweitern

#include <WebServer.h>
#include <WiFi.h>
#include <esp32cam.h>

// Add here ssid and pwd
const char* WIFI_SSID = "<ssid>";
const char* WIFI_PASS = "<pwd>";

WebServer server(80);


static auto loRes = esp32cam::Resolution::find(320, 240);
static auto midRes = esp32cam::Resolution::find(350, 530);
static auto hiRes = esp32cam::Resolution::find(800, 600);
void serveJpg()
{
  auto frame = esp32cam::capture();
  if (frame == nullptr) {
    Serial.println("CAPTURE FAIL");
    server.send(503, "", "");
    return;
  }
  Serial.printf("CAPTURE OK %dx%d %db\n", frame->getWidth(), frame->getHeight(),
                static_cast<int>(frame->size()));

  server.setContentLength(frame->size());
  server.send(200, "image/jpeg");
  WiFiClient client = server.client();
  frame->writeTo(client);
}

void handleJpgLo()
{
  if (!esp32cam::Camera.changeResolution(loRes)) {
    Serial.println("SET-LO-RES FAIL");
  }
  serveJpg();
}

void handleJpgHi()
{
  if (!esp32cam::Camera.changeResolution(hiRes)) {
    Serial.println("SET-HI-RES FAIL");
  }
  serveJpg();
}

void handleJpgMid()
{
  if (!esp32cam::Camera.changeResolution(midRes)) {
    Serial.println("SET-MID-RES FAIL");
  }
  serveJpg();
}


void  setup(){
  Serial.begin(115200);
  Serial.println();
  {
    using namespace esp32cam;
    Config cfg;
    cfg.setPins(pins::AiThinker);
    cfg.setResolution(hiRes);
    cfg.setBufferCount(2);
    cfg.setJpeg(80);

    bool ok = Camera.begin(cfg);
    Serial.println(ok ? "CAMERA OK" : "CAMERA FAIL");
  }
  WiFi.persistent(false);
  WiFi.mode(WIFI_STA);
  WiFi.begin(WIFI_SSID, WIFI_PASS);
  while (WiFi.status() != WL_CONNECTED) {
    delay(500);
  }
  Serial.print("http://");
  Serial.println(WiFi.localIP());
  Serial.println("  /cam-lo.jpg");
  Serial.println("  /cam-hi.jpg");
  Serial.println("  /cam-mid.jpg");

  server.on("/cam-lo.jpg", handleJpgLo);
  server.on("/cam-hi.jpg", handleJpgHi);
  server.on("/cam-mid.jpg", handleJpgMid);

  server.begin();
}

void loop()
{
  server.handleClient();
}

Ein weiteres Problem ist das das Pythonscript sich beendet wenn der Webserver nach einer Zeit nicht mehr erreichbar ist, ein paar Sekunden spannungsfreier ESP geht aber, da weiß ich nicht weiter, zu wenig bisher Erfahrung damit, da muss dann wohl eine weitere Schleife in dem Python-Script vorkommen die das verhindert ?

[Wernieman]

Code Auswählen Erweitern

while True:
Ist doch schon eine Endlosschleife ...