WG oder "AllInOne"-Server?

[vento66]

wie löst man eigentlich das Thema LED Beleuchtung (= 9-12V DC) im Haus? Gibt es steuerbare Netzeile für KNX? Oder braucht das ein neues Bussystem Zentrale Lösungen dürften ja bei DC nicht so angebracht sein. Dezentral klingt es teuer.

Mal eine kurze Frage:Wie willst Du die LED's ansteuern? 9-12V ist etwas sehr unüblich. LED Beleuchtungen sind üblicherweisse 24V oder Konstantstrom (350 oder 700 mA) Dafür gibt es dan das fehlende Glied zu Deiner 7.2 Anlage, nämlich Dali. Bei Dali hast Du ein Dali Steuergerät, welches am KNX bus hängt und Vorschaltgeräte die über Dali angesteuert werden. LED's werden ja nicht über die Spannung gedimmt, sondern über PWM.

[makki]

Support für die Thermochrons einzubauen sollte kein Hexenwerk sein, bisher hat schlicht keiner gefragt..

1. irgendein IP-Router, funktional und preislich kaum relevante Unterschiede.. Die meisten sind eh OEM-Schwesterchen, also einfach beim Lieblingshersteller ins Regal langen..
2. Naja, es ist derzeit nichts "in bequem" da. linknx: xml editieren, selberschreiben in PHP/whatever; einem "normalen Anwender" müsste ich die Frage aktuell mit Nein beantworten.
3. LED: ja gibt für KNX, preislich allerdings IMHO (noch?) ziemlich daneben.
100 Punkte: DALI für LEDs und NV-Halogen oder speziell bei LEDs evtl. auch DMX

Wieviele Signalisierungssysteme hat eigentlich die ISS an Bord? In meiner bescheidenen Hütte werden es wohl 6.2 werden: (CAT7/LAN + KNX + OW + Powerline + TV/Coax + Telefon) + (WLAN + DECT).

Siehe oben, DALI haste vermutlich vergessen

Das ist schon etwas verrückt. Bitte sagt mir, dass das noch normal ist

Definitionssache, was ist "normal".. Sagen wir mal so, ich finde eine Elektroinstallation Stand 1930 wie es häufig praktiziert wird nicht normal

Makki

[grundi]

Achtung: Monsterposting voraus

Erst mal vielen Dank für die vielen schnellen und kompetenten Antworten. Dieses Forum hier ist ein gutes Argument für die WB, nebenbei bemerkt.

Zwischenzeitlich bin ich auf diesen Thread gestossten, der deckt das Thema mit ab. Ständig die selben Fragen der Noobs. Das muss nerven..

Dafür verwendet man einen Rohranlegefühler und Spannband, haben wir als Hülsenfühler mit angeschweißter gewölbter Anlegefläche und 1,5 m Zuleitung:
1-Wire Anlegetemperaturfühler / Rohranlegefühler, incl. Spannband

und mit Klemmkastengehäuse (und ebenfalls gewölbter Anlegefläche unten)
1-Wire Rohranlegefühler, incl. Spannband und Klemmkastengehäuse

OK, verstanden.

Nun, die Thermochrons sind teuer und eigentlich für den offline-Außeneinsatz vorgesehen (also der Landwirt wirft die in seine Felder und kommt einmal alle vier Wochen mit dem Traktor vorbei um den Inhalt mit einem mobilen Gerät auszulesen) oder auch in der Logistik (Überwachung der Einhaltung der Kühlkette).

Die Idee ist, dass man damit die Termeraturgeschichte an beliebigen Orten erfassen und damit analysieren kann. Für den Dauerbetrieb ist das nichts, aber für die Analyse an beliebigen Stellen sehr schön und elegant.

Im häuslichen Umfeld bringt das wenig, weil auch die Bauform - gerade wenn man Rohrleitungen oder die Estrichtemperatur mitschreiben will - eher ungeeignet ist.

Wir haben auch schon Thermochrons in Edlestahlrohren vergossen und damt den Temperaturverlauf innerhalb von entfernten Kompostierungsanlagen oder abbindendem Beton erfasst ("lost sensor").

