Erweiterung des FHEM-Systems

Begonnen von fhemjan, 09 November 2022, 14:51:52

Vorheriges Thema - Nächstes Thema

fhemjan

Hallo,
ich habe mal zwei allgemeine Fragen, die beide in eine ähnliche Richtung abzielen. Setup ist ein Rasp4 mit fhem-docker, dazu ein nanoCUL868 von busware für Homematic und ein CUL433 im Selbstbau, z.B. für IT.

  • Wenn die Sendeleistung des 868 nicht ausreicht für alle Ecken im Haus, was gibt es für Möglichkeiten die Sendeleistung zu erhöhen? Kann man einen zweiten Raspberry mit einem CUL betreiben, die dann aber in der gleichen FHEM-Instanz arbeiten? Oder müsste man eine zweite FHEM-Instanz aufsetzen? Fänd ich nicht so schön...
  • Was kann man tun wenn die USB-Plätze des Raspberrys voll sind und man ein weiteres Gateway nutzen möchte? Gibt es Möglichkeiten zur Erweiterung?

Beide Szenarien sind zum Glück noch nicht akut, aber ich weiß gern worauf ich mich einlasse wenn ich mich auf ein System festlege :D

Beta-User

Zitat von: fhemjan am 09 November 2022, 14:51:52
Wenn die Sendeleistung des 868 nicht ausreicht für alle Ecken im Haus, was gibt es für Möglichkeiten die Sendeleistung zu erhöhen? Kann man einen zweiten Raspberry mit einem CUL betreiben, die dann aber in der gleichen FHEM-Instanz arbeiten? Oder müsste man eine zweite FHEM-Instanz aufsetzen? Fänd ich nicht so schön...
Softwareseitig: ggf. die Sendeleistung anheben.
Hardwareseitig: ggf. eine bessere Antenne anschließen und/oder das Dongle etwas weiter absetzen, damit es nicht den E-Smog vom Pi direkt abbekommt.

Zusätzliche IO's sind bei CUL_HM nicht das große Problem, Stichwort wäre VCCU. Für abgesetzte IO's solltest du aber überlegen, was anderes wie einen CUL zu nehmen (das Pi-PCB des Herstellers, z.B.). Für USB-Dongles an entfernten Linuxen gäbe es u.a. "ser2net". (Sollte alles im Wiki zu finden sein).

ZitatWas kann man tun wenn die USB-Plätze des Raspberrys voll sind und man ein weiteres Gateway nutzen möchte? Gibt es Möglichkeiten zur Erweiterung?
Theoretisch: einen USB-Hub verwenden. Praktisch sollte man überlegen, ob es ein aktiver sein soll. (zumindest ältere PI hatten ein Problem mit der Spannungsversorgung ihrer USB-Schnittstelle).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

MadMax-FHEM

Ich würde schon mal gar keinen CUL für Homematic nehmen/genommen haben ;)

Suchbegriffe: Timeout register read
(und wenn unbedingt CUL: Timing-FW plus "Spezial-Module")

Bei Homematic Classic ist eine Funkerweiterung einfach möglich:

vccu definieren (wenn nicht eh schon vorhanden: sollte man haben)
https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU

Darunter dann weitere Funkmodule (Reihenfolge nach "Qualität"):

Homematic Funk LAN-Gateway (gibt aber nicht mehr viele? Und teuer?)
HMOD-PCB per LAN-Adapter
HMOD-PCB per WLAN-Adapter
(CUL mit LAN-/WLAN-Adapter)

Statt LAN/WLAN-Adapter geht nat. auch ein PI mit socat/ser2net ist aber halt teuer und verbraucht unnötig Strom.
Fhem muss dort nicht sein...
...ginge aber nat. auch ;)

Beantwortet ja auch die Frage: was wenn USB-Plätze ausgehen 8)

https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Beta-User

Hehe, doppelt genäht hält wohl besser...

Nachbrenner: Falls du dein System mit Homematic-Classic-Komponenten erweitern willst, mußt du dich sputen.... Der Hersteller bietet nicht mehr (immer) alles an und pusht lieber sein HM-IP-Zeug in den Markt. Dazu gibt es aber auch schon hinreichend Diskussionen (auch zu Alternativen) usw. usf.. Bruachen wir hier mAn. nicht nochmal vertiefen, es gab keine wesentlichen Neuigkeiten auf dem Markt (abgesehen davon, dass es unglaublich viel relativ günstiges ZigBee-Zeug in China direkt zu erwerben gibt und die Variantenvielfalt einen erschlagen kann...).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

