Digitalstrom facebook Gruppe

Im facebook gibt es eine aktive Digitalstrom User Gruppe. Da dort auch dS Angestellte offiziell teilnehmen, ist die Gruppe empfehlenswert. Ich habe dort mein IP-Symcon Projekt vorgestellt. Diesen Text möchte ich auch hier publizieren. Er ist geschrieben für Leute, welche noch nichts über IP-Symcon gehört haben. Die die auch auf beiden Hochzeiten (dS und IPS und facebook) tanzen können sich auch einmal in dieser dS facebook user Gruppe melden zu meinem Beitrag. Ich bin dort noch ein einsamer Wolf.

Wöchentlich wird hier nach Alternativen es zu den dS-Apps gibt? Einige von uns verwenden App x und posten: „App x ist super.“ Man erhält zwar wöchentlich ein update dieser App-Liste; mehr weiss aber man nicht. Häufig genannt wird: OpenHab, FHEM, IP-Symcon, Mediola, Arnido, Eisbär Scada, Sarah (und Sven). OpenHab und FHEM sind gratis Produkte. Sarah war bis vor kurzem das teuerste. Inzwischen ist Sarah etwas weniger teuer. Es ist auch klar, dass wenn jemand sich in App x eingearbeitet hat, dass dann automatisch App x unschlagbar ist. Meist vergeudet man viel Zeit in die Einarbeitung und in das Einstellen dieser App. Dazu investiert man zudem eine Menge Geld. Kaum einer kennt gar zwei oder drei dieser Apps. Sie sind auch sehr unterschiedlich in der Programmierung. Entsprechend hofft jeder natürlich, dass seine Wahl zum Marktführer avanciert. Als logische Konsequenz dieser Entwicklung erhofft man sich eine Weiterentwicklung dieser App. Vor zwei Jahren entschied ich mich für IP-Symcon. Ich erlaube mir heute ein etwas längerer Bericht darüber zu schreiben. Ich versuche ein relativ neutraler Standpunkt einzunehmen Gleichfalls hoffe ich für Nachahmer-Redaktoren. (Artasches Guber-Gorgojan hat am 6. März beispielsweise viele Screenshots seiner „Sven-App“ gemacht) Ich verspreche im nächsten halben Jahr dann nur noch auf diese Publikation zu verweisen. Korrekturen und Updates zu meinem Wissen sind gerne willkommen. Ebenso Tipps zur Verbesserung meiner Rückkanäle. Damit mein Beitrag für eine breite Leseschaft verfügbar ist, verlagere ich technisches Hintergrundwissen in den Appendix.
Am 18. Juni 2016 habe ich in diesem Forum zum ersten Mal die positive Verwendung von IP-Symcon beschrieben. Seither ist auch bei mir einiges dazugekommen.

Zielpublikum
Es gibt zwar eine erstaunlich grosse Menge an User von IP-Symcon, die wenig bis keine Programmiererfahrungen haben. Trotzdem sind die meisten Kunden für Programmierung offen. Bis man sein Projekt auf meinem Level hat, muss man sicher 100h Arbeit investieren. Ich bin kein Webentwickler noch ein Webdesigner. Diese sind natürlich schneller in der Entwicklung. Alle anderen sollten aber schon diesen Zeitaufwand einplanen. Mein Projekt verhält sich ähnlich zu einer Kathedrale. Fertig ist das Projekt nie. Man möchte es ständig verbessern. Am Anfang kannte ich noch „fast“ keine php. Auch heute komme ich ohne den regelmässigen Besuch von PHP: Hypertext Preprocessor nicht weit. Für Nutzer, welche nie zufrieden mit einer App sind, empfiehlt sich IP-Symcon. Man ist nicht von der Weiterentwicklung der Urentwickler abhängig. Insofern kann IP-Symcon zum Hobby werden. Wer innerhalb eine Stunde ein funktionierendes System haben möchte ohne je eine Bedienungsanleitung lesen zu müssen, ist mit einigen der Konkurrenzprodukte wahrscheinlich besser bedient. Die technischen Möglichkeiten sind meiner Meinung nach in keinem Konkurrenzprodukt auch nur annähernd vorhanden. Die Anzahl Bausteine, die IP-Symcon hat, ist erstaunlich klein. Diese Bausteine sind aber extrem flexible. Es gibt beispielsweise nur 4 verschiedene Variablen (boolean, Integer, floor und string). In einen String kann man jedoch problemlos ganze Datenbanken, komplizierte Array oder HTML-Boxen packen. Technisch einigermassen mithalten kann wahrscheinlich nur OpenHab. OpenHab hatte vor Version 2.0 noch überhaupt keine grafische Benutzeroberfläche. Entsprechend vermute ich noch Aufholpotential von OpenHab. Lasse mich gerne vom Gegenteil hier mit Screenshots überzeugen.

