KNX/EIB Computergesteuerte Aktor- und Sensorverwaltung

[derLeo]

Hallo allerseits,

ich bin KNX/EIB Neuling und beschäftige mich jetzt im Rahmen eines Forschungsprojektes an meiner Hochschule erstmals mit dem Thema.
Das Thema ist eigentlich gar nicht KNX/EIB sondern semantische Sensornetzwerke, wobei wir Haus-, bzw. Raumautomation als Anwendungsgebiet gewählt haben und da ist KNX mit seinem offenen Standard bislang für uns die beste Option.
Wichtig ist vielleicht noch, dass das Projekt (und Ich) im Studiengang Informatik statt finden, also Programmierkenntnisse sind vorhanden, die elektrotechnische Seite sollte aber so einfach wie möglich bleiben.

Meine Frage ist nun die, ob und wie es möglich ist Aktoren und Sensoren Computergesteuert zu betreiben.
Also Beispielsweise soll das Licht nicht über einen Taster gesteuert werden oder direkt durch einen Bewegungssensor beeinflusst werden, sondern die Sensoren sollen über den Computer ausgelesen werden und dann sollen die entsprechenden Aktoren wiederum über den Computer angesteuert werden. (Damit meine ich jetzt nicht zentral über einen bereits fertigen HC - es geht eher darum noch andere Möglichkeiten von Sensorkombinationen und Aktionen zu realisieren)

Ich versuche im folgenden mal ein paar "konkretere" Fragen zu formulieren, auf die man dann eventuell eingehen kann:

1. Welche Komponenten( /Software) werden benötigt, wenn man keine Taster braucht/möchte, bzw. (wie) kann man Signale an den Bus senden (welche Bauteile)? Dazu zu sagen ist, dass wir nur einen Raum als Prototyp ausstatten und möglichst keine baulichen Maßnahmen vornehmen wollen (herumliegende Kabel stellen aber kein Problem dar) - im Groben erstmal: Fenster-, Türkontakt, Bewegungsmelder, Licht- und Heizungssteuerung.

2. Reicht die USB/RS232 Schnittstelle von einem der Hersteller?

3. Ich bin schnell auf "Calimero" als Java-API gestoßen, was mir natürlich zugute kommen würde. Gibt es da Erfahrungen/Probleme/Alternativen?

Ich glaube es werden noch einige Fragen dazu kommen, wobei für mich halt erstmal interessant wäre, ob das Projekt überhaupt zu realisieren ist, bevor ich mich zu tief damit beschäftige.

Ich hoffe, dass es nicht bereits ein ähnliches Thema gibt - falls doch, so habe ich es leider nicht so einfach über die Suchfunktion gefunden nud würde darum bitten dorthin verwiesen zu werden

Für jeden Rat / Information / Erfahrung bedanke ich mich schonmal.

Beste Grüße aus Hannover!
Leo

[2ndsky]

Willkommen im Forum. Zur Anbindung an den Rechner kannst dir auch mal den eibd ansehen.

[derLeo]

Ein klein wenig hatte ich da schon gelesen, was ich da direkt ja kann wäre ja Sachen steuern, aber worum es geht (und was ich bei eibd nicht direkt gefunden habe), wäre dieser Zwischenschritt zwischen der Sensorauswertung und dem Anstoßen neuer Aktionen. Da klingt aber das dort verlinkte linKNX mit der XML Schnittstelle relativ viel versprechend.
Danke für den Verweis auf jeden Fall.

Wie sieht denn das Hardwaremäßig aus, wenn ich einen Sensor anschließen möchte oder auch einen Aktor steuern will? Also Tasterschnittstellen sind dann doch Beispielsweise falsch, oder? Also wie bekomme ich die Endpunkte generell an den Bus - reicht da so ein einfacher Busankoppler (und gibt es die auch als nicht UP?) oder muss da so eine Komponente mit mehr Logik zwischen?

[2ndsky]

Wie sieht denn das Hardwaremäßig aus, wenn ich einen Sensor anschließen möchte oder auch einen Aktor steuern will? Also Tasterschnittstellen sind dann doch Beispielsweise falsch, oder? Also wie bekomme ich die Endpunkte generell an den Bus - reicht da so ein einfacher Busankoppler (und gibt es die auch als nicht UP?) oder muss da so eine Komponente mit mehr Logik zwischen?

