[Adapter] Sonoff- Tasmota

Bluefox

Zur besseren Übersicht habe ich einen neuern Post gemacht.

Es ist wieder einer bzw. zwei kurz nacheinander ausgefallen.

Log Broker von Adapter neustart bis zum Ausfall:

! x
! host.raspberrypi 2018-03-07 15:15:04.837 info instance system.adapter.dwd.0 terminated with code 0 (OK)
! host.raspberrypi 2018-03-07 15:15:00.051 info instance system.adapter.dwd.0 started with pid 7189
! sonoff.0 2018-03-07 15:13:41.420 warn Client error [Radio_Kueche]: Error: This socket has been ended by the other party
! sonoff.0 2018-03-07 15:13:41.420 warn Client error [Radio_Kueche]: Error: This socket has been ended by the other party
! sonoff.0 2018-03-07 15:13:41.420 warn Client error [Radio_Kueche]: Error: This socket has been ended by the other party
! sonoff.0 2018-03-07 15:13:41.420 warn Client error [Radio_Kueche]: Error: This socket has been ended by the other party
! sonoff.0 2018-03-07 15:13:41.419 warn Client error [Radio_Kueche]: Error: This socket has been ended by the other party
! sonoff.0 2018-03-07 15:13:41.419 warn Client error [Radio_Kueche]: Error: This socket has been ended by the other party
! sonoff.0 2018-03-07 15:13:41.419 info Client [Radio_Kueche] closed
! sonoff.0 2018-03-07 15:13:40.821 warn Client error [Disco]: Error: This socket has been ended by the other party
! sonoff.0 2018-03-07 15:13:40.820 warn Client error [Disco]: Error: This socket has been ended by the other party
! sonoff.0 2018-03-07 15:13:40.820 warn Client error [Disco]: Error: This socket has been ended by the other party
! sonoff.0 2018-03-07 15:13:40.820 warn Client error [Disco]: Error: This socket has been ended by the other party
! sonoff.0 2018-03-07 15:13:40.820 warn Client error [Disco]: Error: This socket has been ended by the other party
! sonoff.0 2018-03-07 15:13:40.819 warn Client error [Disco]: Error: This socket has been ended by the other party
! sonoff.0 2018-03-07 15:13:40.818 info Client [Disco] closed
! sonoff.0 2018-03-07 15:12:36.970 info Client [Disco] connected
! sonoff.0 2018-03-07 15:12:31.739 info Client [Radio_Kueche] connected
! host.raspberrypi 2018-03-07 15:12:09.371 info instance system.adapter.weatherunderground.0 terminated with code 0 (OK)
! host.raspberrypi 2018-03-07 15:12:00.061 info instance system.adapter.weatherunderground.0 started with pid 7021
! host.raspberrypi 2018-03-07 15:10:05.096 info instance system.adapter.dwd.0 terminated with code 0 (OK)
! host.raspberrypi 2018-03-07 15:10:00.075 info instance system.adapter.dwd.0 started with pid 6921
! sonoff.0 2018-03-07 15:09:24.570 info Client [Wandlampe_Kueche] connected
! sonoff.0 2018-03-07 15:09:24.541 info Client [Radio_Bruno] connected
! sonoff.0 2018-03-07 15:09:24.446 info Client [Radio_Kueche] connected
! sonoff.0 2018-03-07 15:09:24.372 info Client [Disco] connected
! sonoff.0 2018-03-07 15:09:24.214 info Client [Musik_Wohnzimmer] connected
! sonoff.0 2018-03-07 15:09:24.106 info Client [Wandlampe_Wohnzimmer] connected
! sonoff.0 2018-03-07 15:09:24.105 info Client [Toaster] connected
! sonoff.0 2018-03-07 15:09:24.015 info Client [Terrasse_mitte] connected
! sonoff.0 2018-03-07 15:09:17.768 info Starting MQTT authenticated server on port 1883
! sonoff.0 2018-03-07 15:09:17.629 info starting. Version 1.0.0 in /opt/iobroker/node_modules/iobroker.sonoff, node: v6.11.5
! host.raspberrypi 2018-03-07 15:09:14.820 info instance system.adapter.sonoff.0 started with pid 6866
! host.raspberrypi 2018-03-07 15:09:12.440 info instance system.adapter.sonoff.0 terminated with code 0 (OK)
! sonoff.0 2018-03-07 15:09:12.373 info Client [Disco] closed
! host.raspberrypi 2018-03-07 15:09:12.282 info stopInstance system.adapter.sonoff.0 killing pid 6856
! host.raspberrypi 2018-03-07 15:09:12.282 info stopInstance system.adapter.sonoff.0

