[ NUKI Smartlock ] 73_NUKIBridge.pm und 74_NUKDevice.pm

[CoolTux]

Hier noch die List Ausgaben

Sorry aber so wird das nichts. Was bringt mir Dein Screenshot wenn ich nicht weiß was Du genau gemacht hast. Ich muss schon wissen wie Dein define aus schaut welches Du änderst.
Ich habe ehrlich keine Zeit für solche Halbherzigkeiten. Tut mir Leid.

Gib mir ein vernünftiges Fehlerbild. Übersichtlich wo ich erkenne was Du gemacht hast und wie das Resultat darauf aus sah.

Lösche am besten das NUKIDevice noch mal und lasse es von der Bridge neu anlegen. Klappt das nicht lege es von Hand an und zwar so wie es die Commandref empfiehlt.

[dobiwan]

Sorry aber so wird das nichts. Was bringt mir Dein Screenshot wenn ich nicht weiß was Du genau gemacht hast. Ich muss schon wissen wie Dein define aus schaut welches Du änderst.
Ich habe ehrlich keine Zeit für solche Halbherzigkeiten. Tut mir Leid.

Gib mir ein vernünftiges Fehlerbild. Übersichtlich wo ich erkenne was Du gemacht hast und wie das Resultat darauf aus sah.

Also wenn ich define Haustuer NUKIDevice 1 MyBridge 0 eingebe und das Device erzeugen will bekomme ich folgende Meldung zurück
too few parameters: define <name> NUKIDevice <nukiId> <deviceType>

Ein define Haustuer NUKIDevice 1 0 funktioniert.

Ich habe mir das Commandref durchgelesen. aber mit der Angabe des <IODev-Device> will er es nicht.

Lösche am besten das NUKIDevice noch mal und lasse es von der Bridge neu anlegen. Klappt das nicht lege es von Hand an und zwar so wie es die Commandref empfiehlt.

Ich habe sie schon gelöscht und zwei Tage gewartet. Die werden nicht angelegt.

Im Anhang noch mal die vollständige  Definition der Bevices

Ich verstehe dich ja, dass meine Fehlermeldung nicht genau genug ist, aber wenn ich mich an das Commandref halte funktioniert es nicht.

[CoolTux]

Ich weiß ja das es für Euch einfacher ist wenn ich es mache und ich kann diese Auffassung auch verstehen, immerhin habe ich das Modul ja geschrieben. Aber wenn ich mal nicht so viel Zeit habe und ich Euch dennoch helfen möchte muss eine ordentliche Vorarbeit geleistet werden.

Schau mal hier
https://forum.fhem.de/index.php/topic,55756.msg1104230.html#msg1104230

Dort kann man erlesen wie man an die ID des NUKI Smartlock kommt. Man sieht bei verbose 5 der NUKI Bridge den JSON String wo das Nuki Smartlock drin samt ID aufgeführt wird.

Desweiteren ist die define Syntax

define <name> NUKIDevice <Nuki-Id> <IODev-Device> <Device-Type>

also

define Haustuer NUKIDevice <NUKI_ID_AUS_JSON_STRING> MyBridge 0

Das sollte eigentlich klappen. Wenn das nicht klappt dann lass bitte MyBridge weg, eventuell habe ich da nach dem Umbau was vergessen dann bitte ich um Entschuldigung.

Dann musst Du aber das IODEV über das Attribut korrekt setzen.
Wichtig am Ende für Dich ist die NUKI_ID, wenn Du die korrekt gesetzt hast dann wird es auch klappen.

[heikoh81]

Interessant wäre zu erfahren wann es genau immer so ist.
Es sollte sich definitiv darauf beschränken das es nur unterschiedlich ist wenn aus FHEM raus geschalten wird. Wenn am Schloss direkt oder über die App geschalten wird dürfte das nie passieren.

Wenn es zu einer Abweichung zwischen state und stateName kommt, wurde davor immer mit FHEM gesteuert.
Ich kontrolliere immer nachts vor dem Schlafengehen den Zustand der Haustür, deshalb fällt es mir nur da auf.
Ich habe neben der Haustür einen Taster, der für das Außenlicht gedacht war, umgewandelt in einen, der per MQTT an fhem meldet. Daraufhin erfolgt über ein DOIF dann der Befehl an die Bridge, abzuschließen.
Wir haben noch einen Ekey Uno Fingerprint Reader, der direkt am Nuki angelernt ist. Der wird aber nur tagsüber verwendet, und definitv nicht zum nächtlichen Abschließen, der hängt ja außen 

Viele Grüße,
Heiko

[CoolTux]

Wenn es zu einer Abweichung zwischen state und stateName kommt, wurde davor immer mit FHEM gesteuert.
Ich kontrolliere immer nachts vor dem Schlafengehen den Zustand der Haustür, deshalb fällt es mir nur da auf.
Ich habe neben der Haustür einen Taster, der für das Außenlicht gedacht war, umgewandelt in einen, der per MQTT an fhem meldet. Daraufhin erfolgt über ein DOIF dann der Befehl an die Bridge, abzuschließen.
Wir haben noch einen Ekey Uno Fingerprint Reader, der direkt am Nuki angelernt ist. Der wird aber nur tagsüber verwendet, und definitv nicht zum nächtlichen Abschließen, der hängt ja außen 

Viele Grüße,
Heiko

Ich habe mir mal Deine Infos genau angeschaut. Dein erster Post zeigt in einem Screenshot tatsächlich einen Unterschied zwischen state und stateName.

Dein zweiter Post hingegen, wo Du sagtest Du hast auf verbose 5 gestellt zeigt das sowohl state als auch stateName korrekt (gleich) sind.
Desweiteren ist mir aufgefallen das die Logausgabe welche hier gezeigt wird kein verbose 5 Log ist sondern wohl ein Eventlog. So richtig schlau werde ich leider immer noch nicht aus der ganzen Sache. Am besten beschreibt das Problem in der Tat Dein erster Post und dort sieht man sehr gut das wohl etwas nicht stimmt. Aber selbst wenn beim ersten Post wo die beiden Readings unterschiedlich sind aus FHEM heraus geschalten wurde müsste das Reading state anders lauten.


Grüße

[popy]

Hallo Zusammen.

Funktioniert den bei euch die Klingel Erkennung über den Opener zuverlässig mit dem ringactionState?

Hab das im Sommer getestet und es funktionierte einfach nicht stabil bzw. Schnell genug. Bin dann wieder zurück auf mein Relais + Hue Dimmer, was schnell und zuverlässig geht.

Hier fängt der "alte" Beitrag an : https://forum.fhem.de/index.php/topic,55756.msg1089804.html#msg1089804

Hier der Code den ich damals in einem notify + wdt verwendet hatte.

Code Auswählen Erweitern

VR_NUKI_Haustuer:ringactionState:.* {   
​
  Log 1, "act_VR_Klingel_Nuki: ringactionState/event: ".$EVENT." - state: ".Value($NAME);
 
  #rto active?
  if(index(Value($NAME), "rto") != -1)
  {
    #rto active
    fhem("setreading ".$NAME." rto_active rto_active");
  }
 
  #reset rto state to online
  if((index($EVENT, "0") != -1) && (index(Value($NAME), "online") != -1))
  {
    #reset rto state to online
    fhem("setreading ".$NAME." rto_active online ;");
    fhem("setstate watchdog_VR_Klingel defined ;");
  }
 
  #someone rang?
  if(index($EVENT, "1") != -1)  {
    #known or unkown?
    if(index(ReadingsVal($NAME,"rto_active", "online"), "online") != -1)
    {
        #someone unkown rang!
        Log 1, "act_VR_Klingel_Nuki: someone unkown rang!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!";
    }
    #reset rto state to online
    fhem("setreading ".$NAME." rto_active online ;");
    fhem("setstate watchdog_VR_Klingel defined ;");
  }
}


Wie macht ihr das und funktioniert das bei euch stabil und schnell zur Klingel Erkennung?

Danke

[Thyraz]

Was bedeutet schnell für dich?

Ich habe max. 2 Sekunden Verzögerung zum Relais das parallel dran hängt.
Meist weniger.

Da ich immer noch zu faul war das Relais abzuklemmen und für beides Push Notifications auf dem Handy habe, hab ich da die tägliche Kontrolle.
Komplettaussetzer hatte ich bisher keine.

[dobiwan]

Ich weiß ja das es für Euch einfacher ist wenn ich es mache und ich kann diese Auffassung auch verstehen, immerhin habe ich das Modul ja geschrieben. Aber wenn ich mal nicht so viel Zeit habe und ich Euch dennoch helfen möchte muss eine ordentliche Vorarbeit geleistet werden.

Schau mal hier
https://forum.fhem.de/index.php/topic,55756.msg1104230.html#msg1104230

