Synchronisation mit langsamer Hardware

[khst]

Mich hat jetzt auch das "iobroker-Fieber" gepackt.

Ich habe begonnen, den noch in der Pipeline stehenden "irtrans"-Adapter (iRTrans: http://www.irtrans.de/de/index.php) zu entwickeln. Mit dem Beispiel-Adapter und ein wenig rumspielen hat das auch geklappt.

Mit VIS konnte ich dann meine erste "Remotecontrol-Oberfläche" erstellen und die Infrarot-Fernbedienungs-Codes an die verschiedenen Geräte schicken.

Das war ja alles sehr "zeitunkritisch".

Dann hatte ich begonnen, über den Javascript-Adapter ein Javascript zu erstellen, das eine Folge von Infrarot-Befehlen für gewisse Voreinstellungen "rauspusten" soll. Das war natürlich viel zu schnell. iRTrans braucht zwischen 50 und 80 ms bis es eine Antwort zurückschickt, d.h. bei einem normalen Adapter-Aufbau:

"subscribe" auf eine Variable z.B. "command"

adapter.subscribeStates('command');

````und dem Warten auf ein "stateChange"-Event

adapter.on('stateChange', function (id, state) { ...});

:?: Meine Fragen (wahrscheinlich auch, weil ich das Gesamtkonzept noch nicht ganz verstanden habe):

1) Wie synchronisiert man langsame Hardware, insb. wenn man eine Rückantwort abwarten muss?

2) Was soll ein Adapter machen, wenn er weitere Aufträge ausführen soll, aber noch auf eine Antwort wartet?

cachen? (aufwendig) / wegschmeissen?

3) Müssen "übergeordnete" Skripte (vom Javascript-Adapter) das Verhalten von langsamer Hardware berücksichtigen?

Gruß

KH

[vegetto]

@khst:

1. Wie synchronisiert man langsame Hardware, insb. wenn man eine Rückantwort abwarten muss?

2. Was soll ein Adapter machen, wenn er weitere Aufträge ausführen soll, aber noch auf eine Antwort wartet?

cachen? (aufwendig) / wegschmeissen?

3. Müssen "übergeordnete" Skripte (vom Javascript-Adapter) das Verhalten von langsamer Hardware berücksichtigen? `

Hallo,

ich habe nur ein Adapter geschrieben so ich bin kein Expert aber ich würde:

1. Das ist abhängig von HW: wenn das HW eine Rückmeldung sendet ist am besten. Wenn nicht, muss man probieren, um Pausenzeiten zu definieren.

2. Du kannst mit dem ACK melden, ob dein Adapter das Request prozesiert hat. Wenn Du das Adapter noch ein Request bekommt, bevor die alte prozesiert ist, hast Du zwei Optionen:

a) cachen in Adapter

b) droppen

3. Ich denke schon: ein Script sollte das ACK beruchsichtigen, bevor die Annahme macht, dass ein Kommando angenommen würde.

[khst]

Danke für die Rückmeldung.

So ähnlich hatte ich mir das auch gedacht. Rückmeldung gibt es natürlich über 'ack'. Zunächst werde ich neue Befehle, die zu schnell kommen, also bevor 'ack=true' zurückgemeldet wurde, droppen.

Mir lag es eben an einem Feedback, ob ich richtig liege.

Gruß

KH

[Bluefox]

@khst:

Mich hat jetzt auch das "iobroker-Fieber" gepackt.

Ich habe begonnen, den noch in der Pipeline stehenden "irtrans"-Adapter (iRTrans: http://www.irtrans.de/de/index.php) zu entwickeln. Mit dem Beispiel-Adapter und ein wenig rumspielen hat das auch geklappt.

Mit VIS konnte ich dann meine erste "Remotecontrol-Oberfläche" erstellen und die Infrarot-Fernbedienungs-Codes an die verschiedenen Geräte schicken.

Das war ja alles sehr "zeitunkritisch".

Dann hatte ich begonnen, über den Javascript-Adapter ein Javascript zu erstellen, das eine Folge von Infrarot-Befehlen für gewisse Voreinstellungen "rauspusten" soll. Das war natürlich viel zu schnell. iRTrans braucht zwischen 50 und 80 ms bis es eine Antwort zurückschickt, d.h. bei einem normalen Adapter-Aufbau:

"subscribe" auf eine Variable z.B. "command"

adapter.subscribeStates('command');

````und dem Warten auf ein "stateChange"-Event

adapter.on('stateChange', function (id, state) { ...});

:?: Meine Fragen (wahrscheinlich auch, weil ich das Gesamtkonzept noch nicht ganz verstanden habe):

1) Wie synchronisiert man langsame Hardware, insb. wenn man eine Rückantwort abwarten muss? `  

Z.B. im Sayit Adapter werde die Texte in der Queue gesetzt und dann nach und nach abgearbeitet.

@khst:

2. Was soll ein Adapter machen, wenn er weitere Aufträge ausführen soll, aber noch auf eine Antwort wartet?

cachen? (aufwendig) / wegschmeissen? ` Merken und als Queue abarbeiten.@khst:

3. Müssen "übergeordnete" Skripte (vom Javascript-Adapter) das Verhalten von langsamer Hardware berücksichtigen? `
   Ich denke nicht, aber man muss trotzdem eine Grenze setzten, z.B. nicht mehr als 10 Requests stapeln.

P.S. es gibt noch jemand, wer an RTrans arbeitet: http://forum.iobroker.net/viewtopic.php … 964#p16867

[khst]

Vielen Dank für die Hinweise.

Ich werde in den nächsten Tagen das "Stapeln" einbauen. Ich denke auch, dass man das auf eine vernünftige Größe begrenzen sollte.

Leider habe ich nicht jeden Tag Zeit, daran zu arbeiten.

Gruß

KH

[Bluefox]

@khst:

Vielen Dank für die Hinweise.

Ich werde in den nächsten Tagen das "Stapeln" einbauen. Ich denke auch, dass man das auf eine vernünftige Größe begrenzen sollte.

Leider habe ich nicht jeden Tag Zeit, daran zu arbeiten.

Gruß

KH `
Z.B:

var values     = [];
var processing = false;

// add new request to queue and start processing if not
function insertValue(val) {
    if (values.length > 20) {
        console.warn('To many requests. Request ' + val + ' dropped');
        return;
    } else {
        console.log('Value ' + val + ' queued.');
    }
    values.push(val);
    processNext();
}

// process next request if not processing
function processNext() {
    if (processing) return;

    if (values.length) {
        processing = true;
        processOne(values.shift(), function () {
            processing = false;
            processNext();
        });
    }
}

// process one request
function processOne(val, cbFinished) {
    // do something, e.g.
    // simulation
    setTimeout(function () {
        console.log('Value ' + val + ' processed');

        if (cbFinished) {
            // do not call in same thread
            setTimeout(function () {
                cbFinished();
            }, 0);
        }
    }, 3000);
}

// ------------------ Test
var i = 0;
setInterval(function () {
    insertValue(i++);
}, 1000);

9151_2018-12-16_13_07_05-iobroker.admin.png

[khst]

Danke für den Vorschlag. So ähnlich hatte ich mir das auch gedacht.

Gruß

KH