TheJulianJES

Die Aqara-Produkte brauchen eine gewisse Zeit, bis sie ihre erste Nachricht mit Spannung etc. senden. Nach spätestens einer halben Stunde sollten die Werte verfügbar sein (meist deutlich schneller). Und noch eine weitere Sache bzgl. Aqara-Steckern (bezieht sich nur auf ZHA. Z2M hat ähnliche Funktionalität): Mit Home Assistant Core 2022.11.0 und neuer gibt es eine Einstellung, dass die Stecker nach Stromausfall den vorherigen Zustand wiederherstellen sollen. Siehe Screenshot von hier: https://github.com/home-assistant/core/pull/80444 Bzgl. BlitzWolf/Tuya-Steckern (bezieht sich nur auf ZHA. Z2M hat ähnliche Funktionalität): Mit Home Assistant Core 2022.11.0 und neuer gibt es eine Einstellung, dass die Stecker nach Stromausfall den vorherigen Zustand wiederherstellen sollen oder automatisch auf "an" schalten: https://github.com/home-assistant/core/pull/80486 Die Funktionalität ist zwischen den Steckern leider etwas unterschiedlich, weil die Hersteller (warum auch immer), nicht die Standard-Attribute verwenden. Die 2022.11.0 Beta läuft aktuell schon schon und wird voraussichtlich am 2. November vollständig released. (Bis jetzt gab's aber keine größeren Probleme mit der Beta / sonstige Beta-Release-Notes hier)

Kurze Info an alle ZHA-Nutzer mit Aqara-Steckern: Der "custom Quirk" ist nun in Home Assistant Core 2022.10.5 (und später) mit integriert. Falls der custom Quirk installiert wurde, sollte der also nun entfernt werden. Dazu einfach die Datei aus dem zha_custom_quirks Ordner löschen und dann auf Home Assistant Core 2022.10.5 upgraden. Falls schon vorher HA aktualisiert wurde, kann der alte custom Quirk auch einfach entfernt werden. Danach muss lediglich Home Assistant Core einmal neu gestartet werden, damit der offizielle Quirk übernehmen kann. Wenn man den Stecker mit dem Quirk schon neu gepaired hatte, braucht man das jetzt nicht mehr tun. Falls es mit dem Stecker allerdings Probleme geben sollte, dann als erstes von ZHA/HA entfernen und dann neu pairen. Bei weiteren Problemen hier ein Issue aufmachen: https://github.com/zigpy/zha-device-handlers/issues und mich (@TheJulianJES) taggen.

