Neue Funktion: Module

JPaeper · 17. April 2015 um 12:07

…so Stück für Stück wird es - Danke!

Joachim

JPaeper · 18. April 2015 um 19:28

Hallo Paresy,

unterliegt der „prefix“ in der Datei module.json eigentlich irgendwelchen Konventionen hinsichtlich Länge, Groß-/Kleinschreibung, Sonderzeichen usw?

Joachim

Nall-chan · 18. April 2015 um 20:28

Wäre schön wenn das ausführen eigener Modul-Funktion gefixt wird, ohne das braucht es kein Prefix.[emoji33]
Wenn das endlich funzt und die Timer auch laufen, ist die Homematic-Erweiterung fertig von Delphi in PHP konvertiert. [emoji4]
Michael

JPaeper · 25. April 2015 um 13:50

…ich weiß nicht warum, aber ich kann keine Bilder mehr hochladen…

Wie auch immer: Grundsätzlich kann ich ja jetzt die Funktionen in dem Modul ansprechen, jedoch habe ich jetzt zwei Probleme:

Nach einer Veränderung im Modul bekomme ich eine Fehlermeldung die wohl besagt, dass es ein Problem gibt eine Funktion aus ein Modul ein zweites Mal zu deklarieren (__generated.inc.php). Neustart, Löschen des Modules etc. bringt mich da nicht weiter…
Mir scheint, es werden keine Rückgabewerte aus den Funktionen zurückgegeben…

Joachim

Nall-chan · 25. April 2015 um 16:01

Das Problem mit dem redeclare von Funktionen habe ich auch.
Nach einen Update von einem Modul stehen die doppelt in der __generated.inc.php
Außerdem nutze ich in meinem HM-Modul die Original HM_WriteValue* Functionen.
Da kommt dann der Fehler dass die Functionen schon in __function.inc.php deklariert wurden.
Ideen ?

Update:
Auch auskommentierte public function werden in die __generated eingetragen

Update 2 zu den Funktionen:

Exceptions werden nicht erzeugt, sondern nur als String zurückgegeben.
Hat man mehrere Klassen welche den gleichen Prefix und die gleichen Funktionen unterstützen, wird es auch pro Klasse einmal in die __generated eingetragen.
‚Befehl testen‘-Dialog in der Console geht nicht bei Funktionen mit Parametern.
Leitet man von der IPSModule eine eigene Basis-Klasse ab, von welcher man wiederum eine belibige Anzahl Klassen für x Module ableitet, so werden die Public-Funktionen der eigenen Basis-Klasse nicht erkannt. Workaround ist sie in jeder Modul-Klasse zu überschreiben.
Meine HM-Erweiterung meldet ‚Instance does not implement this function‘ wenn ich die Einträge in der __generated entferne schniff

Und nun wirklich genug gespielt heute
Michael

tomgr · 26. April 2015 um 10:00

Bin ich auch gerade auf die Nase gefallen :

<?

function GEO_ProcessHookData($InstanceID)
{
	return JSONRPC::GEO_ProcessHookData($InstanceID);
}

function IOT_Send($InstanceID, $Text)
{
	return JSONRPC::IOT_Send($InstanceID, $Text);
}

function IOT_Send($InstanceID, $Text)
{
	return JSONRPC::IOT_Send($InstanceID, $Text);
}

function IOT_Send($InstanceID, $Text)
{
	return JSONRPC::IOT_Send($InstanceID, $Text);
}

function IOT_Send($InstanceID, $Text)
{
	return JSONRPC::IOT_Send($InstanceID, $Text);
}

function IOT_Send($InstanceID, $Text)
{
	return JSONRPC::IOT_Send($InstanceID, $Text);
}

function IOT_Send($InstanceID, $Text)
{
	return JSONRPC::IOT_Send($InstanceID, $Text);
}

Die „function IOT_Send“ wird mehrfach angelegt, nach löschen vom Modul „symconTest“ und wieder Hinzufügen, sind die Einträge mehrfach vorhanden.
Habe alle doppelten rausgeworfen, dann geht erst mal wieder alles.

paresy · 26. April 2015 um 10:05

Werde mich da mal Morgen drum kümmern. Da ist definitiv noch was nicht in Ordnung.

paresy

JPaeper · 5. Mai 2015 um 16:47

Hallo Paresy,

hat sich bei den Modulen schon etwas getan? Haben bisher keinen Hinweis darauf gefunden - was bei mir auch mal heißen kann, dass ich etwas übersehen habe…

Joachim

Nall-chan · 5. Mai 2015 um 17:04

Wäre schön wenn der PHP-Klebstoff funzen würde
Und dabei noch der Bug beim Datenaustausch mit dem Parent beseitigt wird.
Habe mich nur nicht mehr getraut zu nerven ähh… fragen.
Michael

