[Adapter] Sonoff- Tasmota
-
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 -
Bin wieder am Testen mit dem sonoff-Adapter. Nun habe ich ein drittes Gerät dabei. ABer leider verlieren die clients nach einer Zeit die Verbindung.
Meist wegen einer anderen "party"!? Ich dachte andere Party könnte hue-Adapter sein, aber wenn ich den ausschalte, passiert es trotzdem.
This socket has been ended by the other partysonoff.0 2017-11-28 19:25:07.669 debug Client [Zirkulation] pingreq sonoff.0 2017-11-28 19:25:01.625 debug Client [Licht_Gartenhaus] pingreq sonoff.0 2017-11-28 19:25:00.681 debug Client [Satellit] pingreq sonoff.0 2017-11-28 19:24:55.553 debug Client [Zirkulation] pingreq sonoff.0 2017-11-28 19:24:46.427 debug Client [Licht_Gartenhaus] pingreq sonoff.0 2017-11-28 19:24:45.677 debug Client [Satellit] pingreq sonoff.0 2017-11-28 19:24:36.199 debug Client [Zirkulation] pingreq sonoff.0 2017-11-28 19:24:31.426 debug Client [Licht_Gartenhaus] pingreq sonoff.0 2017-11-28 19:24:30.749 debug Client [Satellit] pingreq sonoff.0 2017-11-28 19:24:20.433 debug Client [Zirkulation] pingreq sonoff.0 2017-11-28 19:24:16.427 debug Client [Licht_Gartenhaus] pingreq sonoff.0 2017-11-28 19:24:15.707 debug Client [Satellit] pingreq sonoff.0 2017-11-28 19:24:09.103 debug stateChange sonoff.0.info.connection: {"val":"Satellit,Licht_Gartenhaus","ack":true,"ts":1511893449097,"q":0,"from":"system.adapter.sonoff.0","lc":1511893449097} sonoff.0 2017-11-28 19:24:09.095 warn Client error [Zirkulation]: Error: This socket has been ended by the other party sonoff.0 2017-11-28 19:24:09.095 warn Client error [Zirkulation]: Error: This socket has been ended by the other party sonoff.0 2017-11-28 19:24:09.095 warn Client error [Zirkulation]: Error: This socket has been ended by the other party sonoff.0 2017-11-28 19:24:09.094 warn Client error [Zirkulation]: Error: This socket has been ended by the other party sonoff.0 2017-11-28 19:24:09.094 warn Client error [Zirkulation]: Error: This socket has been ended by the other party sonoff.0 2017-11-28 19:24:09.093 warn Client error [Zirkulation]: Error: This socket has been ended by the other party sonoff.0 2017-11-28 19:24:09.090 debug Send to "Zirkulation": tele/sonoff_zirk/LWT = online sonoff.0 2017-11-28 19:24:09.087 info Client [Zirkulation] closed sonoff.0 2017-11-28 19:24:09.073 debug Client [Zirkulation] pingreq sonoff.0 2017-11-28 19:24:05.334 debug [Zirkulation] Received: cmnd/sonoff_zirk/POWER = sonoff.0 2017-11-28 19:24:05.288 debug stateChange sonoff.0.info.connection: {"val":"Satellit,Zirkulation,Licht_Gartenhaus","ack":true,"ts":1511893445279,"q":0,"from":"system.adapter.sonoff.0","lc":1511893366208} sonoff.0 2017-11-28 19:24:05.276 info Client [Zirkulation] connected sonoff.0 2017-11-28 19:24:01.421 debug Client [Licht_Gartenhaus] pingreq sonoff.0 2017-11-28 19:24:00.683 debug Client [Satellit] pingreq sonoff.0 2017-11-28 19:23:46.430 debug Client [Licht_Gartenhaus] pingreq sonoff.0 2017-11-28 19:23:45.699 debug Client [Satellit] pingreq sonoff.0 2017-11-28 19:23:31.422 debug Client [Licht_Gartenhaus] pingreq sonoff.0 2017-11-28 19:23:30.813 debug Client [Zirkulation] pingreq sonoff.0 2017-11-28 19:23:30.705 debug Client [Satellit] pingreq sonoff.0 2017-11-28 19:23:16.494 debug Client [Licht_Gartenhaus] pingreq sonoff.0 2017-11-28 19:23:15.677 debug Client [Satellit] pingreq sonoff.0 2017-11-28 19:23:09.297 debug Client [Zirkulation] pingreq sonoff.0 2017-11-28 19:23:09.295 debug [Zirkulation] Received: cmnd/sonoff_zirk/POWER = sonoff.0 2017-11-28 19:23:09.219 debug stateChange sonoff.0.Zirkulation.alive: {"val":true,"ack":true,"ts":1511893389212,"q":0,"from":"system.adapter.sonoff.0","lc":1511893389212} sonoff.0 2017-11-28 19:23:08.779 debug [Satellit] Received: tele/sonoff_sat/STATUS = {"Zeit":"2017-11-28T19:23:08", "Laufzeit":1, "VCC":3.178, "POWER":"ON", "WLAN":{"AP":1, "SSID":"Sorocaba", "RSSI":60, "APMac":"F2:9F:C2:F7:9B:60"}} sonoff.0 2017-11-28 19:23:01.418 debug Client [Licht_Gartenhaus] pingreq sonoff.0 2017-11-28 19:23:00.652 debug Client [Satellit] pingreq sonoff.0 2017-11-28 19:22:46.342 debug [Licht_Gartenhaus] Received: cmnd/sonoff_Garten/POWER = sonoff.0 2017-11-28 19:22:46.276 debug stateChange sonoff.0.Licht_Gartenhaus.alive: {"val":true,"ack":true,"ts":1511893366272,"q":0,"from":"system.adapter.sonoff.0","lc":1511893366272} sonoff.0 2017-11-28 19:22:46.214 debug stateChange sonoff.0.info.connection: {"val":"Satellit,Zirkulation,Licht_Gartenhaus","ack":true,"ts":1511893366208,"q":0,"from":"system.adapter.sonoff.0","lc":1511893366208} sonoff.0 2017-11-28 19:22:46.207 info Client [Licht_Gartenhaus] connected sonoff.0 2017-11-28 19:22:45.760 debug stateChange sonoff.0.info.connection: {"val":"Satellit,Zirkulation","ack":true,"ts":1511893365750,"q":0,"from":"system.adapter.sonoff.0","lc":1511893365750} sonoff.0 2017-11-28 19:22:45.747 info Client [Zirkulation] connected sonoff.0 2017-11-28 19:22:45.476 debug [Satellit] Received: cmnd/sonoff_sat/POWER = sonoff.0 2017-11-28 19:22:45.473 debug stateChange sonoff.0.Satellit.alive: {"val":true,"ack":true,"ts":1511893365468,"q":0,"from":"system.adapter.sonoff.0","lc":1511893365468} sonoff.0 2017-11-28 19:22:45.449 debug stateChange sonoff.0.info.connection: {"val":"Satellit","ack":true,"ts":1511893365431,"q":0,"from":"system.adapter.sonoff.0","lc":1511893365431} sonoff.0 2017-11-28 19:22:45.306 info Client [Satellit] connected sonoff.0 2017-11-28 19:22:37.521 debug stateChange sonoff.0.Satellit.alive: {"val":false,"ack":true,"ts":1511893357511,"q":0,"from":"system.adapter.sonoff.0","lc":1511893357511} sonoff.0 2017-11-28 19:22:37.521 debug stateChange sonoff.0.Licht_Gartenhaus.alive: {"val":false,"ack":true,"ts":1511893357510,"q":0,"from":"system.adapter.sonoff.0","lc":1511893357510} sonoff.0 2017-11-28 19:22:37.517 debug stateChange sonoff.0.Zirkulation.alive: {"val":false,"ack":true,"ts":1511893357507,"q":0,"from":"system.adapter.sonoff.0","lc":1511893357507} sonoff.0 2017-11-28 19:22:37.459 debug stateChange sonoff.0.info.connection: {"val":"","ack":true,"ts":1511893357445,"q":0,"from":"system.adapter.sonoff.0","lc":1511893353635} sonoff.0 2017-11-28 19:22:37.442 info Starting MQTT authenticated server on port 1500 sonoff.0 2017-11-28 19:22:37.368 debug Schedule restart: 0 6,17 * * * sonoff.0 2017-11-28 19:22:37.233 info starting. Version 0.3.3 in /opt/iobroker/node_modules/iobroker.sonoff, node: v6.12.0 sonoff.0 2017-11-28 19:22:37.166 debug statesDB connected sonoff.0 2017-11-28 19:22:37.111 debug objectDB connected sonoff.0 2017-11-28 19:22:33.632 info terminating sonoff.0 2017-11-28 19:22:33.624 warn Client error [Satellit]: Error: This socket is closed sonoff.0 2017-11-28 19:22:33.624 info Client [Satellit] closed sonoff.0 2017-11-28 19:22:33.623 warn Client error [Licht_Gartenhaus]: Error: This socket is closed sonoff.0 2017-11-28 19:22:33.622 info Client [Licht_Gartenhaus] closed sonoff.0 2017-11-28 19:22:33.622 info Client [Zirkulation] closed sonoff.0 2017-11-28 19:19:50.972 info Client [Zirkulation] closed sonoff.0 2017-11-28 19:18:24.776 warn Client error [Zirkulation]: Error: This socket has been ended by the other party sonoff.0 2017-11-28 19:18:24.775 warn Client error [Zirkulation]: Error: This socket has been ended by the other party sonoff.0 2017-11-28 19:18:24.775 warn Client error [Zirkulation]: Error: This socket has been ended by the other party sonoff.0 2017-11-28 19:18:24.775 warn Client error [Zirkulation]: Error: This socket has been ended by the other party sonoff.0 2017-11-28 19:18:24.774 warn Client error [Zirkulation]: Error: This socket has been ended by the other party sonoff.0 2017-11-28 19:18:24.773 warn Client error [Zirkulation]: Error: This socket has been ended by the other party sonoff.0 2017-11-28 19:18:24.773 info Client [Zirkulation] closed sonoff.0 2017-11-28 19:18:17.540 info Client [Zirkulation] connected sonoff.0 2017-11-28 19:17:01.565 info Client [Zirkulation] connected sonoff.0 2017-11-28 19:15:45.240 info Client [Zirkulation] closed sonoff.0 2017-11-28 19:15:45.239 error Closed because of error sonoff.0 2017-11-28 19:15:45.238 warn Client error [Zirkulation]: Error: This socket is closed sonoff.0 2017-11-28 19:15:45.234 warn Client error [Zirkulation]: Error: read ECONNRESET sonoff.0 2017-11-28 19:15:23.446 info Client [Zirkulation] connected sonoff.0 2017-11-28 19:14:14.805 warn Client error [Zirkulation]: Error: This socket has been ended by the other party sonoff.0 2017-11-28 19:14:14.805 warn Client error [Zirkulation]: Error: This socket has been ended by the other party sonoff.0 2017-11-28 19:14:14.805 warn Client error [Zirkulation]: Error: This socket has been ended by the other party sonoff.0 2017-11-28 19:14:14.804 warn Client error [Zirkulation]: Error: This socket has been ended by the other party sonoff.0 2017-11-28 19:14:14.804 warn Client error [Zirkulation]: Error: This socket has been ended by the other party sonoff.0 2017-11-28 19:14:14.804 warn Client error [Zirkulation]: Error: This socket has been ended by the other party sonoff.0 2017-11-28 19:14:14.803 info Client [Zirkulation] closed sonoff.0 2017-11-28 19:13:03.462 info Client [Zirkulation] connected sonoff.0 2017-11-28 19:12:07.929 warn Client error [Zirkulation]: Error: This socket has been ended by the other party sonoff.0 2017-11-28 19:12:07.929 warn Client error [Zirkulation]: Error: This socket has been ended by the other party sonoff.0 2017-11-28 19:12:07.929 warn Client error [Zirkulation]: Error: This socket has been ended by the other party sonoff.0 2017-11-28 19:12:07.929 warn Client error [Zirkulation]: Error: This socket has been ended by the other party sonoff.0 2017-11-28 19:12:07.928 warn Client error [Zirkulation]: Error: This socket has been ended by the other party sonoff.0 2017-11-28 19:12:07.927 warn Client error [Zirkulation]: Error: This socket has been ended by the other party sonoff.0 2017-11-28 19:12:07.924 info Client [Zirkulation] closed sonoff.0 2017-11-28 19:11:36.170 info Client [Zirkulation] connected sonoff.0 2017-11-28 19:00:05.632 info Client [Licht_Gartenhaus] connected sonoff.0 2017-11-28 19:00:05.625 info Client [Satellit] connected sonoff.0 2017-11-28 19:00:05.307 info Client [Zirkulation] connected -
Was steht in den LOG Files von Tasmota?
Hast du die „Friendly Names“ in Tasmota umgestellt, damit sie nicht gleich sind?
-
Was steht in den LOG Files von Tasmota?
Hast du die „Friendly Names“ in Tasmota umgestellt, damit sie nicht gleich sind? `
Friendly names sind alle unterschiedlich. Was meinst du mit LOG files von tasmota… wo kann ich die abrufen? -
Unter console gibt es ein Fenster in dem man die letzten Einträge sieht.
Dazu vorher am besten den WeblogLevel auf 4 stellen.
Noch eleganter wäre einen Syslogserver zu verwenden (kann z.B. eine Synology DS)
1904_22c35c7c-3e9c-48d6-8554-ff4e61b886f0.jpeg
1904_e0fbb643-555b-4e52-a230-d3b7f5153900.jpeg
