ESP RGBWW Wifi Led Controller - Hinweise zu Sammelbestellung 2.5

[RaspiLED]

Hi,
Bin auch mit 4 dabei
Danke und Gruß Arnd


FHEM auf Raspberry Pi 2, CUL, Signalduino, Intertechno, WifiLight mit H801 - ESP8266, ...

[vbs]

Freu mich über die 2. Sammelbestellung. Bin auch mit 10-15 Stück dabei!

Ansonsten ist mir noch eine Sache aufgefallen:
Mein Controller hat gerade wieder sein eigenes WLAN aufgespannt und ist nicht mehr in meinem WLAN eingebucht. Vermutlich weil ich vorhin meinen AP einige Minuten vom Stromnetz genommen habe. Da wurde der Controller natürlich vom WLAN disconnectet. Aber als der AP dann zurück war, hat er sich nicht wieder dort angemeldet aus eigenem Antrieb.

[Icinger]

Mein Controller hat gerade wieder sein eigenes WLAN aufgespannt und ist nicht mehr in meinem WLAN eingebucht. Vermutlich weil ich vorhin meinen AP einige Minuten vom Stromnetz genommen habe. Da wurde der Controller natürlich vom WLAN disconnectet. Aber als der AP dann zurück war, hat er sich nicht wieder dort angemeldet aus eigenem Antrieb.

Ging mir auch schon zweimal so, nach kurzen Stromausfällen bei Gewittern.
Bei mir wars sogar so, dass der Controller jedesmal in einem "undefined"-Zustand war, also weder ein eigenes WLAN hochspannte, noch sich ins bestehende einklinkte.
Musste beide Male den Controller reseten (vom Strom nehmen), dann baute er sein eigenes auf.

[herrmannj]

Bin auch mit 5 dabei ...

vg
joerg

[mrpj]

Danke euch für das Feedback zu meinen Anliegen mit der Sammelbestellung Nr. 2 - ich hab da noch eine Idee im Hinterkopf, ich lass das mal noch etwas Sacken und schreibe dann nochmal mehr dazu  .

Wie bei Sammelbestellung 1, werde ich das ganze mit Hilfe eines Google Formular organisieren. Tabellen sind doch wesentlich angenehmer zu sortieren als die Privaten Nachrichten oder Foren Posts

Wenn jemand garnicht mit dem Löten klarkommt, würde ich mich als stille "Lötreserve" anbieten,
hierzu wäre es von Vorteil, wenn das PCB schwarz wäre.
Das weiße PCB nimmt viel weniger Wärmestahlung auf als ein dunkleres.

Schade - dabei fand ich weiss doch ganz ansehnlich als PCB Farbe - tun es denn auch z.B. rote oder blaue PCBs? Ich finde der Controller darf ruhig etwas farbenfroh sein oder nicht ? 

Mein Controller hat gerade wieder sein eigenes WLAN aufgespannt und ist nicht mehr in meinem WLAN eingebucht. Vermutlich weil ich vorhin meinen AP einige Minuten vom Stromnetz genommen habe. Da wurde der Controller natürlich vom WLAN disconnectet. Aber als der AP dann zurück war, hat er sich nicht wieder dort angemeldet aus eigenem Antrieb.

Ich denke ich weiss woran es liegt - im Moment gibt es einen Counter der nach X fehlschlägen den Controller den AP aufspannen lässt.
Ich überlege mir nochmal, wie man es etwas besser gestalten kann - ich wollte verhindern dass man den Controller resetten muss (und seine Farbeinstellungen verliert), wenn man mal umzieht oder das Wlan Passwort ändert.

Ein kurzes Feedback dazu wäre hilfreich: Wie soll sich der Controller allgemein verhalten:
- Nur einen AP aufspannen, wenn der Controller resettet wurde?
- Falls nach X versuchen keine Verbindung möglich ist, einen eigenen AP aufspannen?

Bei mir wars sogar so, dass der Controller jedesmal in einem "undefined"-Zustand war, also weder ein eigenes WLAN hochspannte, noch sich ins bestehende einklinkte.
Musste beide Male den Controller reseten (vom Strom nehmen), dann baute er sein eigenes auf.

Trotz powercycle hat er sich nicht verbunden? Das ist etwas seltsam - ich versuch das mal nachzustellen und zu tracken woran es liegen könnte. Kannst du das Szenario etwas näher beschreiben? Stromausfall und AP war danach nicht mehr vorhanden?

[Icinger]

Genauer kann ichs leider nicht sagen, da ich beide Male zu dem Zeitpunkt nicht daheim war.
Jedenfalls gab es scheinbar kurze Stromausfälle (Uhr vom Herd, Mikro etc. waren auf 00:00), aber die APC-USV vom Serverschrank hatte nicht gemeckert.

