NEWS
Adapter mit Bilder-Upload
-
@haus-automatisierung ich schreibe in mein Adapter Verzeichnis unter /iobroker-data/Adapter.<Instanz>
Diese sind ja dafür nutzbar.
Ich bin der Meinung, das Dateien in einer jsonl nichts zu suchen haben. Genau wie sie nicht in eine Datenbank oder Redis gehören.
-
@skb sagte in Adapter mit Bilder-Upload:
Ich bin der Meinung, das Dateien in einer jsonl nichts zu suchen haben.
Meinst Du Binary-States? Die sind etwas anderes und wurden auch seit js-controller Version 6.x abgekündigt und sollten nicht mehr verwendet werden. Hast Du das hier gelesen?!
https://iobroker.readthedocs.io/de/latest/bestpractice/storefiles.html
@skb sagte in Adapter mit Bilder-Upload:
ich schreibe in mein Adapter Verzeichnis unter /iobroker-data/Adapter.<Instanz>
Ja gut, dann musst Du Dich auch selbst um den Prozess kümmern, wenn Du Dich gegen die Boardmittel von ioBroker entscheidest und das Konzept nicht gut findest.
-
@haus-automatisierung Genau, ein Bild ist ja eine Binärdatei - gut, ein Word-Dokument auch
Ich entscheide mich nicht gegen die Bordmittel - die Bordmittel greifen für meinen Anwendungsfall nicht.
Oder, ich habe andere Gedanken dazu.
Du kannst mir ja deine Sicht zu dem Vorhaben mitteilen:
Ich habe eine externe Konfigurationsseite für meinen Adapter, wo man sich eben den Energiefluss zusammenklicken kann. Ein Workspace.
Nun wurde vielfach gewünscht, auch Bilder (wie bei VIS) zu haben. Da viele User aber den Weg über die "ioBroker Dateien" nicht verstehen oder finden und auch das Adapter-Verzeichnis (www) nicht der optimale Weg ist, habe ich über die io-package.json das "dataFolder" Attribut genutzt, damit der Adapter einen Ordner im Dateisystem bekommt.
z.B.
/opt/iobroker/iobroker-data/energiefluss-erweitert.0/userFiles
Soweit so gut.Da ich ja jetzt aus der externen Konfigurationsseite die Bilder dort hinbekommen muss, wollte ich nicht wieder den Umweg gehen und den User zur internen Adapter-Konfig-Seite schicken.
Ich lese also die Bilder ein, schicke sie via
socke.emit('sendTo' ... )
an meinen Adapter. ViaonMessage
verarbeite ich die Daten weiter und schreibe sie genau in diesen Folder.Wie käme ich also "best-practice" mit ioBroker-Bordmitteln ans Ziel?
-
@skb sagte in Adapter mit Bilder-Upload:
Ich entscheide mich nicht gegen die Bordmittel - die Bordmittel greifen für meinen Anwendungsfall nicht.
Okay, aber warum nicht? Der TO hat hier doch vor Jahren auch schon mit den dafür vorgesehenen Funktionen (
writeFile
) gearbeitet, welche mit den Meta-Objekten arbeiten (und eben NICHT mit den abgekündigten Binary-States). Also alles richtig.Das machen ganz viele Adapter so und ich programmiere aktuell sogar mehrere Adapter auf die ioBroker Boardmittel um (dafür gibt es doch das Dateien-Tab im ioBroker).
Zumal es dann auch viel einfacher ist, die Daten z.B. über den Web-Adapter auszuliefern (das ergänze ich noch in der Doku).
@skb sagte in Adapter mit Bilder-Upload:
z.B. /opt/iobroker/iobroker-data/energiefluss-erweitert.0/userFiles
Ja, und die dann ins Frontend zu bekommen oder über HTTP auszuliefern ist dann unnötig kompliziert.
@skb sagte in Adapter mit Bilder-Upload:
auch das Adapter-Verzeichnis (www) nicht der optimale Weg ist
Das ist ja auch wieder ein ganz anderes Thema, ...
-
@haus-automatisierung Okay, wie kann ich denn z.B. die Bordmittel (FileUpload) von meiner externen Oberfläche nutzen bzw. dorthin dann die Dateien ausliefern?
Dazu finde ich irgendwie keine Informationen.
-
@skb sagte in Adapter mit Bilder-Upload:
on meiner externen Oberfläche nutzen bzw. dorthin dann die Dateien ausliefern?
Hier fehlen Infos, wie genau die Oberfläche aufgebaut ist. React? jsonConfig (siehe oben) oder irgendwelche Retro-Technik mit "pure js"?
-
@haus-automatisierung Wie gesagt, es ist eine externe Seite (www-Ordner), die aufgerufen wird. Ähnlich wie Jarvis das macht.
Diese Seite ist via socket.io verbunden und schreibt die eigene JSON config in die Datenpunkte.
-
Ich wüsste spontan aber auch kein Beispiel, welche Adapter noch diese älteren Oberflächen nutzen und File-Uploads implementiert haben (um sich das mal anzuschauen).
-
@haus-automatisierung Socket.io ist doch keine ältere Oberfläche
Funktioniert doch wundertbar mit websockets (Bordmittel).
-
@skb Socket-IO ist gar keine Oberfläche, sondern nur die Lib für die Kommunikation. Die wird ja nach wie vor auch in React oder jsonConfig genutzt.
Nur eben nicht mit dem Retro-jQuery-Kram usw. Und die Verknüpfung fehlt Dir ja gerade. Eventuell kannst Du es Dir ja dort abschauen.
-
@haus-automatisierung Ja, das sind ja Implementierungen, die ich bereits habe.
Also, ich lade das Bild per jQuery (Ok, oldschool - aber zuverlässig) von der Platte, reiche es direkt an das socket.emit weiter, da socket direkt files kann - ohne sie zu konvertieren. Sie kommen im Adapter an, er schreibt sie auf die Platte und gut.
Ab und an ist es aber so, das der Adapter keine Rückmeldung sendet - im Log aber eine Ausgabe erfolgt. Da hakt es gerade.
-
@skb sagte in Adapter mit Bilder-Upload:
Also, ich lade das Bild per jQuery (Ok, oldschool - aber zuverlässig) von der Platte, reiche es direkt an das socket.emit weiter
Mit
writeFile64
? Zeig mal -
@haus-automatisierung Also, aus der Konfigseite versende ich so:
const response = await new Promise((resolve) => { $("#upload_info").text(`Uploading File ${Object.keys(uploadStatus).length || 1} of ${filesLength}!`); socket.emit('sendTo', appProperties.namespace, '_uploadFile', { fileName: filename, fileData: file }, (res) => { resolve(res); }) });
im Adapter empfange ich dies so im
onMessage
Bereich:case '_uploadFile': const uploadPath = path.join(instanceDir + userFiles, obj.message.fileName); if (!fs.existsSync(uploadPath)) { this.log.info(`Uploading a new file to: ${uploadPath}`); fs.writeFile(uploadPath, obj.message.fileData, 'binary', (err) => { if (err) { this.log.error(`Could not upload the file ${uploadPath}. Error: ${err}`); this.sendTo(obj.from, obj.command, { error: err, url: null }, obj.callback); } else { this.sendTo(obj.from, obj.command, { error: null, url: obj.message.fileName, msg: 'File uploaded successfully!' }, obj.callback); } }); } else { this.log.warn(`The file trying to upload already exists: ${uploadPath}`); this.sendTo(obj.from, obj.command, { error: 'File already exists!', url: obj.message.fileName }, obj.callback); } break; Und hier kommt ab und an das Kommando nicht zurück.
-
@skb dein Adapter läuft zu 100% in/mit ioBroker?
Oder startet er rinen eigen Webserver unabhängig von ioBroker?Im ersten fall oder wenn du das per Konfig lösen willst solltest du die Funktionen von ioBroker nutzen.
Im zweiten fall solltest du es mit deinem Webserver lösen ohne Abhängigkeit zum ioBroker.
-
@jey-cee Ja, der Adapter läuft innerhalb des ioBroker. Nur seine "Klicki-Bunti"-Konfig-Oberfläche kommt über den WebAdapter. Genau wie die Inhalte, die er anzeigt.
-
@skb also kein eigener webserver, da das der Web Adapter übernimmt.
-
-
@skb sagte in Adapter mit Bilder-Upload:
Auch die socket.io Verbindung ist die von ioBroker. Alles "Bordmittel".
Ja, aber Du baust Dir damit deinen eigenen Weg via:
@skb sagte in Adapter mit Bilder-Upload:
Also, aus der Konfigseite versende ich so:
socket.emit('sendTo',Warum nicht mit
socket.emit('writeFile64',
wie oben verlinkt? Dann muss dein Adapter damit gar nichts machen und es läuft alles über das Frontend. -
@haus-automatisierung Ach, schau an. Ok, "das geht"? ... ok, wo landet die Datei dann? Wie kann man sie dann wieder abrufen?
-
@skb Sagmal klickst Du auch irgend einen Link hier an oder liest was ich schreibe?