Bastelprojekt WLAN RGB Controller für ca. 6€

[Pf@nne]

Ich würde den Vorschlag aufgreifen und genau andersherum dich bitten den Tree aufzubauen. Ich denke du bist in der MQTT Materie tiefer drinnen und besser vertraut was sinnvoll in einem Tree ist, und was nicht. Die Informationen zu Funktionalität vom Controller sind ja in den letzten Seiten (und auf Github) zu finden.

Ich mache mal einen Vorschlag......ich hoffe, ich schaffe das alles bevor meine Röhren da sind... 

Warum ich auch auf die Latenz des Protokolls schauen möchte:
Wenn ich z.B. bei einem Fader auf dem Tablet runterfade, möchte ich ein möglichst direktes Feedback im Licht haben. Eine größere Verzögerung empfinde ich als unangenehm und schlecht zu bedienen.

Ich habe mal gemessen....
Demnach benötigt ein frame von z.B. FHEM über den Broker zum ESP im Schnitt 8 ms, abhänging vom Datenverkehr in meinen Netz.
(http://www.s6z.de/cms/images/content/test/Homeautomation/Hardware/ESP8266/TMP/MQTTquality.png)

Gemessen habe ich die Zeit die ein publish vom ESP braucht um am ESP als subcribe wieder anzukommen.

[herrmannj]

mich würde mal folgendes interessieren:

Ich habe vor einigen Monaten auch poc auf dem esp dazu gemacht. Ich habe damals aber keinen stabilen Betrieb von WLAN und PWM hin bekommen. Der esp hat immer wieder sporadisch rebootet. Da gab es dann auch Meldungen in der ESP Arduino group dazu.

Gelingt Dir (Euch) das stabil im Dauerbetrieb ?

vg
joerg

[Pf@nne]

Mitlerweile ja, ich kenne diese sporadischen reboots auch, die sind aber mit der ESP 2.1 deutlich besser geworden.
Solltest du vielleicht noch mal wagen....

Edit:
Ich habe meine ESPs aber im Messbetrieb, da ist der ESP natürlich neu verbunden bevor ein neuer Messwert kommt.
Aber ich habe eine reconnect Überwachung drin, die sieht bisher ganz gut aus.

[mrpj]

Ich mache mal einen Vorschlag......ich hoffe, ich schaffe das alles bevor meine Röhren da sind... 

Was für Röhren ? 

Ich habe mal gemessen....
Demnach benötigt ein frame von z.B. FHEM über den Broker zum ESP im Schnitt 8 ms, abhänging vom Datenverkehr in meinen Netz.

Gemessen habe ich die Zeit die ein publish vom ESP braucht um am ESP als subcribe wieder anzukommen.

Sieht doch gut aus - bedenken zu Latenz eingeschränkt.

Gibt es denn eine Lösung auch direkt ohne Broker/Server kommunizieren zu können?
Alternativ kann man ja immernoch ein udp/tcp Protokoll im Hinterkopf behalten - müssen halt mal schauen, wie stark wir den ESP mit webserver/mqtt/tcp server belasten

Ich habe vor einigen Monaten auch poc auf dem esp dazu gemacht. Ich habe damals aber keinen stabilen Betrieb von WLAN und PWM hin bekommen. Der esp hat immer wieder sporadisch rebootet. Da gab es dann auch Meldungen in der ESP Arduino group dazu.

Gelingt Dir (Euch) das stabil im Dauerbetrieb ?

Ist mir bisher bei den fertigen Testplatinen nicht passiert - aber es sind Testplatinen - sprich ich teste im Moment den Code und die sind meist nicht mehr als 10-20 Minuten dauerhaft an. Ich werde morgen einfach mal nen ESP den ganzen Tag durchlaufen lassen und schauen ob er Ausfallerscheinungen zeigt. In den letzten Monaten hat sich aber in der ESP Arduino Library einiges getan - auch diverse fixes für PWM

Mal rein aus Interresse, lag es wirklich am Code, oder kann es sein, dass er zu wenig Pufferung hatte?

[herrmannj]

Mal rein aus Interresse, lag es wirklich am Code, oder kann es sein, dass er zu wenig Pufferung hatte?

Ich sag mal so: großes und kleines c dran - dickes, definitiv sauberes Netzteil. Den Rest kann man nur raten.

Reicht ein aktuelles update der arduino-esp ide auf staging ?

Danke vg
joerg

[Pf@nne]

Moin,

welche Version nutzt du denn? 1.6.5?
Bei mir hat der Sprung auf 2.x schon einiges an Stabilität gebracht...

Ich warte immer noch auf Infrarotelemente (Röhren) für meinen Reflow-Ofen.
Das ist eigentlich mein aktuelles Projekt....

MQTT ohne Broker geht nicht, da der MQTT-ESP - CLIENT ja fest per TCP am Broker hängt.
Wenn es einen MQTT-Broker per UDP gäbe dann würde das gehen......
Dann könnte man an den Client drann kommen.

Aber ein UDP - SERVER im ESP sollte jetzt ja auch kein großes Ding sein.
Das ist mit Sicherheit das Schnellste und Universellste was du machen kannst.
Meine vorherigen Steuerungen liefen alle per UDP.

Man muss nur damit leben, das mal was "verschütt" geht.
Ist im Heimnetzt aber wohl echt eine Ausnahme.

Zur Belastung, da muss man schauen, was das Hausnetzt da so alles verträgt.
Bei mir werden es nach aktuellem Stand einige ESPs werden.
Mit Licht, Sensoren  und Aktoren kommen da schnell 20 Stück zusammen.
Man muss schauen, ob dann nicht ein eigenes Netz für die Haustechnik notwendig wird.
Mal sehen....

[herrmannj]

Man muss nur damit leben, das mal was "verschütt" geht.
Ist im Heimnetzt aber wohl echt eine Ausnahme.

Hab ich auch mal gedacht und das dann gemessen. (Weil ich auch immer alles schnell udp gemacht habe ). Die Fehlerrate kann aber durchaus im Bereich 0%-10% liegen. Und wenn's dumm läuft auch mehr..

vg
joerg

[mrpj]

Servus,
(ich oute mich mal als Franke  )

Ich hab jetzt mal nen Test seit heute morgen am laufen - ein Controller ist die ganze Zeit mit PWM an - wird seit heute morgen mit ping requests noch zusätzlich "bombadiert". Mal sehen ob das schon zu einem reset führt im laufe des Tages.

Schritt 2 wäre dann, dem ESP die ganze Zeit verschiedene Kommandos zu schicken - (muss dann nur das teil in ein andere Zimmer verschieben, sonst bekomm ich wahrscheinlich einen epilleptischen Anfall)

Ich warte immer noch auf Infrarotelemente (Röhren) für meinen Reflow-Ofen.
Das ist eigentlich mein aktuelles Projekt....

Ja sehr cool - mich interressiert fast mehr, was du denn damit vor hast  - ich werde mal deinen Thread dazu lesen

MQTT ohne Broker geht nicht, da der MQTT-ESP - CLIENT ja fest per TCP am Broker hängt.
Wenn es einen MQTT-Broker per UDP gäbe dann würde das gehen......
Dann könnte man an den Client drann kommen.

Aber ein UDP - SERVER im ESP sollte jetzt ja auch kein großes Ding sein.
Das ist mit Sicherheit das Schnellste und Universellste was du machen kannst.
Meine vorherigen Steuerungen liefen alle per UDP.

Naja alternativ geht auch eine low level Implementierung von einem TCP Server - damit spart man sich den Overhead vom Webserver. Die Anwendungen müssen dann halt doch etwas spezifischer programmiert werden 

Zur Belastung, da muss man schauen, was das Hausnetzt da so alles verträgt.
Bei mir werden es nach aktuellem Stand einige ESPs werden.
Mit Licht, Sensoren  und Aktoren kommen da schnell 20 Stück zusammen.
Man muss schauen, ob dann nicht ein eigenes Netz für die Haustechnik notwendig wird.
Mal sehen....

Mit einem guten Router lassen sich ziemlich viele Geräte einbinden - die Teile die bei den meisten Menschen mit ihrem Anschluss dabei sind, sind großer mist (Das mangetafarbene T vorne Weg mit ihren speedlink routern  )

Aber aus einer anderen perspektive macht ein getrenntes Netzwerk viel Sinn: Sicherheit
Wenn du zwei getrennte Netzwerke hast, kannst du alles was nicht im Haustechnik netz aktiv ist, raussperren. Die Kommunikation zwischen Hausnetz und Bedienelementen geschieht dann nur noch via einem Gateway - der Pakete nicht von einem ins andere Netz lässt. Aber ein Service auf dem Gateway (z.B. der MQTT Broker) ist dann die Schnittstelle. Wenn richtig konfiguriert, fallen viele Sorgen zum Thema Sicherheit weg.

[Pf@nne]

Moin (ich oute mich mal als Hamburger),

Franke....So so, ich habe einen Kollegen aus Selb, der hat ein sehr langes uuuuu in Hambuuuurg.....
Verträgt sich aber gurt mit den einheimischen hier........

Ja sehr cool - mich interressiert fast mehr, was du denn damit vor hast  - ich werde mal deinen Thread dazu lesen

Ich bin dabei universelle Aktoren/Sensoren für die einzelnen Zimmer zu entwerfen.
Damit es klein werden soll ist SMD angesagt, damit es mehr oder weniger professionell wird wollte ich mir einen ReflowOfen bauen.

Generell ist ja ersmal die Hardware wichtig, Software kann dann immer noch angepasst werden.
Es wird sich Zeigen welcher Weg der beste ist.
Hängt auch immer mit den eigenen Vorlieben zusammen.....

Aber aus einer anderen perspektive macht ein getrenntes Netzwerk viel Sinn: Sicherheit

Sehe ich auch so, ist schon blöde wenn in 10 Jahren der frühreife Nachbarssohn (Nerd der zweiten Generation) auf der Straße steht und  hier drinnen alles durcheinander bring.


Zu deinem Projekt:
Ich habe jetzt auch auf Arduino 1.6.7 umgestellt und habe festgestellt, das ich einige Probleme mit meinem Code habe.
Z.B. müssen Funktionen in ausgelagerten *.ino files jetz vorher deklariert werden, das war mit 1.6.5 irgendwie noch nicht so.....
Auch deine Library läuft mit meinem Sketch nicht.
Ich muss dazu sagen, dass ich erst vor 3 Monaten mit c/c++ angefangen habe (wg. ESP und Arduino, echt klasse).   
Ich komme aus der Pascal und Basic Ecke.....

Daher würde ganz gerne jetzt ertmal einen frischen Sketch aufmachen mit WEB-IF für den ersten Start, OTA und MQTT Grundgerüst.
Das brauche ich für meine AKT/Sen sowieso. Im Nachgang könnte ich deinen bisherigen Sketch da gerne eintüddeln, der war ja nich so umfangreich.
Dann würde ich mich auch um einen Topic-Tree für die RGB-Module kümmern.

Grüße in den Süden...
Pf@nne

[herrmannj]

na wenn wir beim outing sind: auch Hamburch

Der reboots habe ich mindestens alle 20min gesehen, wenn (und das war Voraussetzung) der esp Wifi UND PWM gemacht hat. Jedes für sich war problemlos.

Da gab es wohl Probleme bei den ISR Routinen. Schön - dann scheint das beseitigt zu sein. Das hat mich "damals" (SIC) echt abgetörnt - freut mich also um so mehr.

vg
joerg

[mrpj]

So ich hab mir mal heute Nachmittag die Zeit genommen und einen seperaten Thread mit allen Informationen (auch relevant zur Sammelbestellung) aufgemacht:
http://forum.fhem.de/index.php/topic,48918.0.html

Ich würde die Unterhaltung zur Software noch hier lassen, können aber auch gerne in den anderen Faden umziehen? Was meint ihr?

Zu deinem Projekt:
Ich habe jetzt auch auf Arduino 1.6.7 umgestellt und habe festgestellt, das ich einige Probleme mit meinem Code habe.
Z.B. müssen Funktionen in ausgelagerten *.ino files jetz vorher deklariert werden, das war mit 1.6.5 irgendwie noch nicht so.....
Auch deine Library läuft mit meinem Sketch nicht.

Seltsam - ich werde mir das dann mal genauer anschauen, sobald die LED Library auf nem guten Stand ist

Ich muss dazu sagen, dass ich erst vor 3 Monaten mit c/c++ angefangen habe (wg. ESP und Arduino, echt klasse).   
Ich komme aus der Pascal und Basic Ecke.....

Ich muss mich gerade erst wieder in c/c++ zurecht finden. In den letzten Monaten/Jahren habe ich bevorzugt mit Python & Javascript gearbeitet. Früher musste ich meine AVR Projekte in C schreiben - und im Studium haben wir C auch gebraucht.

Aber der Überfliege in c++ bin ich nicht

Daher würde ganz gerne jetzt ertmal einen frischen Sketch aufmachen mit WEB-IF für den ersten Start, OTA und MQTT Grundgerüst.
Das brauche ich für meine AKT/Sen sowieso. Im Nachgang könnte ich deinen bisherigen Sketch da gerne eintüddeln, der war ja nich so umfangreich.
Dann würde ich mich auch um einen Topic-Tree für die RGB-Module kümmern.

Da kannst du dir ruhig Zeit nehmen

Der reboots habe ich mindestens alle 20min gesehen, wenn (und das war Voraussetzung) der esp Wifi UND PWM gemacht hat. Jedes für sich war problemlos.

Da gab es wohl Probleme bei den ISR Routinen. Schön - dann scheint das beseitigt zu sein. Das hat mich "damals" (SIC) echt abgetörnt - freut mich also um so mehr.

Also bei mir läuft der Test seit heute morgen ohne Probleme - denke mal das das Problem nicht mehr besteht - dafür soll es wohl andere Probleme geben (ab und an ein Flackern) - was ich bisher noch nicht nachvollziehen konnte

[herrmannj]

Also bei mir läuft der Test seit heute morgen ohne Probleme - denke mal das das Problem nicht mehr besteht - dafür soll es wohl andere Probleme geben (ab und an ein Flackern) - was ich bisher noch nicht nachvollziehen konnte

Schön. manchmal muss einfach ein wenig warten.
Das Flackern kann ich mir vorstellen. Der esp macht das alles per soft PWM und teilt sich die IRQ mit ddem Wifi. Wird aber tolerierbar sein.

vg
joerg

[ext23]

Moin,

Soft PWM? Irgs....

Mit welcher Frequenz wird hier gearbeitet? Man muss ja immer ein gesundes Mittel finden zwischen dem was die Augen als Flackern wahrnehmen (Und vor allem das Gehirn wahrnimmt und stresst) und was den EMV Richtlinien gerecht wird. Viele Nutzen um die 200 Hz, solange man keine bewegten Objekte zu Hause hat geht das auch, aber fürs Gehirn ist es natürlich "Stress".

/Daniel

[mrpj]

Moin

die arduino lib für den esp nutzt 1khz 10bit pwm als default - siehe https://github.com/esp8266/Arduino/blob/master/doc/reference.md#analog-output

Ist aber auch modifizierbar. Wie Joerg schon geschrieben hat, teilt sich der esp den timer für den adc mit wifi. Das macht aber bei mir im Testbetrieb hier nicht viel aus. Auch wenn ich den ESP mit ping requests/http Anfragen belastet habe, habe ich keine aussetzer und kein (merkliches) Flackern erlebt. (Ich hab aber auch nicht die Beleuchtung die ganze Zeit angestarrt, sondern als normale Zimmerbeleuchtung Abends angehabt)

[Garagenhaus]

Hi mrpj,

https://github.com/patrickjahns/esp_rgbww_controller/blob/v1.1/esp12_RGBWW.brd
beim Öffnen der Eagle *brd bekomme ich die Fehlermeldung:
Fehler:
Zeile 6, Spalte 41: Dies ist keine EAGLE-Datei.

Benutze Eagle free 7.2.0