HB-RF-USB - USB Funkmodul für piVCCU

[deimos]

Hi,

die piVCCU Images sind wieder online, prbier es mal damit.
Ich bin mir nicht sicher, ob Jens alle meine Empfehlungen umgesetzt hat, eine hatte mit den LEDs zu tun und könnte genau zu dem Fehlerbild führen.

Viele Grüße
Alex

[chka]

schon am laden danke

[chka]

leider das gleiche bei dir auch, er bootet den pi und nach einer zeit wird die led auf dem pi-rf-mod gelb und das wars.
wie als würde keine Kommunikation zurück geschehen. da es meine erste größere smd Platine ist denke ich habe da einen Fehler.

habe ja noch eine zweite

Code: Alles auswählen

piVCCU version: 3.41.11-16
Kernel modules: Available
Raw UART dev:   Available
HMRF Hardware:  unknown
HMIP Hardware:  unknown
Board serial:   unknown
Radio MAC:      unknown
SGTIN:          unknown
State:          RUNNING
PID:            599
IP:             192.168.178.208
CPU use:        0.90 seconds
BlkIO use:      3.80 MiB
Link:           vethpivccu
 TX bytes:      1.74 KiB
 RX bytes:      115.68 KiB
 Total bytes:   117.43 KiB

[jmaus]

Ich bin mir nicht sicher, ob Jens alle meine Empfehlungen umgesetzt hat, eine hatte mit den LEDs zu tun und könnte genau zu dem Fehlerbild führen.

In der Tat wird die Ansteuerung der LEDs auf dem RPI-RF-MOD mit deinem HB-RF-USB (noch) nicht in RaspberryMatic unterstützt und daher wird diese mit RaspberryMatic bisher einfach immer konstant geld leuchten. Hier muss ich erst Zeit und einen Weg finden wie ich das transparenz zur CCU3 Firmware tun kann ohne tiefgreifende Umstellungen an den LED spezifischen Kernel Modulen vorzunehmen die momentan an verschiedenen Stellen der CCU Software zur Ansteuerung genutzt werden.

[chka]

mit aufgestecktem pi-rf-mod piVCCU wird in cuxd folgendes angezeigt:

Code: Alles auswählen

  USB 1-1 - (9514) [HUB] - Sun Jan 27 10:14:55 2019
  USB 1-1.1 - (ec00) [FF] - no driver - Sun Jan 27 10:14:55 2019
  USB 1-1.3 - HB-RF-USB [FF] - no driver - Sun Jan 27 10:14:55 2019
  USB 1-1.5 - Microsoft® Nano Transceiver v2.0 [HID] - Sun Jan 27 10:14:55 2019

und mittels lsusb

Code: Alles auswählen

pi@raspberrypi:~ $ lsusb
Bus 001 Device 005: ID 045e:0745 Microsoft Corp. Nano Transceiver v1.0 for Bluetooth
Bus 001 Device 004: ID 0403:6f70 Future Technology Devices International, Ltd 
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

denke aber das es immer noch ein locales problem bei mir ist und nichts mit euren Versionen zu tuen hat

[deimos]

Hi,

das wäre ja ganz einfach. Mein fertiges Kernel Modul nehmen, das hat ja die entsprechende Kompatibilität. Und auch da könnte man bei Bedarf über den Device Tree über einen pinmux dafür sorgen, dass die LEDs bereits beim Starten initial aktiviert werden, nur halt nicht den GPIO LED driver laden, sondern nach der Erkennung des Funkmoduls mein Kernel Modul. Und Farben ändern passiert ja meinem Verständnis nach sowieso erst nach der Erkennung des Funkmoduls.

Viele Grüße
Alex

[deimos]

Hi,

mit aufgestecktem pi-rf-mod piVCCU wird in cuxd folgendes angezeigt:

Code: Alles auswählen

  USB 1-1 - (9514) [HUB] - Sun Jan 27 10:14:55 2019
  USB 1-1.1 - (ec00) [FF] - no driver - Sun Jan 27 10:14:55 2019
  USB 1-1.3 - HB-RF-USB [FF] - no driver - Sun Jan 27 10:14:55 2019
  USB 1-1.5 - Microsoft® Nano Transceiver v2.0 [HID] - Sun Jan 27 10:14:55 2019

und mittels lsusb

Code: Alles auswählen

pi@raspberrypi:~ $ lsusb
Bus 001 Device 005: ID 045e:0745 Microsoft Corp. Nano Transceiver v1.0 for Bluetooth
Bus 001 Device 004: ID 0403:6f70 Future Technology Devices International, Ltd 
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