Danke für das Feedback! War gerade noch dabei eine weitere Antwort zu schreiben, aber das scheint dann egal zu sein. Vielleicht sind die folgenden Informationen trotzdem noch für andere interessant (beziehen sich aber nur auf ZHA und auf OTA-Updates): Also für ZHA kann man die OTA-Dateien einfach in einen Ordner packen, den Ordner in der configuration.yaml festlegen, HA neu starten und einen speziellen Befehl an den Stecker senden, dass dieser bei ZHA nach Updates fragt. (Gleiches gilt für andere Zigbee-Geräte und ZHA) (Config-Details folgen unten) Allerdings würde ich für den MAEU01-Stecker empfehlen, den folgenden Quirk zu installieren: https://github.com/zigpy/zha-device-handlers/pull/1656 Siehe dazu die "Testing"-Section in der PR. Bis jetzt haben alle Nutzer damit Erfolg gehabt. (Auf jeden Fall die MAEU01 Plugs nach Installation des Quirks die Stecker neu pairen, damit Strommesswerte korrekt angezeigt werden!) Der Quirk sollte mit beiden Firmware-Versionen des MAEU01 funktionieren. Hier ist ein Beispiel für den Eintrag in der Home Assistant Core configuration.yaml: zha: zigpy_config: ota: # ikea_provider: true # ledvance_provider: true otau_directory: /config/zha_ota custom_quirks_path: /config/zha_custom_quirks (Die Pfade müssen mgw. angepasst werden. Sind aktuell für Ordner im Home Assistant OS config Ordner.) (ikea_provider/ledvance_provider können bei Bedarf auch noch benutzt werden. Wenn es mit den Geräten aber keine Probleme gibt, dann würde ich diese Zeilen erstmal auskommentiert lassen (oder entfernen). Manche Updates für IKEA-Geräte bereiten Probleme.) Aktuell gibt es in ZHA noch kein UI, um den Update-Status zu sehen. Dafür kann noch Debug-Logging aktiviert werden: https://www.home-assistant.io/integrations/zha/#debug-logging Die aktuelle Firmware-Version des Steckers kann folgendermaßen eingesehen werden: Einstellungen -> Integrationen -> ZHA: Konfigurieren -> Geräte -> Stecker auswählen -> drei kleine Punkte -> Cluster verwalten. Dann oben den BasicCluster auswählen (kann ggf. nur Basic heißen) und im zweiten Dropdown-Menü die app_version auswählen. Dann auf Zigbee-Attribut abrufen klicken. Die neue Firmware-Version ist 41. Diese Version braucht auf jeden Fall den "Custom Quirk". Weiterhin hat diese Version ein paar Fehler, die die alte 32 Firmware-Version nicht hat. Daher würde ich empfehlen, auf Version 32 zu bleiben (oder auf diese Version zu downgraden (Anleitung in der PR), wenn man Probleme mit zufälligen An-/Ausschalten hat. Im Gegensatz zu deCONZ sollte ZHA beide Versionen des Steckers mit dem custom Quirk unterstützen. Nur bzgl. des Downgrades: Wenn man downgradet, muss die "custom Datei" die ich in einem Z2M-Thread bereitgestellt habe, nach dem erfolgreichen Downgrade wieder entfernt werden, da der Stecker sonst immer und immer wieder die Datei installiert. Nach dem Entfernen der Datei, muss HA neu gestartet werden und der Stecker auf jeden Fall neu gepaired werden. (Wenn man upgradet, muss die Datei nicht entfernt werden, da hier die OTA-Datei ja wirklich neuer als die aktuelle Firmware auf dem Stecker ist.) Die alte Firmware-Version 32 ist meist mit mit aktuellen HA-Versionen kompatibel, aber auch zusätzlich mit dem "Custom Quirk". (Dieser sollte noch genauere Strom-Informationen liefern.) Um den Befehl an den Stecker zu senden, dass dieser nach Updates fragen soll, das als HA Service Call senden: (IEEE natürlich durch die vom Stecker ersetzen) service: zha.issue_zigbee_cluster_command data: ieee: 00:00:00:00:00:00:00:00 endpoint_id: 1 cluster_type: out command_type: client cluster_id: 25 command: 0 args: - 0 - 100

Am Link der OTA-Datei war am Ende anscheinend noch eine ")". Habe den jetzt im originalen Post geupdatet. (Sollte eine OTA-Datei und keine XML-Datei sein). Mit deCONZ kenne ich mich leider nicht unbedingt aus. Phoscon sollte eine Möglichkeit haben, die OTA-Datei einfach für den Stecker auszuwählen. Hier ist z. B. ein Artikel von deren Seite: https://phoscon.de/en/support#ota-update-osram-devices (Natürlich kann der Teil, wo die Datei für das LEDVANCE-Gerät aus dem Internet runter geladen wird, ignoriert werden.) Das Prozedere ist für alle OTA-Updates mit deCONZ gleich. Vielleicht findest du noch andere Sachen dazu im Internet. (Das Phoscon-UI solltest du über das deCONZ-Addon aufrufen können.)

