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

KernSani

Hast du ein reopen oder Neustart gemacht?


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

KölnSolar

Ich hatte geahnt, dass die Frage kommt  ;D Natürlich  8)

Aber das Problem ist ein anderes. Ich hatte schon an mir gezweifelt und alles mögliche probiert.

Du hast es nur für die neue firmware-version eingebaut.  :(

Das ist etwas sehr unglücklich/unübersichtlich im source code gelöst. Guck Dir das mal ab Zeile 267 an. Endlos viele Zeilen je Version. Tatsächlich unterscheiden sich die beiden firmwares aber nur in Zeile 334/378/379(zusätzlich) und 350/352(modifiziert).
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

neuer Versuch... bei mir läufts (aber ich habe ja auch die neue Firmware ;)).
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

KölnSolar

bei mir jetzt auch(mit alter firmware)  ;D
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

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

KölnSolar

Hi Oli,
hab jetzt nach einem reboot folgende unschöne Logmeldungen gesehen:
2018.04.26 08:19:32 1: PERL WARNING: Use of uninitialized value $msg6 in bitwise and (&) at ./FHEM/45_TRX.pm line 336, <$fh> line 183.
2018.04.26 08:19:32 1: PERL WARNING: Use of uninitialized value $msg6 in bitwise and (&) at ./FHEM/45_TRX.pm line 337, <$fh> line 183.

$msg6 müsste auch für firmware1 initialisiert werden.
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

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

Wolfgang Hochweller

Frage :
Die Einteilung in verschiedene Typen ( also LIGHT, SECURITY, etc ) macht doch nur Sinn, wenn das Device auch nur einen Typ representiert.
Das ist zwar bei den meisten RFXTRX Devices noch so, aber das aendert sich schnell.
Bei Z-Wave etwa ist das doch wild gemischt, sprich, alles was das Device liefert, landet in einem FHEM Device.
Bei einem Switch geht das sicher prima, bei einem Switch mit Powermeter wird es schon kompliziert, bei einem Tuersensor mit Temperatur und Hygro ....

mi.ke

#23
Hi Oli.

Schön, dass sich wieder jemand dem RFXtrx angenommen hat.

Und natürlich auch gleich eine Frage.

WiKa hat vor langer Zeit eine HardwareHack für die Elro AB440R Fernbedienungen vorgestellt, den ich natürlich umtriebig eingesetzt hatte. Willi hat die Software damals dahingehend angepasst.

Nachdem ich nun nach längerer Zeit mein Produktivsystem upgedatet habe, gingen die Fernbedienungen nicht mehr.

Könntest Du bitte,bitte versuchen, diese wieder zum Leben zu erwecken?

Was ich an Hinweisen geben kann ist, dass es mit der Version 45_TRX.pm 10802 2016-02-12 19:41:38Z wherzig $ funktioniert.

Zitat von: Willi am 15 Mai 2016, 21:11:03
Bitte mach doch mal ein update von fhem und lass das noinit weg.
Die neue Version unterstützt auch die Firmware 1001 und höher mit richtiger Initialisierung.

Grüße

Willi

Ich habe leider nicht rausgefunden, ob die Änderungen im 45_TRX oder in der 46_TRX_LIGHT gemacht worder sind, dafür reicht mein Perl schlichtweg nicht aus.

Wäre echt geil, wenn Du in einer ruhigen Minute mal schauen könntest. Wenn ich Dich irgendwie unterstützen kann, sag bitte Bescheid.

Erstmal vielen Dank und beste Grüße

mi.ke

PS.
Ach so, der RFXtrx ist auf der Firmware Version Type1_1025 und der RFXmgr empfängt die 440R problemlos.
FHEM 5.9 | RPi4 + 5 x RPi(Z) + FB7590 + FB 6890 LTE via LAN und WAN (VPN) verbunden.
2 x CUL868 + 3 x RFXTRX(e) + 6 x HMwLanGW + 4 x z2tGw + 5 x LGW + 2 x IRBlast + CO2 +++
FS20, FHT, FMS, Elro(mod), CM160, Revolt, LGTV, STV, AVR, withings, HM-sec-*, HM-CC-RT-DN, AMAD, PCA301, arlo, Aqara

doman75

hallo,

schön das es wieder einen maintainer gibt. hast du das https://forum.fhem.de/index.php/topic,71568.0.html schon eingebaut, so daß ich 46_TRX_LIGHT.pm wieder mit ins Update nehmen könnte?

Grüße
Swen

KernSani

Hallo zusammen,

ich hatte ein langes FHEM-Sommerloch :-) Aber jetzt bin ich wieder da. Ich habe ein paar fixes eingebaut, nachdem ich intensiv Coding und RFX-Doku gelesen habe.
* Fix für SELECTPLUS von KölnSolar (https://forum.fhem.de/index.php/topic,71568.0.html)
* Fix für RFY Device von yoch (https://forum.fhem.de/index.php/topic,36451)
* Fix der on-for-timer und on-till für PT2262 zurück bringt (ob das auch funktioniert weiß ich nicht so genau)

Ich wäre dankbar, wenn jemand angehängte Version ein bisschen testen würde.

Danke,

Grüße,

Oli

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

KernSani

Zitat von: mi.ke am 31 Juli 2018, 11:58:02
Wäre echt geil, wenn Du in einer ruhigen Minute mal schauen könntest. Wenn ich Dich irgendwie unterstützen kann, sag bitte Bescheid.
Mir ist nicht bewusst, dass ich da was geändert hätte... Wenn ich das richtig ergoogelt habe, kommen bei der umgebauten FB IT-Codes an, richtig?

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

KölnSolar

Hallo Oli,
hab die neue Version mal ins Produktivsystem übernommen. IT funktioniert in V1 u. V3.
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

mi.ke

Zitat von: KernSani am 09 Dezember 2018, 17:39:07
Mir ist nicht bewusst, dass ich da was geändert hätte... Wenn ich das richtig ergoogelt habe, kommen bei der umgebauten FB IT-Codes an, richtig?

Stimmt, hier die Codierung.
https://forum.fhem.de/index.php/topic,9587.msg53630.html#msg53630

Ich hab Dir die "funktionierende" Version von 2016 mal angehängt

Danke und Grüße

mi.ke
FHEM 5.9 | RPi4 + 5 x RPi(Z) + FB7590 + FB 6890 LTE via LAN und WAN (VPN) verbunden.
2 x CUL868 + 3 x RFXTRX(e) + 6 x HMwLanGW + 4 x z2tGw + 5 x LGW + 2 x IRBlast + CO2 +++
FS20, FHT, FMS, Elro(mod), CM160, Revolt, LGTV, STV, AVR, withings, HM-sec-*, HM-CC-RT-DN, AMAD, PCA301, arlo, Aqara

KernSani

Hi mi.ke,

ich habe deine "funktionierende" Version mit meiner letzten Version (45_TRX und 46_TRX_LIGHT) verglichen. Der einzige wesentliche Unterschied ist, dass du noch eine Version hast, die nur die alte Firmware unterstützt...  Könntest du mir
a) einen RAW Export deines TRX_LIGHT Devices anhängen
b) das TRX_LIGHT mal auf verbose 5 stellen, und den Logeintrag (beim drücken der fernbedienung) posten?

Danke,

Grüße,

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

mi.ke

#30
Gerne

Zitat von: KernSani am 14 Dezember 2018, 22:30:55
a) einen RAW Export deines TRX_LIGHT Devices anhängen

Internals:
   DEF        ARC C12 light
   IODev      RFXTRX_433
   LASTInputDev RFXTRX_433
   MSGCNT     1
   NAME       OG_Remote_Buero_B
   NR         2742
   RFXTRX_433_MSGCNT 1
   RFXTRX_433_RAWMSG 07100185430c0170
   RFXTRX_433_TIME 2018-12-17 11:03:48
   STATE      on
   TRX_LIGHT_deviceid C12
   TRX_LIGHT_devicelog light
   TRX_LIGHT_type ARC
   TYPE       TRX_LIGHT
   READINGS:
     2018-12-17 11:03:48   light           on
     2016-03-25 19:44:29   rssi            7
     2018-12-17 11:03:48   state           on
Attributes:
   IODev      RFXTRX_433
   alias      (B) Beleuchtung (Büro)
   group      Fernbedienung
   room       0bergeschoss
   sortby     02
   verbose    5