betateilchen

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

MadMax-FHEM

Zitat von: betateilchen am 09 November 2022, 17:32:11
oh, ein Popcorn Thread

Ganz schön spendabel in letzter Zeit... ;)

Aber ich würde was nehmen :)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

fhemjan

Hallo zusammen,
besten Dank schon mal für die Antworten.

Zitat von: MadMax-FHEM am 09 November 2022, 15:02:43
und wenn unbedingt CUL: Timing-FW plus "Spezial-Module"
Das Thema liegt mir schon länger am Herzen und will mal angegangen werden. Gleichzeitig bemerke ich deinen Wink, das der CUL eigentlich nicht so das Wahre ist... Verstehe ich richtig, das ich am Raspberry am besten mit einem HM-MOD-RPI-PCB fahren würde für Homematic Classic und dann VCCU einrichten? Es ist einerseits schön dass es so viele Möglichkeiten gibt, andererseits fühle ich mich regelmäßig erschlagen und frage mich was denn nun das Richtige/Beste für meine Anwendungen ist. Prinzipiell finde ich die IP Sachen auch ganz spannend, aber ich denke ich komme mit den Classic Varianten hin und freue mich das ich da mit gebrauchten Sachen etwas Geld sparen kann...

Generell gab es jetzt in euren Antworten recht viele Stichworte die mir zunächst gar nichts sagen, aber viel Angriffsfläche für die Suche bieten. Werde mich also erstmal schlau lesen :)

Zitat von: betateilchen am 09 November 2022, 17:32:11
oh, ein Popcorn Thread
Ich versteh das mal als positives Feedback und hoffe du fühlst dich gut unterhalten  ;D

Adimarantis

ZitatKann man einen zweiten Raspberry mit einem CUL betreiben, die dann aber in der gleichen FHEM-Instanz arbeiten? Oder müsste man eine zweite FHEM-Instanz aufsetzen? Fänd ich nicht so schön...
Du kannst auf jeden Fall einen zweiten Raspi aufsetzen. Der hat zwar dann seine eigene FHEM Instanz, diese lassen sich aber mit dem FHEM2FHEM Modul miteinander verknüpfen. Ich habe auf diese Weise 3 Raspi am Laufen, wobei einer der "Master" ist mit Homematic (mit PiVCCU und dem schon zitierten HM-MOD-RPI-PCB Modul) und RFXTRX433, ein anderer hängt an der Heizung mit viel GPIO Sensoren und ein dritter managed den Pool)
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU)/RfxTrx433XL/Zigbee
Module: 50_Signalbot, 48_HomeConnect, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Sany

Moin,
noch ein paar Gedanken zu Deinem (Zukunfts-)Setup:
Du kannst natürlich Dein Homematic erweitern, z.B. mittels Raspi + HM-MOD-RPI-PCB Modul. Per VCCU in Deinem fhem kannst Du verschiedene I/O quasi parallel nutzen. auf dem Raspi braucht es kein fhem, in diesem Fall kannst Du die Schnittstelle per ser2net->socat an dein haupt-fhem weiterreichen. Ist nur fast ein wenig schade dafür einen Rapsi zu "verschwenden", der kann ja deutlich mehr. Eine Möglichkeit ist, wie schon angesprochen, dort ein fhem laufen zu lassen und nur bestimmte Dinge per fhem2fhem ans haupt-fhem weiterzugeben.
ein weiterer Vorschlag: Debmatic auf dem Raspi laufen lassen. Damit bekommst Du eine CCU3, die Homematic UND homematicIP kann. Dies wird dann allerdings mit HMCCU an fhem angebunden. Das sieht alles etwas anders aus als CUL_HM in fhem, funktioniert aber super. Im Prinzip ist bei der CUL_HM-Geschichte die "Intelligenz" in fhem, an das nur I/Os angeschlossen werden, bei der Debmatic ist diese die "Intelligenz" und stellt die einzelnen Komponenten dann fhem zu Verfügung. Ich habe das bei mir nun schon einige Wochen am laufen, bisher problemlos. Es ist aber im Moment erst mal ein Test, da ich mir noch nicht so ganz klar über die Zukunft bin. Es geht bei mir hauptsächlich um die Heizung: Heizkörperthermostate, Wandthermostate und Fensterkontakte sind alle untereinander gepeert, so dass das ganze ohne fhem läuft. fhem nutze ich nur zu Beeinflussung und Aufzeichung. Da die Bauteile immer weniger erhältich sind/sein werden überlege ich den Umstieg. Mittels CCU3 kann ich die Verknüpfungen auch erzielen, es muss halt dann die CCU3(Raspi) immer sicher laufen, was er aber eigentlich tut. Vorteil: ich kann Stück für Stück die Komponenten umziehen, oder einfach so lassen und bei Ausfall dann durch hmIP ersetzen und die Logik in die CCU3 übernehmen. Reichweitenverlängerung soll über Schaltsteckdosen von hmIP gehen, das wäre dann auch eine Möglichkeit (kann ich aber noch nicht bestätigen).