Weiterhin noch eine andere kurze Sache zum Thema "Zigbee 3.0". Es gibt alle möglichen "Zigbee 3.0" Produkte von Tuya, die dem Standard so überhaupt nicht folgen bzw. einfach ihr eigenes Protokoll auf Zigbee (3.0) aufgesetzt haben. An sich würde ich empfehlen, Tuya-Produkte zum größten Teil zu vermeiden. Natürlich gibt es in ZHA und Z2M (und wahrscheinlich auch deCONZ) schon viele Anpassungen, sodass Tuya-Produkte auch funktionieren. Man kann aber immer mal einen Stecker mit neuer Firmware erwischen, der dann zum Beispiel gar nicht mehr funktioniert. (Wobei bei Tuya-Steckern das simple Schalten zum Glück meist out-of-the-box funktioniert.) Support für manche Tuya-Sachen hinzuzufügen ist außerdem echt nervig. Wenn es aber solche Probleme gibt, einfach ein Issue hier erstellen: https://github.com/zigpy/zha-device-handlers/issues (ZHA) oder hier für Z2M: https://github.com/Koenkk/zigbee-herdsman-converters/issues (Zum Beispiel sind die Blitzwolf SHP-15 inzwischen in ZHA unterstützt, brauchten aber direkt Anpassungen in Home Assistant (ist schon vor einigen Versionen passiert), da die Stecker alle 30 Sekunden sowohl für den aktuellen Verbrauch, als auch für den Gesamtverbrauch gepolled werden müssen, da die Stecker absolut gar kein Attribute Reporting (Zigbee 3.0-Standard) unterstützen). (Neue Blitzwolf SHP-13 Stecker sollte man übrigens gar nicht mehr kaufen, da diese mit einer Firmware kommen, wo die Messwerte einfach manchmal 0W/0V/0A zurück geben, obwohl das nicht der Fall ist.)

@mgutt @hawihoney Bezüglich eures Aqara MAEU01 Steckers und ZHA: Mit https://github.com/zigpy/zha-device-handlers/pull/1656 wird auch die neuere Firmware-Version der Stecker unterstützt. Auch wenn dieser Quirk früher oder später in zha-device-handlers (und damit HA) gemerged wird, ist es aktuell noch ein "custom Quirk", da alle existierendes Stecker, die jetzt schon Strommessung anzeigen, danach neu gepaired werden müssten. Wir sind aktuell noch am überlegen, ob dies vermieden werden kann. Allerdings gibt es dafür noch kein "Framework". Ein Download-Link für den Quirk ist im OP der PR. Die Installation ist an sich recht simpel (zwei Zeilen in die configuration.yaml und einen Ordner mit dem custom Quirk erstellen). Falls es, warum auch immer, zukünftig zu Fehlern kommen sollte, kann die Datei simpel entfernt werden. (Siehe "Testing"-Section/Link oben). Der Quirk unterstützt sowohl die neuen als auch die alten Firmware-Versionen. Wenn man beide Versionen im Netzwerk hat, muss man nach Installation des Quirks sehr wahrscheinlich nochmal beide Stecker neu pairen, bis die Strommesswerte korrekt angezeigt werden. Ansonsten hat die neuere Firmware-Version des Steckers noch einen Fehler, dass IKEA-Fernbedienungen die Stecker teils an/aus machen. Das kann man mit einem Downgrade "behoben" werden. Die modifizierte Datei ist im Grunde genommen "Original-Aqara-Firmware". Nur der File Versions Header wurde angepasst, damit der Plug sich überhaupt downgraden lässt. (Der Inhalt der Firmware ist also komplett original, sobald das Downgrade komplett ist. Der Header wird nur beim Starten des OTA-Upgrades vom Stecker überprüft.) (OTA Upgrades gehen über ZHA oder Z2M) Edit: Ich sehe gerade, dass zumindest @hawihoney anscheinend deCONZ benutzt. (Dafür ist dieser Post egal). deCONZ hat die Möglichkeit gewählt, alle alten Firmware-Versionen zu "killen", so dass dort ein Upgrade der Firmware (des Steckers) gebraucht wird. (Es hat auch was mit der Firmware des Conbee zu tun und den Manufacturing Codes, die beim Pairen gesendet werden, aber das ist jetzt hier mal egal.) (Edit 2: Falls man die Stecker mit deCONZ upgraden will, kann die neuste Version hier geladen werden: https://cdn.aqara.com/cdn/opencloud-product/mainland/product-firmware/prd/lumi.plug.maeu01/20211209165104_OTA_lumi.plug.maeu01_0.0.0_0041_20211206_0C22EC.ota Falls man seinen Stecker aber downgraden will, gibt es einen Link zu der Datei in der PR oben. Installieren beider Dateien natürlich auf eigene Gefahr. Mit ZHA hatte ich mit Testen von dem Upgrade und Downgrade aber kein Problem mit allen MAEU01-Steckern.)