Daheim ist mir dann aufgefallen, dass der Controller nicht mehr ansprechbar war.
Wie gesagt, gab es weder ein RGBxyz-WLAN, noch war er im Heim-WLAN vorhanden. Auch mittels nmap etc. nicht zu finden.

Da er auf der Terasse im Verteilerkasten eingebaut ist, hab ich kurzerhand einfach die Terasse für ein paar Sekunden vom Netz genommen.
Danach hat er von selbst sein WLAN hochgespannt.
Der AP war einwandfrei zu erreichen, als ich heimkam.

Mehr kann ich bislang nicht dazu sagen, hab auch nicht versucht, das mal nachzustellen.

lg, Stefan

[vbs]

Ein kurzes Feedback dazu wäre hilfreich: Wie soll sich der Controller allgemein verhalten:
- Nur einen AP aufspannen, wenn der Controller resettet wurde?
- Falls nach X versuchen keine Verbindung möglich ist, einen eigenen AP aufspannen?

Meiner bescheidenen Meinung nach, sollte der Controller dauerhaft (bzw. regelmäßig) versuchen, sich zum hinterlegten AP zu verbinden. Wenn der AP nicht in Reichweite ist oder keiner hinterlegt ist, dann das eigene Netz aufspannen.

[Pf@nne]

Moin,

zum  Verhalten bei/nach Stromausfall:

Ist bereits eine SSID hinterlegt, dann sollte der Controller dauerhaft versuchen sich mit diesem zu verbinden,
damit er nach Spannungswiederkehr schnellstmöglich wieder erreichbar ist.
Das darf nicht lange dauern.

Allerdings müsste jede Minute für ca. 20 Sekunden der eigene AP aufgemacht werden.
Der Start des AP über Reset ist ungünstig falls dieser unzugänglich verbaut ist.

Zur PCB-Farbe:

Je dunkler desto besser, blau sollte aber reichen..


Gruß
Marco

[oli82]

wäre ebenfalls mit 4 St. dabei

[pjakobs]

hmm.. der Gedanke, als Fallback den Accesspoint aufzumachen, wenn das hinterlegte SSID nicht zu erreichen ist ist ja nicht verkehrt. So bleiben die Controller erreichbar, wenn z.B. das wlan Password geändert wurde.
Egal, was da nun am Ende wird: Ich denke seit ein paar Tagen darüber nach, im fhem Modul dafür einen auto-Konfigurations-Mechanismus einzubauen. Ich stelle mir das so vor:
- der Host (primär ein RasPi, könnte aber alles andere sein) bekommt ein zweites WLAN Interface, das sich automatisch mit dem Controller AP verbindet
- wenn eine Verbindung mit diesem Netzwerk aufgebaut ist, wird ein Controller gesucht (Patrick: da wäre es interessant zu wissen, ob die Controller a) das AP Netz joinen falls es schon existiert oder in jedem Fall ein eigenes aufziehen und ob sie auf ip address Kollisionen checken)
- wenn ein Controlelr gefunden wird, wird überprüft, ob dort ein Netz hinterlegt ist, wenn ja wird der Controller in dieses Netz "geschickt"
- ist kein Netz hinterlegt, wird ein auf dem RasPi hinterlegtes Netz für den Controller konfiguriert

Nun kommt es nicht so häufig vor, dass wir neue Controller in's Netz konfigurieren, aber ich find's schon immer ein bisschen nervig, dass ich dafür irgendeinen Notebook in ein anderes WLAN Netz hängen muss. Automatik wäre hier schöner.
Nebenbei scheint das auch den Zustand der hier beschrieben wird zu beheben - natürlich nur im fhem Umfeld, aber hey, wir sind hier im fhem board

pj

[Bapt. Reverend Magersuppe]

wäre ebenfalls mit 4 St. dabei

Ich nehme 3 Stück. Langsam wird das unübersichtlich, wo kann man sich denn registrieren?

[mrpj]

Ich nehme 3 Stück. Langsam wird das unübersichtlich, wo kann man sich denn registrieren?

Wie bei Sammelbestellung 1, werde ich das ganze mit Hilfe eines Google Formular organisieren. Tabellen sind doch wesentlich angenehmer zu sortieren als die Privaten Nachrichten oder Foren Posts

Alle posts mit der Menge waren für mich bisher Feedback. Die 2te Sammelbestellung hat noch nicht begonne (daher bisher auch Hinweise zu Sammelbestellung 2 ). Und losgehts wenn ich die Zeit hatte die erste Seite aufzuräumen und wieder mehr Übersichtlichkeit in das Projekt zu bringen.

Ist bereits eine SSID hinterlegt, dann sollte der Controller dauerhaft versuchen sich mit diesem zu verbinden,
damit er nach Spannungswiederkehr schnellstmöglich wieder erreichbar ist.
Das darf nicht lange dauern.