Um nur einige USB Schnittstellen zu bekommen geht auch ein Raspi Zero 1W mit einem Erweiterungsboard, was 3xUSB und LAN zu verfügung stellt: https://www.amazon.de/gp/product/B07T3D5MQ6/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1
Dort angeschlossene I/Os (getestet mit ConBeeII, Z-Wave und FHZ) lassen sich per ser2net und socat an fhem weiterreichen. Das ganze "boot-fest" per service. Auf dem Raspi Zero W läuft ganz normal ein RaspianOS, Angebunden per LAN. Ich würde für so etwas auch nicht WLAN nehmen, das ist u.U. zu langsam/verzögert, um sinvoll die seriellen Schnittstellen zu übertragen (das habe ich immer mal wieder gelesen, nie selbst probiert.)

ZitatEs ist einerseits schön dass es so viele Möglichkeiten gibt, andererseits fühle ich mich regelmäßig erschlagen und frage mich was denn nun das Richtige/Beste für meine Anwendungen ist.
So geht es mir auch oft. Deshalb freue ich mich immer, wenn Wege aufgezeigt werden, die auch irgendwo schon funktionieren.

Viel Erfolg!


Sany
fhem als LXC auf Proxmox auf einem minix Z100 , weitere LXC mit ZigBee2MQTT, MariaDB und Grafana. Homematic, FS20, mySensors, MQTT2, Tasmota, Shelly, Z-Wave  ....

fhemjan

#9
Vielen Dank für die vielen Ideen. Ich muss zu den Stichworten ser2net und socat gestehen, das ich nur Bahnhof verstehe.. da versuche ich mich gerade noch aufzuschlauen. Die Idee mit Debmatic von @Sany klingt interessant bzgl. der Homematic IP Kompatibilität, aber insgesamt auch etwas experimentell und zeitaufwändig (bedenkt man meinen Wissensstand...).

Mir gefällt vom Gedanken die Idee mit der VCCU sehr, auch bzgl. Redundanz und automatischer Wahl der besten Funkverbindung. Ich hatte schon einmal versucht eine VCCU auf meinem System einzurichten, hab es dann aus Ungeduld und nicht drängender Notwendigkeit erst einmal sein gelassen.

@MadMax-FHEM beschreibt die Reihenfolge so:
Zitat von: MadMax-FHEM am 09 November 2022, 15:02:43
Bei Homematic Classic ist eine Funkerweiterung einfach möglich:

vccu definieren (wenn nicht eh schon vorhanden: sollte man haben)
https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU

Darunter dann weitere Funkmodule (Reihenfolge nach "Qualität"):

Homematic Funk LAN-Gateway (gibt aber nicht mehr viele? Und teuer?)
HMOD-PCB per LAN-Adapter
HMOD-PCB per WLAN-Adapter
(CUL mit LAN-/WLAN-Adapter)

Nun zum Verständnis:
Meine FHEM-Hauptinstanz ist im Erdgeschoss und läuft auf einem Raspi4 im docker Container. Darauf richte ich nun eine VCCU ein und weise ihr meinen CUL zu. Ggf. sollte ich den CUL z.B. mal durch ein HMOD-PCB per LAN-Adapter ersetzen. Soweit ist alles klar. Nun wirds interessant: Ich richte nun auf einem zweiten Pi der im Obergeschoss ist auch FHEM ein. Würde ich ebenfalls im Container machen (ich mag das Docker-Prinzip). Da setze ich nun ein HMOD-PCB per LAN-Adapter drauf und bring ihn in der FHEM-Instanz zum laufen. Wie bekomme ich es nun hin, dass meine VCCU den Adapter auf der zweiten FHEM-Instanz erkennt und nutzt? Über fhem2fhem? Ich hatte gelesen fhem2fhem ist unidirektional.. können dann z.B. von Thermostaten nur Daten empfangen aber nicht gesendet werden? Oder paired man das neue I/O device dann ähnlich wie ein Heizungsthermostat mit FHEM?

Noch eine Frage interessehalber:
Zitat von: MadMax-FHEM am 09 November 2022, 15:02:43
Statt LAN/WLAN-Adapter geht nat. auch ein PI mit socat/ser2net ist aber halt teuer und verbraucht unnötig Strom.
Wieso ist die Variante mit socat/ser2net teuer?

edit:
Habe nun zum Beispiel dieses Modul gefunden: https://de.elv.com/elv-homematic-komplettbausatz-funkmodul-fuer-raspberry-pi-hm-mod-rpi-pcb-fuer-smart-home-hausautomation-142141
Kann das dann sogar Homematic Classic und IP?

MadMax-FHEM

Zitat von: fhemjan am 15 November 2022, 16:42:40
Mir gefällt vom Gedanken die Idee mit der VCCU sehr, auch bzgl. Redundanz und automatischer Wahl der besten Funkverbindung. Ich hatte schon einmal versucht eine VCCU auf meinem System einzurichten, hab es dann aus Ungeduld und nicht drängender Notwendigkeit erst einmal sein gelassen.

@MadMax-FHEM beschreibt die Reihenfolge so:
Nun zum Verständnis:
Meine FHEM-Hauptinstanz ist im Erdgeschoss und läuft auf einem Raspi4 im docker Container. Darauf richte ich nun eine VCCU ein und weise ihr meinen CUL zu. Ggf. sollte ich den CUL z.B. mal durch ein HMOD-PCB per LAN-Adapter ersetzen. Soweit ist alles klar. Nun wirds interessant: Ich richte nun auf einem zweiten Pi der im Obergeschoss ist auch FHEM ein. Würde ich ebenfalls im Container machen (ich mag das Docker-Prinzip). Da setze ich nun ein HMOD-PCB per LAN-Adapter drauf und bring ihn in der FHEM-Instanz zum laufen. Wie bekomme ich es nun hin, dass meine VCCU den Adapter auf der zweiten FHEM-Instanz erkennt und nutzt? Über fhem2fhem? Ich hatte gelesen fhem2fhem ist unidirektional.. können dann z.B. von Thermostaten nur Daten empfangen aber nicht gesendet werden? Oder paired man das neue I/O device dann ähnlich wie ein Heizungsthermostat mit FHEM?

Wenn du eine 2te fhem-Instanz anlegst, dann solltest du dort auch eine andere HMID (also neue/weitere Zentrale) vergeben, bzw.: würde ich das so NICHT machen.
Dadurch würdest du die Redundanz der vccu verlieren!

Da ja ein Teil der HM-Geräte dem einen fhem mit einer HMID (und vccu) "zugewiesen" wären und andere HM-Geräte eben der anderen fhem-Instanz mit anderer HMID (und vccu).
Eine gemeinsame HMID für mehrere fhem-Instanzen führt nur zu Problemen: mehrere "Chefs" sind nicht gut! ;)

Ich würde es so machen, dass der 2te PI nur (ser2net/socat) das HMOD-PCB an die fhem-Instanz mit der vccu durchreicht.
Dadurch selbe HMID, also kann die vccu die redundanten Funk-Dongels verwenden/verwalten :)

Ob dann auf dem 2ten PI trotzdem noch ein fhem für andere Dinge läuft: ok, wenn es Sinn macht...
...aber NICHT für Homematic...


Zitat von: fhemjan am 15 November 2022, 16:42:40
Noch eine Frage interessehalber:Wieso ist die Variante mit socat/ser2net teuer?

Naja, ein PI kostet in der Anschaffung und auch im Betrieb (deutlich) mehr als ein ESP oder ein LAN-TTL-Adapter ;)
Das reicht ja.
D.h. das HMOD-PCB einfach an einen ESP oder LAN-TTL-Adapter, den dann mit Strom versorgen und ins Netzwerk und dann einfach auf dem PI mit fhem in die vccu einbinden...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Beta-User

