UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[liv-in-sky]

habe folgendes problem und würde etwas hilfe benötigen:

ich schreibe mit einem script ein file in das iqontrol verzeichnis - dieses file ist ein "mini" htmlfile, mit einer tabelle, welches dann mit iqontrol als popup geöffnet werden kann. das funktioniert auch nur ein user hat auf die controller-version 2 umgestellt - und nun läuft es nicht mehr

der alte befehl:

fs.writeFileSync("/opt/iobroker/iobroker-data/files/iqontrol/htmlvlients.html", "beispiel-text");

nun heißt es, ich solle doch die writeFile() function nützen - leider finde ich keine beschreibung, die funktioniert - selbst das offizielle beispiel erzeugt einen fehler im script - im forum wird nur die fs.fileWrite methode genutzt

var data = fs.readFileSync('/tmp/screenshot.png');
writeFile(null, '/screenshots/1.png', data, function (error) {
    console.log('file written');
});

hat jmd eine idee, wie das richtig funktioniert

@s-bormann , @coyote
@apollon77 ( sorry - ich weiß, du hast viel mit dem controller zu tun)

=================================================================================:

NACHTRAG:

2 Lösungen als beispiel:
beispiel1 (z.b eigene video (kamera) oder bilddateien in vis sichtbar machen)

• schreiben einer datei vom linux-file-system in das iobroker-system - in diesem beispiel wird eine png datei, welche im linux-datei-system liegt, korrekt in iobroker integriert
  -in der vis kann sie unter vis.0/myfiles/img/google-img/javascript.png ausgewählt werden
  -oder über http: http://xxxx.xxx.xxx.xxx:8082/vis.0/myfiles/img/google-img/javascript.png
  -im filesystem wird die datei unter : "/opt/iobroker/iobroker-data/files/vis.0/myfiles/img/google-img " zu finden sein

var fs = require('fs'); 

 const picture= fs.readFileSync('/Daten/picture.png'); //liest linux-datei-system
writeFile('vis.0','/myfiles/img/google-img/picture.png', picture, function (error) { });   //schreibt in iobroker system

-dieser befehl löscht das file wieder:

delFile('vis.0', '/myfiles/img/google-img/picture.png', function (error) {});

• dieser befehl löscht den ordner myfile:

delFile('vis.0', '/myfiles', function (error) {});

beispiel2: (erzeugt eine txt-datei mit einem text-inhalt - z.b kann man ein html file erzeugen und dieses in iqontrol als popup anzeigen)

• es wird eine datei erzeugt, mit dem inhalt "test text" und dem namen meinedatei.txt
• -im filesystem wird die datei unter : "/opt/iobroker/iobroker-data/files/iqontrol.meta " zu finden sein

  writeFile('iqontrol.meta', '/meinedatei.txt',"test text", function (error) { });

löschen:

delFile('iqontrol.meta', '/meinedatei.txt', function (error) {});

um eine datei zu lesen:

 readFile('iqontrol.meta', 'meinedatei.txt', function (error, data) { console.log(data.substring(0, 50));;});

orginal beschreibung:

https://github.com/ioBroker/ioBroker.javascript/blob/master/docs/en/javascript.md#writefile

[coyote]

Ich kann hier zwar nicht viel zu beitragen, aber ich bin derjenige, bei dem es nicht mehr funktioniert seit dem Umstieg auf js-controller >2.0 mit redis :grin:

[apollon77]

@liv-in-sky Was für einen Fehler bekommst Du denn?

Ich würde es ggf im iqontrol meta Bereich ablegen ... da landen alle Userspezifischen Files. Also quasi "iqontrol.meta" als ersten Parameter.

Wenn das tut bitte mach mal Issue auf das Doku falsch bzw code im JS Adapter auch ;-)

[liv-in-sky]

@apollon77 sagte in wie writeFile() in js script nutzen:

"iqontrol.meta"

writeFile( "iqontrol.meta",  "/htmlclients.html", dataHelp, function(callback) {log("ee")});

