wie der eine oder andere vielleicht schon mitbekommen hat, bin ich dabei ein Modul zur komfortablen Einbindung und Steuerung der GPIO von Raspberry Pi - vielleicht später auch ESP8266 - zu erstellen.
Dabei komme ich wohl nicht um den Umstand herum ein oder zwei Python-Dateien mitzuliefern.
Ist das über den Modulimport so abbildbar? (…das die Dateien eben mit heruntergeladen und ggf. aktualisiert werden)
wo musste(n) die Datei(en) in der IPS-Dateistruktur am sinnvollsten abgelegt werden?
alles, was im GIT liegt, wird auch beim Installieren gezogen, egal ob es gebraucht wird oder nicht. Wo Du es hintust ist relativ egal, sinnvollerweise mit zu dem Modul.
Du kannst aber nicht voraussetzen, das auf dem IPS PC/Raspberry/VM auch ein funktionsfähiges Python incl. aller Abhängigkeiten existiert.
Wie tommi schon geschrieben hat wird alles was z.B. auf github liegt so auch in das Modulverzeichnis kopiert. Ablegen und wenn eine Veränderung notwendig ist würde ich die Zusatzdateien dann aber unter Webfront/user wenn Du vom Modul aus Dateien im modules Ordne aus dem Modul heraus aktualisierst, anlegst oder ähnliches weigert sich IP-Symcon dann ein Update des Moduls durchzuführen wenn denn eines ansteht.
Wie bei 1. erwähnt wird alles aus github runtergeladen. Ablegen würde ich die Zusatzdateien dann unter webfront/user da stört sich dann IP-Symcon nicht bei einem Update dran.
Habe mich heute mit den Ersten Schritten zur Modulerstellung beschäftigt:
SourceTree insatlliert
Account by BitBucket eröffnet
mich (einigermaßen) ins GIT eingearbeitet
als Beispiel das Unwettermodul genommen , nach eigenem Wunsch modifiziert, umbenannt (neue Namen, neue GUID, etc.) um erst einmal etwas zum Üben zu haben.
==> komme tatsächlich soweit, dass ich das Modul in der IPS Kerninstanz ‚Module‘ laden kann…aber das ist alles. Im Modulverzeichnis sind die Dateien geladen, die neue Instanz kann ich (auch nach einem Neustart des Dienstes) nicht auswählen ==> irgendwo passt irgendetwas noch nicht. Im Anhang mal meine 3 Dateien, vielleicht kann mir jemand sagen was da noch falsch ist? :mad:
Ich habe das mal bei mir reinkopiert und kann das Modul auswählen und eine Instance erstellen. Auswahl mit Suchen oder bei Hersteller Sonstiges…Auch die Form wird geladen. Der Aktualisierungsbutton funktioniert nicht. Mach mal den Modul-Präfix ohne „_“.
Die library.json brauchst Du auch.
Wenns nicht klappt liefert das IPSLog auch Informationen. Nach jeder Änderung der json Dateien Neustart und ggfs. die _generated.ips.php kontrollieren, ob die eigenen Funktionen drin stehen.
Ich versuche mich hier mit meinem ersten Modul, bekomme aber immer wieder Fehlermeldungen die leider nicht sehr aussagekräftig sind…
Irgendwie war ich vom Code schon mal weiter, habe jetzt schon diverses wieder gelöscht und bekomme aber immer noch Fehlermeldung das das Formular nicht gelesen werden kann…
Ohne das komplett durchgesehen zu haben steht bei Dir weder unter Create noch unter ApplyChanges irgendwas drinnen. Da must Du schon die Variablen anlegen auf die Du im Form verweist.
das habe ich mal geändert, konnte aber das ERgebnis noch nicht prüfen…
Ich spiele mit dem Gedanken das Modul so aufzubauen:
Parent-Formular: Auf ihm wird der Raspberry Pi-Typ ausgewählt, die IP angegeben
Children-Formulare: Hier werden auf einzelne oder Gruppen von GPIO-Pins Funktionen ausgewählt (z.B. Dimmer, RGB-Steuerung etc.)
Ich suche noch nach einem vollständigen und funktionierenden Beispiel (Parent <-> Children) für solch einen Aufbau. Hat das jemand schon mal irgendwo gemacht?
Mir ist unklar, wann ich den Splitter in dem Modell gebrauche. In der Dokumentation steht er als „optional“. Kann mir jemand erklären wann der Splitter erforderlich oder vorteilhafter wäre?
Nun viele Module nutzen einen Splitter obwohl dieser oft nicht zwingend notwendig wäre. Wenn Du als I/O kein eigenen I/O erstellt sondern ein Standard I/O wie Clientsocket oder UDP Socket benutzt, macht es Sinn einen Splitter zu benutzten dann kannst Du das Formular zum Splitter packen. Beispiele sind hier z.B. das Logitech Media Server von Nall-chan oder das Harmony Modul usw.
Wenn Du sowieso ein eigenen I/O baust dann kannst Du Dir in vielen Fällen auch den Splitter sparen und die Daten gleich im I/O verarbeiten. Ansonsten macht es Sinn ein Splitter zu nutzten und dann die Daten die in ReceiveData ankommen zu verarbeiten und dann an die untergeordneten Instanzen weiterzureichen.
Beispiele für Parent Children Aufbau gibt es viele. Was ist Dir denn genau unklar bzw auf was zielt denn die Frage ab?
Das wäre ja im Prinzip der Standard Aufbau einen Moduls. Wie wird denn mit dem Raspberry kommuniziert über einen Standardsocket wie ein Clientsocket? Wenn ja dann dann packst Du das Formular zur Konfiguration des Raspberry zum Splitter dort trägst Du die IP und den Typ ein. Die IP überträgst Du dann in den Parent und setzt diesen auf aktiv.
Die Children kannst Du dann anlegen, diese senden die Daten an den Splitter über ForwardData. Jede Geräteinstanz hat dann ein identisches Formular bei dem Du dann die Funktion auswählst. Wenn sich die Formulare der Geräte unterscheiden musst Du für jede Geräteklasse ein eigenes Formular, spricht eigenes Verzeichnis und eigene GUID anlegen. Dann hast Du auch für die unterschiedlichen Typen einen eigenen Menüpunkt beim Anlegen der Instanz.
…Nein, die Kommunikation erfolgt über einen anderen Weg (die Datei ips2gpio.py).
Im Moment scheitere ich aber immer noch daran die Formulare einfach zu visualisieren - die nichts anzeigenden Fehlermeldungen machen es dann schwer nachzuvollziehen was da überhaupt das Problem sein könnte…
Wenn Du sowieso dann einen eigenen I/O baust dann brauchst Du wahrscheinlich auch nicht zwingend einen Splitter die Daten kannst Du dann auch schon im I/O auswerten und an die Geräteinstanzen weiterleiten. Jetzt ruft gleicht EM vielleicht habe ich später noch mal paar Minuten um zu schauen wo der Fehler wegen dem Form liegen könnte.
Außerdem ist die Variable die Du anlegt vom Namen falsch diese muss sich auf GPIO-Typ und nicht auf Model beziehen. Dann viel Erfolg beim weiter basteln.
…das waren schon mal Super-Tipps!!! Vielen Dank dafür!
Es gibt beim Aufruf aber immer noch eine unkommentierte (kein Text) Fehlermeldung.
Auffällig: Der Name der Instanz wird nicht mit in den Baum übernommen…
Der Klassenname war falsch das hast Du aber schon korrigiert. Ansonsten fehlt auf den ersten Blick noch der Eintrag bei implemented und Dir fehlen zwei GUIDs.
Du brauchst für jede Instanz eine TX und eine RX GUID sind also für den I/O 2, für das Device 2 und für den Eintrag in der library.json eine GUID. Alles zusammen also 5 GUIDs auf den ersten Blick hatte ich aber nur gesehen das Du 3 benutzt.
Am besten Du nimmst GitHub - paresy/SymconTest: Symcon modules for demonstration and testing
als Versuchsgrundlage. Da tauscht Du die GUIDs gegen Deine eigenen aus. Im nächsten Schritt passt Du die Klassennamen an bzw die Namen in der modul.json. Dann schaust Du ob es immer noch funktioniert und das Formular angezeigt wird. Zum Schluss passt Du dann das Formular und die Eigenschaften der Klasse Deinen Bedürfnissen an. Das macht die Fehlersuche vielleicht einfacher. Wenn das Grundgerüst steht kannst Du dann mit den eigentlichen Funktionen in der Klasse anfangen.
ein „passend“ Beispiel wäre echt eine Vereinfachung für mich. Mir ist aber nicht klar, ob ich auf Deinem Link etwas finde was meiner Idee entspricht. Andre W hat bei dem Homebridge-Modul etwas in die Richtung gemacht, jedoch passt das insofern nicht ganz, da er keine „echte“ Auswahl von den Childs zum Parent hat.
Meine Vorstellung geht ja dahin, das ich n-I/O haben kann (für jeden Raspberry Pi im Netz eine) und daran n-„Funktionen“ (wie Dimmer, RGB, etc.) hängen kann. Ein Beispiel dafür habe ich noch nicht gefunden…(oder habe ich etwas übersehen?)