Allerdings müsste jede Minute für ca. 20 Sekunden der eigene AP aufgemacht werden.
Der Start des AP über Reset ist ungünstig falls dieser unzugänglich verbaut ist.

Die Sachen mit den 20 Sekunden finde ich nicht für sinnvoll - führt mMn zu mehr Problemen - auch weil die Beacon/Announcement Intervalle nicht permanent sind. (Was auch gut ist - denn sonst würde man nochmehr das Funkband mit Paketen zumüllen  - Spaß mit dem ESP: http://hackaday.com/2016/01/14/inject-packets-with-an-esp8266/).
Ich denke man kann den AP dann permanent aufziehen, sofern sich der Controller nicht verbunden hat. (Wegen bößartigen Attacken mache ich mir erstmal keine Sorgen, denn man kann den AP des Controllers ja auch mit WPA2 verschlüsseln)

- wenn eine Verbindung mit diesem Netzwerk aufgebaut ist, wird ein Controller gesucht (Patrick: da wäre es interessant zu wissen, ob die Controller a) das AP Netz joinen falls es schon existiert oder in jedem Fall ein eigenes aufziehen und ob sie auf ip address Kollisionen checken)
- wenn ein Controlelr gefunden wird, wird überprüft, ob dort ein Netz hinterlegt ist, wenn ja wird der Controller in dieses Netz "geschickt"
- ist kein Netz hinterlegt, wird ein auf dem RasPi hinterlegtes Netz für den Controller konfiguriert

Ich verstehe gerade nicht was du möchtest? Möchtest du Controller untereinander automatisch verlinken? Das wird schwierig, denn Mesh Networking ist nicht im Sming SDK enthalten. Die ESPs kann man leider nicht in Reihe schalten, es gibt keine Routing (es ist im AP Mode des ESPs immer nur der ESP erreichbar).

[pjakobs]

Ich verstehe gerade nicht was du möchtest? Möchtest du Controller untereinander automatisch verlinken? Das wird schwierig, denn Mesh Networking ist nicht im Sming SDK enthalten. Die ESPs kann man leider nicht in Reihe schalten, es gibt keine Routing (es ist im AP Mode des ESPs immer nur der ESP erreichbar).

Nein, nicht mesh networking, die Idee ist primär Autokonfiguration und sekundär könnte man so Controller abholen, die nach einem Netzausfall im AP Mode hängen.

Idealerweise schalte ich einen frisch geflashten Controller ein, und fhem kümmert sich um alles andere - Netzkonfiguration, Device anlegen etc.

Solange ich einen Controller nach dem anderen einschalte ist das kein Problem. Für das hier vorliegende Szenario könnte es schwieriger werden, weil all Controller ihren AP aufspannen und darin auf 192.168.4.1 lauschen. Hmm..

Hübsch wäre halt, wenn der Controller erstmal schaut "ist mein Default Netz (RGBWW-AP vielleicht) schon vorhanden, wenn ja, joine ich das und mach APIPA für ne freie Adresse, wenn nein mache ich einen AP auf". Dann könnte man alle Controller im Default Netz enummerieren und nacheinander konfigurieren.

pj

[mrpj]

Jeder Controller macht sein eigenes WLAN Netz auf - die SSID bassiert auf dem Prefix "RGBWW" und seiner eigenen chipid - kann aber später durch den Nutzer verändert werden. Die chipid ist laut espressif "einzigartig" - also dürfte es da kein Problem mit konkurierenden SSIDs geben.

Ich verstehe daher nicht ganz, wozu der Controller eine andere IP im Accesspoint mode braucht? Jeder client der sich auf den AP des Controllers verbindet bekommt via DHCP eine IP zugewiesen. Auf dem AP des ESPs können zwei Clients nur mit dem ESP sprechen aber nicht client 1 <-> client 2 (der ESP hat kein Packet routing im AP Modus).

[AxelSchweiss]

Die Sachen mit den 20 Sekunden finde ich nicht für sinnvoll - führt mMn zu mehr Problemen - auch weil die Beacon/Announcement Intervalle nicht permanent sind. (Was auch gut ist - denn sonst würde man nochmehr das Funkband mit Paketen zumüllen  - Spaß mit dem ESP: http://hackaday.com/2016/01/14/inject-packets-with-an-esp8266/).
Ich denke man kann den AP dann permanent aufziehen, sofern sich der Controller nicht verbunden hat. (Wegen bößartigen Attacken mache ich mir erstmal keine Sorgen, denn man kann den AP des Controllers ja auch mit WPA2 verschlüsseln)

Eventuell kann man die Wartezeit und den Wiederholungsintervall ja einstellbar machen.
Ich hätte schon gerne das er ca. zwei Stunden lang versucht die Verbindung wieder aufzubauen.
Das muss er ja nicht aggressiv machen ... alle Minute reicht da.