Danke für die Antworten. Domoticz verwende ich nicht. Wenn sich im Bezug auf Stabilität, Effizienz und/oder Performance nichts geändert hat, dann bleibe ich wohl bei 5.13a,
Danke!
Danke für die Antworten. Domoticz verwende ich nicht. Wenn sich im Bezug auf Stabilität, Effizienz und/oder Performance nichts geändert hat, dann bleibe ich wohl bei 5.13a,
Danke!
Ja, habe da ich dies selbst kompiliert habe schon das Problem gemerkt dass wenig speicher für das OTA Update zur Verfügung steht. Insofern war mein Testablauf wie folgt:
1) Backup mit decode-config
2) reset der Konfiguration(glaube reset 5?)
3) kleinste minimal version die ich finden konnte (glaube 8.x?)
4) wieder reset (hier gibt es nun einen "richtigen" reset wo auch WiFi konfig und alles weg ist)
5) über 192.168.4.1 SSID wieder konfigurieren
6) Update auf neueste minimal Version
7) update auf neueste normal Version
Konfiguration über decode-config wieder einspielen
Dies funktionierte bei den Testmodulen soweit ganz gut. Bin mir nur noch nicht sicher ob ich dies für die "nicht erreichbaren Sonoffs" in der Hohlwand auch riskieren will...
Also wäre deine Empfehlung eher die Module aktuell zu halten?
Ich persönlich würde am liebsten alle auf einen stabilen Stand bringen, und dann nicht weiter updaten, um nicht unnötig Risiko durch fehlerhafte updates zu generieren.
Aber ob dies nun 10.x sein soll, oder eine ältere Version bin ich unschlüssig.
Oder ich lass alles so wie es ist um nichts zu verschlimmbessern...
Hallo,
ich habe bei mir im Haus etliche Sonoffs mit Tasmota verbaut (alle Lampen 1-Gang, Jalousien die Dual, ein paar S20 für die Steckdose Auslässe, 2xPow für WM und WT)
Die meisten haben FW 5.13 selbst kompiliert über die Arduino IDE, die "nichtverbauten" (also alle S20, 2xPOW, und 1x Jalousie, aber KEINE "normalen" vom Licht) haben FW 10.0.
Nun würde ich gerne auf allen die gleiche FW haben,bin nun aber nicht schlüssig welche ich verwenden soll. Meine Geräte gehen z.b. oft einmal für ein paar Sekunden laut MQTT Nachricht offline, obwohl Rossi teilweise >90% ist. Weiß aber nicht ob dies bei den neueren Versionen noch ident ist.
Jetzt habe ich aber gesehen dass der Funktionsumfang sowie die Komplexität der Tasmota SW schon ziemlich riesig ist, und insofern meine Vermutung ist dass der Stromverbrauch sowie die Fehlerwahrscheinlichkeit für meine Anwendung unnötig hoch sein dürfte (brauche eig. nur MQTT, pulsetime, HOLD, evtl. zukünftig noch Jalousiensteuerung, wobei ich dies dzt. In OpenHab über die Zeit bereits abschätze, ist also kein musthave).
Gibt es irgendwo eine Empfehlung welche Version "die stabilste" ist (also am wenigsten known Bugs hat) und für "Normalanwendungen" verwendet werden soll?
Auf der Tasmota Seite ist ja die Empfehlung "never change a running system" / "if it ain't broken, don't fix it". Insofern müsste es eig. Eine möglichst alte SW sein, wo der Code noch "einfach" war, oder?
Oder würdet ihr auf den Letztstand gehen, damit man mit OTA immer auf Letztstand bleiben kann? Wie handhabt ihr eure Smartphone Geräte?
LG Edizius
Hi,
Am besten aber nicht DHCP verwenden, sonst stimmt die aufgeschriebene IP nicht mehr. Andererseits, über den Router sollte normalerweise die richtige IP Adresse auffindbar sein (variiert je nach Router, aber normalerweise gibt es so eine Seite wie "DHCP Clients"). Außerdem solltest du sicherstellen dass du überall einen guten WLAN Empfang hast, damit nicht die verbauten schaltet ständig On- und Offline gehen.
Und noch der Log vom verhalten
:24:06 LOG: SerialLog 0, WebLog 4, MqttLog 0, SysLog 0, LogHost myoh, LogPort 514, TelePeriod 900
19:24:06 HTP: Configuration
19:24:06 CFG: Saved to flash at F9, Count 8, Bytes 4096
19:24:07 WIF: Checking connection...
19:24:07 WIF: Connected
19:24:07 UPP: Multicast (re)joined
19:24:07 UPP: Multicast disabled
19:24:07 MQT: Attempting connection...
19:24:07 MQT: Connected
19:24:07 MQT: FF_TV/tele/LWT = Online (retained)
19:24:07 MQT: FF_TV/cmnd/POWER =
19:24:07 MQT: Subscribe to FF_TV/cmnd/#
19:24:07 MQT: Subscribe to sonoffs/cmnd/#
19:24:07 MQT: Subscribe to cmnd/DVES_7AA21A_fb/#
19:24:08 UPP: Multicast (re)joined
19:24:10 HTP: Main Menu
19:24:12 HTP: Console
19:24:24 UPP: Multicast disabled
19:24:27 WIF: Checking connection...
19:24:27 WIF: Connected
19:24:27 UPP: Multicast (re)joined
19:24:27 UPP: Multicast disabled
19:24:27 MQT: Attempting connection...
19:24:27 MQT: Connected
19:24:27 MQT: FF_TV/tele/LWT = Online (retained)
19:24:27 MQT: FF_TV/cmnd/POWER =
19:24:27 MQT: Subscribe to FF_TV/cmnd/#
19:24:27 MQT: Subscribe to sonoffs/cmnd/#
19:24:27 MQT: Subscribe to cmnd/DVES_7AA21A_fb/#
19:24:28 UPP: Multicast (re)joined
19:24:45 UPP: Multicast disabled
19:24:47 WIF: Checking connection...
19:24:47 WIF: Attempting connection...
19:24:47 WIF: Connecting to AP1 [myWiFi] in mode 11N as FF_TV-0538...
19:24:48 WIF: Checking connection...
19:24:48 WIF: Attempting connection...
19:24:49 WIF: Checking connection...
19:24:49 WIF: Attempting connection...
19:24:51 WIF: Checking connection...
19:24:51 WIF: Attempting connection...
19:24:52 WIF: Checking connection...
19:24:52 WIF: Connected
19:24:52 UPP: Multicast (re)joined
19:24:52 UPP: Multicast disabled
19:24:52 MQT: Attempting connection...
19:24:52 MQT: Connected
19:24:52 MQT: FF_TV/tele/LWT = Online (retained)
19:24:52 MQT: FF_TV/cmnd/POWER =
19:24:52 MQT: Subscribe to FF_TV/cmnd/#
19:24:52 MQT: Subscribe to sonoffs/cmnd/#
19:24:52 MQT: Subscribe to cmnd/DVES_7AA21A_fb/#
19:24:53 UPP: Multicast (re)joined
Alles anzeigen
Program Version 8.1.0(tasmota)
Build Date & Time 2019-12-25T12:33:25
Core/SDK Version 2_6_1/2.2.2-dev(38a443e)
Uptime 0T09:51:06
Flash write Count 8 at 0xF9000
Boot Count 2
Restart Reason Software/System restart
Friendly Name 1 FF_TV
AP1 SSId (RSSI) xxxx (100%, -36 dBm)
Hostname FF_TV-0538
IP Address xxxx
Gateway xxxx
Subnet Mask xxxx
DNS Server xxxx
MAC Address xxxx
MQTT Host xxxx
MQTT Port xxxx
MQTT User xxxx
MQTT Client DVES_7AA21A
MQTT Topic FF_TV
MQTT Group Topic sonoffs/cmnd/
MQTT Full Topic FF_TV/cmnd/
MQTT Fallback Topic cmnd/DVES_7AA21A_fb/
Emulation Hue Bridge
mDNS Discovery Disabled
ESP Chip Id 8036890
Flash Chip Id 0x14405E
Flash Size 1024kB
Program Flash Size 1024kB
Program Size 566kB
Free Program Space 436kB
Free Memory 26kB
Alles anzeigen
Der Vollständigkeit halber: Ich habe nun 2 Module exemplarisch auf 8.1.0 upgedatet und es ist tendenziell schlechter geworden, oder zumindest nicht besser. Vermutlich sind die Module einfach sehr störanfällig und "Aluhut" ist das einzige was hilft...
Mit Arduino have ich vorher schon gearbeitet und funktionierte insofern für mich einfacher. Atom Einrichtung habe ich nicht so ohne weiteres geschafft, insofern blieb ich bei dem alt-bewährten.
Will aber ohnehin nur noch mit OTA updaten, habe nur noch nicht heraus gefunden ob es Vorraussetzungen für die Minimal-Versionen gibt, außer dass sie Platz haben (sprich: unabhängig davon was im Code vorerst manuell aktiviert/ deaktiviert wurde? Ursprüngliche Flash-Einstellungen wie z.B. SPIFF Einstellungen interessant solange die Minimal-Version noch Platz hat? Warum gibt es für jede Version eine neue Minimal-Version und warum ist es nicht für alle, oder zumindest für jede Core-Version die selbe? Warum sind die Minimal-Versionen unterschiedliche groß? Kann man den Migration-Path path nur mit den Minimal-Versionen durchführen, oder muss zwischen drinnen immer die normale tasmota.bin aufgespielt werden?)
Und diese Punkte habe ich im Wiki nicht gefunden und auch so nicht wirklich was relevantes gefunden.
Habe mir damals in der Arduino-IDE alles so vorbereitet dass das Modul im Worst-Case nach einem Reset (z.B. GPIO 0 Button mehr als 40s gedrückt) immer noch zu 90% richtig konfiguriert ist, auch wenn ich als GPIO Eingänge den RX und TX benutze (außer bei den Sonoff Duals, da hier die Serielle Verbindung ja für die Ansteuerung der Relais benötigt wird), damit ich das Risiko zu minimieren kann dass ich physikalisch zu den Modulen muss.
Habe aber bis dato mit keinen Tools rumgespielt von denen ich keine Ahnung habe.
Auf welchen Punkt beziehst du dich genau? Dass die SPIFFs falsch eingestellt waren? Ursprünglich war hier die Anleitung von Tasmota anders und hat sich erst mit der Zeit geändert.
Oder redest du vom OTA Update? Dies ist doch genau das Gegenteil von "Tools die für erfahrene User sind", da dies extra eine Lösung sein sollte damit jeder (auch ohne programmiererfahrung) ein Update zusammenbringt.
Hallo,
Ich habe nun den "TV-Sonoff" (S20, daher leicht zugänglich) nochmals seriell auf die v5.13 geflasht, damit ich das OTA updaten nochmals durchspielen kann. Bin nun aber darauf gekommen dass die SPIFFs Einstellungen wohl falsch waren, da ich hier nun nicht einmal die minimal-Version mehr aufspielen kann. Könnte es sein dass ich vor dem fehlgeschlagenen Update auch falsche SPIFF Einstellungen hätte, aber die Minimal-Version noch Platz hatte? Könnte dies den fehlerhaften OTA Update erklären?
Oder lag es eher daran dass 5.13 nicht direkt auf 8.x über OTA upgedatet werden kann?
Ich habe außerdem gesehen dass die Minimal-Versionen unterschiedliche Größen haben. Hat dies nur mit den Versionen zu tun, oder sind bei den Minimal-Versionen noch ein paar dinge aktiviert? Meine Frage zieht darauf ab, ob es für Tasmota-Module welche mit falschen SPIFF Einstellungen geflasht wurden mittlerweile eine Möglichkeit gibt diese über OTA auf eine andere Version zu bringen oder ob dies (noch?) Nicht geht.
Last but not least: ich habe el2 Module welche noch normal funktionieren, aber sich nicht (mehr) mit dem WLAN verbinden wollen. In den AP Modus bringe ich sie leider auch nicht mehr. Kennt jemand dieses Problem? Habe dazu nämlich nichts sinnvolles bei Google gefunden.
Danke euch allen,
LG Edizius
So, ich habe nun erfolgreich wieder die 5.13 geflasht, und die Konfiguration eingespielt. Wenn ich mir selbst eine .bin aus dem neuesten Tasmota-Projekt erstelle, mit meinen Einstellungen vorkonfiguriert, kann man dann direkt mit 1x minimal und dann auf meine custom.bin updaten?
Sorry, hab das mit dem Migration-Path noch nicht ganz verstanden. Dies ist nur um die Einstellungen von einer Version zur nächsten mitnehmen zu können, oder? Aber wofür ist dann das "decode-config Tool" und der TDM (Tasmota device manager)?
Und wo bekomme ich überhaupt die "alten" minimal/bins für den Migration-Path her?
Danke, lg Edizius
Hi, 40s den Power Button zu drücken habe ich schon versucht. Leider ohne Erfolg. Werde den S20 nochmal über RS232 Flashen probieren
Und muss das OTA Update von Version zu Version sein, ober ist überspringen ok? Also von 5.x direkt auf 8.x?
Ich vermute die Konfiguration muss beim überspringen neu gemacht werden und kann nicht wieder geladen werden, oder?
Hallo,
Vorab zum Setup:
ich habe OpenHAB mit einem MQTT Broker auf einem RasPi laufen und ca. 30 Sonoff-Module in der Wand für Licht und Jalousie Steuerung.
Ich habe mir in OpenHAB eine Regel erstellt, die sich meldet wenn ein Gerät Online oder Offline geht.
Nun habe ich festgestellt dass dies etliche 100x am Tag passiert. Nun habe ich mehrere APs installiert damit alle Geräte einen RSSI von >50% haben. Ein Modul welches öfters Probleme meldet, ist direkt neben dem AP und meldet sogar 100% Empfangsqualität.
Das Problem besteht aber weiterhin.
Laut Konsole startet das Gerät aber nicht neu (uptime zählt weiter und RestartReason bleibt auf SystemRestart, also keine Exception o.ä.)
Ich habe nun gelesen dass ein Software Update etwas bringen kann, bin aber dadurch dass die Module in der Wand vergraben sind etwas vorsichtig.
Ich habe in der Update-Beschreibung auf der Tasmota-Seite gelesen dass das Modul sich normal selbst die minimal Version installiert und erst anschließend die normale .bin Installiert.
Ich habe dies nun Mal mit einem S20 Modul getestet (war auf v5.13) , aber nun blinkt es nur noch grün, verbindet sich nicht mehr mit meinem WLAN und reagiert nicht auf den Button (Relais schaltet nicht). Ein AP wird zwar erstellt (sofort, auch ohne 4x Button drücken), aber wenn ich mich damit verbinde, kann ich trotzdem nicht auf 192.168.4.1 verbinden (Gateway steht zwar 192.168.4.1, aber wenn ich die Adresse im Browser eingebe, kommt nur "ERR_CONNECTION_REFUSED").
Lange Rede kurzer Sinn:
Denkt ihr dass ein Update das Problem lösen kann?
Falls ja, was ist der sicherste Weg um die Module auf neuesten Stand zu bringen?
Wie hoch schätzt ihr das Risiko dass etwas schief geht obwohl ich mich an die Anleitung halte (hab wie gesagt keine Lust eine Wand aufzureißen)
Danke vorab schon mal für die Hilfe.
LG Florian
hmmm... ok, dann werde ich versuchen geoßteils versuchen 2 Taster oder Taster und Steckdose untereinander zu planen und hoffe dass ich die Sonoffs in diese Dosen platzieren habe: https://www.amazon.de/gp/r.html?C=34…811_TE_SCE_dp_2
Danke,
Lg Edizius
ok, danke für deine hiöfw.
also die gpio PINs mit 2,5mm² beschalten, da mit 16A abgesichert
Die Hohlwände werden allerdings wirklich mit so einer Holzdämmwolle ausgestopft sprich, dies ändert die Lage deiner Ansicht nach?
hmmm... 5 €/ stk ist aber auch nicht gerade geschenkt.. wie sieht es aus wenn man 2 "normale" Dosen aufschneidet und hinten den sonoff quer einbaut? Außerdem habe ich hier irgendwo einmal gelesen dass LV und "HV" nicht in der gleichen dose sein darf. Darf man dann keine GPIO PINs an einen Schalter/Taster hängen, da N und L am Sonoff hängen?
Hallo,
Wie ihr sicher ja alle wisst passt ein Sonoff Basic nicht in eine normale UP Dose.
Bei einer Hohlwandinstallation ist es Technisch ja auch machbar den Basic direkt in die Wand zu bauen (z.B. unter oder hinter eine Verteilerdose), vorallem bei Neubau.
Ist dies zulässig, oder hat die VDE etwas dagegen wenn man Elekro-Artikel direkt in die Wand baut? Gehäuse ist ja vorhanden, so dass die Kabel nichts Externes anzünden kann.
Hinter der Dose für den Lichtschalter kann der Sonoff ja eigentlich nicht aus Versehen angebohrt werden.
Lg und danke,
Edizius
P.S. ich habe die Sonoffs leider schon alle gekauft, insofern ist die Verwendung von Shellys keine Alternative.
Nun, ja, ich habe auch Mal bei einem Schütz einen Öffner und einen Schließer Kontakt verwendet mit der Meinung dass damit ausreichend Verriegelt ist dass nie beide gleichzeitig aktiv sein können, allerdings war dann der Öffner Kontakt träger als der des Schließers (oder umgedreht?) und die Schmelzsicherung hat sich mit einem lauten Knall verabschiedet, da ich dadurch einen Kurzen bei 400V gerissen habe. Könnte mir so ein Problem auch bei einer Software-Verriegelung vorstellen, da so ein Microcontroller normalerweise schneller ist als so eine mechanische Lasche.