[GELÖST] OVA - Funk Hardware Konfiguration
Moderatoren: jmaus, Co-Administratoren
- Baxxy
- Beiträge: 11084
- Registriert: 18.12.2018, 15:45
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 638 Mal
- Danksagung erhalten: 2299 Mal
Re: OVA - Funk Hardware Konfiguration
Ich wollte bloß aufzeigen das ich "die Problematik" erstmal so auch zu sehen bekomme.
Fakten und detaillierte Analysen sollten vom TE kommen.
Ich mach das gerade nur, weil mein Bierchen auf dem Balkon zu schnell warm wurde und ich mich nach drinnen verziehen musste.
Das Problem an sich betrifft mich auch nicht wirklich , da ich primär die HB-RF-USB-2 verwende.
Und selbst wenn ein Testsystem mal für ein paar Watt Mehrverbrauch sorgt ist mir das auch ziemlich Wurst, wird ja nicht mit Gas betrieben.
Ob die Anzeigen nun echt sind oder nicht kann man eh nicht konkret verifizieren. Da müsste man schon mit präzisem Equipment den Stromverbrauch des Gesamtsystems messen.
Und dazu habe ich weder Lust noch das Equipment, daher mein Rat an @wolwin...
Besorg dir die HB-RF-USB-2 und ein gutes (mind.) 2m langes USB Kabel, steck das RPI-RF-MOD drauf und dann läuft das.
Fakten und detaillierte Analysen sollten vom TE kommen.
Ich mach das gerade nur, weil mein Bierchen auf dem Balkon zu schnell warm wurde und ich mich nach drinnen verziehen musste.
Das Problem an sich betrifft mich auch nicht wirklich , da ich primär die HB-RF-USB-2 verwende.
Und selbst wenn ein Testsystem mal für ein paar Watt Mehrverbrauch sorgt ist mir das auch ziemlich Wurst, wird ja nicht mit Gas betrieben.
Ob die Anzeigen nun echt sind oder nicht kann man eh nicht konkret verifizieren. Da müsste man schon mit präzisem Equipment den Stromverbrauch des Gesamtsystems messen.
Und dazu habe ich weder Lust noch das Equipment, daher mein Rat an @wolwin...
Besorg dir die HB-RF-USB-2 und ein gutes (mind.) 2m langes USB Kabel, steck das RPI-RF-MOD drauf und dann läuft das.
Grüße... Baxxy
- Raspberry Pi 4 als Homematic-Zentrale - Tipps und Informationen
- Analysescript für genutzte Funk-Adressen, Funkmodul-Hardware und Zentralen Hardware
- NANO CUL 868MHz - Stick zum AskSin Analyzer XS umflashen (Anleitung für ArduinoIDE unter Windows)
- Firmware Updates für IP-Aktoren / Sensoren... Info's, Tipps und Sonstiges
- CCU funkt nicht - CarrierSense (CS) Probleme erkennen und lösen
- jmaus
- Beiträge: 9929
- Registriert: 17.02.2015, 14:45
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Dresden
- Hat sich bedankt: 468 Mal
- Danksagung erhalten: 1922 Mal
- Kontaktdaten:
Re: OVA - Funk Hardware Konfiguration
Das wäre ja die Frage noch. Siehst du diesen Effekt bei Einsatz eines HB-RF-USB-2 an Proxmox nicht?
RaspberryMatic 3.75.7.20240601 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal /
- Baxxy
- Beiträge: 11084
- Registriert: 18.12.2018, 15:45
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 638 Mal
- Danksagung erhalten: 2299 Mal
Re: OVA - Funk Hardware Konfiguration
Nein. Die HB-RF-USB-2 verhält sich von der angezeigten Load wie ein HmIP-RFUSB.
A: HmIP-RFUSB
B: HB-RF-USB-TK mit HM-MOD-RPI-PCB
C: kein Funkmodul
D: HB-RF-USB-2 mit HM-MOD-RPI-PCB
Grüße... Baxxy
- Raspberry Pi 4 als Homematic-Zentrale - Tipps und Informationen
- Analysescript für genutzte Funk-Adressen, Funkmodul-Hardware und Zentralen Hardware
- NANO CUL 868MHz - Stick zum AskSin Analyzer XS umflashen (Anleitung für ArduinoIDE unter Windows)
- Firmware Updates für IP-Aktoren / Sensoren... Info's, Tipps und Sonstiges
- CCU funkt nicht - CarrierSense (CS) Probleme erkennen und lösen
- jmaus
- Beiträge: 9929
- Registriert: 17.02.2015, 14:45
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Dresden
- Hat sich bedankt: 468 Mal
- Danksagung erhalten: 1922 Mal
- Kontaktdaten:
Re: OVA - Funk Hardware Konfiguration
Hmm, interessante Analyse. Werd ich mal versuchen zu reproduzieren in meiner Proxmox Umgebung. Wenn das wirklich eine zusätzlich Auslastung des Proxmox Host wiederspiegelt wäre in der Tat interessant zu wissen woher das kommt?
Das mehr Daten bei einem HB-RF-USB-TK transferiert werden oder größere Latenzen entstehen kann man vmtl. ausschließen. Vielleicht hat Alex ja eine Idee woher das kommen könnte? Die Treiber von beiden sollten ja prinzipiell die gleichen Rahmenbedingungen haben.
RaspberryMatic 3.75.7.20240601 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal /
- deimos
- Beiträge: 5410
- Registriert: 20.06.2017, 10:38
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Leimersheim
- Hat sich bedankt: 121 Mal
- Danksagung erhalten: 962 Mal
- Kontaktdaten:
Re: OVA - Funk Hardware Konfiguration
Hi,
ja, ich habe eine Ahnung, es könnte sein, das da mehr USB Interrupts mit leeren Paketen ankommen, weil der FT232 imho eine etwas niedriegere Latenz hat.
Viele Grüße
Alex
ja, ich habe eine Ahnung, es könnte sein, das da mehr USB Interrupts mit leeren Paketen ankommen, weil der FT232 imho eine etwas niedriegere Latenz hat.
Viele Grüße
Alex
- Baxxy
- Beiträge: 11084
- Registriert: 18.12.2018, 15:45
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 638 Mal
- Danksagung erhalten: 2299 Mal
Re: OVA - Funk Hardware Konfiguration
Was noch fehlt...
ich aber aktuell nicht testen kann wäre der Vergleich RPI-RF-MOD vs. HM-MOD-RPI-PCB, jeweils auf HB-RF-USB-TK und HB-RF-USB-2.
ich aber aktuell nicht testen kann wäre der Vergleich RPI-RF-MOD vs. HM-MOD-RPI-PCB, jeweils auf HB-RF-USB-TK und HB-RF-USB-2.
Grüße... Baxxy
- Raspberry Pi 4 als Homematic-Zentrale - Tipps und Informationen
- Analysescript für genutzte Funk-Adressen, Funkmodul-Hardware und Zentralen Hardware
- NANO CUL 868MHz - Stick zum AskSin Analyzer XS umflashen (Anleitung für ArduinoIDE unter Windows)
- Firmware Updates für IP-Aktoren / Sensoren... Info's, Tipps und Sonstiges
- CCU funkt nicht - CarrierSense (CS) Probleme erkennen und lösen
- Roland M.
- Beiträge: 9914
- Registriert: 08.12.2012, 15:53
- System: CCU
- Wohnort: Graz, Österreich
- Hat sich bedankt: 257 Mal
- Danksagung erhalten: 1421 Mal
Re: OVA - Funk Hardware Konfiguration
Hallo!
Ich habe die Problemstellung auf meinem Proxmox-Server (Xeon E3-1245, ja, auch noch 6.4-15... ) nachgestellt:
1. VM mit HB-RF-USB + RPI-RF-MOD, "nahezu Produktivsystem" mit zwei, drei Geräten angelernt, sowie AddOns (CUxD, E-Mail)
CPU-Auslastung ca. 11%
2. VM mit HmIP-RFUSB, Testsystem, keine Geräte, keine AddOns
CPU-Auslastung ca. 4,5%
3. VM ohne Funkmodul, frische Installation
CPU-Auslastung ca. 4,5%
Interpretationen mögen andere übernehmen!
Roland
Ich habe die Problemstellung auf meinem Proxmox-Server (Xeon E3-1245, ja, auch noch 6.4-15... ) nachgestellt:
1. VM mit HB-RF-USB + RPI-RF-MOD, "nahezu Produktivsystem" mit zwei, drei Geräten angelernt, sowie AddOns (CUxD, E-Mail)
CPU-Auslastung ca. 11%
2. VM mit HmIP-RFUSB, Testsystem, keine Geräte, keine AddOns
CPU-Auslastung ca. 4,5%
3. VM ohne Funkmodul, frische Installation
CPU-Auslastung ca. 4,5%
Interpretationen mögen andere übernehmen!
Roland
Zur leichteren Hilfestellung bitte unbedingt beachten:
-----------------------------------------------------------------------
1. CCU2 mit ~100 Geräten (in Umstellung auf RaspberryMatic-OVA auf Proxmox-Server)
2. CCU2 per VPN mit ~50 Geräten (geplant: RaspberryMatic auf Charly)
3. CCU2 per VPN mit ~40 Geräten (geplant: RaspberryMatic auf CCU3)
CCU1, Test-CCU2, Raspi 1 mit kleinem Funkmodul, RaspberryMatic als VM unter Proxmox, Access Point,...
- Bezeichnung (HM-... bzw. HmIP-...) der betroffenen Geräte angeben (nicht Artikelnummer)
- Kurzbeschreibung des Soll-Zustandes (Was soll erreicht werden?)
- Kurzbeschreibung des Ist-Zustandes (Was funktioniert nicht?)
- Fehlermeldungen genau abschreiben, besser noch...
- Screenshots von Programmen, Geräteeinstellungen und Fehlermeldungen (direkt als jpg/png) einstellen!
-----------------------------------------------------------------------
1. CCU2 mit ~100 Geräten (in Umstellung auf RaspberryMatic-OVA auf Proxmox-Server)
2. CCU2 per VPN mit ~50 Geräten (geplant: RaspberryMatic auf Charly)
3. CCU2 per VPN mit ~40 Geräten (geplant: RaspberryMatic auf CCU3)
CCU1, Test-CCU2, Raspi 1 mit kleinem Funkmodul, RaspberryMatic als VM unter Proxmox, Access Point,...
- jmaus
- Beiträge: 9929
- Registriert: 17.02.2015, 14:45
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Dresden
- Hat sich bedankt: 468 Mal
- Danksagung erhalten: 1922 Mal
- Kontaktdaten:
Re: OVA - Funk Hardware Konfiguration
Bedeutet das, das ein HB-RF-USB (ohne -2) prinzipiell eine geringere Latenz hat was ja eigentlich positiv sein sollte? Und das führt hier zu mehr USB interrupts und damit mehr USB Kommunikation? Die Frage wäre natürlich, ist diese eigentlich geringere Latenz überhaupt relevant für die HomeMatic kommunikation und wenn nicht, kann man den FT232 irgendwie anders ansteuern/umprogrammieren, das er somit geringeren Traffic macht zu lasten der Latenz wenn dieses ohnehin nicht relevant ist?!?
RaspberryMatic 3.75.7.20240601 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal /
- jmaus
- Beiträge: 9929
- Registriert: 17.02.2015, 14:45
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Dresden
- Hat sich bedankt: 468 Mal
- Danksagung erhalten: 1922 Mal
- Kontaktdaten:
Re: OVA - Funk Hardware Konfiguration
Ok, nun hab ich mal hauruck-mäßig meine produktive Umgebung auf ein HB-RF-USB-2 umgestellt (wollte ich ohnehin schon länger) und siehe da:jmaus hat geschrieben: ↑13.07.2022, 17:35Hmm, interessante Analyse. Werd ich mal versuchen zu reproduzieren in meiner Proxmox Umgebung.
.. es pendelt sich in der Tat auf niedrigeres Niveau ein, sodass ich jetzt bei ~4% Grundauslastung lande statt bisher wie mit dem HB-RF-USB (ohne -2) bei ~8-10%.
Was man allerdings auch sieht ist, das sich das in der Gesamtauslastung des Proxmox Hosts – auf dem ja noch andere VMs mit laufen - selbst nicht bemerkbar macht:
Insofern ist das in der Tat wohl nicht wirklich relevant, aber eben trotzdem eine interessante Tatsache und hier wäre in der Tat die Frage inwieweit hier Alex vielleicht noch was dran drehen kann wenn es wirklich am FT232 selber liegt.
RaspberryMatic 3.75.7.20240601 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal /
- deimos
- Beiträge: 5410
- Registriert: 20.06.2017, 10:38
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Leimersheim
- Hat sich bedankt: 121 Mal
- Danksagung erhalten: 962 Mal
- Kontaktdaten:
Re: OVA - Funk Hardware Konfiguration
Hi,
ich könnte einfach etwas dran drehen, die Frage ist nur, ob es sinnvoll ist:
Aktuell ist beim FT232R eine Dead Latency von 1ms eingestellt, d.h. wenn eine Millisekunde lang keine Daten kommen, dann wird der Read URB mit leerem Buffer beantwortet, insgesamt kommt man damit auf eine Gesamtlatency von im Schnitt 3,2ms (First byte of request to last byte of response).
Wenn ich das auf 2ms hochstelle, bedeutet das, dass die Gesamtlatency auf 4,2ms im Schnitt steigen würde, also schon ziemlich nah an der von eQ-3 defininierten maximalen Latency von 5ms (Für meinen Geschack gefühlt zu nah).
Beim CP210x liegt diese Latency bei 2000µs also 2ms, allerdings ist der Chip insgesamt schneller unterwegs, weshalb es nur auf eine Gesamtlatency von 3,8ms im Schnitt kommt und man kann die Dead Latency nur bei der ganz neuen Hardware Revision A02 vom CP2102N anpassen, sonst hätte ich die auch beim CP210x niedriger eingestellt um auf eine Gesamtlatency von ungefährt 3ms zu kommen, wie es bei reinem GPIO Betrieb der Fall ist.
Viele Grüße
Alex
ich könnte einfach etwas dran drehen, die Frage ist nur, ob es sinnvoll ist:
Aktuell ist beim FT232R eine Dead Latency von 1ms eingestellt, d.h. wenn eine Millisekunde lang keine Daten kommen, dann wird der Read URB mit leerem Buffer beantwortet, insgesamt kommt man damit auf eine Gesamtlatency von im Schnitt 3,2ms (First byte of request to last byte of response).
Wenn ich das auf 2ms hochstelle, bedeutet das, dass die Gesamtlatency auf 4,2ms im Schnitt steigen würde, also schon ziemlich nah an der von eQ-3 defininierten maximalen Latency von 5ms (Für meinen Geschack gefühlt zu nah).
Beim CP210x liegt diese Latency bei 2000µs also 2ms, allerdings ist der Chip insgesamt schneller unterwegs, weshalb es nur auf eine Gesamtlatency von 3,8ms im Schnitt kommt und man kann die Dead Latency nur bei der ganz neuen Hardware Revision A02 vom CP2102N anpassen, sonst hätte ich die auch beim CP210x niedriger eingestellt um auf eine Gesamtlatency von ungefährt 3ms zu kommen, wie es bei reinem GPIO Betrieb der Fall ist.
Viele Grüße
Alex