Anderes (internes) Handling für Variablen

Da bin ich nun auf ein recht interessantes „Problem“ gestossen.

Beispiel: Shelly Einbindung via MQTT. Instanz anlegen, MQTT-Server zuweisen, nach einer Weile befüllen sich alle Variablen. Ab da kann ich (scheinbar) in der Instanz beliebig Kategorien anlegen und Variablen dort persistent reinschieben.

Anderes Beispiel: Froggit Integration. Wenn ich da eine Kategorie anlege und erstmal Kram wie „Batterie“ oder „Modell“ reinschiebe, kommen diese Variablen beim nächsten Poll wieder direkt unter der Instanz.

Desgleichen beim Löschen von Variablen: Bei den Shellies ist diese Variable dann halt weg, bei Froggit kommt sie immer wieder.

Wäre interessant, wie man gerade das Löschen von Variablen in den Griff bekommt - nicht jeder möchte sich eine Unlimited Version hinstellen.

Bernd

Es gibt KEINE Möglichkeit die Variablen unterhalb von Instanzen zu reduzieren, wenn das Modul dies nicht SAUBER vorsieht. Ggf. erzwingt das Foggit Modul die Variablen erst beim Neustart (typisches Symcon Verhalten) und das Shelly Modul halt sobald Daten ankommen (Typisch, wenn man nicht sofort weiß, was das Gerät so unterstützt und dem Nutzer entgegenkommen will).

Es müsste ein gemeinsam abgestimmtes Vorgehen geben, wie Module damit umzugehen haben.
Aber solange die Variablenanzahl die quasi einzige Verkaufsmöglichkeit der höheren Versionen ist, ist es schon verständlich, dass seitens Symcon hier wenig kommt.

Ok, ich hab das jetzt mal gemäss Deinem Post verifiziert: Das Shelly-Plugin trägt gelöschte oder in eine Sub-Kategorie verschiebene Variablen mindestens nach einem Restart nach, das Froggit-Plugin bei jedem neuen Poll (hier: alle 60 Sekunden).

Da ich selber von Software lebe, habe ich vollstes Verständnis.

Ich habe mir die Unlimited ja auch nur aus dem Grund geholt um erstmal aus dem Vollen zu schöpfen um dann zu sehen, was ich wirklich brauche - die Anforderung an eine HA sieht man erst nach allen vier Jahreszeiten und braucht dann nochmal solange um es zu realisieren.

Was die reine Anzahl der Variablen angeht, würde eine Option „Aussschliessen“ und ein kleines rotes Kreuz davor im Objektbaum helfen - das wiederum erfordert ein Tracking über eine UID (bei den Shellies wird das mitgeliefert) und Subkomponenten.

Wenn man das hat, ist man auch gleich bei der Möglichkeit eine Variable im Frontend an eine beliebige andere Stelle im Objektbaum zu verschieben.

Aktuell behelfe ich mir da mit Symlinks um grössere Instanzen in einer „Gesundgeschrumpften Version“ abzubilden, aber anscheinend kann nicht jedes Modul Operationen auf verlinkte Variablen durchführen.

Da müsste man nochmal scharf nachdenken.

Bernd

Moin Bernd,

ich gehe davon aus dass Du mein Modul meinst, deswegen möchte ich Dir auch gerne Antworten.
Ich habe mal gelernt, Variablen gehören unter die entsprechende Instanz und nirgendwo anders hin.
Für die Visualisierung arbeitest Du dann nur mit Links.
Weil, nach vielen installierten Modulen und etwas Zeit, findest Du sonst nie etwas wieder.

Das Modul ist relativ einfach aufgebaut.

  • Daten werden empfangen
  • Das Array der empfangenen Werte durchgegangen
  • Variablen erstellt, die nicht vorhanden sind
  • Werte abgespeichert
  • Fertig.
  • Ein paar Sachen werden vorher noch umgerechnet und dazu noch ein Profil ausgewählt, aber das war schon alles.

Vorteil ist, wenn Du einen neuen Sensor anschliesst, werden die Variablen automatisch erstellt. Ohne irgendwas konfigurieren zu müssen.
Ich hatte mal die Idee, einen Schalter in die Instanz zu machen, die das automatische anlegen der Variablen unterbindet. Wenn der aktiv ist, kannst Du dann auch einzelne Variablen löschen. Bin aber noch nicht dazu gekommen.
Klar könnte man auch einen Konfigurator basteln, aber den Bedarf sehe ich nicht.
Du kannst z.b. Variablen, die Du nicht sehen möchtest, unsichtbar schalten.

Attain

Moin!

Zuerst: das war kein Vorwurf in Deine Richtung, im Gegenteil: ich bin sehr dankbar um das Modul.

Ich wollte eher ein generelles Problem ansprechen, was prinzipbedingt überall auftritt wo ganz viele Daten auflaufen.

In diesem Fall sind das knapp 80 Variablen (eine Wetterstation, ein Gateway, 8x Temperatur (je 3 Werte), 8x Bodenfeuchte (je 2 Werte)) und +2 Bildschirmseiten.

Da war meine erste Idee gewesen, den Kram über Kategorien grob zu granulieren („Wind“, „Regen“, „Sonstiges“ und die Sensoren) - das geht nicht weil die Variable dann wieder neu unter dem Root der Instanz angelegt wird.

Nächste Idee: Massenverlinkung in eine neue Kategorie und dort strukturieren. Funktioniert, dummerweise kann z.B. das Rechenmodul nicht mit verlinkten Variablen umgehen („Ungültiges Objekt“).

Da wäre jetzt eine Idee, solchen „Einlese-Modulen“ zu ermöglichen dass (vermutlich „RegisterVariable*“) auch in Subkategorien unterhalb der Instanz nachschaut, ob es die Variable bereits gibt.