Zitat von: fhemjan am 15 November 2022, 16:42:40
Ich muss zu den Stichworten ser2net und socat gestehen, das ich nur Bahnhof verstehe..
Beides sind Varianten (für einen Rechner mit Linux-Betriebssystem wie den Pi), um eine serielle Schnittstelle, an der z.B. das jetzt von dir gefundene Bauteil angeschlossen wird, einfach über das Netzwerk verfügbar zu machen, damit ein ANDERER Rechner diese Schnittstelle wie eine eigene ansprechen kann. Das hat nichts mit FHEM2FHEM zu tun. Die VCCU erlaubt es eben, meherere solcher Schnittstellen zu haben und wählt (mehr oder weniger) automatisch die beste aus...

Aber nochmal: Ende des Jahres 2022 mit CUL_HM (bzw. BidCoS-Komponenten) zu planen ist nicht besonders zukunftsorientiert.

Die HMCCU.*-Module kann man wohl kaum mehr als "Experimentell" bezeichnen, und früher oder später wirst du so oder so nicht darum herum kommen, dich in was anderes einzuarbeiten. (Ich selbst bin aber bei eQ-3 raus und habe den Schritt in Richtung ZWave und ZigBee gemacht. Beides auch nicht so ganz einfach, aber im großen und ganzen zu meiner Zufriedenheit operational).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

fhemjan

Zitat von: Beta-User am 15 November 2022, 17:04:55
Aber nochmal: Ende des Jahres 2022 mit CUL_HM (bzw. BidCoS-Komponenten) zu planen ist nicht besonders zukunftsorientiert.
Die HMCCU.*-Module kann man wohl kaum mehr als "Experimentell" bezeichnen, und früher oder später wirst du so oder so nicht darum herum kommen, dich in was anderes einzuarbeiten.
Da hast du sicher Recht. Das "Experimentell" hat sich auch eher auf mich mit meinen aktuellen Kenntnissen bezogen. Ich freu mich ja jedes Mal wie ein kleines Kind wenn ein Sensor dann endlich mal läuft. Wenn ich mir jetzt vorstelle alles noch mal über den Haufen zu werfen... Wird sicher irgendwann passieren, aber aktuell hab ich zuviele andere Baustellen und hab bei FHEM einigermaßen das Gefühl zu wissen was ich tue, bezogen auf meine Wünsche.

Zitat von: MadMax-FHEM am 15 November 2022, 17:00:18
Ich würde es so machen, dass der 2te PI nur (ser2net/socat) das HMOD-PCB an die fhem-Instanz mit der vccu durchreicht.
Dadurch selbe HMID, also kann die vccu die redundanten Funk-Dongels verwenden/verwalten :)
D.h. das HMOD-PCB einfach an einen ESP oder LAN-TTL-Adapter, den dann mit Strom versorgen und ins Netzwerk und dann einfach auf dem PI mit fhem in die vccu einbinden...
Das klingt genau nach dem was ich aktuell suche. Ich tue mich mit dem Thema leider gerade schwer. Es gibt nicht zufällig ein schönes Tutorial für sowas? Ich finde so manches zu dem Thema, aber meist über HM-MOD und nicht HMOD, oder ist das dass Gleiche?

MadMax-FHEM

Zitat von: fhemjan am 15 November 2022, 17:20:47
Das klingt genau nach dem was ich aktuell suche. Ich tue mich mit dem Thema leider gerade schwer. Es gibt nicht zufällig ein schönes Tutorial für sowas? Ich finde so manches zu dem Thema, aber meist über HM-MOD und nicht HMOD, oder ist das dass Gleiche?

Hier sollte alles zu finden sein: https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi

Und dann noch vccu: https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU

EDIT: hatte ich ja schon mal verlinkt https://forum.fhem.de/index.php/topic,130193.msg1244441.html#msg1244441 ;)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

fhemjan

Zitat von: MadMax-FHEM am 15 November 2022, 19:30:56
Hier sollte alles zu finden sein
Ich danke dir, ich war irgendwie etwas blind. Manchmal muss man mir Sachen wohl sehr deutlich zeigen :D
Ich versuche mich mal an der Variante mit HM-MOD-RPI-PCB an einem Serial TTL to Ethernet Module. Verstehe ich es richtig, das man auf dem verlöteten Modul keine Software installieren/flashen muss? Es klingt zu einfach um wahr zu sein.