Kosten
IP-Symcon ist eine Bezahl Software. Es gibt auch eine gratis Demo Testversion. Die Basic Lizenz kostet 100 EUR. Wahrscheinlich brauchen früher oder später die meisten das Upgrate zur Professional 250 EUR. Ich empfehle 250 Euro zu budgetieren. Anfangen kann man jedoch mit der Basic Lizenz. Ein Hausautomationsserver sollte 24h in Betrieb sein. Entsprechend ist ein PC vom Stromverbrauch ungeeignet. Entweder hat man einen RaspberryPi ca. 30 Euro oder man kauft eine Symbox für 300 EUR. Von der älteren Version dieser Box weiss man, dass die Symbox sehr ähnlich zu einem RaspberryPi ist. Wer sich nicht scheut vor ein bisschen Linux, kauft entsprechend nur den Raspberry Pi. PuTTY und WinSCP erlauben inzwischen eine konfortable Bedienung des Raspberry in Windows.
Ich habe die Installation geschafft ohne Linux Erfahrungen. IP-Symcon hat angekündigt im Sommer dieses Jahres eine Version für eine Synology NAS anzubieten. – Das wird sicherlich ein grosser Fortschritt. Die Schwachstelle beim RaspberryPi ist die Magnet Speicherkarte. Ein RaspberryPi startet über diese Magnet Speicherkarten. Wenn gerade während eines Schreibprozesses ein Stromunterbruch passiert, kann die ganze Magnet Karte kaputt gehen. Von Zeit zu Zeit sollte man entsprechend eine Sicherungskopie auf eine externe Festplatte machen. Ist eigentlich keine grosse Sache. Man muss es aber von Hand machen und dabei zuerst die Software mit allen Prozessen schliessen und danach wieder starten. IP-Symcon macht täglich um 24 Uhr eine Sicherheitskopie während des Betriebes innerhalb des Raspberry Pi. In diesem periodischen backup werden aber Medien nicht mit einbezogen. Vom Raspberry Pi hinaus wird keine automatische Sicherungskopie gemacht. Diese muss man eben von Hand machen. Auf einer Synology kann die Sicherungskopie ständig gemacht werden. Sogar auf eine zweite Synology an einem anderen Standort.
Die IP-Symcon ist die technische Zentrale. Man kann über funktionale gratis Apps auf dem Mobil oder einem Internet Browser das System bedienen. Wer jedoch eine grafische Bedienoberfläche wünscht, kauft für 100 EUR eine Fremdsoftware als add-in genannt IPS-Studio.
Wer Fernzugriff auf seine Haussteuerung haben möchte, kauft noch eine Subscription für 40 Euro/Jahr. In dieser Subscription sind die Software updates enthalten.

Stärken
IP-Symcon läuft sehr stabil und lässt sich einfach installieren. Man liest kaum von Problemen anderer User. Ebenso problemlos verliefen in der Vergangenheit updates. OpenHab und FHEM haben hier einen schlechteren Ruf. Eine Schwachstelle, welche häufig gratis Produkte haben. Die Community von Programmierfreaks hat vermutlich OpenHab gefolgt von FHEM die grössten. Dies ist auch typisch bei gratis Programmen gegenüber Bezahl Software. Danach folgt nach meinem Empfinden die Community von IP-Symcon. OpenHab und IP-Symcon sind sonst sehr ähnlich. Hauptunterschied ist, dass OpenHab auf Java basiert und IP-Symcon auf php. Ich vermute, dass ein Projekt in OpenHab oder FHEM länger dauern als in IP-Symcon. Man spricht etwa von einem Faktor 2 in Bezug auf Aufwand. Screenshots sieht man entsprechend von sehr wenigen Anwendern. Alle Produkte haben irgendwo Ihre Grenzen und lassen den Aufwand kaum begrenzen. Die Daten sind zu Hause von einem Server und nicht in einer Cloud.

