[Adapter] Sonoff- Tasmota
-
Du meinst ob sich von true auf false oder umgekehrt
Ändert? Ja tut es.
-
Ja das meine ich - man kann den Sonoff aus ioBroker heraus via WEB-Command steuern und erhält via Sonoff Adapter die Rückmeldung bzw. weitere Daten (z.B. Temperatuen, etc.)
-
„12:32:31 MQT: Verbindung fehlgeschlagen aufgrund von 192.168.1.114:1883, rc -2. Wiederversuch in 10 sek“ `
Jetzt bin ich verwirrt. Arbeitest Du mit dem MQTT Adapter oder dem Sonoff-Tasmota-Adapter, um den es hier geht?1883 deutet auf MQTT hin, zumindest ist das dessen Standardport.
Falls Du mit dem MQTT-Adapter arbeitest, dann wäre hier der falsch Thread.
Falls Du beide Adapter gleichzeitig laufen hast, dann solltest Du den Port bei den Sonoffs und dem Sonoff-Tasmota-Adapter auf einen anderen, unbenutzten Port umstellen. Hier haben einige den Port 1500 verwendet. Das habe ich so abgeschrieben und meine Sonoffs senden noch Daten. Allerdings schalte ich sehr selten.
-
Habe ich mir gedacht, nur habe ich noch nicht herausgefunden wie das blockly aussehen muss
Gesendet von iPad mit Tapatalk
-
Hi klassisch,
Zur Zeit arbeite ich nur mit dem Sonoff Adapter. Den Port habe ich noch nicht geändert. Meinst du das es daran liegt? Eigentlich ist kein MQTT bei mir im Netzwerk am laufen.
Gesendet von iPad mit Tapatalk
-
Blockly kann so aussehen. vorher einen Datenpunkt anlegen.
-
Habe grade den Port überall geändert. Mal schauen ob es jetzt wieder besser wird.
Habe noch nicht ganz verstanden wie ich dann die eine Zeit rein bringen kann.
z.B. Um 23 Uhr aus schalten.
Gesendet von iPad mit Tapatalk
-
Den Port habe ich noch nicht geändert. Meinst du das es daran liegt? ` Ich weiss es nicht wirklich, aber ein Versuch ist es wert.
Was mich stutzig macht: Deine Fehlerlog startet mit "MQT".
Wenn ich einen Sonoff vom Stromnetz nehme und ihn mit dem Sonoff-Tasmota-Adapter ansteuere startet der Logeintrag im ioBroker bei mir mit sonoff.0, Beispiel
sonoff.0 2018-01-27 14:05:03.353 warn Client "Heizraum-Temp" not connectedDas Umstellen hast Du ja jetzt gemacht, dann hoffen wir, daß es geholfen hat. Falls nicht, hat es nicht geschadet und war einfach und schnell.
Falls Deine o.g. Fehlermeldung vom Sonoff war, dann würde ich es mal mit der Englischen Firmware testen. Denke irgendwo gelesen zu haben, daß es mit der Deutschen Version Verständigungsschwierigkeiten geben könnte. Da ich immer nur Englische Version installiert habe, kann ich das aber nicht mit Gewissheit bestätigen.
Im Großen und Ganzen scheint es bei mir zu funktionieren.
Was aber faul zu sein scheint:
Wenn ich ein Geräte abstecke und danach per ioBroker schalte, wird der Zustand rot angezeigt. Plausibel.
Wenn ich das Gerät dann aber wieder einstecke, schmiert der Adapter ab, wird aber restartet und zeigt dann das Objekt richtig an: Logeintrag
sonoff.0 2018-01-27 14:19:57.272 info Client [SonoffS20-01] connected sonoff.0 2018-01-27 14:19:55.787 info Client [SonoffS20-01] closed sonoff.0 2018-01-27 14:19:55.783 error Closed because of error sonoff.0 2018-01-27 14:19:55.771 warn Client error [SonoffS20-01]: Error: This socket is closed. sonoff.0 2018-01-27 14:19:55.753 warn Client error [SonoffS20-01]: Error: read ECONNRESET -
Hallo,
ich bin neu hier im Forum und möchte mich erstmal an der Stelle bedanken. Es ist wirklich sehr hilfreich und in den meisten Fällen kommt man alleine weiter!
Jetzt leider nicht, denn ich habe auch das Problem mit dem Sonoff Adapter. Alle Teilnehmer (Sonoff S20) verlieren regelmäßig die Verbindung zum Sonoff Adapter.
Den Port habe ich bereits gewechselt, das hat aber leider nicht zum Erfolg geführt. Den Adapter starte ich über einen Cron Job regelmäßig neu. (Finde ich unglücklich, da eventuelle Steuerbefehle hier nicht übertragen werden) Welches QoS Level benutzt der Sonoff-Adapter? Oder kann man einen "Lastwill" definieren? Dann wäre der Neustart nicht so tragisch.
Auf den Sonoffs läuft die Firmware Sonoff-Tasmota 5.11.1. Hier finde ich leider zu QoS o.ä. nichts.
Was mich wundert, ich habe wissentlich eigentlich nichts geändert. Die Sonoffs habe ich vor zwei Monaten in Betrieb genommen und sie liefen einwandfrei. Jetzt, seit ca. 2 Wochen, läuft es mehr als instabil. Das Update der Sonoffs auf 5.11.1 habe ich erste jetzt gemacht, da ich hoffte hierdurch den Fehler zu beheben. (englische Verison, nicht die deutsche) Es lässt sich keine Logik oder Regel erkennen wann die Sonoffs aussteigen. Den Debug Mode im Adapter habe ich angeschaltet, leider hilft der mir auch nicht weiter. Es ist immer der gleiche Fehler: "This socket has been ended by the other party"
Kann mir jemand erklären wodurch dies zustande kommt?
Eine Ansteuerung über Web-Request würde ich gerne vermeiden.
Gruß Alex
-
Hi,
Da heute Morgen meine Außenlampe wieder nicht angegangen ist. Habe ich gerade einen neuen Adapter installiert und nur die Außenlampe eingebunden.
Ich meine irgendwo gelesen zu haben dass für jedes gerät ein eigenen Adapter installiert werden könnte. Ob das Problem damit behoben ist und ob die Performanz darunter leidet, weiß ich noch nicht.
Gesendet von iPad mit Tapatalk
-
Ich habe jetzt mal einen mqtt adapter aufgesetzt und testweise zwei Sonoff S20 umkonfiguriert.
Falls es für jemanden von Interesse ist, hier die Konfiguration, die ich vorgenommen habe.
Sonoff Konfiguration MQTT:
Das Topic habe ich umbenannt, damit nicht alle unter dem Topic "sonoff" laufen.
Den Prefix bei Full topic habe ich nicht geändert, da es anscheinend in der Tasmota Software nicht zuverlässig geändert wird. (oder ich habe es nicht geschafft?!?)
Über MQTT kommen folgende Prefix:
1. cmnd/S20_1/…
2. stat/S20_1/...
3. tele/S20_1/...
Bei Änderung des Prefix im Sonoff werden leider trotzdem noch immer die Statements mit "stat/..." zusätzlich gesendet, so dass man gewisse Werte im ioBroker doppelt hat - also lasse ich das erstmal so wie es ist.
Das Device wird im ioBroker dann folgend angezeigt:
Den Wert unter cmnd->S20_1->POWER auf ON oder OFF setzen und der Sonoff schaltet.
Mal sehen wie lange die Verbindung hält….
-
Danke schon mal für die gestarteten Tests!
Bitte unbedingt das Ergebnis posten - ich habe die Hoffnung noch immer nicht aufgegeben, dass man die Ursache für die Abbrüche findet.
-
Der Test war leider negativ. Auch hier wieder ein Verbindungsabbruch.
Ich denke der Fehler liegt eher auf Seite der Sonoffs…
Aber wie ich da weiter kommen soll, das weiß ich leider noch nicht. Ich habe mal die neue Version Tasmota 5.11.1g geflasht. (noch nicht als Master im Git)
-
Ich melde mich mal wieder, mittlerweile läuft der MQTT und der Sonoff-Adapter seit 3 Monaten ohne einen einzigen Verbindungsabbruch auf meinem System.
Habe auch verschiedene Tasmota-Versionen die auf dem Sonoff-Adapter laufen. Auf dem MQTT-Adapter laufen mehrere Temperatur-Sensoren mit Wemos-mini und Eigenbau-Firmware.
Ich kann mir immer noch nicht vorstellen, das es an den Adaptern oder an der Tasmotafirmware liegen soll.
Systeme : Odroid XU4 mit root-Filesystem auf USB-Festplatte und Raspi 3 mit root-Filesystem auf USB-SSD_Festplatte.
Adapter sind alle auf dem neusten Stand.
-
Mein "ältester" Sonoff läuft jetzt auch 2 Monate, ohne daß ich mir solcher Probleme bewusst wäre.
Vielleicht liegt es an Randbedingungen, Nutzungen, anderen Adapter (another party)?
Bei mir:
-
OrangePi Plus 2e
-
armbian
-
Sonoff: vorwiegend Datenaufzeichnung, sehr wenige Schaltvorgänge, diese bisher noch alle manuell ausgeführt
-
Adapterliste nach Ruhr70-Skript, http://forum.iobroker.net/viewtopic.php … 698#p26698
[{"command":"iobroker.js-controller","pid":"6821","cpu":7.9,"mem":3.8,"vmem":179320,"rss":79532,"start":"Jan28","time":"146:14"},{"command":"io.web.0","pid":"6857","cpu":0.2,"mem":3.4,"vmem":174976,"rss":70132,"start":"Jan28","time":"4:16"},{"command":"io.javascript.0","pid":"6935","cpu":3.7,"mem":3,"vmem":171396,"rss":62516,"start":"Jan28","time":"68:28"},{"command":"io.admin.0","pid":"6831","cpu":4.1,"mem":1.9,"vmem":151904,"rss":40316,"start":"Jan28","time":"77:16"},{"command":"io.hm-rega.0","pid":"6847","cpu":0.6,"mem":1.4,"vmem":140980,"rss":30032,"start":"Jan28","time":"12:24"},{"command":"io.terminal.0","pid":"6919","cpu":0.1,"mem":1.3,"vmem":139092,"rss":28336,"start":"Jan28","time":"2:07"},{"command":"io.tradfri.0","pid":"6963","cpu":0.1,"mem":1.2,"vmem":136252,"rss":26192,"start":"Jan28","time":"2:09"},{"command":"io.socketio.0","pid":"6896","cpu":0.1,"mem":1.1,"vmem":135256,"rss":23744,"start":"Jan28","time":"2:06"},{"command":"io.simple-api.0","pid":"6969","cpu":0.1,"mem":1,"vmem":133160,"rss":21036,"start":"Jan28","time":"3:19"},{"command":"io.history.0","pid":"6905","cpu":9.2,"mem":1,"vmem":130608,"rss":20808,"start":"Jan28","time":"171:11"},{"command":"io.hm-rpc.1","pid":"6867","cpu":0.7,"mem":1,"vmem":132416,"rss":20712,"start":"Jan28","time":"13:55"},{"command":"io.sonoff.0","pid":"6975","cpu":0.2,"mem":1,"vmem":131016,"rss":20640,"start":"Jan28","time":"4:01"},{"command":"io.mihome-vacuum.0","pid":"6949","cpu":0.2,"mem":0.9,"vmem":131496,"rss":20440,"start":"Jan28","time":"4:57"},{"command":"io.hm-rpc.0","pid":"6837","cpu":1.1,"mem":0.8,"vmem":129728,"rss":17260,"start":"Jan28","time":"21:46"},{"command":"io.email.0","pid":"6925","cpu":0.1,"mem":0.8,"vmem":130836,"rss":16544,"start":"Jan28","time":"2:15"}]
-
-
Vielen Dank an alle die da über das Themea schreiben,
vor allem ist auch wichtig, dass jene berichten bei denen es funktioniert!
Ich vermute auch eine Kombination unglücklicher Zustände.
Mein aktueller Ansatz ist folgender:
Ich habe ja schon sehr vieles probiert, - unter anderem habe ich mein Wlan auf Legacy umgestellt (das ist ansich nicht gut) - daraufhin haben meine Sonoffs viel besser funktioniert (ob es wirklich keine Fehler mehr gab kann ich nicht mehr mit Sicherheit sagen).
Aus dieser Erkenntnis habe ich im Tasmota Code die Verbindungsart von 11N auf 11B umgestellt.
Das Wlan wieder „normal“. Hat vorerst auch funktioniert.
Dann hab ich mir 2 UNIFI AP´s geleistet. Damit haben sich die Sonoffs aufgrund der „11B“ Einstellung nicht mehr mit dem WLAN verbinden können.
Also wieder Tasmota Code geändert und geflasht
- noch immer keine Verbindung - Sonoff will noch immer 11B verbinden!Also musste ich den Flash komplett löschen.
Daher würde ich jedem raten, dass er vor dem Aufspielen der neunen Firmware den Flash löscht - offenbar ist es möglich dass Teile vom alten Code überleben.
Erst nachdem ich alle Module komplett gelöscht und neu geflasht hatte, lief das Netzwerk wieder rund.
Wie gesagt - bezüglich der Stabilität kann ich noch keine Aussage machen. Es läuft erst seit 24h.
-
Daher würde ich jedem raten, dass er vor dem Aufspielen der neunen Firmware den Flash löscht - offenbar ist es möglich dass Teile vom alten Code überleben. `
Das kann ich nur bestätigen
-
Wie genau löscht man den Flash im Vorfeld?
Gruß Markus
Getippt von unterwegs mit Tapatalk Pro.
-
Ich meine es wird nicht gelöscht, sondern mit ner leeren Datei geflasht.
Mein Versuch mit einen Adapter für jedes Gerät geht auch nicht. Closet fasst zur gleichen Zeit.
Mein iobroker ist frisch aufgesetzt und an sonnten keine Adapter installiert außer blockly
-
Ich hab das mit dem NodeMCU Flasher gemacht.
Man benötigt dazu noch ein leeres File - also mit lauter 0en.
Findet man hier:
http://www.pratikpanda.com/completely-f … sh-memory/
Wenn man ein Modul mit 1MB hat (normales Sonoff), dann reicht als Startadresse 0x00000.
Bei größeren Speichern müssen noch weitere Bereiche mit der Datei überschrieben werden.
Das hab ich auch noch gefunden, aber nicht getestet:
