Wenn USB-Stick für Diagramme gesteckt, dann Kommunikationsstörungen HM-IP

[ALM007]

Wenn ich auf meinem PI4 / neuem Funkmodul mit aktueller Firmware einen USB Stick stecke, dann kann die CCU nicht mehr senden.
Es kommt eine Servicemeldung das die Kommunikation gestört ist, sobald man einen Wert an einem Gerät ändert. Die Änderung wird auch nicht übertragen.
Empfangen geht noch. (Diagramme und Status werden weithin aufgezeichnet).

habe neues Image auf SD und diverse USB Sticks ausprobiert. Keine Änderung.

Was kann der Grund für das Verhalten sein?

Kleine Historie:

Die neue FW läuft seit 1 Woche ohne Probleme.
Gestern wurden keine Diagramme mehr aufgezeichnet USB wurde nicht gefunden....
USB gestern getauscht - geht wieder - nicht nachgedacht.
Heute da oben beschriebene verhalten.

[ALM007]

Jetzt habe ich den Stick an einen USB2.0 statt USB3.0 Port angeschlossen - jetzt geht es ohne Fehler - mal schauen wie Lange?
Bisher nur am 3.0 Port getestet...

[ALM007]

Hi,

weil leider so wenig Informationen genannt wurden: Die HB-RF-USB funktioniert sowohl an USB2 als auch an USB3, wobei es je nach Controller zu einem minimalen zusätzlichen Delay kommen kann für die Umsetzung von USB2 Paketen auf USB3, das gilt aber primär für Geräte, welche über einen USB3 Hub angeschlossen sind.
Bei einem Raspberry Pi 4 sollte man sich aber dennoch überlegen, ob man die USB3 Ports wirklich nutzen will (nicht nur für die HB-RF-USB, sondern allgemein), weil der USB3 Controller vom Raspberry Pi 4 jede Menge Störstrahlung erzeugt, welche u.U. den HmIP Funk beeinträchtigt.

Viele Grüße
Alex

könnte das die Erklärung sein, das es wenn der Stick an USB3.0 hängt zu Problemen mit dem HM-IP Funk kommt???

[Matthias K.]

Ja.

[ALM007]

OK USB 3.0 mit PI4 und HMIP Funk = böse.....

Wird das mit einer ext. Antenne besser?

...bin eh noch auf Gehäusesuche.....

[Baxxy]

Wird das mit einer ext. Antenne besser?

Wenn du unbedingt USB3 am Pi4 nutzen möchtest wäre es sinnvoller das Funkmodul abzusetzen statt nur die Antenne "auszulagern". Dazu bieten sich z.B. die HB-RF-USB(-2) oder ein simples GPIO-Verlängerungskabel an.

[Hütte]

Stellt sich Frage, ob man immer gleich mit Kanonen auf Spatzen schießen muss.

Die Geschwindigkeit von USB3 ist doch vollkommen überdimensioniert, wenn es darum geht, die Diagramme und die Backups auf den Stick zu schreiben. Die Diagramme sind eventuell einige MB groß und das täglich Backup ist bei mir etwa 24 MB groß. da reicht USB2 von der Geschwindigkeit vollkommen aus, um die Daten in kurzer Zeit auf den Stick zu schreiben.

[jmaus]

Die Geschwindigkeit von USB3 ist doch vollkommen überdimensioniert, wenn es darum geht, die Diagramme und die Backups auf den Stick zu schreiben. Die Diagramme sind eventuell einige MB groß und das täglich Backup ist bei mir etwa 24 MB groß. da reicht USB2 von der Geschwindigkeit vollkommen aus, um die Daten in kurzer Zeit auf den Stick zu schreiben.

Und dazu kommt noch, das bei RaspberryMatic die Diagrammdaten ja eh zeitversetzt auf den USB-Stick (im interval von 10 Minuten) geschrieben werden und nicht sofort darauf landen. Ergo ist hier genug Zeit+Luft die Daten auf den USB Stick zu schreiben sodass ich auch denke das dafür USB2 vollkommen ausreichend ist.

