IPSModuleStrict Preview

Ja, genau. Betrifft dann aber meistens einen Splitter und die Geräte Instanzen hängen dann ja am eigenen Datenfluss. Und dort ist es schön einfach. Ich denke im großen und ganzen eine Verbesserung und ich hoffe, dass wir die Upgrade auf der Konsolen Seite auch bald machen können, sodass auch IPSModule ein GetCompatibleParents bekommt und wir die Emulation umdrehen werden :slight_smile:

Ich glaube das löst das Problem leider nicht. Theoretisch kann ich einfach alle Check deaktivieren und schauen, dass das WebHook Control nichts registriert was schon existiert. So richtig optimal fühlt sich das noch nicht an.

paresy

Löst aber das Problem nicht, welches durch eine Migration eines Moduls auf IPSModuleStrict entsteht.

Vorher war der Webhook in der Property der Webhook Instanz und den will ich jetzt ja loswerden wenn ich registerhook von IPSModuleStrict nutze.
Michael

Prinzipiell würdest du ihn einfach ignorieren und das WebHook Control würde (da die TargetID ein Strict Modul ist) diesen Hook ebenfalls unter den Tisch fallen lassen. Und sobald ein User das WebHook Control öffnet, würden wir ihn zum Aufräumen auffordern. Das sollte für dich einfach sein und für den User ebenfalls recht simpel. Und falls doch ein Downgrad vom Modul gemacht wird, bleibt alles erstmal kompatibel.

paresy

1 „Gefällt mir“

Kurzer Übertrag aus dem Beta 8.2 Bereich, damit wir die Zusammenfassung nicht verlieren.

  • Dies bedeutet, dass intern beim Erstellen einer Geräte-Instanz der Splitter und die I/O Instanz nicht mehr sofort automatisch erstellt wird, sondern die Verwaltungskonsole dies über einen Assistenten mit euch durchführt.
  • Dies löst sehr viele Probleme und hat den riesigen Vorteil, dass wir euch z.B. beim Erstellen von einem neuen ModBus Gerät oder KNX Gerät fragen können, wo dies vom Datenfluss angeschlossen werden soll (an einen bekannten Splitter oder einen neuen) → Bisher war das Erstellen von neuen ModBus oder KNX Strängen sehr speziell.
  • Im Normalfall ändert sich für euch an der Oberfläche nicht viel. Alle internen Module sind bereits auf das neue GetCompatibleParents von ConnectParent/RequireParent/ForceParent umgestellt.
  • Alle IPSModule Module können ConnectParent/RequireParent/ForceParent weiternutzen und es wird GetCompatibleParents passend emuliert. Es darf auf GetCompatibleParents migriert werden und wird dann bevorzugt genutzt. (Falls das Modul auf der Annahme arbeitet, dass der Parent direkt nach ConnectParent/RequireParent/ForceParent verfügbar ist, muss das Modul angepasst werden)
  • Alle IPSModuleStrict Module müssen zeitnah auf GetCompatibleParents wechseln, sofern diese ConnectParent/RequireParent/ForceParent nutzen (das sind die wenigsten Module → Von Symcon betrifft es aktuell nur das eKey Modul, welches wir noch umstellen müssen). Solange die Module nicht umgestellt sind, können diese problemlos weitergenutzt werden → Nur neue Instanzen dürfen nicht erstellt werden.
  • Solltet ihr Instanzen per IPS_CreateInstance in euren Skritpen erstellen, müsst ihr ab sofort die Splitter und I/O Instanzen selbstständig erstellen und mit IPS_ConnectInstance verbinden. (Wird eher selten gemacht :wink: )
  • Erzwungene Änderungen von I/Os (z.B. von ModBus TCP auf ModBus RTU) werden von der Konsole noch nicht erkannt → Der I/O muss aktuell manuell angepasst werden. Dort kommt vermutlich am Montag das Feature Update.

jetzt habe ich bei der Umstellung auf IPSModuleStrict auch ein Problem mit GetCompatibleParents:

public function GetCompatibleParents(): string
{
	return json_encode([
	    'type' => 'require',
	    'moduleIDs' => [
		// WebSocket Client
		'{D68FD31F-0E90-7019-F16C-1949BD3079EF}'
	    ]
	]);
}

