TRX.*-Module - Patches und Aktualisierungen

Begonnen von KernSani, 30 März 2018, 22:30:51

Vorheriges Thema - Nächstes Thema

KernSani

Hallo zusammen,

ich habe die Maintenance der TRX.* Module übernommen. Ich werde mich dabei im Wesentlichen auf kosmetische Anpassungen beschränken (d.h. die Module entsprechend aktueller FHEM Guidelines pflegen).

Wer funktionierende Patches hat, bitte hier an diesen Thread anhängen, ich werde diese dann (soweit mir das möglich ist) prüfen und mit einbauen.

Grüße,

Oli
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

KölnSolar

Hi Oli,
danke fürs "overtaking"  :-*

Und den ordentlichen Einbau der set-extensions in TRX_LIGHT  ;)

Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

vbs

Find ich gut. Würde mal den Anfang machen mit einem Patch für Support für die vair-Sensoren. Ausgangspunkt ist diese Diskussion hier:
https://forum.fhem.de/index.php?topic=67734.0


KernSani

Hi vbs,

ich gehe davon aus, dass der patch nicht nur bei dir funktioniert? Ist es korrekt, dass Änderungen an TRX_ELSE, TRX_WEATER und TRX notwendig sind?

Danke,

Grüße,

Oli
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

vbs

Ja, sollte meiner Meinung auch bei jemand anderem als mir funktionieren :) Habe dazu aber kein Feedback bekommen.
Da das Protokoll aber offenbar nicht frei zugänglich ist, musste ich es reverse engineeren. Daher keine Garantie bzgl. evtl. "Fehlinterpretationen". Vladimir (der Hersteller von vair) hatte wohl Kontakt mit Bert (offenbar der Mann hinter RFX) und wollte auch für Intergration in FHEM sorgen. Habe aber davon nichts mehr gehört (siehe Thread).

Ansonsten ist es korrekt, dass die drei Dateien geändert wurden.

KernSani

RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

vbs


KölnSolar

Hmm,
so richtig gut finde ich den Patch eigentlich nicht.  :(

Warum:
1. der vair-sensor hat nichts mit Temperatur, Luftfeuchtigkeit, Luftdruck, Wind, Gewicht... zu tun. Das tun aber alle bisher im Modul TRX_WEATHER berücksichtigten Protokolle. (0x40-0x5d)
2. Das Protokoll mit 0x7100 passt eigentlich auch nicht in diese Logik.
3. Im Quelltext ist vom RFXmeter die Rede. Das war aber meines Wissens ein Stromzähler und Vladimir hat das Protokoll (glaube ich) nur missbraucht.  :(
4. Wenn nun etwas "Neues" mit 0x71 seitens RFXCOM kommt, fliegt uns das im TRX_WEATHER um die Ohren. Sollte aber eigentlich im TRX_ELSE als "noch nicht implementiert" auftauchen.  :'(

Tut wie es ist nicht wirklich weh, aber in einem separaten Modul oder wenigstens nur im TRX_ELSE hätte ich es besser gefunden.

Für die Zukunft sollten wir uns darauf einigen, dass nur mit RFXCOM(Bert) abgestimmte Protokolle implementiert werden. Vielleicht auch vor der Implementierung eines Patchs diesen hier 1-2 Wochen zu diskutieren.

Grüße Markus

RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

KernSani

Hi Markus,

danke für die (zumindest teilweise) berechtigte Kritik. Ich habe den Eindruck du steckst wesentlich tiefer in den TRX-Modulen drin als ich (aber das kann ja noch werden ;)). Ich finde deinen Vorschlag gut, Patches zunächst hier zum testen zur Verfügung zu stellen gut und werde das in Zukunft so handhaben. 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.

Grüße,

Oli
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

KölnSolar

#9
Hi Oli,
ZitatEine 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.  ???
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

KernSani

HI Markus,

danke für die ausführliche Erläuterung. Ich fasse mal kurz (und vielleicht etwas verallgemeinert) mein Verständnis kurz zusammen:

1. Es gibt Protokolle die von RFXCOM/Bert offiziell unterstützt werden und in FHEM implementiert sind, die dann in den entsprechenden Device Module landen (_LIGHT, WEATHER, _SECURITY)
2. Es gibt Protokolle die von RFXCOM/Bert offiziell unterstützt werden und nicht in FHEM implementiert sind, die in TRX_ELSE landen
3. Es gibt Protokolle die von RFXCOM verstanden werden, aber nicht offiziell unterstützt werden. hier gibt es die Varianten:
3a Protokoll eines Herstellers wird für mehrere Gerätetypen genutzt, aber nicht alle sind offiziell von RFXCOM unterstützt (dein Smartwares Beispiel)
3b Protokoll eines Herstellers wird von einem anderen Hersteller "missbraucht" und wird nicht offiziell von RFXCOM unterstützt. (vair Sensoren)

Bei den Geräten von Punkt 3 stellen sich die von dir genannten Fragen:
* Sollen sie von FHEM unterstützt werden? (Meine Meinung: ja - in beiden Fällen)
* In welchem Device-Modul implementieren? (Meine Meinung: schwierig - wahrscheinlich Diskussion im Einzelfall notwendig und ich will nicht ausschließen, dass es dann in Zukunft vielleicht auch ein TRX_OTHERS o.ä. geben muss)
Wenn man den notwendigen Aufwand mal ignoriert: Macht die Trennung der Device-Module überhaupt noch Sinn, oder wäre es mittelfristig besser ein TRX_DEVICE-Modul zu haben, das alles abdeckt?

Wie hast du denn das im Smartwares-Fall gelöst?

Grüße,

Oli

   
 
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

KölnSolar

Hi Oli,
den 3a-Fall würd ich eher als 1b Fall sehen. Die Infos kommen ja von RFXCOM. Vielleicht ist es nur "vergessen" worden, den devicetype in die Doku(Guide) aufzunehmen.  :-\

ZitatWenn man den notwendigen Aufwand mal ignoriert: Macht die Trennung der Device-Module überhaupt noch Sinn, oder wäre es mittelfristig besser ein TRX_DEVICE-Modul zu haben, das alles abdeckt?
Tja... Machen 2-stufige Module überhaupt Sinn ? Warum ist der CUL so organisiert(2-stufiges Modell) ? Ich denke die Frage ist schon fast philosophisch....
Meiner Meinung nach macht die Trennung Sinn
1. TRX_Light: Aktoren, die schalten können (die Bezeichnung TRX_SWITCH fänd ich treffender)
2. TRX_WEATHER: Sensoren, die Temp, Hygro, pressure, wind speed, weight messen und senden(komplexe Sensor-Informationen;TRX_SENSOR ?)
3. TRX_Security: Sensoren, die nur ein/aus bzw. alarm/normal also nur einen Status zurückliefern(TRX_STATE ? od. in TRX_WEATHER/TRX_SENSOR integrieren ?)
4. TRX_ELSE: der "Mülleimer" Bisher eigentlich für die noch nicht in FHEM implementierten RFXCOM-Protokolle. TRX_OTHER fänd ich hier etwas schöner(else klingt so nach Programmiersprache) Hier könnte man dann die 3b)'s z.B. den vair-sensor unterbringen(Nochmal: wenn jemand mit einem "echten" rfxmeter-device kommt, muss auch das "richtige" rfxmeter-rfxcom-Protokoll implementiert werden. Der vair-sensor kann dann nicht mehr offiziell unterstützt werden und ist tot !!!)

Man könnte sich auch neu aufstellen und der Einteilung aus Kapitel 2.2.1 des Guide folgen:
- curtains, shades,.....
- temp., humidity, weather....
- door, window, other security
- appliance modules, dimmers, relais....
- Remotes
- Chimes
- power, gas, water metering (rfxmeter  ;D)
- Specials

wobei die letzten 4 Gruppen so klein sind, dass man sie zumindest zusammenfassen oder in einer der anderen Gruppen integrieren(z.B. Chimes sind ja auch nur on-/off-Aktoren;max. mit versch. Melodien also ähnlich einem Dimmer) könnte.

ZitatWie hast du denn das im Smartwares-Fall gelöst?
Ich habs dem User damals ins TRX_SECURITY eingebaut. Warum ? Ich konnte ja nicht testen und da fand ich es als Perl-Dummie einfacher in einem kleinen Modul unterzubringen.   8)

Und wo wir einmal philosophisch sind: Lohnt es sich überhaupt noch sich über Umstruktrierungen, Implementierungen von konzeptionellem Unfug(vair-sensor) nachzudenken, diskutieren und aufwändig umzusetzen ?
Der RFXTRX ist in meinen Augen aus FHEM-Sicht ein aussterbender Dino, den es zu füttern und am Leben zu erhalten gilt. Mehr aber auch nicht. Speziell für 433MHz-ASK/OOK sind wir mittlerweile mit Selbstbau-CUL und Signalduino(Open-Source-Entwicklungen aus FHEM heraus) im Umfang der unterstützten Protokolle/Hersteller ebenbürtig. Flexibler  bei neuen devices/Herstellern/Protokollen. Dazu meine Transceiver-Historie:
1. angefangen mit 868MHz-Busware-CUL für FS20
2. nachgelegt mit 433MHz-Busware-CUL für IT-V1 (damals gab es die aculfw noch nicht)
3. mangels Unterstützung von Protokollen durch culfw Umstieg auf RFXTRX
4. der RFXTRX verrichtet weiterhin brav seinen Dienst in meiner Produktivumgebung; Aber mit aculfw od. Signalduino kann ich mittlerweile
auch sämtliche bei mir vorhandenen devices nutzen; Für "Eigenentwicklungen"(also vergleichbar vair-sensor) nutze ich vorhandene/bekannte Protokolle oder lasse mir ein eigenes Protokoll einfallen, das ich im device(Aktor/Sensor), aculfw, 00_CUL umsetzen kann. Wir können Frequenzen, repetition, pulsewidth manipulieren. All das kann man mit dem RFXTRX nicht  :'(

Grüße
Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

KernSani

Zitat von: KölnSolar am 06 April 2018, 09:57:34
Und wo wir einmal philosophisch sind: Lohnt es sich überhaupt noch sich über Umstruktrierungen, Implementierungen von konzeptionellem Unfug(vair-sensor) nachzudenken, diskutieren und aufwändig umzusetzen ?
Der RFXTRX ist in meinen Augen aus FHEM-Sicht ein aussterbender Dino, den es zu füttern und am Leben zu erhalten gilt. Mehr aber auch nicht.
Und da sind wir eigentlich wieder am Anfang... Mehr als füttern und am Leben erhalten hatte ich eigentlich nie vor :)
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

KernSani

Anbei ein kleiner patch von 45_TRX.pm, den ich bei mir schon länger am Laufen hatte. Beim initialisieren (bzw. "reopen") werden ein paar Parameter (die man auch beim Start im Log sieht) als readings weggeschrieben:

firmware: Firmware of the RFXTRX Device
frequency: Frequency and type of the RFXTRX Device
protocols: enabled protocols of the TRX Device

Ist m.E. unkritisch, hätte aber trotzdem gerne, dass mal jemand bei sich testet, bevor ich einchecke.

RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

KölnSolar

Komisch, die 3 readings kommen nicht, obwohl ich Deine Änderung im Source Code sehe :-\

RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt