Liebe Mikrocontroller-Freunde, ich möchte gerne meine Software und Erfahrungen zum Thema Heimautomatisierung für Interessierte zur Verfügung stellen. Einzelheiten zum Projekt finden sich in dem Artikel: Hausbus auf I2C- und ATtiny-Basis: Home2L Brownies Ich hoffe, das Projekt ist für den einen oder anderen hier interessant und freue mich auf Rückmeldungen aller Art! Gundolf Kiefer
:
Verschoben durch Moderator
yet another Homeautomation Totgeburt. sorry, aber wenn man schon damit anfängt aktuell 8 Bitter als Vorteil zu sehen und klobige DIL Gehäuse als kriegsentscheidend darzustellen, nein Danke, 20. Jahrhundert. Und auch Technikverliebt vom Protokoll aus und vom µC aus zu anzufangen ist keine gute Idee. Andere haben Konzepte, Werkzeuge, sind Controllerunabhängig und unterstützen hetereogene Systeme, soweit ist man heute. PS: und es gehört nach https://www.mikrocontroller.net/forum/hausbus weil es kein fertiges Projekt ist.
Hallo Gundolf, grundsätzlich finde ich sowas durchaus interessant, daher habe ich eben mal einen (allerdings nur sehr flüchtigen) Blick darauf geworfen - speziell auf das "home2l-book", wo diese Brownies ja nur ein Unterthema sind. Hier mal meine ehrliche Meinung bzw. ein wenig konstruktive Kritik zu dem ganzen home2l-Projekt, weil Du Dir ja etwas Feedback wünschst: Allgemein: 1. Erst einmal zolle ich Dir grossen Respekt dafür, wie unglaublich viel Arbeit Du da offenbar bereits hineingesteckt hast. Alleine das "home2l-book" als Teil der Dokumentation hat ja bereits über 150 Seiten - Hut ab! Schon aus Respekt für diese ganze Mühe habe ich Dein GitHub-Projekt eben mal ge"star"t. 2. Dein home2l-Projekt besteht ja aus viel mehr als den "Brownies" genannten Sensoren/Aktoren und dem zugehörigen Hausbus. Du hast da ja offenbar noch ein komplettes zugehöriges Heimautomatisierungs-System entwickelt, das dann auf einem zentralen Server läuft - mit Automatisierungs-Regeln, einem Info-Display, passenden Kommandozeilentools, Libraries usw. usw. Hut ab, da muss eine Menge Arbeit hineingeflossen sein. Allerdings: Zumindest für mich sind sind diese Teile ehrlich gesagt eher uninteressant... :-( Auf den ersten Blick erscheint mir das eigentlich nur eine Alternative zu anderen Smart Home-Systemen wie "Home Assistant", "ioBroker", "fhem" etc. zu sein - und wobei ich persönlich dann doch eher zu einem anderen System greifen würde. Denn den einzigen Vorteil, den ich auf Anhieb an Deinem System erkennen kann, ist, dass es wohl deutlich leichtgewichtiger ist als andere Lösungen. Das ist für mich persönlich allerdings eher irrelevant; der zentrale Server meines eigenen Smart Home-Systems stemmt auch die anderen Lösungen problemlos. Dafür sehe ich bei den anderen Lösungen Vorteile, die für mich mehr wiegen: - Webbasierte GUI/Dashboard, über die jedes beliebige Smartphone/Tablet zur Steuerung oder als Info-Display genutzt werden kann - weiter verbreitet und ausgereift, dadurch auch viel mehr Erweiterungen verfügbar, grössere Community usw. Ich würde ehrlich gesagt vermuten, dass dieses Smart Home System in Deinem Heim seinen Dienst wunderbar erfüllen wird, aber letztlich nur wenige Andere Interesse an diesen Komponenten haben werden. :-( Zum Hausbus/den "Brownies": 3. Die Argumente, die Du für die Verwendung der Attinys anbringst, finde ich durchaus plausibel. Für die allermeisten Sensoren/Aktoren dürfte ein 8-Bit-Attiny mit internem Takt, bisschen Flash und RAM in der Tat mehr als ausreichend sein. Aber andererseits sind die 8-Bit-AVRs halt wirklich schon etwas angestaubt und gelten schon heute nicht mehr ganz als Stand der Technik. Dadurch wird das Ganze mit der Zeit unweigerlich ein wenig veraltet wirken. Ich weiss nicht, ob es wirklich so ist - aber beim ersten Überfliegen bekommt man den Eindruck, dass als Sensor-/Aktor-Nodes per se nur ein paar wenige Attinys in Frage kommen. Ich würde das dahingehend verändern, dass Du deutlich herausstellst, dass der Hausbus und das Protokoll nicht auf bestimmte µcs zugeschnitten ist, die Sensor-/Aktor-Nodes letztlich auf jedem µc basieren können - aber dass Du Dich zumindest für den Anfang halt auf 8-Bit-AVR-basierte Sensoren/Aktoren konzentrierst, weil die für diese Aufgabe völlig ausreichend sind und gewisse Vorteile bieten. 4. Was mir bislang am meisten fehlt, um den Einsatz Deines Hausbusses zumindest in Erwägung zu ziehen: Eine MQTT-Bridge, über die der Hausbus dann leicht in fast jedes Smart Home-System integriert werden kann. Ich habe gesehen, dass Du so etwas durchaus bereits vorgesehen hast - ich will einfach nur sagen, dass das für mich persönlich die wichtigste noch fehlende Komponente wäre.
:
Bearbeitet durch User
Joachim S. schrieb: > Denn den einzigen Vorteil, den ich auf Anhieb an > Deinem System erkennen kann, ist, dass es wohl deutlich > leichtgewichtiger ist als andere Lösungen. Ein schwergewichtiger Vorteil. Der entscheidende. > Für die allermeisten Sensoren/Aktoren dürfte ein > 8-Bit-Attiny mit internem Takt, bisschen Flash und RAM in der Tat mehr > als ausreichend sein. So ist das. Und sagen wir ruhig für alle. > Aber andererseits sind die 8-Bit-AVRs halt wirklich schon etwas > angestaubt und gelten schon heute nicht mehr ganz als Stand der Technik. > Dadurch wird das Ganze mit der Zeit unweigerlich ein wenig veraltet > wirken. Dir scheint nicht ganz klar zu sein, daß 8Bitter weiter hochaktuell bleiben und speziell die große, nach wie vor produzierte AVR Familie laufend mit neuen Typen erweitert wird. Vor allem aber scheint Dir nicht klar, daß der Zweck die Mittel bestimmt und nicht irgendeine Mode. Die 8Bitter sind insbesondere dazu geeignet, ein Smarthome System einfach und überschaubar zu halten. Solcherlei Anwendung stemmen die mit links. Johannes S. schrieb: > yet another Homeautomation Totgeburt. Ich nehme mal an das System verrichtet ganz lebendig seinen Dienst. "Yet another" wird seine Berechtigung behalten. Vom Bastelspaß und der befriedigenden Möglichkeit, ein System komplett aufs letzte Bit in der eigenen Hand zu haben mal abgesehen hat Standardisierung aller Couleur immer auch den Pferdefuß, Hackern aller Länder das Leben zu erleichtern. > Andere haben Konzepte, Werkzeuge, sind > Controllerunabhängig und unterstützen hetereogene Systeme, soweit ist > man heute. Damit ist man heute nicht unbedingt besser dran.
Beitrag #6258500 wurde von einem Moderator gelöscht.
Hallo Rudolf, dein Projekt sieht wirklich gut aus – jedenfalls besser, wie das, was ich gebastelt habe. Ich nutze auch ATtinys als Slave für die Auswertung vom Gas - und Stromzähler sowie für Dimmer. Ich überlege mir, meinen Vierfachdimmer mit Zeitschaltuhr hier zu veröffentlichen. Wenn ich mir jedoch die Kommentare anschaue, bin ich mir nicht mehr sicher, ob dies das richtige Forum ist. Carsten
Vielen Dank für die zahlreichen und (am Ende dann doch...) konstruktiven Kommentare! Nur den ersten Antwort-Post (vom 10.05.2020 um 00:35) halte ich für unangemessen, der sollte nach Möglichkeit von einem Moderator gelöscht werden. Nochmal zur Klarstellung, um eventuelle Missverständnisse zu vermeiden: Selbstverständlich handelt es sich hier um kein unfertiges Projekt - die gesamte Software ist so wie im Artikel beschrieben lauffähig und im Einsatz. Und selbstverständlich gibt es auch im Home2L-Projekt "Konzepte" und "Werkzeuge". Bitte nicht in eine "Yet another ..."-Denkweise verfallen und dann Projekte wie ioBroker oder FHEM zum Vergleich nennen. Die haben zum Teil andere Zielsetzungen und sind mit dem hier vorgestellten Projekt (den Home2L-Brownies-Teil meine ich) nicht vergleichbar. Zum Inhaltlichen: Joachim S. schrieb: > Ich weiss nicht, ob es wirklich so ist - aber beim ersten Überfliegen > bekommt man den Eindruck, dass als Sensor-/Aktor-Nodes per se nur ein > paar wenige Attinys in Frage kommen. Die unterstützten Typen sind im Quellcode in der Datei brownies/avr/config.h definiert. Hier könnten neue hinzugefügt werden. Siehe auch: https://gkiefer.github.io/home2l/home2l-api_c/group__brownies__pins.html Joachim S. schrieb: > dass der Hausbus und das > Protokoll nicht auf bestimmte µcs zugeschnitten ist, die > Sensor-/Aktor-Nodes letztlich auf jedem µc basieren können Das ist so. Im Home2L Book ist in Kapitel 7.3 separat das Bus-Protokoll beschrieben, und alles das gilt völlig unabhängig von der ATtiny-Firmware. Man kann also problemlos beliebige µC oder auch ganz andere Rechner in den Bus einbinden. Joachim S. schrieb: > 4. Was mir bislang am meisten fehlt, um den Einsatz Deines Hausbusses > zumindest in Erwägung zu ziehen: Eine MQTT-Bridge, über die der Hausbus > dann leicht in fast jedes Smart Home-System integriert werden kann. Das verstehe ich vollkommen, MQTT steht definitiv auf der ToDo-Liste. Was mir aktuell fehlt, ist eine gute Testmöglichkeit, da ich selber (noch) kein Gerät per MQTT-Anbindung in Betrieb habe. --> Gibt es vielleicht jemanden hier, der einen MQTT-Broker im Einsatz hat und Zeit und Interesse hat, beim Testen mitzuwirken? Moby schrieb im Beitrag #6258500: > Mit dem Ersatz des großen Linux-Servers durch eine simplere, > stromsparendere Kontrollinstanz (gern wieder 8bittig) ließe sich das > System weiter vereinfachen. Für die Einbindung ins WLAN kann man viele > käufliche Module nutzen. Ich bin nicht ganz sicher, ob ich das richtig verstanden habe. Wenn es um den Server/Host geht, könnte vielleicht die Home2L-Resources-Bibliothek als Backend helfen. Ein 8-Bitter als Server halte ich aber offen gesagt für etwas knapp dimensioniert. Aber ein Linux-Server sollte auch mit 1W Leistungsaufnahme möglich sein. Reicht das? Zur Info: Bei mir läuft ein Linux-Kleinrechner mit 2 Cortex-A9-Kernen, max. 960 MHz, Leistungsaufnahme idle ca. 2W. Der Home2L-Server-Prozess, der unter anderem 25 Brownies bedient, erzeugt ca. 2-3% CPU-Last. Da wäre also Luft für einen noch sparsameren (Linux-)Rechner. Carsten schrieb: > Ich nutze auch ATtinys als Slave für die Auswertung vom Gas - und > Stromzähler sowie für Dimmer. > Ich überlege mir, meinen Vierfachdimmer mit Zeitschaltuhr hier zu > veröffentlichen. Das Projekt würde mich interessieren. Liegt der Code auch in einem öffentlichen Repo (github o.ä.), sodass man da mal reinschauen kann?
:
Bearbeitet durch User
Gundolf K. schrieb: > > Nur den ersten Antwort-Post (vom 10.05.2020 um 00:35) halte ich für > unangemessen, der sollte nach Möglichkeit von einem Moderator gelöscht > werden. Ist halt (s)eine Meinung... Hast Du vom Aufbau denn nicht ein mal ein paar Bilder, die Du zeigen kannst? Ich habe gesehen, im github gibt es paar Egale? Files? Aber mal den einen oder anderen Schaltplan mal mit in den Artikel hier packen, das hätte den Vorteil, das man sich das Ganze auch ohne fremde Tools anschauen kann. Die beschriebenen Firmware-Updatemechanismen finde ich interessant. Ist i2c nicht eigentlich ein Bus, der das Gehäuse eines Gerätes nicht verlässt? Kann man einzelne Busse so voneinader entkoppeln, das der Bus, der in die Garage geht galvanisch vom rest des Hauses getrennt ist? Ich weiß im Smarthome nimmt man auch gern 1-wire für Temperatursensoren, mach ich bei mir auch so, aber eigentlich finde ich alles was unter 12 oder 24V ist immer recht unschön im Feld, vorallem dann, wenn beide Potentiale sich irgendwo wieder treffen, was ich bei mir aber tunlichst vermeide.
So so, und gegen welche Nutzungsregeln verstößt mein Beitrag das er gelöscht werden soll? Nur weil dir mein Kommentar nicht passt? Wo kommst du denn her das du sowas forderst?
Sven L. schrieb: > Ist i2c nicht eigentlich ein Bus, der das Gehäuse eines Gerätes nicht > verlässt? Das sehe ich auch so. Ich persönlich halte I2C für eine eher ungeeignete Wahl, da gibt es doch bessere Optionen. Ich habe mir mal die Schaltpläne angesehen, was ich mich frage ist wie du die ganzen Sachen versorgst? Da kommen überall einfach 5V an, keine Sicherungen, keine Schutzschaltungen nichts. Oder habe ich was übersehen? Persönlich habe ich das Gefühl, dass das Ganze nicht sonderlich robust gegenüber Störungen und Überspannungen ist. Ist natürlich auch immer etwas persönliches Gusto wie viele Schutzmaßnahmen man da ergreift. Bei mir ist recht viel Schutz verbaut, bisher gab es aber auch keine Ausfälle irgendeiner Art. Wäre mal interessant zu wissen, ob bei dir langfristig Probleme auftreten. Ansonsten ein nettes Projekt, viele sagen ja solche Eigenbauten sind Mist, weil damit keiner mehr was anfangen kann, wenn man mal das Haus verkauft. Aber ich persönlich baue den Krempel lieber selbst, da kann ich es bauen wie ich es brauche und es ist deutlich billiger als die meisten Fertigen Lösungen.
Johannes S. schrieb: > So so, ... Er meint bestimmt die Art & Weise deines unterirdischen Beitrags oder die unsachliche Argumentation ("Totgeburt etc.") auf untersten Niveau. Dein Beitrag wären in anderen Foren undenkbar. Geht nur auf dem µNet, dem Forum der Wutbürger.
Beitrag #6260959 wurde von einem Moderator gelöscht.
Beitrag #6260975 wurde von einem Moderator gelöscht.
Gundolf K. schrieb: > Bitte nicht in eine "Yet another ..."-Denkweise verfallen und dann > Projekte wie ioBroker oder FHEM zum Vergleich nennen. Die haben zum Teil > andere Zielsetzungen und sind mit dem hier vorgestellten Projekt (den > Home2L-Brownies-Teil meine ich) nicht vergleichbar. Da hast Du natürlich völlig Recht. Du hast diesen Thread hier ja auch explizit zum Hausbus bzw. den "Brownies" verfasst, und den Rest des Home2L-Projektes ursprünglich ja nicht einmal erwähnt. Weil ich allerdings beim Überfliegen des Projekts und speziell des "Home2L-Books" schnell gemerkt habe, dass es bei Deinem Home2L-Projekt eigentlich um viel mehr geht, und die Brownies bzw. Hausbus im Grunde nur ein kleiner Teil davon ist, wollte ich Dir abseits des eigentlichen Themas Hausbus/Brownies halt auch noch kurz meine rein persönliche Meinung zum Rest des Home2L-Projektes kundtun, um den es hier eigentlich gar nicht geht. Und diese Meinung ist vereinfacht gesagt halt: Der Hausbus/die Brownies finde ich interessant, da könnte ich mir grundsätzlich vorstellen, das auch bei mir einzusetzen. Für den Rest des Home2L-Projekts gilt das eher nicht, da würde ich persönlich im Endeffekt wohl doch eher eine Lösung wie Node Red, ioBroker, Home Assistent o.Ä. bevorzugen. Daher wäre für mich persönlich wichtig, dass es eine (von Dir ja auch eh angedachte) MQTT-Bridge gibt, durch die Dein Hausbus ganz leicht in beliebige Smart Home-Systeme integriert werden kann. > Joachim S. schrieb: >> dass der Hausbus und das >> Protokoll nicht auf bestimmte µcs zugeschnitten ist, die >> Sensor-/Aktor-Nodes letztlich auf jedem µc basieren können > > Das ist so. Im Home2L Book ist in Kapitel 7.3 separat das Bus-Protokoll > beschrieben, und alles das gilt völlig unabhängig von der > ATtiny-Firmware. Man kann also problemlos beliebige µC oder auch ganz > andere Rechner in den Bus einbinden. Das hatte ich bereits vermutet. Schliesslich gibt es ja wenige Gründe, warum das Protokoll des Hausbusses auf einen ganz bestimmten µc zugeschnitten sein sollte. Um das auch nochmal klarzustellen, weil zumindest Moby mein Posting da leicht missverstanden zu haben scheint: Dass Du Dich für die Knoten Deines Hausbusses für AVR 8-Bitter entschieden hast, finde ich völlig naheliegend, die von Dir angebrachten Argumente völlig plausibel. Wenn ich mir aktuell einen einfachen "Frickel-Hausbus" basteln würde, würde ich aus den gleichen Gründen ebenfalls auf AVR 8-Bitter setzen. Der entsprechende Abschnitt meines früheren Postings war daher nicht im Sinne von "AVR 8-Bitter sind doch scheisse und veraltet, nimm stattdessen gefälligst den modernen und leistungsfähigen 32-Bit-µc XY!" gedacht, sondern vielmehr als Anregung, in der Dokumentation/Projektbeschreibung einfach noch kurz klarzustellen, dass die Knoten des Hausbusses grundsätzlich natürlich auf fast jedem µc basieren können. > Joachim S. schrieb: >> 4. Was mir bislang am meisten fehlt, um den Einsatz Deines Hausbusses >> zumindest in Erwägung zu ziehen: Eine MQTT-Bridge, über die der Hausbus >> dann leicht in fast jedes Smart Home-System integriert werden kann. > > Das verstehe ich vollkommen, MQTT steht definitiv auf der ToDo-Liste. > Was mir aktuell fehlt, ist eine gute Testmöglichkeit, da ich selber > (noch) kein Gerät per MQTT-Anbindung in Betrieb habe. > > --> Gibt es vielleicht jemanden hier, der einen MQTT-Broker im Einsatz > hat und Zeit und Interesse hat, beim Testen mitzuwirken? Da würde ich eventuell helfen. > Moby schrieb im Beitrag #6258500: >> Mit dem Ersatz des großen Linux-Servers durch eine simplere, >> stromsparendere Kontrollinstanz (gern wieder 8bittig) ließe sich das >> System weiter vereinfachen. Für die Einbindung ins WLAN kann man viele >> käufliche Module nutzen. > > Ich bin nicht ganz sicher, ob ich das richtig verstanden habe. Wenn es > um den Server/Host geht, könnte vielleicht die > Home2L-Resources-Bibliothek als Backend helfen. Ein 8-Bitter als Server > halte ich aber offen gesagt für etwas knapp dimensioniert. Einen 8-Bitter als Server fände ich auch nicht sinnvoll. An dieser Stelle dann ein (fast beliebig schwach brünstiges) Linux-System einzusetzen, wie Du es getan hast, erscheint mir absolut sinnvoll. In der Praxis würden die meisten Leute an der Stelle vermutlich eh einen Raspberry Pi o.Ä. einsetzen, der dann auch noch weitere Aufgaben übernimmt. Wie läuft das bei Dir eigentlich konkret mit der Verkabelung? Wenn ich das Home2L-Book richtig interpretiere, verwendest Du als Kabel KNX-Kabel. Damit kenne ich mich nicht aus. Wieviel kostet da ungefähr der Meter? Und wie schliesst Du die Knoten an den Bus an? Hast Du da extra Dosen verbaut? Usw., erzähl doch mal bisschen mehr dazu. p.s.: Nochmal kurz zur Klarstellung: Mein erstes Posting hier im Thread sollte eben kein Runtermach-Posting a la "Was für ein nutzloser Scheissdreck!" sein, sondern eben konstruktive aber auch ehrliche Kritik. Ich habe für dieses erste Posting bestimmt 30 Minuten Lebenszeit aufgewendet - das tue ich nicht, um mir Frust von der Seele zu schreiben und das Projekt herunterzuputzen, sondern weil ich vielmehr halt grundsätzlich Interesse an dem Projekt habe, und aus Eigeninteresse hoffe, dass es sich in eine gewisse Richtung entwickelt.
Also ich beschäfftige mich auch schon viele Jahre mit Hausautomatisierung und habe im eigenen vieles selber umgebaut und mit KNX als Bus ausgerüstet. Ich baue auch viel mit µC selber und habe da mit 6502, 6809, 8051 angefangen als sowas mal aktuell war. Für ein anspruchsvolles Projekt wie Hausautomatisierung muss man sehr viel Zeit investieren wenn man selber plant und baut. Das alles selber zu machen ist ein Wahnsinn, da braucht man Mitstreiter und die muss man überzeugen. Es geht los mit alten, nicht wahren Vorurteilen gegen 32 Bitter: - die sollen nicht ausgereift sein? What? CM0(+) sind auch einfach, man muss sich eben etwas damit beschäfftigen - DIP Gehäuse sind von Vorteil? In REG und UP Dosen ist wenig Platz, 230 V braucht Isolierabstände. Wer da Angst vor SMD hat, der hat schlechte Karten. - sehr wenig Beschaltung nötig - zeige mir einen CM0 der nicht mit eingebautem RC Oszi daher kommt. Dazu kann man eine PLL optional nutzen und den Takt in weiten Bereichen per Software einstellen - Stromverbrauch: da schneiden die CM mit modernen Produktionsprozessen mit kleinen Strukturen mittlerweile besser ab. Vergleiche Leistungsaufname pro MHz, die CM0 gehen runter bis 10 µW/MHz. - die Rechenleistung von 8 Bittern reicht: bei anderen Bussen sind die Aktoren/Sensoren sehr intelligent geworden und können umfangreiche Dinge selber erledigen und müssen nur konfiguriert werden. Die Brownis haben nur einen Master und Sensoren/Aktoren können einfach gehalten werden. Aber letzeres ist gerade der größte Nachteil, ein Master - Slave. Master aus - Haus tot. Wenn man die Vorzüge eines autarken Bussen kennengelernt hat möchte man ein Single Master System nicht haben. Bei jeder Änderung oder Wartung am Master kann man kein Licht mehr einschalten, das wäre für mich ein no go. Solche Grundfunktionen müssen immer gehen, Komfort wie Sonnenstandabhängige Rollandensteuerung kann ein System im höheren Level machen, aber auch hier denken viele anders und wollen das im Bus und deren Komponenten haben. In den Steuersystemen wie FHEM, ioBroker, OpenHAB um nur einige zu nennen stecken mittlerweile hunderte Mannjahre Entwicklung drin, man muss die 'nur' installieren und konfigurieren, alleine den ganzen Gedanken der vielen Leute zu folgen kostet viel Zeit. Damit ist aber man auf einem ganz anderen Niveau als ein bisschen selber zu programmieren. Man wird es niemals schaffen alles mit einem Bus homogen zu steuern, wenn man damit anfängt kommen schnell verschiedene Geräte dazu die integriert werden möchten, erst dann wird ein Home smart, ein Bus alleine macht das nicht. Und sowas wie ioBroker kann nahezu alles ansprechen was per Funk oder Kabel zu erreichen ist. Der Preisvergleich im Brownie Handbuch ist auch unfair, da werden wohl Bauteilkosten (2-10 €) gegen fertige, CE und EMV getestete, zertifizierte Geräte gegenübergestellt. Ein KNX 12 Kanal Relaismodul mit Strommessung kostet keine 300 €, alleine die Zeit sowas zu entwerfen und zu bauen kostet eine Kleinigkeit. Das so billig zu vergleichen ist einfach Kleingeistig. Die Spannungsversorgung zum Bus soll auch 5V sein? 5V rein und nach 100 m wieder 5V raus? Womit werden Relais, BWM, Bedienpanels versorgt? Es gibt schon diverse Selbstbaubusse, da sind aber viele schon wieder in der Versenkung verschwunden. Entweder die sind Erfolgreich, dann werden die kommerziell weil irgendwann der Supportaufwand für die Entwickler zu groß wird, oder die sterben mangels Interesse Unterstützung der Community. Die meisten wollen doch möglichst billige, fertige Geräte (siehe Shelly & Co.), oder relativ günstige Systeme wie Homematic + Anbindung an den Rest der Welt. Also ich bleibe beim ersten Satz meines ersten Kommentares, da könnt ihr mit Minusklicks um euch werfen wie ihr wollt.
Beitrag #6261152 wurde von einem Moderator gelöscht.
Persönlich finde ich das Projekt von Gundolf eine interessante Sache. Wenn Jemand sich ein eigenes System bauen möchte, hat er hier sehr viel Dokumentation um das unterschiedlich oder gleich aufzubauen. Für viele Aufgaben in der Automatisierung würden eigentlich sogar 4bit-Prozessoren ausreichen. Daher finde ich die Kritik, es wären nur 8bit nicht passend. Wem die Platinen zu wenig gehärtet sind, kann Schutzelemente ergänzen. Wenn er das dem TO zukommen läßt, wird er es sicherlich gerne aufnehmen. Durchaus eine feine Sache ist es einen bereits vorhandenen Bus der Prozessoren zu benutzen. Die Einschränkung ist natürlich auf die eigene Wohnung oder Haus (das auch nicht zu groß sein darf) des Systems. Aber auch hier ließen sich Schnittstellenbausteine über I2B erreichen um über andere Protokolle das System zu erweitern.
Vielen Dank für die ausführlichen Posts! Ich beantworte mal einen Teil davon, die übrigen aus Zeitgründen dann morgen. Sven L. schrieb: > Ich habe gesehen, im github gibt es paar Egale? Files? Die Beispiel-Schaltungen sind mit KiCAD gezeichnet. Sven L. schrieb: > Die beschriebenen Firmware-Updatemechanismen finde ich interessant. Vielleicht lohnt es sich, mal das Tutorial im [https://gkiefer.github.io/home2l/home2l-book.pdf ''Home2L Book''], Kapitel 2, anzuschauen. Man braucht nur einen Linux-PC oder eine Linux-VM und Docker, dann sollte es funktionieren. In Kapitel 2.6 ist eine minimale Beispiel-Schaltung (mit Bild) beschrieben, mit der man alle Vorgänge inklusive des Updates auch testen kann. Sven L. schrieb: > Ist i2c nicht eigentlich ein Bus, der das Gehäuse eines Gerätes nicht > verlässt? Die weit verbreiteten DDC-Protokolle zur Monitor-Erkennung bei VGA-/DVI-/HDMI-Monitorkabeln basieren zum Beispiel auf i2c. Jeder, der einen PC mit Monitor besitzt, besitzt also normalerweise auch einen i2c-Bus, der das Gehäuse eines Gerätes verlässt. Guest schrieb: > Das sehe ich auch so. Ich persönlich halte I2C für eine eher ungeeignete > Wahl, da gibt es doch bessere Optionen. Ich habe mir mal die Schaltpläne > angesehen, was ich mich frage ist wie du die ganzen Sachen versorgst? Da > kommen überall einfach 5V an, keine Sicherungen, keine Schutzschaltungen > nichts. Oder habe ich was übersehen? Zu den ganzen elektrischen und physikalischen Fragen gibt es hier auch einen Artikel: [[I2C_als_Hausbus|I2C als Hausbus]] Die Schaltungen auf GitHub sind Beispiele. Je nach Gegebenheit und persönlichem Sicherheitsbedarf müssen natürlich noch Schutzdioden etc. zugefügt werden. Die Stromversorgung geschieht bei mir zentral über ein Netzteil, das sich beim Linux-Host befindet. Dort befindet sich auch die Absicherung. Guest schrieb: > Persönlich habe ich das Gefühl, dass das Ganze nicht sonderlich robust > gegenüber Störungen und Überspannungen ist. Ist natürlich auch immer > etwas persönliches Gusto wie viele Schutzmaßnahmen man da ergreift. Bei > mir ist recht viel Schutz verbaut, bisher gab es aber auch keine > Ausfälle irgendeiner Art. Wäre mal interessant zu wissen, ob bei dir > langfristig Probleme auftreten. Störungen werden durch die Fehlererkennung im Protokoll und Software korrigiert. Fehlerraten hatte ich im Artikel genannt - nach meiner Erfahrung absolut vernachlässigbar. Abstürze oder spontane Resets der Mikrocontroller, die auf Störungen in der Spannungsversorgung hindeuten könnten, habe ich in den vergangenen zwei Monaten auch nicht erlebt (sie wären nicht unbemerkt geblieben). Um ehrlich zu sein, hätte ich vorher nicht gedacht, dass das so gut funktionieren würde. Langzeit-Erfahrungen über viele Jahre stehen natürlich noch aus. Sven L. schrieb: > Kann man einzelne Busse so voneinader entkoppeln, das der Bus, > der in die Garage geht galvanisch vom rest des Hauses getrennt ist? Galvanische Trennung ist bei i2c nicht ganz einfach, da Open-Drain-Bus. Man könnte mal nach Forenbeiträgen zu dem Thema suchen. Was bei i2c funktioniert, sollte auch beim Brownie-Bus funktionieren. Ich persönlich würde für die Garage einen eigenen Linux-Host verwenden. Alternativ könnte man auch zum Beispiel zwei ATtiny85 mit einer bidirektionalen Verbindung 1:1 galvanisch getrennt miteinander koppeln, sodass einer eine i2c-Slave-Schnittstelle hat, der andere eine Master-Schnittstelle und beide gemeinsam als Hub arbeiten. Das müsste aber erst noch in der Software implementiert werden. Guest schrieb: > Bei > mir ist recht viel Schutz verbaut, bisher gab es aber auch keine > Ausfälle irgendeiner Art. Wie ist denn Dein Bus aufgebaut, wenn ich mal neugierig fragen darf? Das scheint auch eine Eigenentwicklung zu sein?
Gundolf K. schrieb: > Wie ist denn Dein Bus aufgebaut, wenn ich mal neugierig fragen darf? Das > scheint auch eine Eigenentwicklung zu sein? Nennen wir es einen Hybrid. Das Ganze befindet sich aktuell noch im Aufbau bzw. in der Entwicklung. Aktuell sind nur Rollladen damit gesteuert, langfristig soll aber auch Beleuchtung etc. dazu kommen. Ich benutze einerseits EIB/KNX, da ich die Option haben wollte die Standard Tastsensoren zu nutzen (das hat hauptsächlich ästhetische Gründe) und natürlich, weil man über den BUS Endgeräte direkt versorgen kann. Das ist bei mir an der ein oder anderen Stelle für Sensoren und Kleinkram sinnvoll. Zwischen den Unterverteilungen läuft die Kommunikation über einen isolierten CAN. Aktuell arbeite ich an verschiedenen Modulen für Rollladen (Verbesserungen), Dimmen, Schalten und Messen, die werden vermutlich auch über CAN angesprochen. Ich nutze CAN persönlich sehr gerne, das ist aber wohl wie so vieles Geschmackssache. Eine Anbindung ans Netzwerk ist auch noch geplant das wird aber noch ein bisschen dauern.
Johannes S. schrieb: > Also ich bleibe beim ersten Satz meines ersten Kommentares, da könnt ihr > mit Minusklicks um euch werfen wie ihr wollt. Ich war eine der mindestens 7 Personen, die Dein besagtes erstes Kommentar mit einem Minus bewertet haben. Und zwar primär wegen des Tonfalls. Dieses Posting von Dir, auf das ich gerade antworte, habe ich andererseits mit einem Plus bewertet. Weil es zwar trotzdem sehr kritisch, aber ausführlich begründet und vor Allem in einem ganz anderen, sachlichen Tonfall verfasst ist. Das war in meinen Augen tatsächlich ein guter und eben lesenswerter Beitrag. An Allem, was Du da geschrieben hast, ist schon was dran, ich sehe da nix, wo ich Dir klar widersprechen würde. Du misst diesen Hausbus hier an professionellen Bussen wie KNX und benennst zutreffend diverse Schwachstellen/Nachteile. Das hier ist natürlich kein professioneller Hausbus wie KNX, wo an fast alles gedacht wurde. Sondern ein Bus ganz am anderen Ende des Spektrums, der meinem Eindruck nach ganz gezielt auf ein Minimum an Bauteilen und Kosten für die Knoten getrimmt wurde. Ich denke, eine wichtige Frage ist tatsächlich: Für wen oder was macht so eine auf absoluten Minimalismus getrimmte Hausbus-Lösung (unter Inkaufnahme diverser Nachteile) überhaupt Sinn? Schwierig zu beantworten, die Zielgruppe dürfte jedenfalls ziemlich klein sein...
Mit den negativ Bewertungen kann ich leben, das ist wie geschrieben meine Meinung. Beim ersten Post war es zwar spät, ich lese da aber trotzdem keinen bösen Tonfall raus, ich wollt nur keinen Roman schreiben und habe meinen ersten Gedanken erstmal kurz zusammengefasst... Für unsachliche oder wirklich unterirdische Kommentare sind hier andere bekannt. Die Vergleiche zu KNX kommen nicht von mir, die sind im Handbuch zu finden. Das hatte ich zuerst nicht gelesen, das Projekt ist damit doch sehr gut dokumentiert. Nur den Äpfel-Birnen Vergleich auf S.91 halte ich für nicht richtig. KNX ist ein 2-Draht Bus mit Daten und Versorgung in einem Paar, der höhere Strombedarf kommt da auch aus dem Transceiverbaustein. Damit können Relais und Displays vom Bus versorgt werden, das weiß Gundolf weil er KNX ja sogar selber nutzt. Wenn der Brownie Bus mit 5V versorgt wird dürfen die Nodes gar nicht viel Strom ziehen, sonst bekommt man ja Probleme mit Spannungsabfällen. Bei Versorgung mit höherer Spannung sind Spannungsregler nötig die wieder mehr Aufwand und Verluste bedeuten, aber wie soll man sonst mit Komponenten wie Relais und Displays arbeiten? Nur für Rolläden und Sensoren halte ich den zusätzlichen Bus für zu aufwändig, wir reden hier ja von kabelgebunden und das kann man nur richtig beim Neubau oder umfangreichen Umbau einplanen. Wenn man schon KNX hat, was spart man dann gegenüber einem zusätzlichen Relaismodul um noch Rolläden anzusteuern? Und da bitte mal reale Kosten incl. Leistungselektronik ansetzen und nicht nur die Buskomponente. Das der Bus in der Testinstallation gut funktioniert ist natürlich ein Erfolg den man auch erstmal hinbekommen muss. Ich beobachte das Projekt weiter, bleibe aber skeptisch. Was nicht heissen soll das ich dem Autor keinen Erfolg wünsche oder gönne.
Joachim S. schrieb: > p.s.: > Nochmal kurz zur Klarstellung: Mein erstes Posting hier im Thread sollte > eben kein Runtermach-Posting a la "Was für ein nutzloser Scheissdreck!" > sein, sondern eben konstruktive aber auch ehrliche Kritik. Ich habe für > dieses erste Posting bestimmt 30 Minuten Lebenszeit aufgewendet - das > tue ich nicht, um mir Frust von der Seele zu schreiben und das Projekt > herunterzuputzen, Kein Problem. Das kann ich schon einordnen und habe es auch so verstanden. Joachim S. schrieb: > sondern weil ich vielmehr halt grundsätzlich Interesse > an dem Projekt habe, und aus Eigeninteresse hoffe, dass es sich in eine > gewisse Richtung entwickelt. Das freut mich. Ich würde mich auch freuen, wenn es vielleicht in Zukunft Mitstreiter gibt, die das Projekt auf die eine oder andere Art unterstützen. Joachim S. schrieb: >> --> Gibt es vielleicht jemanden hier, der einen MQTT-Broker im Einsatz >> hat und Zeit und Interesse hat, beim Testen mitzuwirken? > > Da würde ich eventuell helfen. Gerne. Ich würde dann etwas detailliertere Informationen brauchen zur eingesetzten Hardware, welcher Broker verwendet wird und was damit gemacht / möglich gemacht werden soll. Bitte gerne persönlich an mich schicken über meinen GitHub-Account. Joachim S. schrieb: > Und diese Meinung ist vereinfacht gesagt halt: Der Hausbus/die Brownies > finde ich interessant, da könnte ich mir grundsätzlich vorstellen, das > auch bei mir einzusetzen. Für den Rest des Home2L-Projekts gilt das eher > nicht, da würde ich persönlich im Endeffekt wohl doch eher eine Lösung > wie Node Red, ioBroker, Home Assistent o.Ä. bevorzugen. Eine völlig legitime Meinung. Node-RED halte ich übrigens auch für ein sehr interessantes Tool, um grafisch Regel einzugeben. --- Eine Bemerkung dennoch am Rande zum restlichen Home2L-Projekt und dem Vergleich mit anderen Frameworks, die immer wieder mal erwähnt werden: Es gibt ja auch viele Texteditoren IDEs Web-Browser / Mail-Clients auf der Welt. Jeder hat da seine persönliche Favoriten, und die sind bei jedem andere, aber jeder ist wiederum der Meinung, dass "seine" Tools die besten sind. Das ist völlig normal, und deshalb ist es meiner Meinung nach sehr wichtig, dass es eine Vielfalt gibt. Das Home2L-Projekt hatte ich seinerzeit (ca. 2014) übrigens deshalb gestartet, weil die verfügbaren Frameworks bestimmte Anforderungen meinerseits nicht erfüllten. Eine davon ist das Thema Verfügbarkeit. Viele andere Systeme setzen einen zentralen Server voraus, der aber damit einen "Single Point of Failure" darstellt. Mit dem Home2L-System kann man ein Netz so aufbauen, dass es keinen Rechner oder µC gibt, der, falls er ausfällt, das komplette System lahmlegen kann. --- Joachim S. schrieb: > Ich denke, eine wichtige Frage ist tatsächlich: Für wen oder was macht > so eine auf absoluten Minimalismus getrimmte Hausbus-Lösung (unter > Inkaufnahme diverser Nachteile) überhaupt Sinn? Schwierig zu > beantworten, die Zielgruppe dürfte jedenfalls ziemlich klein sein... Die Zielgruppe sind Personen, die mit Elektronik umgehen können und gerne etwas selber machen. Das ist bestimmt nicht die Mehrheit der Bevölkerung, aber es soll ja solche Leute geben. Und auch Minderheiten brauchen eine Lobby. ;-) Die Brownies sollen nicht die komplette Hausvernetzung ersetzen. Ein sinnvolles Gesamtsystem ist aus meiner Sicht eine zweistufige Lösung mit zum Beispiel per Ethernet/WLAN vernetzten (Linux-)Knoten und daran angebundene Brownie-Busse für die entsprechenden Sensoren.
Dieser Thread ist noch immer vollständig weltweit aufrufbar und der zu Beginn verlinkte Artikel wird offenbar weiterhin rege gelesen. Deshalb melde ich mich nochmals in eigener Sache. Grund sind im wesentlichen die umfangreichen Posts des Benutzers "Johannes B." sowie verschiedene zustimmende Reaktionen anderer Benutzer darauf, die offenbar nicht auf fundierter Sach- und Fachkunde beruhen. Sie enthalten zahlreiche Fehler und sind zudem geeignet, mein Projekt und meine Person öffentlich zu diskreditieren. Das muss an dieser Stelle - wenn auch nachträglich - nochmals richtig gestellt werden. Das Home2L-Projekt ist ein über mehrere Jahre hinweg entwickeltes privates Programmier- und Elektronik-Projekt, das erfolgreich und konsequent zu Ende geführt wurde. Meine eigene Home2L-Brownie-Installation funktioniert seit über zwei Jahren vollkommen störungsfrei, und es gibt gute Gründe zur Annahme, dass sie auch die nächsten 20-30 Jahre mit sehr geringem Wartungs- und Reparaturaufwand weiter funktionieren wird. Das unabhängige Portal Black Duck Open Hub (https://www.openhub.net/) charakterisiert das Projekt aktuell u.a. als "with a well-commented source code" und "has a young, but established codebase ... with stable Y-O-Y commits" und schätzt den Gesamtwert des Projektes nach dem COCOMO-Modell auf 12 Mannjahre. Wie bereits erwähnt, handelt es sich um ein privates Projekt ohne kommerzielle Interessen. Da der Code unter einer Open-Source-Lizenz veröffentlicht ist, hat jedermann die Möglichkeit, das Projekt kostenfrei zu nutzen, den Code zu lesen oder für sich eigene Änderungen vorzunehmen. Den Code und den zitierten Artikel habe ich veröffentlicht mit der Absicht, andere interessierte Hobby-Entwickler zu unterstützen. Ich habe den Artikel NICHT geschrieben, um das Projekt oder mich öffentlich diskreditieren oder beleidigen zu lassen. Diesen Thread hatte ich übrigens im Forum "Projekte & Code" erstellt, der nach meinem Verständnis für Projektvorstellungen gedacht ist. Warum er hierher verschoben wurde, wurde mir nicht mitgeteilt. Zunächst möchte ich einige der oben noch immer zu lesenden unwahren Tatsachenbehauptungen richtig stellen: Johannes S. schrieb: > und es gehört nach https://www.mikrocontroller.net/forum/hausbus weil es > kein fertiges Projekt ist. Die Behauptung im zweiten Teilsatz, dass das Projekt nicht fertig sei, ist FALSCH. Und mehr noch: Es ist wirklich leicht zu erkennen, dass die Behauptung falsch ist. Bereits im 2. Abschnitt des Artikels "Hausbus auf I2C- und ATtiny-Basis: Home2L Brownies" sind konkrete Messwerte für eine reale, fertige Installation angegeben. Darüber hinaus ist der komplette Quellcode öffentlich auf Github einsehbar und dokumentiert. Es ist deshalb davon auszugehen, dass Benutzer "Johannes S." hier VORSÄTZLICH eine falsche Tatsachenbehauptung aufgestellt hat. Er hat ganz offensichtlich zu dem Zeitpunkt, als er das schrieb, genau gewusst, dass die von ihm formulierte Behauptung unwahr ist. Ich weise darauf hin, dass das öffentliche Behaupten unwahrer Tatsachen wider besseres Wissen durchaus ein Straftatbestand nach §187 StGB sein kann (Verleumdung). Johannes S. schrieb: > [...] Das so billig zu vergleichen ist einfach Kleingeistig. Der Begriff "kleingeistig" ist kein technischer Begriff und kann in dem Zusammenhang nur als persönliche Beleidigung gegen meine Person verstanden werden, die zudem öffentlich geäußert wurde (vgl. §185 StGB). Johannes S. schrieb: > das weiß Gundolf weil er KNX ja sogar selber nutzt. Ich habe Benutzer "Johannes S." auch nicht authorisiert, personenbezogene Informationen über mich zu veröffentlichen. Das ist ein Eingriff in meine Persönlichkeitsrechte, selbst dann, wenn die Behauptung - wie hier - gar nicht stimmt und von "Johannes S." frei erfunden wurde. Übrigens habe ich auch bereits vor längerem den Forumbetreiber mehrfach kontaktiert und auch darauf hingewiesen, dass hier strafbare Handlungen des im Sinne des §186 StGB (üble Nachrede), §187 StGB (Verleumdung) bzw. §185 StGB (Beleidigung) im Raum stehen. Bedauerlicherweise hat der Betreiber darauf nicht reagiert. Auch aus fachlicher Sicht basieren die längeren Posts von "Johannes S." offenbar nicht auf fundierter Sach- und Fachkenntnissen. Ich habe damals darauf verzichtet, auf derartige Posts zu antworten, gehe aber jetzt doch auf einige Punkte noch kurz ein, damit bei evtl. mitlesenden Interessierten kein falscher Eindruck entsteht: Johannes S. schrieb: > sorry, aber wenn man schon damit anfängt aktuell 8 Bitter als Vorteil zu > sehen und klobige DIL Gehäuse als kriegsentscheidend darzustellen, nein > Danke, 20. Jahrhundert. Johannes S. schrieb: > - DIP Gehäuse sind von Vorteil? In REG und UP Dosen ist wenig Platz, 230 > V braucht Isolierabstände. Wer da Angst vor SMD hat, der hat schlechte > Karten. Selbstverständlich kann man Brownie-Schaltungen vom Platzbedarf her in UP-Dosen unterbringen, auch unter Einhaltung der Isolierabstände, falls da 230V vorhanden sind. Die verwendeten Mikrocontroller in DIP-Gehäusen haben gerade den Vorteil, dass das eben auch mit von Hand auf Lochrasterplatine aufgebauten Schaltungen geht - es geht hier um Selbstbauprojekte. Ein kleiner Blick in den Artikel oder das Home2L-Repository - dort finden sich entsprechende Beispiele - oder etwas praktische Erfahrung mit Elektronik hätten eigentlich ausgereicht, um das zu erkennen. (Hinweis an Mitlesende: Arbeiten an 230V ist gefährlich. An Dosen, in denen sich auch 230V-Leitungen befinden, darf man selbstverständlich nur arbeiten, wenn man die entsprechenden Qualifikationen hat!) Johannes S. schrieb: > Die Spannungsversorgung zum Bus soll auch 5V sein? 5V rein und nach 100 > m wieder 5V raus? Womit werden Relais, BWM, Bedienpanels versorgt? Johannes S. schrieb: > Wenn der > Brownie Bus mit 5V versorgt wird dürfen die Nodes gar nicht viel Strom > ziehen, sonst bekommt man ja Probleme mit Spannungsabfällen. Bei > Versorgung mit höherer Spannung sind Spannungsregler nötig die wieder > mehr Aufwand und Verluste bedeuten, aber wie soll man sonst mit > Komponenten wie Relais und Displays arbeiten? Dass mit den 5V keine Relais oder einfachen Displays versorgt werden können, stimmt nicht. Der Artikel zum Projekt erwähnt auch explizit einen funktionierenden Test-Aufbau mit 40 Relais und zentraler 5V-Versorgung. Man muss lediglich die Randbedingungen verstehen und beachten. Johannes S. schrieb: > - die Rechenleistung von 8 Bittern reicht: bei anderen Bussen sind die > Aktoren/Sensoren sehr intelligent geworden und können umfangreiche Dinge > selber erledigen und müssen nur konfiguriert werden. Die Brownis haben > nur einen Master und Sensoren/Aktoren können einfach gehalten werden. > > Aber letzeres ist gerade der größte Nachteil, ein Master - Slave. Master > aus - Haus tot. [...] Bei jeder Änderung > oder Wartung am Master kann man kein Licht mehr einschalten, das wäre > für mich ein no go. Dass ein Bus-Master generell einen "single point of failure" darstellt ("Haus tot") stimmt so nicht. Gerade der Aspekt der Verfügbarkeit und Zuverlässigkeit wird im Home2L-Projekt an mehreren Stellen besonders berücksichtigt. Bei den erwähnten Licht- (oder Rolladen-)Aktoren ist ein Ansatz zum Beispiel, dass der ansteuernde Brownie stets auch Tastereingänge hat, mit dem das Gerät auch bei Busausfall manuell bedienbar bleibt. Bei Bussystemen mit zentral platzierten Aktoren (manche KNX-Installationen werden so aufgebaut) gibt es diese Rückfallebene nicht. Das Sicherstellen der Verfügbarkeit ist insgesamt ein komplexes Thema, und es muss immer das individuelle Gesamtsystem betrachtet und entsprechend konfiguriert werden. Bei jeder Komponente muss geschaut werden, wie wahrscheinlich ein Ausfall ist, was konkret von einem Ausfall betroffen ist, und wie der Ausfall kurz- und mittelfristig behoben werden kann (z.B. Rückfall in einen Notbetrieb, Vorhalten von schnell tauschbaren Ersatzkomponenten). Ob ein einzelner Bus dabei im Single-Master oder Multi-Master-Betrieb läuft, ist dabei nicht entscheidend, es kommt immer auf die individuelle Gesamtkonfiguration an. Gerade die Brownies bzw. das Home2L-Projekt allgemein bietet da aber an verschiedenste Werkzeuge und Mechanismen an, um insgesamt ein hoch verfügbares System zu ermöglichen. Die sind in der Dokumentation beschrieben bzw. kann ich Interessierten gerne auch persönlich erläutern. Ich hoffe, dass ich an dieser Stelle im Nachgang ein paar Missverständnisse aufklären konnte. Allen Mitlesenden, die gerne selber entwickeln und programmieren, wünsche ich viel Erfolg bei ihren Projekten!
Schrullig und verbohrt würde ich die ganze Sache nennen. Und was ist "fertig"? Gerade ein Hobbyprojekt ist niemals richtig fertig. Es kommen immer wieder neue Anforderungen oder Ideen. Wenn ich das verstanden habe, ein Attiny (Brauni) klemmt hinter dem Lichtschalter und signalisiert per I2C an die Zentrale "Schalter gedrückt". Mehr macht der nicht? Die Zentrale lässt dann ein Relais anziehen das Licht geht an?
Gundolf K. schrieb: > Ich hoffe, dass ich an dieser Stelle im Nachgang ein paar > Missverständnisse aufklären konnte. Ich schrieb ja letztes Jahr bereits, das es durchaus Sinn macht, zu seinem Projekt ein paar Bilder etc. zu veröffentlichen. Ob nun hier im Thread oder im zugehörigem Artikel, das sei ja erst ein mal egal. Ich habe aber bspw. keine Lust mir erst einmal selbst alle möglichen Informationen zusammen zu tragen um zu schauen ob das Projekt für meine Anforderungen taugt. Wie ich ja auch schon mal schrieb, hab ich mit dem i²c, der durchs ganze Haus verdrahtet wird bspw. so meine Bauchschmerzen. Dein Argument, das I²C ja für irgendwelche Monitore verwendet wird, mag richtig sein, da wird aber auf einer i.d.R recht kurzen Distanz ein Gerät mit einem anderem verbunden. Auf den Kritikpunkt von dem anderem Schreiber, das eine 5V Versorgung unschön ist, gehst Du nur in soweit ein, das er das Priinzip nicht verstanden hätte. Warum machen eigentlich alle, die etwas mit Hausbus machen eine Versorgung von 12 oder sogar 24V? Ich würde mir auch lieber 5v irgendwo aus der Versorgung generieren, als diese durch's ganze Haus zu ziehen. Was Du hier gerade machst, ist kalten Kaffee lauwarm verkaufen. Wenn Dein Projekt so erfolgreich ist freu Dich doch einfach. Wenn Du wirklich willst, das sich jemand damit auseinander setzt, poste Bilder von Modulen, der Installation, den Platinen usw. >
Gundolf K. schrieb: > Deshalb > melde ich mich nochmals in eigener Sache. wenn du nicht kritikfähig bist, dann solltest du öffentliche Foren meiden.
Johannes S. schrieb: > Gundolf K. schrieb: >> Deshalb >> melde ich mich nochmals in eigener Sache. > > wenn du nicht kritikfähig bist, dann solltest du öffentlich Foren > meiden. Nur zu deiner Erinnerung. > Johannes S. (jojos) 10.05.2020 00:35 > yet another Homeautomation Totgeburt. Das ist keine Kritik. Das ist peinliche Verhalten eines Menschen der nicht in der Lage ist sich sachlich oder fachlich zu artikulieren.
Jade schrieb: > Das ist keine Kritik. doch, und es ist meine Meinung, auch heute noch. Wenn viele andere das Projekt nachgebaut haben und toll finden, dann gönne ich ihnen das und dem Autor auch seinen Erfolg. Aber trotzdem muss ich nicht zum Jubelperser werden wenn ich es nicht toll finde.
Gundolf K. schrieb: > Den Code und den zitierten Artikel habe ich veröffentlicht mit der > Absicht, andere interessierte Hobby-Entwickler zu unterstützen. Hi Gundolf, diesem deinem Anliegen hast du aber mit deiner Reaktion auf Johannes Rückmeldung zu deinem Projekt keinen Gefallen getan. Wenn du schon über kritische Meinungsäusserungen mit dem StGB herziehst, welches Risiko möhen da eventuelle Nachahmer eingehen ... LG, Sebastian
Also ich finde die Idee nicht schlecht. Ist halt das maximal mögliche mit kleinen Controllern, und wenig Hardware. Wenn der Stromverbrauch so gering ist, sind auch die 5V egal. Wobei ich eine mögliche Integration in Openhab und IObroker auch zeitgemäß finden würde. Vieles was hier kritisiert wird kann doch jeder so nachbauen wie er es für richtig hält. Gibt ja keinen zwang DIP zu verwenden und wer unbedingt will baut halt überall noch Spannungsregler ein. Aber ganz ehrlich ich finde das Konzept auf Grund des Stromverbrauches stimmig.
Sebastian schrieb: > diesem deinem Anliegen hast du aber mit deiner Reaktion auf Johannes > Rückmeldung zu deinem Projekt keinen Gefallen getan. Wenn du schon über > kritische Meinungsäusserungen mit dem StGB herziehst, welches Risiko > möhen da eventuelle Nachahmer eingehen ... So sieht's aus. Hatte mir das Projekt damals kurz angesehen und schnell wieder verworfen, eben wegen der hier schon genannten Punkte: - I2C und 5V halte ich für eine sehr ungeeignete Wahl. - Mir ist das Ganze a) viel zu technisch und b) zu fixiert auf Low-Level-Fragestellungen wie Bitbreite und Typ der uCs. Das System muss auch durch meine Frau wartbar sein, sollte ich mal nicht mehr oder gerade im Ausland sein. Und die kann Weboberflächen bedienen, aber keine Linux-Shell. Ganz zu schweigen bei Defekten usw.; der lokale Elektriker kann hier sicher nicht helfen. - Der zentrale Ansatz ist für mich ebenfalls vollkommen ungeeignet; das wird nicht besser dadurch, dass das Manual versucht, mittels Whataboutism KNX genau so schlecht dastehen zu lassen. Aber mit diesem Posting und Drohung mit allen möglichen rechtlichen Mitteln ist das Thema definitiv durch; ein Ein-Mann- oder Kleinprojekt, dessen Autor sich so verhält – da lasse ich meine Finger ganz weit weg.
Horst G. schrieb: > Aber mit diesem Posting und Drohung mit allen möglichen rechtlichen > Mitteln ist das Thema definitiv durch; ein Ein-Mann- oder Kleinprojekt, > dessen Autor sich so verhält – da lasse ich meine Finger ganz weit weg. Der Autor hat einfach nur recht Verleugnung ist strafbar. Aber dass er irgendwem mit rechtlichen Mitteln gedroht hat steht hier nirgendwo geschrieben. Man könnte ja wenigstens aufhören irgendwas zu unterstellen was nicht ist. Und kein einziges Hausbus smart-home-system kann von deiner Frau wieder in Gang gebracht werden. Es sei denn sie kennt sich genauso gut mit der Technik aus wie der Mensch der es in Betrieb genommen hat. Und kein einziges hausbussystem welches im Selbstbau entstanden ist wird von irgendwem anders außerdem Erbauer repariert werden können.
Hallo Gundolf finde deine Arbeit sehr gut. Arbeite selber mit dem Attiny 841 und dem I2C Bus. Habe dazu verschiedene Teile aufgebaut und schreibe auch die Programme dazu. LG Paul
DANIEL D. schrieb: > Der Autor hat einfach nur recht Verleugnung ist strafbar. Das ist Unsinn. Die einzige Verleugnung, die unter bestimmten Umständen strafbar sein kann, ist die des Holocausts. Ansonsten kann man realitätsfern leben wie man will. Natürlich können als Folge einer Verleugnung andere strafbare Tatbestände erfüllt werden, siehe Reichsbürger. Etwas gänzlich anderes wäre jedoch die Verleumdung anderer Personen, die per se unter bestimmten Umständen strafbar sein kann.
:
Bearbeitet durch User
Andreas S. schrieb: > Etwas gänzlich anderes wäre jedoch die Verleumdung anderer Personen, die > per se unter bestimmten Umständen strafbar sein kann. Also wie z.B wenn ich behaupte die Arbeit einer Person sei unfertig, obwohl sie das nicht ist?
DANIEL D. schrieb: > Also wie z.B wenn ich behaupte die Arbeit einer Person sei unfertig, > obwohl sie das nicht ist? Statt einer Verleumdung könnte auch eine Üble Nachrede o.ä. vorliegen. Lies Dir doch einfach selbst StGB §186 ff. durch. Den obigen strafbaren Handlungen stehen durchaus andere (Grund-)Recht entgegen, z.B. das Recht auf freie Meinungsäußerung oder die Freiheiten für Kunstschaffende. Daher gibt es unzählige Gerichtsurteile zu der Frage, wie eng oder weit diese entsprechenden Behauptungen gefasst sein müssen. Diese Thematik beschäftigt die Gerichte schon seit Jahrzehnten. Folglich kommt es auf jeden Einzelfall und den Gesamtzusammenhang an. Bei Behauptungen, die sich durch Dritte leicht überprüfen lassen, liegt die Latte der Strafbarkeit auch wesentlich höher als wenn es sich um "Insiderwissen" handelt. Die Behauptung, die öffentlich zugängliche Arbeit einer Person sei unfertig, wäre vermutlich keine Verleumdung oder Üble Nachrede. Bei einer nicht öffentlichen Arbeit wäre das jedoch anders, insbesondere wenn solch eine unwahre Behauptung durch einen Kunden aufgestellt würde und somit die Gefahr einer erheblichen Rufschädigung bestünde. Hier kämen ggf. aber zusätzlich auch noch wettbewerbsrechtliche Gesichtspunkte hinzu. Die kurze Antwort: Es kommt darauf an.
DANIEL D. schrieb: > Horst G. schrieb: > Und kein einziges Hausbus smart-home-system kann von deiner Frau wieder > in Gang gebracht werden. Es sei denn sie kennt sich genauso gut mit der > Technik aus wie der Mensch der es in Betrieb genommen hat. > Und kein einziges hausbussystem welches im Selbstbau entstanden ist wird > von irgendwem anders außerdem Erbauer repariert werden können. Und das ist der Grund, weshalb ich von solchen Projekten die Finger lasse. Die (Material)-Ersparnis beim Einbau im Vergleich zu KNX verliert meine Frau ganz schnell, falls mir als Erbauer etwas passiert. Beim Wiederverkauf gibt's einen satten Abschlag, weil die Installation neu aufgesetzt werden muss. Ich würde das meiner Familie/meinen Erben nicht zumuten wollen.
Das artet doch wieder aus hier. Man Leute! Da stellt ein Kauz seine Interpretation einer smarthome Lösung vor und nun gipfelt es da drin dass einer vor den Kadi gezogen werden sollte weil er seiner Kritik mit harschen Worten Nachdruck verleihen will. Und da stimme ich Horst zu, da will man nicht mitmachen.
:
Bearbeitet durch User
ich finde der Bus muss nur Daten durch die Gegend schicken und da ist bei einer differentiellen Übertragung wie bei RS485 oder CAN eine niedrige Spannung absolut ausreichend. Jeder Aktor braucht eh eine höhere Spannung die er also schon mitführt. Wenn ich eine 230V Lampe Schalten will sind ja die 230V da. Ich muss also nur den Befehl durch die Gegend schicken. Das KNX Kabel hat ja 4 Leiter, also wieso nicht 2 für die Daten und 2 für die 5V nehmen und schon kann mal auf Buskoppler verzichten. Ich gehe sogar soweit das ich keinerlei Spannungsregler auf meinen Platinen habe. Nur einen kleinen LC Filter mit Z-Diode und dahinter nochmal nen 100µF Elko.
Thomas O. schrieb: > wieso nicht 2 für die Daten und 2 für die 5V nehmen und schon kann mal > auf Buskoppler verzichten. Ich gehe sogar soweit das ich keinerlei > Spannungsregler auf meinen Platinen habe. Ich bin im Garten unterwegs. Da fehlt natürlich der Ringerder. Aktuell habe ich 19V DC, 9V DC und CAN hin- und zurück auf den Erdkabeln. Ich warte noch auf den ersten Blitzeinschlag ... LG, Sebastian
Horst G. schrieb: > Aber mit diesem Posting und Drohung mit allen möglichen rechtlichen > Mitteln ist das Thema definitiv durch; ein Ein-Mann- oder Kleinprojekt, > dessen Autor sich so verhält – da lasse ich meine Finger ganz weit weg. Das ist eine falsche Tatsachenbehauptung. Richtig ist, dass ich an keiner Stelle irgend jemandem gedroht habe, insbesondere nicht mit rechtlichen Mitteln. Es ist wirklich erstaunlich, dass scheinbar mehrere Teilnehmer sich hier öffentlich äußern, die offenbar immer noch nicht den Unterschied verstanden haben zwischen einer Meinungsäußerung und der bewussten Verbreitung von Falschinformationen oder Beleidigungen. Es ist wirklich erstaunlich, dass sich noch immer Teilnehmer mit absurden persönlichen Unterstellungen der Art, ich sei nicht kritikfähig, hier öffentlich zu Wort melden. Wer mich persönlich kennt oder auch einfach mal meine vorherigen Posts gelesen hat, sollte eigentlich wissen, dass ich auf sachliche Fragen - ebenso wie auf sachbezogene Kritik - stets sachliche Antworten gebe und regelmäßig Hilfe bei fachlichen Nachfragen anbiete. Die in meinem vorherigen Post konkret benannten Zitate des Johannes S. sind objektiv KEINE Meinungsäußerungen, sondern so wie erläutert und belegt falsche Tatsachenbehauptungen und z.T. persönlich beleidigend. Falsche Tatsachenbehauptungen sind richtig zu stellen. Das habe ich in meinem vorherigen Post gemacht. Mehr nicht! Ich wiederhole es noch einmal: Mein Programmcode habe ich vollkommen freiwillig und mit guter Absicht für diejenigen zur Verfügung gestellt, die sich dafür interessieren. Meine Absicht war, einen konstruktiven Beitrag für die fachlich interessierte Community zu leisten. Ich habe keinerlei wirtschaftliche Interessen. Mir persönlich ist es vollkommen egal, wer sich das Projekt anschaut oder verwendet. Dass gleich mehrere Forumteilnehmer dieses freiwillige Angebot meinerseits mit einer derartigen Respektlosigkeit und Undank kommentieren, hätte ich nicht erwartet. Ganz sicher werde ich hier keine Projekte oder Code-Beispiele mehr vorstellen.
Vielen Dank, @DANIEL D. und Paul (Gast), für die Unterstützung und das positive Feedback. DANIEL D. schrieb: > Wobei ich eine mögliche Integration in Openhab und IObroker auch > zeitgemäß finden würde. Die Integration in solche Installationen (und auch andere Systeme) ist möglich. Das läuft dann über das MQTT-Protokoll. Einzelheiten dazu finden sich in den Kapiteln "2.5. Using MQTT" sowie "10.4. The MQTT Gateway Driver" der Projektdokumentation ("Home2L Book" auf der Github-Seite). Für Fragen oder evtl. Hilfestellungen bin ich gerne über die Github-Projektseite erreichbar.
Gundolf K. schrieb: > Die Integration in solche Installationen (und auch andere Systeme) ist > möglich. Das läuft dann über das MQTT-Protokoll. Einzelheiten dazu > finden sich in den Kapiteln "2.5. Using MQTT" sowie "10.4. The MQTT > Gateway Driver" der Projektdokumentation ("Home2L Book" auf der > Github-Seite). Ich habe das mal teilweise gelesen das geht ja dann alles über das Linux System. Und du hast scheinbar ernsthaft ein komplettes Systeme erschaffen. Das ist auf jeden Fall viel mehr wie nur ein Bussystem. Welches ich übrigens sehr gut finde. Ich werde da noch mal mehr lesen.
Carsten schrieb: > Ich nutze auch ATtinys als Slave für die Auswertung vom Gas - und > Stromzähler sowie für Dimmer. > Ich überlege mir, meinen Vierfachdimmer mit Zeitschaltuhr hier zu > veröffentlichen. > Wenn ich mir jedoch die Kommentare anschaue, bin ich mir nicht mehr > sicher, ob dies das richtige Forum ist. > Carsten Hallo Rudolf, wie mein Namensvetter nutze ich auch ATtinys für die Auswertung von Gas und Strom. Das funktioniert seit Jahren sehr gut. Auch einen Vierfachdimmer mit Zeitschaltuhr habe ich gebaut(Zufall). Alle Programme der ATtinys sind in Assembler geschrieben. Ich habe die gleichen Bedenken wie mein Namensvetter. Mein Konzept sieht zwar anders aus, aber ich finde Dein Projekt sehr interessant. Gruß Carsten
:
Bearbeitet durch User
Gundolf K. schrieb: > Ganz sicher werde ich hier keine Projekte oder Code-Beispiele mehr > vorstellen. Weise Entscheidung! Wer so dünnhäutig ist und wegen einer YAT-Kritik gleich Paragraphen zitiert ist zu mindest für DIESES Forum nicht geeignet. Bleib du lieber in deinem Tiny-Schloss und geniesse die reibungslose I2C-Steuerung.
Trotzdem nett das der TO nach einem Jahr noch einmal zum Faktencheck eingeladen hat. Denn da bestätigt sich das was ich mit meinem ersten Satz gemeint hatte, und was einige offensichtlich nicht verstanden haben. Auf Github gibt es (Stand heute) 2 (in Worten: zwei) Forks des Projekts. Diese wurden auch nicht weiterentwickelt und sind beide auf altem Stand (last commit 3 years ago / 10 months ago). Es gibt keine Issues, keine Pull Requests, keine Branches. Mit anderen Worten für diejenigen die sich mit Github nicht so auskennen: es gibt freundlich gesagt ein sehr geringes Interesse an diesem Projekt. Also genau das, was ich mit meinem Resume ausdrücken wollte. Immerhin gibt es 4 Follower und 14 Sternchen. Das 'Black Duck Open Hub' Portal kannte ich bisher nicht, aber wenn es dem TO so wichtig ist das er da das ganze Lob zitiert: Gundolf K. schrieb: > Das unabhängige Portal Black > Duck Open Hub (https://www.openhub.net/) charakterisiert das Projekt > aktuell u.a. als "with a well-commented source code" und "has a young, > but established codebase ... with stable Y-O-Y commits" und schätzt den > Gesamtwert des Projektes nach dem COCOMO-Modell auf 12 Mannjahre. Ist es nur typische Werbung oder schon Trumpismus? Denn was er nicht erwähnt sind die anderen Daten wie :'very low activity', '0 current contributors', '1 users on Open Hub' (der TO selber), 0 Reviews. Also auch hier sehr bescheidenes Feedback. Zum selber bewerten: https://www.openhub.net/p/home2l Wenn man sich die Kategorie 'Smarthome' auflisten lässt: https://www.openhub.net/tags?names=smarthome&page=1 dann werden 18 Einträge gelistet. Top sind openHAB und ioBroker, mit sehr großer Community und aktiven Entwicklern. EdgeX und Major DoMo liegen schon weit dahinter, der Rest rangiert mit 'low activity', wenigen Unterstüzern und/oder lange zurückliegenden Commits schon unter ferner liefen. Und danach soll jetzt jemand seinen Hausbus aufbauen? Als Vergleich nochmal das Selfbus Projekt: es gibt viele verschiedene Komponenten mit Schaltplänen und Software zum Nachbau und eine große, aktive Community. Es ist kompatibel zum etablierten EIB/KNX. Dadurch kann es mit den bekannten, gut unterstützten Automatisierungslösungen wie openHAB, ioBroker, FHEM u.v.a genutzt werden. Systemen, die eine heterogene Vernetzung by Design ermöglichen. Weil diese als Konzept im Kern eine in-Memory Datenbank haben die Zustände verwaltet und über Adapter beliebige Bussysteme, logische Verknüpfungen, Visualisierungen sowie Datenbanken anbinden können. Entwicklungen in denen Mannjahre Arbeit stecken und die trotzdem alle als OpenSource frei genutzt werden können. Apropos KNX: mea Culpa, ich habe den TO mit dem User 'Guest' verwechselt. Anstatt kurz zu fragen 'wie kommst du darauf das ich KNX benutze?', konstruiert der TO daraus eine Verletzung von Persönlichkeitsrechten. Aha. Verwechslungen oder Schreibfehler unterlaufen auch dem TO, oder wer ist "Johannes B." ? Zum Projektstatus: in 'Projekte und Code' wurden die Eingangs geposteten wenigen Zeilen als Link zu einem Artikel hier eingestellt. Dieser Artikel ist wiederum Werbung für ein Projekt und konkretere Informationen erhält man nur über externe Links. Mir also 'VORSÄTZLICH eine falsche Tatsachenbehauptung' vorzuwerfen ist absurd bis unverschämt. Und die Entscheidung, Beiträge zu verschieben, obliegt den Moderatoren des Forums. Gundolf K. schrieb: > und freue mich auf Rückmeldungen aller Art! Offensichtlich nur wenn es ultimative Lobhudeleien sind, anderes möchtest du nicht hören. Gundolf K. schrieb: > Wer mich persönlich kennt oder auch einfach mal meine vorherigen Posts > gelesen hat, sollte eigentlich wissen, dass ich auf sachliche Fragen - > ebenso wie auf sachbezogene Kritik - stets sachliche Antworten gebe und > regelmäßig Hilfe bei fachlichen Nachfragen anbiete. Reden und Handeln liegen hier allerdings weit auseinander. Wer nach einem Jahr hier noch so ein Fass aufmachen muss und mit Paragraphen um sich wirft, der scheint ein deutliches Problem zu haben.
Johannes S. schrieb: > Reden und Handeln liegen hier allerdings weit auseinander. Wer nach > einem Jahr hier noch so ein Fass aufmachen muss und mit Paragraphen um > sich wirft, der scheint ein deutliches Problem zu haben. Du musst schon extrem neidisch auf die erbrachte Leistung sein, wenn man sich so sehr darüber aufregt, das einer ne komplette Haussteuerung entwickelt. Ich erkenne nicht wirklich was so schlimm daran ist. Ich bin mir zu 100% das du nicht mal ansatzweise diese Qualität erreichen könntest. Deswegen auch überwiegend Kritik an der Person, und der versuch mit Schwachsinn zu argumentieren. Wie z.B das keine 32bit controller verwendet wurden.
DANIEL D. schrieb: > Ich erkenne nicht wirklich was so schlimm daran ist. Daran ist nichts schlimm. Aber nochmal: das muss nicht jeder toll finden und das ist auch nicht automatisch eine Geringschätzung des Autors. DANIEL D. schrieb: > Ich bin mir zu 100% das du nicht mal ansatzweise diese Qualität > erreichen könntest. Das habe ich erstens nie behauptet und zweitens habe ich mich vorab ausgiebig über Hausautomatisierung informiert. Der Markt ist voll von Hard- und Softwaresystemen und ich habe mich früh gegen einen Selbstbau mit dieser Fertigungstiefe entschieden. Jetzt habe ich zwei Etagen im Haus umfangreich mit Sensoren und Aktoren ausgerüstet. Da wo es ging verkabelt und an weiteren Stellen per Funk. Schon in einem alten Hausautomatisierungs Sonderheft von Heise gab es einen Erfahrungsbericht nachdem es kaum möglich ist alles mit einem System zu erschlagen. Das ist eine wichtige Erkenntnis und viele andere und ich sehen das genauso. Etwas im Umfang von ioBroker, openHAB & Co. würde ich nicht im entferntesten selber schreiben wollen. Alleine das Nutzen der gebotenen Möglichkeiten ist eine gigantische Dauerbaustelle!! Zum 'Sparen' kann man seinen eigenen Bus bauen, nur die Nachteile wurden hier schon mehrfach genannt. DANIEL D. schrieb: > Deswegen auch überwiegend Kritik an der Person, und > der versuch mit Schwachsinn zu argumentieren. Wie z.B das keine 32bit > controller verwendet wurden. Auch das ist wieder eine verdrehte Tatsache und ich habe es bereits begründet. Auf weiteres Nullsummenspiel habe ich keine Lust.
Ja du magst ja vollkommen Recht haben, es ist wirklich für die meisten Menschen unmöglich ein komplettes System selbst zu bauen. Und in Konkurrenz mit IO Broker und openhab ist es schwer besser zu sein, oder etwas für die Massen. Aber ich finde das Projekt trotzdem sehr sinnvoll. Ich habe mir das PDF noch nicht komplett durchgelesen, trotzdem muss ich sagen das ich viele enthalte Ideen echt gut finde, welche man, egal welches System man am Ende verwenden wird sinnvoll nutzen kann. Und ich bin der Meinung ein dermaßen sparsames Bussystem hat einfach gefehlt. Ein Wohnhaus braucht man halt keine 1000m mögliche Übertragungsreichweite von differentieller Übertragungstechnik. Der Bus verbraucht so gut wie kein Strom. Man braucht keine Quarze. Bei DIP kann man leichter auf den ISP verzichten. Und da es so gut wie kein Strom verbraucht kann man wirklich bei einem Großteil der Bus-Teilnehmer welche keine Lasten treiben müssen wie Relais, auf den Spannungsregler verzichten.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.