OBI Funk-Steckdosenumbau ESP8266 (Generation1 Rund)
-
tue mir mal einen Gefallen und nimm mal die Beta 1.0.4 von der 1. Seite und flashe die Dose mal damit. `
gemacht (nur Sketch), aber mit Fehler:Exception in thread "Thread-16" java.util.ConcurrentModificationException at java.util.LinkedList$LLSpliterator.forEachRemaining(LinkedList.java:1239) at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151) at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174) at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418) at cc.arduino.contributions.libraries.LibrariesIndexer.rescanLibraries(LibrariesIndexer.java:127) at processing.app.BaseNoGui.onBoardOrPortChange(BaseNoGui.java:683) at processing.app.Base.onBoardOrPortChange(Base.java:1313) at processing.app.Editor$DefaultExportHandler.run(Editor.java:2198) at java.lang.Thread.run(Thread.java:748)zum ESP Modul gibt es jetzt ein Update auf 2.4.2
EDIT:
Dose findet das Netz auch nicht
Gruß
Rainer
-
Hast du die neue Version mit größeren Timeouts probiert?
Hatte ich als Antwort auf dein letzten Post gepostet. `
Ja, die habe ich getestet. Irgendwie scheint es besser zu sein aber noch immer nicht 100% Stable. Würde es was bringen den Timeout noch höher zu setzen? Wofür genau ist der Timeout denn eigentlich da, dass der die Dose zum Absturz bringt, wenn er offenbar überschritten wird…? Also was bewirkt der genau? `
Hi,
die Dose hat ja nur 25-30 KB freies RAM, wenn nun dein Browser die Daten zu langsam abnimmt, dann sendet die Dose zwar los, aber die Daten von der vorherigen Anforderung sind noch nicht abgeholt. Dann geht der Speicher in die Knie. Bei 0 Speicher nippelt sie dann ab.
Die aktuelle Implementierung versucht das zu umgehen, indem geschaut wird, ob der Speicher sich erholt hat, oder der Timeout von vorher 250 in deiner Version 1000ms abgelaufen ist.
Hab noch einen Fehler in der Timeout Behandlung gefunden. Jetzt ist der Timeout auf 5 Sekunden, trotzdem sollte es bei schnellen Verbindungen fixer sein, da er den Speicher bis auf 12k nutzt, bevor er anfängt zu warten.
Wenn der Timeout kommt, bricht er den Aufbau der Website ab, dann ist die ggf. nur blau. Dann steht im Protokoll so etwas wie Timeout Webpage <zahl>oder Timeout Webpage LAST
Kannst du nochmal testen bitte.</zahl>
-
tue mir mal einen Gefallen und nimm mal die Beta 1.0.4 von der 1. Seite und flashe die Dose mal damit. `
gemacht (nur Sketch), aber mit Fehler:Exception in thread "Thread-16" java.util.ConcurrentModificationException at java.util.LinkedList$LLSpliterator.forEachRemaining(LinkedList.java:1239) at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151) at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174) at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418) at cc.arduino.contributions.libraries.LibrariesIndexer.rescanLibraries(LibrariesIndexer.java:127) at processing.app.BaseNoGui.onBoardOrPortChange(BaseNoGui.java:683) at processing.app.Base.onBoardOrPortChange(Base.java:1313) at processing.app.Editor$DefaultExportHandler.run(Editor.java:2198) at java.lang.Thread.run(Thread.java:748)zum ESP Modul gibt es jetzt ein Update auf 2.4.2
EDIT:
Dose findet das Netz auch nicht
Gruß
Rainer `
Kannst du mir mal genau deine Fritzbox-Version plus Einstellungen für dein Netz senden. Ich habe auch eine Fritzbox, allerdings mit 06.87, da Kabel.
Hast du weitere Filter ausser "Name des WLAN-Funknetzes sichtbar" aktiv. Dann kann ich das mal ausprobieren.
-
Hallo,
mal einen Verbesserungsvorschlag machen möchte.
Fände es gut, wenn der IOBroker Datenpunkt State sich auch ändern würde, wenn die Steckdose mittels Änderung des Datenpunktes SetState geschaltet wird. State springt nur um, wenn direkt an der Steckdose rumgefingert wird oder beim Schalten über die WebGUI des ObiPlugs…Grüße, und weiter so! `
Hallo,
hab grad nochmal getestet, das geht bei mir mit der 1.1.4c.
Was geht:
Änderung Taster oder per WEB an der Steckdose -> update an iobroker
Was nicht geht:
Ändere den Datenpunkt in ioBroker -> dann Änderung an Steckdose,
das geht nur über z.B. Script mit Aufruf der Webschnittstelle IP-Dose/on.
Einfacher ist Integration an CCU2 mit CUXD, da sieht es denn aus wie ein normales Gerät. `
Habe es noch einmal getestet, sämtliche Delay-Befehle stetzen den State und Info - Datenpunkt NICHT zb. /ONdelayOFF?. Die /On /Off Befehle funktionieren. Bitte wenn es geht fixen, denn gerade wenn diese, in meinen Augen sehr nützlichen Funktionen genutzt werden, wäre es sehr wichtig in iobroker zu wissen, wann die Steckdose zb. wieder ausgeschaltet hat um darauf reagieren zu können.
Grüße.. `
Hallo,
hab den Fehler gefunden. Hab da einen Bug eingebaut.
Kannst du bitte testen:
-
Kannst du mir mal genau deine Fritzbox-Version plus Einstellungen für dein Netz senden. Ich habe auch eine Fritzbox, allerdings mit 06.87, da Kabel.
Hast du weitere Filter ausser "Name des WLAN-Funknetzes sichtbar" aktiv. Dann kann ich das mal ausprobieren. `
Gerne (Aber um meine Kunden zu zitieren: Die andere läuft doch
)Fritz 7490
FritzOS 6.93
SSID Sichtbar ohne Haken
und "WLAN-Zugang auf die bekannten WLAN-Geräte beschränken" aktiv = MAC-Adress Filterung
Gruß
Rainer
-
Hi,
kann es nachstellen, bis ich zum lösen komme dauert es aber eher bis Freitag.
Das Problem, dass es zu schnell wieder bootet habe ich auch nachstellen können
Lag bei mir daran, das wenn ich bei der Website auf reload gehe er nicht ip lädt
sondern die letzte und die ist halt ip/reboot und damit startet er automatisch neu.
Also immer wenn starte in einer Sekunde kommt, dann hat man den reboot selbst ausgelöst.
Version ist bei mir übrigens auch die 2.4.2
-
Hi,
die Dose hat ja nur 25-30 KB freies RAM, wenn nun dein Browser die Daten zu langsam abnimmt, dann sendet die Dose zwar los, aber die Daten von der vorherigen Anforderung sind noch nicht abgeholt. Dann geht der Speicher in die Knie. Bei 0 Speicher nippelt sie dann ab.
Die aktuelle Implementierung versucht das zu umgehen, indem geschaut wird, ob der Speicher sich erholt hat, oder der Timeout von vorher 250 in deiner Version 1000ms abgelaufen ist.
code_1_1_4e.zip
firmware1_1_4e.zip
Hab noch einen Fehler in der Timeout Behandlung gefunden. Jetzt ist der Timeout auf 5 Sekunden, trotzdem sollte es bei schnellen Verbindungen fixer sein, da er den Speicher bis auf 12k nutzt, bevor er anfängt zu warten.
Wenn der Timeout kommt, bricht er den Aufbau der Website ab, dann ist die ggf. nur blau. Dann steht im Protokoll so etwas wie Timeout Webpage <zahl>oder Timeout Webpage LAST
Kannst du nochmal testen bitte.</zahl> `
Ah okay, denke ich verstehe. Also richtet sich das nach der Geschwindigkeit der mobilen Verbindung? Würde natürlich auch Sinn ergeben, warum es im WLAN immer problemlos alles klappt und im mobilen Netz über den VPN dann nur noch Probleme.
Ich habe natürlich auch direkt die 1.1.4e mal drüber installiert, leider gleich beim ersten Versuch wieder Absturz. Hab direkt danach noch mal eeProm zurückgesetzt, hat ja beim letzten mal geholfen. Leider direkt beim nächsten Versuch wieder abgestürzt =/
-
gemacht (nur Sketch), aber mit Fehler:
Exception in thread "Thread-16" java.util.ConcurrentModificationException at java.util.LinkedList$LLSpliterator.forEachRemaining(LinkedList.java:1239) at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151) at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174) at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418) at cc.arduino.contributions.libraries.LibrariesIndexer.rescanLibraries(LibrariesIndexer.java:127) at processing.app.BaseNoGui.onBoardOrPortChange(BaseNoGui.java:683) at processing.app.Base.onBoardOrPortChange(Base.java:1313) at processing.app.Editor$DefaultExportHandler.run(Editor.java:2198) at java.lang.Thread.run(Thread.java:748)zum ESP Modul gibt es jetzt ein Update auf 2.4.2
EDIT:
Dose findet das Netz auch nicht
`Komisch, bei mir läuft der ohne Kompilierungsfehler durch.
Das müssen wir erst mal beheben
Was macht er denn, wenn du nochmal die WifiSetup.ino 1.0.0 von Seite 1 draufflashst?
Geht die Kompilierung dann auch ohne Fehler?
Und kommst du damit wenigstens dann in dein WLAN?
Wenn ja, dann nimm mal die Beta 1.0.4 BIN und lade sie mal per OTA Update auf die Dose?
Funktioniert es dann?
Ich habe gerade die Befürchtung, daß deine Arduino oder dein ESPCore nicht richtig installiert ist.
Ist deine Java Umgebung auf aktuellem Stand?
Hast du mal Arduino und auch den ESP Core erneut installiert?
Grüße
Tom
-
Morgens,
die Rückmeldung der Delayed-Befehle funktionieren ab V.1_1_4f. State und info -Datenpunkte werden jetzt korrekt gesetzt
So soll das sein! Danke, für diese echt gute Arbeit sissiwup und TomT…Grüße..
PS: Ach, ist eigentlich für die Zukunft noch MQTT geplant?
-
Morgens,
die Rückmeldung der Delayed-Befehle funktionieren ab V.1_1_4f. State und info -Datenpunkte werden jetzt korrekt gesetzt
So soll das sein! Danke, für diese echt gute Arbeit sissiwup und TomT…Grüße..
PS: Ach, ist eigentlich für die Zukunft noch MQTT geplant? `
Der Frage kann ich mich anschließen
ist eigentlich für die Zukunft noch MQTT geplant?
Gruß
Jürgen
-
Morgens,
die Rückmeldung der Delayed-Befehle funktionieren ab V.1_1_4f. State und info -Datenpunkte werden jetzt korrekt gesetzt
So soll das sein! Danke, für diese echt gute Arbeit sissiwup und TomT…Grüße..
PS: Ach, ist eigentlich für die Zukunft noch MQTT geplant? `
Hi,
schön. Die Images z.B. aus c´t unterstützen MQTT, ist es sinnvoll dieses hier zusätzlich zu ioBroker und CCU-Integration einzubinden?
-
Hallo,
na MQTT hätte auch unter IOBroker Vorteile. Datenpunkte könnten sich automatisch anlegen, und man benötigt nicht unbedingt scripte um diese zu ändern. Die Einbindung wäre für den Nutzer eben einfacher.
Grüße..
-
Hallo,
na MQTT hätte auch unter IOBroker Vorteile. Datenpunkte könnten sich automatisch anlegen, und man benötigt nicht unbedingt scripte um diese zu ändern. Die Einbindung wäre für den Nutzer eben einfacher.
Grüße.. `
Das kann ich auch bestätigen.
Ich möchte das Super Projekt von TomT und sissiwup nicht schlecht machen (Das ist eine geniale Leistung !!) aber ich habe gestern die Implementierung von Tasmota getestet und bin erfolgreich gewesen. Nun läuft eine OBI-Steckdose im Testbetrieb mit Sonoff-Tasmota 6.1.1 und MQTT mit dem ioBroker und dem sonoff-Adappter.
Ich versuche (in einem neuen Thread) die Schritte zu beschreiben. (Wenn gewünscht)
Gruß
Jürgen
-
na MQTT hätte auch unter IOBroker Vorteile. Datenpunkte könnten sich automatisch anlegen, und man benötigt nicht unbedingt scripte um diese zu ändern. Die Einbindung wäre für den Nutzer eben einfacher.
Grüße..
Das kann ich auch bestätigen.
Ich möchte das Super Projekt von TomT und sissiwup nicht schlecht machen (Das ist eine geniale Leistung !!) aber ich habe gestern die Implementierung von Tasmota getestet und bin erfolgreich gewesen. Nun läuft eine OBI-Steckdose im Testbetrieb mit Sonoff-Tasmota 6.1.1 und MQTT mit dem ioBroker und dem sonoff-Adappter.
Ich versuche (in einem neuen Thread) die Schritte zu beschreiben. (Wenn gewünscht)
Gruß
Jürgen
Hallo,
an alle, die dieses projekt so sensationell vorangetrieben haben-klasse arbeit. ich hab im stillen alles mitverfolgt und durchgeführt. bei mir laufen
5stk zur vollsten zufriedenheit. und ja, tut alles, was dieses projekt weiter voranbringt.
-
Hi,
die Dose hat ja nur 25-30 KB freies RAM, wenn nun dein Browser die Daten zu langsam abnimmt, dann sendet die Dose zwar los, aber die Daten von der vorherigen Anforderung sind noch nicht abgeholt. Dann geht der Speicher in die Knie. Bei 0 Speicher nippelt sie dann ab.
Die aktuelle Implementierung versucht das zu umgehen, indem geschaut wird, ob der Speicher sich erholt hat, oder der Timeout von vorher 250 in deiner Version 1000ms abgelaufen ist.
code_1_1_4e.zip
firmware1_1_4e.zip
Hab noch einen Fehler in der Timeout Behandlung gefunden. Jetzt ist der Timeout auf 5 Sekunden, trotzdem sollte es bei schnellen Verbindungen fixer sein, da er den Speicher bis auf 12k nutzt, bevor er anfängt zu warten.
Wenn der Timeout kommt, bricht er den Aufbau der Website ab, dann ist die ggf. nur blau. Dann steht im Protokoll so etwas wie Timeout Webpage <zahl>oder Timeout Webpage LAST
Kannst du nochmal testen bitte.</zahl> `
Ah okay, denke ich verstehe. Also richtet sich das nach der Geschwindigkeit der mobilen Verbindung? Würde natürlich auch Sinn ergeben, warum es im WLAN immer problemlos alles klappt und im mobilen Netz über den VPN dann nur noch Probleme.
Ich habe natürlich auch direkt die 1.1.4e mal drüber installiert, leider gleich beim ersten Versuch wieder Absturz. Hab direkt danach noch mal eeProm zurückgesetzt, hat ja beim letzten mal geholfen. Leider direkt beim nächsten Versuch wieder abgestürzt =/ `
Ok,
das Problem sollte jetzt gefixt sein. Es liegt an der Lib 2.4.2, die hat da scheinbar ein Problem.
Die 2.3.0 ist da scheinbar stabiler. Habe jetzt die Version mal mit der gebaut.
-
Kannst du mir mal genau deine Fritzbox-Version plus Einstellungen für dein Netz senden. Ich habe auch eine Fritzbox, allerdings mit 06.87, da Kabel.
Hast du weitere Filter ausser "Name des WLAN-Funknetzes sichtbar" aktiv. Dann kann ich das mal ausprobieren. `
Gerne (Aber um meine Kunden zu zitieren: Die andere läuft doch )Fritz 7490
FritzOS 6.93
SSID Sichtbar ohne Haken
und "WLAN-Zugang auf die bekannten WLAN-Geräte beschränken" aktiv = MAC-Adress Filterung
Gruß
Rainer `
Hallo,
kannst du auch mal die 1.1.4g ausprobieren.
Bitte wenn du selbst baust:
2.3.0 und nicht 2.4.2 als Lib nehmen.
Auch Tasmota läuft über VPN nicht mit 2.4.x, da ist der Tipp im Forum zurück auf 2.3.0 zu gehen.
Falls du Visual Studio Code verwendest:
platformio] build_dir = bin [env:esp01_1m] platform = espressif8266@1.5.0 lib_extra_dirs = ~/Documents/Arduino/libraries board = esp01_1m framework = arduino lib_deps = ESP8266Ping build_flags = -Wl,-T../ld/eagle.flash.1m64.ldDer Pfad zum Memory Layout ist anders! 1m64 = Board mit 1Megabyte, davon 64KB als Spiffs.
-
Wenn die LIB 2.3.0 die Lösung für VPN und den versteckten SSID ist, dann baue ich MQTT ein, ist auch nicht die Welt.
-
Hallo sissiwup
die 2.4.0 rc-2 sollte das Problem von Rainer nicht haben.
Denn alle Versionen vor BETA 1.0.4 wurden mit dem Core 2.4.0-rc2 erzeugt.
Rainer hatte noch keine Rückmeldung gegeben, ob das von mir erzeugte Beta 1.0.4.bin auch seine Probleme erzeugt, daher warte ich da noch auf seine Rückinfo.
Generell auf die Core 2.3.0 zurück zu gehen halte ich bezüglich des KRACK EXPLOITS für keine gute Idee….
Das machst den WLAN Zugang unsicher.
Link : https://www.krackattacks.com/
Ab 2.4.0-rc2 sollte dieses Einfalltor behoben sein...
Grüße
Tom
-
Hallo Tom, Hallo Sissi,
ich bin aus gesundheitlichen Gründen im Moment nicht weitergekommen.
Aaaaber…
Der erste Versuch war von 1.0.2b via OTA auf 1.1.4
Da ist keine Arduino IDE involviert gewesen.
Ab da begann das Desaster
Auch die 1.0.9 klappte ja, solange ich die SSID sichtbar hatte - ein OTA von dieser auf 1.1.4a brauchte noch einen Hardreste und dann lief diese auch solange die SSID sichtbar war.
Ich gehe davon aus, dass das auch direkt von 1.02b auf 1.1.4 so gewesen ist.
Sollte also irgendetwas kompiliertes schuld sein, müsste das bereits latent in der 1.0.2b drin sein, aber erst durch die neueren Versionen "zum Leben erweckt" werden.
Natürlich möchte ich wissen woran es liegt. Werde baldmöglichst nochmal ganz von vorne beginnen.
Gruß
Rainer
-
Hallo sissiwup
die 2.4.0 rc-2 sollte das Problem von Rainer nicht haben.
Denn alle Versionen vor BETA 1.0.4 wurden mit dem Core 2.4.0-rc2 erzeugt.
Rainer hatte noch keine Rückmeldung gegeben, ob das von mir erzeugte Beta 1.0.4.bin auch seine Probleme erzeugt, daher warte ich da noch auf seine Rückinfo.
Generell auf die Core 2.3.0 zurück zu gehen halte ich bezüglich des KRACK EXPLOITS für keine gute Idee….
Das machst den WLAN Zugang unsicher.
Link : https://www.krackattacks.com/
Ab 2.4.0-rc2 sollte dieses Einfalltor behoben sein...
Grüße
Tom `
Hallo,
kann man die Version der LIB im Code Anzeigen? => ESP.getCoreVersion()
Ich nutze nicht die Arduino-Core IDE, sondern PlattformIO, da kann ich auf 2.4.0, 2.4.1 gehen.
2.4.1 habe ich grade probiert, die geht nicht mehr per VPN.
2.4.0 habe ich auch getestet, geht auch nicht.
2.3.0 geht. Steht leider auch so in anderen Foren.