Log Sonoff " Disco" selber Zeitraum

! 15:09:24 MQT: verbunden
! 15:09:24 MQT: tele/sonoff/LWT = online (beibehalten)
! 15:09:24 MQT: cmnd/sonoff/POWER =
! 15:09:55 MQT: Verbindungsversuch…
! 15:10:00 MQT: Verbindung fehlgeschlagen aufgrund von 192.168.0.108:1883, rc -2. Wiederversuch in 10 sek
! 15:10:11 MQT: Verbindungsversuch...
! 15:10:16 MQT: Verbindung fehlgeschlagen aufgrund von 192.168.0.108:1883, rc -2. Wiederversuch in 10 sek
! 15:10:16 RSL: tele/sonoff/STATE = {"Time":"2018.03.07 15:10:16","Uptime":"3 01:30:29","Vcc":3.510,"POWER":"OFF","Wifi":{"AP":1,"SSId":"BND_EINSATZ#24","RSSI":64,"APMac":"AC:22:05:54:82:E1"}}
! 15:10:16 RSL: tele/sonoff/SENSOR = {"Time":"2018.03.07 15:10:16","SI7021":{"Temperature":20.1,"Humidity":48.1},"TempUnit":"C"}
! 15:10:27 MQT: Verbindungsversuch...
! 15:10:32 MQT: Verbindung fehlgeschlagen aufgrund von 192.168.0.108:1883, rc -2. Wiederversuch in 10 sek
! 15:10:43 MQT: Verbindungsversuch...
! 15:10:48 MQT: Verbindung fehlgeschlagen aufgrund von 192.168.0.108:1883, rc -2. Wiederversuch in 10 sek
! 15:10:58 MQT: Verbindungsversuch...
! 15:11:03 MQT: Verbindung fehlgeschlagen aufgrund von 192.168.0.108:1883, rc -2. Wiederversuch in 10 sek
! 15:11:14 MQT: Verbindungsversuch...
! 15:11:19 MQT: Verbindung fehlgeschlagen aufgrund von 192.168.0.108:1883, rc -2. Wiederversuch in 10 sek
! 15:11:30 MQT: Verbindungsversuch...
! 15:11:35 MQT: Verbindung fehlgeschlagen aufgrund von 192.168.0.108:1883, rc -2. Wiederversuch in 10 sek
! 15:11:48 MQT: Verbindungsversuch...
! 15:11:53 MQT: Verbindung fehlgeschlagen aufgrund von 192.168.0.108:1883, rc -2. Wiederversuch in 10 sek
! 15:11:54 DNS: initialisiert
! 15:12:04 MQT: Verbindungsversuch...
! 15:12:09 MQT: Verbindung fehlgeschlagen aufgrund von 192.168.0.108:1883, rc -2. Wiederversuch in 10 sek
! 15:12:20 MQT: Verbindungsversuch...
! 15:12:25 MQT: Verbindung fehlgeschlagen aufgrund von 192.168.0.108:1883, rc -2. Wiederversuch in 10 sek
! 15:12:36 MQT: Verbindungsversuch...
! 15:12:36 MQT: verbunden
! 15:12:36 MQT: tele/sonoff/LWT = online (beibehalten)
! 15:12:36 MQT: cmnd/sonoff/POWER =
! 15:15:55 MQT: tele/sonoff/STATE = {"Time":"2018.03.07 15:15:55","Uptime":"3 01:35:29","Vcc":3.510,"POWER":"OFF","Wifi":{"AP":1,"SSId":"BND_EINSATZ#24","RSSI":64,"APMac":"AC:22:05:54:82:E1"}}
! 15:15:55 MQT: tele/sonoff/SENSOR = {"Time":"2018.03.07 15:15:55","SI7021":{"Temperature":20.1,"Humidity":48.3},"TempUnit":"C"}

Log vom anderen:

! 15:12:18 MQT: Connect failed to 192.168.0.108:1883, rc -2. Retry in 10 sec
! 15:12:29 MQT: Attempting connection…
! 15:12:31 MQT: Connected
! 15:12:31 MQT: tele/sonoff/LWT = Online (retained)
! 15:12:31 MQT: cmnd/sonoff/POWER =
! 15:15:25 MQT: tele/sonoff/STATE = {"Time":"2018-03-07T15:15:25","Uptime":"1T22:20:14","Vcc":3.186,"POWER":"ON","Wifi":{"AP":1,"SSId":"BND_EINSATZ#24","RSSI":82,"APMac":"AC:22:05:54:82:E1"}}
! 15:20:25 MQT: tele/sonoff/STATE = {"Time":"2018-03-07T15:20:25","Uptime":"1T22:25:14","Vcc":3.186,"POWER":"ON","Wifi":{"AP":1,"SSId":"BND_EINSATZ#24","RSSI":82,"APMac":"AC:22:05:54:82:E1"}}

Wireshark habe ich auch an gehabt.

Wie kann nen log hier Posten?

Nachtrag : Fast 24 Stunden ohne Ausfall. Hab nix geändert :shock: `
Ich empfehle dir WiFi Qualität zu prüfen. Liegt oft daran.

klassisch

Bei mir gibt es derzeit ein reproduzierbares Szenario und ich habe in github einen report eingestellt.

Bei mir lief alles über Wochen stabil. Dann habe ich einen Sonoff an ein remote location, die über Internet und VPN verbunden ist, verbracht. Hier kommt es durch die tägliche Zwangstrennung ab und an zu Verbindungsabbrüchen, die dann zu dem "connection ended by other party" Fehlerzustand führen. Ich habe die entsprechenden Logs eingesammelt und dukumentiert.

Wenn die Verbindung zum Sonoff abbricht und wieder zurückkehrt und dabei der "connection ended by other party" Fehler aufgetreten ist, empfängt der ioBroker-Adapter den sonoff status weiter, sendet aber anscheinend nicht mehr an den Sonoff.

Der Sonoff ist weiterhin ueber seine Website ansprechbar, ansteuerbar, auslesbar. Alles ganz normal.

Wird dann der Sonoff-adapter im ioBroker neu gestartet, läuft alles wieder, auch das Senden vom ioBroker zum Sonoff.

Aus meiner naiven Sicht könnte eine einfache mitigation des Problems so aussehen:

Wenn ioBroker Adapter im Fehlermode nach einen "connection ended by other party" Fehler steckt, sollte er versuchen, die Verbindung wieder aufbauen. Spätestens aber wenn er vom Sonoff ein (zyklisch gesendetes) Datum empfängt. Dann hätte man im schlimmsten Fall eine Totzeit in der Größenordnung der zyklischen update rate des Sonoffs, die der user ja im Sonoff einstellen kann.

TimmBo

@ Bluefox

Habe ich auch immer im Blick. Der eine sonoff "Musik Wohnzimmer" liegt neben dem Router. Habe die wlan Kanäle gewechselt. Ohne eine Änderung.

Das Problem das "klassisch" festgestellt hat kann ich bestätigen. Die Sonoff sind nur über den Broker nicht mehr zu erreichen wenn die auf ner anderen Party sind.

Übers web interface geht's ohne Probleme. Auch wenn ich die über die IP schalten lasse. Starte ich den Sonoff Adapter neu ohne was am sonoff zu machen ist alles wieder gut.

Zur Zeit lasse ich den Adapter 1x in der Stunde neu starten. Ist aber auch keine ideale Lösung da die sonoff teilweise nach 5 min wieder weg sind.

Wenn der Adapter sich wieder automatisch mit den Sonoff verbinden könnte wäre das mit Sicherheit eine bessere Lösung.

Schönen Samstag Gruß Timm

consul58

~~@Bluefox:~~

Ich empfehle dir WiFi Qualität zu prüfen. Liegt oft daran. `

Das ist mir zu einfach. Wieso kann der Adapter nicht selbständig auf Erreichbarkeit prüfen und daraus seine Schlüsse ziehen? Oder soll er das schon können, aber es funktioniert nicht?

Btw.: In FHEM laufen die Sonoffs ohne diese Probleme.

Balu0127

@bluefox

Am Wlan kann es auch nicht liegen.

Der Pi hängt bei mir am Kabel.