schlägt einen Client Socket, einen Server Socket oder einen Serial Port vor, aber keinen WebSocket.

Mache ich etwas falsch oder ist das ein BUG?

Grüße

Jürgen

Hast du einen Branch für dein Modul gegen den ich das mal testen könnte?

Das sieht eigentlich korrekt aus und sollte dann auch nur den WS Client anbieten.

Du bist mit der Beta der 8.2 unterwegs, oder?

paresy

Es betrifft das Deconz Modul und dort das Gateway. Ich habe das einfach mal auf den Master-Branch hochgeladen. Ansonsten funktioniert eigentlich alles einwandfrei. Ich nutze die Kernelversion 8.2 vom 22.12.2025 (Revision 894065d7a87f)

Grüße

Jürgen

beim Cutter habe ich das gleiche Problem. Das wird alles angeboten…

Kann es nachstellen und die Konsole bekommt da falsche Infos. Bin gespannt wo es klemmt :slight_smile:

paresy

Fix wird gebaut. Kommt in ca. 45 Minuten online :wink:

paresy

1 „Gefällt mir“

Du bist echt klasse!

Danke

Jürgen

Danke die ganzen Modul Updates :slight_smile:

Das Update ist für alles außer Windows online. Der Build klemmte ich musste ihn noch mal starten :wink:

paresy

Hab das Update gerade eingespielt…

…läuft, wie es soll

:heart_eyes:

1 „Gefällt mir“

Inzwischen habe ich alle meine Module auf IPSModuleStrict umgestellt. Ich hatte vorher etwas Respekt vor der Aufgabe, weil ich sehr viele eigene Module geschrieben habe. War aber letztendlich deutlich weniger Aufwand als erwartet. Wichtig zu wissen ist, dass die Internen Module von Euch alle Datenpakete als HEX senden und empfangen. Das heißt, dass in der Regel beim Empfangen ein hex2bin() erforderlich wird und beim Senden ein bin2hex(). Das ist nicht weiter schlimm, fehlt aber oben in deiner (@paresy ) Zusammenfassung. Im Video habt ihr das ja sauber besprochen.

Darüber hinaus gibt es noch ein Finding beim WebHook. Ändert man den Hooknamen einer Instanz, dann wird der alte Name nicht mehr korrekt abgemeldet. D.h. die Instanz ist unter altem und neuem Hooknamen erreichbar. Erst nach Neustart von Symcon ist alles wieder bereinigt.

Ansonsten läuft alles sehr gut und nach meinem Gefühl einen Tuck schneller als vorher. Aber das kann auch täuschen.

Jetzt werde ich erst einmal Langzeiterfahrungen sammeln.

Grüße

Jürgen

Jein:

Daraus sollte man schon ableiten das die RegEx Regel natürlich auch auf HEX Daten angewendet wird.

Hast du vorher den Hook selber über die Instanz mit IPS_SetPropery gesetzt und jetzt per SDK Funktion?
Weil zur Laufzeit kanndt du den Hook jetzt nicht mehr anpassen. Das RegisterHook ist nur im create erlaubt. → Somit dürfte das Thema gar nicht aufteten?!

nö, steht bei mir im AplyChanges und funktioniert da auch. Würde auch sehr bevorzugen, wenn das so bleibt, denn ansonsten kann man nicht mehr mehrere Instanzen eines Moduls mit unterschiedlichen Hooknamen anlegen.

Das ist entscheidend:

Klar geht das. Indem man z.B. die InstanzId anhängt.

nein, habe immer per RegisterHook gearbeitet.

Das ist vielleicht ein toller Notnagel, mehr aber nicht. Ich bevorzuge eindeutig das Anpassen über ApplyChanges().

Das gab es doch vorher gar nicht im SDK.
Und auch jetzt gibt es das nicht in IPSModule, sondern nur in IPSModuleStrict.

Diese Funktion kann normalerweise nur für IPSModuleStrict genutzt werden. Für das alte IPSModule kann allerdings die Basisklasse WebHookModule heruntergeladen und erweitert werden.

Quelle: RegisterHook

ich spreche ja auch nur vom IPSModuleStrict.