I also noticed that Unassigned Devices installed but didn't show up correctly in the UI. Before doing another reboot, I uninstalled and reinstalled those plugins and the ZFS plugin. I've restarted now and everything came up as expected now. So, i'm not really sure what this was about (maybe some UNRAID bug?) but at least everything works now. Thank you so much again for the plugin and the fast support.

Mhm, I'm currently having an issue where a reboot of my UNRAID 6.10.3 installation doesn't correctly re-install the ZFS package anymore. I'm also using ZFS master and ZFS companion and they get installed just fine (like all my other plugins). I've had to reinstall the ZFS addon twice now (after every restart). I don't see anything interesting in the logs though. When I reinstall the addon, it always says "ZFS found locally..." and then continues to install correctly. In the past, I've had no issues whatsoever though. Should the plugin have a folder in "/boot/config/plugins"? (Because right now, it doesn't). Edit: Nvm, it does: unRAID6-ZFS.plg and unRAID6-ZFS/ Any ideas on how to troubleshoot this? Thanks!

Only a slight annoyance on macOS: Basically, Apple has removed the Xserve glyph in macOS 11. They also haven't brought it back in macOS 12 (released a year later). So it seems to be gone for good now (and it seems like it's rather intentional than being a bug). It would be nice if UNRAID could instead use the Mac Pro icon for avahai. (This is also what TrueNAS does) The current Xserve glyph only shows up as a "file" icon which can be confusing to some users. "model=Xserve" in "/etc/avahi/services/smb.service" would need to be replaced with: "model=MacPro7,1@ECOLOR=226,226,224" There's some more information here:

This is still an issue. The Xserve glyph seems to be removed for good. (Tested on macOS 12 Monterey 12.3.1 (21E258)). I think that if it's a mistake on Apple's side, they would have fixed it since the initial Big Sur release. Even the last major OS release didn't add the glyph back. It would be nice if UNRAID could just change the default to the Mac Pro rackmount icon. The current "file" icon is somewhat confusing. (TrueNAS also uses "model=MacPro7,1@ECOLOR=226,226,224") Also, for now I'd recommend the following script (if you don't want the file icon). This will replace the model=Xserve with the correct model for the Mac Pro rackmount icon. If the file ever changes in future UNRAID versions, this should still work. sed -i -e 's/model=Xserve/model=MacPro7,1@ECOLOR=226,226,224/g' /etc/avahi/services/smb.service I set it to run at "Array Startup", but I didn't restart my UNRAID server just yet. I just manually ran the script once (which worked).

Ah, good to know that it's still possible to reboot then. I just updated like 7 minutes ago and on GitHub, it looked like they were ready. Not sure what exactly happened, but I guess I'll reboot later today (and see what happens).

Just got this error while updating to UNRAID 6.10.0 rc4. I previously updated from rc1 to rc3 just fine. The server logs (the ones in the UI) don't seem to show anything valuable regarding this error? Any ideas on how to re-trigger the download maybe? (Although I'm not sure why it failed in the first place, since the internet was working just fine.)

