21 Minuten online. Ich wundere mich.
Ich bin eigentlich kein Freund von DHCP. Bei einem Routerausfall / Tausch wirst Du wahnsinnig, weil alle Geräte neue IPs bekommen.
Zumindest die Grundstruktur wie Switche / Router selber etc. ist imho mit fixen IPs besser ausgestattet.
Ich schau mit mal die core.devics_registry an. Es gab da schon mal ein Problem mit den Shellys. Da wurde die Aufwachzeit der Fenstersensoren nur einmalig gesetzt...
mit DHCP ist er jetzt schon 4 Minuten online - sollte das die Lösung sein?
und vor allem warum?
Die verwendeten festen IPs sind auf jeden Fall frei, ich hab da eine umfangreiche Exceltabelle. Es war allerdings schon mal ein anderes Gerät mit dieser IP im Netz und in HA.
Device ID: 3494547B7F47 (57811677183815)
WiFi connected to SSID: Cassiopeia
WiFi RSSI: -57 dBm
def. mehr als 6 
HA 2023.6.2
DHCP ist noch einen Versuch wert. Wobei ich ungern die Kontrolle über die IPs abgebe
Ja, multicast geht auch nicht.
Aktuell hab ich die beiden über MQTT eingebunden - schöner wäre aber eine Integration für alle Shellies.
Die von HA mitgelieferte Integration.
Guten Morgen zusammen,
ich habe Probleme mit zwei Shelly 1, die ich partout nicht in HA eingebunden bekomme.
Es handelt sich dabei um den 48. und 49. Shelly - eigentlich weiß ich was ich tue.
Eingebunden sind Sie alle über CoIoT unicast (port 5683) - feste IP, Gateway, Maske, alles tip top.
Die Weboberfläche der Shellys selber ist problemlos erreichtbar, dbm -67 also super.
HA findet die beiden jeweils auch, wirf die aber nahezu sofort als nicht verfügbar wieder raus.
Da ich die beiden als letztes gekauft habe - können die beide defekt sein?
Alles übliche hat übrigens nicht geholfen (Reboot von Router, Shelly, HA, Rücksetzen auf Werk, Firmware erneut flashen…)
Kennt jemand ein solches Problem und kann mir helfen?
Habe bei mir das gleiche Problem.
Ich wollte mit Hilfe des Shelly DW meine Shelly GU10 Bulb beim betreten des Hauses einschalten.
Leider bei mir auch erst nach 5-7 Sekunden.... Bis dahin bin ich im dunkeln schon über alle Schuhe gestolpert.
Auch die Vergabe einer festen IP bringt bei mir keine Besserung.
Bulb und DW sind übrigens in unmittelbarer Nähe zum Router.
Hast du mittlerweile eine Lösung?
Ich habe die Reaktionszeiten nie mit der Stoppuhr gemessen, aber in der Tat dauert es etwas, bis die Statiänderungen registriert und angezeigt werden. Bei mir 3 Sekunden würde ich sagen.
Als Fensterkontakt für Heizungsabschaltung / Alarmsensoren natürlich vollkommen ausreichend.
Bei dem Einsatz ist ein PIR-Sensor evtl. besser geeignet und def. schneller. Je nach Einsatzort käme zur Not auch ein kabelgebundener Microschalter in Betracht.
Hier der Abschlussbericht:
Seit der Änderung der Sleep-period in der core_config von HA von 6 Stunden (21.600) auf 12 Stunden habe ich keinerlei unavailable-Stati mehr in Home Assistant.
Der Floorplan gefällt mir viel besser
Der Wert der Shelly-Sensoren wird tatsächlich einmalig bei Einrichtung übernommen und danach nicht mehr verändert.
Wenn man jetzt, wie ich, den Wert in den Shellys manuell hochsetzt um den Batterieverbrauch zu senken sollte man das tunlichst auch im HA machen. Weil ansonsten nämlich genau das von Devil beschriebene Verhalten auftritt.
"Shelly sagt nach 12 Stunden "hallo hier bin ich", HA sagt aber schon nach 6 Stunden: "nix? - also offline".
Danke Devil für die Hilfe.
Grüße, digi
HA startet nach core-Änderung soeben neu.
Ich werde berichten...
Ja, da bin ich bei Dir. Ich habe soeben folgendes gefunden:
meine DW2 gehen aller 6h sinnlos online um zu sagen ich bin noch da..
laut Shelly API kann man:
Shelly Door/Window accepts the following extra parameters on it's /settings endpoint:
sleep_mode_period number Periodic update period in hours, 1..24
den Wert ändern bzw einstellen, leider kein Beispiel wie das gehen soll.
Kann mir jemand sagen wie der HTTP Befehl dafür aussieht ?
Danke
Das ist also im Shelly.
Ich setze mal testweise die Werte vom Gäste-WC-Fenster in der core-config von HA hoch und schaue was passiert. Das hat so gut wie nie eine Statusänderung und ist deswegen fast immer grau.
Ich hatte mal eine URL für die Shellys um die Sleeptime zu ändern (bestimmt hier aus dem Forum) Das sollte er dann an HA durchleiten vermute ich. Oder das ist einmalig bei Einbindung.
Und Du bist sicher, dass Sleeptime die Zeit bis OFFLINE ist? Dann ist erhöhen auf jeden Fall besser
[...] Wenn du natürlich nur den Window State überwachst wird es hier natürlich schwierig einen passenden Wert zu finden man möchte ja auch wissen wenn dann mal einer wirklich nichts mehr sendet.
Ich überwache so gut wie alle Werte (inkl. Batterie) das sollte passen. Ich werde die Sleep-Time mal etwas runter setzen. Vielleicht hilft das neben erhöhtem Batterieverbrauch auch die Anzeige zu Stabilisieren.
Oh, war die Falsche. Du meintest sicherlich die "core.config_entries"
Da findet sich sowas:
"entry_id": "a665bc64711e06d99b4ee089d12ef980",
"version": 1,
"domain": "shelly",
"title": "Fenster Gäste-WC",
"data": {
"host": "192.168.2.206",
"sleep_period": 21600,
"model": "SHDW-2"
Aber müsste ich das dann nicht verringern anstatt erhöhen? Scheinen jetzt ja 6 Stunden zu sein.
Du kannst natürlich in der .storage config die sleepperiode erhöhen ist glaube Standardmässig auf 12 Stunden. Da ich Temperatur Lux und mittlerweile Vibration noch aktiv habe wachen diese natürlich doch das ein oder andere mal mehr auf
In meiner steht so gut wie nix drin:
{
"data": {
"version": "0.2.0-b6"
},
"key": "shelly/36785[..........]09ba03/config",
"version": "1"
}
Nutzt du die Integrierte oder Shelly for Hass integration meine sind irgendwie nie unavailable
Ich benutze die interne Integration von HA und habe alles abgestellt was zusätzliche Aufweckzyklen verursacht. (Helligkeit, Temperatur) Vibration ist an.
Eingebunden sind die über ColoT unicast.
Und leider wird der Zustand eben nicht immer zuverlässig angezeigt.
Aktuell sieht z.B. der Floorplan im EG so aus:
Die drei grauen sind unavailable.
Beispiel:
Ich habe den Fensterstatus als template-Sensor angelegt und das "unavailable" als "unklar" geklariert daher die Anzeige.
Hallo zusammen,
Ich habe diverse DW2s in meinem Smart-Home mittels unicast eingebunden.
Laufen tut alles prima - leider verlieren einige regelmäßig die Verbindung und werden dann als unavailable angezeigt. Ist aber nur ein optisches Problem, da bei jeder Statusänderung die Sensoren wieder korrekt angezeigt werden bzw. Sie auch von alleine wiederkommen.
Da ich jetzt einige Teile "neu" gestalte könnte ich das Protokoll auf MQTT ändern.
Könnte es damit besser werden?
Das ist ja interessant. Meine sahen vorher schon sehr sehr unruhig aus. Hat sich hinterher auch nicht geändert. Allerdings sind die nicht über MQTT sondern über ColoT eingebunden. Ebenfalls ohne Cloud.
Und schalten tut der o.a. Shelly nie. Also daran sollte es nicht liegen.
Das hast Du vollkommen richtig erkannt. Home-Assistant ist meine Smart-Home-Lösung. Respekt 
Ich würde ein Bild aus z.B. ioBroker bestimmt nicht zuordnen können .
Aber wirklich interessant, dass die Shellys um knapp 10°C "abstürzen" Da hätte ich so nicht mit gerechnet..
Bist Du sicher, dass das ein Fehler ist?
Sieht für mich nämlich wie Transientenspannung beim Einschalten vom Kühlschrank / Tiefkühltruhe aus.
wird jetzt wohl eh eine ganz merkwürdige Lösung. Da er sich null um was gekümmert hat sind die Markisen jetzt nur per Fernsteuerung (Somfy) zu schalten.
AlexAn ja. So werde ich es jetzt auch halten. Ich bestimme die Hardware.