Mein Gebrauch
IP-Symcon kauft ich mir primär mich für eine grafische Visualisierung. Jegliche Hausautomation, welche man in dS machen kann, mache ich weiterhin in dS. dS hat aber noch Limiten. Die Lüftungssteuerung ist noch sehr basic. Sehr viele Fachmänner empfehlen die Verwendung von absoluter Feuchtigkeit der Luft. Die dS Sensoren kennen aber nur die relative Feuchtigkeit und die Temperatur. Aus der Temperatur, der Relativen Luftfeuchte und dem Luftdruck, kann man die Absolute Luftfeuchte berechnen. Eine solche Umrechnung ist nur elementare Algebra; übersteigt jedoch bei weitem die Möglichkeiten von dS. Hier kann IP-Symcon auch dS unterstützen. Hier übernimmt dann die IP-Symcon die Hausautomation.
Eine weitere Anwendung ist der Thanos. Standardmässig kann der Thanos nur Sonos bedienen. Mit dem SceneResponder und dessen url-Aufrufe, kann man auch andere Musiksysteme steuern. Zur Veränderung der Lautstärke verwendet Thanos die Dimm Stimmungen (Szene 11 und 12). Der SceneResponder kann aber in der heutigen Konfiguration nicht auf diese Szenen reagieren. Hier spring bei mir dann auch die IP-Symcon ein.
Im Sommer benutzt man gerne die Rollläden um das Innere eines Gebäudes kühl zu behalten. Im Winter möchte man aber gerade Sonnenstrahlen durch die Fenster lassen um Heizkosten zu sparen. Sobald man sich damit auseinandersetzt, braucht man schnell Kerngrössen wie, Sonnenstand und durchschnittliche Strahlungsstärke während der letzten 15 Minuten. (Wenn man nicht einen Durchschnitt über eine Zeitperioden wählt, würde bei jeder kleinen Wolke die Rollläden ständig hinauf und wieder hinunter gehen). Auch hier ist das Latein von dS erreicht. Ich hoffe, im Sommer kann ich dann auch hier positive Erfahrungen erhalten.
Bis jetzt konnte ich mich nicht motivieren, mich in HighCharts einzuarbeiten. Auch dies kann man machen. Highcharts demos | Highcharts Da bei mir aber der Kochherd, Backofen und Heizungsbrenner über keinen dS-Meter laufen, sehe ich nicht den ganzen Stromkonsum. Da ich bis jetzt kein EnOcean Gateway kaufte, brauche ich es auch jetzt noch nicht. Wozu soll ich auch einen Sanitärinstallateur beauftragen, eine Wasseruhr einzubauen? Meine alte Heizung zeigt den Heizölverbrauch auch nicht an. Das einzige was ich habe sind Temperatur, Luftfeuchte und Stromverbrauch.
Die Entwicklung einer Nachgebauten Fernbedienung für den Fernseher habe ich bis jetzt immer verschoben. Irgendwie bevorzuge ich eine haptische Fernbedienung gegenüber einer App auf einem smart Phone. Obwohl IPS Studio mittlerweilen auch Fibrationsrückmeldungen machen könnte. Zudem fand ich im Internet noch keinen publizierten Hack für einen Rückkanal, welcher für meinen Samsung Fernseher des ES Jahrganges möglich ist.

Schwachstellen
IP-Symcon ist kein Produkt für Digitalstrom. Es ist ein Produkt, welches auch Digitalstrom verarbeiten kann. Die dS Community innerhalb IP-Symcon ist sehr klein. Als kleiner Vergleich: Das Unterforum Digitalstrom von IP-Symcon-Forum hat 90 Beiträge, während HomeMatic 2000 Beiträge zählt. 1-Wire MBus hat 860 Beiträge, Z-wave hat 660 Beiträge, KNX hat 560. Es versteht sich von selbst, dass das Entwicklungsbudget zu ungunsten von dS aufgesetzt wird. Sarah war früher exklusiv für dS. Inzwischen hat sich dies aber auch geändert. Hubware macht inzwischen auch KNX Projekte. (Vermutlich nicht nur aufgrund der zukünftigen Schnittstelle KNX-dS). Ein Business Case mit nur dS-Kunden funktioniert wahrscheinlich nicht.
Ein entscheidendes Manko von IP-Symcon ist beispielsweise der fehlende just in time Rückkanal von Benutzerdefinierten Zuständen. Das wäre technisch einfach umsetzbar. Mit einem sehr ähnlichen Trick könnte man auch den unmittelbaren Rückkanal für Temperatur Sensoren implementieren. Momentan steht aber die Portation auf die Synology an oberster Stelle.
In IPStudio kann man beispielsweise zwischen Hoch- und Querformat wählen. Ein automatisches Verlinken dieser beiden Views ist noch nicht integriert. Ebenso eine automatische Umschaltung Intranet oder Internet auf dem Mobil. (Die Auflistung eines solchen Mankos zeigt klar meine Zufriedenheit.)