im scripteditor ist alles unterkringelt (egal was in den klammern bei fileWrite() steht) - fährt man darüber steht dann:
cannot invoke ab expression whose type lacks a call signature type boolean has no call signatur" -starte ich das script trotzdem kommt sowas wie

			
javascript.2	2019-10-05 21:35:15.353	error	at Timer.processTimers (timers.js:223:10)
javascript.2	2019-10-05 21:35:15.353	error	at listOnTimeout (timers.js:263:5)
javascript.2	2019-10-05 21:35:15.353	error	at tryOnTimeout (timers.js:300:5)
javascript.2	2019-10-05 21:35:15.353	error	at ontimeout (timers.js:438:13)
javascript.2	2019-10-05 21:35:15.353	error	at Timeout._onTimeout (/opt/iobroker/node_modules/iobroker.javascript/lib/sandbox.js:1888:34)
javascript.2	2019-10-05 21:35:15.353	error	at Object.<anonymous> (script.js.Armin_Schalter.ALLERLEI.aaaaatestunifiInst2:769:5)
javascript.2	2019-10-05 21:35:15.352	error	Error in callback: TypeError: writeFile is not a function
javascript.2	2019-10-05 21:35:15.352	info	script.js.Armin_Schalter.ALLERLEI.aaaaatestunifiInst2: anfang
javascript.2	2019-10-05 21:34:55.277	error	at Timer.processTimers (timers.js:223:10)
javascript.2	2019-10-05 21:34:55.277	error	at listOnTimeout (timers.js:263:5)
javascript.2	2019-10-05 21:34:55.277	error	at tryOnTimeout (timers.js:300:5)
javascript.2	2019-10-05 21:34:55.277	error	at ontimeout (timers.js:438:13)
javascript.2	2019-10-05 21:34:55.277	error	at Timeout._onTimeout (/opt/iobroker/node_modules/iobroker.javascript/lib/sandbox.js:1888:34)
javascript.2	2019-10-05 21:34:55.277	error	at Object.<anonymous> (script.js.Armin_Schalter.ALLERLEI.aaaaatestunifiInst2:769:5)
javascript.2	2019-10-05 21:34:55.277	error	Error in callback: TypeError: writeFile is not a function

[apollon77]

@liv-in-sky Sehr Strange ... Die Funktion ist da im Code ... keine Ahnung warum er meckert. Muss BF schauen.Leg bitte Issue bei Javascript an

[liv-in-sky]

@apollon77 ich werde gerne ein issue anlegen

aber eine frage hätte ich noch um besser zu verstehen - dieses writeFile kommt eigentlich fast garnicht im forum vor - es wird eigendlich immer mit fs.writfile gearbeitet - ich vermute mal, dass dies alles erst wichtig wird, weil mit dem controllerv2 redis auch die files verwaltet - das ging ja bis da :-(

wie muss ich mir das mit der redis datenbank vorstellen ?
1- werden die inhalte der dateien in die datenbank geschrieben als ein datensatz oder
2- wird nur ein neuer datensatz mit einem link zu dieser datei erzeugt und die datei irgendwo anders (system intern) hinkopiert

im 2ten fall muss doch auch beim lesen des files mit readFile gearbeitet werden ?

@s-bormann - wie greifst du in der popup kachel auf die files zu ? nutzt du die readFile() funktion ? die kachel ist so definiert

[apollon77]

@liv-in-sky Aaaaalso. Der Fehler liegt meiner Meinung nach irgendwie im js-Adapter. Generell funktioniert alles.

iqontrol nutzt für die Anzeige im Admin die Funktion "readDir" via socket.io. Im "Live Frontend" wird das ganze vom web-Adapter geregelt, der ganz einfach per Pfad erlaubt auf alles im Storage zuzugreifen (unter /iqontrol liegen die Files vom Adapter und in iqontrol.meta liegen soweit ich weiss die Userfiles).

Und zu Deiner ersten Frage:
Das man Files nun optional auch im Redis ablegen kann (und ja, da landen dann die kompletten File-Inhalte also "binär Daten im Redis, der kann das und Objects/Files in Redis ist eine Vorstufe zu High Availabiltiy Themen für die Zukunft) ist nur ein Randthema. Im js-controller haben wir die State und Objects-Datenbanken komplett neu geschrieben.

In dem Zuge ist der Code jetzt aber so ausgerichtet das auch bei nutzung von "file" als DB-Typ hier das Redis-Protokoll für die Kommunikation genutzt wird. Bei einer "file" DB simulieren wir quasi einen Redis auf der Datenebene und alle Funktionen dahinter sind entsprechend gekapselt. Dadurch haben sich ein paar Dinge geändert wie im Detail auf die Daten im "IoBroker-File-Storage" zugegriffen wird. Früher war dies einfach ein Filesystem-Zugriff, jetzt ist das etwas mehr weggekapselt. Wir haben auch aus Sicherheitsüberlegungen das ganze etwas besser abgesichert - keiner der beteiligten Entwickler ist von der Kreativität ausgegangen das hier massiv Dateien an den "Regeln" vorbei eingeschleust werden ;-)) Genau diese Themen fallen jetzt auf.

