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
0Teilnehmer
Freue mich über Euer Feedback und regen Teilnahme
Heiko
Interessante Diskussion. Ich habe den symcon Komfort gewählt. Denn wenn ich die arbeit auf den user schiebe, kann ich
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.
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.
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.
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.
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
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.
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…
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?
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.
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.
.
.