Konfiguration: Symcon vs. Home Assistant

[pitti]

Liebe Symcon-Nutzer,

in einigen Beiträgen wird Home Assistant als leuchtendes Beispiel für eine schnelle und weitreichende Integrationslösung gepriesen. Dass Symcon hier hinterherhinkt, ist wohl unbestritten. Ich gebe zu, dass ich selbst noch kein HASS-System aufgesetzt habe und mein Wissen lediglich aus umfangreicher Internetrecherche und dem offiziellen Internetauftritt von Home Assistant stammt. Ich gestehe auch offen, dass ich mich bei meinen Modulen gelegentlich von Umsetzungen in HASS inspirieren lasse. Als jemand vom Fach kann ich solche Ansätze schnell abstrahieren und in PHP umsetzen.

Wenn ich den Aufwand für die Konfiguration ins Verhältnis zur reinen Funktionalität setze – insbesondere bei Modulen mit Kommunikation via API/REST/JS usw. –, dann ist dieser bei Symcon enorm. Man muss sich mit Tokens, Sessions, Cookies und verschiedenen Authentifizierungsmechanismen herumschlagen, teilweise sogar extremes Reverse Engineering betreiben, nur um die Setup-Daten eintragen zu können. Die spätere Datenabfrage benötigt dann meist nur noch einen Bruchteil der Implementierungszeit – oft reicht ein einziger Aufruf mit Übergabe der Setup-Daten, gefolgt von der Auswertung, Formatierung und Speicherung in Statusvariablen. Grundsätzlich finde ich dieses Vorgehen aber passend zum Konzept von Symcon, da es volle Möglichkeiten zur dynamischen Konfiguration bietet.

Bei HASS hingegen muss der Endnutzer die benötigten Daten selbst zusammensuchen und in einer YAML-Datei (Textdatei) hinterlegen – und das war’s. Das bedeutet, dass der gesamte Aufwand, wenn überhaupt, beim Nutzer liegt, während der Entwickler der Integration lediglich die Abfrage umsetzt.

Nun zu meiner Frage: Wie seht ihr das?
Gerade bei meinem Abfallwirtschafts-Modul könnte ich auf diese Weise eine deutlich höhere Geschwindigkeit realisieren, allerdings ginge dabei auch der Komfort für weniger technikaffine Nutzer verloren.

Ich bin gespannt auf eure Meinungen und starte daher diese Umfrage …

• weiterhin den Symcon-Komfort von Konfigurationsformularen nutzen und anbieten
• gebe lieber meine Daten direkt ein und im Fehlerfall bin ich selber schuld
• ist mir egal, Hauptsache viele Integrationen

Freue mich über Euer Feedback und regen Teilnahme
Heiko

[kris]

Hi,

Interessante Diskussion. Ich habe den symcon Komfort gewählt. Denn wenn ich die arbeit auf den user schiebe, kann ich

1. mich vor supportanfragen kaum retten,
   2.gleich zu homeassistant wechseln

Das hier module fehlen liegt daran, das hier überwiegend endanwender sind und es hauptsächlich auf DACH beschränkt ist. Zudem kostet der einstieg geld.

Da es zuhauf kostenlose alternativen gibt (openhab,fhem, ha, iobroker etc) ist es eher schwer mit einem kostenpflichtigen Grundprodukt die Masse anzulocken.

Andererseits müssen die symcon jungs/mädels aber auch was essen und miete zahlen. Das geht mit kostenlos nicht.

Und das Risiko einzugehen, zukünftig durch connect, div. Module und support leben zu können muss man sich auch erstmal trauen können.

Viele grüsse

[Senior]

Die meisten, mir bekannten Nutzer von Symcon, wollen das System für die Home-Automation nutzen und nicht für jede neue Hardware stundenlang im Internet rumsuchen damit die Geräte und/oder Funktionen zur Verfügung stehen. Ich denke, dass Symcon auf dem richtigen Weg ist.

[bbernhard]

Servus
Ich habe mich auch für den Komfort entschieden, weil das ist ja genau der Sinn der Module.
Wenn für eine Integration tiefer einsteigen müßte dann tu ich mir (evtl. Beschränkungen) eines Modules gar nicht erst an sondern schreibe gleich selbst eins Script. Dann hab ich gleich alles so wie ich es mir wünsche.