I can't copy some files from my Mac to my UNRAID NAS anymore. Finder always hang at 100% copying and completely locks up. I tracked this down to Samba errors (/var/log/samba/log.smbd is spammed) when the file is copied. Is it possible to (temporarily) update Samba to 4.15.2 to see if the issue is fixed there? (Or does someone have another idea on how to fix this?) Edit: Looked at the previous pages now and it seems like other people also have issues with Samba. I guess I could also revert to rc1 and see if that fixes the issue (and doesn't break anything else). Edit 2: Downgraded back to rc1 and the issue is no longer present. Here's a short example of the logs: [2021/12/06 00:13:41.909635, 0] ../../source3/lib/dumpcore.c:315(dump_core) dumping core in /var/log/samba/cores/smbd [2021/12/06 00:13:41.913951, 0] ../../lib/dbwrap/dbwrap.c:82(dbwrap_record_get_value) PANIC: assert failed at ../../lib/dbwrap/dbwrap.c(82): rec->value_valid [2021/12/06 00:13:41.913963, 0] ../../lib/util/fault.c:172(smb_panic_log) =============================================================== [2021/12/06 00:13:41.913966, 0] ../../lib/util/fault.c:173(smb_panic_log) INTERNAL ERROR: assert failed: rec->value_valid in pid 12146 (4.15.0) [2021/12/06 00:13:41.913968, 0] ../../lib/util/fault.c:177(smb_panic_log) If you are running a recent Samba version, and if you think this problem is not yet fixed in the latest versions, please consider reporting this bug, see https://wiki.samba.org/index.php/Bug_Reporting [2021/12/06 00:13:41.913971, 0] ../../lib/util/fault.c:182(smb_panic_log) =============================================================== [2021/12/06 00:13:41.913974, 0] ../../lib/util/fault.c:183(smb_panic_log) PANIC (pid 12146): assert failed: rec->value_valid in 4.15.0 [2021/12/06 00:13:41.914010, 0] ../../lib/util/fault.c:245(log_stack_trace) BACKTRACE: #0 log_stack_trace + 0x39 [ip=0x151cfca684d9] [sp=0x7ffd74189460] #1 smb_panic + 0x9 [ip=0x151cfca68839] [sp=0x7ffd74189da0] #2 dbwrap_record_get_value + 0x27 [ip=0x151cfb5d69a7] [sp=0x7ffd74189db0] #3 smbXsrv_version_global_current + 0x121a [ip=0x151cfc89d03a] [sp=0x7ffd74189dc0] #4 smb2srv_client_mc_negprot_send + 0x6b [ip=0x151cfc89e03b] [sp=0x7ffd74189ee0] #5 smbd_smb2_request_process_negprot + 0xad2 [ip=0x151cfc885f42] [sp=0x7ffd74189f10] #6 smbd_smb2_request_dispatch + 0x1283 [ip=0x151cfc882e43] [sp=0x7ffd7418a080] #7 smbd_smb2_process_negprot + 0x217 [ip=0x151cfc884c67] [sp=0x7ffd7418a110] #8 smb_request_done + 0x1083 [ip=0x151cfc86eb83] [sp=0x7ffd7418a160] #9 smb_request_done + 0x2226 [ip=0x151cfc86fd26] [sp=0x7ffd7418a210] #10 tevent_common_invoke_fd_handler + 0x91 [ip=0x151cfc6e03f1] [sp=0x7ffd7418a280] #11 tevent_wakeup_recv + 0x108f [ip=0x151cfc6e691f] [sp=0x7ffd7418a2b0] #12 tevent_signal_get_tag + 0xb7 [ip=0x151cfc6e4a87] [sp=0x7ffd7418a310] #13 _tevent_loop_once + 0x94 [ip=0x151cfc6df844] [sp=0x7ffd7418a330] #14 tevent_common_loop_wait + 0x1b [ip=0x151cfc6dfb2b] [sp=0x7ffd7418a360] #15 tevent_signal_get_tag + 0x57 [ip=0x151cfc6e4a27] [sp=0x7ffd7418a380] #16 smbd_process + 0x828 [ip=0x151cfc871388] [sp=0x7ffd7418a3a0] #17 start_fssd + 0x2885 [ip=0x55ac4071f745] [sp=0x7ffd7418a430] #18 tevent_common_invoke_fd_handler + 0x91 [ip=0x151cfc6e03f1] [sp=0x7ffd7418a510] #19 tevent_wakeup_recv + 0x108f [ip=0x151cfc6e691f] [sp=0x7ffd7418a540] #20 tevent_signal_get_tag + 0xb7 [ip=0x151cfc6e4a87] [sp=0x7ffd7418a5a0] #21 _tevent_loop_once + 0x94 [ip=0x151cfc6df844] [sp=0x7ffd7418a5c0] #22 tevent_common_loop_wait + 0x1b [ip=0x151cfc6dfb2b] [sp=0x7ffd7418a5f0] #23 tevent_signal_get_tag + 0x57 [ip=0x151cfc6e4a27] [sp=0x7ffd7418a610] #24 main + 0x1a41 [ip=0x55ac40717ba1] [sp=0x7ffd7418a630] #25 __libc_start_main + 0xcd [ip=0x151cfc04501d] [sp=0x7ffd7418a970] #26 _start + 0x2a [ip=0x55ac407180fa] [sp=0x7ffd7418aa40] [2021/12/06 00:13:41.922829, 0] ../../source3/lib/dumpcore.c:315(dump_core) dumping core in /var/log/samba/cores/smbd [2021/12/06 00:13:41.959236, 0] ../../source3/smbd/fd_handle.c:92(fsp_get_io_fd) fsp_get_io_fd: fsp [---HERE: PATH TO FILE WHICH CAUSES THE ERROR---] is a path referencing fsp [2021/12/06 00:13:41.959255, 0] ../../lib/util/fault.c:172(smb_panic_log) ===============================================================