Eigenes Fazit
Der Zeitaufwand ist hoch. Man soll sich gut überlegen, ob man nicht auf ein Standard Produkt wie Sarah zurückgreifen möchte. Vor Kurzem kostete Sarah 3‘200 CHF plus. Dies war über meiner Schmerzgrenze. Wenn ich meinen Aufwand mit meinem Stundenlohn vergleiche, wird es kompliziert. Diese 100h sollte man vielleicht lieber der Familie schenken. Man darf aber auch den persönlichen Lerneffekt eines solchen Projektes nicht vergessen. Es ist schon fast peinlich, dass ich mich bis ins Jahr 2016 nie mit dem Gestalten einer Homepage oder App befasst habe. TCP/IP und HTML sah ich immer irgendwo geschrieben. Inzwischen weiss ich dank diesem Projekt einiges mehr. Die Kosten der IP-Symcon sind zwischen OpenHab und Sarah. Der Zeitaufwand vermutlich aber auch irgendwo dazwischen.

Appendix
Rückkanal
Bei der Markteinführung von Digitalstrom wurde der mangelnde Rückkanal von der Fachwelt bemängelt. Das dS Marketing hat dieses Fehlen stets als unbedeutend in der Anwendung klassifiziert. KNX Fans verspotten dS deshalb. dS gilt als teures Gadget für den homebedarf, dass in einem professionellen Gebäude Management nicht einführbar ist ausser irgendwelche Heimatschutz Gebäude. [DS ist Gadget für den grossen Geldbeutel. Profis bevorzugen aber KNX]
Es ist relativ einfach z.B. mit Logitech Harmony ein Gerät zu steuern. Viel komplizierter ist es, den Zustand des Gerätes zu kenne. Dies ist der Rückkanal. Nur die ganz teuren z.B. B&O Fernseher teilen Ihrer Fernbedienung mit, welcher Kanal gerade geschaut wird. Eine solche Fernbedienung kostet aber 1‘000 CHF. Es gibt verschiedene Methoden und Tricks einen solchen Rückkanal zu erstellen. Ebenso gibt es verschiedene Güten dieser Information. Die einfachste Methode ist ein Strommeter in Form eines Zwischensteckers dazwischen zu hängen, der dann Rückmeldet, ob Gerät x Strom isst oder nicht. Meines Wissens kann das dS bis jetzt nur über die EnOcean-Geräte machen. Dummerweise verbraucht ein abgestürzter PC häufig mehr Strom als im Standby. Sehr zuverlässig ist eine Messung des Stromverbrauches nicht immer. Schon wesentlich komfortabler sind Geräte, welche eine API haben. Hier kann man durch periodische Abfragen, den „aktuellen“ Status des Gerätes abfragen. Mein Yamaha Surround Receiver, Mährroboter, Telefon und Türstation haben diese Möglichkeit. Bei einer solchen Abfrage muss man zwingend die Abfragezeit berücksichtigen. Wenn die Abfrage 2 Sekunden dauert und man jede Sekunde eine solche Abfrage losschickt, stürzt das System in naher Zukunft zusammen. Digitalstrom hat bekanntlich diese Funktionalität einer API auf dem Server. Man muss aber berücksichtigen, dass bei mir eine solche Abfrage (file_get_contents … apartment/getDevices) fast 5 Sekunden dauert. Dies ist bei mir sicher verschuldet, da ich über 100 Klemmen verwende und noch den alten dS Server dSS11-1GB betreibe. (Bitte rückmelden, wenn der neue dSS20 schneller ist). Viel Zeit nimmt dabei das Einloggen mit der Token Abfrage in Anspruch. Solange der Token noch gültig wäre, könnte man eine weitere Abfrage schneller durchführen. Leider sind in dieser JSON Datenbank jedoch nicht alle Informationen enthalten. Der Zustand einer Klemme (z.B. GE-KM200) sieht man nicht. Man kann einzig den Server beauftragen, den Zustand der Klemme nachzufragen. Eine solche Abfrage dauert bei mir 5 Sekunden. Natürlich wieder 2 Sekunden für den Token login. Meines Wissens kann man eine solche Abfrage nicht parallel durchführen. Kurzum ein Rückkanal auf Geräte Ebene muss man sich anders bauen. Bei IP-Symcon ist dies über die last Szene im Raum. Vereinfach gesagt wird die LastCallScene protokolliert und beinahe „just in Time“ geliefert. Nur anhand der LastCallScene lässt sich in vielen Konfigurationen der Status einer Lampe nicht berechnen. (Angenommen man hat zwei Lampe im Raum, Scene 1 Lampe 1 ein und Lampe 2 nicht beeinflussen. Scene 2 beide Lampen ein. Aufgrund der Meldung Scene 1 weiss man nicht, ob Lampe 2 brennt. Falls vorher Scene Aus galt, brennt die Lampe 2 nicht. Falls vorher Scene 2 war, brennt Lampe 2.) In all meiner Konfigurationen, kann man den Zustand von Raum- und Bereichsklemmen jedoch aufgrund der vollständigen auflisting der lastCall Szene stets berechnen. Dasselbe gilt auch für Schatten. Die „just in Time“ Philosophie muss man jedoch aufgeben, sobald man lokal dimmt oder noch schlimmer, mit dem dS-API-Befehl „HTTP SET /json/device/setOutputValue“ kann man diesen Retourkanal austricksen. Da die wenigsten Benutzer im Haus diese Befehle verwenden, kann ich mit dieser Inkonsistenz leben. Der Rückkanal mit Hilfe der last Scene ist verhältnismässig schnell. Eigentlich fast „just in time“. dS verbraucht 250ms zum Auslösen und mein RaspberryPi wiederum 80ms bis der Wert updated wird.
Eine andere Möglichkeit für einen Rückkanal ist neuerdings der Scene Responder auf Geräte-Ebene. Dies empfehle ich höchstens bei Gerätetastern. Ueber ein url Aufruf starte ich ein php-Skript von einem Drittserver, welche dann über die JSON-RPC Schnittstelle der IP-Symcon deren Datenbank verändert. Zum einen braucht der Szene Responder in dS über eine Sekunde an Reaktionszeit. Zudem ist man auf einen dritten Server angewiesen, welcher auch wieder seine Reaktions- und Verarbeitungszeit benötigt. Entsprechend bevorzuge ich die Methode von Raum- und Bereichstaster. Dummerweise spielt einem der Thanos einen Strich, da dieser „nur“ Raumtaster auf der Hauptseite bedient. Bis jetzt bin ich vermutlich der einzige, welcher sich hier über diesen Zustand des Thanos beschwert. (Angenommen zuerst schaltet ein Gerätetaster das Gerät ein. Danach schaltet ein Raumtaster das Gerät wieder aus und schreibt in der Datenbank Gerät aus. Erst jetzt danach schreibt man durch den Scene Responder ein. Schon hat man einen Fehler in der Datenbank).
Meine Musikanlage Voxnet von Revox hat noch eine dritte Methode des Rückkanals. Man kann einstellen, dass bei Statusänderung sofort von einem Port die neue Status Anzeige an IP-Symcon verschickt wird. Diese Methode ist natürlich mit Abstand die Komfortabelste.

Gesendet von meinem SM-G900F mit Tapatalk

Mini-Fehler: IP-Symcon basiert auf C++ und beinhaltet für eigene Skripte PHP :slight_smile:

Ansonsten toller, ausführlicher Text und vielen Dank für die Blumen! Wir haben für die Zukunft auch so einige Update zu dS auf der Roadmap und ich kenne auch ein paar dS Fans in meinem Freuendeskreis. Hast du vielleicht den Facebook Link parat? :slight_smile:

paresy

digitalSTROM User Group