Nachdem es mich genervt hat, für meine Rolladensteuerung bei jedem Befehl x Devices anzugeben oder mit Dummy + notify zu arbeiten, habe ich Modul gebastelt um Devices (beliebige) in Gruppen zu sammeln und mit einem einzigen Befehl anzusprechen.
Heraus gekommen ist 98_DeviceList.
Möglichkeiten:
- Anlegen von beliebig vielen Listen (werden als Reading gespeichert und angezeigt)
- Anlegen von beliebig vielen Devices pro Liste
- Jedes Device darf auf beliebig vielen Listen vorkommen
- Löschen von einzelnen Devices von einer Liste
- Löschen einer kompletten Liste
- der Befehl set [name] [reading] [commad] leitet command an alle Devices der Liste [reading] weiter
- hinzufügen und löschen von Listen und Devices bequem per Mausklick
- Pause bei der Befehlsweiterleitung nach X Devices für Y Sekunden (Attribute timeOutAfter und timeOut - Standardwert für timeOut ist eine Sekunde, timeOutAfter ist Standard 0 = kein TO)
Define:
define <name> DeviceList
Grenzen:
Das Modul prüft bei der Befehlsweiterleitung NICHT ob das jeweilige Device den auch ausführen kann.
Bei mir ist dieser Fall noch nicht eingetreten - Falls jemand mit einem entsprechenden Testsystem das ganze versuchen möchte: bitte gern...
Es werden KEINE Events oder Meldungen (nur Logmeldungen bei erfolgreicher Befehlsweitergabe) erstellt.
Es ist bisher weder programmiert noch geplant, eine gesammelte Abfrage für die Readings durchzuführen. (Wobei das evtl. noch interessant werden könnte....)
Ein wenig Commandref habe ich auch eingebaut - für mein Englisch übernehme ich keine Garantie...
Aber eigentlich ist das komplette Modul selbsterklärend.
Für alle die es testen / verwenden wollen ist die .pm Datei im Anhang.
Ich habe beim programmieren auf einem Testsystem ausgiebig getestet und verwede diese Version inzwischen auf meinem Live-System.
Trotzdem distanziere ich mich natürlich von jeglicher Garantie oder ähnlichem.
Eine offizielle Aufnahame in SVN ist meinerseits nicht geplant.
Bei Fragen und Anregungen - immer her damit :-)
PS: Das ist mein erstes Modul für fhem - u.U. sind Lösungswege verwendet die suboptimal sind - aber sie funktionieren 8)
Andreas
Was glaubst du, wofür das Modul structure gedacht ist?
oder LightScene (mit dem neuen set all kommando).
geht auch mit archetype und set raw ;)
Schön und gut...
Aber
Zitat von: Darkmozart am 28 September 2017, 00:18:15
- Pause bei der Befehlsweiterleitung nach X Devices für Y Sekunden (Attribute timeOutAfter und timeOut - Standardwert für timeOut ist eine Sekunde, timeOutAfter ist Standard 0 = kein TO
Wie sieht's damit aus? Das habe ich bisher nirgends gefunden... (Vllt auch weil ich nicht besonders danach gesucht habe)
nennt sich bei structure und LightScene async_delay. funktioniert zwar ein klein wenig anders da die verzögerung zwischen alle devices geschoben wird und nicht in gruppen, sollte aber am ende aufs gleiche hinaus laufen.
@Darkmozart , Glückwunsch zum ersten Modul :) Durch schreiben eigener Module lernt man IMHO wesentlich mehr über FHEM als durch einfaches Nutzen. Auch wenn vllt. das erste Kind nicht so auf die große Gegenliebe der anderen User stößt :
Benutze es weiter ! Das Ding hast du im Griff, eben weil es von dir ist ( ich selbst benutze einige Module die ich nur für meine direkten Anforderungen geschrieben habe und nie veröffentlicht)
Zwei kleine Tipps noch , du kennst https://wiki.fhem.de/wiki/DevelopmentModuleIntro ?
a. Such dort mal nach $_[3] und vergleiche das dort geschriebene mit deiner Attr Funktion
b. vermeide zwei , drei updateSingleReading in Folge und verwende besser updateBulkReading ( hat auch einen Abschnitt im Wiki)
@Wzut:
Danke!
Werde ich machen :-) dafür habe ich es ja geschrieben (unter anderem).
Zu den Tipps:
- ja, kenne ich.
a) Wenn ich das richtig interpretiere kann ich mir dadurch eine komplette Unterfunktion sparen, richtig?
b) habe ich gesehen, das ich es nicht umgesetzt habe war eher meiner Faulheit und der Uhrzeit geschuldet :-) Werde ich wohl noch einbauen.
@igami:
Das es mit archetype funktioniert habe ich mir fast gedacht - war aber zu faul mich in die Anwendung des Moduls einzuarbeiten :-) Weiterhin war es mir (nach kurzem überfliegen) zu starr - Ich wollte die Listen einfach manipulieren können, ohne das Device großmächtig verändern zu müssen.
@justme:
Sieht so aus al währe LightScene oder structure noch das was am ehesten an das honkommt was ich gesucht hätte - aber auch hier (zumindest bei structure und bei grobem überfliegen) stört mich die starrheit - wie gehabt, ich wollte die Listen einfach übers Frontend manipulieren können - hat wiederum was mit meiner Faulheit zu tun :-)
@marvin78,justme,igmai:
Die Info mit welchen Modulen das auch geht ist war für jemand der danach sucht ganz nett - vor allem wenn man nach etwas sucht, das evtl. sogar noch mehr Möglichkeiten bietet.
Allerdings führen gewisse Formulierungen wohl eher dazu manche davon abzuhalten ein Modul das sie selbst erstellt haben zu veröffentlichen - unter Umständen trifft das dann auch Module die für alle richtig toll wären... Bedenkt doch bitte das bei geschriebenem Text leider nur die Worte für sich stehen - da fehlen locker mal 75% der normalen Kommunikation (Körpersprache, Mimik, Modulation der Worte usw). Das soll jetzt nicht heißen das ich nicht für Kritik offen bin - aber Wzut hats in meinen Augen besser formuliert und gleich noch Tipps mitgeliefert. Das spornt eher an als ein bloßes hatten wir schon mal...
Just my 10cts.
Darkmozart
Um die andere Seite auch zu vertreten: wir haben in FHEM zunehmend das Problem, dass fuer die gleiche Aufgabe mehrere Module gibt, was bei allen (hier nicht erwaehnten) Vorteilen auch Nachteile mit sich bringt, naemlich dass Anfaenger verwirrt, und Entwicklerzeit "verschwendet". Ich habe nicht vor, doppelte Module zu verbieten, moechte nur bitten, dass der Autor es gut ueberlegt, bevor er so ein Modul veroeffentlicht. Insb. die "Eintagsfliegen" stoeren mich, da ein Anfaenger schlecht erkennen kann, dass ein Modul weder weiterentwickelt, noch unterstuetzt wird.
Auch das ist wiederum verständlich.
Und gerade für Anfänger, wie ich ja auch einer bin recht unübersichtlich. Auch wenn einige Modulnamen für sich sprechen und die Commandref, Wiki und Forum einiges erklären, so gestaltet sich die Suche nach einer bestimmten Funktion teils recht unwegig. - Aber das ist ein anderes Thema.
Die Kritik an sich stört mich ja nicht - eher die Verpackung derselben. Aber auch dies kann dem Umstand geschuldet sein, das doppelte Dinge auf Dauer nerven und man deswegen relativ kurz angebunden ist.
Schwamm drüber.
Ich denke, wir brauchen langsam ein umgekehrtes Inhaltsverzeichnis.
Nicht unter dem Modulnamen die Funktionen auflisten. Sondern parallel dazu eine Liste von Funktionalitäten führen, und auf die Module verweisen.
Für Hardware ist das ganz einfach.
Bei Automatisierungsmodulen eher schwierig.
LG
pah
Einen ähnlichen Vorschlag habe ich mir vorhin verkniffen 8)
Es kommt auch besser an, wenn sich Anfänger das Eine oder Andere verkneifen ... 8)
LG
pah
Dennoch danke für das Modul!
Es mag ähnliche Module geben, wie ich gelesen habe, finde aber jede Erweiterung für Fhem durchaus positiv. Alleine das sich jemand hin setzt und eine (von mir aus Variante) erstellt, so ist sie ggfs. einfacher in der Bedienung oder hat andere Vorzüge in der Verarbeitung.
Sollten nicht gerade auch Anfänger einmal positiv gefördert werden?
Evtl. muss man darüber nachdenken die "Features" einzelner Module anhand einer Matrix in ein neues "besseres" neues Modul zu überführen mittelfristig und langfristig.
Gruß,
Andre
Zitat von: andre070 am 01 Oktober 2017, 09:37:43
Sollten nicht gerade auch Anfänger einmal positiv gefördert werden?
Ist doch schon öfter passiert, dass erfahrene Modulautoren Anfängern als Tutor bei der Entwicklung geholfen haben.
Zitat von: andre070 am 01 Oktober 2017, 09:37:43
Evtl. muss man darüber nachdenken die "Features" einzelner Module anhand einer Matrix in ein neues "besseres" neues Modul zu überführen mittelfristig und langfristig.
Es spricht ja nichts dagegen Verbesserungen für bestehende Module zu schreiben. Aber in diesem Fall funktioniert das Modul ja einfach anders als die bestehenden.
Und es ist ja auch schon vorgekommen, dass Module ersetzt wurden. Aus EIB wurde KNX.
Ich denke mal es kommt auch immer darauf an wie das Modul weitergeführt wird.
Wenn jemand ein Modul nur so für sich entwickelt und es hier vorstellt, dann muss das eindeutig gekennzeichnet sein. Sprich ohne Anspruch auf Weiterentwicklung.
Ändern kann man das ja immer noch, aber die User wissen dann Bescheid.
Wer Module entwickelt mit dem Gedanken sie bei Gefallen auch offiziell zu machen sollte sich als Anfänger an einen erfahrenen Entwickler als Mentor wenden. Das hilft bei allgemeinen Fragen rund um FHEM Development.
Ich betreue 5 und selten geht es um Code sondern um allgemeine Fragen zum Aufbau oder um organisatorisches.
Und nun noch mal was zum Thema Modul und dem Thema ein anderes Modul mit gleicher Funktion aber leichterer Bedienung.
Ich finde es nicht sinnvoll ein Modul zu entwickeln nur weil man es einfacher in der Bedienung machen kann. Besser wäre es sich als User an den Entwickler zu wenden und sich über die usability zu unterhalten oder sogar Patches vor zu schlagen damit das schon vorhandene Modul besser wird.
Grüße
Zitat von: CoolTux am 01 Oktober 2017, 10:08:50
Besser wäre es sich als User an den Entwickler zu wenden und sich über die usability zu unterhalten oder sogar Patches vor zu schlagen damit das schon vorhandene Modul besser wird.
Klingt vom Ansatz gut, allerdings habe ich da Erfahrungen in zwei Richtungen gemacht. Es gibt Entwickler die reagiern bei leiser Kritik nach dem Motto "Unwürdiger wie kannst du es wagen mein Reich zu betreten" und andere nach dem Motto "gib her , baue ich ein sobald ich Zeit habe" :)
Anyway, inzwischen allerhand OT .... sollten wir dafür nicht mal einen Fred aufmachen unter Bezug auf Pahs Zitat
ZitatIch denke, wir brauchen langsam ein umgekehrtes Inhaltsverzeichnis
?
ich muss gestehen so manches Modul für mich auch erst endeckt zu haben weil es entsprechende Hinweise hier im Forum dazu gab. Via commandref wäre ich da bestimmt nicht drauf gekommen und auf die von Rudi angesprochen Eintagsfliegen schon gar nicht, zumal viele davon niemals in der commandref je auftauchen werden.
Gute Idee.
Nehmt doch in den neuen Fred auch gleich die Frage mit, wie man neue Modulautoren auf solche Dinge hinweist :-)
Neue Modulautoren finden im Entwicklerbereich schon deutliche Hinweise auf die Entwicklungsrichtlinien.
@andre070: Gegen eine "positive Förderung" ist nichts einzuwenden - aber die besteht nun einmal idealerweise darin, erst einmal kräftig zu lesen. Und nein, eben nicht jede Erweiterung ist zu begrüßen, und schon gar keine "Varianten". - denn das führt zum Chaos bei der Wartung und Pflege, wie jeder Software-Profi weiß.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 01 Oktober 2017, 11:34:08
Neue Modulautoren finden im Entwicklerbereich schon deutliche Hinweise auf die Entwicklungsrichtlinien.
Die habe ich alle gelesen...