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

[apollon77]

Dann zeig mal wie du es versuchst , dann kann ich vllt besser helfen :-)

[eric2905]

Mir fehlt gerade völlig der Ansatz, wie ich anfangen soll, die vorhandenen DPs einzulesen … als ob ich unter einer temporären Amnesie leide ...

Ich brauche einen Denk-Anstoß ... besser -Antritt [Peinlich berührt …]

Ein Code-Snipplet würde mir wahrscheinlich schon reichen, um die Blockade zu lösen ….

Gruß,

Eric

[apollon77]

Was willst Du denn tun?

WIllst Du die aktivien DPs aus einer Instanz einlesen und in einer anderen Aktivieren oder was ist dein Ansatz?

[eric2905]

Ich möchte alle aktiven Datenpunkte, die per SQL aufgezeichnet werden, auslesen und ggf. als Basis für eine Kopie / als Backup nutzen.

Ich habe eine komplette (neu aufgesetzte) zweite ioBroker-Instanz und könnte den Abzug dann dort als Import nutzen, um nicht alle SQL-Aufzeichnungen wieder manuell einrichten zu müssen.

Ferner gibt es bei HMIP noch das Problem, das das Objekt ab und zu komplett gelöscht und neu angelegt wird und dabei dann natürlich ebendiese Konfig gelöscht wird.

Man könnte ein Script schreiben, was die SQL-Konfig dann wieder hinzufügt (prüfen ob gelöscht; wenn ja, dann erneut Konfig hinzufügen), usw.

Wie gesagt, mir fehlt die Initialzündung …

Gruß,

Eric

[apollon77]

Dann mach doch mal folgendes. Lege ein JS an und nennen es "alle_History_DPs_holen" und mach da mal das hier rein:

Pot. die Instanz (sql.0) anpassen

sendTo('sql.0', 'getEnabledDPs', function (result) {
    console.log(JSON.stringify(result));
    // Das was da zurückkommt kannst Du jetzt z.B. in ne Datei Speichern
});

Und zum wieder einlesen müsste man sowas bauen:

// zuerst file einlesen und unter der Annahme es kommt was rein was Du oben gespeichert hast ... in Variable "dps"
setAllHistory('sql.0', dps);

function setAllHistory(instance, data) {
    if (Object.keys(data).length) === 0 ) return; // we are done
    var currentId = Object.keys(data)[0];
    var currentData = {
        id: currentId,
        options: data[currentId]
    };
    delete data[currentId];    
    sendTo(instance, 'enableHistory', currentData, function (result) {
    if (result.error) {
        console.log(result.error);
        // aufhören
    }
    if (result.success) {
	// next one
	setAllHistory('sql.0', data);
    }
});
}

Das ganze ist jetzt frei Hand geschrieben und nicht getestet … aber so in der Art sollte es run

[eric2905]

Hi ho,

@apollon77:

Dann mach doch mal folgendes….

sendTo('sql.0', 'getEnabledDPs', function (result) {
    console.log(JSON.stringify(result));
    // Das was da zurückkommt kannst Du jetzt z.B. in ne Datei Speichern
});
```` `  

sowas in der Art hatte ich auch schon - klappt aber nicht.

Ich habe den SQL-Adapter in der Version 1.4.0 (über den Git-Installer im Admin) installiert.

Das Script 1:1 kopiert (sql.0 passt). Es läuft auch ohne Fehlermeldung durch, aber es kommt nichts zurück.

Es werden 20 Datenpunkte (Temp. und Humm.) über sql.0 aufgezeichnet (ja, Daten sind auf dem SQL-Server vorhanden :) ), aber die o.g. Abfrage liefert nichts zurück.

Die v1.4.0 ist doch die richtige, oder? Laut Github-Readme sollte es so sein.

Danke und Gruß,

Eric

[apollon77]

Fehler gefunden (kommt davon nwenn man es aus dem Gedächtnis macht):

Richtig ist:

sendTo('sql.0', 'getEnabledDPs', {}, function (result) {
    console.log(JSON.stringify(result));
    // Das was da zurückkommt kannst Du jetzt z.B. in ne Datei Speichern
});

Auch Methoden die keine Daten beim Aufruf übertragen müssen da was leeres übergeben. Fixe das Beispiel im Github nachher gleich

[eric2905]

Moin,

@apollon77:

Fehler gefunden …

Auch Methoden die keine Daten beim Aufruf übertragen müssen da was leeres übergeben. `

super - Danke Dir.

Genau das habe ich auch nicht gesehen und bin daran hängengeblieben - und einfach nicht weitergekommen … jetzt habe ich den Denk-Antritt, den ich brauchte.

Danke und Gruß,

Eric

[apollon77]

Super,

ab der nächsten js-controller Version gibts das auch offiziell das man den Parameter weglassen kann wenn er leer ist :-)

[frankjoke]

Habe einen kleinen Bug im Sql-Adapter bei der Adapter-Konfiguration gesichtet als ich heute am Testsystem schnell den Adapter installiert und was mit Flot/History testen wollte.

Habe SQLite gewählt da ich auf diesem raspi kein MySQL installieren wollte.

Nun, wenn man den Adapter konfiguriert und dann speichern will lasst er es nicht zu da für ihn die passwörter nicht ident sind mit der Kontrollabfrage!

Also musste ich kurz zur MySQL config schalten, dort idente passwörter eingeben dann zurück auf SQLite und dann speichern.

Obwohl SQLite kein passwort benötigt wird wird beim Speichern der Konfiguration diese Bedingung abgefragt.

Liebe Grüße

[apollon77]

Fix auf Github :-)

[frankjoke]

Ok, werd' ich mal testen!

Muss an Scripten basteln um die Daten von einem SQL (MySQL) auf anderen (SQLite) -Adapter zu übertragen, hab rausgefunden dass MySQL etwas zu viel Platz frisst…

[apollon77]

Hey, dann schau dir mal die anderen neuen Features der History-Adapter an … gibt Funktionen für "query", "setState", "getEnabledDPs" und sowas. Das kann man nehmen.

Aber wenn ich ehrlich bin ist SQLite vllt nicht die beste Wahl ... hatte schon einige Probleme mit "geblockten" DBs weil immer nur ein Zugriff erlaubt ist