Issue seems to still be present in 6.10.0-rc2. Closed some old UNRAID tabs (that were open before restarting the machine) and the spamming stopped.

Might be an Unassigned Devices thing, but I can no longer connect to an NFS share on a Windows machine from UNRAID (yes, NFS and not SMB because of Duplicati bugs). Logs: Aug 10 04:54:28 Prime unassigned.devices: Mount NFS command: /sbin/mount -t nfs -o rw,noacl,hard,timeo=600,retrans=10 '192.168.1.12:/duplicati_backups_nfs' '/mnt/remotes/winserver_duplicati_backups_nfs' Aug 10 04:54:28 Prime rpc.statd[10816]: Version 2.5.4 starting Aug 10 04:54:28 Prime rpc.statd[10816]: Flags: TI-RPC Aug 10 04:54:28 Prime rpc.statd[10816]: Failed to register (statd, 1, udp): svc_reg() err: RPC: Remote system error - Connection refused Aug 10 04:54:28 Prime rpc.statd[10816]: Failed to register (statd, 1, tcp): svc_reg() err: RPC: Remote system error - Connection refused Aug 10 04:54:28 Prime rpc.statd[10816]: Failed to register (statd, 1, udp6): svc_reg() err: RPC: Remote system error - Connection refused Aug 10 04:54:28 Prime rpc.statd[10816]: Failed to register (statd, 1, tcp6): svc_reg() err: RPC: Remote system error - Connection refused Aug 10 04:54:28 Prime rpc.statd[10816]: failed to create RPC listeners, exiting Aug 10 04:54:38 Prime unassigned.devices: Error: shell_exec(/sbin/mount -t nfs -o rw,noacl,hard,timeo=600,retrans=10 '192.168.1.12:/duplicati_backups_nfs' '/mnt/remotes/winserver_duplicati_backups_nfs' 2>&1) took longer than 10s! Aug 10 04:54:38 Prime unassigned.devices: NFS mount failed: 'command timed out'. Aug 10 04:54:38 Prime unassigned.devices: Mount of '192.168.1.12:/duplicati_backups_nfs' failed: 'command timed out'. Edit: I get this error when trying to mount the NFS share via CLI: mount.nfs: rpc.statd is not running but is required for remote locking. mount.nfs: Either use '-o nolock' to keep locks local, or start statd. I "fixed it" by starting the port remapper: /etc/rc.d/rc.rpc start