Wlan Signal meist bei 75 - 100%

Und warum sollten die im Sonweb dan funktionieren?

Hab mal Probiert die Aktualisierung bei Sonweb runter zu setzen auf 2 Sek. hatte dan im Sonweb immer wieder Fehler. Entweder Sonweb ist da noch nicht ausgereift oder die Sonoff können die schnellen Zugriffe nicht Verarbeiten.

Könnte ja auch sein das die Zugriffe bei Iobroker teils zu oft kommen und der Sonoff dan nicht mehr alles abarbeiten kann.

Kann das sein?

modmax

Diese Fehler "Error: This socket has been ended by the other party" hatte ich auch eine zeitlang täglich im ioBroker log,

jedoch seit 2 Wochen nicht mehr.

Die Lösung war aber etwas kompliziert, da ich meine "eigene" Firmware geflasht habe.

1.) Die Sonoffs per FTDI komoplett löschen mit einem leeren 1MB-bin-File.

2.) Die letzte Firmware aus dem Tasmota-Repo geholt (war die 5.12d).

3.) Diese Firmware dann in Atom.io/Platform.io eingebunden und die Datei

user_config.h auf meine Bedürfnisse angepat (insbes. die Webeinstellungen).

USE_DOMOTICZ und USE_HOME_ASSISTANT dabei auch auskommentiert.

MY_LANGUAGE auf de_DE gesetzt, damit alles schön in deutsch daher kommt.

In der IDE kann man nun alles bauen lassen.

Oder eben einzeln per FTDI flashen.

Seitdem hatte ich keinen einzigen dieser Fehler mehr.

Wichtig ist eben nur Tasmota 5.12.d zu verwenden oder aber die 5.11.1,

da es mit der 5.12.0 Probleme damit gibt.

Jedoch kann es dann noch zu Problemen kommen, daß der Sonoff-Adapter irgendwann mal

die Verbindung verliert und dann wieder kein Connect hinbekommt, obwohl der Sonoff selber

noch fleißig schickt.

Im Datenpunkt "sonoff.0.info.connection" kann man auch sehen, welche Sonoffs verbunden sind.

Meist verbinden sich die Sonoffs dann gleich wieder; aber selten eben auch nicht mehr,

obwohl der Sonoff noch funktioniert.

Dafür habe ich dann ein Skript geschrieben, was mir dann einen Neustart ermöglich.

Bei mir sieht das zwar anders aus als üblich, da ich virtuelle Geräte verwenden (Forum-Suche nach virtualDevice),

aber vielleicht hilft das ja etwas.

! ```
`// definierte Hosts
var devices = [];
devices.push({hostName: 'sonoff1', virtual: 'virtualDevice.Schalter.Sonoff1'});
! // bei Änderung an connections auslösen
on('sonoff.0.info.connection', function (obj) {
var connections = obj.state.val;
! // prüfe ob jedes Gerät noch verbunden ist
for (var i = 0; i < devices.length; i++) {

    var hostName  = devices[i].hostName;
    var virtual = devices[i].virtual;

! if (connections.indexOf(hostName) == -1) {
// CASE: Gerät nicht verbunden
! var delays = getStateDelayed(virtual+'.reconnects');
if ((delays.length === 0) && (getState(virtual+'.reconnects').val === 0)) {
// setze reconnects in 3 Minuten auf 1
setStateDelayed(virtual+'.reconnects', 1, true, 180000);
}
} else {
// CASE: Gerät verbunden

        // lösche laufende schedules und counter
        clearStateDelayed(virtual+'.reconnects')
        setStateIfChanged(virtual+'.reconnects', 0, true);
    }
}

})

