Mein Forum
Registrieren
Neu hier?
Baukonstruktionen
Fertighaus
Fenster
Dämmung
Dichtheit
Passivhaus
Schimmel
Energieausweis
Heizung
Pellets
Erdwärme
Warmwasser
Stromsparen
Solaranlagen
Photovoltaik
Lüftungsanlagen
Energiespartipps
Berechnungen
|
|
||
|
Ich habe mir jetzt mal eine Futro organisiert, denke das der als Plattform nicht schlecht ist, egal für welches System. Die 5 W stören mich jetzt auch nicht so, gibt sicher schlimmere Stromfresser. Habe jetzt ein bisschen mit ioBrocker auf den Raspberry herumgespielt und da merkt man schon dass er einwenig überfordert ist. Schauen wir mal wie es mit Futro und Proxmox läuft. |
||
|
||
|
also mein Futro spielt sich mit meinen Edomi, dass dauerd pollt und sachen abfragt und macht und dazu in die Influx Partition sachen schiebt und Grafana flitzt auf! Am besten je 2 Cores mit 1 gig Ram oder mehr zur Verfügung stellen! Hatte anfangs eine mit zu wenig Ram, da gings zach |
||
|
||
|
Edomi only. läuft perfekt, visu verwende ich sehr selten (nur zum logging PV und Eigenverbrauch). |
||
|
||
|
Ich nutze IP-Symcon. Hat den Vorteil, dass sich dort mittlerweile echt alles integrieren lässt und eine super Community dahinter steht (inkl. Firma). Nachteil, mittlerweile kostet es schon einiges. |
||
|
||
|
Was mich vor proprietären Lösungen wie edomi oder IP-Symcom halt immer abschreckt ist, dass man an einen Hersteller gebunden ist und dass es passieren kann, dass irgendwann Funktionen abgedreht/kostenpflichtig/o.ä. werden. Da gibt es leider immer wieder Bsp. Ich wollte z.B. snips für die Offline-Sprachsteuerung verwenden und bevor ich richtig anfangen konnte, wurde die Firma von Sonos gekauft und die API dafür abgedreht. Die User, die da viel Zeit in die Einrichtung ihrer Sprachsteuerung gesteckt haben, haben dann Pech gehabt. Oder Logitech hat mal die API für den lokalen Zugriff auf das Harmony-System abgedreht (dann aber nach sehr viel Kritik wieder aktiviert). Bei OpenSource geht es eigentlich immer weiter, dafür hat man halt keinen Support einer prof. Firma, die dahinter steht. Kannte die Plattform gar nicht. Dürfte lt. Spezifikationen etwas (10-30%) schneller als ein Raspberry Pi4 sein. Bei IO-lastigen Sachen noch mehr, wegen SATA. Also sicher auch super als NAS oder Medienserver geeignet. |
||
|
||
| Hallo chrismo, schau mal hier im Shop nach, da siehst du Preise und wirst sicher auch fündig. | ||
|
||
|
Vor allem edomi läuft eig. Nicht auf einen pi, wegen anderer Prozessorplattform. Ist wirklich ein gutes billiges teil |
||
|
||
|
Stimmt zum Teil. Aber IP-Symcon ist ein kommerzielles Produkt, da steht eine Firma mit hunderten/tausenden Installationen dahinter und man muß eh dafür bezahlen. Klar gibts keine Garantie, aber die hat man beim Gira Homeserver oder Loxone auch nicht. Edomi, Openhab usw. sind komplett opensource, was für ein paar Spielereien sicher ok ist. Wennst aber in 5 Jahren die Lust fürs Rumspielen verlierst oder nicht mehr kannst, fangen dann die Probleme an, weil das kein anderer mehr angreifen wird. |
||
|
||
|
Für mich stellt sich immer noch die Frage warum es solche Monster braucht. Die meisten dieser tools bieten Funktionalität als Klickibunti an, die man auch einfach runterprogrammieren kann und ich meine nicht, dass man alles selber machen muss. Für OpenHAB hab ich mir mal die Liste der plugins angesehen und für so gut wie jedes davon ein Python-library-pendant gefunden, das sich einfach integrieren hätte lassen. Fehler gibt es da wie dort. Als Nicht-Softwerker bekommt man entweder Firmensupport, den aus der Community oder eben keinen. Wenn der support scheitert, ist man auf sich selbst gestellt und dann ist es vorteilhaft, wenn die Komplexität möglichst niedrig ist. Auch ist dann die Austauschbarkeit gewahrt. Wenn Grafana also schlecht unterstützt wird, kann ich vermutlich ein tool-XY in der Zukunft verwenden, das eine ähnliche Leistung bietet, wenn ich in OpenHAB hänge, tausche ich das gesamte SW-System aus, weil ändern willst als Normalsterblicher in diesem Monster nichts. Eigentlich ist das ein zeitgenössisches Problem, viele fahren einen SUV mit n-tausend Assistenzsystemen und haben nicht den geringsten Plan was da läuft, nicht-mal mehr die Werkstätten bekommen das immer hin. Am Ende steht die Kiste aus unerfindlichen Gründen ... meine Autos sind bisher immer an 'Multiorganversagen' gestorben, mit mehr als 15 Jahren am Buckel. In Häuser (oder Autos) Dinge einzubauen, die einen deutlich niedrigeren life-cycle haben (consumer range 1-5 Jahre) ist sowieso problematisch, will aber auch keiner sehen. Verhält sich ähnlich wie Flachdächer, Nordseiten-WDVSe und Holz-Ziegel-Mischarchitekturen (nein den Dachstuhl mein ich nicht), steigende Komplexität und immer weniger (relative) Kompetenz bei den Ausführenden und den Benutzern. ---- rant mode off --- |
||
|
||
|
jo eh, aber seine eigene Haussteuerung selbst "runterprogrammieren" ist sehr zeitaufwändig. Wenn du da jemanden beauftragst, ist das eher nicht leistbar. oder eben beides bei einer kommerziellen Lösung wie zb. loxone oder ip-symcon. Korrekt. Obwohl Grafana eher wurscht ist, das ist nicht essentiell. Darum "predigen" ja so viele (inkl. mir), dass die Grundfunktionalität vom System selbst abgedeckt sein soll und die Visualisierung/Spielereien eben dann mit OpenHab, Loxone, FHEM, IPSymcon usw. gemacht wird. d.h. da kommt dann eh nur KNX in frage. Wenn die superschicken Grafiken mal nicht funktionieren, wirds deiner Frau wurscht sein. Wenn aber das Licht oder die Heizung nicht mehr funktioniert, weil irgendein Problem mit den Spielerein aufgetreten ist, dann hast ein echtes Problem mit deiner Frau
|
||
|
||
|
Ich bin ja auch ein Freund von Textkonfiguration. Aber für 95% der BenutzerInnen ist eine grafische Oberfläche wichtig, damit schnell damit weiterkommen. Die Aussage verstehe ich nicht. Was hat das eine mit dem anderen zu tun? 🤔 Oder anders gesagt: was nützt mir eine Library, die dann nicht mit dem Rest des Systems integriert ist. Man muss erst die Kommunikation mit dem physischen Ding herstellen, Werte auslesen, in ein uniformes Format bringen bzw. Semantik zuordnen, damit das System weiß, dass das jetzt eine Temperatur ist, oder ein Schalter, etc. Dazu sollte es dann noch so modular aufgebaut sein, dass ich einzelne Teile beliebig austauschen kann (welche Datenbank, welche Plugins zur Anbindung von Sensoren/Aktoren). Das hat für mich weniger mit "Monster" zu tun als mit Grundfunktionalitäten so eines Systems. Aber vielleicht habe ich dich falsch verstanden. Da stimme ich dir bzw. gdfde komplett zu. Daher sollte das Smart Home System auf einer soliden technischen Basis stehen, bei uns z.B. KNX. Wenn ich den Raspberry Pi mit openHAB und co. außer Betrieb nehme, fällt die Smartphone/PC-Steuerung weg und die ganze Logging-Funktionalität (Nibe WP WP [Wärmepumpe], Smartmeter, Temperaturen). Also im Prinzip genau das, was ohnehin nur ich nutze. Der restlichen Familie würde das nichtmal auffallen |
||
|
||
|
Da hast du aber weit ausgeholt :D Aber nur weil du keinen SUV willst musst du dein Auto ja nicht gleich selber zusammenschweißen ;) Grundsätzlich bin ich bei dir, ich finde da aber den HomeAssistant Ansatz auch ganz nett. Da darf z.B. kein hardwarespezifischer code in den core, das muss alles in eigene spezifische python libs ausgelagert werden die dann auch anderen projekten zur Verfügung stehen (und auch getrennt weiterleben für den Fall der Fälle). Die HomeAssistant plugins sind dann im prinzip nur converter zwischen diesen hardware anbindungen und dem HomeAssistant interfaces. Im Prinzip einfach eine Abstraktionsschicht mehr mit definierten Interfaces für Daten und Konfiguration und einem Broker/Eventsystem dazwischen. Und alles weitere (Visualisierungen/Datenbank) usw. ist dann wieder ausgelagert und die Anbindung an diese kann zentral getauscht werden wenn nötig. Und ja, das könnte man auch selber basteln, muss man aber nicht unbedingt ;) Wenn ich jetzt z.b. Lüftung, Heizung,... in eine Datenbank mitloggen will muss das ja irgendwo zusammenlaufen. Und natürlich kann das jedes subsystem getrennt machen, aber dann muss ich halt für den Fall, dass ich die Datenbank austauschen will das auch überall getrennt nachziehen. Was man natürlich kritisieren kann ist dann z.b. ob es das integrierte HomeAssistant Dashboard braucht. Wobei sie auch da relativ fokusiert sind und klar sagen: "Wenn ihr aufwändigere Datenvisualisierungen braucht, bindet dafür Grafana ein, denn wir wollen nichts nachbauen das jemand anderes schon besser kann" Ich finde es einen guten tradeoff zwischen Bequemlichkeit und Flexibilität/Offenheit. Kommt aber natürlich auch wieder stark auf das Anwendungsgebiet an. Also irgendeine Art von Broker muss ja fast sein (ob das nun MQTT, Homeassistant oder Nodered ist) sonst wird alles was darauf aufbaut unübersichtlich. |
||
|
||
|
Zwischen, ein durchschnittlich ausgestattes Auto halbwegs verstehen und eines selber schweißen gibt es eben viele Stufen. Die Tendenz der Benutzer geht bei immer weniger Know-How zu immer komplexeren Fahrzeugen. Ja klar, nur schießen die meisten der genannten Systeme (OpenHAB, FHEM, HomeAssistant und ioBroker) deutlich über dieses Ziel hinaus, die eine Portierbarkeit in andere Bereiche verunmöglicht. Ein MQTT-Broker ist so fundamental, dass du Implementierungen in 100 Sprachen und für zig Plattformen findest, das ist so nicht vergleichbar. Ich wollte aber eigentlich nur darauf hinweisen, dass diese SW-Brocken suggerieren, dass sie die Dinge einfach machen, aber in Wahrheit die Komplexität gewaltig nach oben schrauben. Allein z.B. die Versionspflege der eigenen Konfiguration und der software an sich kann nur von Spezialisten vernünftig geleistet werden, dem Durchschnittsnutzer ist nichtmal klar, dass er sowas braucht Eine Ausfallanalyse mit einem zentralisierten Brocker ist auch schon eine Herausforderung, such mal einen Fehler nach einem Systemupdate, das notwendig wurde weil ein plug-in mit einer gewünschten Erweiterung einen Konflikt produziert, nicht mehr gepflegt wird und der Ersatz erst ab Version-x läuft. Es ist eben wie in den oben genannten Dingen, diese tools erlauben rel. Unwissenden das Erschaffen komplexer Systeme, deren Ausfallwahrscheinlichkeit beliebig hoch ist. https://en.wikipedia.org/wiki/Total_cost_of_ownership wird hier total unterschätzt. Ich denke alle, die hier schreiben, wissen worauf ich hinauswill, ich wollte dem OP nur eine kleine Warnung mit auf den Weg geben. Es gab ja in einem Parallelthread die Frage, ob man nicht die konventionelle Lichtinstallation völlig aufgeben soll ..., sicher eine Spitzenidee. |
||
|
||
|
Ja, das ist ein guter Punkt. Viele hier richten ja ihr System selbst ein und warten es dann auch - mich eingeschlossen - womit die Arbeitszeit kostenlos ist. Ich kann nicht sagen, wieviele Stunden ich da insgesamt "versenkt" habe, aber ich denke, es wird in den zwei Jahren sicher Richtung dreistellig gehen. Ich sehe das als Hobby und somit schaue ich da wirklich nicht auf die Zeit. Ich habe sogar umgekehrt einiges dabei gelernt, was ich dann später in der Arbeit nutzen konnte, profitiere somit doppelt davon. Aber jetzt lass das einen Spezialisten für 80-100 Eur/h netto erledigen und du hast die Kosten für einen Kleinwagen ins Smart Home gesteckt - um bei den Autovergleichen zu bleiben Da ist klar, dass es auch sehr nutzerfreundliche Systeme geben muss, die schneller eingerichtet (dafür weniger flexibel sind). Ja, das wurde aber eh von jedem anderen als Schnapsidee gesehen, aber wer nicht hören will... |
||
|
||
|
Also ich benutze HASSIO in verbindung mit KNX und ESPHome, und restlos davon überzeugt. Grundfunktionen bietet mir ausfallsicher und mit hohem WAF das KNX und mit HASSIO und ESP Home kann ich trotz viel Arbeit und Kinder ohne viel Zeitaufwand alles umsetzen was das her begehrt. und die Kosten sind Minimal |
||
|
||
|
Ich gabe euch allen recht und würde diese Systeme nicht als Core KNX System einbinden. Bei mir läuft KNX auf einen X1 und dort soll es auch bleiben. Die Systeme wie ioBroker, OpenHAB, FHEM, HomeAssistant, usw... sind für mich Erweiterungen und Unterstützungen. Hauptsächlich ist der Plan damit eine Visu zu erstellen, wo ich mehrere Systeme zusammenfassen kann für Steuerung über ein Tablet und für Logging für Daten welche man sich dann auch über die Visu anzeigen lassen kann. Wenn dann der Broker bei mir ausfallen würde hat das keinen Einfluss auf die Grund-KNX-Konfiguration, schlimmstenfalls würden ein paar spielereien wegfallen, aber die habe ich jetzt auch nicht und kann sehr gut damit leben. Ich sehe das ganze auch eher aus Hobby und will sehen was man alles so rausholen kann aus dem System, aber wie gesagt nur aufbauend auf ein funktionierenden KNX System, welches nicht ersetzt wird sondern nur erweitert. |
||
|
||
|
Sehe das ebenfalls so. Alle Basic-Funktionen sind in KNX/DALI in solider Herstellerunabhängiger Hardware realisiert. Komfortfunktionen mit Timer und Bedingungen sind über Edomi gelöst, welches zwar nicht Open-Source ist aber Freeware mit grosser Community. Und wenn die Visu einmal nicht mehr funktioniert merkts in 5 Jahren e keiner mehr. |
||
|
||
|
Naja wozu brauchst du den X1 als Core? bei KNX ist ja der vorteil das jedes gerät für sich die Funktionalität mitbringt um locker alle Kernfunktionen im Haus abdeken zu können. Fände es recht blöd einen X1 für eine Visu uu haben und dann noch eine HASSIO oder OpenHAB Visu, ich will ja nicht switchen müssen Also das X1 Teil würde ich mir echt sparen weil es finde ich für den Preis viel zu wenig mehrwert bringt gegenüber der Funktionalität der Endgeräte ...... Was würdest du am X1 machen was die Engeräte nicht von sich aus können, aber so wichtig ist das du es nicht auf z.b. HASSIO machen würdest? Mit Grundfunktionen meinte ich z.b. sowas wie das weder Heizung noch Licht ausfallen darf nur weil z.b. Router, Switch, oder der Raspberry defekt sind ;) ich mein ja Hassio Backup ist auf einem Raspberry eh in minuten wieder eingespielt, aber das will ich eben nicht im finstern machen müssen. |
||
|
||
|
Hab den x1 auch wegen der schnellen leichte app bedienung und alle wichtigen Logiken laufen da drauf auch schnell und sicher. So sicher ist mein Edomiserver nicht. Da ist die Platte letztens eingangen und das Ding ist jeden 2tag dadurch abgstürzt |
||
|
||
|
Sehe das ganauso. Die wichtigen Logiken laufen darauf und für die App ist für die Standardbedienung schon praktisch und danke S1 auch von überall. Weiters benütze ich den X1 auch gleich als Gateway, für die Broker, usw... Man muss ja auch nicht switchen. Die Visu über einen Broker wird alles beinhalten was auch die X1 Visu kann + ein paar spielereien. Laufen wird dass dann über ein Tablet oder vielleicht auch mal mehr. Fällt mir mein Broker aus kann ich noch immer die Grundfunktionen wie Licht und Raffs über das Gira App bedienen und auch die Logik für die Raffs und Aussenbeleuchtung läuft weiter. |
||
|
||
|
Ich habe bisher noch keinen Bedarf für KNX-Logiken. Außer ob alle Fenster geschlossen sind, was der Binäreingang von MDT aber direkt anbietet. Könnt ihr mir mal Bsp. geben, was ihr damit so macht? |
||
|
||
|
also bei mir gibts dämmerungslogiken,... Wind und Wetter Logiken, Automatische Tag/ Nacht Dimmwerte für Handläufe und Spots mit Bewegungsmelder usw.. wird immer mehr.. Das komplizierte läuft am Edomi, wie Denon Steuerung, vor allem mit MDT oder Gira Taster im Bad. Influx, Pool, USV usw usw, Alarmweiterleitung und und und |
Beitrag schreiben oder Werbung ausblenden?
Einloggen
Kostenlos registrieren [Mehr Infos]