Adapter mit Bilder-Upload

[haus-automatisierung]

@skb sagte in Adapter mit Bilder-Upload:

der User muss Bilder über die Einstellungen des Adapters hochladen

Das war doch das Thema dieses Threads, oder nicht?

@skb sagte in Adapter mit Bilder-Upload:

wo ist dann der Speicherpfad?

Das kommt darauf an, welche Objekt-Datenbank konfiguriert ist. Bei Redis in der Datenbank direkt und bei jsonl im Dateisystem. Aber damit hat man als Entwickler dann ja nichts zu tun, sondern nutzt nur die ioBroker internen Funktionen und muss mit dem Dateisystem gar nicht arbeiten.

Habe ich im Kurs ausführlich erklärt und hier auch dokumentiert:

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

[SKB]

@haus-automatisierung Finde ich nicht so praktikabel, wenn die Bilder die jsonl oder Redis Datenbank aufblähen.

Auch muss ich über den WebAdapter die Bilder dann wieder abfragen und drum herum etwas bauen.

Aktuell 'emitte' ich base64 Bilder per Socket in meinen Adapter und speichere sie dann im dataFolder.

Abgerufen wird das Bild dann über die web.js, die den WebAdapter nutzt.

Habe aktuell nur die Thematik, das die Datei zwar hochgeladen wurde, mein Adapter sie schreibt, jedoch keine Rückmeldung an das WebSkript gibt.

[haus-automatisierung]

@skb sagte in Adapter mit Bilder-Upload:

mein Adapter sie schreibt, jedoch keine Rückmeldung an das WebSkript gibt.

Das ist ja der Vorteil von dem ioBroker-Dateisystem: Du bekommst auch Events, wenn sich eine Datei ändert (mit onFile).

@skb sagte in Adapter mit Bilder-Upload:

wenn die Bilder die jsonl oder Redis Datenbank aufblähen.

Bei jsonl liegen die ganz normal im Dateisystem unter /opt/iobroker/iobroker-data/files/. Deswegen sollte man ja auch nie manuell in diese Verzeichnisse schreiben, weil dann eben die Meta-Informationen auseinander laufen und die Events nicht mehr funktionieren. Also: Das Verzeichnis immer in Ruhe lassen.

[SKB]

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

[haus-automatisierung]

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

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