RFM-Gateway: A radio-to-WiFi bridge
The RFM-WiFi interfaces a Hope-RF radio module to an ESP8266 microcontroller in order to send or receive data over radio and forward it to a WiFi network. The PCB can be assembled with one of the following radiomodules:
- RFM69C(W) 315 / 433 / 868 / 915 MHz FSK/OOK radio module
- RFM69HC(W) 315 / 433 / 868 / 915 MHz FSK/OOK radio module
- RFM95(W) 868 MHz LoRa module
- RFM96(W) 433 MHz LoRa module
- RFM97(W) LoRa module
- RFM98(W) 433 MHz LoRa module
Features
- Modern USB-C connector for power supply, flashing and UART interface to the ESP8266
- Integrated USB programmer, no need for an additional programmer in order to upload firmware to the ESP8266
- SMA connector for mounting an SMA antenna for the RFM radio module
- Connector for optional 0.96″ I²C OLED display
- Completely SMD assembled (except radio module and SMA and extension-connectors)
- Extension pinheader for I²C
- Extension pinheader for 1-wire bus
- fits in a compact plastic enclosure TEKO 100007, 80 x 56 x 24 mm
Applications
- Bring wireless weathersensors (LaCrosse, …) into your WiFi
- Control RC sockets
- Single channel LoRa-Gateway
- Gateway for open-energy-monitor nodes (emonTH)
- Gateway for mysensors nodes
- Gateway for JeeNodes
- Gateway for nodes based on Moteino
Includes
- PCB with all SMD parts assembled
- SMA connector
- Pin headers for I²C & 1wire
- Plastic enclosure (without cuts für SMA & USB connectors)

Firmware
The RFM-gateway is meant as a open-source-hardware-platform to be used for own projects. When shipped it is preflashed with the inhouse-firmware. Push the button > 3 s in order to bring it into the configuration mode. It will open an access point with ssid RFM-gateway. This password is 12345678. Connect to it and browse to the address http://4.3.2.1. Connect it to your WiFi-network and configure the MQTT settings.


The inhouse firmware has the following capabilities:
433 MHz RC pulse gateway

When the RFM-gateway is assembled with a 433 MHr radiochip it can send & receive the signals of many sockets, remote controls, sensors and more. A (not complete) list of compatible devices can be found here. Received radiodata is translated to MQTT-messages and vice versa. Decoded and unknown received messages are displayed under the „log“ tab in the webinterface:

The log additionally shows the MQTT topic and payload, and the HTTP call in order to generate and send the received message from radio.
Receiving
Received and known protocols are sent using MQTT messages. The addressing parameters are encoded in the MQTT topic. E. g. an intertechno tristate device has the parameters house, group and channel, the topic is home/rfm-gateway/ittristate/A/1/1. The command („on“ or „off“) is available in the payload of the MQTT message. The received data is also sent to the topic home/rfm-gateway/received as a JSON object, for example:
{
"protocol": "ittristate",
"house": 1,
"channel": 1,
"group": 1,
"command": "on"
}
{
"protocol": "intertechno",
"id": 12345,
"channel": 1,
"command": "on"
}
{
"protocol": "pilota",
"id": 12345,
"type": 1,
"channel": 1,
"command": "on"
}
{
"protocol": "emylo",
"id": 12345,
"key": "A"
}
Sending
Commands over radio can be transmitted using 4 different ways:
HTTP GET
The parameters and commands are encoded in the URL. Example for an ittristate device:
http://192.168.178.78/send/ittristate/A/1/1/on switches on the device with housecode A, group 1 and channel 1.
HTTP POST
The parameters and commands are encoded as an JSON object in the HTTP post data sent to the endpoint http://192.178.178.78/send. The JSON data has the same structure as described in the chapter „Receiving“.
MQTT
The parameters need to be encoded in the MQTT topic as described in the chapter „Receiving“, and the part /set has to be appended to the topic. Example topic for a intertechno tristate device: home/rfm-gateway/ittristate/A/1/1/set. The payload can be „on“, „off“ or others, depending on the used protocol.
MQTT JSON
The JSON objects described under chapter „Receiving“ can also be sent to the topic home/rfm-gateway/send in order to control a RF device.
868 MHz sensor gateway
When the RFM-gateway is assembled with the RFM69 868 MHz radiochip it can receive the following sensors and send the received data to a MQTT broker:
- Lacrosse temperature/humidity sensors TX-22, TX-29, TX-35, …
- Voltcraft Energy Count 3000
- Bresser 7-in-1 weatherstation
- EMT7170 energy counter

The data can be fed into homeassistant or other homeautomation software.
868 MHz FS20 gateway
This application sends and receives radio messages from FS20 devices and translates these to MQTT messages and vice versa. Sending and receiving works in a similar way as for 433 MHz RC pulse gateway mode:
{
"protocol": "fs20",
"house": 1,
"address": 1,
"command": "10",
"ext": 8
}
- house: 16-bit (1-65525)
- address: 8-bit address (1-255), nibble = 15 addresses all
- command: String containing the 8-bit or 16-bit HEX-string or „ON“ or „OFF“, or 8-bit or 16-bit integer
- ext: value (optional) for the extension byte, HEX-string or integer
Adding devices to Home Assistant
If a supported device is received a button is displayed on the log page:

By clicking this button a MQTT auto discovery message is sent to Home Assistant wich will add the apropriate controls.
Devices can also be added manually to Home Assistant by adding them to configuration.yaml:
mqtt:
switch:
- name: "Test Switch"
command_topic: "home/rfm-gateway/ittristate/A/1/1/set"
state_topic: "home/rfm-gateway/ittristate/A/1/1"
payload_on: "ON"
payload_off: "OFF"

Shop
Links
Git repository with hardware and inhouse firmware

Hallo Herr Seegel,
leider wird keiner meiner 5 verschiedenen FS20-Sender empfangen. Das Gateway müsste ok sein, denn jeelink-Sender werden empfangen und an meinen MQTT-Server weitergeleitet. Im Log wird nichts angezeigt. Sende ich eine json-Message, wird im Log der Empfang bestätigt aber weiter geschieht nichts. Die FS20 Applikation ist eingestellt. Die FS20-Sender werden an verschiedenen Geräten empfangen, die können nicht die Ursache sein. Zur Info: Deren Frequenz ist laut Datenblatt 868,35 MHz. Was könnte ich tun?
Mit freundlichen Grüßen
Hans-Werner Hollarek
Hallo,
ich schau mal näher in die Firmware rein, vermutlich stimmt da etwas nicht.
Super, vielen Dank!
Was mir noch aufgefallen ist: Es gibt nach Hauscode, Addresse und Kommando noch eine Erweiterung mit einem Byte. Wird die ebenfalls unterstützt?
Ach ja – comand oder command?
Ich verwende seit Langem diesen: https://media.elv.com/file/103866_fs20_wue.pdf, mit einem ATMega328 und in BASCOM programmiert.
Viele Grüße
Hans-Werner Hollarek
hawe (*) hawehollarek.de
Ab sofort steht Firmware v2.0 zur Verfügung, damit sollte es mit den FS20 Komponenten klappen:
https://github.com/Phunkafizer/RFM-gateway/releases/tag/v2.0
Vielen Dank Herr Seegel,
mit der neuen Firmware wird einer meiner Sender jetzt korrekt empfangen, die anderen verwenden das Erweiterungsbyte. Das ist aber nicht so wichtig.
Viele Grüße
Hans-Werner Hollarek
Prima! Das Erweiterungsbyte sollte eigentlich auch funktionieren, habe aber keinen Sender um das zu testen. Kommt im Log etwas an?
Ja, im log:
RAW: 7 8 7 8 7 8 7 8 7 8 7 8 7 8 7 8 7 8 7 8 7 8 7 8 11 12 7 8 7 8 11 12 11 12 7 8 11 12 11 12 7 8 7 8 7 8 7 8 11 12 11 12 7 8 11 4 11 12 7 8 7 8 7 8 7 8 7 8 7 8 7 8 11 12 11 12 11 12 11 12 7 8 7 8 11 12 11 12 11 12 7 8 7 8 11 12 7 8 7 8 7 8 7 8 7 8 7 8 7 8 11 12 7 8 11 12 11 12 7 8 11 12 11 12 7 8 11 12 7 8 7 8 7 8 7 120
Hauscode:
dez 54 54
hex 36 36
Adresse:
hex 07
Befehl:
hex 39
Erweiterung:
hex 02
aber kein rec.
Danke für das Log! Mit v2.1 müsste nun auch das ext Byte gehen!
https://github.com/Phunkafizer/RFM-gateway/releases/tag/v2.1
Ja, geht jetzt.
Log:
Rec. MQTT ~/FS20/13878/7: f39
Rec. MQTT ~/received: {„house“:13878,“address“:7,“command“:“f39″,“protocol“:“FS20″}
Das „f“ im Command ist die ext.
Ich möchte nicht unverschämt sein, aber schöner wäre {„house“:13878,“address“:7,“command“:39,“ext“:15}
Vielen Dank für Ihre Bemühungen
Liebe Grüße
Hans-Werner Hollarek
Was ich noch festgestellt habe:
Sende ich im Browser z.B. „http://192.168.178.57/send/FS20/13878/7/e39“, wird ein Signal gefunkt.
Das Log dazu:
RAW: 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 12 12 8 8 8 8 12 12 12 12 8 8 12 12 12 12 8 8 8 8 8 8 8 8 12 12 12 12 8 8 12 12 12 12 8 8 8 8 8 8 8 8 8 8 8 8 8 8 12 12 12 12 12 12 12 12 8 8 8 8 12 12 12 12 12 12 8 8 8 8 12 12 8 8 8 8 8 8 8 8 8 8 12 12 12 12 12 12 8 8 12 12 12 12 12 12 8 8 8 8 8 8 8 8 8 8 8 8 8 8 1 120
Im MQTT-Explorer kann ich senden, was ich will, es wird nichts gefunkt.
Beispiel:
Topic:
rfmgw/FS20
json:
{
„house“:13878,
„address“:7,
„command“:“e39″
}
Log:
Rec. MQTT ~/FS20: { „house“:13878, „address“:7, „command“:“e39″ }
oder
{
„house“:13878,
„address“:7,
„command“:e39
}
Log:
Rec. MQTT ~/FS20: { „house“:13878, „address“:7, „command“:e39 }
Der Grund des Ganzen:
Ich möchte gerne meine vorhandenen Sender mit OPENHAB weiter nutzen.
Viele Grüße und Dank
Hans-Werner Hollarek
Das ist kein Problem, siehe v2.2. Doku ist auch korrigiert. Topic muss „home/rfm-gateway/send“ sein, Payload z. B.
{„protocol“:“FS20″, „house“:13878, „address“:7, „command“:39, „ext“: 15}
Nochmal vielen herzlichen Dank!
Es funktioniert jetzt perfekt mit
Topic: home/rfm-gateway/send
Payload z.b.: {„house“:13878,“address“:7,“command“:“39″,“ext“:“F“,“protocol“:“FS20″}
Viele Grüße
Hans-Werner Hollarek
Hallo Hr Seegel,
Können sie mir sagen, ob von dem RFM-Gateway die Technoline TX35DTH-IT Temp. Sensoren unterstützt werden. Ich wollte mit dem Gateway meinen alten JeeLink in Verbindung mit FHEM ersetzen. Ich denke, ich habe das richtige RFM-Gateway – RFM69CW 868 bestellt und auch passend konfiguriert. Bekomme aber keine Daten ihm log und auch nicht im MQTT Broker angezeigt. Da ich schon kurz zufällig einige RAW Daten im log gesichtet habe, schließe ich einen Hardware defekt aus. Wie könnte ich den Fehler weiter eingrenzen ?.
Mit freundlichem Gruß, Josef
Ja das TX35DTH wird unterstützt, die Logausgabe sollte in etwa so aussehen:
Switch to mode 1, 9579 bit/s, synclen 2
RFM payload: 91 86 12 23 40 -69 dBm
LaCrosse ID 18, 21.20 °C, 35 %, bat ok
RFM payload: 99 85 90 26 99 -59 dBm
LaCrosse ID 98, 19.00 °C, 38 %, bat ok
RFM payload: 90 86 04 24 78 -56 dBm
LaCrosse ID 8, 20.40 °C, 36 %, bat ok
Switch to mode 1, 9579 bit/s, synclen 2
RFM payload: 91 86 12 23 40 -69 dBm
LaCrosse ID 18, 21.20 °C, 35 %, bat ok
RFM payload: 99 85 90 26 99 -59 dBm
LaCrosse ID 98, 19.00 °C, 38 %, bat ok
RFM payload: 90 86 04 24 78 -55 dBm
LaCrosse ID 8, 20.40 °C, 36 %, bat ok
Switch to mode 1, 9579 bit/s, synclen 2
RFM payload: 91 86 12 23 40 -69 dBm
LaCrosse ID 18, 21.20 °C, 35 %, bat ok
RFM payload: 99 85 90 26 99 -59 dBm
LaCrosse ID 98, 19.00 °C, 38 %, bat ok
RFM payload: 90 86 04 23 ef -56 dBm
LaCrosse ID 8, 20.40 °C, 35 %, bat ok
RFM payload: 90 86 04 24 78 -56 dBm
LaCrosse ID 8, 20.40 °C, 36 %, bat ok
Switch to mode 1, 9579 bit/s, synclen 2
RFM payload: 91 86 12 23 40 -69 dBm
LaCrosse ID 18, 21.20 °C, 35 %, bat ok
RFM payload: 99 85 90 26 99 -59 dBm
LaCrosse ID 98, 19.00 °C, 38 %, bat ok
RFM payload: 90 86 04 24 78 -53 dBm
LaCrosse ID 8, 20.40 °C, 36 %, bat ok
Ich schicke Ihnen mal zum Testen ein Ersatzgerät.
Guten Tag Hr. Seegel,
Danke für das Ersatzmodul. Das neue RFM-Gateway funktioniert bestens. Beim alten Modul habe ich versucht, die Firmware neu aufzuspielen und Reset durchzuführen. Es ist mir aber nicht gelungen, das Board zuverlässig zum Laufen zu bringen. Aber das neue ist perfekt. Genau das richtige für meine Home Assistant Integration. Nochmals Danke für die neue Hardware.
Mit freundlichem Gruß, Josef
Hallo,
wie kann/muss ich im Yahka-Adapter (HomeKit) im IO-Broker meine diversen INTERTECHNO-Geräte genau konfigurieren?
Im IO-Broker sind zwar alle Status-Infos über MQTT verfügbar,
aber mein Know-How bzgl. MQTT-Scripting ist leider limitiert.
Danke für ein Feedback
Mit IO-Broker und Yahka kenne ich mich leider nicht aus. Um z. B. eine Intertechno Steckdose mit der ID 12345 Kanal 1 zu schalten muss an das MQTT Topic
home/rfm-gateway/intertechno/12345/1/set
der Payload on der off gesendet werden.
Hallo Herr Seegel,
ich habe die Einrichtung des Gateways und die Integration in Home Assistant gut hinbekommen.
Der Vollständigkeit sollte erwähnt werden dass durch die Angabe einer unique_id der Schalter oder die Lampe Bereichen zugeordnet werden kann.
Ich habe einige ITL-250 Dimmer am laufen welche ich gerne Dimmbar ansteuern möchte.
Leider funktioniert es mit z.B. mit payload_on: „85“ (für 85% der Helligkeit) nicht. Der Dimmer schaltet dann gar nicht ein.
Setze ich statt dessen payload_on: „On“ wird das Licht auf 100% Helligkeit eingeschaltet.
Haben Sie eventuell noch einen Rat für mich wie sich dieses Problem lösen lässt?
Mit freundlichen Grüßen
David Schuster
Hallo Herr Seegel,
ich habe noch ein weiteres Problem im Home Assistant.
Die Schaltzustände der Schalter werden wenn sie über Home Assistant direkt geschaltet werden nicht korrekt angezeigt. Alle in der configuration.yaml von mir angelegten Schalter haben den Zustand „unbekannt“ und springen bei Betätigung wieder zurück auf „Aus“ obwohl die Lampe richtig geschaltet wird, also an ist. Schalte jedoch die gleiche Lampe oder Steckdose mit einem Funkschalter wird plötzlich der Zustand korrekt angezeigt. Es sieht so aus als ob der Schaltzustand wenn über Home Assistant direkt geschaltet wird vom Gateway nicht zurückgegeben wird.
Vielen Dank im Voraus
David Schuster
Es muss das Topic zum setzen und für den Status angegeben werden, hier ein Beispiel:
light:
– name: „Schreibtisch 1“
unique_id: rcpulse-ittri-a-1-1
command_topic: „home/rcpulse/ittristate/A/1/1/set“
state_topic: „home/rcpulse/ittristate/A/1/1“
Ich habe selber leider keine Dimmer um das zu testen. Wenn sie eine Fernbedienung zum dimmen haben, können sie mir den Logmitschnitt von rcpulsegw zusenden wenn mit der Fernbedienung gedimmt wird?
Gibt es eine Möglichkeit um das Somloq Protokoll von Sommer einzubinden und per MQTT an Home Assistant weiterzuleiten? Konkret geht es um einen Garagentor-Öffner TX40-868-4.
Hallo,
ich versuche gerade vergeblich, die aktuelle Firmware herunterzuladen. Der Link zur Git Repository enthält alles, außer ein gültiges Firmware-File. Können sie mir bitte die Firmware 1.4 oder höher zukommen lassen?
Danke und Gruß
Norbert Lübke
Hallo, ich habe eben in Github unter Releases die aktuelle Version 1.4 hochgeladen:
https://github.com/Phunkafizer/RFM-gateway/releases/tag/v1.4
Hallo
Ich möchte das Intertechno Master Gate entsorgen da das Teil immer wieder rumzickt und unendlich Zeit frisst. Lässt sich das RFM Gatway ohne das arbeiten in MQTT im Home Assistant integrieren? Und findet die vorhandenen Intertechno Empfänger quasi von alleine? Mir ist überhaupt nich klar wie ich den ITL3500 Empfänger von Intertechno mit den vier Kanälen mit Zeilen wie oben beschrieben in MQTT bearbeiten müsste.
Danke für Ihre Antwort
Hallo,
den ITL3500 verwende ich selber hier. Dieser kann einfach an Kommandos angelernt werden über die Tasten an den Kanälen. Es gibt 2 Möglichkeiten entsprechende Kommandos mit dem RFM Gateway zu senden. Entweder über einen HTTP Aufruf an das RFM Gateway wie:
http://IP-Adresse/send/ittristate/A/1/1/on
Damit wird z. B. der 1. Kanal (Hauscode A, Gruppe 1) eingeschaltet wenn der 1. Kanal des ITL3500 damit angelernt wird,
http://IP-Adresse/send/ittristate/A/1/2/on
wäre das gleiche für den 2. Kanal.
Alternativ erzeugt eine MQTT Nachricht an das Topic
home/rfm-gateway/ittristate/A/1/1/set mit dem Payload „on“ das gleiche Kommando.
In Home Assistant können sie in der Konfigurationsdatei einfach jeweils einen Switch anlegen der die passende MQTT Nachricht erzeugt. Ich werde den Blogbeitrag noch um ein Konfigurationsbeispiel ergänzen.
Backup…
Hatte Herrn Seegel mein Problem mit dem verbummelten Zugang per Mail geschildert.
Ein Tag später war eine versprochene Lösung online (s. Git Repository oben). Die beinhaltet
nun ein Restore des Auslieferungszustands nach Drücken des Reset-Tasters für 10 Sekunden.
Das nenne ich Kundenorientierung!!!
Mit freundlichem Gruß,
Michael Märker
Hallo Herr Seegel,
kann mich auf meinem rfm-gateway nicht mehr anmelden, da mein Sohn mit dem Gateway „rumgespielt“ hatte.
Können Sie mir einen Weg nennen, um den Auslieferungszustand wiederherzustellen?
Mit freundlichem Gruß,
Michael Märker