Schlimmer wird es aber bei den Kacheln. Das ist mir und offensichtlich vielen anderen eindeutig eine Nummer zu hoch sowas vernünftig zu hinzubekommen.

greez
bb

[BlackOrca]

Naja Es gäbe ja noch Nummer 4. Symcon muss das Erstellen der Konfigurationsseiten vereinfachen. Ganz ehrlich dieses Drama für dynamische gestaltete Eingabefelder mit json hier dann wieder zurück das ist alles total schön generische aber am Ende ist das was mich davon abhält mich auf die nächsten Module zu stürzen.
Ich verstehe aber auch wenn symcon da nicht ran will, denn das ist keine Besserung für die endnutzer, sondern nur für die modulentwickler.
Deswegen machen ich dann eher ein script für mich und die Symcon Gemeinschaft geht leer aus.

Gruß BlackOrca

[kris]

Und scripte kann man nicht an die gemeinschaft weitergeben weil? Ging, bevor es php module gab, auch

[paresy]

Wie würdest du es denn vereinfachen? Hast du eine coole Idee wie wir es einfacher machen könnten?

Ich ärgere mich da ab und zu auch, dass es manchmal zu kompliziert ist. Aber noch hatten wir keine coole Idee wie man sagen wir mal das meiste schafft - aber trotzdem einfacher hinbekommt.

Mach am besten ein neues Thema auf und bring uns Input - wir sind da immer offen für clevere Verbesserungen

paresy

[BlackOrca]

Hallo parsey,
Ich bin kein System architekt und ich kenne PHPs Fähigkeiten nicht aber ich orientiere mich jetzt mal an dotnet und mit der Oberflächen Beschreibung xaml. Ich rede auch nicht von MVC oder MVVM.
Es geht nicht um die Syntax, ich bin ein Fan von Json.
Es geht um die Möglichkeit das alle UI Elemente verschiedene Events feuern können. So klassische dinge: OnButtonClick, OnButtonRelease, OnGotFocus, OnLostFocus, TextEntered, OnSelected, OnUnselected, etc. Diesen Events kann man Methoden in der module.php übergeben. (geht ja schon im Action Bereich)
Eventuell mit entsprechenden args die Infos über das UI Element welches gefeuert hat mit übergibt um Methoden für mehrere UI Elemente nutzen zu können.
Dann kann man in der Methode darauf reagieren und z.B. ein Propertie eines anderen UI Element z.B. die Visibility, Farbe, Text, Caption, Typo, etc. setzen.
Jetzt kommt die nötige symcon Magie dazwischen die das managed. Sprich symcon ändert das Propertie in der json und sagt der UI das die neue json gerendert werden muss.
Sprich die Modul Entwickler beschreiben die Oberfläche wie gewohnt, halt mit den zusätzliche Möglichkeiten. Man verweist mit den gewünschten Events auf Methoden und kann über UI Manipulations APIs die UI verändern.
Symcon dazwischen ist dafür zuständig auf die Events zu reagieren und die Methoden aufzurufen und die gewünschten Änderungen wieder an die UI zu geben (sprich die json Manipulation)

In der json sind 2 Sektionen eine auf Visibility false und eine auf true.
Man hat 2 Radio Buttons. Man registriert auf einem der beiden dann OnSelected auf die Methode ModusSelected()
In der Methode ruft man irgendwas Forms.Visibility(name or ID, true)
Das setzt Symcon um. Setzt die Visibility des gewünschten Elements auf true und rendert das.
Kein json_decode dann darin rummachen und dann wieder json_encode.

Zusätzlich die Möglichkeit in der eventbeschreibung „basic Möglichkeiten“ gleich zu übergeben. Event=„SetVisibility(Name ID)“
So gäbe es die Möglichkeit ohne eine eigene Methode zu schreiben basics direkt zu nutzen.

Wie das im PHP Universum funktionieren kann da bin ich kein Fachmann und wie es in eurer Programm Logik ausschaut weiß ich nicht. Mir ist bewusst das das aufgeführte ein Schwergewicht ist.

Dann das Tooling. WYSIWYG Erweiterung für VS Code ist sicherlich nicht möglich. Aber wie wäre es langfristig in symcon eine Modul Entwicklungs UI zu integrieren. Dort sind die renderlogic vorhanden. Ihr habt schon einen Script Editor mit Intelisense.

