Es in den Splitter auszulagern wäre eine Möglichkeit… das überlege ich mir mal.
Was spricht denn gegen den Konfigurator?
Das funktioniert ja schon, nur dass man die Änderungen leider noch nicht live sieht, sondern nur beim neu öffnen des Konfigurators.
Michael
Der Splitter macht in sofern mehr Sinn, da man sonst pro Gerät die identischen Anmeldedaten nochmal anlegen müsste. So hab ich sie einmal zentral im Splitter.
Hä?
Du hast da irgendwas nicht verstanden 
Der Konfigurator senden per Datenaustausch seine Anfrage an den Splitter und bekommt das Ergebnis.
Und der Splitter hat doch die Anmeldedaten.
Michael
Maybe wir sprechen von verschiedenen Sachen was den Konfigurator angeht? Ich meine die form.json des Moduls. Aktuell ist in dieser auch die Anmeldung enthalten, was die oben beschriebene Problematik ergibt (erst Anmeldedaten eingaben, dann aktualisieren etc.). Dem kann ich aus dem Weg gehen, wenn die Anmeldung im Splitter liegt, dann kann ich beim auflegen des Konfigurators des Moduls gleich die zur Verfügung stehenden Instanzen anzeigen.
Hallo Leute,
haben mal vier Fragen:
-
Ist es den Regeln nach zulässig, wenn der Nutzer im Konfigurationsformular die Möglichkeit hat, das Variablen-Logging ein- bzw. auszuschalten?
-
Das GetConfigurationForParent ist ja doch explizit dafür gedacht, die übergeordnete Instanz mit den erforderlichen Daten zu befüllen. Ich gehe daher davon aus, dass diese im Thread geführte Diskussion nicht diese Feature bzw. die „Fernkonfiguration anderer Instanz“ betrifft?
-
Ist es noch stand der Technik zum Start einer untergeordneten Instanz den IPS-Runlevel mit IPS_GetKernelRunlevel() == 10103 abzufragen oder soll stattdessen ein anderer Status verwendet werden?
-
Mein Splitter benötigt einige zusätzliche Librarys. Diese sind aktuell im Modul-Verzeichnis wie im Bild zu sehen angeordnet. Muss diesen fünf Ordnern noch das Verzeichnis „libs“ übergeordnet werden?
Joachim
@Hagbard:
Der Konfigurator ist eine eigene Instanz. Damit ist nicht die Form gemeint.
Michael
- Ich enthalte mich Wobei es bei einigen Modulen sinnvoll ist, wenn du die Archive Daten auch im Modul nutzt um z.b. Berechnungen durchzuführen.
Aber immer schön den User darauf hinweisen. - GetConfigurationForParent konfiguriert nix um. Gibt nur Daten für die Konsole vor. Bestes Vorgehen, was ich gerade umbauen in meinen Modulen.
Alles was in IO konfiguriert werden soll, bleibt dort und entferne ich aus meiner Instanz. Und damit ich mitbekomme wenn der IO aktiv geht, reagiere ich im MessageSink darauf.
Beim starten von IPS passt das nicht, somit braucht mein Splitter auch immer noch die Nachricht 10001 zusätzlich. - 10001 wäre korrekt.
- Ja.
Michael
Dann hilf mir mal auf die Sprünge. Ich kenne sonst Konfiguratoren nur die in IPS eingebauten (Webseite, Homematic etc.) und habe in der Anleitung nichts gefunden so etwas selber zu bauen… einzig auf Konfiguratorformular bin ich gestoßen, das war ja aber das was ich oben meinte.
Grobes vorgehen, Rest sonst später oder auch per PN von einem Modul was ich in Arbeit habe:
Ein neues Modul vom Typ Konfigurator schreiben.
An den IO binden für den Datenaustausch.
Im Modul bei GetConfigurationForm die Geräteliste über den Splitter laden und als Liste aufbereitet und json codiert zurückgeben an die Console.
Zusätzlich einen Butten in der Form erzeugen, welche den ausgewählt Eintrag der Liste nutzt um eine neue Instanz zu erzeugen.
Schaut dann ungefähr so aus:
Michael
Verstehe, aber ist in meinem Fall nur Overhead… Das jemand mehrere Instanzen der selben Art hat dürfte die Ausnahme sein und nur da würde es Sinn machen (damit man jede Instanz nur einmal hat), ansonsten wäre es für den Anwender umständlich erst in den Konfigurator zu gehen und dann noch ins Konfig-Formular des Moduls. Aber danke für die Erklärung.
- Ja. Ist zulässig. Hauptsache es passiert nicht automatisch.
- Jupp.
- 10103 (KR_READY) stimmt (@NallChan 10001 ist KernelStarted beim MessageSink ;))
- Genau. Alles in libs werfen.
paresy
Ja, danke habe jetzt erst meine Kaffee
Michael
Verstehe ich nicht; ich denke du willst mehrere Instanzen anlegen?
Man kann auch eine Geräte Instanz schreiben, welche mehrere physikalischen Geräte unterstützt und die Statusvariablen einfach dynamisch erzeugt (siehe HM).
Michael
Hallo,
wir die Liste der Module
https://www.symcon.de/forum/threads/34187-Feature-Vorschlag-Modul-Installation irgendwann veröffentlicht?
In der Übersicht der PHP-Module könnte das MQTT-Modul von Thomas68 aufgenommen werden.
Grüße, Gerhard
ich bekomme da eine ‚mangelde-Rechte‘-Meldung
Hi,
ich versuche mich gerade in die Modulentwicklung einzulesen und frag mich, ob es eine Möglichkeit gibt zu prüfen ob genug freie Variablen zur Verfügung stehent?
So könnte man ggf eine Installation ablehnen oder Vorwarnen wenn ein Schwellenwert erreicht ist. Hintergrund ist, das ich eine Heizung abfragen und steuern möchte und je nach Ausbaustufe der Anlage kann es sein, das bis zu 200 Variablen angelegt werden müssen (Worst Case) aber schon eine normale Anage kann bis zu 25 Variablen benötigen.
Darf das Modul automatisert Serversocket Instanzen und Registervariablen anlegen?
Viele Grüße
Bei der Installation nicht. Es existiert zu diesem Zeitpunkt noch keine Instanz aus deiner Klasse, also kannst du nichts ‚machen‘.
Jedoch kannst du beim anlegen der Variabeln prüfen; wenn du das willst.
Typischerweise wird das aber (bisher) nicht gemacht, sondern einfach anlegen und dann bekommt der User von Symcon schon eine Fehlermeldung um die Ohren geworfen ^_^;
Ja, dafür das hier nutzen:
RequireParent — IP-Symcon :: Automatisierungssoftware
Nein, nicht benutzen. Brauchst du auch nicht!
Hier lesen: Datenfluss — IP-Symcon :: Automatisierungssoftware
Michael
Das Anlegen über dem Limit ist in dem Sinne auch kein kritischer Fehler, der den aktuellen Betrieb stören würde - die neuen Variablen, welche über dem Limit sind, sind nur eben nicht ansteuerbar.
paresy
Ich habe mal die Einstellungen für StyleCI hinzugefügt, welche wir für unsere PHP Module (z.Z. Alexa, Assistant) verwenden.
paresy