Adapter mit Bilder-Upload

[SKB]

@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. Via onMessage verarbeite ich die Daten weiter und schreibe sie genau in diesen Folder.

Wie käme ich also "best-practice" mit ioBroker-Bordmitteln ans Ziel?

[haus-automatisierung]

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

[SKB]

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

[haus-automatisierung]

@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"?

[SKB]

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

[haus-automatisierung]

https://github.com/ioBroker/ioBroker.socketio/blob/ff4096402fa560e3fb4ba2555767ece5fe8ae36e/lib/socketCommands.js#L881-L911

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

[SKB]

@haus-automatisierung Socket.io ist doch keine ältere Oberfläche

Funktioniert doch wundertbar mit websockets (Bordmittel).

[haus-automatisierung]

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

https://github.com/ioBroker/ioBroker.admin/blob/761ded4f4947cef7d051dd74e11b5f785e652c25/packages/jsonConfig/src/JsonConfigComponent/ConfigImageUpload.jsx

[SKB]

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

[haus-automatisierung]

@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

[SKB]

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

[Jey Cee]

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

[SKB]

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

[Jey Cee]

@skb also kein eigener webserver, da das der Web Adapter übernimmt.

[SKB]

@jey-cee Genau. Auch die socket.io Verbindung ist die von ioBroker. Alles "Bordmittel".

[haus-automatisierung]

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

[SKB]

@haus-automatisierung Ach, schau an. Ok, "das geht"? ... ok, wo landet die Datei dann? Wie kann man sie dann wieder abrufen?

[haus-automatisierung]

@skb Sagmal klickst Du auch irgend einen Link hier an oder liest was ich schreibe?

[SKB]

@haus-automatisierung Klar, tat ich Da ist die Funktion aufgeführt. Ok, in der Readme kommt dann:

writeFile64(_adapter, fileName, data64, options, callback)

Heisst im Endeffekt mache ich:

socket.emit('writeFile64', 'energiefluss-erweitert.0', 'userFiles/Bild.jpg', Bild64Daten, function()');

Die Datei bekomme ich dann auf dem anderen Weg wieder - ok.

Mit readDir bekomme ich die Dinge dann aufgelistet zurück?

[haus-automatisierung]

@skb sagte in Adapter mit Bilder-Upload:

Mit readDir bekomme ich die Dinge dann aufgelistet zurück?

Nochmal der Link...

https://iobroker.readthedocs.io/de/latest/bestpractice/storefiles.html