test: modul 74_UnifiProtect.pm & 74_UnifiProtectDevice.pm

[Mitch]

Danke @Ralli, geht auch bei mir wieder!

[Mitch]

Nachtrag: das neue Modul spamt mir den Log zu:

Can't read ./FHEM/_UnifiProtectDevice.pm

[Ralli]

Kann ich nicht nachvollziehen, vor allem nicht mit diesem Namen - hast du vielleicht noch eine Sicherheitskopie mit abgewandeltem Namen im Verzeichnis? Berechtigungen passen?

Edit: Und du hast aus diesem Thread hier auch die Datei 74_UnifiProtectDevice.pm mit den passenden Berechtigungen im FHEM-Verzeichnis?

[Mitch]

Ja, stimmt natürlich alles.
Merkwürdig ist, dass es gar keine UnifiProtectDevice.pm Datei gibt?

[Ralli]

Dann musst du bei dem ersten Beitrag dieses Threads anfangen. 

[Mitch]

Danke Dir!
Komisch, dass die Datei bei mir nicht vorhanden war?

Mal sehen, ob es jetzt noch zu Fehlern kommt.

[OliS.]

Ralli, danke für das angepasste Modul.
Jetzt wird bei mir zumindest das UnifiProtectDevice angelegt. Nach dem Anlegen kommen auch Readings. Allerdings werden die wenigsten davon tatsächlich aktualisiert. Und soetwas wie ein Ring-Event scheint es an dem Device auch nicht zu geben.
Das Reading lastMotion wird zwar (sehr stark verzögert aktualisiert, motion jedoch seit dem Anlegen noch gar nicht. Habe ich möglicherweise etwas übersehen? Fehlt vieleicht noch eine Einstellung in UnifiProtect?

Code Auswählen Erweitern

DEF        64777dc80111aa03e40003ef
  FUUID      657ee046-f33f-08ae-5449-073728b5d7d07014
  IODev      UnifiProtect
  NAME      UnifiProtectDevice_Doorbell
  NR        1020
  STATE      CONNECTED
  TYPE      UnifiProtectDevice
  enabledFeatures led
  eventCount 409
  featureFlags audioCodecs:[aac,opus] noAdjustIrLedLevel noMagicZoom noOpticalZoom noTouchFocus noAccelerometer hasAec hasAutoICROnly noBattery hasBluetooth hasChime noColorLcdScreen noExternalIr noFlash hasHdr hasIcrSensitivity hasInfrared hasLcdScreen hasLdc hasLedIr hasLedStatus hasLineCrossing noLineCrossingCounting noLineIn noLiveviewTracking hasMic hasMotionZones noPackageCamera hasPrivacyMask noRtc noSdCard hasSmartDetect hasSpeaker hasSquareEventThumbnail hasWifi isDoorbell isPtz  motionAlgorithms:[enhanced] smartDetectAudioTypes:[smoke_cmonx] smartDetectTypes:[person,vehicle,package] videoModeMaxFps:[30,30,45,30,20] videoModes:[default,homekit,highFps,sport,slowShutter]
  firmwareVersion 4.68.17
  hardwareRevision 23
  id        64777dc80111aa03e40003ef
  ispSettings.aeMode auto
  mac        68D79ADF986B
  marketName G4 Doorbell
  micVolume  66
  model      UVC G4 Doorbell
  modelKey  camera
  name      Haustuer
  phyRate    43
  smartDetectSettings.objectTypes person,package
  type      UVC G4 Doorbell
  videoMode  default
  wifiConnectionState.channel 11
  wifiConnectionState.frequency 2462
  wifiConnectionState.phyRate 43
  wifiConnectionState.signalQuality 90
  wifiConnectionState.signalStrength -73
  READINGS:
    2023-12-17 12:54:19  IODev          UnifiProtect
    2023-12-17 12:49:27  connectedSince  2023-12-17 11:41:11
    2023-12-17 12:49:27  eventStats.motion.lastDays 0,0,0,0,0,0,0
    2023-12-17 12:49:27  eventStats.motion.recentHours 0,0,0,0,0,0,0,0,0,0,0,0,0
    2023-12-18 00:08:31  eventStats.smart.average 26
    2023-12-19 00:09:03  eventStats.smart.lastDays 19,11,28,31,25,37,32
    2023-12-19 15:09:22  eventStats.smart.today 9
    2023-12-17 12:49:27  hdrMode        true
    2023-12-17 12:49:27  irLedMode      auto
    2023-12-19 08:39:13  isDark         
    2023-12-19 15:09:22  lastMotion      2023-12-19 15:09:21
    2023-12-19 15:29:23  lastSeen        2023-12-19 15:28:21
    2023-12-17 15:51:52  micVolume      66
    2023-12-17 12:49:27  motion          nomotion
    2023-12-17 12:49:27  recordingMode  detections
    2023-12-17 12:49:27  state          CONNECTED
    2023-12-17 12:49:27  statusLed      false
    2023-12-19 15:14:22  upSince        2023-12-17 11:18:41
    2023-12-17 12:49:27  videoMode      default
  helper:
    featureFlags:
      lensModel 
      lensType 
      audio:
      audioCodecs:
        aac
        opus
      focus:
        degrees:
          max       
          min       
          step     
        steps:
          max       
          min       
          step     
      hotplug:
        audio     
        video     
        extender:
          hasFlash 
          hasIR     
          hasRadar 
      motionAlgorithms:
        enhanced
      mountPositions:
      pan:
        degrees:
          max       
          min       
          step     
        steps:
          max       
          min       
          step     
      privacyMaskCapability:
        maxMasks  16
      smartDetectAudioTypes:
        smoke_cmonx
      smartDetectTypes:
        person
        vehicle
        package
      tilt:
        degrees:
          max       
          min       
          step     
        steps:
          max       
          min       
          step     
      videoModeMaxFps:
        30
        30
        45
        30
        20
      videoModes:
        default
        homekit
        highFps
        sport
        slowShutter
      zoom:
        ratio      1
        degrees:
          max       
          min       
          step     
        steps:
          max       
          min       
          step     
Attributes:
  IODev      UnifiProtect
  alias      Haustuer
  includeEventStats 1
  room      UnifiProtectLG
OliS.

[BergMuel]

Ich denke, ich konnte das Problem lösen. Seit einem der letzten Updates wird zunächst beim Login kein CSRF-Token übermittelt. Dies wird in in einer Routine ausgewertet und damit festgelegt, ob die Maschine UnifiOS hat oder nicht - und dies ist wiederum die entscheidende Variable für den richtigen URL-Zusammenbau. Ab dem erfolgreichen Login wird allerdings das CSRF-Token übermittelt und ist ab dann auch wichtig.

Anbei die von mir angepasste 74_UnifiProtect.pm, mit der es bei mir wieder klappt.

Achtung: in der Routine isUnifiOS wird nun nicht wirklich darauf geprüft sondern das zwangsweise angenommen - mit Firmware-Versionen vor 3.2.x dürfte diese Version nicht funktionieren, sie ist daher ausschließlich für Geräte, die min. UnifiOS 3.2.x einsetzen, geeignet.

Vielen Dank @Ralli für den Fix vom 16.12.23. Auf den ersten Blick scheint alles wieder zu funktionieren. ABER: nun habe ich festgestellt, dass mein System alle rund 12 Minuten abstürzt und neu startet.
Im Fhem Log finde ich folgenden Eintrag: Undefined subroutine &main::UnifiProtect_ConnectWebsocket
Mein System läuft ansonsten einwandfrei. UnifiProtect ist auf Version 3.2.7 und erfüllt somit auch die Anforderungen für den Fix.

Hat jemand ein ähnliches Phänomen und/oder sogar eine Lösung dazu?

[Ralli]

Kann ich hier nicht nachvollziehen. Vor allem deswegen nicht, weil eine solche Funktion "UnifiProtect_ConnectWebsocket" weder aus der 74_UnifiProtect.pm noch aus der 74_UnifiProtectDevice.pm aufgerufen wird.

BTW: Protect ist bestimmt nicht auf Version 3.2.7 sondern das darunter liegende Unifi-OS.

[BergMuel]

Danke @Ralli für Deine prompte Antwort!
Und ja, natürlich meinte ich mit V3.2.7 das darunter liegend Unifi-OS. Sorry, ich war unpräzise...

In Deiner modifizierten Datei 74_UnifiProtect.pm wird beispielsweise in Zeile 716 das Websocket eingesetzt. Ich kann es zweifelsfrei reproduzieren. Spiele ich wieder die "alte" Datei vom 13.02.22 ein, dann läuft das System stabil, aber die Bilder werden natürlich nicht mehr geliefert. Mit Deiner Version vom 16.12.23 habe ich dann zwar die Bilder, aber zuverlässig auch die Abstürze. Mit dem Austausch der Datei 74_UnifiProtect.pm (und einem entsprechenden reload in Fhem) kann ich das so beeinflussen.

Könnte es sein, dass ich allenfalls noch etwas in Bezug auf websocket nachspielen muss? Kennst Du da die Systemvoraussetzungen?

[Ralli]

Protect ist bei mir die Version 2.10.11 - keine Ahnung, ob das noch eine Rolle spielt in diesem Zusammenhang.

Ja, natürlich werden Websockets verwendet. Aber es gibt mehrere Funktionen, die sich darum kümmern und interessanterweise keine mit dem Namen "UnifiProtect_ConnectWebsocket" sondern immer mit Unterstrich und weiterem Text dahinter.

Gehe mal auf Verbose 5 und poste das Log bis zum Absturz. Dazu bitte ein list vom UnifiProtect-Device.

Nein, nicht dass ich wüsste - zumal ich ja sonst keine Zeilen im Modul angepasst habe außer zweier, wo es um die Erkennung des überlieferten CSRF-Tokens geht. Was für ein System ist unter FHEM? System und FHEM sind aktuell?

Fast das wichtigste vergessen: was hast du für Unifi-Maschine? Nicht dass bei dir richtigerweise isUnifiOS = 0 zurückliefern sollte!

Probiere mal die erneut modifizierte UnifiProtect.pm. Dort habe ich jetzt das Attribut "isUnifiOS" hinzugefügt. Default ist der Wert im Modul auf 1 gesetzt und die UnifiOS-spezifische URL wird für den Login und API-Aufrufe genutzt, wird das neue Attribut auf 0 gesetzt, dann wird die alternative URL genutzt.

Referenz: https://ubntwiki.com/products/software/unifi-controller/api

Darüber hinaus habe ich noch ein paar Zeilen geändert, um Warnungen im FHEM-Log über nicht-initialisierte Variablen zu elimenieren, und ein paar Veränderungen vorgenommen, sodass mehr Events ausgewertet werden können.

[BergMuel]

Protect ist bei mir auch die Version 2.10.11
System läuft auf einem Raspberry PI 4
Das RPI halte ich monatlich atuell.
Bei Fhem bin ich etwas zurückhaltender. Da aktualisierte ich nur einzelne Module, und nur wenn ich etwas vermisse, resp. neues benötige.

Zu den Listings...
Während ich nun Verbose auf 5 gesetzt habe und das Protect und das erste Device detailliert aufgezeichnet und währenddessen die Listings erstellt habe, konnte ich nun #magic während einer halben Stunde keinen Absturz mehr beobachten. Eigentlich schön, aber irgendwie auch doof. Ich kann mir nur vorstellen, dass nun mit dem erneuten beschreiben, reconnecten und so etwas korrekt verankert wurde, was vorher nicht der Fall war.

Um ganz sicher zu gehen, habe ich das RPI noch neu gestartet. Danach leider wieder die alten Probleme.
Ich schiebe die Listings noch nach. Muss zuerst alles erwischen...

[Ralli]

Bei Fhem bin ich etwas zurückhaltender. Da aktualisierte ich nur einzelne Module, und nur wenn ich etwas vermisse, resp. neues benötige.

Das ist nicht gut, da ja auch einige Basisdateien und Abhängigkeiten immer wieder erneuert werden.

Daher: mein FHEM ist aktuell und deines sollte es auch sein, damit wir veraltete Software-Stände oder gar fehlende Dateien als Ursache ausschließen können.

[BergMuel]

Du hast wohl recht. Bevor wir uns hier weiter beüben, sollte ich sauberen Tisch machen.
Ich werde das ganze mal auf den neusten Stand bringen...

Edit / 29.12.23:
Du hattest Recht @Ralli...! Ein Update des kompletten Fhem hat das Problem gelöst. Es gab zwar einige kleine Nebeneffekte mit geänderten State Werten und Readings. Aber am Ende läuft nun alles wieder wie gewünscht und meine FHEM Installation ist sogar mal wieder auf dem neusten Stand. Das soll mir (und hoffentlich auch vielen anderen) eine Lehre sein. Haltet Eure Systeme auf dem neusten Stand!
Vielen Dank an @Ralli für die Unterstützung und Deine tolle Arbeit! Das Problem lag klar auf meiner Seite, wofür ich mich entschuldige!

[Ralli]

Allerdings werden die wenigsten davon tatsächlich aktualisiert. Und soetwas wie ein Ring-Event scheint es an dem Device auch nicht zu geben.
Das Reading lastMotion wird zwar (sehr stark verzögert aktualisiert, motion jedoch seit dem Anlegen noch gar nicht. Habe ich möglicherweise etwas übersehen? Fehlt vieleicht noch eine Einstellung in UnifiProtect?

In dem Beitrag https://forum.fhem.de/index.php?msg=1297819 habe ich die zwei aktualisierten Dateien eingefügt, die auch das Event-Handling verbessern und zu deutlich mehr Events führen und vor allem die Aktualisierung der Readings wesentlich schneller vornehmen sollten.

Ob es einen Ring-Event gibt, kann ich dir nicht sagen, habe keine Doorbell. Allerdings kannst du mit verbose 4 oder 5 jetzt haufenweise Daten sammeln -> verbose 5 einschalten, Klingeln, wieder auf verbose 3 zurück. Vielleicht kann man was herausziehen.