Ich bräuchte Hilfe, bzw. denke ich, dass mit kollektiver Anstrengung von Leuten die sich gut mit den verschiedenen Geräte-/Serviceklassen auskennen hier das Ergebnis besser wird.
Ziel ist (für mich, aber ich werde auch für FHEM einen Migrationspfad vorschlagen) von einer flachen NN_<Modulname>.pm "Hierarchie" zu einer
lib/Klasse/Unterklasse/... Hierarchie für die Module zu kommen. Siehe auch https://forum.fhem.de/index.php/topic,109522.msg1035912.html#msg1035912
wo man hoffentich sieht, dass so eine Modularität auch der Wiederverwendbarkeit von Code zugutekommt. Für künftige Modulentwicklung hätte das den Vorteil, dass man Module leichter und mächtiger zusammenstöpseln kann und vermutlich mit dem halben Codeumfang.
Bevor man aber soweit denken kann, muss erstmal eine vernünftige Klassifizierung und Hierarchie gefunden werden, und da wäre die FHEM Community Schwarmintelligenz gefragt:
Es gibt "Protokolle" (RS485, SNMP, ...) es gibt "Systeme" (Somfy, Sonos, HomeMatic) es gibt "Devices" physisch und virtuell, es gibt "Interfaces", "Agenten" (TelegramBot u.ä.) und vermutlich noch etliche andere. Das alles sitzt da wie ein verfilztes Wollknäuel - sowohl auf Festplatte wie auch in meinem Kopf.
Ein paar Sachen sind durch die Namensgebung relativ offensichtlich, wie z.B.
36_EleroDrive.pm 36_EleroStick.pm 36_EleroSwitch.pm
Elero.pm
Elero/Drive.pm
Elero/Stick.pm
Elero/Switch.pm
wobei ja die Hoffnung ist, dass man in Elero.pm z.B. den Code unterbringt, der den Modulen in der Hierarchie gemeinsam ist und dort einfach nur als redundante Duplikate rumhängt.
Die Frage ist dann zum Beispiel: muss man Elero als hersteller, als Geräteklasse oder als sonst etwas anderes betrachten?
Macht es Sinn eine AV Klasse zu haben und dann
AV/YAMAHA/...
AV/ONKYO/...
Anstatt Top-Level nach Hersteller zu gehen. ??? Ich frage ergebnisoffen, weil ich selbst in der Sache noch keine Klarheit habe und möchte jetzt nicht irgendwas im Elfenbeinturm entwerfen was komplett an der Realität vorbeigeht.
;D
Das kommt mir - nur aus einem ganz anderen Blickwinkel - einigermaßen bekannt vor...
Weiß nicht, ob das jetzt wirklich weiterhilft, was ich hier zusammenschreibe:
Wir hatten vor einiger Zeit mal eine hübsche Diskussion um diesen Wiki-Artikel hier: https://wiki.fhem.de/wiki/System%C3%BCbersicht (https://forum.fhem.de/index.php/topic,101736.0.html). Wenn man sich das ansieht, wird einigermaßen schnell klar, dass du dir damit eine Herkulesaufgabe gestellt hast...
Es gibt Dinge, die (vermutlich) eng zusammengehören mit je einem Interface und dann einem oder mehreren "Client-Modul(en)" (Elero ist vermutlich sowas, MySensors jedenfalls ist sowas, aber auch da gibt es eine "RS485-Variante", die sich aber im Handling in FHEM nicht von einem anderen physischen Transport-Layern unterscheidet).
Bei "IT" (und anderen 433MHz-Protokollen, insbes. auch "Somfy") ist es so, dass wir mehrere Interfaces kennen (mind. CUL (incl. diverser Derivate...) und Signalduino), die aber in der Regel dieselben Client-Module bedienen.
"Homematic" ist noch "schillernder: Da gibt es 2 grundsätzlich unterschiedliche Interface-Familien (wenn man die RS485-"classic"-Variante dazunimmt sogar 3 (?)), die jeweils komplett andere Clients bedienen.
RS485 ist jedenfalls eher ein "Transport-Layer" denn ein (eigenes logisches) Protokoll.
MQTT2_DEVICE schließlich ist als Client-Modul mMn. so universell, dass man "eigentlich" jedes Interface "davorklemmen" könnte, wenn das die empfangenen Daten auf einen MQTT-Standard runterbricht (mit MYSENSORS_DEVICE wäre es btw. ähnlich, das kennt sogar standardisierte "Werteklassen", bei denen man direkt weiß, ob es sich um einen Temperaturwert oder eine Voltage handelt...
Bin mal gespannt, ob es dazu ein greifbares Ergebnis geben wird :) .
MMn. ist bei derartigen Operationen aber die Gefahr riesig, dass irgendwo eine wechselseitige Abhängigkeit übersehen wird, und ins Leere gehende Funktionsaufrufe sind nicht eben prickelnd, was das user-feedback angeht ;D .
Gruß und viel Spaß beim Reinfuchsen in die ganzen Details,
Beta-User
Hi Richard,
ich will nicht den Spielverderber spielen und auch nicht völlig ausschliessen, dass man in gewissen Bereichen auf eine eingeschränkte Hierarchie kommen könnte. Das Ganze konsequent und nachvollziehbar zu machen dürfte aber schwierig werden. Schon die Unterscheidung in Geräte- und Hilfsmodule in der Commandref ist m.E. teilweise nicht völlig trennscharf.
Nehmen wir als Beispiel die TRX*-Module, die ich geerbt habe. Damit können Geräte verschiedenster Hersteller, verschiedenster Geräteklassen gesteuert werden. Wesentlicher gemeinsamer Nenner ist, dass sie auf 433Mhz funken (und nichtmal das ist richtig - es gibt auch 866MHz TRXe, die sind aber meines Wissens kaum verbreitet). Die gleichen Geräte (oder zumindest ein Teil davon) kann aber auch mit einem Signalduino oder CUL o.ä. gesteuert werden, die völlig anders arbeiten. Damit wird eine "logische" Hierarchie schonmal quasi unmöglich (oder ich habe "Intertechno" als Kind von 27 Eltern). Jetzt könnte man noch auf eine technische Ebene gehen. Das wird heute schon beim zweistufigen Modell (https://wiki.fhem.de/wiki/DevelopmentModuleIntro#Zweistufiges_Modell_f.C3.BCr_Module) an vielen Stellen praktiziert, nur im Dateisystem (und natürlich im Namensraum, aber das ist ein anderes Thema) nicht hierarchisch abgebildet. (Ich kenne Elero nicht, nehme aber an, dass es sich dabei genau um so ein zweistufiges Modell handelt)
Sicher gibt es eine Menge redundanten Codings innerhalb der FHEM Module, dies lässt sich aber m.E. eher durch generische Libs (wir hatten es ja z.B. mal von der ganzen JSON-Bearbeitung) lösen, als durch deinen Vorschlag.
Grüße,
Oli
es gibt leider nicht nur zweistufige Module sondern wie bei MAX auch dreistufige ....
00_CUL empfängt das Funktelegramm und gibt es wenn es ein MAX Telegramm ist an 14_CUL_MAX weiter , 14_CUL_MAX verarbeitet es entweder selbst oder reicht es 10_MAX weiter. Der Rückweg erfolgt i.d.R dann auch über alle drei 10_MAX -> 14_CUL_MAX -> 00_CUL
Die Namensgebung eng am Hersteller hat IMHO schon den Vorteil leichter feststellen zu können ob es für meinen Haarschneider der Fa. Glatzkopf vllt. ein FHEM Modul namens 33_Glatzkopf gibt.
Ja, Namensgebung eng am Hersteller oder am Protokoll (z.B. MQTT) macht Sinn, allerdings wird's doof, wenn Fa. Rastalocke baugleiche Haarschneider herstellt ;-) Oder - wie ich gerade schmerzlich feststellen muss - ein Grünbeck SD 18 eine ganz andere Sprache spricht, als der SC 18...
Gesendet von iPhone mit Tapatalk
Wie ich schrieb: ergebnisoffen.
Ob das Ergebnis nun ist
"Wir lassen's so wie es ist"
"Werden wir zumindest die Zahlen los"
"göttliche 1-Baum Hierarchie mit den abstraktesten der abstrakten Klassen. Sir!"
"mehrere Bäume-Hierarchie" (so wie in der Taxonomie)
...
bin ich schmerzfrei solange man am Ende der Diskussion der Ansicht sein kann, die Entscheidung ist begründet. Momentan sind wir noch nichtmal in der Diskussion, sondern im Brainstorming. Und die erste Regel des Brainstorming lautet: Es gibt keine schlechten Ideen.
Ich denke, ein Hauptproblem ist, dass sich nicht alles in starre Hierarchien zwängen lässt. So wie ich das sehe, haben die meisten Module eher sowas wie Attribute. Ohne vorgreifen zu wollen, würde ich momentan intuitiv sagen, dass eine Hierarchisierung nach Hersteller wohl eher nicht zu empfehlen ist.
Sonst hat man bei Samsung mal eben Schiffe neben Fernsehern. ;)
Ich könnte durchaus mit einer "multi-Baum" leben. TRX-Baum, HomeMatic-Baum ... und rein vom pragmatischen Ansatz her könnte (eher: müsste) man den Übergang ohnehin fliessend gestalten: sprich die einzelnen Bäume würden nach und nach aus der "flachen Ursuppe" der Module herauswachsen.
https://wiki.fhem.de/w/images/a/ab/System%C3%BCbersicht.png
Ist ziemlich hifreich. Unten rechts in der Legende sind ja mal so ganz abstrakte Klassen von Kommunikationswegen dargestellt. Könnten das nicht Basisklassen sein?
Zitat von: Wzut am 08 April 2020, 14:24:08
Die Namensgebung eng am Hersteller hat IMHO schon den Vorteil leichter feststellen zu können ob es für meinen Haarschneider der Fa. Glatzkopf vllt. ein FHEM Modul namens 33_Glatzkopf gibt.
Woher weisst Du dann die 33? Und was machst Du wenn Fa. Glatzkopf neben Haarschneidern auch Sexpuppen herstellt? Da würde ich letztere schon lieber irgendwo im FHEM Rotlichtbezirk unter
Entertainment/Dolls/Glatzkopf/Turbo9000.pm
Entertainment/Dolls/RealDoll/Schatzi2.0.pm
...sehen.
Zitat von: RichardCZ am 08 April 2020, 14:55:58
Ist ziemlich hifreich. Unten rechts in der Legende sind ja mal so ganz abstrakte Klassen von Kommunikationswegen dargestellt. Könnten das nicht Basisklassen sein?
...manche nennen es zurecht "überfrachtet" (aber mir ist bisher auch noch nichts besseres eingefallen)...
Das mit den "Basisklassen" kann man ggf. so sehen, aber das sind mMn. eher Unterscheidungen, die (vielleicht/offentlich) für Kaufentscheidungen eine Rolle spielen mögen, aber einen weiteren "Mehrwert" (im Sinne der Modulentwicklung) kann ich im Moment nicht erkennen, und auch der Transport-Layer "Kabel" oder "Luftschnittstelle" ist völlig sekundär. Darüber hinaus ist es (aus Modulsicht) fast egal, ob etwas unidirektional oder bidirektional ist (will sagen: der "Sendeoverhead" ist in der Regel beim Clientmodul gering, und der Hauptanteil liegt eher beim Codieren der zu sendenden Daten, oder?
Und dann gibt es ja eine ganze Reihe von Modulen, die nicht so richtig auf dem Schaubild zu finden sind (praktisch das ganze IP-Zeug ist irgendwo "in der Wolke", dto. für generische Dinge wie HTTPMOD&Co oder Messanger-Dienste).
Das "organisierte Chaos" spiegelt sich ja zum Teil auch in der Gliederung des Forums wieder...
Das war jetzt kein "dafür" oder "dagegen", ich mache grundsätzlich bei allem mit, was irgendwie Sinn macht - sei es aus Usersicht, sei es aus Entwicklersicht...
Aus Nutzersicht würde es eventuell Sinn machen, die Module anders präsentiert zu bekommen als Alphabetisch in den bekannten drei Kategorien. Im Sinne des Brainstormings sei mal eine "order"-Option in den Raum geworfen, wie wir sie von attrTemplate her teils kennen, das ganze hier aber dann ggf. mehrdimensional. Damit könnte man z.B. die 433-MHz-Geräte "zusammensortieren" - getrennt in Interface und Client, oder das, was zu CUL_HM gehört (aber dann wieder: nur das?!? Eher nicht, dann auch HMCCU.*). Kann sein, dass Meta teilweise was in die Richtung ermöglicht, aber eigentlich wäre sowas dann eher ein Thema für commandref-modular-2.
Zitat von: RichardCZ am 08 April 2020, 15:07:52
Woher weisst Du dann die 33?
Mwn ging es da "ganz früher" mal drum, die Ladereihenfolge beeinflussen zu können. Deswegen haben fast alle seriellen IO's die "00", und das "Logikzeug" kommt irgendwo hinten.
Ansonsten ist es schlicht ziemlich willkürlich und für den User schon gleich gar nicht irgendwo zu sehen...
ZitatMwn ging es da "ganz früher" mal drum, die Ladereihenfolge beeinflussen zu können.
ganz frueher ist noch nicht vorbei: $hash->{ORDER} (abgeleitet vom Nummer) im modul-Hash bestimmt clientArray, und damit in welcher Reihenfolge die virtuellen Module benachrichtigt werden, wenn ein Paket von physischen Modul verarbeitet werden soll.
passt das zur Beschreibung/Erklärung im wiki?
https://wiki.fhem.de/wiki/DevelopmentModuleIntro#Dateiname
ZitatSchlüsselnummer - Eine zweistellige Zahl zwischen 00 - 99. Die Schlüsselnummer hat aktuell keine technische Relevanz mehr. In früheren FHEM-Versionen ist sie relevant für zweistufige Module (Reihenfolge für Dispatch() um logische Module zu prüfen). .....
Zitat von: nils_ am 09 April 2020, 08:24:29
passt das zur Beschreibung/Erklärung im wiki?
https://wiki.fhem.de/wiki/DevelopmentModuleIntro#Dateiname
Nee, das Wiki stimmt nicht.
Ich hab' da mal was vorbereitet
$ lstree2 HoBo
HoBo
+- Module
| +- Air
| +- Control
| +- Energy
| +- Multimedia
| +- Security
| +- Service
| +- UI
| `- Water
`- System
Da eine strikte Hierarchie eh nicht möglich sein wird, und z.B. sowas wie
"Hauswasserwerk"
"Gartenbewässerung"
"Brunnensteuerung"
"..."
bei mir unter HoBo::Module::Water::* landet, aber man durchaus wird logische Cluster wie "Garden" haben wollen, wo außer Gartenbewässerung eben auch die Mähroboter (keine Ahnung ... HoBo::Module::Device::Bot::Lawn::*) sind, wird es eben auch solche Bundles/Cluster geben, die man sich aber zusammendefiniert - oder am besten "zusammenklickt".
Das wird sich noch alles sehr ändern und ich jongliere da noch rum im Kopf. Aber irgendwo muss man jemand ja anfangen.
zu dem zeitpunkt wo das jemand liest, hat sich das sicher schon geändert. :D
Ich hatte ursprünglich verstanden, dass du eine Modularität erreichen willst, die (u.a.) auch redundanten Code verhindern soll. Deine aktuelle Idee orientiert sich jetzt aber eher an einer Art logischer Geräteklassen o.ä. und das "Garden" Beispiel geht in Richtung Anwendungsbereich. Mir ist nicht ganz klar, was das Ziel der Hierarchisierung jetzt ist und was damit erreicht werden soll, kann. Was ich hier jetzt sehe, liese sich m.E. mit einem Tag-basiertem System (wie z.B. Meta/Installer) ganz gut abbilden (dann kann die Brunnensteuerung nämlich sowohl in "water" als auch in "Garden" eingeordnet werden und vielleicht zusätzlich auch noch bei "MQTT" etc...). Das ist aber eher eine Endanwender-Sicht, die möglicherweise ein gewisses Mass an technischer Modularisierung erfordert, aber nicht notwendigerweise zu besserem oder modularerem Code führt. Vielleicht können wir mal festlegen was die Ziele sind (und vielleicht auch klar abgrenzen, was man nicht damit erreichen will) und dann die Schwarmintelligenz darauf loslassen :-)
Zitat von: KernSani am 14 April 2020, 18:32:00
Ich hatte ursprünglich verstanden, dass du eine Modularität erreichen willst, die (u.a.) auch redundanten Code verhindern soll.
Ja, das ist ja weiterhin das Ziel:
Module::Device::Bot::Lawn::BoschXYZ.pm
Module::Device::Bot::Lawn::GardenaFoo.pm
Module::Device::Bot::Lawn::HusqvarnaBar.pmkönnten ja immer noch auf Gemeinsamen Code unter
Module::Device::Bot::Lawn.pm zurückgreifen. (Vmtl. fackelt man etliches auch durch Aliase ab, wenn baugleich)
Und ganz hart genommen sogar
Module::Device::Bot::Vacuum::iRobot::Dummbeutel.pm
Module::Device::Bot::Vacuum::LG::SuckOMat.pm
-> Module::Device::Bot::Vacuum.pm
und besagte *Bot::Lawn.pm und *Bot::Vacuum.pm eban auf *::Bot.pm
Zitat
Deine aktuelle Idee orientiert sich jetzt aber eher an einer Art logischer Geräteklassen o.ä. und das "Garden" Beispiel geht in Richtung Anwendungsbereich.
Das kommt
dazu. Sprich "Garden" ist ein Bundle aus diversen Dingen "Bewässerung (Modul XYZ)", "Rasenmäher (Modul ABC)", "Springbrunnen (Modul FGH)" ...
Zitat
Vielleicht können wir mal festlegen was die Ziele sind (und vielleicht auch klar abgrenzen, was man nicht damit erreichen will) und dann die Schwarmintelligenz darauf loslassen :-)
Ok. Es gibt zwei Zielsetzungen:
1) Logische Hierarchisierung zwecks Code-Wiederverwendbarkeit
2) Logische Clusterung zwecks intuitiver Usability
Ich hätte vielleicht 2) gar nicht erwähnen sollen um nicht zu verwirren, denn das wird vmtl. nur "ein Modul/Klasse" sein, wo dann Instanzen rauspurzeln: "Garten", "Wohnzimmer", "Garage" und die beinhalten Dinge, die irgendwo unter 1) in einer Hierarchie leben.
Zitat von: RichardCZ am 14 April 2020, 18:49:32
Module::Device::Bot::Lawn::BoschXYZ.pm
Module::Device::Bot::Lawn::GardenaFoo.pm
Module::Device::Bot::Lawn::HusqvarnaBar.pm
könnten ja immer noch auf Gemeinsamen Code unter Module::Device::Bot::Lawn.pm zurückgreifen. (Vmtl. fackelt man etliches auch durch Aliase ab, wenn baugleich)
Finde ich ganz schick, dann sehe ich als Anwender direkt was gibt es denn an Geräten.
Und da sie gleiche Codeteile verwenden sollte die Ansteuerung aus FHEM heraus keinen großen Unterschied machen.
Und die Probleme mit 1) - Hierarchie - sind eben:
* sinnvoll Hypernym -> Hyponym
* kurze aber prägnante Bezeichner
* Klassifizierung
Hinsichtlich Klassifizierung gibt er ja das alte Problem:
Multimedia::AVR
Multimedia::TV
So. Was macht man nun mit Fernsehern, die einen DVR eingebaut haben?
Multimedia::Combo?
oder belässt man die unter Multimedia::TV, nur haben die eben ein "Feature X" - was AVRs halt auch haben? Das ist etwas wo ich ein paar Koprozessoren gebrauchen könnte. ;)
Na ja, unter technischen Gesichtspunkten ist ggf. Bosch - Geschirrspüler näher an dem Mower oder dem Rauchmelder aus demselben Hause als an einem von Xiaomi mit BT- oder WLAN-Schnittstelle.
Wenn man das unter Code-Synergieeffekten ansieht, kommt vielleicht irgendeine Art Matrix-Denke raus. Was "klassische" HA-Hardware angeht (CUL_HM, HMCCU.*, ZWave, KNX, MySensors, HUE/Zigbee, EnOcean), sind jedenfalls die Geräte innerhalb einer Familie näher beieinander als verschiedene Geräte mit dem selben Zweck unterschiedlicher Basistechnik... (schon ein BT-Thermostat aus dem Hause eQ3 tickt anders als eines in HM-classic, und das ist wieder was anderes als MAX oder ein ZWave-eurotronic-spirit, der wieder anders funktioniert wie ein zigbee-eurotronic spirit)
Eventuell würde man sowas wie eine HAL-Ecke brauchen, aber die meisten zweistufigen Module sind grade eine Art HardwareAbstractionLayer, und die Unterschiede zu anderen Modulen haben mMn. meist technische Gründe.
Ansonsten: wir haben ja schon Schwierigkeiten "battery" einheitlich zu interpretieren... Unterschiedliche Funktionalitäten ergeben dann voraussichtlich genau das, was wir jetzt haben: eine große Unübersichtlichkeit. Aber immerhin: es geht, aber der user muß entsprechend viel kofigurieren/beachten, und es gibt gewisse Versuche, wenigstens ein bisschen Einheitlichkeit herzustellen (weekprofile, z.B.).
Könnten wir diesen Thread irgendwohin verschieben wo auch Nicht-Entwickler was sagen können?
Mich erreichen PMs von Leuten, die aus Benutzersicht was dazu sagen möchten und die können hier nicht schreiben. War von mir vmtl. zu kurz gedacht das hier zu plazieren.
Du bist TE also einfach unten links auf Thema verschieben gehen ;D
Zitat von: RichardCZ am 14 April 2020, 20:44:51
Könnten wir diesen Thread irgendwohin verschieben wo auch Nicht-Entwickler was sagen können?
Mich erreichen PMs von Leuten, die aus Benutzersicht was dazu sagen möchten und die können hier nicht schreiben. War von mir vmtl. zu kurz gedacht das hier zu plazieren.
Wo wir wieder beim Thema ,,Zielsetzung" wären. Geht es hier um eine technische Modularisierung, die einen hohen Grad von Wiederverwendbarkeit ermöglicht (die der Anwender aber überhaupt nicht zu sehen bekommen muss) oder um eine leichtere Auffindbarkeit für den Anwender. Das sind aus meiner Sicht zwei paar Schuhe, die auch getrennt von einander behandelt werden sollten.
Edit: Und ein dritter Punkt wäre dann Standardisierung von Geräteklassen (oder auch nur einzelnen Readings - siehe battery reading Beispiel von Betauser)
Zitat von: CoolTux am 14 April 2020, 20:59:31
Du bist TE also einfach unten links auf Thema verschieben gehen ;D
Schon, aber a) frage ich mal ob EInwände sind, b) ... ich weiß nicht wohin. Wunschliste? FHEM/Sonstiges?
FHEM Sonstiges klingt Sinnvoll.
Zitat von: KernSani am 14 April 2020, 21:05:01
Wo wir wieder beim Thema ,,Zielsetzung" wären. Geht es hier um eine technische Modularisierung, die einen hohen Grad von Wiederverwendbarkeit ermöglicht (die der Anwender aber überhaupt nicht zu sehen bekommen muss) oder um eine leichtere Auffindbarkeit für den Anwender. Das sind aus meiner Sicht zwei paar Schuhe, die auch getrennt von einander behandelt werden sollten.
Edit: Und ein dritter Punkt wäre dann Standardisierung von Geräteklassen (oder auch nur einzelnen Readings - siehe battery reading Beispiel von Betauser)
Aus meiner (persönlichen) Sicht, muss ich das alles erstmal auf die Reihe bekommen und ich traue mich momentan nicht zu sagen was von was getrennt gehört. Daher Brainstorming, ergebnisoffen. Denn ehrlich gesagt glaube ich, dass eine Modulhierarchie, bzw. Hierarchien (mehrere Bäume) zu der wir hier nach mehreren Iterationen kommen sollten, sich von dem was vielleicht beim Endbenutzer an Intuition vorliegt nicht komplett unterscheidet.
Ich weiß nicht wie es bei euch ist, aber ich brauche für einen guten Entwurf erstmal viele Daten und Erfahrungswerte. Oft habe ich hier bereits gehört, dass das was an Hardware bei den FHEM Nutzern vorliegt - und die Kombinatorik in der es vorliegt - einen ungeheueren Erfahrungsschatz darstellt. Meine Hoffnung wäre daher, dass während wir uns zu einer Klassifizierung, Hierarchie und Nomenklatur vortasten, ab und zu jemand aufschlägt und
"Möööp! Ne ... das ist so und so." einwirft. Naja und dann geht's halt in die nächste Iteration. Bis wir entweder am Schluss alle angeödet sind, oder sich das Gefühl breitmacht: "Jetzt ist es richtig".
Meine zweite Iteration. Devices fehlen noch komplett wie man sieht. Davor habe ich Angst.
$ lstree2
.
+- Control
+- Device
+- System
`- Topic
+- Environ
| +- Air
| +- Humidity
| +- Light
| `- Temp
+- Multimedia
+- Resource
| +- Energy
| | +- Heat
| | `- Power
| `- Water
+- Safety
+- Security
+- Service
`- UI
Hallo,
da ich wohl der Auslöser für die Verschiebung war will ich euch meinen Brainstorm nicht vorenthalten.
Aus mehr oder weniger Endnutzer-Sicht denke ich das eine Ordnung über das Protokoll mit dem das entsprechende Gerät kommuniziert am meisten Sinn macht.
zB.:
Protokollart-->Verbindungslayer-->Endgerät
FUNK-->ZWAVE-->Sensor
ENOCEAN-->Aktor
Netzwerk-->MQTT-->Tasmota
HTTPMOD-->Internetseite
AMAD-->Amad-SW
DLNA-->DLNA-client
UNIFI-->Switch
-->USG
-->AP
Ob das die besten und richtigen Namen für die einzelnen Sachen sind muss halt festgelegt werden.
Der naive Traum ist das jeweils die Schnittstellen definiert sind und wenn z.B. ein neuer Stereoreceiver kommt zumindest die Standardfunktionalität wie ein/aus, lauter/leiser, ... schon da ist und bei Bedarf nur der Verbindungslayer neu gemacht werden muss falls sich ein Hersteller mal wieder ein neues Protokoll ausdenkt.
Unifi is denke ich auch ein ganz gutes Beispiel, die Daten werden soweit ich weiß vom Modul Unifi über HTTPMOD geholt und dann an das Untermodul switch weitergeleitet/abgeholt welches dann das Endgerät darstellt. Wenn man es jetzt auf die Spitze treiben wollte würde dieses Untermodul switch auch mit einem Verbindungslayer Netgear zusammen arbeiten.
Wenn die Schnittstelle Verbindungslayer --> Endgerät hinreichend genau definiert ist wie z.B. bei DLNA (Modul DLNArenderer) --> DLNA-client oder MQTT --> Tasmota werden die Endgeräte automatisch in Fhem angelegt.
Ich denke das ist nah genug an der jetzigen Struktur und von der Wiederverwendbarkeit sollten auf jeden Fall die entsprechenden Verbindungsprotokolle abgedeckt sein.
So das war genug Storm für mein Brain :-X
Gruß
Eisix
Keine Panik, alles ist noch im Fluss - ich lerne noch:
$ lstree2
.
+- Protocol
| +- 1Wire
| +- Broetje
| +- Buderus
| +- ECS
| +- EnOcean
| +- Fronius
| +- Gardena
| +- Gavazzi
| +- HomeConnect
| +- HomeMatic
| +- Husqvarna
| +- InterTechno
| +- KNX
| +- Kostal
| +- Lemmonbeat
| +- MQTT
| +- Proteus
| +- SMA
| +- Vaillant
| +- Victron
| +- Viessmann
| `- ZWave
+- Self
`- Topic
+- Environ
| +- Air
| | +- Humidity
| | +- Quality
| | `- Ventilation
| +- EMS
| +- PR
| `- Temp
| `- AC
+- Multimedia
| +- Console
| +- Player
| +- Recorder
| `- TV
+- Resource
| +- Energy
| | +- Heat
| | `- Power
| | +- BMS
| | +- Charger
| | +- Combi
| | +- Inverter
| | `- Meter
| +- HHO
| +- LPG
| `- Water
+- Safety
+- Security
+- Service
`- UI
Gestern bin ich ins Kaninchenloch Gardena <->Husqvarna <-> Lemmonbeat gestiegen und habe Depressionen bekommen. ;) Naja - nur ein wenig.
Ich muss definitiv dieses Protokoll vs. Hersteller a.k.a. baugleiche/kompatible auf die Reihe bekommen.
Heute war das Kaninchenloch
https://www.e-sensorix.com/de/ecometer-s-ultraschall-fuellstandsanzeige-zisterne
versus
44_TEK603.pm
dran. Ohne Forum keine Chance. Das sollte besser werden.
hmmm,
echt coole Idee ;-)
Mein bescheidener Vorschlag sich an dem OSI Modell https://de.wikipedia.org/wiki/OSI-Modell zu halten
also die verschiedenen Layer nutzen ;-)
damit wäre dann der Part Kommunikation erledigt - zwar "etwas" Overhead, könnte aber langfristig merklich Vorteile bieten.
Als Konsequenz wären die Endgeräte quasi von der Kommunikation befreit und würden nur noch "Funktionen" anbieten...
Da es ja mittlerweile alle Möglichen Kombinationen von Geräten gibt, wäre da ein "Tagging" von den entsprechenden Eigenschaften imho eine möglich Lösung...
z.b:
deviceName: Eierlegende Wollmichsau mit Solarantrieb für die absolute Dunkelheit
Protocols: bidcos zigbee3.0 mqtt ...
Characteristics: getEier getWolle getMilch getKoteletts setAntrieb getSpecial setSpecial
tbc (to be continued)
Ich möchte auch etwas dazu beitragen, auch wenn es nur Bedenken sind.
Fronius.....
Es gibt unterschiedliche Herangehensweisen im Forum einen Fronius WR auszulesen (HTTPMOD oder MODBUS).
Daher sehe ich Fronius nicht unter Protocol, eher unter Topic -> Resource -> Energy
Dort dann eingeteilt in Inverter und Meter.
Wo aber steckt man dann aber den Speicher hin? Dieser ist von LG oder BYD, die benötigten Daten werden aber vom Fronius WR mit an FHEM übertragen?
Es gibt von Fronius zwar noch andere Geräte (Schweisstechnik), aber die bindet man wohl eher nicht in FHEM ein.
KNX.....
KNX kann man wohl als Protocol verstehen, dieser BusTyp deckt jedoch so ziemlich alles an Geräten ab die in einem halbwegs intelligenten Haus zu finden sind.
Licht, Rollos, Heizung, Klima, Lüftersteuerung, Wettersensoren/Stationen, andere Sensorien und Alarm um nur einige zu nennen.
Somit wäre KNX dann unter fast jeder Topic zu finden und wahrscheinlich auch unter Safety Security und Service.
KNX war übrigens bei mir der Grund zu FHEM zu kommen. Eine Visu ala Gira Homeserver incl. mehrere Bedientableaus sind einfach viel zu teuer.
Mittlerweile weiss ich auch, dass ich die Logikmodule zu teuer erkauft habe, denn das kann FHEM mit ein wenig Fleissarbeit auch besser.
Auch wenn ich nur Perl Laie bin und die Arbeit höchstwahrscheinlich unterschätze,
wäre es m.M.n. sinnvoll Module wie KNX oder Fronius nach folgender Logik zu trennen.
| +-Grundmodul PV
| +- Fronius
| +- Kommunikationsweg
| - Meter
| - Inverter
| - Akku
| - usw.
| +- SMA
| +- Kommunikationsweg
| - Meter
| - Inverter
| - Akku
| - usw.
- Grundmodul KNX
| +- Licht
| - Dimmer
| - Schalter
| - RGBWW
| +- Heizen/Kühlen
| - Wärme
| - Lüften
| - Klima
| +- Sensoren
| +- usw.
Gut Möglich, dass ich mit meinen Gedanken völlig auf dem Holzweg bin, so macht es aber für mich als Endanwender zumindest einen überblickbaren Eindruck und für den kleinen Modulschreiber in mir wäre es der Horror.
Ich habe mir die Idee gerade durchgelesen. Bin durchaus angetan von einer Struktur. Finde ich gut.
Allerdings würde ich das viel flacher angehen :)
In FHEM gibt es derzeit vier Klassen von Modulen, korrigiert mich, wenn es weitere gibt:
Hilfsmodule
Kommandos
Physische Module
Logische Module
Warum nicht erst mal nur damit anfangen. Wenns darunter dann weitere Verästelungen benötigt wachsen die schon von alleine.
Das ganze nach Hersteller, Protokoll, Empfangsgerät aufzudröseln führt unweigerlich wieder zu neuen Problemen.
Ich habe es bei dem Logischen Modulen für Sensoren, die unter anderem durch einen SIGNALduino empfangen werden können, direkt aufgeben Produktnamen in den Modulnamen zu verwursten. Da gibt es ständig sehr ähnliche Sensoren mit neuem Namen.
Da haben wir eher so Abkürzungen wie "Bell" für Klingeln oder SD für SensorDevice verwendet. Wenn sich für jemand der Bedarf ergibt, z.B. ein Modul aufzuteilen in dem 10 Funkklingeln verarbeitet werden, dann kann er das doch jederzeit unter den Logischen Modulen dann noch anlegen und einen Ast wie Beispielweise Bell::DeviceA, Bell::DeviceB anlegen. Wenn es das gibt, wird sich der Nächste vermutlich auch unter Bell sein Modul mit einchecken.
Super Beispiel ist auch das IT Modul. Das kann alle möglichen Funksteckdosen, die eine der verdächtigen Chipsätze verwenden.
Wenn jemand den Chipsatz in seine Funkklingel eingebaut hat, dann ist es auf einmal eine IT Definition und taucht nicht unter Bell auf. Die eigentliche Funktion kann sich der Anwender dann aber dennoch in FHEM einbauen.
Genauso auch die ganzen Logischen Module die CUL oder TRX in den Namen verpasst bekommen haben. Die sind doch nicht wirklich auf das physische Empfangsgerät beschränkt, das haben wir doch nur teilweise so eingebaut :)
Also vielleicht eher da ganze erst mal einfach und offen halten ?
Grüße Sidey
Hallo,
versuche mal meinen Vorschlag am Beispiel von Shadow3561 zu erklären, wobei ich nicht weiß wie Fronius und SMA kommunizieren (vermute da ist auch httpmod im Spiel, ich nehme hier aber an es wären proprietäre Protokolle).
Zitat
| +-Grundmodul PV
| +- Fronius
| +- Kommunikationsweg
| - Meter
| - Inverter
| - Akku
| - usw.
| +- SMA
| +- Kommunikationsweg
| - Meter
| - Inverter
| - Akku
| - usw.
Protokollart --> Verbindungslayer --> Endgerät
--------------------------------------------------------------------------
Netzwerk +- Fronius | - Meter
+- SMA | - Inverter
| - Akku
| - usw.
+-SIGNALduino | - Bell
| - Tempsensor
Das von Sidey habe ich auch mal eingebaut.
Zitat
Ich habe es bei dem Logischen Modulen für Sensoren, die unter anderem durch einen SIGNALduino empfangen werden können, direkt aufgeben Produktnamen in den Modulnamen zu verwursten. Da gibt es ständig sehr ähnliche Sensoren mit neuem Namen.
Da haben wir eher so Abkürzungen wie "Bell" für Klingeln oder SD für SensorDevice verwendet. Wenn sich für jemand der Bedarf ergibt, z.B. ein Modul aufzuteilen in dem 10 Funkklingeln verarbeitet werden, dann kann er das doch jederzeit unter den Logischen Modulen dann noch anlegen und einen Ast wie Beispielweise Bell::DeviceA, Bell::DeviceB anlegen. Wenn es das gibt, wird sich der Nächste vermutlich auch unter Bell sein Modul mit einchecken.
Konstruiere mal ein Beispiel:
Wenn jetzt Fronius beschließt eine Klingel in Ihren Inverter einzubauen dann müßte das Fronius Modul zusätzlich auch noch die Klingeldaten für das schon vorhandene Endgerät (Bell) bereitstellen.
Frage mich ob man da überhaupt noch nach Protokollart sortieren sollte, da es eigentlich nur eine logische Sortierung ist. Der Hauptunterschied zu den jetzigen Modulen ist das Verbindung und Funktion getrennt wird, so wie es jetzt eigentlich bei MQTT schon ist, nur das da keine Standart-Endgeräte da sind (wobei die templates schon sehr nah dran sind).
Gruß
Eisix
Ich lasse mal meinen Gedanken freien Lauf:
- Meine FHEM-Devices sind - in den meisten Fällen - reale Geräte, z.B. eine Alexa, ein Fensterkontakt oder ein Schaltaktor. Ein (oder mehrere) FHEM-Device(s) referenziert ein reales Device, z.B. WZ_Fenster_Rechts_Kontakt einen Fensterkontakt.
- Die andere Kategorie sind Datenquellen, z.B. Buienradar, Tankerkönig oder die ODL-Daten
- Ich fände es charmant, wenn ich z.B. ein Fenster definieren würde, dem ich Eigenschaften geben könnte, z.B. hat das Fenster einen Rollladen, einen Fensterkontakt, einen Griffsensor und eine Beleuchtung. Ich würde dem Fenster gerne sagen (lassen): Verblende dich. Und dann macht das Fenster, was auch immer es dafür tun muss. Ich glaube ich hätte gerne mehr "Smart" im "Home".
- Diese Items/Objekte können Unterobjekte sein, die wiederum Unterobjekte von einem Objekt sein können, usw. Sinngemäß: Haus, verblende dich → alle Rollläden fahren runter. Das haben wir aktuell mit Structures.
- Das wäre der eine Baum.
Den anderen Baum, den Gerätebereich, würde ich glaube ich so gestalten (alles Beispiele):
lib/Hardware/eq3/Homematic/BidCos/RF/$Device
lib/Hardware/eq3/Homematic/BidCos/Wired/$Device
lib/Hardware/eq3/Homematic/IP/RF/$Device
...
lib/Hardware/Amazon/Echo/$Device
...
lib/Services/Weather/Buienradar
lib/Services/Environment/ODL
...
Also allgemein lib/$TYPE/$VENDOR/$FAMILY/([$SUBBFAMILY/ ...])$DEVICE
So ungefähr hab ich auch aktuell meine Geräte taxonomiert (anhand der Räume).
vielleicht wäre es sinnvoll die code organisation (widerverwendbarkeit hinsichtlich protokollen und logischen funktionen) auf der einen seite und die präsentation und auffindbarkeit zum endanwender auf der anderen seite nicht als identisch anzusehen.
zumindest letzteres wird mit einer mehr oder weniger starren hierarchie nicht funktionieren da es zu viele n:m beziehungen gibt. hier wäre ein tagging besser geeignet weil ein device so sehr einfach in mehrer auch orthogonale kategorien gehören kann. der fernseher von oben wäre also einfach beides: TV und DVR.
ein beispiel wie das mit dem tagging aus sicht eines anwenders aussehen könne habe ich hier: https://forum.fhem.de/index.php/topic,106528.msg1006445.html#msg1006445 (https://forum.fhem.de/index.php/topic,106528.msg1006445.html#msg1006445) am beispiel der commandref überarbeitung an der ich noch bin gezeigt.
@Eisix: meine netzwerk kategorie von oben schmeisst netzwerk basierte protokolle und die geräte der netzwerk infrastruktur in die gleiche überkategorie. das ist falsch.
Ein Fernseher wäre für mich z.B.
Verbindungslayer --> Endgerät
--------------------------------------------------
+- HTTPMOD | - TV
+- DLNA | - DVD
| - DLNA-Client
Endgerät sollte vielleicht Funktion heißen. Also wäre der Fernseher die Summe der zur verfügung gestellten Funktionalitäten was im Grunde bedeutet Funktionalität ist eigentlich auch eine Art tagging.
Jetzt bin aber erst mal ruhig bevor die Programmierer hier die Hände über meinem Wolkenschloss zusammenschlagen. :-X
Gruß
Eisix
Zitat von: justme1968 am 16 April 2020, 11:21:32
ein beispiel wie das mit dem tagging aus sicht eines anwenders aussehen könne habe ich hier: https://forum.fhem.de/index.php/topic,106528.msg1006445.html#msg1006445 (https://forum.fhem.de/index.php/topic,106528.msg1006445.html#msg1006445) am beispiel der commandref überarbeitung an der ich noch bin gezeigt.
Das ist vermutlich für die Anwender Sicht die besser Idee.
Was das Aufteilen der Module auf Strukturen angeht, so bin ich noch mal in mich gegangen.
Mein Beispiel mit dem IT Modul und der Funkklingel, gibts in Echt sogar mit Motorleinwänden.
Das ist dann ein bisschen blöde, dass das IT Modul die Motorleinwand implementiert, weil die Befehle der Leinwand doch leicht abweichend sind.
Worauf ich damit hinaus will ist, die Zuordnung zu einer Strukur nach Funktion oder Gerätetyp passt aktuell nicht, weil der Code für beides in einem Modul steckt. Und wenn es darum geht doppelten Code zu reduzieren, dann könnte es vermutlich für die Struktur helfen, wenn der Code aufgeteilt wird.
Am Beispiel IT, Schaltsteckdose und Motorleinwand, wäre dann vielleicht ein Teil in einem "PT2262etc" Modul, was die Daten "versteht" und Module wie Schaltsteckdose und Motorleinwand würden dann die Darstellung aus dem "PT2262etc" Modul übernehmen.
Bei den Ganzen Modulen mit Wettersensoren würde das doch auch ganz gut klappen :)
Was dafür alles an Änderungen notwendig ist, darüber habe ich jetzt noch nicht mal Ansatzweise nachgedacht. Bestimmt eine ganze Menge :)
Ob wir dann davon was haben, naja vermutlich schon, weil die Präsentationsschicht entkoppelt wird. Heute wird das halt über die readinggroups oder auch dummys mit notifys realisiert. Geht so natürlich auch irgendwie :)
das schöne an der Sache ist aber, das man es parallel dazu einfach machen kann :-)
Eine "Basis§ wird erstellt und dann kommen die "Neuen" Devices dann in den Baum, also Alte und Neue Welt gleichzeitig. Wenn es perfekt läuft werden dann die alten Module auf die neue Struktur gebracht
https://metacpan.org/pod/Moo#IMPORTED-SUBROUTINES
Moo - eine Perl-only Implementierung des Großteils von Moose. (Welches wiederum ein postmodernes OO System für Perl ist)
extends - kann auf einer Basisklasse aufbauen
with - kann eine oder mehrere Rollen einer Klasse zuweisen
has - definiert Attribute
und noch ein paar mehr auf die ich jetzt nicht im Detail eingehen muss, aber im Grunde genommen hat das alles was man braucht um den bunten Zoo abzubilden mit dem wir es zu tun haben.
Perl-only bedeutet in diesem Fall ich kann das mit zum source packen, der User bekommt das mitgeliefert und muss weder CPAN, noch Distripaket (obwohl es das wohl bei den großen Distris gibt) machen, es wird kein Compiler etc. benötigt.
Damit kann man m.E. "next generation" Module machen, das sind IMHO die Bauteile für den Veyron, verglichen mit dem Golf I derzeit.
Aber der größte Witz an der Sache ist, dass man künftig Modulautoren nicht mehr Perl Können abverlangt, sondern weniger! De facto wird das auf 90% Parametrierung, 10% Programmierung hinauslaufen, wobei die Parametrierung ein einer deklarativen Syntax erfolgt:
package Multimedia::TV::Glotz9000;
extends 'Multimedia::TV';
has Nippel => (
is => 'rw',
);
has Lasche => (
is => 'rw',
);
etc.
Und wie Wuppi schon sagte, der Arm kann parallel wachsen (also was sowohl Struktur, wie auch Technologie betrifft) und muss das bestehende nicht stören. Man muss FHEM nicht von Grund auf neu implementieren. Man kommt auch inkrementell in die 30er des 21Jh.
Vielleicht hier etwas OT, aber thematisch paßt es aus Usersicht evtl. ganz gut rein:
Wir hatten grade das Thema "sinnvolle Namensgebung" bei Readings usw. rund um eine bestimmte Ladestation für E-Autos (go-echarger, diese Threads: MQTT-Weg (https://forum.fhem.de/index.php/topic,105457.msg1043434.html#msg1043434) und spezielles Modul (https://forum.fhem.de/index.php/topic,110282.msg1043223.html#msg1043223)).
Was z.B. Multimedia-Geräte angeht, habe ich gestern erst wahrgenommen, dass es sowas für Multimedia schon gibt (https://wiki.fhem.de/wiki/DevelopmentGuidelinesAV) und eben das hier gefunden: (https://wiki.fhem.de/wiki/DevelopmentGuidelinesReadings).
Das ist alles irgendwie noch nicht so richtig miteinander verknüpft und sehr bruchstückhaft...
Vielleicht mag sich jemand (oder eine Gruppe von Leuten) mal die Mühe machen, einen deutlich umfassenderen Vorschlag dazu zu erarbeiten bzw. das nach und nach erweitern? Das würde jedenfalls aus usersicht (und teils auch aus Ansteuerungssicht untereinander) m.E. einiges an verbessertem "Look and feel" bringen und wir würden nicht nachlaufend dann jeweils Reparaturen machen oder historische Zufälle zum Maß der Dinge machen...
Zitat von: Beta-User am 17 April 2020, 12:30:28
Das ist alles irgendwie noch nicht so richtig miteinander verknüpft und sehr bruchstückhaft...
Vielleicht mag sich jemand (oder eine Gruppe von Leuten) mal die Mühe machen, einen deutlich umfassenderen Vorschlag dazu zu erarbeiten bzw. das nach und nach erweitern?
Seit heute ist besagtes Moo Bestandteil des HoBo repository (einschliesslich ~7000 Tests) und während ich mich auf der stupiden Sisyphos Odyssee des Unit-Tests- Schreibens befinde, muss ich doch ab und an mal was anderes - anspruchsvolleres - machen.
Also habe ich mir überlegt wie man bestimmte Geräte, die FHEM heute schon unterstützt "zerstückeln" kann. Also woraus so ein "Samsung Fernseher" bzw. "Ethernet Sensorarray", bzw... "Fronius Symo" etc. besteht. Was sind deren "Komponenten", "Funktionen/Rollen", bzw. "(abstrakte) Basisklassen" (für die das gleiche gilt).
Wenn da jemand mitphilosophieren will, gerne.
Hi,
Wie wäre es mit Aktoren und Sensoren?
Grüße Sidey
Zitat von: Sidey am 21 April 2020, 08:50:25
Wie wäre es mit Aktoren und Sensoren?
Wo würdest du da eine Schaltsteckdose einsortieren, die auch Temperaturen / Leistung misst?
Sowohl als Aktor und auch als Sensor?
Gesendet von meinem Moto Z (2) mit Tapatalk
Zitat von: Sidey am 21 April 2020, 08:50:25
Wie wäre es mit Aktoren und Sensoren?
Meinst Du abstrakte, logische oder reale? ;-)
Auf der abstrakten Ebene sind beides die gleiche Komponente: Input->Output Transformation
Eingangsgröße -> Ausgangsgröße
Eingangsgröße: Wertebereich & Einheit
Ausgangsgröße: Wertebereich & EInheit
->: Mapping Funktion
nun kann man einen anstrakten Sensor zu einem logischen parametrieren
z.B. Eingangsgröße: (-50 bis +100 °C), Ausgangsgröße: (0 bis 5 V), -> ("Kennlinie")
Kennlinie laut Datenblatt oder Erfahrungswert oder Kalibrierung.
abstrakter Aktor, gleiches Spiel. parametriert dann (sagen wir Schrittmotor):
Eingangsgröße: (1 "Puls"), Ausgangsgröße: (0.1 ° Winkeländerung), -> (1:1)
Thema "Puls" ist nochmal ein Kapitel für sich.
Nun ist natürlich ein Aktor wie man ihn kennt "Rolladenmotor/steuerung" ein
Sammelsurium solcher Komponenten. Vermutlich:
* Motor
* Sensor(en) (Endbegrenzer, Pulszähler)
* Zustand (a.k.a. interner Speicher. Flip-Flops etc.) - andere Klasse.
Und der "Jalousienator Rollladen-Rolli 9000" hat dann noch andere Komponenten. Irgendwo muss ja ein Interfac sein über das man mit ihm (oder er mit einem) kommuniziert.
Ich habe doch dieses "Ethernet Thermometer". Aber eigentlich ist das ein Gerät welches über die folgenden Dinge verfügt:
2 x 1-Wire Ports (ich bin noch zu unbedarft was 1-Wire anbelangt, vermute das ist aber das was hier in "1-Wire" diskutiert wird)
1 x (logischen) Ethernet Port
"Ethernet Port" ist ein "IP-Netzwerkinterface"
Ebenso ist ein "WiFi Port" ein solches.
Die in Anführungszeichen genannten Dinge sind abstrakte Basisklassen. wobei "IP-netwerkinterface" basisklasse von "Ethernet Port" bzw. von "WiFi port" ist.
Und Ethernet Port wird dann zu einem "Fast-Ethernet port" (= 100MBit, FD, ...) parametriert. und als Instanz besagten Gerätes ... naja instantiiert.
Den ganzen Schlunz mit IP Adresse, Netzmaske, Gateway, ... hat es von der "IP Netzwerkinterface" Basisklasse geerbt.
Das Gerät hat als Rollen/Features einen eingebauten "Webserver" (Basisklasse) und "SNMP" (Basisklasse). Das kann ich dem Gerät nur deswegen zuordnen, weil es ein besagtes Netzwerkinterface hat.
Das Ziel wäre für mich, dass ein "Modulautor" künftig hergeht und so ein neues zu unterstützendes Gerät quasi aus dem vorhandenen Baukasten zusammensetzt und zu 90% fertig ist. Mit besserem/vollständigerem Support als das heute der Fall ist beim "copy&paste des nächstähnlichen". Naja ganz 100% wird das in den wenigsten Fällen gehen. Ich bin Pragmatiker genug um zu wissen, dass die Welt nicht
so orthogonal ist.
Aber wenn ich dann meinen beschi* neuen Samsung TV derart konstruktiv zusammensetze, dann wird der einige dieser komponenten haben (u.a. ein WiFi Interface, s.o.), aber auch sowas wie ein Video-Display (welches dann Attribute der Auflösung etc. hat)
Mal schauen wie weit man das treiben kann. Aber wenn das gelingen sollte, wären wir - glaube ich - in einer anderen Liga. In unserer eigenen. ;)
Zitat von: Christoph Morrison am 21 April 2020, 08:56:00
Wo würdest du da eine Schaltsteckdose einsortieren, die auch Temperaturen / Leistung misst?
s.o.
Wenn sie Leistung und Temperaturen misst, hat sie zwei logische Sensoren.
Wenn sie schaltet, mindestens einen Aktor (Wertebereich: an/aus)
Sie wird ja vermutlich noch irgendwo ein interface haben, sonst wäre sie für uns ja irrelevant.
Dann kommt es darauf an wann/warum sie schaltet. autark? von aussen?
Vermutlich wird man aber mit so ganz einfachen Komponenten anfangen müssen, bei denen die Dekonstruktion in logische Einheiten noch übersichtlich ist.
Ziel für den Endnutzer ist es aber diese ganze Komplexität überhaupt nicht zu sehen. Der weiß nur "Ich habe eine Schalti 2000" Steckdose, die gibt er ein (oder läst einen auto-discovery wizard laufen) und wenn die supported wird, wird die ziemlich gut supported - weil da ja eine tonne wiederverwendbarer Code mitwirkt. ;)
Ich weiß, das klingt alles noch wie Sci-Fi und da ist es auch noch eine Weile hin. Aber wenigstens wisst ihr was mich so antreibt.
Hallo,
könnte man sich nicht an den Z-Wave Geräten orientieren. So was ich bis jetzt mitbekommen habe, unterstützen die Geräte, auch von verschiedenen Herstellen, bestimmte Funktionen:
Vision Security ZG8101 Garage Door Detector (http://devel.pepper1.net/zwavedb/device/340)
classes BASIC ALARM ASSOCIATION BATTERY MANUFACTURER_SPECIFIC SENSOR_BINARY VERSION WAKE_UP
vclasses ALARM:2 ASSOCIATION:1 BATTERY:1 MANUFACTURER_SPECIFIC:1 SENSOR_BINARY:1 VERSION:1 WAKE_UP:2
Steckdose (http://devel.pepper1.net/zwavedb/device/361)
classes MANUFACTURER_SPECIFIC VERSION CONFIGURATION PROTECTION SWITCH_BINARY SWITCH_ALL METER ALARM ASSOCIATION INDICATOR
vclasses ALARM:3 ASSOCIATION:1 CONFIGURATION:1 INDICATOR:1 MANUFACTURER_SPECIFIC:2 METER:2 PROTECTION:2 SWITCH_ALL:1 SWITCH_BINARY:1 VERSION:1
pejonp