Aktuell behelfe ich mir über eine sortierbare Namenskonvention - das dauert halt.

Bernd

Moin Bernd,

ich habe es nicht als Vorwurf verstanden und bin dankbar für Hinweise. Für mich ist programmieren hier reines Hobby. Ich habe es nie „gelernt“ und auch beruflich wenig damit zu tun.

Das anlegen einer Variablen unter einer Modulinstanz, ist relativ einfach und mit einer Zeile Code getan. Das sortieren in Ordnern braucht halt ein paar Zeilen mehr Code und am ende ist es sowieso falsch. Weil jeder bevorzugt eine andere Struktur.
z.b.

  • alle Batteriewerte in ein Ordner?
  • oder alle Werte zu einem Sensor in ein Ordner?

Deswegen halte ich es für mich einfach, alle Werte darunter anlegen. Du darfst es dann selber auseinander „verlinken“. :slight_smile:

Attain

Ich wäre auch lieber Gärtner oder so ähnlich :slight_smile:

Du hast mich da falsch verstanden: Es soll dem Anwender ermöglicht werden, unterhalb des Instanzen-Root selber Kategorien anzulegen und die Variablen dort hinzuverschieben OHNE dass beim nächsten Poll diese Variable neu unterm Root neu auftaucht.

Du als Modulentwickler kannst/musst da nichts machen, das wäre eine Erweiterung im Core (rekursiv nachschauen, ob eine Variable irgendwo im Baum unterhalb der eigenen Instanz existiert) + Schalter ob das auch so gemacht werden soll weil es unter Umständen nicht erwünscht ist.

Bernd

1 „Gefällt mir“

Das ist ja vom Konzept her nicht vorgesehen und eigentlich auch nicht erforderlich :wink: .

Die Struktur unterhalb der jeweiligen Instanz ist eher „Hardware“, das ist alles was da kommt und es wird in Scripten oder Abläufplänen genutzt.

Die Visualisierung erstellst du mit Links, damit kannst du sortieren und zusammenstellen wie du möchtest.

1 „Gefällt mir“

Ja nun - als Mitarbeiter der Symcon hast Du natürlich tiefere Einblicke in das Designkonzept als ich.

Meinereiner kann ja nur sehen kann „da gibt es eine Funktionalität die hier geht aber dort nicht“.

Obwohl Du selbstverständlich meine Ausführungen mit grösster Sorgfalt gelesen hast, ist Dir meine Einlassung entgangen dass das „Aufräumen“ über Links den Nachteil hat, dass jene von anderen Modulen (aufgeführt war das Rechenmodul) nicht ad hoc als Quellvariablen genutzt werden können (auch hier wieder „geht hier, geht da aber nicht“).

Bernd

Ich nutze Symcom zwar seit über 15 Jahren, aber nur privat. Wo hast du denn sorgfältig recherchiert, dass ich Mitarbeiter bin?

Links sind keine Variablen, Links können auf jedes andere Objekt verweisen und sich nicht auf Variablen beschränkt. Somit können Links keine Quelle für andere Instanzen (Module sind keine Instanzen) oder Ereignisse sein. Sie dienen in erster Linie der Visualisierung in den verschiedenen Frontends.

Das Konzept das eine Statusvariable (siehe Doku) unter einer Instanz hängt, und das immer, ist die Grundlegende Funktion von Instanzen.

Deine Ordnungsliebe im Objektbaum kannst du auch durch das sinnvolle einsortieren von Instanzen in Kategorien lösen. Für Visualisierung benutzt du dann Links. Kannst ja auch ganze Instanzen verlinken, musst dann halt die nicht gewünschten Variablen unsichtbar (also Haken bei Sichtbarkeit entfernen) schalten.

Die Frontends können keine Kategorie unterhalb einer Instanz visualisieren. Somit ist das vergeben Mühe deinerseits.

Statusvariablen dürfen nicht gelöscht werden. Diese werden spätestens mit einem Neustart vom Dienst neu erzeugt und fehlende Statusvariablen können zu Fehlern führen.

Gar nicht. Die Lizenzen haben u.a. halt das Limit der Variablenanzahl. Wenn du zu viele Variablen, also auch Geräte hast, dann brauchst du eine größere Symcon-Lizenz.

Dann verstehe ich deinen vorherigen Post nicht.

Eventuell sollten Newcomer nicht gleich mit diversen Forderungen in’s Haus fallen, sondern zuerst sich etwas mehr einarbeiten :thinking: (Meine Meinung)

Michael

PS: Nein, auch ich stehe nicht auf der Gehaltsliste von Symcon :stuck_out_tongue:

5 „Gefällt mir“

Vielen Danke für Deine Antwort, aber was hat das mit meinem Vorschlag zu tun?

Ich habe keine Forderung gestellt sondern gefragt, ob man ein Feature realisieren kann, habe begründet warum ich es für eine gute Idee halte, welchen konkreten Anwendungsfall es gibt und ein sehr grobes Konzept erarbeitet, wie es ausgeführt werden könnte.

So?
Bernd

Es gab in Deinen Beiträgen keine Fragestellung, sondern lediglich die Beschreibung von (Deinen) Problemen, zu welchen Du (Deine) Lösungen angeboten hast, welche Du umgesetzt haben möchtest.
Das sind somit Forderungen nach Realisierung und keine Fragen.

Ich empfehle Dir Dich etwas mehr in das System und Konzept von Symcon einzuarbeiten und nach entsprechenden Grundkenntnissen gezielt Wünsche auszusprechen.
Diese sollten auch einen Mehrwert für andere bieten, ohne das grundlegende Konzept von Instanzen und somit die Funktionsweise der Software zu zerstören.
Michael

1 „Gefällt mir“