Erweiterungsmodule

[Antimone]

Ich schätze das System wegen seiner Web-Oberfläche, mit der man an kein App-Biotop gebunden ist. Einen Browser hat schließlich jedes noch so exotische System *top*
Viele sinnvolle Funktionen (wie die kommende Verbrauchsmessung) machen das System zur eierlegenden Wollmilchsau.
(Gibt's dafür eigentlich schon ein Erscheinungs-Datum?)

Andererseits wird man immer auf externe Erweiterungen, wie PowerLan, Wifi, Last-Schütze, Pegelwandler etc zurückgreifen müssen.

Wäre es nicht sinnvoller, solche Erweiterungen als Anel-spezifische Zusatz-Hardware-Bausteine anzubieten, die dann seamless in der vorhandenen Web-Oberfläche einer 'Master-HUT' erscheinen?

Beispiel:
Für eine RGB-LED-Steuerung nutze ich derzeit die Ansteuerung über die I/Os der NetPwrCntrl Hut. In diesem konkreten Fall wäre eine Erweiterung der Ports wünschenswert. Das geht natürlich auch über mehrere Hut-Module. Dafür muss man dann aber eine eigene Website vorhalten, die die nötigen Kommandos für alle Geräte generiert. Abgesehen davon, dass für viele Anwender diese Hürde unüberwindlich ist, liegt dabei die Fähigkeit der Hut-Module sinnlos brach und es könnten genauso gut billige IP-Steckdosen zum Einsatz kommen.

Statt immer mehr Funktionen in einem Gerät zu vereinen, die von keinem Anwender mehr in vollem Umfang benötigt werden, plädiere ich für ein Modulsystem.

Die Kommunikation der Geräte untereinander könnte über PowerLan (da Netzanschluss ohnehin vorhanden) oder eines der Protokolle der Hausautomatisierung (FS20, X10 usw.) erfolgen. Damit könnten Erweiterungsmodule auch an entfernten Orten ins System eingebunden werden. Bspw wäre die hier im Forum nachgefragte fernschaltbare Einzelsteckdose damit kein Problem.
Im einfachsten Fall könnten die Erweiterungsmodule einfach eine Unterseite für die Website der 'Master-HUT' generieren. Die Verbindung der Geräte müsste der Anwender dann selbst durch Lan-Kabel, Wlan oder PowerLan realisieren.
WiFi wäre eher zu meiden, da die begrenzte Bandbreite den steuernden Mobilgeräten exklusiv vorbehalten sein sollte.

Da wir gerade beim Wünschen sind:
Mir fehlt ein Modul mit Dimmerausgängen,
ein Modul mit RGB-LED-Ansteuerung (defacto auch nur Dimmermodule),
ein Dateneingangsmodul zum Anschluss von Sensoren
Für eine 'Master-HUT' wünsche ich mir eine einfachere Anpassung der integrierten html-Seite, keine Kompression/mehr Speicherplatz (isch 'abe keine Windows :p)

Derzeit realisiere ich das über die I/Os mehrerer HUT-Module und einen Server für das GUI
--> ziemlich viel Hardware-Overkill
--> leider keine Mainstream-Lösung für DAUs ;(

Die geplante Scriptsprache wäre sicher auch geeignet, gewünschte Abhängigkeiten im System zu hinterlegen. Allerdings besteht bei solchen Software-Erweiterungen immer die Gefahr auf Nerd-Niveau abzurutschen. Für die breite Masse ist Plug and Play wichtiger als Konfigurierbarkeit bis ins letzte Zipfelchen

Um den Entwicklungsaufwand klein zu halten, wäre es vllt auch sinnvoll, die Integration vorhandener Hausautomatisierungsmodule in Erwägung zu ziehen.

[andy]

Hi Antimone,

Danke, sehr ausführlich und interessant.

Wir werden es genau studieren, alles ist nicht möglich aber wünschenswert.

LG Andy

[Antimone]

Beim 'Studieren' sollten Sie vllt auch einen Blick über den Tellerrand werfen
Ihr derzeitiges Alleinstellungsmerkmal gegenüber anderen Anbietern (bspw: http://denkovi.com/category/11/ip-relay-boards.html) besteht in der einfach zu individualisierenden, intergrierten WebSite der NetPwrCntrl ...also der Betriebssystemunabhängigkeit.
Hardwarenahe Anwender haben genügend Alternativen - nicht zuletzt wegen der steigenden Verbreitung von Arduino & Co.
Dagegen gibt es zahlreiche Anwender mit html-Kenntnissen o.ä., für die Hardware böhmische Dörfer sind, die aber vor der Aufgabe stehen, virtuelle Oberflächen mit der realen Welt zu verknüpfen.
Die große Verbreitung von FS20 in DE oder X10 in US zeigt doch sehr gut, dass trotz dieser verhältnismäßig primitiven Systeme eine Ausrichtung auf eine größere Zielgruppe für mehr Verbreitung und damit langfristig größeren Entwicklungsspielraum sorgt. Mit Ihrem Streben zur eierlegenden Wollmilchsau mit einer ggf eigenen Script-Sprache geraten Sie, wie bereits erwähnt, in die Nähe des Nerd-Niveaus und damit in die Gefahr, Nischenanbieter zu werden.

Ich selbst stehe derzeit vor der Wahl,
entweder eigene GUI-Infrastruktur durch 'dumme Relais' etc zu ergänzen
oder auf eine kooperative Integration Ihrer 'HTML-Relais' und 'HTML-I/O' zu setzen (zu warten/zu hoffen).
Dazu müsste die html-Entwicklung systemunabhängig möglich sein und der Speicherplatz der HUT heutigen multimedialen Anforderungen an Webseiten entsprechen.
Glücklicherweise bin ich in der privilegierten Position, nicht auf anel-eigene PnP-Hardware-Ergänzungen angewiesen zu sein, was man für die Mehrheit Ihrer Zielgruppe sicher nicht voraussetzen kann.
Vllt könneten Sie sich abseits der Lobhudelei für meine Vorschläge zu Andeutungen Ihrer Präferenzen hinreißen lassen :p

[andy]

Es ist zwar sehr polemisch, hebe aber nicht ganz verstanden worum es geht.

Wir brauchen als Techniker klare aussagen. Erweiterungen aber keine Wollmilchsau oder doch?

Script-Sprache hätte jedes Problem mit Extrawünschen erledigt, ist aber nicht angenommen worden. Schade.

Was möchten Sie uns sagen?

LG Andy

[Antimone]

Tut mir leid, dass ich da etwas undeutlich rüber kam =:-)
In erster Linie wollte ich eigentlich gern erfahren, wohin Ihre Entwicklung geht

Letztlich tragen Sie das unternehmerische Risiko und sollten daher selbst vorgeben, wohin die Reise geht.

Was mir vorschwebt, ist ein modulares System mit einzelnen anel-Bausteinen, die ein neues Ganzes bilden - Lego-ähnlich

Ich versuche mich noch einmal an der Metapher:
Will ich ein eierlegendes Wollmilchschaf, nehme ich ein Woll-Modul, ein Milch-Modul usw.
Wenn ich nun bspw mit einem Smartphone die gemeinsame Seite dieser Module aufrufe, sehe ich ein Wollmilchschaf in Gänze, ohne mir Gedanken machen zu müssen, wie ich an die Milch, die Wolle oder die Eier herankomme.
Ein Endanwender geht ja auch nicht in den Hühnerstall, den Kuhstall usw. sondern er bekommt die gesamte verfügbare Produktpalette automatisch präsentiert, an seine Bedürfnisse angepasst (aka Supermarkt)

zurück zur Technik:
Für einen Anwender müssten die Bausteine quasi 'selbstvernetzend' sein; nicht nur auf Hardware- sondern vor allem auch auf Software-Ebene.
Fügt er bspw ein weiteres Relais-Modul hinzu, müssten statt der 8 Schaltflächen 16 erscheinen. Analog dazu könnten auch anel-fremde Module in die Oberfläche integriert werden - ähnlich der nachladbaren KernelModule bei Linux - nur eben auf Anwendungsebene.
Der Anwender sollte mit den unteren Ebenen nicht konfrontiert werden (ggf von der Auswahl des phys.Layer abgesehen)
Eine Meshnetz-Struktur wäre sicher ideal, um auf dedizierte Steuerserver verzichten zu können.

Trotzdem sollte die HTML-Seite der anel-Module vom Anwender individuell gestaltbar bleiben - und das konsequent systemunabhängig. Webseiten-Gestalter, die eine gewünschte Individualisierung vornehmen, gibt's genügend - meist sogar im Hobbybereich in der Nachbarschaft

Der Endanwender erhält quasi Hardware-Apps zum Stecken nur ohne android, iOS oder andere Biotop-Käfige

Natürlich schränke ich damit die Flexibilität in's I-Tüpfel ein. Das macht aber auch Apple
Obwohl Macs auch nur aus Standard-Hardware bestehen, wird die Auswahl stark eingeschränkt - zugunsten einer 'idiotensicheren' Konfiguration durch jeden DAU.
Wichtiger als Performance-Optimierung sind Bonjour und Co.

Ob man die Hardware-Ebene der Vernetzung dabei dem Anwender überlässt oder
den Modulen eigenes Wlan/PowerLan (ggf als Zusatzmodul) spendiert, wäre noch überlegenswert.

Natürlich können wir uns auch gern detailierter über meine Ideen unterhalten. Ob das öffentliche Forum für Lösungsansätze die geeignete Plattform ist, müssten Sie entscheiden, denn hier lesen auch andere mit