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.
meine Shellys laufen gemischt (einige wenige haben feste IP, die meisten per DHCP)..
Da die Fritzbox den Clients eh immer die gleiche IP gibt spielt das eigentlich keine Rolle.
Lediglich die batterie-betriebenen Geräte sollte man (muss man aber nicht) mit fester IP ausstatten, weil der DHCP-Request ein paar Millisekunden Zeit (und damit minimale Baterie-Leistung) kostet.
Probier es mal mit einem Reset des Shelly und dann einfach bei der IP-Adress-Vergabe DHCP zu lassen, das funktioniert eigentlich reibungslos ..
Im Zweifelsfall kannst du anschließend in der FritzBox unter System - Ereignisse WLAN sehen, warum die Verbindung nicht klappt..
192.168.178.201
die 201 (und folgende) am Ende ist ein Sonderfall (und nirgends seitens AVM dokumentiert!!), die vergibt die FritzBox nämlich eigentlich an VPN-Teilnehmer (wenn man die Funktion nutzt) 
Daher die Empfehlung:
wenn außerhalb vom DHCP-Scope Adressen genutzt werden sollen .. ab ...178.210 ist das unproblematisch.
führe solche Tests im Hyper-V Container durch.
das wird mit ziemlicher Sicherheit das Problem sein, da der Listener die Host-Netzwerk-Karte nutzen muss.. Innerhalb eines Containers wird das vermutlich in eine Art Bridge-Modus wie bei Docker-Containern laufen.
Da werden die Multicast-Nachrichten nicht bis zum virtuellen Netzwerk-Adapter durchkommen..
Den shelly HT, bekomme ich gar nicht mehr aus dem Access Mode heraus
mit dem Knopf aufwecken, dann mit dem AP-Modus verbinden und dort deine WLAN-Zugangsdaten (SSID und zugehöriges Kennwort) eintragen und abspeichern.
Anschließend in der FritzBox unter System - Ereignisse - WLAN
Da sollte man dann sehen können, warum es ggf. nicht klappt.
harrym kannst du da ggf. etwas zu sagen?
192.168.78.110
exakt das ist das Problem, das ist ein anderes Subnetz und damit von keinem Client erreichbar. Statt 78 wird es 178 sein müssen, zumindes wenn deine Subnetz-Maske 255.255.255.0 ist (Standardeinstellung in der FritzBox).
Besser ist es Shellys einfach mit DHCP zu betreiben, dann kriegen die vom Router nämlich alle Daten korrekt übergeben.
1) das geht nur, wenn der Shelly Zugriff zum Internet (HTTP und NTP) hat. bist du ganz sicher, dass der Shelly das darf?
2) das Topic lässt sich nicht exakt so anpassen, wie du das gerne hättest.. was aber geht
dann kommen alle Nachrichten über folgendes Topic an:
shellies/keller/einShelly..
der vordere Teil ist fest verdrahtet und lässt sich nicht anpassen.
die allererste Meldung "CoIoT Listener started" siehst du aber noch?
kam denn eine Meldung, dass der Listener einen Port in der Firewall öffnen will?
Ist dein Rechner ggf. nicht im gleichen VLAN / WLAN wie die Shellys und der ioBroker?
Ich hab das gerade mal an einem alten Windows Notebook meiner Tochter (Windows10 32bit) getestet. Da 32bit musste ich die EXE neu kompilieren aber das sollte eigentlich keine Rolle spielen.
Da hab ich die Eingabeaufforderung (mit Rechtsklick "als Administrator") gestartet, dann das Programm ausgeführt und dann kam die Windows-Firewall-Meldung, die man bestätigen muss..
Dann hat sich Avira Antivir gemeldet und den Zugriff verweigert. Hab die Datei dann aus der Quarantäne genommen und im Avira den Zugriff explizit erlaubt.
(Info: Es ist definitv kein Virus, ich kann den Quelltext später zum Nachlesen gerne auf Github hochladen.)
Danach hat es dann funtioniert..
so, damit du das selber testen kannst hab ich mal auf die Schnelle einen input-Listener (Widows 64bit executable) gebaut..
http://archive.shelly-faq.de/input-listener.zip
Falls Bedarf besteht kann ich die auch gerne für Linux, MAC oder den Raspberry kompilieren..
einfach direkt in der Windows-Konsole ausführen mit
input-listener.exe -ip 192.168.178.147 IP bitte durch die IP deines I3 tauschen.
Ich kann die Binary unter Windows nicht testen (hab keinen Windows PC), es kann aber sein, daß sie administrative Rechte braucht bzw. meckert wegen der Firewall-Einstellungen.
Die macht einen Coap-Listener auf der Adresse 224.0.1.187:5683 auf, genau wie der ioBroker das auch macht.
Nach dem Start solltest du folgende Meldungen sehen können:
CoIoT Listener started
neues Event am Taster1: S
neues Event am Taster1: SSSS ist Shortpress,
L ist Longpress
SSS dreifach ShortPress.
LS LongShort
SL Short, Long
SS doppel-Short
Da mach ich exakt das, was der Hersteller sich dabei gedacht hat.
InputEventCnt auswerten und InputEvent ausgeben.
Getestet hab ich es nur mit dem ersten Input, hoffe die anderen funktionieren auch (Copy&Paste mit Anpassungen)
Vielleicht glaubst du mir ja dann doch, das ich damit richtig liege
Ist seitens Shelly eigentlich nicht irgendeine Planung in der Pipeline die i3's mit http-Befehle ansteuern zu können?
nein, aber welchen Sinn sollte das machen? der I3 hat ja keine Outputs (Relais, Light) sondern nur Inputs..
das Repetier-Server image wird irgendein Ubuntu / Debian basiertes System sein, sonst gäbe es solche Shell-Kommandos wie
sudo service RepetierServer stop
nicht Kann also gut sein, dass es läuft ..
Beim ActionRouter muss zum verzögerten Anschalten lediglich ein Sleep vor den eigentlichen HTTP-Befehl gesetzt werden (10000 entspricht 10 Sekunden)
Oder sowas wie bevorzugte MAC Adressen wenn ein Repeater mal nen Neustart benötigt.
Das würde indirekt ein Roaming bedeuten, sprich wenn der alte AP wieder da ist soll der Shelly vom schlechteren AP zum besseren zurückkehren?
Genau das geht aber nicht, weil der ESP8266 (die MCU in den Shellys) meines Wissens nach kein Roaming nach 802.11 k/v/r unterstützt.
Falls du einen PC / Raspberry hast der immer an ist, hätte ich ein kleines selbstgeschriebenes Programm, was das ebenfalls kann
Damit bekommt man doch mehr ein Live System in der Oberfläche da Homeassistant die Anzeige nach gewisser Zeit als Unbekannt darstellt was unschön ist.
ja, das lässt sich steuern ..
Dazu müsste über die REST-API der Wert für mqtt_update_period (bei MQTT) bzw. coiot_update_period (bei CoAp)u angepasst werden.
Ich würde aber wegen der Batterieleistung dringend davon abraten..
Zu dem CoAp-Problem: das wird einer der Repeater sein (vermutich einer, der nur über WLAN arbeitet).. eventuell kannst du ja in der MESH-Übersicht der Fritzbox sehen, an welchem Repeater die Shellys hängen, von denen keine Updates mehr ankommen..
Sprich du baust dir selber eine Lösung, ja?
Exakt Die passende coap (CoIoT) Library hab ich unter OpenSource-Lizenz auf Github veröffentlicht:
Hast du dir das im ioBroker auch ansehen können? Womit wertest du die CoAP Ereignisse aus? Das sind ja glaube ich Broadcasts, korrekt?
Ich werte sie mit einer selbgeschriebenen Library unter Go direkt in der Linux-Konsole aus, allerdings nur zu Debug-Zwecken..
Nein, ich hab mir das im ioBroker nicht angesehen, weil ich aktuell keinen mehr habe (hab die VM vor drei Tagen in die Tonne gehauen, weil ich es für meine Zwecke unnütz empfinde.)
und nein, es sind keine Broadcasts, es sind Multicast-Nachrichten, die gezielt an die Multicast-Adresse 224.0.1.187 auf Port 5683 gesendet werden.
Ich denke nicht, dass man einen Event-Count als Trigger verwenden sollte. Falls doch, frage ich mich, wieso bei einem leicht längeren Tastendruck (und ich meine nicht den longpress) dann das Input-Event kommt und bei einem sehr kurzen Druck nicht?
doch, genau so ist es gedacht.. exakt am InputEventCnt kannst du festmachen, ob ein Input Ereignis erfolgt ist oder es z.B. ein einfaches Coap-Status-Update war..
Beim Tastendruck werden zwei Coap-Nachrichten geschickt, die erste wird vom internen Sensor am Taster ausgelöst, die zweite ist das Ereignis, also der Tastendruck. Dadurch dass 2103 von 7 auf 8 gesprungen ist kann ich mit Sicherheit sagen, dass der Taster gedrückt wurde und zwar mit dem Wert von 2102, also Shortpress.
Event:
,"192.168.178.147:5683","SHIX3-1","A4CF12F46CAF","14940","{"G":[[0,9103,3],[0,2101,0],[0,2102,"S"],[0,2103,7],[0,2201,0],[0,2202,""],[0,2203,0],[0,2301,1],[0,2302,"S"],[0,2303,5]]}"
Event:
,"192.168.178.147:5683","SHIX3-1","A4CF12F46CAF","14941","{"G":[[0,9103,3],[0,2101,0],[0,2102,"S"],[0,2103,8],[0,2201,0],[0,2202,""],[0,2203,0],[0,2301,1],[0,2302,"S"],[0,2303,5]]}"mach ich das gleiche mit einem Longpress kommen wieder zwei Coap-Nachrichten, die erste vom Sensor mit dem alten Zustand (da steht der Counter noch auf 8 und und der Wert noch auf S, die zweite Nachricht hat den Counter auf 9 hochgezogen und das Event auf L gestellt, also Longpress.
Der Wert 2101 (Input State) wird zwar geändert, hat aber für Taster keine Aussagekraft, denn daraus kann ich nicht ableiten, ob Longpress, Shortpress oder DoublePress getätigt wurden. Der hat ausschließlich den Sinn, den Zustand eines Schalters zu emulieren. Du benutzt aber keinen Schalter sondern einen Taster.
Event:
,"192.168.178.147:5683","SHIX3-1","A4CF12F46CAF","14942","{"G":[[0,9103,3],[0,2101,1],[0,2102,"S"],[0,2103,8],[0,2201,0],[0,2202,""],[0,2203,0],[0,2301,1],[0,2302,"S"],[0,2303,5]]}"
Event:
,"192.168.178.147:5683","SHIX3-1","A4CF12F46CAF","14943","{"G":[[0,9103,3],[0,2101,1],[0,2102,"L"],[0,2103,9],[0,2201,0],[0,2202,""],[0,2203,0],[0,2301,1],[0,2302,"S"],[0,2303,5]]}"Wie das in ioBrker nun ausgewertet wird /werden muss , kann ich nicht beantworten. Da müsste jemand mit ioBroker-Kenntnissen etwas zu sagen.
Wie verhält sich denn der Shelly jetzt, wenn er über Shelly-App, das Webinterface oder den Schalter geschaltet wird? ist da das Verhalten korrekt?
Zu ioBroker kann ich leider fast nichts sagen, da müsstest du ggf. im entsprechenden Unterforum nachfragen..
ich versuch es nochmal anders, eventuell wird es dann verständlicher, stellvertretend für den ersten Eingang.
die Coap-Nachrichten vom I3 enthalten 3 relevante Dinge:
2101: Input -> der kennt true oder false
2102: InputEvent - Werte sind S/L/SS/SSS/SL/LS
2103: inputEventCnt -> Counter, der wird bei jedem "Schaltvorgang" hochgezäht
Bei Schaltern kannst du auf 2101 gucken, da gibt es true für Strom an und false für Strom aus zurück.
Bei Tastern guckst du stattdessen auf 2102 und 2103.
Wird 2103, also der inputEventCnt einen hoch gezählt gab es ein neues Event. Welches kannst du dann im Feld InputEvent sehen..
2101 (Input) ist dann irrelevant, der wird für Schalter (und nur dann) benötigt.
Denn der Event-Count zählt eins hoch. Nur das Input-Event kommt halt nicht an bei diesem sehr kurzen Tastendruck.
na dann ist doch alles gut, was steht denn dann bei Input-Event drin? vermutlich ein S für short press, oder?