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.
Und irgendwann ist er dann wieder offline...
wenn du Feste IP vergeben hast? was hast du als Gateway eingetragen? die IP vom Router oder von einem AccessPoint/Repeater?
ggf. einfach wieder auf DHCP umstellen, dann passen die Einstellungen mit ziemlicher Sicherheit.
lässt sich schwer sagen, aber ich kenne verschiedene Netzwerk-Komponenten, die Coap-Nachrichten ggf. mal unterdrücken oder filtern..
du kannst ja probeweise den einen Shelly mal mittels MQTT überwachen, das basiert auf TCP und wird mit großer Wahrscheinlichkeit nicht gefiltert.
würde ich von abraten, da der Hersteller die Messwandler einzeln auf das Gerät kalibriert hat, das geht dabei mit ziemlicher Sicherheit verloren..
Nur in der App (auf mehreren Geräten!) bekomme ich Cloud disabled. Ab und zu zeigt er auch mal den korrekten Status an, aber in 95 % habe ich leider "Cloud disabled".
dann schalte die Cloud über das Webinterfache des Shelly aus und schalte sie, sobald er in der App sichtbar ist, dort an.. vermutlich fehlt die "Verknüpfung" zwischen dem Shelly und deinem Cloud-Konto..
Rein über das Webinterface lässt sich das nicht korrigieren, weil da ja kein Cloud-Konto eingetragen werden kann.
Wenn ich den Shelly HT im Bad stehen habe kann ich dann Alexa fragen wie die Werte sind?
Temperatur ja, Luftfeuchtigkeit nicht (Alexa kennt keine Luftfeuchtigkeit)
Ich stelle mir die Frage, wie zuverlässig ist der Shelly 1PM.
diesbezüglich ist der Shelly1PM eigentlich zuverlässig, die Frage ist: ist es dein Netzwerk auch?
wie kriegt ioBroker die Daten vom Shelly? über MQTT oder Coap?
Coap-Nachrichten werden üblicherweise als NonConfirmable an die Multicast-Adresse 224.0.1.187 auf Port 5683 geschickt..
soll heissen: der Shelly schickt Daten nach dem Prinzip "Fire and forget" und kümmert sich im weiteren Verlauf nicht darum, ob jemand die Daten mitliest oder verarbeitet.
Im Log from ioBrkoker finden sich keinerlei Hinweise?
Es sieht für mich so aus, als wenn beim Schaltvorgang soviel "CPU" Leistung benötigt wird, dass für den Netzwerkstack für einige Sekunden nicht mehr da ist und daher Pakete nicht ankommen.
passiert das auch, wenn du den Shelly statt über MQTT über den Schalter oder die App an/ausschaltest? ich hatte das im Screenshot oben mit dem Schalter getestet
Leichte Laufzeit-Schwankungen beim Schalten gibt es in der Tat, das ist aber eigentlich unproblematisch.
Folgende Dinge könnte ich mir als mögliche Gründe vorstellen (Vermutung):
1) der ESP ist Single-Threaded, kann also immer nur eine Sache gleichzeitig.. beim Schalten antwortet er deshalb verzögert auf den Ping
2) Durch das Zuschalten der Spannung am Relais gibt es kurzzeitige WLAN-Interferrenzen
Bei mir sieht das während eines Schaltvorgangs (Shelly1) so aus:
die beiden Zeiten über 100ms waren die Schaltvorhänge.
beim Shelly1Pm liegen die Zeiten während der Schaltvorgänge sogar noch etwas höher (>200ms), das liegt vermutlich an der zusätzlichen Stromverbrauchsmessung.
Paketverluste konnte ich bisher nicht feststellen, das kommt aber sicherlich auch noch darauf an wie gut oder schlecht die initiale WLAN-Verbindung ist..
Coap und MQTT tun sich funktionell nicht wirklich was.. Zustände von Inputs & Outputs, Stromverbrauch etc. kannst du sowohl über MQTT als auch Coap sehen..
Einziger gravierender Unterschied:
- Coap + Shelly Cloud geht gemeinsam.
- MQTT und Cloud gleichzeitig geht (noch) nicht.
Bei meiner Synology hat das Anlegen des MACVLAN für Docker keine 5 Minuten gedauert..
Subnetz berechnen, zwei Shell-Kommandos abschicken und es läuft..
http://www.stueben.de/mehrere-vlans-…f-der-synology/
Den Aufwand beim MicroK8s mit ContainerD kann ich aber absolut nicht einschätzen, Den MQTT nach außen hin sichtbar zu machen sollte aber mit einem Deployment im K8s minimaler Aufwand sein, der "externe" Port ist ja (da TCP-basiert und frei definierbar) eher nebensächlich..
Das Feld ist neu und wurde für die HomeAssistant-Integration eingebaut.. Ist ein frei definierbares Text-Feld mit 30 Zeichen Länge..
Worauf nicht gewartet werden muss ist der Doppeldruck, da es den per Action nicht gibt.
Hab das mal als Feature-Request im QA-Bereich eingereicht (Doppel-Push Optional statt fest im Gerät verankert).. Das würde die Verzögerung auf jeden Fall um einige Millisekunden verkürzen..
mhh, bei meinen Shellys (egal ob 1, 1PM, Dimmer...) ist es überall nur schwach grau und verschwindet, wenn ich in das Feld klicke (sind einfache HTML Placeholder).. da muss die URL vollständig eingetragen werden.
Vergleiche mit dem Browser sind schwierig, der ist "clever" und löscht so Dinge wie Leerzeichen am Anfang oder Ende, speichert Zugangsdaten im Cache und sowas..
Mit welchen Schalter / Taster, Gira, funktioniert das???
du suchst einen Rolladen-Taster mit Neutralstellung? Gira hat sowas meines Wissens nicht im Programm, Alternative:
In der Shelly App werden beide Shellys als Offline angezeigt. Liegt das an der Homekit Software?
ja, die App funktioniert nur mit der nativen Shelly-Firmware, nicht aber mit Homekit..
Shift+F5 löscht den Browser-Cache unter Windows..
das hier ist von einem meiner 1PM, da gibt es den Punkt.
hab das grad mal mit einem Dimmer1 getestet, Dimmer2 hab ich gerade nicht griffbereit:
1) Button Debounce auf 60
2) TransitionTime 0
3) Warm-Up auf 100% und 1000ms..
Der Dimmer ist quasi unmittelbar nach dem Loslassen auf 100% Licht, eine minimale Verzögerung ist noch da (paar Millisekunden würde ich meinen) aber die wird man nicht wegkriegen..
Was hat der 1PM für ein Problem in der Richtung?
eigentlich keines.. ich mache exakt das gleiche mit einem 1PM in der Küche, Ziel ist bei mir ein alter 4Pro aber das sollte keinen Unterschied machen.
Eventuell beim Eintragen der URL irgenwo ein Leerzeichen (z.B. am Ende) reingerutscht?
@Olsche ja, für den LongPush ist es so, wie du es beschreibst aber für den Shortpush (der ja hier der Kritikpunkt ist) lässt es sich (aus den o.g. Gründen) nicht ändern..
Solche unschönen Neben-Effekte meine ich mit "Frust" ..
Browser heisst HTTP, das ist ein TCP-basiertes Protokoll und funktioniert deshalb, weil du den Shelly explizit ansprichst..
Die App arbeitet mit mDNS/CoAp (das sind beides UDP-basierte Protokolle) und wartet auf Multiicast-Pakete . Die kommen da aber nicht an..
Mit dem Zitat tu ich mich echt schwer, denn wenn ich im Browser(nicht die App) das Licht ein oder ausschalte, dann passiert dies ohne Verzögerung!
Im Browser gibt es deswegen keine Verzögerung, weil der Shelly da nicht erst warten muss, ob es ggf. ein Longpress war..
Grundsätzlich kann der Shelly über den Taster ja erst nach dem "Loslassen" entscheiden, um welche Art Tastendruck es sich gehandelt hat (also Short oder eben Longpress)..