paresy · 6. Mai 2015 um 16:43

Für die wichtigsten Probleme gibt es im nächsten Update fixes. Hast du noch kurz einen Schubser, was du mit dem Datenaustauschproblem meinst?

Habe einige schwierige, weniger kritische Fehler mal der Fehlerliste hinzugefügt.

‚Befehl testen‘-Dialog in der Console geht nicht bei Funktionen mit Parametern.

Das konnte ich leider noch nicht nachstellen.

paresy

Nall-chan · 6. Mai 2015 um 16:56

Wenn ich es schaffe versuchte ich es heute abend genauer zu beschreiben. Bin noch beim Kunden und daheim liegt eine 40m Tanne ‚im‘ Gartenhaus
Das mit den Datenaustausch betrifft das SendToParent mit Daten ab 0x80.
Michael

BerndJ · 7. Mai 2015 um 13:21

Hi,

Versionen:
IPS cd64852b vom 6.5.2015,
Modules: Misc Module Symcon GmbH 1.00

wollte jetzt endlich das Geofency Modul testen und krieg es nicht hin,
sowohl auf dem RasPi, als auch auf einem Ubuntu 14.03.

So wie es aussieht fehlt bei beiden die Datei /usr/share/symcon/scripts/__ipsmodule.inc.php

Oder hab ich da ´nen Denkfehler?

mfg

BerndJ

BerndJ · 7. Mai 2015 um 19:58

Hi,

Fehler gefunden.

Das Geofency Modul muss aus dem Haupverzeichnis installiert werden, dann stimmt auch der erzeugte Hook.

mfg

BerndJ

Nall-chan · 9. Mai 2015 um 18:08

So habe endlich mal etwas Zeit gefunden

PHP-Funktionen werden nicht mehr mehrfach in der __generated eingetragen.
Dafür vermehren sie sich in der Konsole unter Befehle testen; bei jeden Update eines Modules über das Modul Control.

Und Parameter werden noch immer nicht unterstützt.

Außerdem werden auch Funktionen welche sich in Kommentar-Blöcken befinden hinzugefügt.

Aber das überscheiben von vorhandenen Instanz-Funktionen funktioniert perfekt, danke dafür.

Wer schon mal etwas testen und spielen möchte (auf eigene Gefahr, ist noch in einem sehr frühen Stadium):

git://github.com/Nall-chan/IPSHomematicExtended.git

Michael

Nall-chan · 13. Juni 2015 um 17:57

So, ich wollte nun endlich mal weiter machen…
Erstes Problem waren diverse Meldungen im Log der ScriptEngine mit Executing ScriptText und Sender RunScript.
So ca 20-30 Meldungen pro Sekunde !
Die PHP-Informationen Ansicht in der Konsole brachte dann zutage das es sich um meine Module handelt, welche Daten von einem HID-Instanz empfangen. Muss das wirklich in das Log ?! Sollte das nicht der Modul-Progger entscheiden was er loggt ?

Dabei hat dann die (aktuelle) Konsole ein ‚paar‘ Fehler geworfen.

Und der Datenaustausch mit Bytes größer 0x80 geht noch immer nicht
Parameter type of JSONData does not match…

Michael

andre · 14. Juni 2015 um 16:05

Hallo zusammen,

ich habe auch mal mit den neuen Modulen experimentiert.
Ich habe das Geofency-Modul von paresy an Geofancy angepasst (so wie andere hier auch schon).

Des Weiteren habe ich mir ein Modul zum Steuern von LCN-Gruppen gebastelt.
Die Module liegen hier bei GitHub: https://github.com/w-andre/symcon-php

Das LCN-Gruppen-Modul hat folgende Möglichkeiten:

Schalten/Dimmen von einem Ausgang für alle Module einer Gruppe mit definierter Rampe (je Modul Ausgang 1 oder 2 oder …)
Schalten von einem Relais für alle Module einer Gruppe (je Modul Relais 1 oder 2 oder …)
Abrufen einer Lichtszene für eine Gruppe
Speichern einer Lichtszene für eine Gruppe

Ich habe aber leider auch noch ein paar Probleme bzw. Sachen „unschön“ gelöst:

Ich bastel mir im Modul den PCK-Befehl zusammen. Aktuell sende ich den über den Client Socket, an dem der LCN Gateway hängt.
Dafür verbinde ich mich mit dem Client Socket über IPS_ConnectInstance. Um die passende Instanz zu selektieren (es kann ja mehrere Client Sockets für unterschiedliche Zwecke geben), hole ich mir erst das LCN Gateway und nehme davon die verbundene Parent-Instanz („ConnectionID“).