Jede Buskomponente kann von sich aus mit dem Bus kommunizieren. Lediglich manche Komponenten werden in Anwenderschnittstelle und Busankoppler aufgeteilt. Hast du also z.B. einen Taster der die BCU nicht direkt integriert benötigt er diese noch extra. Aktoren für den Schaltschrank haben diese i.d.R. integriert. Bei richtiger Auswahl der Komponenten lassen sich komplexe Logiken ohne zusätzliche zentrale Komponente erstellen.

Generell werde ich das Gefühl nicht los, du solltest dir erstmal ein gutes Buch schnappen und dir etwas mehr Theorie anlesen... nicht böse gemeint, nur als Tipp.

[derLeo]

Um ein Buch werde ich früher oder später nicht drum herum kommen, da hast du Recht. Es ging/geht mir jetzt erstmal in erster Linie darum, ob es überhaupt Sinn macht, bzw. möglich ist in diese Richtung weiter zu denken. Ansonsten würde das Projekt sowieso abgesagt werden (bzw. KNX/EIB) und ich bräuchte auch kein Buch^^

Bei richtiger Auswahl der Komponenten lassen sich komplexe Logiken ohne zusätzliche zentrale Komponente erstellen.

Naja eigentlich möchte ich ja den Computer als "zentrale Komponente" und für die komplexe Logik...

Jede Buskomponente kann von sich aus mit dem Bus kommunizieren.

Das klingt schonmal super, nehmen wir ein konkretes Beispiel. Ein Fenster-Kontaktsensor - so wie ich den im Katalog gesehen habe (~20€) hat der keine direkte Anbindung, bräuchte der dann also einen Busankoppler separat? Das würde die Kosten für die Hardware doch recht stark ansteigen lassen.

[fireblade]

Fensterkontakte kann man über Tasterschnittstellen anbinden, die wiederum eine Schnittstelle zum Bus haben. Sind es mehrere, eignen sich Binäreingänge, die für potentialfreie Kontakte ausgelegt sind.
Aber das Projekt hört sich für mich nicht neu an. Das hab ich sehr weitgehend schon in meinem Haus am Laufen. Meine zentrale Komponente ist der eibPC, der genau das Beschriebene macht.

[Tessi]

Wenn Du Schaltkontakte herkömmlicher Bauart auf den Bus bekommen möchtest, da brauchst Du entweder einen Baustein mit Binäreingängen oder eine Tasterschnittstelle (Unterschied: ersterer erwartet eine Spannung am Eingang, je nach Typ 12-24V= oder 230V~, letztere liefert die Abfragespannung für Schaltkontakte selbst). Diese Geräte enthalten die Busankopplung schon. Die Trennung zwischen "Anwenderschnittstelle" und Busankoppler gibt es hauptsächlich bei UP-Taster für KNX. Dabei wird der Buskoppler wie eine Steckdose oder ein Schalter in die Unterputzdose montiert und ein Modul mit Tastern aufgesteckt. Die meiste Elektronik und Software steckt im Busankoppler, mit dem dann verschiedene Tastenmodule (unterschiedliches Design, unterschiedliche Anzahl an Tasten) mit wenig oder gar keiner Elektronik über einen Stecker verbunden werden. So ein Busankoppler kann normalerweise nur mit den dafür vorgesehenen Modulen verbunden werden, nur die passen und nur dafür bekommt man vom Hersteller auch die passende Software für den Busankoppler. Wer mehr will muss richtig basteln, was aber wegen oft nicht ausreichender Dokumentation über Busankoppler und Module für einen Anfänger praktisch nicht möglich ist. Solche Basteleien sind auch nicht vorgesehen.
Für einen Fensterkontakt nimmt man vorzugsweise eine Tasterschnittstelle (so ab 40€ für zwei Eingänge).
Um den Bus überhaupt betreiben zu können braucht man eine Stromversorgung, aber nicht irgendeine sondern spezielle für KNX. So ab 150€...
Aktoren entsprechend dem, was man so machen möchte, für den Anfang einen Schaltaktor mit 8 Relais, so ab 200€...
Anschluß an den PC: Es gibt Schnittstellen mit RS232, USB oder Ethernet.
Der PC kommt mit allen zurecht, verwendet wird heute meist USB. Auch so um 200€...
Zur Konfiguration aller KNX-Geräte braucht man zwingend die Software ETS. Die Vollversion kostet fast 1000€, es gibt aber ein kleine Version (kann nur maximal 20 Geräte in einem Projekt anlegen und reicht für Deine Versuche) die unter 200€ kostet (glaube ich). Um die USB-Schnittstelle nicht nur mit ETS benutzen zu können ist ein Treiber erforderlich, frei erhältlich ist bislang nur eibd aber der läuft nur unter linux während Die ETS nur unter Windows läuft. Der eibd stellt auch nur die Kommunikation her, es wird dann noch Software gebraucht, die die Daten vom Bus auswertet und ggf. auch wieder Daten sendet. Da gibt es inzwischen mehrere freie Entwicklungen, allerdings habe ich noch mit keiner gearbeitet.

