Hätte ich auch so gesehen. Eventuell, wenn das möglich ist, könnte man ja nach einer Wartezeit den Befehl der gesendet werden sollte noch einmal senden. Oder vorher prüfen ob der Server (Bridge) verfügbar ist und wenn nicht, warten und dann erst senden. Sind mal so Ideen die mir eben eingefallen sind.
Super Uli,
vielen Dank für das Modul. Als Du das gestern oder Sonntag in Discord erwähntest hatte ich nicht zu wagen gehofft dass Du schon „lieferst“. Mein Nuki kommt morgen, so kann ich wohl bald „mitmachen“.
Danke und Gruss Seppm
Ich denke mal darüber nach, wie man es lösen könnte…
Ansätze von dir sind aber erstmal gut.
Uli
503 wird auch im Nuki Forum besprochen:
Habe schon ein paar Ideen, vielleicht schaffe ich es bis heute Abend umzusetzen.
Uli
Das heißt, auch Nuki empfiehlt die Wiederholung des Befehls.
Zum Log möchte ich noch was sagen. Erstens gefällt mir gut.
Ich denke aber, dass da nur Meldungen rein kommen, die als Auslöser eine Aktion in IPS haben. Ich bin mir aber fast sicher, dass das Modul auch alle „externen“ Änderungen (Aufsperren über das Keypad, automatischen Zu- und Aufsperren bei aktiviertem Tag/Nacht Modus) mitbekommt. Eventuell könnte man diese Änderungen auch ins Log mit aufnehmen. Womöglich sogar speziell gekennzeichnet (z.b. Schrift kursiv oder fett). Das man nicht erfährt, wer - Keypad, manuell, Autounlock - es gemacht hat, ist mir klar.
Edit: Ah, ich sehe das passiert schon, das mit dem Logeintrag. Ich hab es nur nicht gesehen, weil ich auf dein Anraten die automatische Aktualisierung des SmartLocks deaktiviert hab. Ich hab das mal wieder aktiviert.
Ich habe das neue Modul parallel zum alten Modul eingerichtet.
Für die Einrichtung des Callback-Webhooks gibt es keinen Automatismus, oder? Zumindest wurde bei mir keiner angelegt.
Ich muss also den neuen Hook manuell erstellen, in der Bridge hinterlegen und auf die neue Instanz umleiten, oder? Alternativ könnte ich ja auch den bestehenden Hook nehmen, aber dann sind in der URL die falschen IDs enthalten, was mich glaube ich irgendwann verwirren würde.
Gruß
Slummi
EDIT: Habe gerade noch mal nachgesehen. Laut Doku sollte der Hook automatisch gesetzt werden. Ich vermute, dass das nicht klappt, wenn bereits ein Hook und Callback vom alten Modul existiert.
Hi Slummi,
wenn
wird der Callback automatisch angelegt.
Die Bridge kann auch mehrere Callbacks verwalten.
Mal den Schalter und IP-Adresse und Port überprüft. Das muss stimmig sein.
Uli
Habe ich aktiviert, funktioniert aber nicht. Es wird kein Callback / Hook eingerichtet.
Deshalb ja die Vermutung, dass er das nicht macht, weil schon ein Callback/Hook vorhanden ist. Evtl. prüfst du da zuvor zu allgemein?!
Hi,
welche Symcon Version, auf welchem System?
Poste bitte mal die Instanz-Konfiguration vom Splitter und die Ausgabe aus dem Entwickler-Bereich Callback anzeigen oder gerne per PN.
IP-Adressen darf du teilweise unkenntlich machen, wenn du willst.
Uli
Ich musste den Dienst gerade neu starten. Jetzt sind sie da, sowohl der Hook als auch der Callback.
Nach der Einrichtung der Instanz gab es nur den alten Hook und einen Callback (Index 0), jetzt sind es zwei.
Habe es mehrfach getestet, da ich mehrere Bridges / Locks verwende.
Willst du die Config trotzdem noch haben?
Nutze IPS 6.1 (aktuelle Stable) auf Windows Server.
Hi Slummi,
wenn es jetzt funktioniert ist doch gut.
Jede Bridge Instanz hat eine eindeutige Callback URL:
http://192.168.17.48:3777/hook/nuki/bridge/20773/
D.h. neben der IP-Adresse und Port ist am Ende noch die Instanz ID angefügt.
Dies überprüfe ich bei der Erstellung. Wenn es diese URL gibt, wird kein Callback angelegt, ansonsten wird einer erstellt. Jede neue Splitter Instanz bekommt ja von Symcon eine neue ID, sollte also passen.
Uli
Ja, mir ist schon klar, wie die Callbacks funktionieren. Deswegen habe ich ja auch sofort gesehen, dass die beim Erstellen der Instanzen und aktivieren der Statusabfrage nicht eingerichtet wurden.
Was ich nicht verstehe ist, warum er die Hooks/Callbacks erst nach dem Neustart des Dienstes eingerichtet hat. Kann es sein, dass es da einen Unterschied zwischen ApplyChanges() und Create() gibt?
Bei mir passt die Config jetzt. Aber vielleicht ist da ja noch irgendwo ein Bug drin.
Ich validiere zunächst die Konfiguration:
Es muss ein Token vorhanden sein, die Bridge IP-Adresse und Port.
Sind diese Werte vorhanden wird im ApplyChanges die Methode ManageCallback() aufgerufen.
Wenn du das nochmals nachstellen kannst mit Debug / Log Informationen schaue ich mir das gerne noch einmal an. In meiner Testumgebung (ich habe allerdings nur eine Bridge) konnte ich es nicht reproduzieren.
Uli
Alles klar. Ich werde das bei Gelegenheit noch mal testen und dir Feedback geben, wenn ich es erneut nachstellen kann.
Servus,
hab ein 3.0 mit Opener eben installiert aber mit dem Modul noch bissl Stress.
Allerdings meint die Bridge in der Nuki App sie würde einen FW Update machen die nächsten 2 Stunden. Das hat erst verhindert dass ich das Lock koppeln konnte.
Hab das aber nicht ganz kapiert und mich gewundert warum ich keine Updates im Modul bekam und warum er es nicht selbst fand.
Hatte schon eine längere Abhandlung hier drunter um das Problem zu beschreiben, aber offenbar war dann der FW Update durch und ein neuer Versuch konnte das Lock koppeln (in der App).
Nun ist es auch im Modul.
Die Installation des Moduls klappte sehr gut!
Respekt, so macht das Spass!
Werde noch testen, aber besser kanns grad nicht aussehen!
Danke für das tolle Modul @ubittner !
Cheers Seppm
Hi,
neue Beta online:
2.0-2
Verbesserung für HTTP Fehler 503
Magst du die mal ausprobieren. Sollte jetzt schon Verbesserungen mitbringen. Generell sollte man aber jeden Schaltbefehl abwarten, bis der nächste Schalt-/ Abfragebefehl durchgeführt wird.
Beim Lock ‚n‘ Go könnte es noch auftreten, da der Vorgang ja länger dauert als gewöhnlich. Eventuell muss ich das noch umbauen, dass ich nicht auf die Antwort warte…
Uli
Beim ersten Befehl nach dem Update und ohne einen Befehl vorher zu schicken, kam der selbe Fehler. Ob es der 503er war, weiß ich leider nicht, da ich den Debug nicht offen hatte. Ich wartete dann ein paar Sekunden und schickte ihn noch einmal. Dann hat es funktioniert. War ein Zusperren. Nach einer kurzen Wartezeit kam der Aufsperren Befehl. Das hat dann alles funktioniert. Was mir auch aufgefallen ist, dass sich die Variable für den Vorgang wieder zurückgeändert hat. War vorher auf den Wert „Aufsperren“. Ich hab auf „Zusperren“ geklickt. Dann kam der Fehler. Die Variable sprang dann von „Zusperren“ auf „Aufsperren“. Alles weitere hat wie erwartet funktioniert.
Ich habe es jetzt so umgebaut,
wenn Status automatisch aktualisieren aktiv ist, dann wird zunächst der Wert der Variable gesetzt und wenn der WebHook eingeht, dann wird nur geprüft ob es einen Unterschied gibt, wenn ja, wird die Variable aktualisiert.
Wenn jetzt mal ein Schaltbefehl fehlschlagen sollte, dann wird der gesetze Wert wieder auf den ursprüngliche Wert zurückgesetzt.
Leider kann ich die Befehle nicht puffern, bzw. man sagt glaube ich „serialized“, da ich dann keine Zuordnung habe, welche Rückmeldung zu welchem Befehl gehört…
So ganz glücklich bin ich noch nicht, aber vielleicht testen wir erstmal ein paar Tage.
Welche Anwendungsfälle hast du denn ausserhalb vom WebFront (Skripte)?
Schönen Abend
Uli
Für mich passt das so im Grunde. Ist für mich jetzt kein Beinbruch, wenns mal fehlschlägt, aber ich kann es aus deiner Sicht verstehen, dass es funktionieren sollte.
Ich habe sonst nichts in Skripten in Verwendung. Ich zeige lediglich im WF die Variablen an und es gibt die Möglichkeit die verschiedenen Zustände zu schalten. Und ich hab es noch mit dem Alexa Modul von IPSymcon verbunden um das Schloss per Sprachbefehl zu schalten.
Dann schlage ich vor, wir probieren das jetzt mal aus 
Uli
1 „Gefällt mir“