Gibt es da eine bessere Lösung, um PCK-Befehle abzusetzen?

Wenn ich im Constructor Properties mit „RegisterPropertyInteger“ registriere und dann eine Aktualisierung des Moduls über das „Module Control“ durchführe, dann sind alle Einstellungen meiner vorhandenen Instanzen weg bzw. wieder auf Default.

Was mache ich falsch?

Je nachdem, ob ich das Modul zum Steuern von Ausgang/Relais/Lichtszene verwenden will, sollen andere Variablen unterhalb der Instanz verfügbar sein. Das mache ich in der ApplyChanges()-Methode.
Irgendwie finde ich das aber aktuell noch nicht sehr „sauber“ gelöst. Hat einer einen Tipp für mich, wie man das schön realisieren kann?

Insgesamt muss ich sagen, dass ich die neuen Module super finde!

Gruß
André

paresy · 15. Juni 2015 um 08:30

Du kannst dich direkt an das LCN Gateway hängen. Dann musst du folgende Felder mitsenden:


	int Address;
	int Segment;
	int Target;	
	String Function;
	String Data;

Wobei Address (=1) sein muss, wenn du an eine Gruppe senden willst.

Falls das zu knapp beschrieben ist, müsste ich mal sehen, ob ich dir ein Beispiele machen kann :rolleyes:

Muss ich mir ansehen… Klingt aber nach einem Fehler, wenn es so passiert. Kann mir noch nicht erklären warum es so sein sollte…
Ich würde entweder drei einzelne Module machen, oder es so lassen wie es ist. Wir machen es auch in ApplyChanges.

paresy

Nall-chan · 19. Juni 2015 um 17:38

Ich würde gerne noch mal etwas ‚Werbung‘ für die PHP-Module machen.
Es gibt m.E. noch einige Baustellen und einiges was verbessert werden kann.
Schreibt doch einfach was euch dazu einfällt auch mit in den Thread.

Was mich noch stört ist das die Funktion ‚Befehle testen‘ in der Console nicht funktioniert, sobald eine Funktion einen Parameter erwartet.
Aufgrund das PHP hier typenlose Variablen nutzt, tauchen die Parameter in der Funktionliste vom Script-Editor nur mit Variant auf und das Fenster ‚Befehle testen‘ scheint das einfach nicht zu kennen.

Außerdem unterliegen Funktionsnamen jetzt den Restriktionen der PHP Schlüsselwörter.
Vorher war diese Funktion kein Problem ELRO_Switch.
Das geht nun nicht mehr da Switch ein PHP Schlüsselwort ist.
User die später auf 4.0 Updaten müßten wieder Ihre Scripte anpassen

Alternativ würde ich vorschlagen, dass es wieder eine Art Interface gibt welches z.B. in der JSON-Datei mit definiert wird.
Dort könnten dann die Typen der Parameter und Rückgabewerte sowie der IPS- und der dazugehörige PHP-Funktionsname definiert werden. Die Namen dürfen dann auch unterschiedlich sein. So könnte ELRO_Switch auf SendSwitch verweisen und für den Nutzer ändert sich nichts.
Netter Nebeneffekt, IPS braucht dann nicht mehr alle Klassen nach public blablafunktion durchsuchen.

Edit: Jeder Datenaustausch zwischen IPS und einer Modul-Instanz wird auch im Snapshot abgebildet. Ist auch nicht so optimal. Könnte mir vorstellen, dass dadurch auch das System bzw. Webfront, App, IPSView etc… ‚leiden‘.
Michael

paresy · 20. Juni 2015 um 16:44

Das mit dem JSON File habe ich auch schon überlegt. Die aktuelle Idee basiert darauf, dass es kaum Aufwand bei der Erstellung der Modul gibt. Aber mit dem „Variant“ und dem Auswerten von PHP Code gibt so ja so einige nervige Probleme… Ebenso das Mapping, wie von dir vorgeschlagen, wäre ein nettes Feature.

Ich werde dort demnächst noch einmal mehr Zeit widmen… nächste Woche schauen wir uns erstmal die Performance Probleme unter Linux an… Das ist m.E. das vorrangige Problem.

Trotzdem sind Vorschläge Willkommen… evtl. welche, die ohne zusätzlichem JSON File auskommen?

paresy

drapple · 20. Juni 2015 um 20:21

Ich hätte einen Vorschlag, aber der wird leider nie umgesetzt werden können

Man könnte den Spieß doch umdrehen und die Hersteller von Geräten (Denon, Miele, Samsung usw.) sollen für IPS die passenden Module bereitstellen :eek:

Aber das wird leider nie passieren :mad: