Hallo zusammen.
Ich habe mich mal rangesetzt und einen Vorschlag für eine Kompatibiltätsliste f. FHEM entworfen.
Folgende Spalten schlage ich vor:
| entry |
| group |
| producer_or_supplier |
| brandmark |
| modelname |
| rev_or_vers |
| model_or_ordering_code |
| product_availability |
| technically_identical_to |
| interface |
| frequency_of_radio_devices |
| protocol_in |
| protocol_out |
| function |
| support_status |
| FHEM_module |
| link_to_commandref |
| link_to_WiKi |
| link_to_fhem_board |
| remarks_and_hints |
Dabei könnten die Felder "support_status", "function", "interface", "protocol", "group" und "product_availability" durch Vorgaben referenziert werden:
| support_status | function | interface | protocol | group | product_availability |
| OK | alarming | 1-Wire | 1-Wire | actuators | end of life |
| experimental | bridging | API | ARC | audio_video_receiver | still in production |
| NOT_OK | controlling | EBUS | AC | bus_devices | unknown |
| detecting | GPIO | Bluetooth | busmasters |
| executing | I2C | DECT | cameras |
| measuring | KNX | EiB/ KNX | controller |
| observing | Modbus | EM | displays |
| programmable | Radio | EnOcean | dongles |
| receiving | RJ45 | FHT | door_chimes |
| sending | RS232 | Firmata | external_software |
| serving | RS485 | FS20 | illumination |
| | SPI | FTP | motion_detectors |
| | USB | HMS | motor_screens |
| | | HomeMatic | power_sockets |
| | | HomeMatic wired | pushbuttons |
| | | IT | set_top_boxes |
| | | IT ev1527 | smart_meters |
| | | IT_V1 | weather_stations |
| | | IT_V2 |
| | | IT_V2 |
| | | IT_V3 |
| | | LaCrosse |
| | | Max! |
| | | MQTT |
| | | MySensors |
| | | N.A. |
| | | parallel |
| | | PCA |
| | | proprietary |
| | | S300 |
| | | serial |
| | | several |
| | | SWAP |
| | | TCP/IP |
| | | Telnet |
| | | UDP |
| | | WMBUS |
| | | XMPP |
| | | ZigBee |
| | | Z-Wave |
Anbei habe ich vorschlagsweise Füllungen eingefügt (aus Wiki und Commandref herausgepickt + ein paar eigene), um zu zeigen, wie das aussehen könnte und welche Fragen sich ergeben können (Tabelle ist ein ods-File, wenn es Probleme beim Öffnen gibt, müsste ich es als XLS o.ä. konvertieren).
Ein paar Gedanken zur Liste:
- die Füllung wäre m.E. ein Thema für alle, die sich einbringen möchten - einer allein hätte wenig Spaß stets die Zumeldungen nachzupflegen
- Liste eher in Englisch pflegen - so haben mehr Leute etwas davon
- es sollten m.E. auch Einträge möglich sein, welche nicht gegengeprüft sind - so haben auch Exoten, sehr teure oder seltene Geräte eine Chance erfasst zu werden
- wenn es zu falschen/ fehlerhaften Einträgen kommt, werden sie halt korrigiert, sobald es auffällt - es mindert die Verwendbarkeit der Liste weniger
- die Liste könnte zweierlei ermöglichen:
- reines referenzieren von kompatibler Hard- und Software
- Hinweisgeber für Neuanschaffungen/ Einkaufsliste etc.
so erschienen mir Felder sinnvoll wie "product_availability", "model_or_ordering_code" und "technically_identical_to" - natürlich sind Infos zur Baugleichheit schwer zu bekommen -> umso wichtiger Bekanntes hier zu erfassen ;)
- es sollten mehrere Module benannt werden dürfen, wenn z.B. ein Device durch mehr als ein Modul unterstützt wird - zu erläutern, wie die Einbindung erfolgt, das wäre dann nachzulesen in Commandref, Wiki oder im Forum
Nun meine Fragen:Wie sind Eure Meinungen?
Was fehlt Euch, was sollte raus/ anders?
Bestünde Interesse dies weiter zu verfolgen?
In welcher Form würde es Sinn machen, eine solche Liste zu publizieren u. zu pflegen?
Oder ist dies Thema sinnlos/ überflüssig?
Vielen Dank und beste Grüße
rob
klingt sehr gut ;-)
wäre aber als "Datenbank" mit Web Frontend bestimmt einfacher aktuell zu halten - und könnte wunderbar auf FHEM.de und im Wiki beheimatet sein.
bei dem Feld Group habe ich noch ein wenig Bauchschmerzen wegen der vielen Kombigeräte
Bsp: WiFi Steckdose mit Strommessung und Temperatur ...
Da fände ich persönlich es cool, wenn man entsprechende Haken als "Gruppe" (Steckdose; Wifi, Strommessung; ...) setzen kann
Finde ich auch gut. 8)
Als Neuling tut man sich schwer, passende Hardware zu finden.
So wäre es auch sinnvoll, das "zugehörige" Gateway mit aufzunehmen.
Es gibt ja z.B. ZigBee und dafür aber auch einen selbst gebauten Gateway, der mehrere Hersteller in einem Rutsch bedienen kann.
Man kommt da aber bestimmt schnell von 10 auf 100 Varianten.
Als Liste wird das sehr schnell, sehr unübersichtlich.
Daher ist die Idee mit der Datenbank nicht von der Hand zu weisen.
Wäre sicher top, wenn das klappen würde, allein es fehlt der Glaube mir...
Diese Art Vorschlag kommt ca. 1x p.a., und ist bisher immer wieder im Sande verlaufen. Das hat imo vielfältige Ursachen, angefangen damit, dass es im wiki verpönt ist, Ratschläge zu erteilen, über die missliche Zwickmühle, dass man immer nur beurteilen kann, was man kennt (jedenfalls, wenn das Konzept halbwegs OK ist) und zu guter letzt ist es oft genug sehr schnelllebig.
Bsp: zigbee kann man auf mindestens 4 Wegen einbinden, wobei alleine für Mqtt zwei Ansätze bestehen. Was im Einzelfall die Beste ist: k.a....
MiLight: auch hier hat man 3 Wege, aber eigentlich eine Technik, die große Defizite aufweist.
IT: hier gibt es so viele unterschiedliche interfaces, aber nicht den Königsweg....
Und Zwischenschichten wie MQTT? Passen gar nicht so recht in so eine Datenbank....
Trotzdem viel Erfolg, bin mal gespannt!
Zitat von: Beta-User am 30 Oktober 2018, 15:19:15
Wäre sicher top, wenn das klappen würde, allein es fehlt der Glaube mir...
Diese Art Vorschlag kommt ca. 1x p.a., und ist bisher immer wieder im Sande verlaufen. Das hat imo vielfältige Ursachen, angefangen damit, dass es im wiki verpönt ist, Ratschläge zu erteilen, über die missliche Zwickmühle, dass man immer nur beurteilen kann, was man kennt (jedenfalls, wenn das Konzept halbwegs OK ist) und zu guter letzt ist es oft genug sehr schnelllebig.
Bsp: zigbee kann man auf mindestens 4 Wegen einbinden, wobei alleine für Mqtt zwei Ansätze bestehen. Was im Einzelfall die Beste ist: k.a....
MiLight: auch hier hat man 3 Wege, aber eigentlich eine Technik, die große Defizite aufweist.
IT: hier gibt es so viele unterschiedliche interfaces, aber nicht den Königsweg....
Und Zwischenschichten wie MQTT? Passen gar nicht so recht in so eine Datenbank....
Trotzdem viel Erfolg, bin mal gespannt!
ich denke, man muss nur die Gerätschaften entsprechend differenzieren :-)
sehe das ganze vergleichbar dem ISO Schichten Model ...
dann passt auch MQTT in die Darstellung rein ;-)
@Wuppi68
Ich geb Dir vollkommen Recht. Diese Eingruppierungen können einerseits zu starr sein, sodass Kombis nie richtig passen, und andererseits würde zuviel Wildwuchs dazu führen, dass man nix zusammenfindet.
Deshalb hatte ich die Beispielfüllungen gemacht, um solche Dinge besprechen zu können ;)
Zu Deinem Beispiel
Zitat von: Wuppi68 am 30 Oktober 2018, 14:28:38
Bsp: WiFi Steckdose mit Strommessung und Temperatur ...
Da fände ich persönlich es cool, wenn man entsprechende Haken als "Gruppe" (Steckdose; Wifi, Strommessung; ...) setzen kann
Bei Group wollte ich eigentl. die Hard- u. Software grob clustern. Damit ich einen Zwischenstecker von einer Wetterstation trennen kann - beide messen Temperaturen. So würde ich die WiFi Steckdose und Wetter-Temp-Sensor bspw. so einsortieren:
group | |interface | |frequency_of_radio_devices | |protocol_in | |protocol_out |
power_sockets | |Radio | |2.4GHz | |TCP/IP | |TCP/IP |
weather_stations | |Radio | |868MHz | |LaCrosse | |LaCrosse |
Und bei function bin ich dann genau bei dem was Du schreibst. Die Kombis können vieles sein. Da finde ich Deinen Ansatz mit Häkchen eine sehr gute Idee.
Könnte dann so aussehen:
group | |interface | |frequency_of_radio_devices | |protocol_in | |protocol_out | |alarming | |bridging | |controlling | |detecting | |executing | |measuring | |observing | |programmable | |receiving | |sending | |serving |
power_sockets | | Radio | | 2.4GHz | | TCP/IP | | TCP/IP | |N | |N | |N | |N | |Y | |Y | |N | |N | |N | |N | |N |
weather_stations | | Radio | | 868MHz | | LaCrosse | | LaCrosse | |N | |N | |N | |N | |N | |Y | |N | |N | |N | |N | |N |
Ein strenger Datenpfleger könnte sagen, dass eine Komp.-Liste nur kompatible Hard- Software nennen solle und nicht die Beschreibung der Geräte/ Programme übernehmen müsse. Nach dem Ansatz würden obige Spalten alle rausfallen - vielleicht zu streng ;D
Pflege via DB-Backend + Webfrontend wäre auch in meinen Augen der Königsweg. An die Liste hatte ich deshalb gedacht, weil ich Tabellen im Wiki anlegen kann und andere User diese editieren dürfen. Eine DB + Webif im Wiki einbetten kann ich dagegen nicht.
Aber vielleicht lässt sich dafür etwas finden, wenn im ersten Schritt das "Datenmodell" verabschiedet worden ist.
Vielen Dank und beste Grüße
rob
@Neuhier
Zitat von: Neuhier am 30 Oktober 2018, 14:42:29
So wäre es auch sinnvoll, das "zugehörige" Gateway mit aufzunehmen.
Es gibt ja z.B. ZigBee und dafür aber auch einen selbst gebauten Gateway, der mehrere Hersteller in einem Rutsch bedienen kann.
Für mich eine gute Idee. Das Feld könnte z.B. einfach "Gateway", "controlled_by" oder "bridged_through" heißen. Ähnlich den Modulnennungen, müssten dann mehrere Einträge je Datensatz möglich sein.
Wie man das Erfassen handhabt, müsste sich dann in der Praxis ggf. einschleifen ;D
Bestfall:
Derjenige wer einen Eintrag erstellt, würde zunächst nach seinem Wissen das Gateway1 reinschreiben, welcher er selbst einsetzt. Der nächste User könnte nun den Eintrag mit seinem (anderem) Gateway2 ergänzen.
Weniger gut:
Der nächste findet vorigen Eintrag nicht und erstellt flugs einen neuen mit Gateway1.
Garnicht gut:
Jemand müsste die DB/ Liste auf Redundanzen prüfen und aufräumen (Wem sollte man das aufbürden?).
In DBen ließe sich das ein Stück weit via Schlüssel einfangen. Ganz verhindern ließe es sich wahrscheinlich nicht.
Vielen Dank und beste Grüße
rob
@Beta-User
Zitat von: Beta-User am 30 Oktober 2018, 15:19:15
Wäre sicher top, wenn das klappen würde, allein es fehlt der Glaube mir...
Diese Art Vorschlag kommt ca. 1x p.a., und ist bisher immer wieder im Sande verlaufen. Das hat imo vielfältige Ursachen...
Trotzdem viel Erfolg, bin mal gespannt!
Ich stimme Dir zu. Ich hab da nix neues aufgebracht und das ist im Detail wohl selten trivial.
Sicher werden noch div. Fragen/ Probleme hoch kommen (manchmal scheitert man schon an Kleinigkeiten) und es gibt keine Garantie, dass es nicht wieder im Sande verläuft.
Ich wollte nur nicht gleich aufgeben. Wenn es doch unlösbar ist, dann werde ich es auch nicht ändern können - habs aber versucht ;)
Vielen Dank und beste Grüße
rob
da gibt es noch einen ganz anderen Lösungsansatz :-)
Verbindungen über klickbare Hashtags
da könnte man sogar einfach zwischen Deutsch und Englisch umschalten
als Beispiel:
HM-LC-DIM1T-FM 1-Kanal-Dimmer UP
Wiki: https...
CommandRef: https...
Forum: ....
#Homematic #Dimmer #Funk #BidCos #Supported #NoNewDevices ...
HM-CFG-LAN LAN Konfigurations-Adapter
Wiki:
CommandRef:
Forum:
#Homematic #Gateway #TCPIP #BidCos ...
Na ja, man kann auch das wiki nochmal doppeln...
Wer vorläufig aktiv sein mag, kann auch hier seine Erkenntnisse einpflegen: https://wiki.fhem.de/wiki/System%C3%BCbersicht
Ist an sich auch kein sooo schlechter Startpunkt, wenn man heute was sucht.
Zur Inspiration hatte ich ein wenig auf die Hardwareliste von OpenWRT geschielt (https://openwrt.org/toh/start (https://openwrt.org/toh/start)). Keine Ahnung, ob da eine DB hinter steckt.
Aber Varianten sind ja viele denkbar. Das Tagging find ich auch reizvoll. Naja, das Wiki klonen wollte ich nicht gleich ;D
Mal schauen, was noch an Rückmeldungen kommt. Vielleicht ist das Thema aber zu oft im Sande verlaufen und es rieselt bereits heimlich ;)
Viele Grüße
rob
Idee: gut, Umsetzung: schwierig
Ich nehm mal das Beispiel des STV für SamsungGeräte. Geräteytpen(TV, BlueRay, mehr ?). Zumindest bei den TV-Gerätetypen gibt es 4 verschiedene grundlegende technische Varianten. Diesen lassen sich die 12 Geräteserien(Baujahr) zuordnen. Je Geräteserie wird nach Kontinent und Modellausstattung unterschieden, so ca. 50 je Geräteserie. Und dann macht noch die firmware einen Unterschied, denn manche Geräte/firmware werden überhaupt nicht unterstützt.
Was ich damit sagen will: Es macht zumindest keinen Sinn diese Modelle in eine Liste zu übernehmen, sondern es müsste ein Eintrag genügen und in einer Spalte wird auf ein detaillierendes Dokument verwiesen.
Grüße Markus