Die vom WireGate Multifunktionsgateway gelesenen Daten sind im Standardformat RRD aufgezeichnet, ein Export nach CSV oder anderen Formaten ist entweder bereits enthalten oder leicht machbar. Also kein Problem das zu sichern oder zu migrieren.

Da könnte man bestimmt durch "externe" Logik z.B. die Daten eines Thermochrons irgendwie einschmuggeln?

Der Wunsch die Anzahl der Systeme klein zu halten ist allgemein verbreitet. Geht uns auch nicht anders. Allerdings führen die All-In-One Gedanken immer zu größeren Kompromissen im Design, zudem mangelnde Austauschbarkeit / Upgrade einzelner Komponenten und ein umfassender Funktionenausfall bei Defekt - weil zuviel nur von einem Gerät geleistet wird.

Das ist schon richtig, aber in meinem Haushalt gibt es immer genügend Hardware, den den Ausfall der WB sehr schnell kompensieren könnten, wenn das System virtualisiert und die Kommunikation IP basiert ist. Die Freuden der Virtualisierung sind in eurem Ecosystem noch nicht so bekannt, scheint mir, Stichwort "Serverkonsolidierung".
Im Bezug auf die Peripherie (Aktoren/Sensoren/Leitungen etc) sind die Lösungen gleichwertig. Wozu n Systeme betreiben/kaufen/warten wenn jedes System für sich (fast) pausenlos Däumchen dreht.

Nicht zwangsläufig. Das WireGate Multifunktionsgateway schaffte im internen LAN-Performancetest - Makki korrigiermich wenn ich es falsch wiedergebe - knapp über 90 MBit/s bei moderater Prozessorlast.

Klar, aber ein Core2Duo mit 2 GB RAM (mein "altes" Notbook) zieht schon etwas mehr vom Teller.

Schließlich läuft hier kein Windows, sondern ein hocheffizientes Debian-Linux.

Ich will hier keinen Religionsstreit entfesseln, aber ich betreibe seit Jahren Windows, OSX und Linuxlösungen. Windows ist sehr wohl für 24/7 Betrieb geeignet, allerdings ist es einfacher, Linux ressoucenschonend einzusetzen, das stimmt. Dieses Argument zählt aber mit meiner Recycling Hardware nicht, denn die ist eh Überdimensioniert.

Nun, das ist Deine Entscheidung natürlich. Allerdings solltest Dir den Aufwand nicht so gering vorstellen, wir arbeiten am heutigen Stand seit zwei Jahren.
Was den Preis betrifft, die HW macht bereits die Hälfte der Kosten aus, der Rest ist für die fertige Installation, die zweijährige Gewährleistung (und wir verschicken schon nur bei Verdacht eines HW-Fehlers vorab raus!) und insbesondere die laufenden (ca. 14 tägigen) Updates und unseren sehr individuellen Support. In Notfällen sind wir echte 24/7 telefonisch erreichbar.

Alles sehr gute Argumente. Mir geht es um das Thema Vereinfachung. Wenn mein System ausfällt kann ich dank Virtualisierung meiner Frau am Telefon sagen, worauf sie Doppelklicken muss, damit es wieder läuft. Dazu müsste sie nicht mal in den Keller. Selbst wenn das Netzteil abraucht o.Ä. Ich könnte sogar ohne Mehrkosten ein komplettes Backupsystem vorhalten.

Meines erachtens nach - auch wenn ich als Hersteller befangen sein mag - rechtfertigt der anzunehmende Zeitaufwand für die Selbstimplementierung (und auch aller laufenden Updates) und mangelnden Support am Ende nicht die Einsparungen von ca. 180.- EUR (halber Preis, die andere Hälfte ist ja für die HW).

Der Preis ist bei den Zahlen, die mir gerade um den Kopf schwirren nicht das Hauptthema. Verglichen mit den anderen "Lösungen" ist das WG sehr günstig.

Ließ mal hier (u.a. die die Kommentare der beiden WG-Selbstbauer Bodo und ThorstenGering):
https://knx-user-forum.de/forum/supp.../wiregate/9816