Bleibt allerdings die Frage, wenn es zentral eigentlich mehr um den PC geht und KNX nur als ausführende "dumme" Peripherie gedacht ist, ob da andere Systeme (z.B. die von Conrad) nicht schlicht besser geeignet und vor allem billiger sind...
Denn KNX ist eigentlich dafür entwickelt worden, im Betrieb ohne zentrale Intelligenz (PC) auszukommen. Als dumme IO-Bausteine für einen PC ist es ziemlich teuer und auch aufwendig in Betrieb zu nehmen (Ohne Konfiguration per ETS läuft erst einmal gar nichts).

[derLeo]

Vielen Dank für die vielen und schnellen Antworten schonmal.
Dein EibPC werde ich mir mal genauer an sehen, wobei ich befürchte, dass das schon zu "fertig" auf Seite der Software ist.
Falls das aus dem bisherigen Thread noch nicht deutlich geworden ist, so ist mein Hauptanliegen in dem Projekt die Sensorsignale selber nochmal nachzuverarbeiten, mehr zu interpretieren und um weiteres Wissen anzureichern. Dazu brauche ich halt die input und output Schnittstellen...

Bleibt allerdings die Frage, wenn es zentral eigentlich mehr um den PC geht und KNX nur als ausführende "dumme" Peripherie gedacht ist, ob da andere Systeme (z.B. die von Conrad) nicht schlicht besser geeignet und vor allem billiger sind...
Denn KNX ist eigentlich dafür entwickelt worden, im Betrieb ohne zentrale Intelligenz (PC) auszukommen. Als dumme IO-Bausteine für einen PC ist es ziemlich teuer und auch aufwendig in Betrieb zu nehmen (Ohne Konfiguration per ETS läuft erst einmal gar nichts).

Unwissenheit. Die Idee neben Simulationen und theoretischen Sensoren einfach mal etwas praktisches umzusetzen kam halt innerhalb des Projektes und KNX war jetzt der erste, und bislang einzige, vielversprechende Anlaufpunkt.
Was Conrad für andere Systeme anbietet weiss ich nicht - vor allem was da an technischen Know-How benötigt wird ist dabei die größte Frage. Das Vorhaben soll letztendlich möglichst wenig technischen Aufwand mit sich bringen, da die eigentliche Projektarbeit und der inhaltliche Fortschritt mithilfe der Sensordaten auf dem Rechner geschehen soll.

[Chris M.]

Hallo Leo, willkommen im Forum!

Das Thema ist eigentlich gar nicht KNX/EIB sondern semantische Sensornetzwerke, wobei wir Haus-, bzw. Raumautomation als Anwendungsgebiet gewählt haben und da ist KNX mit seinem offenen Standard bislang für uns die beste Option.

KNX ist da sicher eine gute Wahl, es ist per internationaler Norm (AFAIK das einzige System damit!) im Detail festgelegt und die Zahl der Hersteller ist mit >200 riesengroß.

Das Thema "Kosten" ist ja bereits oben schon angesprochen worden.
Hier kann es durchaus Sinn machen die Welten zu koppeln, z.B. mit 1wire als dummer und sehr preiswerter Mess-(Sub-)Bus.

Meine Frage ist nun die, ob und wie es möglich ist Aktoren und Sensoren Computergesteuert zu betreiben.
Also Beispielsweise soll das Licht nicht über einen Taster gesteuert werden oder direkt durch einen Bewegungssensor beeinflusst werden, sondern die Sensoren sollen über den Computer ausgelesen werden und dann sollen die entsprechenden Aktoren wiederum über den Computer angesteuert werden.

Was Du suchst ist im Grunde nur die Einbindung einer Logik-Engine.