Alle Lösungen mit "fs.write" gehen bei einem Single-Host System gut. Schon bei Master/Slave muss man darauf achten welche der Adapter wo laufen damit das alles zusammenspielt. Weiter gedacht für ein High Availablity System (sei es nur Failover System oder eine Art Cluster wo Adapter - ausser die mit lokalen Schnittstellenabhängigkeiten - quasi überall laufen könnten) ist es damit vorbei.

[liv-in-sky]

@apollon77 - bin etwas weiter und vielen dank für deine erklärung und die aufgewendete zeit

habe jetzt mal ein ganz neues script gemacht

writeFile('iqontrol.meta', '/htmltest.html', dataHelp, function (error) {
    console.log('file written');
});
readFile('iqontrol.meta', '/htmltest.html', function (error, data) {
    console.log("mein text:  ----:"+data.substring(0, 50));  
});

da funktioniert es

setzte ich den code in eine existierende function in meinem script, kommen wieder die fehler (cannot invoke ab expression whose type lacks a call signature type boolean has no call signatur")

erzeuge ich eine neue function mit dem code und rufe ich diese dann auf -> funktioniert es

ich weiß/verstehe nicht - warum es in einer schon existierenden function - die ohne probleme läuft - nicht geht
aber das ist soweit ok - hauptsache es läuft - zuminest werden die files jetzt im meta-ordner erzeugt - jetzt muss ich nur noch herausfinden, was ich in der iqontrol kachel angeben muss

auf jeden fall gehöre ich jetzt nicht mehr zu den "system-vorbei-schauflern" - das ist schon mal was

und da doch einige in zukunft das problem haben werden, kannst du ja (als neg. beispiel) auf diesen thread verweisen :-)

vielen dank

[apollon77]

@liv-in-sky Super das höre ich gern. Ich habe auch @AlCalzone mal gebeten zu schauen. Vllt hat er eine Idee.
Komisch ist es allemal.

Ich kann mir nur vorstellen das irgendwie der Sandbox-Ansatz für deine Code-Struktur ausgehebelt wird. Kannst Du mal einen Minimal-Skript bauen wo es nicht tut und hie rposten das man vergleichen kann?
Danke!

an sich sollte es per /iqontrol.meta/ erreichbar sein per web-adapter (alternativ lade per iqontrol Admin was hoch, bau es in die Visu ein und schau dir den Pfad an :-)

[apollon77]

PS: Der vorteil es offiziell zu schreiben ist das es auch im Backup landet :-)

[AlCalzone]

@liv-in-sky sagte in wie writeFile() in js script nutzen:

type boolean has no call signatur

Magst du mir mal den gesamten Code zeigen? Klingt für mich nach shadowing einer Variablen

[liv-in-sky]

@AlCalzone aber klar - bin doch froh wenn jmd hilft

scriptunifi- iqontrol-poblem.txt

momentan geht es - es geht um zeile 769 - die geht - da eine eigene function (paar zeilen drunter ) aufgerufen wird