Ich hoffe das ich als nicht Informatiker hier nicht schwachsinn runtergeschrieben habe.
Ich habe mir das Programmieren C#, dotnet seit über 10 Jahren mit 1000en Stunden YouTube erlernt. Mit PHP habe ich mich nur für symcon beschäftigt.

Schönen Abend
BlackOrca

[da8ter]

Die Konfiguration zu vereinfachen würde auf jeden Fall die Einstiegshürden drastisch senken. Ich bin auch kein Informatiker sondern eher ein visueller Mensch und tue mich sehr schwer dabei mir diese abstrakten Datenflüsse visuell vorzustellen wie wo was welche Daten verarbeitet, zwischengespeichert etc. werden. Wenn ich mir das an einer Wand aufzeichnen würde sähe das vermutlich so aus:

Ich würde gerne meine HTML Kacheln weiter optimieren und für den User flexibler konfigurierbar machen. Bekomme aber schon beim drüber nachdenken wie das mit den Formularen laufen könnte ein Gehirnaneurysma. Da hab ich momentan einfach keine Zeit für mich da weiter reinzufuchsen…

Ne Lösung hab ich natürlich auch nicht parat.

Viele Grüße
Stephan

[pitti]

Einen visuellen Konfig-Editor wäre ne wahnsinns Sache. Habe ich schon oft im Kopf gehabt.
Wollte ich sogar mal als Programm angehen, aber nie dazu gekommen. Gehen müsste es ja, IPSView kann das ja zum Teil auch. Aber da braucht man wahrscheinlich Zugang zur internen Entwicklung von Symcon.

Was zudem nervt ist die Adressierung der Elemente über Indizes, also item[0].value[1] oder so. Wenn man dann später das Formular erweitert muss man durch den Code gehen und alles anpassen. Ich mach das schon meistens mit Konstanten, aber richtig dolle ist dass nicht. Könnte man das nicht irgendwie über den Namen oder sonst wie adressieren?

Gruß HEiko

[kris]

@pitti

Einen visuellen Konfig-Editor

Das wäre echt eine coole sache. Alleine das suchen nach den guid für io instanzen ist schon grausig, nur weil man den bspw für den mqtt server braucht. Wie pitti schon schreibt, das ansprechen über indizen ist auch unschön.

Im konfigformular eine option dazwischenfügen und man ist ewig dran das zu ändern.

[pitti]

Vielen Dank für die zahlreiche Teilnahme an der Abstimmung und das wertvolle Feedback .
Das Ergebnis zeigt eine klare Präferenz für das etablierte Konzept .

Ich hoffe, dass die daraus entstandene Diskussion konstruktive Impulse für IPS liefert und der Fokus erhalten bleibt und nicht bei den vielen Themen untergeht.

Gruß Heiko

[Ghostraider]

Ich bin erst seit gut 2 Monaten symcon User und noch mitten in der Migration von MyHomeControl welches ich 7 Jahre im Einsatz hatte.

Bevor ich den Weg zu symcon gefunden habe, hatte ich etliche Anläufe mit HomeAssistant. Die Tatsache dass ich nun symcon nutze ist unter anderem der Situation geschuldet dass es mir mit Home Assistant und der umfangreichen konfigurieren via YAML nicht gelungen ist meine Hardware anzubinden.

Bei Symcon waren nach wenigen Stunden nahezu alle Geräte rudimentär verbunden.

Der wechsel von MHC zu Symcon ist dennoch eine deutliche Umstellung. MyHomeControl war 100% NoCode, wohin gehen Symcon eine Mischung aus No und LowCode ist.

Abhängig von der Zukunftsvision von Symcon ist der weg zur NoCode bzw. LowCode Plattform sicher der richtig wenn man auch nicht versierte Anwender abholen möchte die vlt. mit den Bordmitteln von z.B eine Phillips HUE oder Alexa Anbindung nicht mehr zufrieden sind.

Ich für mein Teil (als nicht Entwickler) Versuche so viel wie möglich mit den Logikplänen zu bauen. Alles was damit nicht geht muss ChatGPT mit einfachen PHP Scripten regeln

