mir scheint, frigate schaut nur über den "bus" tree ... Eine kleine Modifikation hat es zum Fliegen gebracht Hängt jetzt an einem "Fake" USB-Bus 10 als erstes Device (wenn der Berg nicht zum Propheten .....) root@pve:/etc/udev/rules.d# cat 98-coral.rules SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="9302", SYMLINK+="/bus/usb/010/001" root@pve:/etc/udev/rules.d# ls /dev/bus/usb 001 002 010 root@pve:/etc/udev/rules.d# ls /dev/bus/usb/010 001 root@pve:/etc/udev/rules.d# ls -l /dev/bus/usb/010/001 lrwxrwxrwx 1 root root 10 Nov 4 15:56 /dev/bus/usb/010/001 -> ../002/003 root@pve:/etc/udev/rules.d# [image: 1730732846629-be64733d-3b27-43dd-a05a-561d45196f34-grafik.png] info 2024-11-04 15:59:55 frigate.detectors.plugins.edgetpu_tfl Attempting to load TPU as usb info 2024-11-04 15:59:56 frigate.app Camera processor started for stellplatz: 379 info 2024-11-04 15:59:56 frigate.app Capture process started for stellplatz: 380 info 2024-11-04 15:59:58 frigate.detectors.plugins.edgetpu_tflTPU found

@dr-bakterius aber wir sollen alle e-karren fahren... ist aber ein anderes thema. ich hab 2019 beim hauskauf >95% auf led umgestellt. eine 6,4er pv anlage mit akku im/am haus, da scheren mich 3w wenig. zumal server, 4 pcs 24/7, nas und sonstiges weit mehr braucht. dafür brauch/hab ich kein gas. geheitzt wird mit infrarot. haus und werkstatt 10 kreise. zumal ich im sommer für einspeisung noch einen altvertrag habe, der 19 cent bringt. [image: 1730029941864-8daa3a71-2b64-47c2-a507-d587c498e000-grafik.png] aber, wie gesagt, jedem das seine! ;)

@kellerkind-86 Anbei meine config.yml mqtt: enabled: true host: 192.168.178.98 port: 1885 # Standard mqtt-Port ist 1883, darauf hört bei den ESPxx auch mosquitto, der es dann an den ioBroker.mqtt-client weitergibt (auch 1883) # ioBroker.frigate hat einen eigenen mqtt-server, der nur auf 1885 hört topic_prefix: frigate tls: enabled: False birdseye: enabled: true width: 1280 height: 720 mode: continuous # layout: # scaling_factor: 2.0 detectors: coral: type: edgetpu device: usb go2rtc: #log: # exec: trace streams: #----- Output ist MJPEG, Video.Transkodierung in H.264, Audio.Transkodierung in OPUS oder AAC CAM_EG: - rtsp://admin:xxx@192.168.178.84:554/cam/realmonitor?channel=1&subtype=1#audio=aac CAM_OG: - rtsp://admin:xxx@192.168.178.90:554/cam/realmonitor?channel=1&subtype=1&proto=Onvif #----- Output ist JPEG, Video.Transkodierung in H.264, kein Audio vorhanden CAM-3DPrinter: - ffmpeg:http://192.168.178.69:81/stream#video=h264 #----- Alle 4 LE232 Konfiguration: Video: H.264 Audio: AAC (keine Transkodierung erforderlich) # Alle 4 können den neuen Video-Standard H.265, das kann go2RTC aber nicht # WebRTC kann AAC | OPUS | PCM # MSE kann OPUS | PCM # MJPEG kann AAC | PCM CAM-Eingang: - rtsp://admin:xxx@192.168.178.38:554/Port/cam/realmonitor?channel=1&subtype=1 CAM-Terrasse: - rtsp://admin:xxx@192.168.178.39:554/Port/cam/realmonitor?channel=1&subtype=1 CAM-Garten: - rtsp://admin:xxx@192.168.178.40:554/Port/cam/realmonitor?channel=1&subtype=1 CAM-Garage: - rtsp://admin:xxx@192.168.178.41:554/Port/cam/realmonitor?channel=1&subtype=1 webrtc: candidates: - 192.168.178.43:8555 - stun:8555 cameras: CAM-Eingang: ffmpeg: output_args: record: preset-record-generic-audio-copy inputs: - path: rtsp://127.0.0.1:8554/CAM-Eingang input_args: preset-rtsp-generic roles: - detect detect: width: 704 height: 576 fps: 5 CAM-Terrasse: ffmpeg: output_args: record: preset-record-generic-audio-copy inputs: - path: rtsp://127.0.0.1:8554/CAM-Terrasse input_args: preset-rtsp-generic roles: - detect detect: width: 704 height: 576 fps: 5 CAM-Garten: ffmpeg: output_args: record: preset-record-generic-audio-copy inputs: - path: rtsp://127.0.0.1:8554/CAM-Garten input_args: preset-rtsp-generic roles: - detect detect: width: 704 height: 576 fps: 5 CAM-Garage: ffmpeg: output_args: record: preset-record-generic-audio-copy inputs: - path: rtsp://127.0.0.1:8554/CAM-Garage input_args: preset-rtsp-generic roles: - detect detect: width: 704 height: 576 fps: 5 CAM_EG: ffmpeg: output_args: record: preset-record-generic-audio-copy inputs: - path: rtsp://127.0.0.1:8554/CAM_EG input_args: preset-rtsp-generic roles: - detect detect: enabled: false CAM_OG: ffmpeg: output_args: record: preset-record-generic-audio-copy inputs: - path: rtsp://127.0.0.1:8554/CAM_OG input_args: preset-rtsp-generic roles: - detect detect: enabled: false CAM-3DPrinter: ffmpeg: inputs: - path: rtsp://192.168.178.43:8554/CAM-3DPrinter input_args: preset-rtsp-generic roles: - detect detect: enabled: false objects: track: - person # - car record: enabled: true retain: days: 0 # Keine Standard-Aufzeichnung, nur im Falle von events events: retain: default: 10 # 10 Tage aufbewahren mode: active_objects # motion: bei jeder Bewegung # active_objects: nur bei Bewegung eines der Objekttypen (person, car) # detect: # nur an der Kamera selbst angeben, nicht global für alle # enabled: false version: 0.14 Gruß ExMatador