Das habe ich vorhin schon, das geht in die selbe Richtung.

Kein Problem, wir leben Open Source, da gehört auch offene Diskussion dazu

Sehr schön. OS ist aber leider keine Gewähr für frei denkende Leute, sagt meine Erfahrung.

Das ist das IP Gateway, nicht der IP Router, oder?

Ja, so habe ich das verstanden. Ich sehe oft die /21 (nicht /22) Version, was ist da eigentlich der Unterschied?

Prinzipiell spricht nichts dagegen und der Gedanke der Unabhängigkeit ist auch nicht verkehrt (wieso auf RS232 oder gar USB gehen, wenn's auch IP gibt?...)

Genau so sehe ich das auch. Gibt es Alternativen in der Preisklasse (...ich habe eine berufsbedingte Siemens-Allergie, mein Elektriker anscheinend auch)

IIRC hat das "IP Gateway" das Problem, dass ein HS nicht darüber betreibbar ist, der würde den "IP Router" benötigen - das war der Grund, warum ich zum Router gegriffen habe (damals gab's das WireGate noch nicht). Auch wenn's teurer war, ist das die wahre, und flexibelste Lösung.
Außerdem erlaubt der Router den Zugriff von mehreren Stellen gleichzeitig, d.h. ich muss nicht die Visu abklemmen um mit der ETS auf den Bus zu kommen.

Stimmt. Mal sehen, was der Preisunterschied ist. Wenn ich die WB abklemme, bekommt sie auch Gedächtnislücken (...Thermochron...).

Ein "IP Gateway" kann jedoch mit dem eibd, der dann IP-Router spielt, quasi aufgewertet werden - aber nur wenn eben eine "Box" extra läuft. Und zwar durchgehend.

Das ist die etwas vertrackt Logik, das stimmt. Für eine WB-lose welt ist die IP-basierte Lösung jedenfalls vorzuziehen, und das Argument wird vermutlich den Ausschlag geben.

Direkt geht's wohl nicht (außer Du schreibst sämtliche Software neu...). Aber über den eibd wird's wohl gehen, musst halt mal die Beispiele vom bcusdk durchschaun.

Irgendwie geht fast alles, aber ich will auch nicht das Rad nochmal erfinden (...müssen).

Für den Visu-Teil, der mit dem KNX kommuniziert, ist PHP nicht die beste Lösung. Da nimmt man besser ein bis zwei mini Programme, die die Kommunikation mit dem eibd übernehmen, per CGI erreichbar sind und die entsprechenden Daten per JSON über HTTP bereitstellen. Hier nun noch etwas AJAX und COMET dazu (die Web-Seiten dürfen gerne per PHP generiert werden) und fertig ist eine rasend schnelle, Echtzeit fähige, komplett Browser basierte Visu.

Genau so hätte ich es auch gelöst, wenn ich mehr Zeit hätte. Überhaupt finde ich viele Ideen von mir in Deinen Posts wieder. Ich würde auch den Betatester spielen, die JS Welt würde ich etwas anders angehen als Du, aber das sind Details. Die immer schlaueren und schnelleren Browser sind klar die Zukunft hier.

PHP braucht als Scriptsprache eine sehr kurze Toolchain, und Performance wäre auf einem C2D Notebook auch kein wirkliches Argument.

Das gute: die beiden kleinen, benötigten Programme sind schon auf dem WireGate vorhanden, aber da geht's jetzt aktuell in den Bereich des Beta-Testens...

Für mich wird das ganze eh erst im nächsten Sommer akut. Würde auch den Piloten spielen.

1+2. Richtig. vorinstalliert: PHP Version 5.2.6-1+lenny4. Wenn man so ungefähr weiss, was man mit ssh, console&PHP so tut: ja, warum nicht..

Das effizienteste ist es nicht, aber die Hardware sollte es hergeben

Auf der Box ist an der Unterseite ein Aufkleber mit dem root-Passwort, ob und wie man das nutzt ist jedem selbst überlassen..

Ohne das wäre für mich das WG nur halb so attraktiv.

3. Klar. Man kann aber auch einfach "apt-get install apache2.." machen, es kann dann eben nur sein, das man manche Komfortfunktionen bei Updates etc. nicht mitbekommt, da man sich damit bzgl. des Webservers in einen unsupporteten Zustand begibt; solange man damit leben kann: auch kein Thema.

damit könnte ich leben, die alternative wäre ja eh one support

Letztlich Geschmackssache, beides hat Vor&Nachteile, wenn man allerdings übern eibd auf die IP-Schnittstelle muss (weil N148/01 nur eine Verbindung, /22 AFAIK 4), machts wohl keinen Sinn mehr.. Wenn IP dann IMHO nen Router.
Das TP-UART hat neben einigem anderen einen Vorteil: Man kann (und es werden) Ack's versendet - wichtig bei 1-Linien-Installationen ohne LK mit "Soften Geräten wie HS, WireGate&Co, Stichwort Telegrammwiederholungen..

OK

5. Theoretisch ja, Beispiele wären mir keine bekannt.. Aber genau diesen blutigen Teil nimmt einem der eibd ja umfassend ab und liefert eine dokumentierte API mit Beispielen..
Makki

Das wäre nur eine extreme Fallback-Position. Meine Erfahrung sagt: je weniger Komponenten, desto zuverläsiger, leichter wartbar, einfacheres debuging und man tut sich später leichter, wieder einzusteigen.

Ich will ja irgendwann wieder in einen Zustand kommen, wo KNX/OW & Co wieder aus meinen Gedankengängen verschwinden können.

Jetzt nochmal die Fragen:

1. welches ist jetzt die empfohlene Lösung, wenn man die WB via IP betreiben möchte
2. man bekommt mit der WB auch die Möglichkeit, sich eine Browser-basierte Steuerung/ViSu schnell zusammen zu basteln, richtig? Das muss nicht die endgültige Lösung sein, sollte aber nach Inbetriebnahme schnell zur Verfügung stehen, WAF etc.
3. wie löst man eigentlich das Thema LED Beleuchtung (= 9-12V DC) im Haus? Gibt es steuerbare Netzeile für KNX? Oder braucht das ein neues Bussystem Zentrale Lösungen dürften ja bei DC nicht so angebracht sein. Dezentral klingt es teuer.

...und jetzt die 100-Punkte Frage:

Wieviele Signalisierungssysteme hat eigentlich die ISS an Bord? In meiner bescheidenen Hütte werden es wohl 6.2 werden: (CAT7/LAN + KNX + OW + Powerline + TV/Coax + Telefon) + (WLAN + DECT).

Das ist schon etwas verrückt. Bitte sagt mir, dass das noch normal ist

Grüßle

[makki]

1+2. Richtig. vorinstalliert: PHP Version 5.2.6-1+lenny4. Wenn man so ungefähr weiss, was man mit ssh, console&PHP so tut: ja, warum nicht..
Auf der Box ist an der Unterseite ein Aufkleber mit dem root-Passwort, ob und wie man das nutzt ist jedem selbst überlassen..
3. Klar. Man kann aber auch einfach "apt-get install apache2.." machen, es kann dann eben nur sein, das man manche Komfortfunktionen bei Updates etc. nicht mitbekommt, da man sich damit bzgl. des Webservers in einen unsupporteten Zustand begibt; solange man damit leben kann: auch kein Thema.
4. Letztlich Geschmackssache, beides hat Vor&Nachteile, wenn man allerdings übern eibd auf die IP-Schnittstelle muss (weil N148/01 nur eine Verbindung, /22 AFAIK 4), machts wohl keinen Sinn mehr.. Wenn IP dann IMHO nen Router.
Das TP-UART hat neben einigem anderen einen Vorteil: Man kann (und es werden) Ack's versendet - wichtig bei 1-Linien-Installationen ohne LK mit "Soften Geräten wie HS, WireGate&Co, Stichwort Telegrammwiederholungen..
5. Theoretisch ja, Beispiele wären mir keine bekannt.. Aber genau diesen blutigen Teil nimmt einem der eibd ja umfassend ab und liefert eine dokumentierte API mit Beispielen..

Den Rest hatten wir ja schon

Makki

[Chris M.]

1. PHP ist auf dem WG kein Problem, richtig? (CLI + CGI?)

Ja, habe ich schon genutzt: wunderbar, out-of-the-box, ohne Probleme

1. läuft das Beisbiel aus bcusdk_0.0.4 aus dem Verzeichnis bcusdk-0.0.4\contrib\eibdvis\ out of the box (mit der angepassten config.php)?

Keine Ahnung - ich vermute ja.

1. man kann den lighttpd im WG für die eigene Visualisierung verwenden (bisher verwende ich nur den Apachen)?

Klar - genau das mache ich zur Zeit

1. was spricht eigentlich gegen den Einsatz einer N148/22 anstelle des TP-UART? Damit wäre es egal, wo die Intelligenz räumlich steht (vorzugsweise in meinem Regal). Preislich ist das afaik nicht viel anders, aber die IP-basierte Lösung scheint mir flexibler zu sein, weil WG optional. Ausserdem lässt sich diese Lösung leichter virtualisieren, weil keine USB oder RS232 Schnittstellen verwendet werden

Das ist das IP Gateway, nicht der IP Router, oder?

Prinzipiell spricht nichts dagegen und der Gedanke der Unabhängigkeit ist auch nicht verkehrt (wieso auf RS232 oder gar USB gehen, wenn's auch IP gibt?...)

IIRC hat das "IP Gateway" das Problem, dass ein HS nicht darüber betreibbar ist, der würde den "IP Router" benötigen - das war der Grund, warum ich zum Router gegriffen habe (damals gab's das WireGate noch nicht). Auch wenn's teurer war, ist das die wahre, und flexibelste Lösung.
Außerdem erlaubt der Router den Zugriff von mehreren Stellen gleichzeitig, d.h. ich muss nicht die Visu abklemmen um mit der ETS auf den Bus zu kommen.
Ein "IP Gateway" kann jedoch mit dem eibd, der dann IP-Router spielt, quasi aufgewertet werden - aber nur wenn eben eine "Box" extra läuft. Und zwar durchgehend. Wenn man das macht, dann hätte man aber auch ein TP-UART nehmen können...
Zusätzlich soll wohl - hier ist aber mein Wissen sehr dünn - der TP-UART "näher" am Bus sein, d.h. damit sollte sich bei geeigneter Software detaillierter der Busstatus ablesen lassen können.

1. kann man mit PHP auch direkt über eine N148 ("KNXnet") mit dem KNX Bus kommunizieren? Gibt's Beispiele?

Direkt geht's wohl nicht (außer Du schreibst sämtliche Software neu...). Aber über den eibd wird's wohl gehen, musst halt mal die Beispiele vom bcusdk durchschaun.

Nur, einen Sinn sehe ich da nicht drinnen...

Für den Visu-Teil, der mit dem KNX kommuniziert, ist PHP nicht die beste Lösung. Da nimmt man besser ein bis zwei mini Programme, die die Kommunikation mit dem eibd übernehmen, per CGI erreichbar sind und die entsprechenden Daten per JSON über HTTP bereitstellen. Hier nun noch etwas AJAX und COMET dazu (die Web-Seiten dürfen gerne per PHP generiert werden) und fertig ist eine rasend schnelle, Echtzeit fähige, komplett Browser basierte Visu.
Das gute: die beiden kleinen, benötigten Programme sind schon auf dem WireGate vorhanden, aber da geht's jetzt aktuell in den Bereich des Beta-Testens...

[StefanW]

Hallo und herzlich willkommen,

die Fragen 1-5 überlasse ich lieber Makki,

6. was für einen 1Wire Temperatursensor würde man verwenden um Vor- und Rücklauftemperatur zu loggen (wie bekommt man den thermischen Kontakt zum Rohr?)

Dafür verwendet man einen Rohranlegefühler und Spannband, haben wir als Hülsenfühler mit angeschweißter gewölbter Anlegefläche und 1,5 m Zuleitung:
1-Wire Anlegetemperaturfühler / Rohranlegefühler, incl. Spannband

und mit Klemmkastengehäuse (und ebenfalls gewölbter Anlegefläche unten)
1-Wire Rohranlegefühler, incl. Spannband und Klemmkastengehäuse

7. warum eigentlich verwendet kaum jemand die Thermochrons (1921, 1922) Dann wäre die Historie im System, ein Wechsel der Intelligenz wurde keinen Gedächtnisverlust bedeuten (ja, der Bus ist langsam, aber JS ist schlau)

Nun, die Thermochrons sind teuer und eigentlich für den offline-Außeneinsatz vorgesehen (also der Landwirt wirft die in seine Felder und kommt einmal alle vier Wochen mit dem Traktor vorbei um den Inhalt mit einem mobilen Gerät auszulesen) oder auch in der Logistik (Überwachung der Einhaltung der Kühlkette).
Im häuslichen Umfeld bringt das wenig, weil auch die Bauform - gerade wenn man Rohrleitungen oder die Estrichtemperatur mitschreiben will - eher ungeeignet ist.
Die vom WireGate Multifunktionsgateway gelesenen Daten sind im Standardformat RRD aufgezeichnet, ein Export nach CSV oder anderen Formaten ist entweder bereits enthalten oder leicht machbar. Also kein Problem das zu sichern oder zu migrieren.

Eigentlich wollte ich ein brachliegendes, untertaktetes C2D-, 2GB- RAM Notebook als 24/7-Server zu verwenden, vlt ist ein dediziertes WireGate aber doch die bessere Lösung. Andererseits will ich aber die Anzahl der Systeme klein halten.

Der Wunsch die Anzahl der Systeme klein zu halten ist allgemein verbreitet. Geht uns auch nicht anders. Allerdings führen die All-In-One Gedanken immer zu größeren Kompromissen im Design, zudem mangelnde Austauschbarkeit / Upgrade einzelner Komponenten und ein umfassender Funktionenausfall bei Defekt - weil zuviel nur von einem Gerät geleistet wird.

KNX ist ein eigentlich dezentrales System, das sollte man auch bei den zusätzlichen Komponenten wir Logik, Visu, Mediensteuerung usw. auch weiterhin so halten. Führt aber zu mehreren Boxen.

Z.B. für Video-Streaming ist ein 500 MHz LX 800 doch etwas überfordert.

Nicht zwangsläufig. Das WireGate Multifunktionsgateway schaffte im internen LAN-Performancetest - Makki korrigiermich wenn ich es falsch wiedergebe - knapp über 90 MBit/s bei moderater Prozessorlast. Da war jetzt zwar kein Massenspeicher beteiligt, aber das wäre mal auszuprobieren. Es gibt auch das Multifunktionsgateway mit 3 LAN-Anschlüssen (momentan noch Bückware, d.h. steht nicht im Shop) um als Firewall, Reverse-Proxy für Remote-Visu, Internetzugang zu dienen. Läuft einwandfrei an VDSL bis 50M und an einer 34M Standleitung.

Schließlich läuft hier kein Windows, sondern ein hocheffizientes Debian-Linux.

Allerdings, wie Makki gestern schon geschrieben hat, Du hast entweder ein gutes NAS oder ein gutes Wiregate (ging darum WG-Funktionen auf einer Synology zu installieren.

Mir ist klar, dass die all-in-one Lösung in Linux mit etwas post-materiellem Basteln verbunden ist. Zur Not könnte ich ja das WG später dazukaufen, kaputt gemacht hätte ich dann aber auch nichts. Den Aufwand mit PHP, JS & Co könnte ich ja auf dem WG recyclen, wenn PHP dort läuft.

Nun, das ist Deine Entscheidung natürlich. Allerdings solltest Dir den Aufwand nicht so gering vorstellen, wir arbeiten am heutigen Stand seit zwei Jahren.
Was den Preis betrifft, die HW macht bereits die Hälfte der Kosten aus, der Rest ist für die fertige Installation, die zweijährige Gewährleistung (und wir verschicken schon nur bei Verdacht eines HW-Fehlers vorab raus!) und insbesondere die laufenden (ca. 14 tägigen) Updates und unseren sehr individuellen Support. In Notfällen sind wir echte 24/7 telefonisch erreichbar.
Meines erachtens nach - auch wenn ich als Hersteller befangen sein mag - rechtfertigt der anzunehmende Zeitaufwand für die Selbstimplementierung (und auch aller laufenden Updates) und mangelnden Support am Ende nicht die Einsparungen von ca. 180.- EUR (halber Preis, die andere Hälfte ist ja für die HW).

Ließ mal hier (u.a. die die Kommentare der beiden WG-Selbstbauer Bodo und ThorstenGering):
https://knx-user-forum.de/forum/supp.../wiregate/9816

...vielleicht eine etwas ketzerische Frage in einem WG Forum, ich weis

Kein Problem, wir leben Open Source, da gehört auch offene Diskussion dazu

[grundi]

Hallo Forum,

ich plane gerade ein EFH mit teilweiser KNXsierung (Rolladen + WiGa + Kleinkram) und erwäge, dafür ein WireGate anzuschaffen.
Die Anlage wird erst mal so konfiguriert, dass es für den Normalbetrieb keine zusätzliche Visu/Steuerung/Regelung braucht (hoffentlich).
Ich bin Newbie und bisher KNX-Theoretiker, daher mögen meine Fragen für die Veteranen hier etwas banal sein.

1. PHP ist auf dem WG kein Problem, richtig? (CLI + CGI?)
2. läuft das Beisbiel aus bcusdk_0.0.4 aus dem Verzeichnis bcusdk-0.0.4\contrib\eibdvis\ out of the box (mit der angepassten config.php)?
3. man kann den lighttpd im WG für die eigene Visualisierung verwenden (bisher verwende ich nur den Apachen)?
4. was spricht eigentlich gegen den Einsatz einer N148/22 anstelle des TP-UART? Damit wäre es egal, wo die Intelligenz räumlich steht (vorzugsweise in meinem Regal). Preislich ist das afaik nicht viel anders, aber die IP-basierte Lösung scheint mir flexibler zu sein, weil WG optional. Ausserdem lässt sich diese Lösung leichter virtualisieren, weil keine USB oder RS232 Schnittstellen verwendet werden
5. kann man mit PHP auch direkt über eine N148 ("KNXnet") mit dem KNX Bus kommunizieren? Gibt's Beispiele?
6. was für einen 1Wire Temperatursensor würde man verwenden um Vor- und Rücklauftemperatur zu loggen (wie bekommt man den thermischen Kontakt zum Rohr?)
7. warum eigentlich verwendet kaum jemand die Thermochrons (1921, 1922) Dann wäre die Historie im System, ein Wechsel der Intelligenz wurde keinen Gedächtnisverlust bedeuten (ja, der Bus ist langsam, aber JS ist schlau)

Hintergrund:
Eigentlich wollte ich ein brachliegendes, untertaktetes C2D-, 2GB- RAM Notebook als 24/7-Server zu verwenden, vlt ist ein dediziertes WireGate aber doch die bessere Lösung. Andererseits will ich aber die Anzahl der Systeme klein halten.

Einen Mail-, Medien-, Backup-, File- HTTP- 24/7 Server wird es ohnehin geben, warum da nicht die Visu/Steuerung gleich mit draufpacken? Z.B. für Video-Streaming ist ein 500 MHz LX 800 doch etwas überfordert.

Falls es mal steht ist das kein Drama, ausserdem will ich es virtualisieren, sodass eine Backuplösung sehr schnell zur Verfügung steht.

Mir ist klar, dass die all-in-one Lösung in Linux mit etwas post-materiellem Basteln verbunden ist. Zur Not könnte ich ja das WG später dazukaufen, kaputt gemacht hätte ich dann aber auch nichts. Den Aufwand mit PHP, JS & Co könnte ich ja auf dem WG recyclen, wenn PHP dort läuft.

...vielleicht eine etwas ketzerische Frage in einem WG Forum, ich weis