Hallo,
passt eigentlich besser in die Development Ecke, aber mangels Schreibrechten poste
ich mal hier:
Ich experimentiere seit einiger Zeit mit der Möglichkeit FHEM Module durch Klassen
in PERL darzustellen, also PERLs objektorientierte Fähigkeiten zu nutzen. Mein Ziel
war dabei eine Möglichkeit zu haben kleine Utility-Module einfach bauen zu können.
Bisher hat man ja im Grunde die Wahl sich per dummy devices, notifies, Funkionen
in 99_myUtils.pm und Co. was zusammenzustricken oder die harte Tour über ein echtes
Modul was für kleinere Probleme eher unhandlich ist.
Vom Grundgedanken her hat man dann eine PERL Klasse z. B. FHEM::MyClasses::CSomeDev,
die das Verhalten eines Devices mit Methoden/Funktionen definiert und auf
Events reagiert und man kann mit
define mydev D10_Device FHEM::MyClasses::CSomeDev param1 param2 ...
ein derartiges Device erzeugen.
Der Modultyp - hier D10_Device - gibt dabei den Anwendungsbereich vor; aktuell habe ich
insbesondere D10_Device für allgemeine Devices und D10_MQTT_Device für MQTT Devices.
Auch diese Module hängen in der Klassenhierachie, sind also auch PERL Klassen;
die allgemeinste Klasse ist dabei FHEM::D10::CDevice.
Etwas Doku findet sich dazu in meinem Codeberg Archiv, in den Abchnitten der mitgelieferten
Module für die commandref und in dem Code selbst:
https://codeberg.org/kgie/framework-fhem-d10.git (https://codeberg.org/kgie/framework-fhem-d10.git)
Anmerkungen, Fragen und Kritik zu diesem Ansatz könnt ihr mir gerne hier schreiben.
Ich selbst habe das bei mir seit einiger Zeit am Laufen; aber bei mir meckert auch
höchstens ein Mitbewohner, dass das Licht nicht mehr geht. Für "Produktion" ist
das noch nicht geeignet.
Gruß
Kai
Der Ansatz ist nicht neu. Schau Dir mal die commndref zu ECMD und ECMDDevice an, da wird ein ähnlicher Weg gegangen.
ZitatDefining one fhem module for any device class would create an unmanageable number of modules. Thus, an abstraction layer is used. You create a device class on the fly and assign it to a logical ECMD device. The class definition names the parameters of the logical device, e.g. a placeholder for the number of the ADC or port, as well as the get and set capabilities.
Zitatpasst eigentlich besser in die Development Ecke, aber mangels Schreibrechten poste
ich mal hier:
Es würde im jetzigen Stadium auch gut in die perl-Ecke unterhalb von Automatisierung oder in den Bereich Codeschnipsel passen.
ECMD/ECMDDevice hatte ich nicht auf dem Schirm, danke für den Hinweis.
Allerdings gibt es schon einen wesentlichen Unterschied: ECMD nutzt sozusagen seine eigene Art von Geräteklassen, in meinem Ansatz geht es aber um PERL Klassen. Eine PERL Klasse ist ja letztlich ein Package mit zugehörigem @ISA. D.h. bei dem define aus meinem Beispiel wird mit
bless $hash, 'FHEM::MyClasses::CSomeDev'aus dem Device-Hash $hash = $main::defs{mydev} eine Objektinstanz der Klasse FHEM::MyClasses::CSomeDev. Letztlich sind auch die Module (D10_Device, D10_MQTT_Device, etc.) alle Klassen in einer Klassenhierarchie mit FHEM::D10::CDevice an der Spitze, wobei es zu jedem Modul dann eine entsprechende implementierende (abstrakte) Klasse gibt. Z.B. wird D10_Device durch FHEM::D10::CGenericDevice implementiert und FHEM::MyClasses::CSomeDev ist dann eine Ableitung dieser Klasse.
Das ist mir schon alles klar.
Mir ging es mit meinem Hinweis lediglich darum, darauf hinzuweisen, dass es zusätzlich zur klassischen Modulstruktur durchaus auch schon andere Denkansätze in FHEM gibt. Nirgends habe ich behauptet, dass diese Klassenmodelle gegenseitig austauschbar oder vergleichbar seien.