Dort kann man erlesen wie man an die ID des NUKI Smartlock kommt. Man sieht bei verbose 5 der NUKI Bridge den JSON String wo das Nuki Smartlock drin samt ID aufgeführt wird.

Desweiteren ist die define Syntax

define <name> NUKIDevice <Nuki-Id> <IODev-Device> <Device-Type>

also

define Haustuer NUKIDevice <NUKI_ID_AUS_JSON_STRING> MyBridge 0

Das sollte eigentlich klappen. Wenn das nicht klappt dann lass bitte MyBridge weg, eventuell habe ich da nach dem Umbau was vergessen dann bitte ich um Entschuldigung.

Dann musst Du aber das IODEV über das Attribut korrekt setzen.
Wichtig am Ende für Dich ist die NUKI_ID, wenn Du die korrekt gesetzt hast dann wird es auch klappen.

Hallo Danke für die Hilfe,

jetzt läuft alles.

[popy]

Was bedeutet schnell für dich?

Ich habe max. 2 Sekunden Verzögerung zum Relais das parallel dran hängt.
Meist weniger.

Da ich immer noch zu faul war das Relais abzuklemmen und für beides Push Notifications auf dem Handy habe, hab ich da die tägliche Kontrolle.
Komplettaussetzer hatte ich bisher keine.

Schnell = Instant 
Nein, natürlich reichen 1-2 Sekunden 

Bei meinen Tests vor ein paar Monaten war es aber sehr viel mehr und manchmal gar nicht.

Kannst du dein Notify posten mit dem du das auswertest bzw. darauf reagierst?
Wie hast du das gelöst wenn "RTO_active" ist.
Das verhielt sich bei mir vor ein paar Monaten auch nicht zuverlässig.
Natürlich will ich wenn "RTO_active" nicht die AKtionen in FHEM triggern.

Danke

[fsch]

Hallo zusammen,

habe das Nuki-Schloss auch seit zwei Tagen in Betrieb.

(1)
Das Ganze funktioniert sauber, danke für die Module.

(2)
Unschön finde ich nur die Geschwätzigkeit der Nuki-Bridge im Event-Monitor. Die sendet z.T. mehrmals in einer Minute einen Status, der sich eigentlich nur in der Signalstärke, Uptime und Current-Time unterscheidet.
Das sind Infos, die mir auch alle paar Stunden reichen würden.

Die Meldungen werden vermutlich von der Bridge gepusht.
Gibt es eine Möglichkeit, die Häufigkeit dieser Meldungen zu reduzieren?

(3)
Im Wiki (wiki.fhem.de/wiki/NUKI) werden webhookHttpHostname und webhookFWinstance im Abschnitt NUKIDevice als Attribute des Device dargestellt. Das sind aber eigentlich Attribute der Bridge.

(4)
Ggf. könnte man im Wiki auch hinterlegen, wo man die IP und den API-Key findet. Offenbar gab es ein Update der Nuki-App, sodass die Erklärungen dazu im Internet nicht mehr zutreffend sind.
Auch der Umstand, dass sich fhem nicht mit der Bridge verbindet, solange diese im Config-Modus in der App ist, wäre einen Hinweis wert.

Gruß
Frank

[fsch]

Habe selbst mal gesucht.
Ist gar kein Push, sondern 73_NUKIBridge.pm pullt alle 30 Sekunden in einem Alive-Check (GetCheckBridgeAlive).
InternalTimer( gettimeofday() + 30,
        'NUKIBridge_GetCheckBridgeAlive', $hash );

Gibt es einen Grund, warum der Alive-Check so häufig gemacht wird?
Vielleicht könnte man ein Attribut spendieren.

[CoolTux]

Schau mal hier
https://wiki.fhem.de/wiki/Event-on-change-reading

[freddeh]

Hi ihr Lieben,

ich scheitere aktuell an der Einbindung meines Nuki Smartlocks in FHEM.

Bridge:

Code Auswählen Erweitern