! // bei Skriptstart
for (var i = 0; i < devices.length; i++) {
var virtualDevice = devices[i].virtual;
log('Create subscription for ' + virtualDevice, 'debug');
! on({id: 'javascript.'+instance+'.'+virtualDevice+'.reconnects', change: 'gt'}, function (obj) {
var virtual = obj.id.replace('javascript.0.','').replace('.reconnects','');
var reconnects = obj.state.val;

    if (reconnects === 4) {
        // nach 3 erfolglosen Reconnect-Versuchen Push-Over-Nachrichten versenden
        sendTo('pushover', {
            title :  'Sonoff-Neustart erfolglos',
            message: virtual
        });

    } else if (reconnects < 4) {
        log('Neustart von Sonoff: ' + virtual);
        var ip = getState(virtual+'.ipAddress').val;

! request('http://'+ip+'/cm?cmnd=Restart 1', function(error, response, body) {
if (error || response.statusCode !== 200) {
log('Fehler beim Neustart von Sonoff: ' + virtual + ' (StatusCode = ' + response.statusCode + ')');
}
// erhöhe reconnects in 3 Minuten um 1
setStateDelayed(virtual+'.reconnects', reconnects+1, true, 180000);
});
}
});
}`
! Aber im Grunde sehe ich das Problem beim Sonoff-Adaper, da er Meldungen vom Sonoff machmal anscheinend verschluckt.
! Genauso wie das "alive" auch nicht wirklich funktioniert.[/i][/i][/i]

klassisch

Vielen Dank für die Impulse zum workaround.

Deine Beobachtungen kann ich nur bestätigen. Und ich teile Deine Meinung, daß das Thema am besten beim Adapter zu beseitigen oder zumindest zu mitigieren ist.

Ist das bei Dir auch so, daß vom "abgehängten" Sonoff weiterhin Botschaften empfangen werden? Spätestens dann könnte man den Adapter neu starten.

TimmBo

Danke für die Tipps.

Drücke dir die Daumen das das Problem lösen konntest.

Nach dem selben Weg bin ich auf vorgegangen. Hatte dann ca 3 Wochen Ruhe und ohne das ich was an den Sonoff geändert habe ging das Problem wieder los.

Werde ma die neuste Firmware Flaschen und die Daumen drücken.

Mfg Timm

modmax

@klassisch

Bei mir ist das Problem auch so, daß der Sonoff was schickt, aber der Adapter nix verarbeitet.

Der Sonoff erscheint nicht mehr unter "sonoff.0.info.connection".

Und wenn der da nicht mehr drin ist (auch wenn der per Web noch erreichbar ist),

dann meldet der Sonoff-Adapter beim Sendern auch den Fehler, daß der Sonoff nicht verbunden ist.

Wird wohl vor jedem senden geprüft, ob der Sonoff in der connections-Liste drin ist; anstatt auf

das ALIVE des Sonoff zu setzen oder dergleichen.

Mein Skript habe ich eben noch mal umgeschrieben, so daß es von jedem verwendet werden kann.

Es erzeugt dann ein paar neue States im Javascript-Adapter und darüber funzt dann der Neustart.

Einzugtragen sind nur alle Geräte, die man im Sonoff-Adapter hat; könnte man sicherlich auch eleganter lösen,

so daß man nicht alle Sonoffs eintragen muß, aber da es bei mir anderes benutzt wird, sollte das reichen.

Hab das Skript nun aber nicht ausführlich getestet, sondern lediglich umgeschrieben

und geprüft, damit es lauffähig ist.

! ```
`// definierte devices
var devices = [];
devices.push('sonoff_1');
! // bei Änderung an connections auslösen
on('sonoff.0.info.connection', function (obj) {
var connections = obj.state.val;
! // prüfe ob jedes Gerät noch verbunden ist
for (var i = 0; i < devices.length; i++) {
var deviceName = devices[i];
! if (connections.indexOf(deviceName) == -1) {
// CASE: Gerät nicht verbunden
! var delays = getStateDelayed('sonoff.reconnects.'+deviceName);
if ((delays.length === 0) && (getState('sonoff.reconnects.'+deviceName).val === 0)) {
// setze reconnects in 3 Minuten auf 1, wenn keine Delay läuft und reconnects=0 ist
setStateDelayed('sonoff.reconnects.'+deviceName, 1, true, 180000);
}
} else {
// CASE: Gerät verbunden

        // lösche laufende schedules und counter
        clearStateDelayed('sonoff.reconnects.'+deviceName);
        setState('sonoff.reconnects.'+deviceName, 0, true);
    }
}

})

! // bei Skriptstart
for (var i = 0; i < devices.length; i++) {
var deviceName = devices[i];
log('Create subscription for ' + deviceName, 'debug');
createState('sonoff.reconnects.'+deviceName, 0, {type: 'number', read: true, write: false, role: 'value', name: deviceName});
! on({id: 'javascript.0.sonoff.reconnects.'+deviceName, change: 'gt'}, function (obj) {
var sonoffDevice = obj.id.replace('javascript.0.sonoff.reconnects.','');
var reconnects = obj.state.val;

    if (reconnects === 4) {
        // nach 3 erfolglosen Reconnect-Versuchen Push-Over-Nachricht versenden
        sendTo('pushover', {
            title :  'Sonoff-Neustart erfolglos',
            message: virtual
        });

    } else if (reconnects < 4) {
        log('Neustart von Sonoff: ' + sonoffDevice);
        var ip = getState('sonoff.0.'+sonoffDevice+'.INFO.IPAddress').val;

! request('http://'+ip+'/cm?cmnd=Restart 1', function(error, response, body) {
if (error || response.statusCode !== 200) {
log('Fehler beim Neustart von Sonoff: ' + sonoffDevice + ' (StatusCode = ' + response.statusCode + ')');
}
// erhöhe reconnects in 3 Minuten um 1
setStateDelayed('sonoff.reconnects.'+sonoffDevice, reconnects+1, true, 180000);
});
}
});
}` [/i][/i]