Hier gibt es beim KNX viele Möglichkeiten. Von kommerziellen wie GIRA HomeServer oder den EibPC bis hin zu Open Source Lösungen wie LinKNX oder Misterhouse.
Spannend finde ich in diesem Kontext das WireGate - ein kommerziell (und damit mit sehr gutem Support!) vertriebenes kleines Linux-Kistchen (Root-Zugang unterstützt!!! Debian basiert und x86, d.h. viel Software läuft Out-of-the-Box) das lediglich 5 Watt Strom-Verbrauch unter Volllast hat.
Neben dem vorgefertigten LinKNX und MisterHouse bietet es s.g. "Plugins" an, was kleine Perl-Skripte sind die somit eine Logik-Engine bilden.

1. Welche Komponenten( /Software) werden benötigt, wenn man keine Taster braucht/möchte, bzw. (wie) kann man Signale an den Bus senden (welche Bauteile)? Dazu zu sagen ist, dass wir nur einen Raum als Prototyp ausstatten und möglichst keine baulichen Maßnahmen vornehmen wollen (herumliegende Kabel stellen aber kein Problem dar) - im Groben erstmal: Fenster-, Türkontakt, Bewegungsmelder, Licht- und Heizungssteuerung.

Open- oder Closed Source?

Bei Open Source ist das entscheidende Stück Software der eibd.
Der greift per KNX-Interface auf den Bus zu und stellt auf dem Rechner eine einfache API bereit um mit dem Bus standard konform zu kommunizieren. Language Bindings gibt's in allen möglichen Sprachen.

Um mit dem Bus zu kommunizieren gibt es nun alle möglichen Interfaces, je nach Vorliebe mit RS232, USB oder Netzwerk.
(Bei Verwendung des eibd ist die TP-UART über die RS232 nicht nur die günstigste, sondern auch die Schnittstelle mit den meisten Möglichkeiten...)

Für den Raum brauchst Du dann noch einfach die passenden KNX Komponenten der üblichen Hersteller. Einfach mal die Katalöge von GIRA & Co bestellen und bisschen blättern.

2. Reicht die USB/RS232 Schnittstelle von einem der Hersteller?

Jain.
Grundsätzlich: Ja.
Praktisch: Bei USB sollte man sich vorher erkundigen. Und bei RS232 besser auch.

Klare Empfehlung: Wenn Du den eibd verwendest (was auch meine Empfehlung ist), den TP-UART nehmen. (Ohne eibd ist der nicht nutzbar!)
Wenn Du den nicht willst, dann "IP Routing" oder "IP Tunnel" nehmen.

3. Ich bin schnell auf "Calimero" als Java-API gestoßen, was mir natürlich zugute kommen würde. Gibt es da Erfahrungen/Probleme/Alternativen?

Ich dachte, Du wolltest Software machen?!?

Im ernst: Aus verschiedenen Gründen ist für mich Java in diesem Kontext keine Option, daher habe ich mir Calimero nie genauer angesehen.
Und hier im Forum lese ich auch nur sehr selten darüber, was mich vermuten lässt, dass die Nutzung "unterdurchschnittlich" ist.

Der eibd dagegen wird inzwischen auf vielen Systemen produktiv verwendet. D.h. der ist stabil und gut debugt.

wobei für mich halt erstmal interessant wäre, ob das Projekt überhaupt zu realisieren ist, bevor ich mich zu tief damit beschäftige.

Logik-Engines gibt es schon einige, daher werden kaum Probleme technischer Art auftauchen. Mangelndes Wissen dagegen kann entscheiden. (Es ist halt im Detail nun mal komplex; so komplex aber nun auch wieder nicht)

Ich hoffe, dass es nicht bereits ein ähnliches Thema gibt - falls doch, so habe ich es leider nicht so einfach über die Suchfunktion gefunden nud würde darum bitten dorthin verwiesen zu werden

Wie geschrieben: Logik-Engines gibt es einige.

Was der "neue" Ansatz wohl dann wäre, wäre wie die Sensoren ausgewertet werden.
Wobei auch hier immer mal wieder "innovatives" wie Neuronale Netze kommt (und geht, da es sich nicht durchgesetzt hat...)

Übrigens: besonders intelligent ist es, nicht alles auf eine zentrale Intelligenz zu setzten, sonder es optimal mit dem dezentralen Konzept von KNX zu verheiraten. (Zentrale Intelligenz ist halt ein Single Point of Failure).
Beispiel:
Die Wetterstation meldet Sonneneinstrahlung und Windstärke.
Eine zentrale Logik kann damit die optimale Lamellenstellung berechnen und bei starkem Wind (ggf. gemittelt und mit der Wettervorhersage vernküpft) auch die Lamellen hochfahren um diese vor Beschädigung zu schützen.
Liegt diese Schwelle nun unter der Sicherheitsschwelle der KNX-Wetterstation, dann ist die Jalousie auch bei Ausfall der zentralen Logik geschützt.