[Hütte]

@jmaus
ich habe gerade bei mir gesehen, als ich mir mit WinSCP die Dateien auf dem USB-Stick angeschaut habe, dass scheinbar auch bei mir jetzt etwas mit den Diagrammen schief läuft.

/media/usb0/ ist verlinkt nach /media/usb1/. Dort gibt es die Verzeichnisse "backup" und "measurement". Im Verzeichnis "backup" liegen die täglichen Backups, auch das von heute Nacht.

Im Verzeichnis "measurement" liegen 8 Dateien für die 8 Diagramme, die ich aufzeichne. Das merkwürdige ist, dass 7 dieser Dateien einen Zeitstempel haben vom April 2020. Und die andere Datei hat einen Zeitstempel vom 27.09.2020 02:01:18, etwa so 6 Stunden, nachdem ich die aktuelle Version installiert hatte. Wenn ich in der WebUI mir die Diagramme anzeigen lasse, dann fehlt da auch nichts.

Und zusätzlich finde ich dieselben 8 Dateien in /tmp/measurement/. Bei den 7 Dateien mit dem Zeitstempel vomm April sind jeweils sowohl Größe als auch Zeitstempel identisch. Nur bei der 9. Datei, da unterscheidet sich der Zeitstempel um eine Sekunde, bei identischer Größe?

Hast du dafür eine Erklärung? Sowohl, warum die Dateien in beiden Ordnern liegen, als auch, warum sich der Zeitstempel nicht ändert?

Denn ich habe schon lange einen USB-Stick dran für die Diagramme. Kann ich auch daran erkennen, dass im Verzeichnis /usr/local/sdcard/measurement_bak/ noch die alten Dateien liegen, als sie zum ersten Mal auf den Stick ausgelagert wurden.

[ALM007]

Beim Löschen einer Datenquelle kommt ein Fehler das nicht gespeichert werden kann
http://www.youscreen.de/phbahoaho81.jpg

Das entsprechende Diagramm kann auch nicht mehr angezeigt werden.


EIntrag in Log Datei beim Speichern des Diagrammes

Code: Alles auswählen

Oct 6 19:30:35 de.eq3.lib.datalogging.rrd.RrdDatalogging ERROR [vert.x-worker-thread-19] The data sources could not be added to the diagram 6 
java.io.FileNotFoundException: Could not open /tmp/measurement/6.rrd [non existent]
	at org.rrd4j.core.RrdDb.<init>(RrdDb.java:196)
	at org.rrd4j.core.RrdDb.<init>(RrdDb.java:174)
	at org.rrd4j.core.RrdDb.<init>(RrdDb.java:235)
	at de.eq3.lib.datalogging.rrd.RrdDatalogging.addDataSources(RrdDatalogging.java:188)
	at de.eq3.lib.measurement.MeasurementService.updateDiagram(MeasurementService.java:376)
	at de.eq3.ccu.measurement.http.service.DiagramSettingsController.saveDiagram(DiagramSettingsController.java:202)
	at de.eq3.ccu.server.internal.DiagramRequestWorker.handle(DiagramRequestWorker.java:84)
	at de.eq3.ccu.server.internal.DiagramRequestWorker.handle(DiagramRequestWorker.java:14)
	at io.vertx.core.eventbus.impl.HandlerRegistration.deliver(HandlerRegistration.java:212)
	at io.vertx.core.eventbus.impl.HandlerRegistration.handle(HandlerRegistration.java:191)
	at io.vertx.core.eventbus.impl.EventBusImpl.lambda$deliverToHandler$3(EventBusImpl.java:505)
	at io.vertx.core.impl.ContextImpl.lambda$wrapTask$2(ContextImpl.java:337)
	at io.vertx.core.impl.TaskQueue.lambda$new$0(TaskQueue.java:60)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)