VPN/Proxy erkannt
Es scheint, dass Sie einen VPN- oder Proxy-Dienst verwenden. Bitte beachten Sie, dass die Nutzung eines solchen Dienstes die Funktionalität dieser Webseite einschränken kann.
Das hier in ioBroker nicht die Events Input: true direkt gefolgt von einem Input: false ankommt ist meiner Meinung nach ein Bug.
oder es ist einfach eine Statusnachricht und dein tastendruck ist so kurz, dass überhaupt kein Strom am I3 ankommt 
Wie gesagt, bei jedem Tastendruck wird der inputEventCnt einen hoch gezählt, passiert das nicht gab es kein Event..
Soweit mir bekannt werden die Jarolift-Motoren von Rademacher produziert.
Und rein logisch würde es ja passen, wenn der Motor zwischen dem vorletzen und letzten Schritt eine kleine Pause machen will und der Shelly damit nicht zurecht kommt..
Ich warte mal, was die Entwickler dazu sagen..
bei Schaltern ist es völlig normal, dass der Shelly auf dem SW-Eingang längere Zeit Spannung hat, und zwar immer dann wenn der Schalter auf "an" steht.
Wenn du aber zwei Lampen parallel am Shelly1 anschließt, dann kannst du sie auch nur gleichzeitig ein- und ausschalten, nicht aber voneinander getrennt.
Der Shelly1 hat ein Relais, du bräuchtest aber zwei Relais weil du zwei Lampen unterschiedlich steuern willst.. Das ginge z.B. mit einem Shelly 2.5.
Ist denn Shelly selbst nicht auch für die ioBroker Implementation der Ansprechpartner?
nein, natürlich kann Allterco nicht diverse Heimatomatisierungs-Systeme mit Code versorgen, sonst müssten sie ja sämlichte Programmiersprachen beherrschen.. Javascript für ioBroker, Java für OpenHAB, Python für HomeAssistant, Perl für FHEM...
Der Longpress ist leider auch immer noch defekt: Löst man das zweite mal einen Longpress aus, wechselt der Wert nie auf "false" zurück, weshalb man den zweiten Longpress nicht über den Longpress-Trigger erkennen kann.
ob der input auf True oder False steht ist bei den Coap-Nachrichten speziell beim I3 komplett egal,
Interessant sind die Werte für 2102, 2202 und 2302 für das InputEvent auf den 3 Inputs S/L/SS/SSS/SL/LS
S steht für Short, L für Long, SS für Short Short usw.
zweiter wichtiger Wert ist der inputEventCnt (Counter), 2103, 2203 und 2303,
Wenn sich da einer der drei Counter um 1 erhöht, gab es ein Event für den jeweiligen Taster. Welches Event es genau ist, steht im InputEvent (s,l, ss, sss...)
Wenn die 3 inputEventCnt sich NICHT verändern, handelt es sich lediglich um CoAp-Status-Nachrichten, die werden generell alle 15 Sekunden geschickt.
ich kenne die ioBoker-Implementierung nicht, kann also dazu nicht viel sagen:
mein I3 schickt bei jedem Tastendruck, auch wenn er noch so kurz ist eine Coap-Nachricht und zählt dabei den 2103 (inputEventCnt vom ersten Taster) um 1 nach oben.
Payload vor dem Tastendruck:
{"G":[[0,9103,0],[0,2101,0],[0,2102,"S"],[0,2103,1],[0,2201,0],[0,2202,""],[0,2203,0],[0,2301,1],[0,2302,"S"],[0,2303,5]]}
Payload nach dem (sehr kurzen) Tastendruck:
{"G":[[0,9103,0],[0,2101,0],[0,2102,"S"],[0,2103,2],[0,2201,0],[0,2202,""],[0,2203,0],[0,2301,1],[0,2302,"S"],[0,2303,5]]}
das sieht für mich von Shelly-Seite erstmal vollkommen korrekt aus, denn daraus lässt sich ableiten, dass der erste Taster betätigt wurde (Counter um 1 erhöht) und auch welches Event ausgelöst wurde (2102, S steht für single press)
kontrolliere bitte mal die Logs der Fritzbox, eventuell steht da ja etwas brauchbares drin..
SSID und zugehöriges Passwort sind ganz sicher korrekt?
hast du das Hinzufügen via App (Android? IOS?) oder via PC erledigt?
Wenn du es vorher schon erfolgreich geschafft hast und keine Änderungen in der FritzBox (den Repeatern?) vorgenommen wurden sollte es eigentlich immer noch klappen...
Anlegen funktioniert über CoAp-Discovery, alles weitere dann über Coap-Status-Updates. da gibt es kleine Unterschiede.
wie sind Fritzbox und repeater verbunden? Alle über LAN oder alle über WLAN oder oder DLAN/Powerline oder gemischt?
Eventuell funktionieren die Status-Updates ja nur an bestimmten Repeatern nicht?
Mein Motor (es ist ein Rademacher) benötigt nach dem Schalten 1-2 Sekunden, bis das Rolle wirklich fährt. I
Guter Hinweis, hab mal eine Anfrage bei den Entwicklern eingereicht, ob es da ggf. ein Timeout gibt..
Die Shellys schicken ihre Zustände via CoAp (UDP) an eine Mutlicast-Adresse. Auf dieser Adresse "lauscht" der HomeAssistant.
Wenn da nun von einigen deiner Shellys keine Daten ankommen wird irgendeine deiner Netzwerk-Komponenten (Router, AccessPoint, Repeater, Switch..) die Coap-Nachrichten blockieren..
Was hast du denn für Netzwerk-Komponenten im Einsatz?
VC -> Phase 3 (vor FI, da der Sicherungsautomat dort noch frei war)
Neutral -> Neutral (hinter FI).
bin zwar keine gelernte Elektrofachkraft aber das hier wird nicht funktionieren und den FI zum Auslösen bringen
gibt ein paar Unterschiede, zumindest diese hier fallen mir direkt ein:
- der H&T wird von Alexa und Google Home als Sensor erkannt, man kann also via Sprache die Temperatur abfragen. Das geht mit dem Shelly1 und TempAddon nicht.
- der H&T ist meist im Deepsleep (Batterie) und kann deshalb nicht per REST-API direkt abgefragt werden.
- Beim Shelly1 muss der Sensor mit ensprechend Abstand zum Shelly montiert werden, wegen der Eigenhitze vom Shelly würde es sonst zu Verfälschungen kommen.
- Der H&T ist in seiner Optik wohnzimmer-tauglich
- Der H&T ist portabel und kann z.B. auch problemlos im Külschrank plaziert werden.
tbc..
Eigentlich baut er fast gar keine auf ..
Alle 3 sind optional, also nicht zwingend erforderlich wenn man z.B. ohne Cloud arbeitet.
- http (Port 80) Richtung Cloud zum Dowload der Firmware
- NTP (Port 123) zur Zeitsynchronisation, wenn kein lokaler NTP-Server genutzt wird.
- TCP von intern Port 57206 auf Destination Port 6021 (Shelly zu Cloud -> TLS 1.2 verschlüsselt)
keine Uhrzeit oben bedeutet keinen Internet-Zugang. sicher, dass dein Gateway richtig ist? (IP vom Router)
Hast du mal probiert einen zu resetten und ihm anschließend eine andere IP zu verpassen?
Ich hatte das Verhalten vor Monaten mal mit dem 2.5er (unter Firmware 1.6.x oder 1.7.x, genau kann ich das nicht sagen) und da hatte das mit dem Reset und der anderen IP Abhilfe geschafft.
Ausstecken und näher am Router hast du auch probiert?
Oben rechts im Webinterface zeigt er dir die Uhrzeit an?
(bis auf die statische IP, hier 216, welche natürlich disjunkt sind).
ganz sicher kein Tippfehler oder falsche Adresse beim Gateway?
bitte probeweise auf DHCP umstellen und nochmals probieren..
Klemm mal zum Testen den Draht zur Lampe ab und guck was passiert..
im zweiten Schritt die Lampe anklemmen und dafür den Schalter / Taster abklemmen, auch da gucken was passiert..
So lässt sich zumindest die Ursache etwas eingrenzen.
Kalibriert hast du ihn vermutlich noch nicht, oder?
probier bitte mal http://192.168.178.216/ota?url=http://archive.shelly-faq.de/version/v1.9.2/SHPLG-S.zip
Wenn das nicht klappt, dann hat dein ShellyPlug möglicherweise das Problem, das er keine Internet-Berechtigung hat? (gateway falsch konfiguriert?)