[derLeo]

Hallo Chris,

Was Du suchst ist im Grunde nur die Einbindung einer Logik-Engine.

Hier gibt es beim KNX viele Möglichkeiten. Von kommerziellen wie GIRA HomeServer oder den EibPC bis hin zu Open Source Lösungen wie LinKNX oder Misterhouse.

Jein, der kleine Unterschied ist glaube ich, dass ich die Logik-Engine selber schreiben möchte.

Open- oder Closed Source?

Prinzipiell egal, solange ich Schnittstellen habe über die ich alles steuern kann. Wie gesagt, die Logik möchte ich selber implementieren und daher müsste dieser Part entweder Open Source sein oder über Schnittstellen komplett steuerbar sein.

Was der "neue" Ansatz wohl dann wäre, wäre wie die Sensoren ausgewertet werden.

So in etwa würde ich es auch beschreiben, die Art wie die Sensoren ausgewertet und vor allem die "Verarbeitung", sprich Verknüpfung/Erweiterung der Sensorinformationen soll das "neue" werden.
Deswegen ist auch die Java-Schnittstelle interessant, da ich darüber (hoffentlich) alle Informationen bekomme und Signale wieder einspielen kann, aber in meiner Software die Verarbeitung vornehmen könnte.

Das Thema "Kosten" ist ja bereits oben schon angesprochen worden.
Hier kann es durchaus Sinn machen die Welten zu koppeln, z.B. mit 1wire als dummer und sehr preiswerter Mess-(Sub-)Bus.

Von 1wire habe ich noch nicht gelesen, aber sieht auf den ersten Blick auch sehr gut aus, gerade weil die Komponenten so "dumm" sind - was ich da aber gerade nicht auf den ersten Blick finden konnte ist, ob neben den Sensoren so etwas wie Aktoren existieren (Beispiel Heizungssteuerung). Wie sähe denn so keine "Kopplung der Welten" aus, von der du gesprochen hast?

[2ndsky]

Von 1wire habe ich noch nicht gelesen, aber sieht auf den ersten Blick auch sehr gut aus, gerade weil die Komponenten so "dumm" sind - was ich da aber gerade nicht auf den ersten Blick finden konnte ist, ob neben den Sensoren so etwas wie Aktoren existieren (Beispiel Heizungssteuerung). Wie sähe denn so keine "Kopplung der Welten" aus, von der du gesprochen hast?

Die Aktoren wären KNX seitig und könnten über das Wiregate als KNX Gateway angesprochen werden. Da Aktoren ja eh nur schalten, ist das kein Problem für euer Projekt. Aber KNX Sensorik ist meist teuer, weil die eben irgendwie an Bus muss. Daher würde ich für die Sensorik vielleicht sogar komplett auf den 1wire Bus setzen. Es gibt auch IOs an die Taster gehängt werden könnten. Dann wäre die Sensorik günstig und dumm.

[Tessi]

Und Du musst Dich nicht nur mit einem, sondern gleich mit zwei Systemen herumschlagen, wo Deine Arbeit doch hauptsächlich die Programmierung der Logik-Engine auf dem PC sein soll...

Und der 1wire ist manchmal eine richtige Mimose und zickt herum, sobald man etwas unsauber verkabelt (KNX-TP ist da weitaus robuster).

Falls Du Dich für KNX entscheiden solltest, dann bleibe auch dabei. Bei der voraussichtlich recht überschaubaren Anzahl an Sensoren ist KNX nicht so viel teurer wie Dich die Probleme (inklusive Zeitverlust) kommen werden, wenn Du anfängst, auch noch mehrere Systeme zu verknüpfen.
Und Du musst die "Intelligenz" der KNX-Geräte ja nicht nutzen, man kann sie auch "dumm" konfigurieren, also wirklich einfache Datensender und Kommandoempfänger daraus machen. Es ist halt nur so, das man sie auf jeden Fall konfigurieren muß, denn ab Werk machen sie erst einmal gar nichts. Da sind sie wie ein neuer PC, der zwar schon ein OS drauf hat, aber sonst noch keinerlei Programme.

