[AMADNG] Alles neu macht der Mai

[CoolTux]

Hallo Leute,

Ich habe vor den kompletten Unterbau von AMAD neu zu entwerfen. Ganz besonders möchte ich hier Hand an die AMADCommBridge legen. Ziel ist es die CommBridge Abseits von FHEM zu betreiben, so das eventuelle Probleme mit der Bridge oder gar ein zu großes Trafficaufkommen FHEM nicht mehr bremsen. Es soll also ein Socketserver im NonBlocking Modus entstehen. Der Jörg hat mir da tolle Tips und Tricks verraten und ich hoffe ich finde weiterhin Unterstützung von seiner Seite für dieses (für mich) große Projekt.

Warum nun eigentlich AMADNG? Nun da es sich um eine größere Aktion handelt und ich sowieso die Bridge als IODev entwickeln wollte werden auch die TYPE Namen sich ändern.
70_AMADCommBridge.pm
74_AMADNG.pm
werden die neuen Module heißen.

Alles neu macht der Mai?? Jepp, so ist es. Denn das ganze soll bis Mai 2017 abgeschlossen sein.


Vorbereitet für das alles habe ich angefangen die aktuell stabile Version von AMAD ein paar Umbauten zu verpassen. Dazu mehr im aktuellen AMAD2 Thread.




Grüße
Leon

[accessburn]

Das bestehende AMAD2 wird aber ohne Änderungen lauffähig bleiben, oder?

[marvin78]

Darauf habe ich gehofft. AMAD ist bei mir aktuell ein echter Blocker und deshalb auf eine zweite Instanz ausgelagert. Dein Plan hört sich also sehr gut an.

[CoolTux]

Ja selbstverständlich. Und es wird auch noch bis mitte nächsten Jahres Supportet. Neuentwicklungen/Userwünsche fließen aber ausschließlich in die neue Version ein.

[dev0]

so das eventuelle Probleme mit der Bridge oder gar ein zu großes Trafficaufkommen FHEM nicht mehr bremsen.

Hast Du mal analysiert wo die Probleme herkommen, die Marvin auch angesprochen hat?
Da mein ESPEasy Modul auch die TcpServerUtils verwendet, wundert es mich, da ich, mit ESPEasy in meiner Umgebung, absolut keine Performanceprobleme feststellen kann. Allerdings ist der Netzwerktraffic mit den ESPEasy Clients auch eher gering. Versuche mit 3-4 Connect/s wirken sich laut Apptime so gut wie gar nicht aus, allerdings ist das Trafficvolumen dabei auch sehr gering, ca. 200-500 Byte pro Connect.

[CoolTux]

Messungen habe ich keine vorgenommen. Ich hatte spürbare Hänger im einstellen Sekundenbereich. Allerdings ausschließlich wenn FHEM vorher hing oder neustartete, da wurden dann die angesammelten Flows der einzelnen Tablets abgearbeitet. Das waren schon mal 200-300 Aktionen pro Tablet. Also Mal sieben.

Nun wurde aber in der Zwischenzeit die Arbeitsweise der Prüfungen geändert so das solch hohes Aufkommen erst gar nicht mehr auflaufen kann.
Daher ist es durchaus Möglich das genau dieses Problem nicht mehr existiert.

Vielleicht mag Marvin Mal mit der neusten Version testen.