Vielleicht lässt sich damit auch etwas machen und einen KI Assistent einbauen zur Erstellung einfacher Scripte basierend auf einem prompt vom Anwender.

[habre]

Erstmal herzlich willkommen !

@Ghostraider

wohin gehen Symcon eine Mischung aus No und LowCode ist.

Für den geneigten Leser möchte ich schon anmerken dass es sich der Anwender eigentlich aussuchen kann.

• NoCode
• LowCode
• aber auch volle Programmierbarkeit mittels PHP - und dann ists kein LowCode mehr. Da kannst du dich voll austoben.

[teebeutel]

Ich habe mir zu dem Thema Bedienung und Konfiguration in Symcon einige Gedanken gemacht. Allerdings nicht aus der Sicht eines Modulentwicklers, sondern aus meiner Usersicht.

Ich bin zwar ITler, allerdings ist Programmieren nicht mein Steckenpferd. Begonnen habe ich mit Symcon im Jahr 2010, damals war 2.1 die aktuelle Version. Die Programmierung lief fast komplett auf PHP Basis, und als View hatten wir das Dashboard. Das war aber damals schon auf der Abschussliste, das Webfront war gerade neu und wurde von vielen als die beste View angesehen. Auf der legendären Steiner-Gartenparty habe ich darüber auch mit @Paresy diskutiert. Aber letztlich ist das Dashboard still und heimlich begraben worden.
Einen Ersatz gab es erst mit dem IPS View von Brownson. Dieser hat dann auch die Workflows gebaut, die ähnlich wie die Programmierung von Codesys 2.3 aufgebaut ist.

In den letzten Jahren ist dann die Modulentwicklung entstanden. So langsam werden die PHP Scripte wohl zum größten Teil damit ersetzt werden.

Für mich hat sich die Situation insgesamt nicht viel verbessert. Bei den PHP Scripten konnte ich noch ein wenig basteln, wenn etwas nicht funktioniert hat. Nachteilig finde ich, wenn MOdule oder Scripte Webfrontoptimiert sind, also am Ende eine html Seite in einer Variable alle Daten enthält. Diese kann ich in Ipsview meisten nicht sinnvoll nutzen.

Ein Beispiel dafür ist der Kalender. Ich möchte alle Termine als Liste auf dem Bildschirm in der Küche darstellen, aber ich bekomme es mit dem Kalendermodul nicht hin. Oftmals ist auch dei (aus meiner Sicht) unvollständige Dokumentation mein Problem. Viele Punkte dort sind mir unklar, da mögliche Parameter nicht beschrieben sind, oder es gibt keine Beispiele, wie das ganze angewendet wird. Ein Beispiel dafür ist AC_GetLoggedValues, es gibt etliche Parameter, aber ich weiss nicht wie sie lauten oder wo ich sie nachschlagen kann.

Ein wirklicher Gewinn ist aus meiner Sicht die Einführung der Logikpläne bzw. Workflows. Am Anfang habe ich mich schwergetan, die Symcon-Videos haben mir aber gehlfen, das Thema zu verstehen, Wobei auch hier die Dokumentation nur lückenhaft ist, und die alte 6.0er Doku bei Brownson enthält keine Beispiele und ist wahrscheinlich auch nicht mehr aktuell.

Was dabei wirklich helfen würde, wäre ein Bereich, in dem Workflowvorlagen abgelegt werden können, sowie vollständiger Dokumentation dazu.
Für die Wago SPS z.B. gibt es z.B. die OScat Libraries, die sind ja im Prinzip wie die Sublogikpläne aufgebaut, und es gibt eine saubere Dokumentazion dazu:
http://www.oscat.de/de/component/jdownloads/send/5-oscat-building/25-oscat-building100-de.html

Wie gesagt, ich schreibe das hier aus Usersicht. Ich bin seit 2010 mit IP-Symcon unterwegs, und empfehle es allen meinen Bekannten, aber für die meisten ist es nicht realisierbar, da man tiefgehende Technikkenntnisse benötigt. Einige meiner Kollegen sind nach einiger Zeit zu Alternative gewechselt, meistens zu Home Assistant. Meine Subscription geht auktuell noch bis 2030, aber auch ich schiele mit einem halbe Auge auf HomeAssistant, alleine schon wegen EVCC.

Gruß Teebeutel