[WorkingProcess] "SmartHome" mit Tasmota-KNX

  • Hi,

    ich würde hier gerne einfach in lockerer Folge über meine SmartHome-Erfahrungen schreiben, fast schon bloggen. Eigentlich fast ohne konkreten Grund, abgesehen vom Mitteilungsbedürfnis. Einfach bisschen informieren, Brainstorming und KnowHow ansammeln, insbesondere da ich versuche einen etwas anderen Ansatz anzugehen, als den, den man so klassischerweise findet - Tasmota-KNX ist da eher dürftig vertreten. Andere Beiträge sind selbstverständlich erwünscht: Hilfe, Fragen, Brainstorming,...

    Mein Hintergedanke ist, dass ich ein SmartHome-System haben möchte, dass möglichst dezentral und (damit) ausfallsicher ist. Klassischer Ansatz ist ja, dass div. Geräte mit einem zentralen Gerät kommunizieren. Bei DIY-Zeug ist das zentrale Gerät dann meistens ein Recher (RasPi) mit einem MQTT-Server und einer darauf laufenden Visualsierung + ggf. Logik. Ich kenne es von meinem OMV-Server: Rechner fallen gerne mal aus. SSD/SD defekt, Netzteil defekt, HDD defekt, was auch immer. Und bis das ganze dann wieder läuft dauert dann meistens etwas. Und wenn in dieser Zeit diverses Zeug nicht läuft:

    Also ist mein Ansatz möglichst ohne Server auszukommen und die Aktor/Sensoren so zu verbauen, dass diese möglichst sogar ohne Netzwerk ihre Grundfunktion erfüllen können.
    Im Moment sind als Unterputzgeräte Shellys angedacht. Die werden dann zwischen den Lichtschalter (im Falle einer Serien-/Kreuzschaltung nach dem letzten) und dem Licht reingehängt. Der Shelly soll dann von sich aus mit seiner eingebauten Logik das Licht ganz normal schalten. Am liebsten wären mir da sogar Shellys mit zwei Wechslerrelais. Dann könnte man die komplett "transparent" in eine Serien-/Kreuzschaltung integrieren und man das Licht sogar bei defektem Shelly ganz normal bedienen. Manche Sonderfunktionen oder etwa "wäre ganz gut, wenn man auch noch hier einen Lichtschalter für das Licht da hätte" klappt halt dann nicht mehr.

    Das auf allen Geräten möglichst Tasmota zum Einsatz kommt, ist ja fast schon selbstverständlich. Ich habe mich aufgrund des dezentralen Einsatzes für Tasmota-KNX entschieden. Einerseits habe ich schon Erfahrung in Sachen KNX (ich betreue seit ca. 2 Jahren u.A. ein ca. 20 Jahre altes KNX-Bussystem mit ca. 430 Geräten und 1900 Gruppenadressen - bin dazu allerdings wie die Jungfrau zum Kinde gekommen und hatte bis dato aus div. Gründen noch nichtmal einen KNX-Kurs).
    Auf der anderen Seite bietet mir KNX genau das was ich haben will: Dezentralität.
    Dazu will ich kurz den KNX-Bus anreißen:
    Jedes Gerät eine eine physikalische Adresse mit drei Segmenten, diese ist vergleichbar mit einer IP-Adresse in einem Netzwerk. Die Segmente werden mit Punkten getrennt, z.B.: "3.4.5". Die Segmente werden natürlich logisch aufgeteilt, so reserviert man z.B. die 0-er Segmente (0.x.y & x.0.y) für zentrale Geräte (0.0.0 ist reserviert). Dann zählt man etwa mit dem ersten Segment die Stockwerke durch (1.x.y => KG; 2.x.y => EG; 3.x.y => OG; 4.x.y => außen) und mit dem Zweiten die Räume (x.1.y => Flur; 2.2.y => Küche;...). Im dritten Segment kann man dann noch versuchen Geräte aufzuteilen. Z.B. könnten alle 10er Geräte Shelly1 sein, alle 20er Shelly2,...
    Mit der physikalischen Adresse definiere ich also das Gerät und den Standort.

    Für Funktionen, also etwa Schaltbefehle gibt es die Gruppenadressen. Auch wieder drei Segmente, Trennzeichen hier aber ein Slash: "/". Auch hier sollte man sich ein System überlegen. Üblicherweise sind 0-er wieder für Zentralfunktionen, z.b. wird 0/0/0 gerne für "zentral Ein/Aus" verwendet. Üblich ist bei der Benennung der Gruppenadresse das System "Gewerk/Geschoss/Funktion", oder auch "Geschoss/Gewerk/Funktion". Gewerk wäre z.B. Licht, Rolläden, Heizung,.. (etwas mehr Text: https://www.knx-hausblog.de/gruppenadresse…en-wie-war-das/)

    So, wie funktioniert jetzt der KNX? Ganz einfach: Wenn ich einen Eingang eines KNX-Sensors z.B. mit einem Schalter auf "Ein" schalte, schickt der ein Telegramm auf den Bus, Inhalt: die für den Eingang programmierte Gruppenadresse und der Schaltzustand - in diesem Fall wahrscheinlich "Ein". Möglich wären auch noch "Aus" und "Um"(-schalten). (Und natürlich gibt es auch noch größere Telegramme, mit denen man mehr schicken kann, wie etwa Temperaturen, Zeiten,...) Alle anderen Teilnehmer horchen auf den Bus und werten ankommende Telegramme aus. Bekommt jetzt ein Aktor ein Telegramm, bei dem für einen Ausgang die entsprechende Gruppenadresse programmiert ist reagiert dieser entsprechend.
    Zusammengefasst: Sensor schreit auf den Bus: "3/4/52 auf Ein", alle horchen zu und die, die es interessiert reagieren.

    Tasmota-KNX nimmt hier KNX-IP her. Das macht vom Prinzip her das gleiche, nur halt nicht auf der KNX-Busleitung sondern im Netzwerk IP-Basiert. Genauer: der Sensor schreit hier per Multicast auf der (hierfür reservierten) IP-Adresse 224.0.23.12.

    Nun zu meinen ersten Erfahrungen:
    Angedacht war eigentlich als erstes Projekt ein GoSund-Plug für meinen Laserdrucker im Keller. Per Smartphone einschalten und nach einer gewissen Zeit ohne Benutzung (Stromverbrauch) wieder ausschalten. Also ein Zweierpack GoSund-Plugs geordert und mit Tuya-Convert bequem geflasht, das ging echt super.
    Dann kam Weihnachten. Und mit Weihnachten die Weihnachtsbeleuchtung. Und die erste Weihnachtsbeleuchtung war an einer Stelle, die man schlecht erreicht und dann immer schalten.. ne.. ich habe ja noch einen Plug übrig. Und dem dann gleich eine Zeitschaltung programmiert: 30min vor Sonnenuntergang ein, um 23:00 aus. Hat super geklappt.
    Aber hin und wieder will man das Ding doch manuell schalten, und jetzt muss ich mich nicht nur zum Schalter hinquälen, sondern sogar zur Steckdose um den Plug zu schalten! Also hier mal gefragt, ob es vernünftige Schalter gibt. Da hat mir aber nix zugesagt und irgendwann ist mir der zweite Plug eingefallen. Der passt doch super in die bequem zu erreichende Steckdose (Griffhöhe) in der wir sowieso immer die andere Weihnachtsbeleuchtung stecken!
    Also gemacht. Und hier kam dann einer der großen Vorteile von Tasmota-KNX zum tragen:
    Ich habe beiden Geräten ihre individuelle physikalische Adresse zugewiesen, die Gruppenadresse eingetragen (Screenshots liefere ich nach) und - es läuft. Also auf jeden Fall schonmal gut für kleine Installationen oder "mal eben schnell".

    Dann sollte der Weihnachtsbaum dazukommen. Plugs hatte ich keine mehr, aber Shellys. Also Shelly versucht zu flashen, klappt nicht. Ursache war dann, dass der USB-Adapter bei 3,3V wohl zu wenig Strom ausspuckt. Mein gutes Netzteil rangehängt und lief. Da werde ich wohl mal was basteln müssen, was mit weniger fliegender Verdrahtung auskommt.
    Einstellungen setzen ging dann auch gut mit 3,3V. aber das Relais schaltet nicht? Evtl. brauchts dazu mehr Saft. Also umgejumpert und 12 rangeklemmt - Relais schaltet! Super, kann ich morgen einbauen.
    Am nächsten Tag eingebaut, Sicherung rein, Sicherung raus.. halt - Sicherung raus?... ähm, ja:

    da war doch noch was,...

    Zurück auf Anfang, Relais testen brauche ich dieses mal nicht, und unbedingt nochmal auf den Jumper achten, gut.
    Und, was soll ich sagen? Funktioniert!
    Aber: nicht so zuverlässig wie gewünscht. In gerader Linie zu dem Shelly und den Signalgebenden Plug liegt der Weihnachtsbaum, etwas Mauer und die Steckdose auf geradener Linie. Das W-Lan-Signal vom Shelly liegt bei ca. 32%, ich glaube nicht dass die FritzBox die Multicastpakete wiederholt,... das dürfte der Knackpunkt sein.
    Ich werde hier bei Gelegenheit die Steckdose nochmal aufschrauben, gucken wo die Antenne hängt und ggf. den Sehlly umdrehen.
    Für die Kommunikation mit der Visualisierung (wahrscheinlich OpenHab2) wollte ich auch noch einen MQTT-Server aufsetzen (bzw. ist schon). Dann kommt der halt als BackUp-Ebene für solche schwierigeren Fälle auch noch unten drunter. Mal gucken.

    Was bis dato noch getan wurde:
    * Raspi2 mit Openhab2 & Tasmoadmin in Docker-Containern aufgesetzt (Tasmoadmin wirkt ganz praktisch).

    Weitere Gedankengänge/ToDo:
    * Das organisieren der KNX-Adressen über Excel-Listen ist ziemlich kompliziert und unübersichtlich. Ich habe ja Zugriff auf die ETS5, und würde das gerne da drinnen mal probieren. Ich habe auch schon probiert, ob ich mit der ETS auf den "Bus" hören kann. Problem: die ETS erwartet unbedingt einen KNX-Router im Netzwerk, auch wenn sie dann letzten Endes trotzdem Multicast arbeitet (und den Router dafür gar nicht braucht). Da werde ich wohl mit knxd einen Software-Router aufsetzen.
    * Unbedingt mit Openhab2 auseinandersetzen (kennt wer gute Tutorials? Das Openhab2 Buch vom Rheinwerkverlag ist leider sogar gebraucht echt teuer und meine Bibliotheken haben das nicht,...)
    * Den Drucker schalten!
    * Programmieradapter für die Shellys löten: ich habe LM78xx kompatible Schaltregler die die 5V aus dem USB auf 3,3V regeln können. Und dann eine Stift-/Buchsenleiste wo man nur noch 1:1 verbinden muss. Ich muss dazu aber nachprüfen, von welcher Sicht aus RX/TX auf den Shelly-PinOuts angegeben ist.

    Schauen wir mal, was sich noch so alles tut.

    Zitat von root2

    Merke: Das "S" in "IoT" steht für Sicherheit!

  • Oh, OH3? Na dann doch noch etwas warten.
    Ich bin allerdings kein Freund von YT-Videos, ich lese lieber. Bei YT-Videos bin ich irgendwie immer beschäftigt, die Stelle zu finden, die wirklich interessant ist.

    Zitat von root2

    Merke: Das "S" in "IoT" steht für Sicherheit!

  • Ich kenn mich mit KNX genau null aus, bin aber immer davon ausgegangen, dass das ein par millionen Kilometer Kabel im Haus voraussetzt und sauteuer ist. Dem scheint nicht so zu sein, wenn das ganze auch über IP funktioniert.

    Eine Frage aber zur Denzentralität und zu dieser Aussage:

    Klassischer Ansatz ist ja, dass div. Geräte mit einem zentralen Gerät kommunizieren. Bei DIY-Zeug ist das zentrale Gerät dann meistens ein Recher (RasPi) mit einem MQTT-Server und einer darauf laufenden Visualsierung + ggf. Logik. Ich kenne es von meinem OMV-Server: Rechner fallen gerne mal aus. SSD/SD defekt, Netzteil defekt, HDD defekt, was auch immer. Und bis das ganze dann wieder läuft dauert dann meistens etwas.


    Ich gehe davon aus, dass man iregendeinen KNX Router oder ähnliches braucht, der den einzelnen Aktoren ihre KNX adresse zuweist. Außerdem brauchst du ja wohl auch einen Router, da das ganze ja anscheinend über IP funktioniert. Sowohl der "KNX Router" auslauch der IP Router können ebeso ausfallen, wie ein Smarthomesystem auf einem PRI. Der Vorteil erschließt sich mir daher nicht so ganz.

  • Moin, ich hab früher auch knx installiert und betreue heute noch (privat) meine ehemaligen Projekte(3)

    Bezügluch Topologie musst du dir mal Gedaken um kosten/nutzen machen, stichwort Bereichs/Linien-Koppler.
    (Bereich/Linie/Gerät) immerhin lassen sich bis zu 256 Teilnehmer je Linie hinzufügen, in privaten Häusern bin ich selten über 2 Linien gekommen, sicherlich ist die Telegrammflut innerhalb der Linien (bei mehreren) gechillter, wo auch die schwachstelle (des langsamen) Buses liegt.
    Mit weniger zyklischen Telegrammen (aufs nötigste) aber auch bewerkstellig bar.

    Beispiel, du musst den Temperatur Sensoren nicht sagen sie sollen zyklisch alle 5min ihren Wert senden, es reicht auch aus bei ner Hysterese von 1Grad zu schreiben.


    Ich werf mal noch die knx powernet Technik in den Raum, mit UP Aktoren/Sensoren über die vorhandene 230v Leitung auch ne "feine" Sache.

    https://download.gira.de/de_DE/index.html?id=1068

    https://www.busch-jaeger.de/archiv?tx_nlbj…b893f47ee59eec3


    Generell seh ich das wie du, wenn dann dezentral.

    2 Mal editiert, zuletzt von DeBaschdi (11. Januar 2021 um 15:24)

  • @Momo90 ,
    Ein knx ist ein Bus System, es braucht eine Spannungsversorgung und Teilnehmer wie Aktoren + Sensoren.
    Die Teilnehmer werden über einen sogenannten Busankoppler über den PC mit z.b ETS programmiert, jedes Gerät für sich, fällt ein Gerät aus, funktionieren alle anderen Trotzdem (Ausnahme Spannungsversorgung).

    Natürlich können auch ganze Linien ausfallen bei größeren Projekten mit mehreren Linkenkopplern (notwendig bei >256 Teilnehmern.)

  • Ich gehe davon aus, dass man iregendeinen KNX Router oder ähnliches braucht, der den einzelnen Aktoren ihre KNX adresse zuweist. Außerdem brauchst du ja wohl auch einen Router, da das ganze ja anscheinend über IP funktioniert. Sowohl der "KNX Router" auslauch der IP Router können ebeso ausfallen, wie ein Smarthomesystem auf einem PRI. Der Vorteil erschließt sich mir daher nicht so ganz.

    Zum KNX selbst hats @DaBaschdi schon gesagt
    Was ich brauche und benutze ist ein W-LAN-AccessPoint, aka Router. Die Tasmotas müssten aber auch ohne diesen auskommen (Ad-hoc W-LAN). Dieser Router ist bei mir eine FritzBox 7390 (oder so) von der ich noch zwei weitere im Betrieb habe (pro Stockwerk eine als AP). Ich hätte also ggf. zwei Reservegeräte daheim die ich ohne großartige Probleme einsetzen könnte.
    Und so eine FritzBox läuft erfahrungsgemäß deutlich stabiler als ein RasPi.

    Bezügluch Topologie musst du dir mal Gedaken um kosten/nutzen machen, stichwort Bereichs/Linien-Koppler.
    (Bereich/Linie/Gerät) immerhin lassen sich bis zu 256 Teilnehmer je Linie hinzufügen, in privaten Häusern bin ich selten über 2 Linien gekommen, sicherlich ist die Telegrammflut innerhalb der Linien (bei mehreren) gechillter, wo auch die schwachstelle (des langsamen) Buses liegt.
    Mit weniger zyklischen Telegrammen (aufs nötigste) aber auch bewerkstellig bar.

    Ich glaube nicht, dass ich da BK/LKs brauchen werde. Die 256-Teilnehmergrenze ist m.W. elektrisch bedingt (mehr kann der Bus nicht treiben), das Problem habe ich nicht. Die Telegrammzahl dürfte sich auch in Grenzen halten, auf jeden Fall in Grenzen die ein 54Mbit WLAN nicht auslasten.
    Bei dem System das ich in der Arbeit habe, läuft die Bereichslinie noch komplett über TP und nicht - wie man es heute macht - über IP. In der hängt aber ein IP-Router der u.A. ein Visualisierungsmodul anbindet. Dieses schickt zudem noch jedes Telegramm auf an einen SQL-Server (Fehleranalyse). Bis dato hätte sich die IT noch nicht über eine übermässige Netzwerklast beschwert.
    Wenn ich sowas brauchen würde, würde ich das aber wohl mit knxd in Software realisieren. Da gäbe es dann auch Module die KNX-TP anbinden könnten.


    Ich werf mal noch die knx powernet Technik in den Raum, mit UP Aktoren/Sensoren über die vorhandene 230v Leitung auch ne "feine" Sache.

    http://download.gira.de/de_DE/index.html?id=1068

    http://busch-jaeger.de/archiv?tx_nlbj…e6b2574290b893f47ee59eec3

    Wird m.W. eher Stiefmütterlich behandelt. Zudem bin ich dann wieder bei KNX typischen Preisen und brauche wirklich zwingend die ETS.
    _________________

    Hier nochmal zwei Screenshots wie die KNX-Config in Tasmota aussieht:

    Die Dinger werden sowieso nochmal umprogrammiert. Ich bin mit den Hardwaredressen noch nicht so zufrieden.

    Zitat von root2

    Merke: Das "S" in "IoT" steht für Sicherheit!

  • Bezüglich Topologie nochmal, ohne Bereichskoppler kannst du von 1.0.0 keine Telegramme nach 2.0.0 schicken, und ohne Linienkoppler keine Telegramme von 1.0.0 nach 1.1.0, jede Linie kann 256 Teilnehmer enthalten, 15 Bereiche und 15 Linien sind möglich, das macht 58.363 Teilnehmer :)
    ((256x15)+49)x15+48

    Allerdings (noch nie getestet) wenn du innerhalb der gleichen physikalischen "Hauptlinie" deine Addressen mischst, also 1
    1.2 und z.b 2.0.2 kann ich nicht mit Sicherheit sagen ob die Geräte untereinander ohne Koppler kommunizieren können *asche auf mein Haupt" vermute aber eher nicht.

    https://www.voltimum.de/artikel/knx-gr…2-knx-bussystem

    Zitat

    Der KNX TP-Bus kann maximal 50 Telegramme pro Sekunde übertragen. Bei KNX PL kommt man auf einen Durchsatz von nur sechs Telegrammen pro Sekunde, bedingt durch die niedrigere Baudrate, den längeren Telegrammaufbau und das andere Zugriffsverfahren. Speziell hier sollte also aufhäufig wiederholte Telegramme (zyklische Wiederholungen) verzichten werden bzw. die Wiederholzeit sehr hoch angesetzt werden.


    Knx IP k3nne ich (noch) nicht, hört (liest) sich aber interessant an.

    Einmal editiert, zuletzt von DeBaschdi (11. Januar 2021 um 20:37)

  • Bezüglich Topologie nochmal, ohne Bereichskoppler kannst du von 1.0.0 keine Telegramme nach 2.0.0 schicken, und ohne Linienkoppler keine Telegramme von 1.0.0 nach 1.1.0, jede Linie kann 256 Teilnehmer enthalten, 15 Bereiche und 15 Linien sind möglich, das macht 58.363 Teilnehmer
    ((256x15)+49)x15+48

    Ich habe es noch nicht mit KNX-TP getestet, aber was ich weiß, macht der LK/BK die physikalische Ankopplung & Filterung. Sprich: Eigentlich sollte man ohne LK/BK von 1.0.0 nach 2.0.0 Telegramme schicken können, solange die auf der gleichen Busleitung sitzen, warum den auch nicht? Die Geräte bekommen ja vom LK/BK nix mit, und wenn die Geräte auf der gleichen Leitung sitzen, kann der LK/BK da auch nix rausfiltern.
    In der Praxis ist es aber so, dass die Geräte 1.0.x und 2.0.x auf unterschiedlichen Busleitungen sitzen, die mit einem LK/BK angebunden sind. Und der lässt natürlich nur nach Filtertabelle durch. Das habe ich aber in meiner Installation nicht, da die Geräte durch das (W)-LAN ja alle auf der gleichen "Bus-Leitung" sitzen.

    Knx IP k3nne ich (noch) nicht, hört (liest) sich aber interessant an.

    Backline machst du heutzutage immer in KNX IP. Du hast heutzutage m.W. eigentlich nur noch (IP-)Linienkoppler. Alles was auf deiner Hauptlinie/Bereichslinie passiert läuft über LAN. Je nach Aufbau der Installation würde ich sogar davon ausgehen, dass die KNX-Busleitung die (Unter-)Verteilungen gar nicht mehr verlässt.

    Zitat von root2

    Merke: Das "S" in "IoT" steht für Sicherheit!

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!