die auskommentierten zeilen 771-773 bringen den fehler

scriptunifi- iqontrol-poblem.txt

[liv-in-sky]

@apollon77 sagte in wie writeFile() in js script nutzen:

@liv-in-sky Super das höre ich gern. Ich habe auch @AlCalzone mal gebeten zu schauen. Vllt hat er eine Idee.
Komisch ist es allemal.

Ich kann mir nur vorstellen das irgendwie der Sandbox-Ansatz für deine Code-Struktur ausgehebelt wird. Kannst Du mal einen Minimal-Skript bauen wo es nicht tut und hie rposten das man vergleichen kann?
Danke!

an sich sollte es per /iqontrol.meta/ erreichbar sein per web-adapter (alternativ lade per iqontrol Admin was hoch, bau es in die Visu ein und schau dir den Pfad an :-)

danke - das mit dem pfad /iqontrol.meta/file.html in der popup kachel als src funktioniert bei mir mit alten js-controller - @coyote wird dann sicher noch den neuen controller testen

[AlCalzone]

@liv-in-sky Mein Instinkt war richtig:

In Zukunft: Rechtsklick -> Gehe zu Definition zeigt dir wo eine Variable definiert ist:

[liv-in-sky]

@AlCalzone super ich danke dir - doppelt genutzt - wie doof

[coyote]

@liv-in-sky ich probiere nachher gerne nochmal, aber gestern Abend hat dass so nicht funktioniert, ich hatte die HTML Datei einfach zum Test mal nach iqontrol.meta kopiert und dann versucht über die angepasste src darauf zuzugreifen, ging aber leider nicht

[liv-in-sky]

@coyote

nur rein kopieren wird nicht funktionieren, da dann redis nix weiß von der datei (das funktioniert nur ohne redis(files) - wenn dann nur mit test- script vom anderen thread

[s.bormann]

Hi,

ich glaube, alles, was ich hier im Moment beisteuern könnte, wurde bereits gesagt. Mit diesem ganzen Datei-Kram war/bin ich auch total überfordert und habe mit dem try'n'error-Prinzip so lange getüftelt, bis es lief. Mir hat hier einfach ein "best practice" oder ein "how to" gefehlt. Die Nachteile sieht man jetzt, wo der 2.0er-Controller etwas strikter ist. Aber egal, so nach und nach wird das ganze immer besser und wird auch mit dem 2.0er irgendwann fehlerfrei laufen.

Da ich aber z.Zt. (noch) kein Test-System mit 2.0er-Controller habe, kann ich aktuell leider an dieser Stelle nicht weiter helfen, da mir selbst die Ahnung fehlt. Habe mir den Thread aber hier mal gespeichert - das mit dem writeFile u.s.w. werde ich ja dann - wenn ich es richtig verstanden habe - auch noch bei mir entsprechend anpassen müssen, oder?

VG

[liv-in-sky]

@apollon77 @AlCalzone

hallo - wollte backup (über console: iobroker backup) für controllerv2 machen - da kam dieser fehler -

fs.js:114
    throw err;
    ^

Error: ENAMETOOLONG: name too long, mkdir '/opt/iobroker/node_modules/iobroker.js-controller/tmp/backup/files/iqontrol.meta/<!DOCTYPE html><html

• ich habe nicht in diesen ordner geschrieben :-) aber evtl habe ich durch die writeFile-tests irgendetwas produziert :-( der name des files ist eigenlich der inhalt des files

habe gestern etwas probiert und einen fehler gemacht - meine eigentliche frage: kann ich die beiden files einfach so löschen oder sind die nun irgendwo registriert

der ordner sieht so aus

der iqontrol.meta:

[apollon77]

@liv-in-sky Es gibt in iobroker-data/files/iqontrol.meta ein File namens _data.json wo der "index" der registrierten Files drin ist.

Lso iobroker stoppen, das blöde File im verzeichnis lschen, dann das JSON da editieren und auch da rauswerfen. Alternativ versuch "iobroker file del" glaube ich von den CLI kommandos ...