Um Dir allerdings Geräte empfehlen zu können müssten wir schon viel genauer wissen, was alles wie an den Bus angeschlossen werden soll.
Ggf. reicht Dir ein Aktor mit 8-16 Relais und ein IO-Konzentrator mit 32 binären Eingängen (die auch als Ausgänge konfiguriert werden könnten).
Mit Netzteil, Software (ETS Lite) und Schnittstelle liegen wir dann knapp über 1000€ (ohne PC, den setze ich mal als vorhanden voraus).
Linux, eibd und diverse darauf aufsetzende Frameworks gibt es gratis.

[lobo]

Hallo Leo,

aus reiner Neugierde - handelt es sich hierbei um eine Übung im Sinne einer Seminararbeit, oder hat es da wirklich was mit einem Forschungvorhaben zu tun?

Denn das was Du bisher beschreibst, ist irgendwie Standard ... und am Besten zu vergleichen mit einer simplen SPS, welche die Signale von verschiedenen Sensoren nach unterschiedlichen Logiken auf passende Aktoren umsetzt ... ggf. noch mit einer übergeordneten GLT.

Also - irgendwie habe ich den Kern Deine Aufgabe noch nicht verstanden - und vielleicht würde das bei der Beantwortung Deiner Fragen auch helfen (wenn es noch mehr Leuten so geht wir mir).

Viele Grüße,

Stefan

[tht]

Hi Leo,

da ich gerade bei meinem Kunden bin erstmal nur die Kurzfassung:

KNX ist ein eigenständig funktionierendes System aus Sensoren und Aktoren. Grob vereinfacht senden die Aktoren aufgrund von Ereignissen Informationen in Form von Telegrammen auf den Bus, die von erstmal an alle gehen (=> vgl. Hub). Jene Aktoren, denen man im Rahmen der Parametrisierung - landläufig auch "Programmierung des Busses" - erklärt hat darauf zu hören, agieren dann auf die entsprechenden Programme.

Die eigentliche Software wird schon von den Herstellen in die jeweiligen Komponenten gebaut. Damit kann das alles dezentral nahezu unabhängig voneinander arbeiten.

Wenn du also eine Software bauen willst, wird die im Grunde nichts anders machen, als die Telegramme zu lesen auszuwerten und dann eigene Telegramme auf den Bus schicken. Die Basis-Logik steckt an sich schon in den Komponenten drin, anspruchsvollere Lösungen sowie eine Visualisierung sind die Ansatzpunkte, die "sinnvoll" wären. Die Aktoren zu "dummen" Schaltern zu degradieren würde sicherlich auch klappen, ist aber im Grunde nicht sinnvoll/eine Vergewaltigung des Konzeptes.

Ich würde dir raten, dich noch etwas einzulesen (z.B. auch auf PeterPan's Seite) und das Konzept zu überdenken. Eine Logikengine/Visu für anspruchsvollere Logiken macht Sinn, den Bus durch Zentralisierung neu erfinden zu wollen und zu ner Quasi-SPS umzubauen eher weniger.

@Chris:
Java war zumindest bis vor eine Weile Lehrsprache Nr. 1 an den dt. Hochschulen und wird wohl auch noch immer sein, daraus folgt dann eine Java-Affinität der Studenten/Abgänger.

[StefanW]

Und der 1wire ist manchmal eine richtige Mimose und zickt herum, sobald man etwas unsauber verkabelt (KNX-TP ist da weitaus robuster).

Richtig, man darf bei 1-Wire weniger wild verkabeln. Dafür kostet aber der Temperatursensor inkl. Businterface auch nur 2.- EUR, ist so groß wie ein Transistor (TO-92) und mit einer Genauigkeit von +/- 0,5 °C und einer Auflösung von 11 Bit auch noch genauer als die meisten KNX basierten Schätzeisen zum 100-fach höheren Preis.

Ohne diese preiswerten 1-Wire Sensoren würde man auch in 2012 noch keiner Hütte 50 Temperatursensoren verpassen.

Dafür muss man bei der Verkabelung zwei Regeln mehr beachten als bei KNX.

Nicht falsch verstehen: Klar ist ein KNX-Device technisch besser durch seine lokale Intelligenz und durch das bessere Übertragungsprotokoll / Businterface. Nur sollte man bei Vergleichen auch immer den - hier erheblich höheren - Preis betrachten.

glg

Stefan