@david-g sagte in Proxmox Basissystem: LAN-Speed überwachen: i3 12100. [image: 1729587592769-69a9b5d4-f0b8-4d64-b5a4-bd3477da23e8-grafik.png] [image: 1729587949005-9b08f5c8-8967-4369-83f6-dd7c46c1043b-grafik.png] Deine CPU ist um den Faktor 23 schneller als mein N3000 .... Selbst der SoC des Pi4 ist ca um Faktor 1,4 schneller,als mein lahmer N3000 ... OFFTOPIC: Die 60 Watt TDP sind zwar erstmal beängstigend, aber die werden im Homeserver-Betrieb wahrscheinlich nur selten ausgereizt (außer man lässt die Bewegungserkennung von Überwachungskameras durch die CPU "rechnen"), trotzdem die Frage: Was schluckt Dein System pro Tag an Strom? Das letzte Mal, als ich den Gigabyle N3000 "Nuc" alleine gemessen habe, waren es 0,116 kWh pro Tag... Noch ein Nachtrag... Ich habe das Intervall aller Server weiter auf 5 Minuten gelassen... inux-control.0 2024-10-22 14:00:56.363 info getting data from proxmox (192.168.2.200:22) linux-control.0 2024-10-22 14:00:56.777 info successful received data from proxmox (192.168.2.200:22) linux-control.0 2024-10-22 14:01:05.661 info getting data from frigate (192.168.2.196:22) linux-control.0 2024-10-22 14:01:06.380 info successful received data from frigate (192.168.2.196:22) linux-control.0 2024-10-22 14:01:17.716 info getting data from docker (192.168.2.146:22) linux-control.0 2024-10-22 14:01:18.598 info successful received data from docker (192.168.2.146:22) linux-control.0 2024-10-22 14:01:30.702 info getting data from iobroker (192.168.2.201:22) linux-control.0 2024-10-22 14:01:31.356 info successful received data from iobroker (192.168.2.201:22) linux-control.0 2024-10-22 14:03:34.968 info getting data from debian (192.168.2.164:22) linux-control.0 2024-10-22 14:03:36.068 info successful received data from debian (192.168.2.164:22) linux-control.0 2024-10-22 14:05:56.779 info getting data from proxmox (192.168.2.200:22) linux-control.0 2024-10-22 14:05:57.312 info successful received data from proxmox (192.168.2.200:22) Mir scheint, die Abarbeitung des Zeitplans ist nicht sehr systematisch, bis auf die Einhaltung des individuellen Intervalls für jeden einzelnen Server ... Dadurch ergaben sich schon recht hektische Lastspitzen ...

@meister-mopper Hmm, wie lange ist bei Dir ein "apt-get update" unterwegs? Und wie lange die Abfrage der CPU-Temperatur aus der Kommandozeile? Ich habe hier mal gemessen - ersteres etwa 8 ... 10 Sekunden ... zweiteres ist quasi SOFORT wieder zurück... PVE + 5 LXC, die alle reihum abgefeuert werden, dann wird das ggfs. 1 Minute dauern, bis das "durch" ist.... Ist zwar noch kein DOS, aber wenn die sich alle bemühen, die Datenbank zügig upzudaten, ist das schon eine temporär hohe Last ... Ist jedenfalls merklich, dass da die Last heruntergegangen ist, als ich das abgeschaltet habe ... Die Situation auf einem PVE System ist ja etwas spannender, als auf einem Pi, der die Pfeile nach außen abfeuert. Wenn der iobroker - adapter die selbst genutzte Virtualisierungsplattform mit jedem Container, der abgefragt wird mehr belastet .... Hier von zwei Containern ... Oct 21 16:02:43 DockerKlon1 sudo: martin : TTY=pts/3 ; PWD=/home/martin ; USER=root ; COMMAND=/usr/bin/apt-get update 2024-10-21T16:00:16.511762+02:00 ubuntu-frigate-privileged sudo: frigate : TTY=pts/3 ; PWD=/home/frigate ; USER=root ; COMMAND=/usr/bin/apt-get update

