Hi Oli,
Eine Beschränkung auf abgestimmte Protokolle kann ich nachvollziehen, würde ich aber nicht als generelle Regel verstehen wollen. Sofern keine Nebenwirkungen auftreten, ist es meiner Meinung nach nur von Vorteil, wenn auch Geräte angesteuert werden können, die nicht offiziell unterstützt werden.
Ich bin mir nicht sicher, ob Dir der Ansatz des RFXTRX klar ist. Ich hatte das damals schon
hier mit vbs diskutiert. Anders als z.B. beim CUL oder S'duino hacked RFXCOM Funk-Protokolle, baut sie in die firmware ein, für uns eine black-box. Als Datenschnittstelle dient dann nicht mehr das ursprüngliche Protokoll, sondern ein "RFXTRX"-Protokoll, wir sehen also nie "echte" raw-Daten, sondern nur das, was uns die RFXTRX-firmware zur Verfügung stellt.
Im konkreten Fall hat Vladimir scheinbar das Original-Protokoll für rfxmeter analysiert und für den vair-Sensor missbraucht, so dass ein RFXTRX den Sensor nun als rfxmeter interpretiert. Nirgends ist dokumentiert, dass das RFXCOM-rfxmeter-Protokoll für einen vair-Sensor steht. Der richtige Weg wäre gewesen in sein Protokoll etwas einzubauen, am besten in Abstimmung mit RFXCOM, was seinen Sensor eindeutig identifiziert. Dann hätte RFXCOM es in seine Firmware eingebaut und eine eindeutige RFXTRX-Id vergeben über die dann sauber der FHEM-Ablauf gesteuert werden könnte.
Wird nach vbs, kernsani, kölnsolar noch jemals jemand den FHEM-Programmcode mit inline-Kommentar "rfxmeter" verstehen ?
Ich halte den Weg von Vladimir daher für einen Irrweg, den wir unterstützen und damit auch Support, Transparenz FHEM-Programm-Code ...negativ beeinflussen.
Eigentlich ist für uns FHEMler immer folgender Weg vorbestimmt:
- ein Protokoll, welches überhaupt nicht vom RFXTRX unterstützt wird, ergibt auch im RFXMGR keine Ausgabe
--> ein User kann sich an RFXCOM wenden, dass das Protokoll in die firmware aufgenommen wird
--> Ist es aufgenommen, wird es im RFXTRX-User-Guide dokumentiert, im RFXMGR ausgegeben.
- Noch nicht in FHEM implementierte RFXTRX-Protokolle landen im TRX_ELSE. Das ist dann für uns der Hinweis, dass wir mit RFXCOM Kontakt aufnehmen müssen, um Infos über das Protokoll zu bekommen und es implementieren zu können(oder wir hacken das RFXTRX-Protokoll)
- ein von FHEM
UND RFXTRX unterstütztes(und im User-Guide dokumentiertes) Protokoll landet in den Modulen TRX_LIGHT, TRX_WEATHER, TRX_SECURITY.
Ich hoffe ich konnte die RFXTRX-Philosophie etwas verdeutlichen und dass Vladimir mit seinem Sensor und Funkprotokoll in keinster Weise dieser Philosophie gefolgt ist, wir das auch noch unterstützen.
Je mehr ich drüber nachdenke, umso mehr komme ich zu dem Schluss, dass, wenn wir diesen "Unfug" unterstützen wollen, es eigentlich in ein eigenes
TRX_NOT_SUPPORTED Modul gehört, damit klar wird, dass zwar eine FHEM-Unterstützung vorhanden ist, das Protokoll aber originär
nicht von RFXCOM unterstützt, dokumentiert.... ist.
Ob der Einzelfall vair-Sensor aber überhaupt den Aufwand für ein neues Modul und eine umfangreiche Diskussion rechtfertigen.....
Grüße Markus
Edit: Ich hätte da noch ein Beispiel, an dem wir gemeinschaftlich ein
neues Protokoll implementieren könnten. Ich hab das vor 2 Jahren für einen User umgesetzt(der noch aktiv ist u. sicherlich testen könnte). Allerdings mit gewissen Annahmen, die wir hier schon gemeinsam treffen müssten: Es handelt sich eigentlich um Rolladenaktoren von Smartwares. Dazu gibt es aber im Guide zum RFXTRX gar keinen Hinweis. Wohl aber zu Thermostaten, mit dessen RFXTRX-Protokoll auch die Rolladenaktoren angesteuert werden können.
Und schon stellt sich die 1.Frage: Wohin damit ? packet type ist 0x48--> also TRX_WEATHER ? Oder unabhängig vom packet type ins TRX_LIGHT, weil ein "Schalter" gesteuert wird ? Und um eins drauf zu setzen: Im Guide ist das Protokoll unter "Specials" aufgeführt.