TimmBo

~~@modmax:~~

Einzugtragen sind nur alle Geräte, die man im Sonoff-Adapter hat; könnte man sicherlich auch eleganter lösen,

so daß man nicht alle Sonoffs eintragen muß, aber da es bei mir anderes benutzt wird, sollte das reichen. `

Danke erstmal für die Mühe.

Kannst du mir bitte noch verraten wo und in welcher Form ich die Geräte eintragen muss.

Würd das Skript gerne mal testen.

Mfg Timm

klassisch

Die Geräte stehen automatisch in der Liste

sonoff.0.info.connection

Wenn sich an dieser Liste was ändert, wird das Skript getriggert.

modmax

~~@TimmBo:~~

Kannst du mir bitte noch verraten wo und in welcher Form ich die Geräte eintragen muss. `

Eingetragen werden die direkt im Skript.

Wenn Du z.B. Sonoffs hast (also das was Du unter sonoff.0 siehst)

die da lauten: wc-lampe,flur-licht,..

Dann mußt Du im Skript am Anfang folgendes ergänzen.

devices.push('wc-lampe');
devices.push('flur-licht');

Das eine Device was da bereits im Skript steht ist nur zur Verdeutlichung

und kann gelöscht werden.

Die Namen entsprechen genau den Namen, die Du auf den Sonoffs

bei den MQTT-Einstellungen vergeben hast.

TimmBo

Danke …

Hab es mal so eingetragen und Teste jetzt. Ich melde mich mal wie es läuft.

schönen Abend noch Timm

Chaot

Ich habe in Zeile 67 eine Fehlermeldung: "Don't make functions within a loop"

modmax

Hab ich auch … :-

Ist aber nur ne Warnung .... Kein Fehler .... Und funktioniert trotzdem

Balu0127

Hab glaub ich was verpasst?

Wo schreib ihr das Script hin?

Chaot

Ja, die Funktion ist da. Ich wollte nur darauf hinweisen.

Mal sehen ob das jetzt besser wird.

Wobei ich immer noch meine Fritzbox im Verdacht habe. Die ist kaum noch zu bedienen seit IOBroker läuft.

modmax

@Bluefox

Ich hab mir mal den AdapterCode angesehen und da ist mir (vielleicht) etwas aufgefallen.

Vielleicht kannst Du da den Fehler erkennen .. oder ich habe noch nicht die Logik von Javascript und Adaptern komplett kapiert.

Oder meine Erkenntnisse sind voll daneben oder passen eben nicht; und bei asynchronem Javascript passe ich eh meistens.

Ist ab Zeile 467 in der "lib/server.js" zu finden.

            client.on('disconnect', function (/*packet*/) {
                if (client._sendOnStart) {
                    clearTimeout(client._sendOnStart);
                    client._sendOnStart = null;
                }
                adapter.log.info('Client [' + client.id + '] disconnected');
                client.stream.end();
                if (clients[client.id]) {
                    delete clients[client.id];
                    sendLWT(client);
                    updateClients();
                }
            });

            client.on('close', function (had_error) {
                if (client._sendOnStart) {
                    clearTimeout(client._sendOnStart);
                    client._sendOnStart = null;
                }
                if (had_error) adapter.log.error('Closed because of error');
                adapter.log.info('Client [' + client.id + '] closed');
                if (clients[client.id]) {
                    delete clients[client.id];
                    sendLWT(client);
                    updateClients();
                }
            });

            client.on('error', function (err) {
                if (client._sendOnStart) {
                    clearTimeout(client._sendOnStart);
                    client._sendOnStart = null;
                }
                adapter.log.warn('Client error [' + client.id + ']: ' + err);

                if (!clients[client.id]) return;

                delete clients[client.id];
                sendLWT(client, function () {
                    updateClients();
                    client.stream.end();
                });
	});