Internals:
   BRIDGEAPI  1.9
   DEF        192.168.0.114 t****7
   FUUID      60f9ca4b-f33f-****-7450-022024d5167f5ff3
   FVERSION   73_NUKIBridge.pm:v1.9.16-s20994/2020-01-16
   HOST       192.168.0.114
   NAME       NUKIBridge
   NOTIFYDEV  global,NUKIBridge
   NR         500
   NTFY_ORDER 50-NUKIBridge
   PORT       8080
   STATE      connected
   TOKEN      t****7
   TYPE       NUKIBridge
   VERSION    v1.9.16
   WEBHOOK_COUNTER 1
   WEBHOOK_LAST 2021-07-30 23:01:22
   WEBHOOK_PORT 8084
   WEBHOOK_REGISTER sent
   WEBHOOK_URI /fhem/NUKIBridge-192.168.0.114
   WEBHOOK_URL http://192.168.0.112:8084/fhem/NUKIBridge-192.168.0.114
   READINGS:
     2021-07-30 22:34:22   bridgeType      Hardware
     2021-07-30 22:34:22   currentTime     2021-07-30T20:34:21+00:00
     2021-07-30 22:34:22   firmwareVersion 2.9.3
     2021-07-30 22:34:22   hardwareId      5482**570
     2021-07-30 22:34:22   serverConnected 1
     2021-07-30 22:34:22   serverId        553196154
     2021-07-30 23:11:31   state           connected
     2021-07-30 22:34:22   uptime          1492
     2021-07-30 22:34:22   wifiFirmwareVersion 2.2.0
   fhem:
     infix      NUKIBridge
   helper:
     iowrite    0
     actionQueue:
Attributes:
   icon       1_nuki_bridge
   room       NUKI
   verbose    5
   webhookFWinstance WEBnuki
   webhookHttpHostname 192.168.0.112

Smartlock:

Code Auswählen Erweitern

Internals:
   BRIDGEAPI  1.9
   DEF        592***821 0
   DEVICETYPE 0
   FUUID      60f9ca4b-f33f-0d64-****-a0ead5f6ffce4659
   FVERSION   74_NUKIDevice.pm:v1.9.12-s21020/2020-01-20
   IODev      NUKIBridge
   LASTInputDev NUKIBridge
   MSGCNT     7
   NAME       Garten
   NOTIFYDEV  global,autocreate,Garten
   NR         501
   NTFY_ORDER 50-Garten
   NUKIBridge_MSGCNT 7
   NUKIBridge_TIME 2021-07-30 23:11:31
   NUKIID     592***821
   STATE      smartlock response error
   TYPE       NUKIDevice
   VERSION    v1.9.12
   READINGS:
     2021-07-30 22:56:36   IODev           NUKIBridge
     2021-07-30 23:01:22   batteryChargeState 88
     2021-07-30 23:01:22   batteryCharging 0
     2021-07-30 23:01:22   batteryState    ok
     2021-07-30 23:01:22   deviceType      smartlock
     2021-07-30 23:01:22   doorsensorState 2
     2021-07-30 23:01:22   doorsensorStateName door closed
     2021-07-30 22:52:10   firmwareVersion 2.10.8
     2021-07-30 23:01:22   mode            door mode
     2021-07-30 22:52:10   name            Garten
     2021-07-30 23:11:31   nukiId          592***821
     2021-07-30 22:34:22   paired          true
     2021-07-30 22:34:22   rssi            -84
     2021-07-30 23:11:24   state           smartlock response error
     2021-07-30 23:01:22   stateName       locked
     2021-07-30 23:11:31   success         0
   helper:
Attributes:
   genericDeviceType lock
   icon       1_nuki
   model      smartlock
   room       Garten,HomeKit,NUKI
   verbose    5


FHEM Instanz:

Code Auswählen Erweitern

Internals:
   BYTES_READ 415
   BYTES_WRITTEN 0
   CONNECTS   261
   CSRFTOKEN  csrf_499071***255409
   DEF        8084 global
   FD         7
   FUUID      61045eea-***-0d64-fcfb-a47c83b9c862abc7
   NAME       WEBnuki
   NR         18
   NTFY_ORDER 50-WEBnuki
   PORT       8084
   STATE      Initialized
   TYPE       FHEMWEB
   READINGS:
     2021-07-30 22:56:34   state           Initialized
Attributes:
   allowfrom  192.168.0.114
   hiddenroomRegexp ^(?!NUKI)
   room       System

Sowohl der Webhook scheint nicht zuverlässig zu funktionieren als auch das Öffnen/Schließen des Schlosses liefert immer nur einen Error 503...
Per App funktioniert alles...

Log eines Schließvorgangs:

Code Auswählen Erweitern

2021.07.30 23:21:51 4: NUKIBridge (NUKIBridge) - Response JSON: {"success": false}
2021.07.30 23:21:51 4: NUKIBridge (NUKIBridge) - Response ERROR:
2021.07.30 23:21:51 4: NUKIBridge (NUKIBridge) - Response CODE: 200
2021.07.30 23:21:51 5: NUKIBridge (NUKIBridge) - Bridge ist online
2021.07.30 23:21:51 5: NUKIBridge: dispatch {"nukiId":"592***821","success":false}
2021.07.30 23:21:51 5: NUKIDevice (NUKIBridge) - Parse with result: {"nukiId":"592***821","success":false}
2021.07.30 23:21:51 4: NUKIBridge (NUKIBridge) - created uri: http://192.168.0.114:8080/lockState?token=t****7&nukiId=592***821&deviceType=0
2021.07.30 23:21:51 4: NUKIBridge (NUKIBridge) - Send HTTP POST with URL http://192.168.0.114:8080/lockState?token=t****7&nukiId=592***821&deviceType=0
2021.07.30 23:21:51 5: NUKIDevice (Garten) - lockAction readings set for Garten
2021.07.30 23:21:51 4: NUKIDevice (Garten) - find logical device: Garten
2021.07.30 23:21:52 4: NUKIBridge (NUKIBridge) - Response JSON: HTTP 503 Unavailable
2021.07.30 23:21:52 4: NUKIBridge (NUKIBridge) - Response ERROR:
2021.07.30 23:21:52 4: NUKIBridge (NUKIBridge) - Response CODE: 503
2021.07.30 23:21:52 4: NUKIBridge (NUKIBridge) - Response from Bridge: 503, HTTP 503 Unavailable

Jemand eine Idee?

[Udomatic]

Hi ihr Lieben,

ich scheitere aktuell an der Einbindung meines Nuki Smartlocks in FHEM.

Bridge:

Code Auswählen Erweitern

Internals:
   BRIDGEAPI  1.9
   DEF        192.168.0.114 t****7
   FUUID      60f9ca4b-f33f-****-7450-022024d5167f5ff3
   FVERSION   73_NUKIBridge.pm:v1.9.16-s20994/2020-01-16
   HOST       192.168.0.114
   NAME       NUKIBridge
   NOTIFYDEV  global,NUKIBridge
   NR         500
   NTFY_ORDER 50-NUKIBridge
   PORT       8080
   STATE      connected
   TOKEN      t****7
   TYPE       NUKIBridge
   VERSION    v1.9.16
   WEBHOOK_COUNTER 1
   WEBHOOK_LAST 2021-07-30 23:01:22
   WEBHOOK_PORT 8084
   WEBHOOK_REGISTER sent
   WEBHOOK_URI /fhem/NUKIBridge-192.168.0.114
   WEBHOOK_URL http://192.168.0.112:8084/fhem/NUKIBridge-192.168.0.114
   READINGS:
     2021-07-30 22:34:22   bridgeType      Hardware
     2021-07-30 22:34:22   currentTime     2021-07-30T20:34:21+00:00
     2021-07-30 22:34:22   firmwareVersion 2.9.3
     2021-07-30 22:34:22   hardwareId      5482**570
     2021-07-30 22:34:22   serverConnected 1
     2021-07-30 22:34:22   serverId        553196154
     2021-07-30 23:11:31   state           connected
     2021-07-30 22:34:22   uptime          1492
     2021-07-30 22:34:22   wifiFirmwareVersion 2.2.0
   fhem:
     infix      NUKIBridge
   helper:
     iowrite    0
     actionQueue:
Attributes:
   icon       1_nuki_bridge
   room       NUKI
   verbose    5
   webhookFWinstance WEBnuki
   webhookHttpHostname 192.168.0.112

Smartlock:

Code Auswählen Erweitern

Internals:
   BRIDGEAPI  1.9
   DEF        592***821 0
   DEVICETYPE 0
   FUUID      60f9ca4b-f33f-0d64-****-a0ead5f6ffce4659
   FVERSION   74_NUKIDevice.pm:v1.9.12-s21020/2020-01-20
   IODev      NUKIBridge
   LASTInputDev NUKIBridge
   MSGCNT     7
   NAME       Garten
   NOTIFYDEV  global,autocreate,Garten
   NR         501
   NTFY_ORDER 50-Garten
   NUKIBridge_MSGCNT 7
   NUKIBridge_TIME 2021-07-30 23:11:31
   NUKIID     592***821
   STATE      smartlock response error
   TYPE       NUKIDevice
   VERSION    v1.9.12
   READINGS:
     2021-07-30 22:56:36   IODev           NUKIBridge
     2021-07-30 23:01:22   batteryChargeState 88
     2021-07-30 23:01:22   batteryCharging 0
     2021-07-30 23:01:22   batteryState    ok
     2021-07-30 23:01:22   deviceType      smartlock
     2021-07-30 23:01:22   doorsensorState 2
     2021-07-30 23:01:22   doorsensorStateName door closed
     2021-07-30 22:52:10   firmwareVersion 2.10.8
     2021-07-30 23:01:22   mode            door mode
     2021-07-30 22:52:10   name            Garten
     2021-07-30 23:11:31   nukiId          592***821
     2021-07-30 22:34:22   paired          true
     2021-07-30 22:34:22   rssi            -84
     2021-07-30 23:11:24   state           smartlock response error
     2021-07-30 23:01:22   stateName       locked
     2021-07-30 23:11:31   success         0
   helper:
Attributes:
   genericDeviceType lock
   icon       1_nuki
   model      smartlock
   room       Garten,HomeKit,NUKI
   verbose    5


FHEM Instanz:

Code Auswählen Erweitern

Internals:
   BYTES_READ 415
   BYTES_WRITTEN 0
   CONNECTS   261
   CSRFTOKEN  csrf_499071***255409
   DEF        8084 global
   FD         7
   FUUID      61045eea-***-0d64-fcfb-a47c83b9c862abc7
   NAME       WEBnuki
   NR         18
   NTFY_ORDER 50-WEBnuki
   PORT       8084
   STATE      Initialized
   TYPE       FHEMWEB
   READINGS:
     2021-07-30 22:56:34   state           Initialized
Attributes:
   allowfrom  192.168.0.114
   hiddenroomRegexp ^(?!NUKI)
   room       System

Sowohl der Webhook scheint nicht zuverlässig zu funktionieren als auch das Öffnen/Schließen des Schlosses liefert immer nur einen Error 503...
Per App funktioniert alles...

Log eines Schließvorgangs:

Code Auswählen Erweitern

2021.07.30 23:21:51 4: NUKIBridge (NUKIBridge) - Response JSON: {"success": false}
2021.07.30 23:21:51 4: NUKIBridge (NUKIBridge) - Response ERROR:
2021.07.30 23:21:51 4: NUKIBridge (NUKIBridge) - Response CODE: 200
2021.07.30 23:21:51 5: NUKIBridge (NUKIBridge) - Bridge ist online
2021.07.30 23:21:51 5: NUKIBridge: dispatch {"nukiId":"592***821","success":false}
2021.07.30 23:21:51 5: NUKIDevice (NUKIBridge) - Parse with result: {"nukiId":"592***821","success":false}
2021.07.30 23:21:51 4: NUKIBridge (NUKIBridge) - created uri: http://192.168.0.114:8080/lockState?token=t****7&nukiId=592***821&deviceType=0
2021.07.30 23:21:51 4: NUKIBridge (NUKIBridge) - Send HTTP POST with URL http://192.168.0.114:8080/lockState?token=t****7&nukiId=592***821&deviceType=0
2021.07.30 23:21:51 5: NUKIDevice (Garten) - lockAction readings set for Garten
2021.07.30 23:21:51 4: NUKIDevice (Garten) - find logical device: Garten
2021.07.30 23:21:52 4: NUKIBridge (NUKIBridge) - Response JSON: HTTP 503 Unavailable
2021.07.30 23:21:52 4: NUKIBridge (NUKIBridge) - Response ERROR:
2021.07.30 23:21:52 4: NUKIBridge (NUKIBridge) - Response CODE: 503
2021.07.30 23:21:52 4: NUKIBridge (NUKIBridge) - Response from Bridge: 503, HTTP 503 Unavailable

Jemand eine Idee?

In der Bridge hast du das Attribut webhookFWinstance mit WEBnuki gesetzt. Heist deine FHEM Webinstanz wirklich so? Im Standard ist das eigentlich immer nur WEB

[freddeh]

In der Bridge hast du das Attribut webhookFWinstance mit WEBnuki gesetzt. Heist deine FHEM Webinstanz wirklich so? Im Standard ist das eigentlich immer nur WEB

Ja, ich hatte hier im Thread gelesen es ist ratsam eine eigene Instanz für das Nuki einzurichten, die "List"-Info zu dem WEBnuki steht oben. Ist auf die IP und den Raum vom Nuki beschränkt.