@peterfido Danke. OK

Interessanterweise gibt es bei der USB-HDD einen Returncode !=0 Bei der SSD kommt immer eine 0 (alles O.K.) als "result" zurück, bei der HDD eine 4... also Bit 2 gesetzt ... ich vermute, aufgrund der folgenden Fehlermeldung mit anschließender Warnung ... === START OF READ SMART DATA SECTION === SMART Status command failed: scsi error unsupported scsi opcode SMART overall-health self-assessment test result: PASSED Warning: This result is based on an Attribute check. .... smartctl -a /dev/sda >/root/scripte/Proxmox_Skripte/Testdata.txt result=$? Das bedeutet laut untenstehendem ... Return Values The return values of smartctl are defined by a bitmask. If all is well with the disk, the return value (exit status) of smartctl is 0 (all bits turned off). If a problem occurs, or an error, potential error, or fault is detected, then a non-zero status is returned. In this case, the eight different bits in the return value have the following meanings for ATA disks; some of these values may also be returned for SCSI disks. Bit 0: Command line did not parse. Bit 1: Device open failed, device did not return an IDENTIFY DEVICE structure, or device is in a low-power mode (see '-n' option above). Bit 2: Some SMART or other ATA command to the disk failed, or there was a checksum error in a SMART data structure (see '-b' option above). Bit 3: SMART status check returned "DISK FAILING". Bit 4: We found prefail Attributes <= threshold. Bit 5: SMART status check returned "DISK OK" but we found that some (usage or prefail) Attributes have been <= threshold at some time in the past. Bit 6: The device error log contains records of errors. Bit 7: The device self-test log contains records of errors. [ATA only] Failed self-tests outdated by a newer successful extended self-test are ignored. To test within the shell for whether or not the different bits are turned on or off, you can use the following type of construction (this is bash syntax): smartstat=$(($? & 8)) This looks at only at bit 3 of the exit status $? (since 8=2^3). The shell variable $smartstat will be nonzero if SMART status check returned "disk failing" and zero otherwise. This bash script prints all status bits: status=$? for ((i=0; i<8; i++)); do echo "Bit $i: $((status & 2**i && 1))" done

@samson71 Danke für den Hinweis!

oder es gibt hier auch noch angepasste Helper Installationsscripte https://tteck.github.io/Proxmox/

@jojo58 Das habe ich in der Tat nicht gemacht. Alles in einem "Arbeitsgang". Teste es nachher. EDIT Er hat es nicht selber gemacht. Gehe dann die Tage mal nach diesem Video vor: https://www.youtube.com/watch?v=309zHHkt1s8

@da_woody ja das hatte ich nicht so ganz auf dem Schirm gehabt. Aber nun bin ich beruhigt.

@tilly sagte in VM Festplatte erweitern: warum Iobroker so viel Platz braucht. sudo ncdu /

@martinp Hattest Du seither mal einen Neustart des LXC gemacht oder den Coral AI aus- und wieder eingesteckt? Bei mir hat sich nämlich der Pfad geändert. Die letzte Zahl, also 002 wird immer um eins erhöht… Das ist ein wenig unpraktisch.

@amg_666 Danke! Den part konnte ich in meinem LXC 1:1 übernehmen. lxc.cgroup.devices.allow: c 189:* rwm lxc.mount.entry: /dev/bus/usb/001/010 dev/bus/usb/001/010 none bind,optional,create=file lxc.mount.entry: /dev/ttyACM0 dev/ttyACM0 none bind,optional,create=file Schon hängt der UPS da dran. Mal schauen ob ich den Nut-Server zum laufen bekomme.

@lustig29 sagte in Verbindungsabbrüche mit Proxmox: @meister-mopper Scheint wieder zu gehen habe bei Github einen Beitrag gefunden. Mit dem Befehl iob setup first Scheint es wieder zu gehen. Hoffe ich zu mindestens. Was hattest du in Beta erwartet? Das ist was für Spezialisten.

@meister-mopper sagte in fail2ban wird im repository nicht gefunden: Das erklärt mir, warum Du immer wieder Debian (das Original) empfiehlst. Ja, das ist ein Grund (von vielen).

@martinp sagte in Riesen "apt update" Welle heute: Man macht sich schon seine Gedanken, warum da auf einmal so viel aus den Rohren geschossen wird... Das dürfte mit dem PointRelease 12.6 in Zusammenhang stehen: https://linuxnews.de/debian-gnu-linux-12-6-und-11-10-freigegeben/

@warp735 in einem Docker Container benutzt man " pkill -u iobroker" als root, um die iobroker processe zu beenden. In einem Proxmox Container benutzt man "iob stop".

@negalein sagte in Proxmox Update 6.x --> 7.x: Läuft der Befehl erst mit 7.4? ja 7.4 wird benötigt https://pve.proxmox.com/wiki/Upgrade_from_7_to_8