1.) Nur ne Kleinigkeit: in der client.on('error',…) die Zeile

adapter.log.warn('Client error [' + client.id + ']: ' + err);

hinter die Zeile

 if (!clients[client.id]) return;

setzen.

Dann würde die Fehlermeldung nur einmal ausgegeben.

2.) Die sendLWT-Befehle sind mir noch irgendwie fremd, bzw. der Ablauf nicht ganz klar,

aber die werden in den 3 Methoden anders aufgerufen.

bei "disconnect" und "close". nämlich so:

if (clients[client.id]) {
    delete clients[client.id];
    sendLWT(client);
    updateClients();
}

Bei "error" aber mittels callback:

delete clients[client.id];
    sendLWT(client, function () {
        updateClients();
        client.stream.end();
    };
});

Ich würde für alle 3 Fälle disconnect,close,error erwarten, daß sowas ausreichen würde.

if (clients[client.id]) {
    delete clients[client.id];
    updateClients();
    sendLWT(client);
}

Also erst Stream schließen, dann Client aus Liste löschen und dann erst LWT wieder senden.

Sind wie gesagt nur meine Erkenntnisse und ich bin auch kein Experte in Javascript,

aber es fiel mir eben ins Auge und deswegen die Frage ob das "nicht wiederverbinden"

wie hier im Thread auf den letzten Seiten beschrieben ist evtl. auf das Handling von "error" zurückzuführen ist.

Testen kann ich das aktuell auch nicht wirklich, sondern habe mich anhander

der hier geposteten Logfiles da durch gehangelt.

MfG Markus

modmax

@Skript-Benutzer

Wie ich selber feststellen mußte funktioniert mein Skript zu gut.

Es triggert auch, wenn der Sonoff-Adapter geschlossen wird,

da dann auch die connections zurückgesetzt werden.

Daher müßte man das Skript folgendermaßen ergänzen:

....
// bei Änderung an connections auslösen
on('sonoff.0.info.connection', function (obj) {

    if (getState('system.adapter.sonoff.0.alive').val === false) {
        // Sonoff-Adapter gestoppt; nichts zu tun
        return;
    }
....

TimmBo

Soeben ist das Skript zum Einsatz gekommen.

Hat 1a funktioniert.

  sonoff.0	2018-03-13 19:27:03.577	info	Client [Musik_Wohnzimmer] connected
javascript.0	2018-03-13 19:26:56.123	info	script.js.scripte.Sonoff.Sonoff_restart: Neustart von Sonoff: Musik_Wohnzimmer
sonoff.0	2018-03-13 19:23:56.083	warn	Client error [Musik_Wohnzimmer]: Error: This socket has been ended by the other party
sonoff.0	2018-03-13 19:23:56.083	warn	Client error [Musik_Wohnzimmer]: Error: This socket has been ended by the other party
sonoff.0	2018-03-13 19:23:56.082	warn	Client error [Musik_Wohnzimmer]: Error: This socket has been ended by the other party
sonoff.0	2018-03-13 19:23:56.081	warn	Client error [Musik_Wohnzimmer]: Error: This socket has been ended by the other party
sonoff.0	2018-03-13 19:23:56.081	warn	Client error [Musik_Wohnzimmer]: Error: This socket has been ended by the other party
sonoff.0	2018-03-13 19:23:56.080	warn	Client error [Musik_Wohnzimmer]: Error: This socket has been ended by the other party

Vielen Dank!

Hoffe trotzdem das Bluefox etwas Zeit hat um sich den Adapter mal anzusehen.

Mfg Timm

Community Forum

NEWS

[Adapter] Sonoff- Tasmota

Support us

839

32.4k

81.5k

1.3m