Zitat von: KernSani am 14 Dezember 2018, 22:30:55
b) das TRX_LIGHT mal auf verbose 5 stellen, und den Logeintrag (beim drücken der fernbedienung) posten?

ON auf der Remote:
2018.12.17 11:03:48 5: TRX_LIGHT_parse_X10() OG_Remote_Buero_B devn=TRX_ARC_C12 first=1 command=on, cmd=01

ON per Website:
2018.12.17 11:19:48 5: TRX_LIGHT_Set() name=OG_Remote_Buero_B device_type=ARC, deviceid=C12 house=67, unit=12 command=on
2018.12.17 11:19:48 5: TRX_LIGHT_Set hexline=07100100430c0100

FHEM 5.9 | RPi4 + 5 x RPi(Z) + FB7590 + FB 6890 LTE via LAN und WAN (VPN) verbunden.
2 x CUL868 + 3 x RFXTRX(e) + 6 x HMwLanGW + 4 x z2tGw + 5 x LGW + 2 x IRBlast + CO2 +++
FS20, FHT, FMS, Elro(mod), CM160, Revolt, LGTV, STV, AVR, withings, HM-sec-*, HM-CC-RT-DN, AMAD, PCA301, arlo, Aqara

KernSani

@mi.ke: Ich habe das nachgebaut und bei mir funktioniert das wunderbar. Der Befehl wird in FHEM empfangen und korrekt verarbeitet (Lampen-Icon leuchtet).

@all: Angehängte Version von TRX_LIGHT unterstützt nun Cuveo Devices. Dazu muss der RFX mit Pro2 firmware geflasht sein (die Einschränkungen bez. anderer Protokolle hat, nachzulesen in Kapitel 2 des RFXCOM User Guides). Unterstützt werden von RFXTRX (und damit in FHEM) Sender (Fernbeidienung, Motion Sensor, Wandschalter, etc...) und Empfänger (Steckdosen).

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

duke24

#32
Hi Oli,

Cuveo empfangen klappt super, jeder Tastendruck wird erkannt, selbst von der anderen Seite des Hauses. Aus FHEM heraus kann ich mit dem empfangenen Code leider nicht senden. Kein Empfänger reagiert.
Welche Infos benötigst Du zur Fehlersuche?

MfG
Daniel

KernSani

Hi Daniel,

Sind die Empfänger an die Sender angelernt?  Mich würde im Prinzip ein verbose 5 log von
1.) Tastendruck auf Sender
2.) Selbes Ereignis aus FHEM

Danke,

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

duke24

#34
Hi Oli,

ja, angelernt sind sie, die Fernbedienung schaltet die Empfänger entsprechend ein und aus und FHEM bekommt das auch mit. Nur wenn ich aus FHEM heraus versuche zu schalten, das funktioniert irgendwie nicht.

Hier die Logs:
Tastendruck an FB

2018.12.22 11:55:17 5: TRX/RAW: / ��p
2018.12.22 11:55:17 5: TRX: TRX_Read '0b150181e812010100000070'
2018.12.22 11:55:17 5: TRX_Read rmsg '0b150181e812010100000070'
2018.12.22 11:55:17 5: TRX_Read TRX_data '0b150181e812010100000070'
2018.12.22 11:55:17 5: TRX_Parse() '0b150181e812010100000070'
2018.12.22 11:55:17 5: rfxtrx: dispatch 0b150181e812010100000070
2018.12.22 11:55:17 5: TRX_LIGHT_Parse() decoding delay=317 hex=0b150181e812010100000070
2018.12.22 11:55:17 5: TRX_LIGHT_Parse() X10 num_bytes=11 hex=0b150181e812010100000070
2018.12.22 11:55:17 5: TRX_LIGHT: device_name=TRX_CUVEO_e81211 data=00
2018.12.22 11:55:17 5: TRX_Read END


Senden über FHEM

