[Adapter] Sonoff- Tasmota
-
@ple:Mal ne Frage zu SonOTA,
bin gerade dabei meine POW irgendwie zu flashen, nur komm ich irgendwie nicht voran.
Nachdem ich den POW mal mit meinem Wlan verbunden hatte und ein Firmwareupdate durchgeführt habe, sendet er nun was, geht aber nur bis 35% dann klackt er 3 mal und es beginnt von vorne. Scheint so als wäre er in einer Endlosschleife.
Ich hatte es auch mal über ein Hotspot versucht, aber der gleiche Fehler.
Noch wer eine Idee?? `
Ich kriegs einfach nicht hin mit sonota.
Schade eigentlich.
Naja, dann halt auf die altmodische Art.
Hat wer einen link mit Anleitung zum Flashen mit arduino ide? Pins sind schon angelötet.
-
müsste auch einfacher mit https://github.com/nodemcu/nodemcu-flasher
gehen
und dann nimmst dir eine fertige bin https://github.com/arendst/Sonoff-Tasmota/releases
–-
das hier ist auch ein sehr guter flasher mit dem man sogar den esp einmal formatieren kann
-
und das heute morgen um 8:00, dann hätte ich mir eine Menge Zeit gespart
Ich war schon am Mac mit Atom und platformio usw. aber ging auch nicht.
Jetzt, in 5 min geflasht.
Besten Dank.
Morgen mal die Kabeladapter anbringen und dann mal alles soweit integrieren.
Besten Dank
-
Es funktioniert!!!!
Ich hoffe ich freue mich nicht zu früh, aber seit mehreren Tagen kein Ausfall mehr, alles läuft perfekt.
Was habe ich geändert:
Bei meinem Asus AC87 beim den WLAN Einstellungen auf Legacy umgestellt.
Bei welchem Gerät nun der wahre Fehler liegt kann ich natürlich nicht zweifelsfrei beantworten, aber ich bin somit einen riesen Schritt weiter. Danke noch mal an alle die mich vielleicht durch die eine oder andere Meldung auf neue Wege gebracht haben!
Was mich noch sehr interessieren würde, ob jemand diese Module mit einem Wlan AP von Ubiquiti in Betrieb hat. Wenn ja, dann bitte um Angabe mit welchem Typ.
LG Schubi
-
Es funktioniert!!!!
Ich hoffe ich freue mich nicht zu früh, aber seit mehreren Tagen kein Ausfall mehr, alles läuft perfekt.
Was habe ich geändert:
Bei meinem Asus AC87 beim den WLAN Einstellungen auf Legacy umgestellt.
Bei welchem Gerät nun der wahre Fehler liegt kann ich natürlich nicht zweifelsfrei beantworten, aber ich bin somit einen riesen Schritt weiter. Danke noch mal an alle die mich vielleicht durch die eine oder andere Meldung auf neue Wege gebracht haben!
Was mich noch sehr interessieren würde, ob jemand diese Module mit einem Wlan AP von Ubiquiti in Betrieb hat. Wenn ja, dann bitte um Angabe mit welchem Typ.
LG Schubi `
Ich war auf unifi AC Pro umgestiegen. Meine Probleme mit den sonoff s in Zusammenhang mit sonoff Adapter habe ich nicht in Griff bekommen. Bin wieder zurück zur hue Emulation. Jetzt ohne Unterbrechung. Am WLAN liegt mein Problem also nicht. -
Ich habe meine Sonoff POW gerade dran, AP AC Pro besitze ich auch. Der Trockner ist gerade am laufen.
Aber mal ne Frage, bekomme ich die Leistungwerte des Sonoff POW garnicht in iobroker rein?? Wollte damit Strom mitloggen, dann können die HOmematic dann raus.
Gruß
-
Hi,
bei mir läuft das WLAN auch über einen Ubiquiti Unify AP AC Pro. Und ich hatte mit den Sonoff und Tasmota auch immer wieder Abbrüche, wenn ich sie via MQTT eingebunden hatte (sowohl mit dem Adapter hier, als auch mit dem "großen" MQTT-Adapter. Seit ich sie einzeln über Hue-Adapter laufen habe, flutscht alles. Es scheint also so, als ob die Sonoff (zumindest unter Tasmota, andere Firmware habe ich nicht getestet) mit der Zeit Probleme im MQTT-Betrieb bekommt. Wobei es bei mir auch immer die 2 Sonoff traf, die das relativ schlechteste WLAN-Signal hatten. Beides Basic
Gruss, Jürgen
-
Das finde ich sehr interessant, dass die Verbindung via MQTT bei anderen auch Probleme bereitet.
Das komische ist nur dass ich seit der Umstellung auf Legacy in Wlan-AP keine Problem mehr habe.
Ich hatte das selbe Problem auch bei der Verwendung von ESP-Easy.
Offenbar ist in den Bibliotheken von MQTT oder WIFI beim ESP8266 etwas faul. Was mich dann aber etwas wundert, dass die Software (Tasmota, ESP-Easy) munter weiterentwickelt wird wenn da etwas nicht passt. Gibt es wirklich so wenige bei denen es nicht funktioniert?
Ja ich weiß, das sollte man in den entsprechenden Foren posten…
Ich hab schon viel gelesen - aber noch nichts brauchbares gefunden, aber vielleicht weiß noch jemand mehr.
Folgendes war dabei:
https://github.com/peterhinch/micropython-mqtt
https://community.ubnt.com/t5/UniFi-Wir … -p/1881869
https://forum.micropython.org/viewtopic.php?t=4028
Ich bin halt auch kein Programmierer - ich verstehe nur so ungefähr worum es hier gehen könnte.
Eventuell sollte man dafür einen eigenen Thread dafür aufmachen!?
LG Schubi
-
Wie macht sich das denn Bemerkbar bei euch? und wann tritt das auf?
Ich habe gerade eine Trocknerladung fertig. Soweit keine Abbrüche oder so.
Was mich mehr interessiert, wie krieg ich die Verbrauchswerte mit dem POW rein? Im Log stehen die soweit
Gruß
-
Hi,
bemerkbar gemacht hat es sich dann einfach mit Fehlern im ioBroker-Log, dass irgendein Gerät via MQTT nicht mehr erreichbar ist bzw. sich länger nicht mehr gemeldet hat (habe die Meldung leider nirgends archiviert). Und im Sonoff-Adapter war es dann zusätzlich so, dass dieser sogar irgendwann auf gelb gesprungen ist und ich ihn manuell wieder starten musste (oder das eben regelmäßig via cron hätte tun müssen).
Via Webinterface waren die Geräte (meist) dennoch erreichbar.
Wobei, wie schon geschrieben, beide nicht den idealen WLAN-Empfang hatten. Laut Sonoff-Webinterface bei einem nur 28%. Durch Umstellen das AP AC Pro ist der schlechteste Wert mittlerweile bei 48%, aber mit der HUE-Emulation lief es auch bisher dann problemlos. Im Log waren zwar ab und an Meldungen, dass das eine oder andere HUE-Gerät nicht erreichbar wäre, aber ein paar Minuten später war es dann doch wieder da ohne dass ich hätte eingreifen müssen oder ein Adapter sich verabschiedet. Bei MQTT hiess Verbindungsverlust (soweit ich mich erinnere) eben Verbindungsverlust bis ich manuell eingreife und das Gerät oder den Adapter mal manuell anschiebe…
Ich vermute mal, dass die Sonoffs einfach heikel auf zu schwachen WLAN-Empfang reagieren und die Verindung dann unzuverlässig ist oder schnell und oft abreisst und das bei MQTT einfach mehr Probleme macht als bei der HUE-Emulation. Vielleicht kennt sich ja jemand in beiden Protokollen aus und hat da eine Erklärung?
Gruss, Jürgen
-
Hi,
bemerkbar gemacht hat es sich dann einfach mit Fehlern im ioBroker-Log, dass irgendein Gerät via MQTT nicht mehr erreichbar ist bzw. sich länger nicht mehr gemeldet hat (habe die Meldung leider nirgends archiviert). Und im Sonoff-Adapter war es dann zusätzlich so, dass dieser sogar irgendwann auf gelb gesprungen ist und ich ihn manuell wieder starten musste (oder das eben regelmäßig via cron hätte tun müssen).
Via Webinterface waren die Geräte (meist) dennoch erreichbar.
Wobei, wie schon geschrieben, beide nicht den idealen WLAN-Empfang hatten. Laut Sonoff-Webinterface bei einem nur 28%. Durch Umstellen das AP AC Pro ist der schlechteste Wert mittlerweile bei 48%, aber mit der HUE-Emulation lief es auch bisher dann problemlos. Im Log waren zwar ab und an Meldungen, dass das eine oder andere HUE-Gerät nicht erreichbar wäre, aber ein paar Minuten später war es dann doch wieder da ohne dass ich hätte eingreifen müssen oder ein Adapter sich verabschiedet. Bei MQTT hiess Verbindungsverlust (soweit ich mich erinnere) eben Verbindungsverlust bis ich manuell eingreife und das Gerät oder den Adapter mal manuell anschiebe…
Ich vermute mal, dass die Sonoffs einfach heikel auf zu schwachen WLAN-Empfang reagieren und die Verindung dann unzuverlässig ist oder schnell und oft abreisst und das bei MQTT einfach mehr Probleme macht als bei der HUE-Emulation. Vielleicht kennt sich ja jemand in beiden Protokollen aus und hat da eine Erklärung?
Gruss, Jürgen `
Klingt wie bei mir. Unter connected clients haben die sich gerne mal verabschiedet. Ich hatte auch eine zeitlang einen cron job für 6.00 und 17:00 Uhr zum Neustarten des Adapters. Empfang der beiden war zwar nicht gut, aber immer ausreichend (bestimmt > 25%), weil immer über webif erreicht und über hue auch kein Problem. Eventuell ist das mit mqtt empfindlicher gegen kurze Aussetzer beim Empfang? Eigentlich würde es ja schon reichen, wenn ein client die Verbindung verliert, dass er die Verbindung wieder bekommt, z.B. durch Neustarten des Adapters. Im log sieht man, dass er manchmal die Verbindung nur für Sekunden, aber manchmal auch für Stunden verliert. Warum verbindet er sich automatisch wieder… was ist der "verbindungs-trigger"?:
1146_unbenannt.jpg -
Ich habe das Verhalten hier schon mal dokumentiert:
http://forum.iobroker.net/viewtopic.php … =80#p94263
Das Eigenartige ist eben, dass die WLAN-Verbindung eben noch(zumindest teilweise) funktioniert!
- Es werden keine MQTT-Kommandos angenommen. MQTT wird ja gerade als robustes Protokoll für schlechte Verbindungen und geringe Bandbreite genannt.
-
Zumindest bei mir seit 1 Tag alles gut.
keine Abbrüche oder sonst was. Mal weiter abwarten.
Wie schaut es denn nun mit den Werten aus des POW?
Ich log tauchen die wohl auf, aber nicht als Datenpunkt.
Oder ist das noch nicht implementiert ??
Gruß
-
@ple:
laut Github solte es drinnen sein:
This adapter communicates with Sonoff devices with Tasmota firmware or ESP devices via MQTT.
Following topics are expected:
tele/DeviceNAME/STATE
tele/DeviceNAME/SENSOR
tele/DeviceNAME/INFOx
tele/DeviceNAME/ENERGY
…..
wie schaut dein Logeintrag aus?
<u>Zu den Abbrüchen habe ich was interessantes gefunden:</u>
` > I've also changed my configuration for all my modules and now everything is working fine.
What I have learned, (with the help of @arendst), is that the "Configuration->Configure Other->Friendly Name 1 = "xyz" name and the name in the topic …/.../xyz/... can NOT be the same.
In my case I have added the prefix "m" (for module) to all my names (mxyz) in all the mqtt topics.
Thanks
P.S. This item can be closed `
Quelle: https://github.com/arendst/Sonoff-Tasmota/issues/1162
-
@ple:
laut Github solte es drinnen sein:
This adapter communicates with Sonoff devices with Tasmota firmware or ESP devices via MQTT.
Following topics are expected:
tele/DeviceNAME/STATE
tele/DeviceNAME/SENSOR
tele/DeviceNAME/INFOx
tele/DeviceNAME/ENERGY
…..
wie schaut dein Logeintrag aus?
<u>Zu den Abbrüchen habe ich was interessantes gefunden:</u>
` > I've also changed my configuration for all my modules and now everything is working fine.
What I have learned, (with the help of @arendst), is that the "Configuration->Configure Other->Friendly Name 1 = "xyz" name and the name in the topic …/.../xyz/... can NOT be the same.
In my case I have added the prefix "m" (for module) to all my names (mxyz) in all the mqtt topics.
Thanks
P.S. This item can be closed `
Quelle: https://github.com/arendst/Sonoff-Tasmota/issues/1162 `
Der Sonoff-Adapter nutzt den topic-Namen und Friendly-Name aber nicht, es wird der Client-Name genutzt.
-
Ja das ist schon klar, die Frage ist nur wozu ist der friendly-name - ist das das Fallback-Topic wenn die Verbindung abreißt?
Das würde zumindest erklären wieso für das Modul alles "normal" ist und man es nicht mehr ansprechen kann.
Ich habe im Moment noch überhaupt keinen Überblick wie das bei Tasmota läuft.
Eine verständliche Beschreibung über die Konfigurationsmöglichkeiten ist mit noch nicht untergekommen - nur dass es sehr viele gibt
-
Hier mal mein Log mit den Leistungswerten.
sonoff.0 2017-11-15 21:17:43.645 debug [HWR_Steckdose_Waschmaschine] Received: tele/sonoff/ENERGIE = {"Zeit":"2017-11-15T21:17:44", "Total":1.224, "gestern":1.214, "heute":0.010, "Punkt":0, "Leistung":2, "Faktor":0.12, "Spannung":224, "St sonoff.0 2017-11-15 21:17:43.608 debug [HWR_Steckdose_Waschmaschine] Received: tele/sonoff/STATUS = {"Zeit":"2017-11-15T21:17:44", "Laufzeit":24, "VCC":3.142, "POWER":"ON", "WLAN":{"AP":1, "SSID":"xxxxxxxxx", "RSSI":100, "APMac":"xxxxxxxxx: sonoff.0 2017-11-15 21:17:34.302 debug [HWR_Steckdose_Trockner] Received: tele/sonoff/ENERGIE = {"Zeit":"2017-11-15T21:17:34", "Total":0.001, "gestern":0.000, "heute":0.001, "Punkt":0, "Leistung":0, "Faktor":0.00, "Spannung":218, "Strom": sonoff.0 2017-11-15 21:17:34.267 debug [HWR_Steckdose_Trockner] Received: tele/sonoff/STATUS = {"Zeit":"2017-11-15T21:17:34", "Laufzeit":24, "VCC":3.160, "POWER":"ON", "WLAN":{"AP":1, "SSID":"xxxxxxxxx", "RSSI":96, "APMac":"xxxxxxxxxxx: sonoff.0 2017-11-15 21:17:28.872 debug Client [HWR_Steckdose_Waschmaschine] pingreq sonoff.0 2017-11-15 21:17:28.830 debug Client [HWR_Steckdose_Trockner] pingreq sonoff.0 2017-11-15 21:17:13.871 debug Client [HWR_Steckdose_Waschmaschine] pingreq sonoff.0 2017-11-15 21:17:13.830 debug Client [HWR_Steckdose_Trockner] pingreq -
ich denke du hast die deutsche version installiert kann das sein?
Energy und energie… jetzt findet er die daten nicht mehr.
Einfach eine Issue erstellen mit deinen Logs und ich denke ab der nächsten version geht es dann
-
Eben mit ota geflasht. Nun kommen die Werte rein.
Danke
-
Naja ich weis es geht einfacher mit Schalter Wert aber ich möchte den Switch Schalter nutzen. Das muss gehen.
Was ich brauche ist ( True/False/ ) inkl. Status Wert
Und egal was ich mache ich finde meinen Fehler nicht
Habe es auch schon mit sonst Falls versucht. Er will nicht schalten.
Erledigt!!!!
Fehler lag am Vis Editor des mdui-switch ( html hatte nicht die passende id_ ) warum das auch immer so war keine Ahnung hatte es nicht geändert. Nun funktioniert es.
3717_objekt.jpg
3717_blockly.jpg
3717_vis.jpg