denke aber das es immer noch ein locales problem bei mir ist und nichts mit euren Versionen zu tuen hat

Die Platine selbst wird per USB erkannt, sonst würde sie nicht gelb leuchten, das wird erst du das Kernel Modul aktiviert. Rein das Funkmodul wird nicht erkannt. Prüf mal durch, ob du am 5V Pin der 40-poligen Leiste Spannung anliegen hast, oder ob da ggf. ein Lötfehler am Mosfet oder an den Pullups ist. Und idealerweise auch mal die RX und TX Pins durchklingeln (wenn die Platine nicht angeschlossen ist).

Viele Grüße
Alex

[jmaus]

das wäre ja ganz einfach. Mein fertiges Kernel Modul nehmen, das hat ja die entsprechende Kompatibilität. Und auch da könnte man bei Bedarf über den Device Tree über einen pinmux dafür sorgen, dass die LEDs bereits beim Starten initial aktiviert werden, nur halt nicht den GPIO LED driver laden, sondern nach der Erkennung des Funkmoduls mein Kernel Modul. Und Farben ändern passiert ja meinem Verständnis nach sowieso erst nach der Erkennung des Funkmoduls.

Ich werde mir das bei Gelegenheit noch einmal näher anschauen. Hat aber momentan recht niedrige Priorität da es IMHO keine fundamental wichtige Funktion ist und die Verbreitung des HB-RF-USB (noch) nicht so groß ist. Problem ist zusätzlich, dass ein Austausch des kernel Modules nur zur Ansteuerung der LED über den HB-RF-USB von eQ3 Seite sicher nicht wirklich wichtig eingestuft wird. Ich sollte daher die Änderungen so gering wie möglich halten, sonst gibt es null Chance, dass die in die CCU3 firmware übernommen werden und RaspberryMatic nach und nach immer mehr von der CCU3 firmware abweichen.

Und momentan werden die LEDs des RPI-RF-MOD in der Tat schon unmittelbar nach dem booten via sysfs zum frühstmöglichen Zeitpunkt auf andere Werte gesetzt (siehe https://github.com/jens-maus/RaspberryM ... t#L97-L106)

[deimos]

Hi,

Und momentan werden die LEDs des RPI-RF-MOD in der Tat schon unmittelbar nach dem booten via sysfs zum frühstmöglichen Zeitpunkt auf andere Werte gesetzt (siehe https://github.com/jens-maus/RaspberryM ... t#L97-L106)

Die verlinkte Code-Stelle setzt die LEDs vom Raspberry und nicht die LEDs vom RPI-RF-MOD.

Die LEDs vom RPI-RF-MOD werden in S02InitRTC, allerdings nur auf gelb, also redundant zum initialen DeviceTree. Danach erst in S11InitRFHardware und da weiß man dann ja, welches Funkmodul genutzt wird. Das blaue blinken kommt erst beim Netzwerk, also deutlich später.
Dass das eigene Kernel Modul einige Vorteile hat, habe ich dir ja bereits erleutert, warum sollte sich eQ-3 daher einer bereits fertigen Lösung wiedersetzen?

Viele Grüße
Alex

[SGubler]

Hallo Alex.

Das klingt ja wie Weihnachten. Ein USB Adapter für das Homematic Funkmodul, das HM und HMIP kann.
Darüber habe ich auch schon nachgedacht, mit dem Ziel, die Homematic auf einem soliden Server zu virtualisieren.
Auf dem Tinkerboard läuft das zwar recht gut, aber alle professionellen Systeme laufen heute auf virtualisierten Servern.
Jetzt fehlt nur noch die Portierung auf X64 und zusammen mit dem USB Modul wäre dies dann möglich.

Der einzige Nachteil wäre dann, dass das USB-Kabel nicht sehr lang sein darf. Um aus dem Serverrack oder aus dem PC herauszuschauen wäre das ja genug. Und das USB-Kabel trennt sich dann auch etwas das Funkmodul vom PC ab. Dies sollte sich positiv auf den Empfang auswirken, solange der PC in einem gut abgeschirmten Gehäuse steckt.

Wenn man diese Idee von Deinem USB Modul aber noch weiterdenkt wäre dann die Folgerung ein Modul mit Ethernet Anschluss
(analog HM-Lan-Gateway, aber für HM und HmIP) und der Ort des Funkmoduls könnte unabhängig vom Serverstandort gewählt werden.
Vermutlich gäbe dies wieder andere Probleme, wie z.B. Verzögerungen etc.


Bleiben wir aber in der Realität.
Wenn Du also noch einen USB-Adpater übrig hast, dann würde ich dies sehr gerne testen.

Viele Grüsse
Stefan