2018.12.22 11:56:00 5: rfxtrx sending 0B1501000012010100000070
2018.12.22 11:56:00 5: SW: 0B1501000012010100000070
2018.12.22 11:56:00 5: TRX/RAW: /
2018.12.22 11:56:00 5: TRX: TRX_Read '0402010000'
2018.12.22 11:56:00 5: TRX_Read rmsg '0402010000'
2018.12.22 11:56:00 5: TRX_Read TRX_data '0402010000'
2018.12.22 11:56:00 5: TRX_Parse() '0402010000'
2018.12.22 11:56:00 5: rfxtrx: dispatch 0402010000
2018.12.22 11:56:00 5: TRX_ELSE_Parse() decoding delay=45495 hex=0402010000
2018.12.22 11:56:00 5: TRX_ELSE_Parse() 2 hex=0402010000
2018.12.22 11:56:00 5: TRX_ELSE_Parse() num_bytes=4 hex=0402010000 type=2
2018.12.22 11:56:00 5: TRX_Read END
2018.12.22 11:56:01 5: TRX/RAW: / �`
2018.12.22 11:56:01 5: TRX: TRX_Read '0b1501820012010100000060'
2018.12.22 11:56:01 5: TRX_Read rmsg '0b1501820012010100000060'
2018.12.22 11:56:01 5: TRX_Read TRX_data '0b1501820012010100000060'
2018.12.22 11:56:01 5: TRX_Parse() '0b1501820012010100000060'
2018.12.22 11:56:01 5: rfxtrx: dispatch 0b1501820012010100000060
2018.12.22 11:56:01 5: TRX_LIGHT_Parse() decoding delay=44 hex=0b1501820012010100000060
2018.12.22 11:56:01 5: TRX_LIGHT_Parse() X10 num_bytes=11 hex=0b1501820012010100000060
2018.12.22 11:56:01 5: TRX_LIGHT: device_name=TRX_CUVEO_001211 data=00
2018.12.22 11:56:01 5: TRX_Read END


MfG
Daniel

KernSani

Hi Daniel,

kannst du auch noch ein ,,list" des TRX_Light devices mit anhängen?
Danke,
Oli


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

duke24

Ich hoffe das ist, was Du meinst:

Internals:
   CFGFN     
   DEF        CUVEO e81211 light
   IODev      rfxtrx
   LASTInputDev rfxtrx
   MSGCNT     50
   NAME       TRX_CUVEO_e81211
   NR         38
   STATE      off
   TRX_LIGHT_deviceid e81211
   TRX_LIGHT_devicelog light
   TRX_LIGHT_type CUVEO
   TYPE       TRX_LIGHT
   rfxtrx_MSGCNT 50
   rfxtrx_RAWMSG 0b150114e812010101050070
   rfxtrx_TIME 2018-12-22 17:43:03
   READINGS:
     2018-12-22 17:43:03   light           off
     2018-12-22 17:43:03   state           off
Attributes:
   IODev      rfxtrx
   room       TRX_LIGHT

KernSani

Hi Daniel,

kannst du angehängte Version nochmal probieren? Hatte einen blöden Bug mit der Hex-Konvertierung der bei mir nicht aufgefallen ist, da meine test-Devices zufällig alle numerische IDs bekommen hatten...

Grüße,

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

duke24

Hi Oli,

läuft soweit :). Senden klappt, empfangen klappt, ich werde dann über die Feiertage mal ein paar weitere Sachen probieren wie Bewegungsmelder, Helligkeitssensor und was ich noch da habe. Melde mich, falls etwas nicht klappt.

MfG
Daniel

KernSani

Hi Daniel,
danke für's testen. Freut mivh, dass es läuft. Bewegungssender wird sich wie ein Schalter verhalten (also on und off schicken). Helligkeitssensor wird wahrscheinlich nicht funktionieren, zumindest gibt das RFXCOM SDK dazu nichts her. Auf Basis der RAW Messages können wir aber vielleicht was basteln.
Schöne Feiertage!
Oli


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

duke24

Hallo Oli,

hab jetzt Bewegungsmelder und Helligkeitssensor vom CUVEO Sytem getestet. Beide senden nur ON und OFF, funktionieren also bestens. Einen Empfänger nur an FHEM anlernen, mit ausgedachtem Code klappt auch.
Bis jetzt sind noch keine Fehler oder ungewollten (nicht)Schaltungen aufgetreten. Top und Danke für die Einbindung in FHEM.

MfG
Daniel

KernSani

Danke für's testen :-)
Habe jetzt beide (TRX und TRX_LIGHT) eingecheckt, sollten also morgen mit dem regulären Update zur Verfügung stehen.
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...