Vorstellung: HB-RF-MOD - alternative RPI-RF-MOD PCB

Entwicklung und Bau von Hardware aller Art, die im HM-Umfeld eingesetzt werden kann

Moderator: Co-Administratoren

Benutzeravatar
jmaus
Beiträge: 7631
Registriert: 17.02.2015, 14:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Dresden
Hat sich bedankt: 244 Mal
Danksagung erhalten: 878 Mal
Kontaktdaten:

Re: Vorstellung: HB-RF-MOD - alternative RPI-RF-MOD PCB

Beitrag von jmaus » 21.11.2020, 15:46

jp112sdl hat geschrieben:
21.11.2020, 14:28
Spätestens wenn eQ-3 auf die Idee kommt, nur noch das RPI-RF-MOD zu unterstützen, den multimacd/rfd rauszuschmeißen und alles über ihre closed-source HMIPServer-Java-Applikation zu machen, hat Homematic an Attraktivität für mich ohnehin verloren.
Also ersteres (nur noch Unterstützung des RPI-RF-MOD) ist ja quasi teilweise bereits passiert wie man an HmIP-Wired und HmIP-HAP sieht. Ich bezweifle auch das noch weitere Firmware-Updates für das HM-MOD-RPI-PCB kommen werden. Letzteres (multimacd, rfd) abkündigung bezweifle ich einfach ganz stark, denn es werden die alten BidCos-RF Geräte ja weiterhin unterstützt und sie sind noch weit von der Vielfalt der alten Geräte entfernt. Insofern hast du mit deinem PCB alles richtig gemacht und bist wieder etwas zukunftssicherer!
RaspberryMatic 3.59.6.20210911 @ ESXi – ~195 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker – GitHub / Twitter / Facebook / Sponsors

MathiasZ

Re: Vorstellung: HB-RF-MOD - alternative RPI-RF-MOD PCB

Beitrag von MathiasZ » 21.11.2020, 17:58

@jp112sdl
Dazu habe ich auch alle ehemaligen Raspberrymatic-versionen auf der Festplatte.
Sollte eq3 wirklich auf die dumme Idee kommen, muß ich eben auf eine vorherige Raspberrymatic umsteigen, bzw diese zusätzlich nur für AskSin++ Geräte aufbauen soweit es Dein Addon zuläßt. Zusammenfassen kann man sie ja wieder über IObroker.
Und ja, es macht Sinn. Wenn man das ganze umbaut, kann der User nur den Plunder anlernen, den man selber verkauft hat. :evil:
Die Platine schaut gut aus! Im Moment habe ich (leider) keine Komm-Störungen.

jp112sdl
Beiträge: 9352
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 573 Mal
Danksagung erhalten: 1335 Mal
Kontaktdaten:

Re: Vorstellung: HB-RF-MOD - alternative RPI-RF-MOD PCB

Beitrag von jp112sdl » 23.11.2020, 12:33

Die RGB LED habe ich dann jetzt auch für meine Zwecke umgebogen.

Grün an: System ok (keine Alarme/Servicemeldungen)

Rot an: Servicemeldungen vorhanden
Rot blink: Alarmmeldungen vorhanden (übersteuert Servicemeldungen, da wichtiger)

Blau:
- aus = DC ok
- an = DC > 60%
- blink = DC > 90%

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

PN sind deaktiviert!

maxx3105
Beiträge: 257
Registriert: 19.10.2018, 16:07
Hat sich bedankt: 126 Mal
Danksagung erhalten: 40 Mal

Re: Vorstellung: HB-RF-MOD - alternative RPI-RF-MOD PCB

Beitrag von maxx3105 » 17.01.2021, 17:50

jp112sdl hat geschrieben:
21.11.2020, 10:31
jmaus hat geschrieben:
21.11.2020, 10:14
Daher würde mich in der Tat interessieren inwieweit hier das Verzichten auf die Stromversorgung via GPIO einen negativen Einfluss darauf hat oder ob das in irgendeinerweise vllt auch negative effekte für den RaspberryPi (gerade bei Lastspitzen) bringt.
Für mich sieht es so aus, als hätte man den Hohlstecker nur gewählt, um
a) keinen fummeligen USB-Micro Stecker zu nutzen (CCU2 hat auch den Hohlstecker, HAP hat den Hohlstecker,... Corporate Design 8) ) und
b) um ihn genau dort im Gehäuse platzieren zu können.
Die USB Buchse am Raspberry ist (aus eQ-3 Sicht) für das Produktdesign an einer ungünstigen Stelle gewesen

Die 3.3V Spannungserzeugung für das TRX-Modul erfolgt direkt auf der Platine (aus der Spannung vom Netzteil) und wird nicht wie beim HM-MOD-RPI-PCB vom RaspberryPi abgezwackt.

Ohne den Verpolschutz-MOSFET wären der 5V-Pin der Micro-USB-Buchse am Raspberry und der Hohlstecker-Pin 1:1 verbunden.
Hallo Jerome, überlege nun ob ich deine Platine bestellen soll. Hast du Probleme bzw. Einschränkungen mit der Platine bemerkt (Stromversorgung, Empfang)? Finde kein passendes Hutschienen-Gehäuse für den RasPi 4.

jp112sdl
Beiträge: 9352
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 573 Mal
Danksagung erhalten: 1335 Mal
Kontaktdaten:

Re: Vorstellung: HB-RF-MOD - alternative RPI-RF-MOD PCB

Beitrag von jp112sdl » 17.01.2021, 18:06

maxx3105 hat geschrieben:
17.01.2021, 17:50
Einschränkungen mit der Platine bemerkt (Stromversorgung, Empfang)?
Nein, ganz und gar nicht.

Aber
maxx3105 hat geschrieben:
17.01.2021, 17:50
RasPi 4.
ist halt eine sehr schlechte Wahl für ein direkt verbautes Funkmodul. Egal ob das originale oder mein "umgedrehtes"

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

PN sind deaktiviert!

maxx3105
Beiträge: 257
Registriert: 19.10.2018, 16:07
Hat sich bedankt: 126 Mal
Danksagung erhalten: 40 Mal

Re: Vorstellung: HB-RF-MOD - alternative RPI-RF-MOD PCB

Beitrag von maxx3105 » 17.01.2021, 18:12

jp112sdl hat geschrieben:
17.01.2021, 18:06
Aber
maxx3105 hat geschrieben:
17.01.2021, 17:50
RasPi 4.
ist halt eine sehr schlechte Wahl für ein direkt verbautes Funkmodul. Egal ob das originale oder mein "umgedrehtes"
Trotz herausgeführter Antenne eher ein abgesetztes Modul verwenden?

jp112sdl
Beiträge: 9352
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 573 Mal
Danksagung erhalten: 1335 Mal
Kontaktdaten:

Re: Vorstellung: HB-RF-MOD - alternative RPI-RF-MOD PCB

Beitrag von jp112sdl » 17.01.2021, 18:17

Erfahrungswerte kann ich dir leider keine bieten, aber nach dem was man hier so liest... würde ich beim Pi 4 das komplette Funkmodul weit weg packen.

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

PN sind deaktiviert!

ivo-int
Beiträge: 167
Registriert: 13.04.2020, 08:55
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 14 Mal
Danksagung erhalten: 10 Mal

Re: Vorstellung: HB-RF-MOD - alternative RPI-RF-MOD PCB

Beitrag von ivo-int » 18.01.2021, 08:06

maxx3105 hat geschrieben:
17.01.2021, 18:12
Trotz herausgeführter Antenne eher ein abgesetztes Modul verwenden?
jp112sdl hat geschrieben:
17.01.2021, 18:17
Erfahrungswerte kann ich dir leider keine bieten, aber nach dem was man hier so liest... würde ich beim Pi 4 das komplette Funkmodul weit weg packen.
Aber ich habe Erfahrungswerte. Mit abgesetztem Modul treten fast keine Funkstörungen mehr auf.

Es ist mehr ein gefühlter Wert da ich es auch nicht ins Detail verfolgt habe. Vor dem Absetzen hatte ich in der Regel mehrere Unreach Meldungen pro Tag. Jetzt ca 1 pro Monat. Obwohl seit der Absetzung mehr Geräte im Funknetzt sind.
_______________________________________________________________________________________________________
Raspberrymatic auf einem Raspi 4 4GB (HB-RF-USB-2) mit 2 LAN Gateways,
42 RF Geräte, 5 IP Geräte und 21 Cuxd Geräte, 22 RF Eigenbau Geräte
hm_pdetect, E-Mail, XML-API, JB HB Devices, HB-TM-Devices-AddOn, CUx-Daemon, CCU-Historian auf einem separaten Raspi

turrican944
Beiträge: 377
Registriert: 29.05.2019, 22:19
Wohnort: Bargfeld
Hat sich bedankt: 3 Mal
Danksagung erhalten: 26 Mal

Re: Vorstellung: HB-RF-MOD - alternative RPI-RF-MOD PCB

Beitrag von turrican944 » 05.08.2021, 22:32

Moin
Ich glaube ich muss mir die Platine auch mal bauen, da mitlerweile das Funkmodul am USB Adapter hängt ist soviel Platz im Gehäuse, dann könnte ich wieder ein Raspi Gehäuse nehme und die RTC kann ich auch gleich weglassen, weil die über die HB RF USB2 eh nicht benutzt wird. RTC hat das Odroid N2 Board eh.
Ich glaube ich muss mal wieder eine JLC Bestellung fertig machen.
Gruß Florian

turrican944
Beiträge: 377
Registriert: 29.05.2019, 22:19
Wohnort: Bargfeld
Hat sich bedankt: 3 Mal
Danksagung erhalten: 26 Mal

Re: Vorstellung: HB-RF-MOD - alternative RPI-RF-MOD PCB

Beitrag von turrican944 » 14.08.2021, 12:39

Moin
jp112sdl hat geschrieben:
23.11.2020, 12:33
Die RGB LED habe ich dann jetzt auch für meine Zwecke umgebogen.

Grün an: System ok (keine Alarme/Servicemeldungen)

Rot an: Servicemeldungen vorhanden
Rot blink: Alarmmeldungen vorhanden (übersteuert Servicemeldungen, da wichtiger)

Blau:
- aus = DC ok
- an = DC > 60%
- blink = DC > 90%
Wie geht das mit den LEDs ?
Gruß Florian

Antworten

Zurück zu „Hardwareentwicklung und Selbstbau von Aktoren und Sensoren“